zk-SNARKs vs zk-STARKs: Which Is Quantum Secure?

TL;DR: zk-SNARKs rely on elliptic curve pairings and discrete logarithm hardness — both efficiently broken by Shor's algorithm on a sufficiently powerful quantum computer. zk-STARKs rely only on collision-resistant hash functions, which are attacked by Grover's algorithm at most quadratically — a 256-bit hash retains approximately 128 bits of quantum security. For long-term ZK infrastructure, STARKs are the only production-ready quantum-resistant option. No production SNARK system is quantum safe as of 2026.

Background: What Makes a ZK Proof System?

Zero-knowledge proof systems allow one party (the prover) to convince another (the verifier) that a statement is true without revealing any information beyond the truth of that statement. The two dominant families in production blockchain systems — SNARKs and STARKs — achieve this through fundamentally different mathematical foundations, and those foundations determine their quantum security profiles.

Understanding the quantum security of a ZK scheme requires identifying which computational hardness assumption underlies the proof system's soundness. If that assumption is efficiently solvable by a quantum computer, the entire proof system collapses. If the assumption is only polynomially harder for a quantum computer (as with hash functions), the scheme can be made quantum-safe by parameter adjustment.

zk-SNARKs: The Elliptic Curve Dependency

Succinct Non-Interactive Arguments of Knowledge (SNARKs) achieve their extraordinary proof compression — often below 1 KB — through algebraic techniques built on bilinear pairings over elliptic curves. The most widely deployed SNARK constructions are:

• Groth16 — used in Zcash Sapling, Loopring, and many early ZK systems. Requires a per-circuit trusted setup ceremony. Proof size approximately 192 bytes.
• PLONK — used in Aztec Protocol, Polygon zkEVM, and Miden. Universal trusted setup (not per-circuit). Proof size approximately 1–2 KB.
• Nova/SuperNova — recursive folding schemes using Pedersen commitments over elliptic curves. Used in some zkVM research.
• Halo2 — used by the Zcash Foundation and Scroll. Eliminates the trusted setup using polynomial commitments over elliptic curves.

The curves involved are specifically BN128 (also called BN254), BLS12-381, and the Pasta curves (Pallas/Vesta). Every one of these systems is an instance of the same underlying problem: the hardness of the discrete logarithm in a cyclic group of prime order. For pairing-based SNARKs, soundness additionally depends on assumptions like the d-power Knowledge of Exponent assumption (d-PKE) or q-Strong Diffie-Hellman (q-SDH) — all group-theoretic assumptions over elliptic curves.

Why Shor's Algorithm Destroys SNARK Security

Shor's algorithm (1994) solves the discrete logarithm problem in polynomial time on a quantum computer. On a classical computer, the best known algorithms (general number field sieve, Pollard rho) require sub-exponential or exponential time. Shor's algorithm reduces the problem to quantum Fourier transforms, solving it in O((log N)^3) quantum gate operations.

The practical implication: any SNARK whose soundness depends on discrete logarithm hardness — over any elliptic curve group — is breakable by a quantum adversary with a sufficiently large fault-tolerant quantum computer. Current estimates suggest breaking BN254 would require approximately 2,000–3,000 logical qubits (after error correction), mapping to millions of physical qubits with near-term hardware. This is not achievable today, but the trajectory of quantum hardware development means "harvest now, decrypt later" attacks already threaten ZK systems storing long-term secrets.

Critically, for ZK rollups used as validity provers (zkSync Era, Starknet, Polygon zkEVM), a quantum adversary who can forge proofs can submit invalid state transitions that appear valid to the L1 verifier contract. This is a catastrophic security failure — an attacker could drain the rollup bridge without any fraud proof mechanism catching it, since validity proof systems have no fraud windows.

The Trusted Setup: A Compounding Vulnerability

Many SNARKs require a "trusted setup" ceremony — a multi-party computation (MPC) that generates a Structured Reference String (SRS). The security of the SRS depends on participants honestly deleting their "toxic waste" (private trapdoor values). If any participant retains this trapdoor, they can forge proofs.

The quantum dimension adds a second layer of risk: the SRS itself consists of elliptic curve group elements. If a quantum computer recovers the underlying field elements from the published SRS (by solving discrete logs), the attacker reconstructs the toxic waste without needing any participant to cooperate. For Groth16 circuits with per-circuit setups, this means every ceremony published on-chain is a target once quantum hardware matures.

PLONK's universal SRS (the KZG polynomial commitment ceremony, such as Ethereum's "Powers of Tau") is similarly vulnerable — the published G1 and G2 elements are discrete-log instances over BLS12-381.

zk-STARKs: The Hash-Only Foundation

Scalable Transparent Arguments of Knowledge (STARKs) were designed by Eli Ben-Sasson and collaborators specifically to avoid trusted setups and elliptic curve dependencies. Their security reduces to a single assumption: collision resistance of the underlying hash function. In production deployments (StarkEx, Starknet, Cairo), this is typically Pedersen hash (over the Stark curve) for in-circuit commitments, and BLAKE2 or Keccak-256 for the Fiat-Shamir heuristic that makes the interactive proof non-interactive.

The proof structure uses Polynomial IOPs (Interactive Oracle Proofs) combined with FRI (Fast Reed-Solomon IOP of Proximity) for low-degree testing. Neither step requires algebraic groups — only finite field arithmetic and hash functions.

Hash functions face Grover's algorithm on quantum hardware. Grover provides a quadratic speedup: searching a space of size N takes O(sqrt(N)) quantum queries instead of O(N) classical queries. For a 256-bit hash like SHA-256 or BLAKE2b-256, Grover reduces the effective security from 256 bits to 128 bits. This is the widely cited "128-bit post-quantum security" of SHA-256.

128-bit security is considered sufficient by NIST for long-term security through at least 2050 under current projections. The practical Grover attack requires maintaining approximately 2^64 qubits in superposition with extremely low error rates — hardware challenges that remain unsolved. The math is sound; the engineering is extraordinarily difficult.

Poseidon Hash: The ZK-Friendly Post-Quantum Option

SHA-256 and BLAKE2 are efficient for native computation but expensive inside arithmetic circuits (ZK proofs). The Poseidon hash function was designed specifically for ZK-circuit efficiency — it operates entirely over prime fields using algebraic operations that translate naturally to R1CS/AIR constraints.

Starknet's Cairo VM uses Poseidon for its proof system internals. Poseidon's security relies on algebraic structure within a prime field, not elliptic curve groups, making it quantum-resistant under the same hash collision hardness argument. However, Poseidon's cryptanalysis is less mature than SHA-256 — it is a newer design and has seen fewer years of public scrutiny. For maximum assurance, combining Poseidon (for circuit efficiency) with SHA-256 (for final commitments) provides defense in depth.

Proof Size Trade-offs

The primary engineering cost of using STARKs is proof size. The compression efficiency of SNARKs comes precisely from the algebraic structure (pairings, polynomial commitments over elliptic curves) that makes them quantum-vulnerable. STARKs using FRI produce larger proofs because they rely on redundancy in Reed-Solomon codes rather than algebraic condensation.

Scheme	Proof Size	Trusted Setup	Quantum Security	Production Use
Groth16	~192 bytes	Yes (per-circuit)	None (Shor breaks it)	Zcash Sapling, Loopring
PLONK (KZG)	~1-2 KB	Yes (universal)	None (Shor breaks it)	Aztec, Polygon zkEVM
Halo2 (IPA)	~10-30 KB	No	None (Shor breaks it)	Zcash Orchard, Scroll
FRI-STARK	50-200 KB	No	~128-bit (Grover only)	Starknet, StarkEx, dYdX
Lattice SNARK (research)	10-100 KB	Varies	~128-bit (lattice hard.)	None (pre-production)

Recursive Proofs and the Quantum Surface Area

Modern ZK systems use recursive proof composition — proofs of proofs — to achieve scalability. Starknet's Cairo VM supports recursive STARK proofs where each proof attests to the verification of multiple prior proofs. Because each step in the recursion uses STARKs, the entire recursive stack is quantum-resistant. The proof size does not grow with recursion depth in Starknet's design.

By contrast, Polygon's zkEVM uses PLONK recursion. Each step in the recursive aggregation introduces new elliptic curve pairing operations and new discrete logarithm instances. Polygon has announced research into post-quantum-safe ZK circuits but has not shipped production quantum-resistant proofs as of 2026.

zkSync's Boojum prover (introduced in 2023) uses a combination of PLONK and FRI — a "PLONK over FRI" construction. The FRI component provides the proximity testing, but the polynomial commitment scheme still uses KZG commitments over BLS12-381. The soundness reduction for the overall system therefore still relies on elliptic curve discrete logarithm hardness. The FRI alone being hash-based is insufficient — the system is only as quantum-resistant as its weakest link.

Post-Quantum SNARKs: The Research Landscape

Several research directions aim to produce SNARKs with quantum-resistant security:

Lattice-based SNARKs use the hardness of Learning With Errors (LWE) or Module-LWE (the basis of CRYSTALS-Kyber and CRYSTALS-Dilithium, standardized by NIST in 2024). Schemes like Ligero, Compressed Sigma Protocols over lattices, and LaFranc provide polynomial commitments from lattice assumptions. The challenge is efficiency: lattice arithmetic produces larger proofs and slower verification than pairing-based schemes by roughly two orders of magnitude.

Hash-based SNARKs use Merkle tree commitments and sumcheck protocols — essentially STARK variants with different algebraic structure. Some constructions (Brakedown, Orion) achieve sublinear verification using only symmetric primitives, but proof sizes remain large (1–10 MB range).

Code-based SNARKs use error-correcting codes as the underlying hard problem. These have strong theoretical properties but remain impractical for blockchain verification due to verifier complexity.

None of these post-quantum SNARK constructions have been deployed in production blockchain systems as of 2026. The research community estimates production-ready lattice-based SNARKs may be 3–5 years from deployment at current progress rates.

Implications for Privacy Protocols

Privacy protocols using ZK proofs face a particularly acute quantum risk. Zcash's Sapling protocol uses Groth16 — any shielded transaction published today becomes transparent to a quantum adversary who can reconstruct the proving key trapdoor from the trusted setup SRS. The "harvest now, decrypt later" threat model applies: an adversary recording Zcash transactions today could retroactively break the privacy guarantees once quantum hardware matures.

Tornado Cash's note commitments used Groth16 (before regulatory actions). Aztec's Noir circuit compiler targets PLONK. Both are quantum-vulnerable for stored notes and historical transactions.

Zcash Foundation has announced research into post-quantum Sapling, but no deployment timeline exists. The Zcash community recognizes this as a long-term existential risk to the privacy guarantees that define the protocol's value proposition.

QuanChain's ZK Architecture

QuanChain uses ML-DSA-87 and SLH-DSA composite signatures for all on-chain transactions — these are NIST-standardized post-quantum signature schemes that replaced elliptic curve signatures at genesis. For ZK proof applications on QuanChain, the protocol architecture requires STARK-based proofs (FRI + hash commitments) or lattice-based constructions as they mature, with hard exclusion of any elliptic-curve-pairing-based proof system from the core consensus and settlement layers.

This means QuanChain cannot natively settle Groth16 or PLONK validity proofs without a quantum-vulnerable trust assumption. ZK applications building on QuanChain must use hash-based proof systems — a constraint that aligns with the ecosystem's long-term quantum-resistant posture. See the guide on Layer 2 quantum security for how existing L2 rollups compare.

Practical Guidance: Evaluating ZK System Quantum Risk

When evaluating any ZK system for quantum risk, apply this checklist:

1. Identify the polynomial commitment scheme. If it uses KZG (BLS12-381 or BN254 pairings), it is quantum-vulnerable. If it uses IPA (Inner Product Argument) over a non-pairing curve, it is quantum-vulnerable (Shor applies to discrete logs in any group). If it uses FRI (hash-only), it is quantum-resistant.

2. Check the Fiat-Shamir hash function. Even a STARK using FRI needs a quantum-safe hash for its Fiat-Shamir transform. SHA-256 and BLAKE2b-256 provide ~128-bit post-quantum security. MD5 or SHA-1 are broken classically and must never be used.

3. Examine the trusted setup surface. Any published SRS (KZG ceremonies, Groth16 ceremonies) is a potential quantum attack target. The attack is retroactive — all historical proofs become forgeable once the trapdoor is recovered from the published SRS.

4. Evaluate recursion depth independently. A recursive system where any level uses elliptic curve commitments inherits that quantum vulnerability throughout the stack.

Conclusion

The quantum security divide between SNARKs and STARKs is stark (no pun intended). SNARKs derive their efficiency from elliptic curve pairings — a cryptographic structure that Shor's algorithm efficiently destroys. STARKs derive their security from hash collision resistance — a structure that Grover's algorithm weakens quadratically but does not break with 256-bit parameters. For blockchain systems, ZK rollups, and privacy protocols that need security guarantees lasting decades, STARKs represent the only production-ready quantum-resistant zero-knowledge proof system available today.

The cost is proof size: 50–200 KB versus 0.2–2 KB for SNARKs. On modern L1 networks, this translates to higher calldata costs for STARK proof verification. As Ethereum's EIP-4844 and subsequent blob fee mechanisms continue to develop, this cost differential is decreasing. The tradeoff — paying more in proof size to avoid quantum vulnerability — is increasingly the correct engineering choice for any system intended to operate securely beyond a 5–10 year horizon.

For further reading, see our analysis of how Layer 2 networks handle quantum security, and our overview of post-quantum cryptography primitives.