Post-quantum ZK is an architecture problem

Research notes from an unfinished paper, shared to invite criticism, counterexamples, and discussion.

Post-quantum migration for deployed ZK systems is primarily an architectural problem, not a parameter-tuning problem.

Most discussions of "post-quantum ZK" collapse into a binary: PQ-safe or not PQ-safe. That framing misses the real engineering question:

Which layer of the proving stack carries the quantum-vulnerable assumption, and can that layer actually be migrated in a deployed system?

I'm working on a paper that tries to formalize this. The paper is not finished, and I would rather get challenged on the core thesis now than polish the wrong framing in isolation. What follows is an intentionally incomplete research note.

Why this matters now, not later

For ZK deployments, the quantum analogue of "harvest now, decrypt later" is not about confidentiality. It is closer to:

Collect now, forge later (CNFL).

In many deployed ZK systems, the relevant artifacts are already public: verification keys, on-chain verifier logic, proof formats, transcripts, and commitments. The risk is not that an attacker needs to secretly collect them.

The risk is that a vulnerable verifier remains live long enough that a future quantum-capable adversary can generate new fraudulent proofs that legacy infrastructure still accepts.

That is an integrity problem, not a confidentiality problem.

And for blockchains and rollups, the nuance matters: this does not mean "quantum magically rewrites finalized history." It means that if a protocol continues to accept proofs under broken verification semantics, fraudulent future transitions may still be accepted as canonical state.

The planning question is not exactly when a cryptographically relevant quantum computer appears. The question is:

How long would migration take if we had to do it seriously?

If migration is a multi-year exercise involving redesign, audits, governance, compatibility, dual-verifier windows, and ecosystem coordination, then some systems need to think about this much earlier than the phrase "post-quantum" usually suggests. Beginning too early costs engineering effort; beginning too late risks operating with broken verification semantics.

A layered view: L1-L4

The lens I'm currently using is a four-layer decomposition:

L1, Arithmetization / encoding: How computation becomes constraints or polynomials.
L2, Commitment + consistency: The layer that lets a verifier reason about large algebraic objects compactly (PCS, Merkle+FRI, IPA, etc.).
L3, Protocol logic: The argument / IOP structure that enforces identities and soundness amplification.
L4, Non-interactivity + extraction model: Fiat-Shamir, ROM vs QROM, and extractability assumptions.

This decomposition is an analytical tool, not a claim that every proof system cleanly factors into four independent modules. In practice, boundaries overlap; FRI is both a commitment mechanism (L2) and a core component of the protocol logic (L3). But the decomposition helps isolate where post-quantum risk enters and whether it can be isolated for replacement.

Why I think L2 is the hinge

A central claim in my current draft is that L2 is often the load-bearing post-quantum hinge.

If the commitment/consistency layer relies on Shor-vulnerable algebra, then in many cases the problem is not "raise parameters and move on." It is a structural or semi-structural migration problem.

That leads to a taxonomy I'm currently using:

Structural break: Quantum attacks break a load-bearing assumption, and the system cannot be repaired without changing its verification semantics. (Example: Groth16, where pairing-based verification is fused into the statement being proved.)
Modularly replaceable break: A critical component breaks, but the architecture supports principled migration by replacing it. (Example: a PLONK-style system with a separable PCS interface.)
Quantitative degradation: Security degrades under quantum attacks, but can plausibly be restored by increasing parameters rather than replacing the proof primitive. (Example: STARK-style systems, where hash parameter increases absorb Grover-type speedups.)

Migration feasibility: the second axis

The break classification alone is not enough.

A system can be theoretically replaceable and still fail in deployment.

So I separate the cryptographic effect from a second axis: migration feasibility.

Very roughly:

Upgrade-ready: The deployment has explicit mechanisms for verifier replacement and state continuity. (Starknet: upgradeable on-chain verifier through governance.)
Upgrade-constrained: Some upgrade path exists but faces governance, coordination, or engineering obstacles. (Zcash: consensus-layer changes require hard-fork-level coordination.)
Upgrade-blocked: No practical upgrade path exists without replacing the entire system. (Immutable on-chain verifier with no proxy or governance mechanism.)

The practical outcome is the combination of both axes. A modularly replaceable break is only good news if the verifier, governance path, state transition rules, and historical commitments actually allow migration. Otherwise, "replaceable" is just a theoretical comfort blanket.

The modularity test

To make this more concrete, the paper proposes a post-quantum modularity test: a three-condition checklist for whether a deployed proving stack can actually migrate.

Replaceable commitment interface: The commitment/consistency mechanism (PCS, Merkle+FRI, vector commitment, etc.) is modular and exposes a stable verification interface.
Replaceable Fiat-Shamir layer: Transcript hashing and challenge derivation can be reinstantiated without altering the statement being proved.
Upgradable verification logic: Deployed verifiers (smart contracts, embedded clients, audited libraries) can be versioned or replaced without invalidating long-lived commitments.

Failure of any condition constrains the feasibility of migration, potentially making a cryptographically replaceable break operationally irrecoverable.

What the case studies show

The paper applies the modularity test to three real deployments. Even in summary form, I think the results are instructive:

Zcash Sapling (Groth16): Fails condition (1) decisively. Groth16's verification semantics are intrinsically pairing equations; there is no separable PCS module to swap. Combined with upgrade-constrained governance (hard-fork-level coordination required), the classification is total collapse. Migration means deploying an entirely new proof system.

Zcash's move to Orchard (Halo 2) addressed the trusted-setup concern but is itself a structural break under this taxonomy, since IPA depends on discrete-log hardness. The community rationally prioritized eliminating its trusted setup (a concrete, present-day trust concern) over PQ resilience (a future threat). That means a subsequent PQ migration will require another full proof-system replacement. The Sapling Groth16 verifier remains part of the active consensus rules even after Orchard's deployment, so the Shor-vulnerable verification path is not merely historical.

ZKsync Era: The proving stack should be described more carefully than just "PLONK+KZG." Current documentation centers the Boojum proof system, and public descriptions characterize Boojum as a STARK-oriented proving pipeline with a SNARK final wrap for on-chain verification efficiency. For post-quantum analysis, the right question is not whether "ZKsync is PLONK+KZG," but which layer of the proving and verification pipeline is load-bearing for soundness and which parts are realistically swappable.

The inner proof system (FRI over Goldilocks) falls under quantitative degradation. The outer pairing-based compression wrapper is Shor-vulnerable and falls under modular collapse: it must be replaced, not re-parameterized. ZKsync's on-chain verifier sits behind an upgradeable proxy with multisig governance, which provides an explicit upgrade mechanism. The system passes all three conditions of the modularity test, with the Boojum upgrade providing empirical evidence for condition (1). The exact migration path depends on which layers currently carry Shor-vulnerable assumptions, but the architectural separability makes this a favorable case.

Starknet (STARK-based): Hash-based Merkle commitments and FRI proximity testing carry no obvious Shor-vulnerable assumptions at the proof-system core. Classification: quantitative degradation, upgrade-ready. PQ hardening means increasing hash output sizes for collision-critical paths and widening soundness margins to absorb QROM overhead. That said, it is not "done."

Even STARKs carry a QROM obligation

The common shorthand that "STARKs are post-quantum" is too simple.

Hash-based STARK systems avoid the obvious Shor-style structural break, but that does not make the QROM story trivial. There has been formal progress on Fiat-Shamir security for FRI and related SNARKs in the QROM, including work like Fractal, which presents transparent, post-quantum recursive proofs with QROM analysis. Mapping those results onto specific deployed stacks, concrete parameter choices, and full production pipelines still requires system-specific analysis.

The paper's ethSTARK parameter assessment illustrates the kind of analysis involved. ethSTARK targets 80-bit conjectured security in its standard configuration. With 256-bit hash outputs, Merkle collision security drops to ~85 bits under quantum assumptions (via the generic quantum collision bound), leaving only a 5-bit margin above the target. That margin erodes further when you account for QROM composition overhead across FRI's multi-round folding structure and the halving of grinding parameter contributions under Grover. The combination places effective PQ security well below the 80-bit classical target, though the exact magnitude depends on the QROM composition model applied to FRI's full pipeline, which remains an open question. "Quantitative degradation" still means there is real engineering work to do.

Recursion does not escape the problem

Recursion does not automatically remove Shor-vulnerable assumptions. In many common folding-based systems, including Nova-family constructions, the folding layer relies on Pedersen-style or other group-based commitments with discrete-log-style security. Recursion embeds the inner verifier as arithmetic constraints in the outer system, which means it can preserve rather than eliminate the relevant post-quantum dependency.

The structural break can propagate through the recursion chain: if the inner commitment scheme is Shor-vulnerable, then common recursive constructions that preserve that commitment layer inherit the same post-quantum dependency. By contrast, recursion for hash-based IOP systems stays within the "hash + field arithmetic" envelope, so the dominant effect remains quantitative.

What I am not claiming

This is not a complete set of conclusions.

I am not claiming:

that STARK-style systems have no remaining PQ work (they do: QROM verification and parameter tightening),
that all Fiat-Shamir deployments have satisfactory end-to-end QROM stories,
that every proof family cleanly fits my taxonomy,
that I already have a final migration playbook for deployed systems,
that the current draft of the paper is ready.

I am claiming something narrower:

The right way to reason about post-quantum ZK is more architectural and deployment-aware than most current discussions.

A note on methodology

The paper uses an explicit evidence-status convention to distinguish between claims that are directly supported by cited formal results ("Established"), engineering consequences that follow from cited results under stated assumptions ("Derived"), and deployment-oriented guidance that extrapolates beyond current end-to-end proofs ("Heuristic"). I mention this because the choice is deliberate: if the paper's thesis is that PQ readiness should be treated as an engineering problem, then the analysis should be transparent about which parts rest on proven ground and which parts are informed estimates.

Where I want to be challenged

I would welcome feedback on:

Where does this layered framing break down?
Is L2 really the right "hinge," or am I overemphasizing it?
Which deployed systems are the best counterexamples to this taxonomy?
Where is the line between modular replacement and full redesign blurrier than I describe?
Which systems have stronger or weaker QROM stories than I'm giving them credit for?
Do the case studies (Zcash, ZKsync, Starknet) validate the modularity test, or do they just happen to fit?
Which papers, blog posts, or implementation notes am I missing?
Which real deployments should be treated as additional case studies?

This is part of a larger, unfinished paper. Read it as an open research note, not a polished verdict. If the framing is wrong or missing something important, that is exactly what I want to hear.

Post-quantum ZK is about where vulnerable assumptions sit in the stack, and whether deployed systems can actually replace them.