Are zk-Rollups Quantum-Safe? The Real Answer Behind SNARKs, STARKs, and Ethereum's 2026 Quantum Roadmap
Published by: QubitChain Research
URL: qubitchain.io/blog/zk-rollups-quantum-safe-snark-stark-ethereum-roadmap
Category: Blockchain Scaling and Security, Post-Quantum Cryptography
Reading Time: Approximately 16 minutes
Last Updated: August 2026
Most discussion of blockchain and quantum computing stops at wallets and consensus. Break ECDSA, drain exposed addresses, done. That framing skips an entire layer of the modern blockchain stack that carries its own, separate quantum exposure, one that scales, secures, and increasingly defines Ethereum itself: zero-knowledge proofs.
Definition: The Real Question
Not "are zk-rollups quantum-safe," which treats zero-knowledge proofs as one category. The accurate question is which cryptographic commitment scheme a specific proving system uses, because that choice, not the "SNARK" or "STARK" label attached to it, determines whether it survives a quantum computer.
That distinction sounds pedantic until you see how much confusion it clears up. Billions of dollars in total value locked sit behind zk-rollups today, each one making a specific, often under-examined cryptographic choice about how it commits to and verifies computation. Some of those choices are provably safe against Shor's algorithm. Others are exactly as exposed as the ECDSA signatures securing an ordinary Bitcoin wallet. And in February 2026, Ethereum's own co-founder published a detailed roadmap acknowledging exactly that.
The Mechanical Difference: Why Some Proofs Break and Others Don't
Zero-knowledge proof systems let a prover convince a verifier that a statement is true, in blockchain's case, that a batch of thousands of transactions was executed correctly, without the verifier redoing the computation itself. The proof is small; the underlying computation can be enormous. That's the entire value proposition for a rollup: compress a huge amount of off-chain work into a proof cheap enough to verify on a congested, expensive Layer 1.
How that compression happens is where the quantum question actually lives.
The proof systems most people default to thinking of as "zk-SNARKs," Groth16 and KZG-based PLONK variants, achieve their remarkable compactness (Groth16 proofs run 200 to 300 bytes, genuinely tiny) through elliptic curve pairings. A pairing is a specialized mathematical operation that maps two points on an elliptic curve to a value in a different algebraic structure in a way that preserves certain relationships, and it's what lets these systems commit to enormous polynomials with a handful of curve points instead of the polynomials themselves. It's an elegant piece of mathematics. It's also, for exactly the same reason ECDSA is vulnerable, built on the discrete logarithm problem over an elliptic curve group, a problem Shor's algorithm solves in polynomial time on a sufficiently powerful quantum computer. Break the pairing-friendly curve, and you don't just forge one transaction signature; you can forge proofs that entire fraudulent transaction batches were executed correctly.
STARKs, introduced by Eli Ben-Sasson and collaborators at StarkWare in 2018, take a structurally different approach. Instead of committing to polynomials via elliptic curve points, they use the FRI protocol (Fast Reed-Solomon Interactive Oracle Proof of Proximity), which commits to polynomials using nothing but Merkle trees and hash functions. There's no elliptic curve anywhere in a STARK's core commitment scheme, which means there's no discrete logarithm problem for Shor's algorithm to attack. The tradeoff is size: STARK proofs typically run 40 to 200 kilobytes, one to three orders of magnitude larger than a Groth16 SNARK, because you're paying in Merkle authentication paths and polynomial evaluation openings for the privilege of not depending on elliptic curves at all.
That's the mechanical core of the whole question, and it's worth stating plainly: it's not "SNARKs are quantum-vulnerable and STARKs are safe" as a rule about naming conventions. It's "elliptic curve pairing-based polynomial commitments are quantum-vulnerable, and hash-based polynomial commitments aren't," and the SNARK and STARK labels only track that distinction reliably in the simplest, oldest systems.
Why the SNARK/STARK Label Stopped Being Reliable
Here's where most coverage of this topic, understandably, gets sloppy, and where it's worth being unusually precise.
Modern proving systems increasingly mix and match. Plonky2, developed at Polygon, uses PLONK-style arithmetization, the flexible constraint system that made PLONK popular, but swaps out PLONK's traditional KZG commitment scheme for FRI-based commitments instead. The result inherits PLONK's circuit-design flexibility and FRI's hash-based, non-elliptic-curve foundation simultaneously, producing proofs larger than a KZG-based SNARK but smaller than a full STARK, and critically, without the quantum exposure a KZG commitment carries. Whether you call that a "SNARK" or a "STARK" is almost a semantic argument at that point; what matters is that its commitment scheme is hash-based.
zkSync's proving system tells a similar story from the other direction. Matter Labs migrated away from an earlier, KZG/PLONK-based proving system to Boojum, which uses FRI-based commitments over the Goldilocks field rather than elliptic curve pairings. Depending on which explainer you read, you'll see Boojum described as a "SNARK" (because it produces succinct, cheap-to-verify final proofs) or a "STARK" (because its core commitment scheme is hash-based like a STARK's). Both descriptions are capturing something real; neither is capturing the full picture on its own. The commitment scheme is what determines the quantum exposure, and on that specific axis, Boojum's FRI-based approach sits on the hash-based, not-vulnerable-to-Shor's-algorithm side.
Contrast that with Scroll, which has built its proving system on Halo2 using KZG commitments specifically to achieve tight, bytecode-level EVM equivalence. That's a deliberate, reasonable engineering tradeoff for a different priority, developer compatibility over cryptographic future-proofing, but it means Scroll's core proving system carries the same elliptic-curve-pairing exposure a Groth16 SNARK does.
This is a fast-moving landscape, prover systems get upgraded, chains migrate commitment schemes, and any specific claim about a specific project's exact current setup should be checked against that project's own current documentation before you treat it as permanent fact. But the framework for evaluating any of them doesn't change: ask what the polynomial commitment scheme is, not what the marketing calls the overall system.
| System | Commitment Scheme | Elliptic Curve Pairings? | Quantum-Vulnerable Core? |
|---|---|---|---|
| Groth16 | Trusted-setup pairing-based | Yes | Yes |
| KZG-based PLONK | Pairing-based (KZG) | Yes | Yes |
| Halo2 with KZG (used by Scroll) | Pairing-based (KZG) | Yes | Yes |
| Plonky2 (Polygon) | FRI (hash-based) | No | No |
| Boojum (zkSync) | FRI over Goldilocks field | No | No |
| StarkNet / StarkEx (StarkWare, Cairo VM) | FRI (hash-based) | No | No |
| Labrador (emerging, lattice-based) | Module-SIS lattice commitments | No | No (lattice-based assumption) |
The Trap Almost Nobody Talks About: What Happens When You Wrap a STARK in a SNARK
There's a genuinely important nuance here that most coverage of "which rollups are quantum-safe" misses entirely, and it matters more than the table above suggests on its own.
A growing pattern in production ZK systems, RISC Zero and Succinct's SP1 among the clearest examples, generates a STARK proof of arbitrary program execution internally, where the hash-based, quantum-resistant properties genuinely apply, and then wraps that STARK inside a final Groth16 SNARK specifically to make on-chain verification cheap, since verifying a 100-kilobyte STARK proof directly on Ethereum costs meaningfully more gas than verifying a 200-byte Groth16 proof.
This is a smart, pragmatic engineering decision for gas costs today. It is also, if you don't think it all the way through, a quiet reintroduction of exactly the quantum vulnerability the STARK layer was supposed to avoid. The full pipeline's actual quantum security is only as strong as its weakest link, and the weakest link in a STARK-wrapped-in-a-Groth16 system is the final wrapper, the part that actually gets verified on-chain. A quantum computer capable of breaking the elliptic curve underlying that final Groth16 layer can forge the wrapper regardless of how cryptographically sound the STARK inside it was. The STARK's post-quantum properties matter enormously for the prover's internal integrity guarantees; they don't automatically extend to the system's on-chain verification security once a classical wrapper is bolted on for gas efficiency.
This is precisely the kind of detail that gets lost when "does it use STARKs" becomes shorthand for "is it quantum-safe." The honest answer for any wrapped system is: it depends entirely on what the outermost, on-chain-verified layer is built on, not on what happens inside the black box before it gets there.
Ethereum's Own Answer: Inside Vitalik Buterin's February 2026 Quantum Roadmap
This entire question stopped being theoretical for Ethereum specifically in February 2026, when Vitalik Buterin published a detailed roadmap identifying exactly four areas of Ethereum's cryptography he considers exposed to a future quantum computer:
- Consensus-layer BLS signatures
- KZG-based data availability commitments
- ECDSA-based externally owned account signatures
- Application-layer zero-knowledge proofs built on KZG or Groth16
That fourth category is the one this article has been building toward, and having it named explicitly, by Ethereum's own co-founder, in a public roadmap, is about as strong a confirmation as this analysis could ask for. Buterin's post was direct about the tradeoff: Ethereum's current ZK-SNARK verifications are relatively cheap, and quantum-resistant STARK-based alternatives cost meaningfully more, which is exactly the wrapping-for-gas-efficiency tension described above, now playing out at the base-layer protocol level rather than just within individual rollups.
The roadmap that followed, an Ethereum Foundation initiative organized around a staged, multi-fork upgrade path informally called the "Strawmap" internally, targets full deployment through 2029 and gets specific in ways worth knowing. At the consensus layer, BLS validator signatures would move to hash-based alternatives, drawing on the same SPHINCS+ lineage covered in our SLH-DSA deep dive, alongside recursive STARK aggregation to compress the cost of validating many individual attestations into a single proof. For data availability, KZG commitments, currently central to how Ethereum verifies that rollup data is properly structured and available, would move toward STARK-based or lattice-based alternatives, though Buterin has been candid that STARKs lack a mathematical property called linearity that Ethereum's current two-dimensional data availability sampling design depends on, meaning this specific swap is "manageable, but there's a lot of engineering work to do" in his own words, not a drop-in replacement.
The gas cost gap Buterin cited is worth sitting with as a concrete number:
| Verification type | Gas cost | Relative cost |
|---|---|---|
| Standard ECDSA signature verification | ~3,000 gas | Baseline |
| Quantum-resistant signature verification | ~200,000 gas | ~65x more expensive |
That's the same signature-size-to-throughput tradeoff every post-quantum migration runs into, just measured in Ethereum's own fee unit instead of raw bytes, and it's why the roadmap leans so heavily on recursive proof aggregation, compressing many expensive individual verifications into one cheaper aggregate proof, as the mechanism that makes the whole migration economically survivable rather than something that quietly multiplies every user's transaction cost by sixty-five.
What This Means If You're Building or Choosing a ZK System
For a rollup team currently choosing or evaluating a proving system, the quantum-security question has a specific, answerable checklist, not a vague vibe check.
What is the actual polynomial commitment scheme, not the marketing label. KZG in any form, whether inside a Groth16 SNARK, a PLONK variant, or a Halo2 system, carries the elliptic-curve-pairing exposure. FRI, in any form, whether branded as a STARK or a PLONK-with-FRI hybrid like Plonky2, does not.
If the system wraps an internally post-quantum STARK proof in a final SNARK for gas efficiency, what is that final wrapper built on. That outermost, on-chain-verified layer is the actual quantum exposure surface for the whole pipeline, regardless of what happens upstream inside the prover.
Is there a credible, published migration path for the specific commitment scheme in use, the way Ethereum's own February 2026 roadmap now provides one for KZG. A team with no plan is a materially different risk profile than a team that's already named the problem and staged a fix, even years out.
For DeFi protocols and applications building on top of any of these systems, the practical takeaway is less about switching infrastructure today, since no quantum computer capable of exploiting any of this exists yet, and more about understanding that "our rollup uses zero-knowledge proofs" is not, on its own, a security claim about quantum resistance. It's a claim about a specific cryptographic construction that needs to be evaluated on its own mathematical terms, the same way this entire content cluster keeps insisting the underlying blockchain's signature scheme needs to be.
Where the Research Frontier Is Headed
STARKs solved the elliptic-curve-dependency problem at the cost of proof size. The most interesting current research is chasing a third option that keeps the hash-based, no-trusted-setup, quantum-resistant properties of a STARK while shrinking the proof size back down toward SNARK territory.
Labrador, built on the Module Short Integer Solution problem, the same lattice-hardness family underlying ML-DSA and ML-KEM, is one of the clearest examples: a genuinely post-quantum, trusted-setup-free proving system producing proofs on the order of 50 to 60 kilobytes for large circuits, meaningfully smaller than a typical STARK while retaining STARK-equivalent security assumptions rather than elliptic-curve ones. It's early-stage research relative to the years of production hardening behind Groth16 or PLONK, but it's evidence that "post-quantum" and "compact" aren't permanently in tension the way the current SNARK-versus-STARK tradeoff makes them look.
That's also, not coincidentally, the exact same story the rest of NIST's post-quantum standardization has told: the first generation of solutions trades size or speed for safety, and the research community spends the following years clawing that cost back down without giving up the safety. Lattice-based zero-knowledge proofs are still in that early phase. Worth watching, not yet worth betting production infrastructure on.
Where This Connects to the Base Layer
Everything in this article has been about the proof layer, a question that sits one level above the base blockchain protocol itself. But the underlying logic doesn't change as you move down the stack: a system's quantum resistance is only as strong as its most exposed cryptographic primitive, whatever layer that primitive lives in, and swapping a label for the underlying math is the mistake to avoid at every layer, not just the ZK proof layer.
That's the same principle QubitChain.io applies at the base protocol itself. Every transaction signature runs on ML-DSA from the genesis block, not a legacy elliptic-curve scheme with a promised future upgrade. There's no wrapper, no gas-efficiency shortcut that quietly reintroduces a Shor's-algorithm-breakable dependency at the layer that actually gets verified on-chain. If you're evaluating infrastructure with the same rigor this article just applied to zero-knowledge proof systems, that consistency, checking what's actually happening under the label rather than trusting the label itself, is the right standard to hold the base layer to as well.
Full architecture: qubitchain.io/whitepaper. Full blockchain-by-blockchain quantum security comparison: qubitchain.io/compare.
Frequently Asked Questions
Q: Are zk-rollups quantum-safe?
A: It depends entirely on the specific proving system's polynomial commitment scheme, not on whether it's labeled a SNARK or a STARK. Systems using elliptic curve pairing-based commitments like KZG (including Groth16 and many PLONK variants) are vulnerable to Shor's algorithm on a quantum computer, the same way ECDSA is. Systems using FRI-based, hash-only commitments, the core mechanism behind STARKs, are not vulnerable to Shor's algorithm because they contain no elliptic curve discrete logarithm problem to break.
Q: What is the difference between a zk-SNARK and a zk-STARK for quantum security?
A: Traditional zk-SNARKs like Groth16 achieve small, cheap-to-verify proofs using elliptic curve pairings, which are broken by Shor's algorithm on a sufficiently powerful quantum computer. zk-STARKs, introduced by Eli Ben-Sasson and StarkWare in 2018, use the FRI protocol instead, committing to polynomials with Merkle trees and hash functions rather than elliptic curve points, making them resistant to Shor's algorithm. The tradeoff is size: STARK proofs typically run 40 to 200 kilobytes versus 200 to 300 bytes for a Groth16 SNARK.
Q: Does wrapping a STARK in a SNARK reintroduce quantum vulnerability?
A: Yes, in the specific part of the system that gets verified on-chain. Systems like RISC Zero and SP1 generate a hash-based, quantum-resistant STARK proof internally, then wrap it in a final Groth16 SNARK to reduce on-chain gas costs for verification. That final Groth16 wrapper depends on elliptic curve pairings, meaning the outermost, on-chain-verified layer of the pipeline carries the same quantum exposure as any Groth16 SNARK, regardless of the STARK's post-quantum properties earlier in the pipeline.
Q: What did Vitalik Buterin say about Ethereum and quantum computing?
A: In February 2026, Vitalik Buterin published a roadmap identifying four areas of Ethereum vulnerable to quantum computers: consensus-layer BLS signatures, KZG-based data availability commitments, ECDSA-based account signatures, and application-layer zero-knowledge proofs built on KZG or Groth16. The roadmap proposes moving toward hash-based signatures, STARK or lattice-based data availability commitments, and recursive STARK aggregation to manage the higher computational cost of post-quantum verification, targeting deployment across multiple upgrades through 2029.
Q: Which Ethereum Layer 2s use post-quantum-safe proving systems?
A: StarkNet and StarkEx, built by StarkWare on STARK proofs with no trusted setup, are the clearest case of a system using hash-based, non-elliptic-curve commitments. Polygon's Plonky2 and zkSync's Boojum both use FRI-based polynomial commitments rather than KZG, placing their core proving systems on the hash-based side as well, though this landscape evolves frequently and should be verified against current project documentation. Scroll's Halo2-based system uses KZG commitments, which carry the same quantum exposure as a traditional SNARK.
Q: Why does Ethereum's data availability layer (KZG) need to change for quantum resistance?
A: Ethereum currently uses KZG commitments, an elliptic curve pairing-based scheme, to verify that rollup data posted to the network is properly structured and available. Because KZG relies on elliptic curve cryptography, it is vulnerable to Shor's algorithm. Vitalik Buterin's 2026 roadmap proposes replacing it with STARK-based or lattice-based alternatives, though he has noted this requires substantial engineering work because STARKs lack a mathematical linearity property Ethereum's current data availability sampling design depends on.
Q: How much more expensive is post-quantum verification on Ethereum?
A: According to figures Vitalik Buterin cited in his February 2026 roadmap, standard ECDSA signature verification costs approximately 3,000 gas on Ethereum, while quantum-resistant signature verification alternatives can cost around 200,000 gas, roughly a sixty-five-fold increase. This is why the proposed roadmap relies heavily on recursive proof aggregation, compressing many individual verifications into a single cheaper proof, to keep the migration economically viable.
Q: What is Labrador and how is it different from a STARK?
A: Labrador is an emerging zero-knowledge proving system built on the Module Short Integer Solution problem, the same lattice-based hardness assumption family underlying NIST's ML-DSA and ML-KEM standards. Like a STARK, it requires no trusted setup and is not vulnerable to Shor's algorithm, but its proofs run around 50 to 60 kilobytes for large circuits, meaningfully smaller than a typical STARK's 40 to 200 kilobyte range, representing an early-stage attempt to combine STARK-level quantum resistance with more competitive proof sizes.
Q: Is Groth16 quantum-safe?
A: No. Groth16 depends on elliptic curve pairings and a per-circuit trusted setup ceremony. The pairing-based commitment scheme relies on the elliptic curve discrete logarithm problem, which Shor's algorithm solves in polynomial time on a sufficiently powerful quantum computer. Groth16 remains widely used in production, including Zcash, Filecoin, and as the final wrapping layer in several STARK-based systems, but it carries the same category of quantum exposure as ECDSA.