Quantum hardware still tops out at only a few thousand physical qubits, yet the cryptographers behind today's blockchains already feel the heat. A single machine that can run Shor's algorithm on 256-bit elliptic-curve keys would unravel the math that keeps privacy-preserving smart contracts from impersonating the prover.
How urgent is that threat, and what stands between current systems and a post-quantum safety net?
Spoiler alert: The safety net already exists, but it costs some extra gas, extra compute, and (at least so far) significantly more developer friction than most projects budget for.
Investors and protocol governors alike are beginning to demand explicit migration plans, but few chains are actually delivering. Waiting until the drop of a shrill all-caps "Q-Day" headline is not a strategy; this article explores a few options that are.
Where Classical Zero Knowledge Proofs (ZKPs) Crack
Before diving into some proposed fixes, let's note where the issues are the most likely to appear.
The dominant zero-knowledge (ZK) engine on public chains today is zk-SNARK. Its best-known constructions, Groth16 and Plonk, depend on elliptic-curve pairings, and those curves break once a sufficiently powerful quantum computer extracts the private key behind any on-chain parameter, a risk laid out in a 2023 primer by Chainlink on zero knowledge proof types.
In particular, Ethereum's layer 2 (L2) rollup ecosystem for scaling amplifies the exposure. Virtually every live zkEVM, including Linea, zkSync Era, Scroll, and Polygon zkEVM, posts Groth16 or Plonk proofs back to the mainnet, meaning the rollup inherits the same quantum shelf life as the layer-1 (L1) verifier pre-compile. A quantum attacker able to forge one valid zero knowledge proof could withdraw funds or inflate token supplies.
Many privacy coins sit on the same unstable tectonic plate. An academic review of the vulnerability of blockchains to quantum attacks labels Zcash's trusted-setup SNARK "highly vulnerable." Even community threads concede that the vulnerability will remain unless a post-quantum SNARK replaces it.
Hash-based STARKs
If the threat lives in elliptic curves, abandon them.
Hash-based systems grouped under the zk-STARK banner do exactly that. The principle is that a STARK relies only on collision-resistant hashes, which remain safe even if quantum computers gain dramatic speed-ups. In short, the scheme is provably post-quantum.
But, the leap carries two downsides. Proofs expand from a size of roughly 200 bytes to tens of kilobytes. Verifying those larger objects costs dramatically more times more gas on Ethereum. Projects such as dYdX v4 and Starknet accept the hit because they value future proofing over short-term fees.
Take a look at this table comparing systems and their mitigation potential:
As you can see, even though zk-STARK and Brakedown/HyperPlonk-based solutions are PQC-secure, the infrastructure to implement them isn't fully evolved as of yet.
Importantly, hash hardness matters. Even with a million physical qubits, inverting a 256-bit hash remains impractical.
Verifiable Computing Meets Real Budgets
Theory alone does not pay gas bills. Nor does being secure, at least not in isolation.
Georgetown professor and a16z crypto researcher Justin Thaler argues that "a verifiable-computing protocol is only as useful as its cost profile." An astute point, especially from the standpoints of both users and investors, which he documents in a survey of proof systems. Benchmarks from his debates with Srinath Setty show that STARK-style FRI proofs run typically orders of magnitude slower than Groth16, as captured in a benchmark analysis.
Developers therefore juggle three competing issues.
The security horizon (also known as the time until quantum hardware matures)
Proof cost (whether sequencers can recoup the fee overhead)
Integration friction (how much tooling must be rewritten, typically to the chagrin of developers)
Thaler's takeaway on this front is exceedingly unsentimental, arguing to publish cost models rather than white papers. He's probably right.
To make that more concrete in terms of mitigation steps to take:
Inventory every circuit that relies on elliptic-curve pairings before budgeting any migration.
Prototype hash-based back-ends with libraries such as Winterfell to gauge proof weight.
Publish gas cost projections under EIP-4844 and danksharding so users see the spread; don't try to market it to them, just explain the situation and set expectations conservatively.
Stage migrations behind opt-in dual-proof formats, letting live contracts flip gradually.
Fund audits that compare classical and post-quantum circuits for semantic parity.
Each move forces teams to price in risk rather than hand-wave it. Getting communities on board will be a challenge, but it'll be a bit easier when there's a clear plan of action and reasonable estimates for what changes or new costs users will need to shoulder.
Separately, for investors, there's a lot of high-signal information to observe here. Watch the mitigation discussion, planning, and implementation process carefully. Skilled teams will probably find the above process challenging and time-consuming to do correctly and comprehensively; less-skilled teams will likely miss the interplay between details and tradeoffs that make the exercise a difficult one. When it comes to communication about what's going on, it'll be quite easy to determine who has it together and who is disorganized.
What Happens If Ethereum Waits?
Can Ethereum hard-fork to implement PQC if it has to? Many would reflexively argue that the answer to that question is unambiguously yes, but the truth is a bit more complicated.
The canonical SNARK verifier lives in a pre-compile baked into the Ethereum Virtual Machine (EVM). Swapping that opcode for a STARK verifier instead of simply adding a new one would break byte-code assumptions across thousands of contracts. Coordinating such a switch under time pressure risks chaos reminiscent of the 2016 DAO fork, but this time magnified by every rollup that depends on the pre-compile.
Attackers need not wait. They can harvest call-data now, then crack it later, and at least a few probably are doing exactly that. Once a private key leaks via quantum methods, forging proofs is possible.
Investors do not need to become cryptographers, but they should ask pointed questions.
Does the rollup you back publish benchmarked STARK provers? Has the privacy protocol rehearsed a dual-proof upgrade? If the answer is "we'll cross that bridge when we come to it," be aware that the bridge might have already collapsed at that point.
To keep up with the latest in blockchain technology and quantum computing, join us on X and subscribe to our newsletter.
