Skip to main content

PQ scaling cliff

Post-quantum signatures can be CPU-manageable, but they are large — and that cascades into bandwidth, storage, and consensus proof scaling. We call this the PQ scaling cliff: the engineering reality that "just turn on PQ" is not a one-line change in protocols sized around 32–96 byte primitives.

This is the framing that drives many of Quantum's design choices: Falcon at consensus, the KeyVault detached-key model, the cold-vault profile being a profile rather than a default, the post-mainnet ML-KEM decision.

User layer — throughput becomes byte-limited​

Each transaction carries a larger authorization payload. Compared to a 65-byte ECDSA signature, a 2,420-byte ML-DSA-44 signature plus pubkey (3,733 B if undetached, 2,421 B detached) is roughly 37× larger. If blocks and propagation are tuned around 65–72 byte classical signatures, PQ payloads:

  • Reduce transactions per block at the same byte budget.
  • Increase propagation latency and orphan risk because each tx is bigger and propagation cost scales with bytes.
  • Increase mempool bandwidth and storage pressure — keeping a few thousand transactions in flight costs more.

Quantum's countermeasures:

  • KeyVault detached-key model. Public keys live on-chain in chunked KeyVault storage. The transaction carries the signature and a key_id, not the pubkey. This cuts ~1.3 KB off every ML-DSA-44 tx (~35% wire reduction).
  • Native AA in the envelope. No proxy-contract calldata, no ERC-4337 UserOp wrapper, no EntryPoint hops. The transaction is a real L1 transaction.
  • Batched calls. One signed envelope can execute multiple calls atomically. The signature amortizes across the batch.
  • 2D nonces. Parallel mempool queues prevent head-of-line blocking from a slow primary lane.

Consensus layer — quorum proofs grow with validator count​

In BFT-style consensus, finality requires a quorum (often 2f+1) of validator approvals. If a quorum proof contains the set of signatures, then:

quorum-proof signature bytes
   ≥  (2f + 1) × signature_size
      + signer IDs / bitmap + framing overhead

For Falcon-512 (≤ 666 B max per signature):

  • n = 100 ⇒ f = 33 ⇒ 2f+1 = 67 ⇒ ≥ 44,622 bytes (~44.6 KB)
  • n = 200 ⇒ f = 66 ⇒ 2f+1 = 133 ⇒ ≥ 88,578 bytes (~88.6 KB)

For ML-DSA-44 (2,420 B):

  • n = 100 ⇒ 2f+1 = 67 ⇒ ≥ 162,140 bytes (~162 KB)
  • n = 200 ⇒ 2f+1 = 133 ⇒ ≥ 321,860 bytes (~322 KB)

This is why Falcon is at consensus and ML-DSA is at userland. Userland tolerates a 2,420-byte signature; consensus would not.

Quantum's countermeasures:

  • Falcon at the critical path. Smallest PQ signature size standardized.
  • Threshold research with DKG to compress quorum proofs to a single signature. Benchmark-gated; not v1.
  • Hash-based checkpoint hedging at low frequency for long-horizon verifiability. Research, post-mainnet.

Where time goes — why bytes become latency​

In practice, PQ payloads show up first as:

  • Network latency pressure — bigger votes and certificates, more bandwidth on the critical path. The first bottleneck you hit.
  • Durability pressure — larger artifacts persisted; fsync / WAL sync points become more visible in latency tails. Often the second.
  • Verification pressure — usually secondary for consensus (which has plenty of CPU between votes), primary for transaction throughput on commodity hardware.

The ordering is design-dependent, but on Simplex + Falcon at the validator counts we run, network bytes are the dominant constraint and the reason Falcon was chosen.

Why these aren't "fix it with more bandwidth"​

You can't just throw bandwidth at the problem because of latency tails. A 100 ms p99 increase per hop compounds across propagation paths. Consensus has hard timing constraints — fall behind enough times and you stop participating. The right answer is to keep the bytes small in the first place, which is why scheme placement matters so much.

The same logic applies to storage: a chain that ingests 5–10× more authorization bytes per block accumulates 5–10× the historical state. Pruning helps. Static-file segmentation (Reth Storage V2) helps. Neither of these is a free lunch — they shift the cost, they don't eliminate it.

Design response​

The protocol was built around PQ payload sizes from day one: Falcon at consensus, the KeyVault detached-key model, native AA in the envelope, batched calls, and 2D nonces. Research into post-quantum threshold signatures with DKG targets further compression of the consensus quorum proof as validator counts grow.