Post-Quantum Consensus: How Blockchain Families Differ Under Quantum Attack

Replacing the signature scheme in a blockchain is not the same problem as replacing it in a web server. A web server can be upgraded on a Tuesday. A blockchain has to persuade a distributed set of independent operators to change the rules of a system that stores every signature it has ever accepted, forever, and whose entire value proposition is that the rules do not change arbitrarily.

This is the problem my current research addresses, and the comparison below is the framing I have found most useful for thinking about which consensus designs migrate gracefully and which do not.

This piece accompanies work presented at IEEE ICNC 2026. The detailed comparative results are in the paper; what follows is the conceptual picture.

Where the cryptography actually sits

It helps to separate three distinct uses of cryptography in a chain, because they face different threats and migrate on different timelines.

• Transaction signatures prove authorisation to move assets. These are the acute exposure: on most public chains a spent output reveals the public key, and Shor’s algorithm turns a revealed public key into a private key.
• Hash functions secure block linkage and, in proof-of-work, the mining puzzle. Grover’s algorithm gives a quadratic speedup against these, which is real but manageable — doubling the output length restores the security margin.
• Consensus-layer cryptography covers validator identity, block attestation, and in some designs threshold or aggregate signatures. This is where the families genuinely diverge.

The important asymmetry is that hashing degrades gracefully under quantum attack and signatures do not. Grover costs an adversary a quadratic speedup. Shor breaks the scheme outright.

Proof of work

Proof of work is, counterintuitively, the least threatened at the consensus layer. Mining is a hash preimage search, and Grover’s quadratic speedup does not collapse it — it is closer to an efficiency advantage than a break, and one that competes against highly optimised classical hardware.

The exposure in a proof-of-work chain is almost entirely in transaction signatures rather than in consensus. That is a meaningful architectural property: the consensus mechanism itself survives, and the migration problem reduces to the address and signature scheme.

The complication is the enormous quantity of historical value sitting at addresses whose public keys are already visible on-chain. Those cannot be retroactively protected. Any transition has to reckon with funds that are exposed the moment a capable machine exists, and whose owners may be unreachable or long gone.

Proof of stake

Proof of stake moves more cryptography into consensus. Validators hold keys, sign attestations, and in many implementations those signatures are aggregated — BLS being the common choice — to keep block sizes manageable when thousands of validators participate.

Aggregation is the pressure point. BLS aggregate signatures rely on pairing-friendly elliptic curves, and no post-quantum scheme currently offers equivalent aggregation with comparable compactness. Lattice-based aggregate signatures are an active research area, not a deployable substitute.

Remove aggregation and the arithmetic gets uncomfortable quickly. Individual ML-DSA signatures at roughly 2.4 to 4.6 kilobytes, multiplied across a large validator set per slot, produce a bandwidth and storage burden that pushes directly against decentralisation — because the operators who drop out first are the small ones. That trade-off between quantum resistance and participation breadth is, in my view, the most under-discussed consequence of this transition.

BFT and committee-based consensus

Classical Byzantine fault tolerant protocols and their modern descendants use signatures heavily for voting rounds, but with a structural advantage: committees are small and known. A protocol with a hundred validators exchanging larger signatures is a very different engineering problem from one with a million.

Their weakness is different. Many of these designs assume partial synchrony, and larger messages mean longer transmission times. Post-quantum signature sizes can push message propagation past timeout thresholds tuned for compact signatures, which affects liveness rather than security — the chain does not break, it stalls. That failure mode is easy to miss in analysis and obvious in production.

Hash-based consensus and the conservative option

Designs that lean on hash-based primitives rather than public-key operations start from a stronger position, because hash functions need parameter increases rather than replacement.

SLH-DSA is the relevant standardised option, and its properties are exactly what a conservative chain design would want: security resting on nothing but hash function assumptions, and therefore unaffected by any structural break in lattice cryptography. The cost is signature sizes from roughly 7.8 to nearly 50 kilobytes, which is prohibitive per transaction and entirely reasonable for infrequent, high-consequence operations like protocol upgrade authorisation or root key certification.

The plausible outcome is not one scheme but a layered one: hash-based signatures for the operations that must never fail, lattice-based for routine transaction volume.

The transition problem is governance, not mathematics

Every technical option above assumes you can deploy it. On a live public chain, that assumption is doing enormous work.

Changing a signature scheme is a consensus-breaking change. It requires a hard fork, coordinated across wallets, exchanges, custodians, node operators, and application developers with no shared authority and genuinely different incentives. The chain must continue validating historical signatures produced under the old scheme while accepting new ones, indefinitely. And funds at addresses whose owners never migrate remain permanently vulnerable, which raises a question no protocol has answered well: what, if anything, should be done about coins their owners can no longer protect?

That last question is not cryptographic. It is a question about property, governance, and who has standing to decide — and it is likely to be harder than any of the engineering.

What this means for design choices now

For anyone building a new chain rather than migrating one: the cost of designing for algorithm replacement at the outset is a fraction of the cost of retrofitting it. Version your signature scheme in the transaction format. Do not assume a signature size. Separate consensus identity from transaction authorisation so the two can migrate independently.

For existing chains, the sequencing that makes sense is to protect new value first — quantum-resistant address formats and hybrid signing — while the harder conversation about historical exposure proceeds in parallel. It will take longer than the engineering, and it should start now.