CRYSTALS-Dilithium (ML-DSA) Signature Sizes: The Blockchain Throughput Problem

TL;DR: CRYSTALS-Dilithium, standardized as ML-DSA in NIST FIPS 204, produces signatures between 2,420 and 4,595 bytes depending on the parameter set — 38 to 72 times larger than a 64-byte ECDSA signature. For blockchains, this overhead directly reduces block capacity unless the architecture is designed to absorb it. Aggregation, per-channel signature budgets, and compression are the three main mitigations. QuanChain uses all three.

What Is CRYSTALS-Dilithium and Why Does Signature Size Matter?

CRYSTALS-Dilithium, now standardized as ML-DSA under NIST FIPS 204, is a lattice-based post-quantum digital signature scheme. Its signatures range from 2,420 bytes (ML-DSA-44) to 4,595 bytes (ML-DSA-87), compared to 64 bytes for ECDSA. This size difference directly reduces how many transactions fit in a block, lowering effective throughput unless the architecture compensates.

Digital signatures are present in every blockchain transaction. Every transfer, contract call, and validator attestation carries at least one signature that every node on the network must download and verify. When that signature grows from 64 bytes to 2,420 bytes, the signature component of the average transaction grows by a factor of 38. For a chain operating close to its block size limit, this translates directly into fewer transactions per block and lower throughput — unless the architecture is explicitly designed to handle the overhead.

This is not a theoretical problem. It is the central engineering challenge of deploying post-quantum cryptography on any high-throughput blockchain. NIST finalized FIPS 204 in August 2024, settling the algorithm selection question. The throughput question remains open for most chains, and the answers differ significantly depending on architectural choices made years before post-quantum migration was on anyone's roadmap.

The Three ML-DSA Parameter Sets: Sizes and Trade-offs

FIPS 204 defines three ML-DSA parameter sets. ML-DSA-44 targets NIST security level 2 (equivalent to AES-128 against quantum adversaries) with 2,420-byte signatures. ML-DSA-65 targets level 3 with 3,309-byte signatures. ML-DSA-87 targets level 5 (equivalent to AES-256) with 4,595-byte signatures. For financial blockchain applications with long asset lifetimes, ML-DSA-65 or ML-DSA-87 is the appropriate choice.

The performance difference between parameter sets is modest. On a modern server running the reference implementation, ML-DSA-44 signs approximately 4,900 times per second and ML-DSA-87 signs approximately 2,800 times per second. Verification is faster: ML-DSA-44 verifies around 2,200 times per second and ML-DSA-87 around 1,400. These figures are sufficient for the transaction throughput most chains currently target, and hardware-optimized implementations using AVX2 or NEON SIMD instructions improve performance by two to five times.

The real constraint is not signing speed — it is bandwidth. A transaction that previously carried a 64-byte ECDSA signature now carries a 3,309-byte ML-DSA-65 signature. If the average pre-quantum transaction size was 250 bytes, the signature component has grown from 26% of the transaction to 93%. Block capacity measured in transaction count falls proportionally.

Scheme	Public key	Signature	Sign/s	Quantum safe
ECDSA (secp256k1)	33 bytes	64 bytes	~70,000	No
Ed25519	32 bytes	64 bytes	~50,000	No
ML-DSA-44 (FIPS 204 L2)	1,312 bytes	2,420 bytes	~4,900	Yes
ML-DSA-65 (FIPS 204 L3)	1,952 bytes	3,309 bytes	~3,500	Yes
ML-DSA-87 (FIPS 204 L5)	2,592 bytes	4,595 bytes	~2,800	Yes
SLH-DSA-SHA2-128s (FIPS 205)	32 bytes	7,856 bytes	~6	Yes

How Signature Size Hits Block Capacity

For a blockchain with a 1 MB block limit and 250-byte average transaction size, replacing ECDSA with ML-DSA-65 shrinks capacity from roughly 4,000 transactions per block to around 280 — a 93% reduction. The exact impact varies by chain, but the direction is universal: post-quantum signatures require architectural accommodation, not just algorithm substitution.

Consider a simplified model. Bitcoin's standard block limit is approximately 1 MB for base data (4 MB with SegWit witness discount). A typical P2WPKH transaction is about 141 virtual bytes, giving roughly 7,000 transactions per block. If the signature component grows from 64 bytes to 3,309 bytes (ML-DSA-65), the transaction size grows to approximately 3,390 virtual bytes — reducing block capacity to around 290 transactions. Even with a generous SegWit-style witness discount applied to the signature data, block capacity would fall to perhaps 1,200 transactions under optimistic assumptions.

For Ethereum, where gas limits constrain computation rather than raw bytes, the impact manifests differently: each calldata byte costs 16 gas. At Ethereum's current ~30 million gas block limit, replacing a 64-byte ECDSA signature with a 3,309-byte ML-DSA-65 signature adds approximately 51,920 gas per transaction just in calldata costs. With an average transaction consuming around 21,000 gas for a basic transfer today, a naive post-quantum upgrade would raise the gas cost of every transfer by 247% before execution costs are even counted.

The Three Mitigation Strategies

Three architectural approaches can absorb post-quantum signature overhead without abandoning throughput goals. Most production-ready post-quantum blockchains will use a combination of all three.

Signature aggregation

Aggregation combines multiple individual signatures into a single compact proof that a verifier can check against all original signers simultaneously. For ECDSA, BLS aggregation on BLS12-381 curves is well understood and deployed at scale — Ethereum's validator layer uses it. For lattice-based schemes like ML-DSA, aggregation techniques exist but are less mature. Research groups at ETH Zurich and elsewhere have published lattice aggregation constructions, but none has reached the production-ready status that BLS enjoys for ECDSA. STARK-based proofs of ML-DSA validity are a more near-term option: a single STARK proof that a set of ML-DSA signatures is valid can be verified cheaply, but proof generation is computationally expensive and adds latency.

Per-workload signature budgets

Not all blockchain transactions carry the same economic weight or latency requirement. A payment transfer completing in 200 milliseconds has different throughput demands than a smart contract deployment or a large data-anchoring operation. Architectures that separate transaction types into distinct channels can allocate different signature overhead budgets per channel — using ML-DSA-44 for high-volume, lower-value transfers and ML-DSA-87 for lower-frequency, higher-assurance operations. This matches security level to actual risk rather than applying a one-size-fits-all parameter set.

Compression and encoding efficiency

ML-DSA signatures contain significant structured data that compresses well. Lossless compression of ML-DSA-65 signatures typically achieves 15–25% size reduction, bringing the effective signature size closer to 2,500 bytes. Combined with binary encoding optimizations (eliminating DER/ASN.1 overhead), real-world deployed sizes can be meaningfully smaller than the worst-case figures in the FIPS specification. This is not a substitute for the other two strategies, but it helps at the margin.

How QuanChain Handles ML-DSA Overhead

QuanChain implements all three mitigations through its TADEQS architecture and three-channel design. Channel 1 handles payments at 200 ms finality and uses ML-DSA-44 for child-wallet signatures, keeping the per-transaction signature overhead at the lower end of the ML-DSA range. Channel 2 handles smart contract execution at 2-second finality and uses ML-DSA-65, matching a higher security level to the longer-lived state changes that contracts represent. Channel 3 handles data anchoring at 10-second finality, where larger block payloads make the relative signature overhead negligible.

The TADEQS parent identity — the Level 20 root that anchors each wallet's key hierarchy — uses the composite ML-DSA-87 + SLH-DSA-SHA2-256f combination specified in FIPS 204 and FIPS 205. This signature appears only when the parent identity is registered or updated, not on every transaction. The per-transaction overhead is carried by the child-level ML-DSA signatures, keeping the common-case cost at the ML-DSA-44 level for most users.

The result is that QuanChain delivers post-quantum security from genesis without sacrificing the throughput targets its architecture was designed around. Chains that are considering retrofitting post-quantum signatures onto an ECDSA foundation face a harder problem: they must redesign their block and transaction formats, update every wallet implementation, coordinate a hard fork, and manage the re-signing of all existing accounts — all while their existing public keys remain permanently harvestable from historical ledger data.

What Developers Building Post-Quantum Systems Should Know

If you are building a new chain or a new layer-2 protocol and intend it to remain secure past the mid-2030s, the practical guidance from the CRYSTALS-Dilithium size problem is:

• Design your transaction format for ML-DSA-65 from the start. Retrofitting a larger signature field into an existing transaction format is painful. Building for 3,309 bytes now avoids a breaking change later.
• Do not rely on SegWit-style witness discounts as your only throughput mitigation. A 75% discount on a 3,309-byte signature still leaves you with 827 effective bytes per signature — thirteen times the current ECDSA cost.
• Evaluate STARK-based signature aggregation for your use case. For chains where proof generation latency is acceptable, aggregate proofs dramatically reduce the per-transaction signature cost at the block level.
• Consider parameter set tiering. Not every transaction needs ML-DSA-87. A tiered approach matched to asset value and transaction type keeps throughput healthy for common operations.

The TADEQS documentation and QuanChain developer quickstart cover how these principles are implemented in practice on a live testnet.