Chapter 35: Case studies: Zcash, ZKsync, Starknet
Three deployed zero-knowledge systems, three different choices at L2 and L4, three different post-quantum postures. Zcash runs Groth16 (Sapling) and Halo 2 (Orchard). ZKsync Era runs Boojum, a FRI-based STARK compressed by a pairing-based outer wrapper before on-chain verification. Starknet runs a FRI-based STARK pipeline with no outer pairing wrapper. The deployed prover transitioned from ethSTARK / Stone to Stwo on mainnet in late 2025, announced on 3 November 2025 (StarkWare, 2025), with L2Beat’s milestone log dating the switch to 19 October (L2BEAT, 2026). The four-layer decomposition from Ch 31 and the two-axis grid of Figure 35.1 below turn those three choices into a decision the operator can read off a chart.
Three deployed systems, one taxonomy
Section titled “Three deployed systems, one taxonomy”The research kernel for Part VI poses one question for each deployed system (Renz, 2026). Which layer carries the quantum-vulnerable assumption, and does that layer have a separable replacement? Ch 31 formalized the answer as the four-layer decomposition and the two-axis L2-by-L4 classification of Table 31.2. Ch 32, Ch 33, and Ch 34 filled in the L2 primitives, the L4 QROM analysis, and the composed STARK pipeline. A deployed system’s posture is the dominant color of its (L2, L4) cell in the grid.
Zcash, ZKsync, and Starknet span three distinct cells in the grid. Sapling and Orchard both sit in the red L2 and red L4 cell, with the same verdict reached by two different cryptographic routes. ZKsync Era sits in a composite cell, with an amber inner (FRI) and a red outer (pairing wrapper) that occupy different L2 positions in the same deployed system. Starknet sits in the amber L2 and amber L4 cell across both its Stone root proof and its Stwo leaf proofs. This is the only configuration Part VI has analyzed where both L2 and L4 survive a Shor adversary with parameter bumps and QROM work.
Zcash Sapling at quantum landfall, revisited
Section titled “Zcash Sapling at quantum landfall, revisited”Ch 31 opened Part VI with Sapling as the canonical pairing-based system: Groth16 proofs over BLS12-381, one pairing equation at verification, polynomial-time break under Shor (Groth, 2016; Hopwood et al., 2026; Shor, 1994). The same motivating example anchors the case-study walkthrough. Sapling is the red entry point. The audit procedure that exposes Sapling’s posture applies unchanged to Orchard, to ZKsync Era, and to Starknet.
The procedure has five steps. Identify the L2 commitment and the hardness assumption that binds it. Identify the L4 non-interactivity method and its oracle model. Cite the deployed parameters where the project publishes them, flag them as unpublished where it does not. Place the system in the grid of Figure 35.1 by reading L2 color and L4 color. Compute the bit margin against a quantum adversary at the deployed parameters, or declare the margin zero where Shor applies.
The (L2 x L4) grid and bit-margin arithmetic
Section titled “The (L2 x L4) grid and bit-margin arithmetic”A deployed system fixes one L2 choice and one L4 choice. The two-axis grid of Figure 35.1 assigns a color to each cell of the Cartesian product, extending Ch 31’s Table 31.2 to the classes deployed in 2026. Three L2 classes and three L4 classes cover the systems deployed in 2026, and Table 35.2 gives the reason each carries the color it does. The BHT and CNPS bounds cited there assume QRACM (quantum random-access classical memory) and no QRACM respectively. Ch 32’s Merkle subsection sizes both.
Table 35.1. Symbols introduced or reused in Ch 35.
| Symbol | Meaning |
|---|---|
| (L2, L4) | Grid cell name per Figure 35.1 |
| k_sys | Target post-quantum bit margin for a deployed system |
| q_sys | Adversary quantum query budget at a system’s threat model |
| r_out | Fiat-Shamir rounds of an outer wrapper (ZKsync only) |
| n_hash | Hash output bit width, the BHT / CNPS input |
| r_FS | Fiat-Shamir rounds, configuration-dependent (reused from Ch 34, ethSTARK r_FS = 6 throughout this chapter) |
| mu | Independent FRI query paths, each picking one LDE position and following it through every fold layer (reused from Ch 34) |
| g | Grinding bits on the transcript (reused from Ch 34) |
| q | Adversary quantum query budget in QROM math (reused from Ch 33) |
Table 35.2. L2 and L4 classes and the cell each occupies, for systems deployed in 2026.
| Layer | Class | Cell | Why |
|---|---|---|---|
| L2 | pairing, discrete log | red | Shor solves discrete log in polynomial time (Shor, 1994) |
| L2 | Merkle plus FRI | amber | BHT 2^{n_hash/3}, CNPS 2^{2 n_hash/5} (Brassard et al., 1998; Chailloux et al., 2017) |
| L2 | lattice PCS | amber | conditional on QROM analysis of the construction |
| L4 | pairing CRS trust | red | the trapdoor falls with the curve |
| L4 | FS over a DL sigma | red | L2 falls to Shor before QROM matters |
| L4 | FS over a hash transcript | amber | asymptotic QROM bound proven for FRI and batched FRI (Block et al., 2023), deployment-parameter accounting pending |
Two CNFL specializations matter for Ch 35, and Section 6 of Renz (2026) names both for pairing-based zk-SNARK deployments. Forward forgery is the risk that an adversary holding a quantum computer generates proofs for false statements and a legacy Shor-vulnerable verifier still in service accepts them. Retroactive trust erosion is the risk that long-retained attestations lose evidentiary weight once forged proofs become indistinguishable from genuine ones under that same verifier. That source is explicit that the historical proofs are not themselves invalidated: what degrades is their probative value, not their soundness.
Placing the two on the four layers is this book’s own analysis rather than anything Renz (2026) derives. Forward forgery enters at L4-via-CRS, because in the Ch 31 decomposition Groth16’s L4 is the CRS and the recovered trapdoor is what forges a proof. Trust erosion is read off L2, because the pairing equation every historical proof was checked against is the L2 mechanism Shor breaks. Renz’s own layer scheme differs on the first of these, reserving L4 for Fiat-Shamir and the oracle model and placing CRS-trapdoor forgery at L2. Ch 31 says the decomposition used here is Encryptorium’s analytical framing rather than a standard taxonomy, and this is one of the places the two part company.
FRI-based STARKs have no L2 group-DLP route, so they avoid the Shor-on-curve forgery path entirely. The long-term risk instead splits across two amber surfaces. L2 hash and Merkle binding degrades quantitatively under BHT and CNPS collision finding, so the effective hash margin shrinks against a quantum adversary unless n_hash is widened (Brassard et al., 1998; Chailloux et al., 2017). L4 Fiat-Shamir over the FRI transcript carries the deployment-parameter QROM caveat the chapter develops below per Ch 33’s three-tier classification and Ch 34 Section 5.6 (Block et al., 2023). The algebraic proximity test itself is the information-theoretic component; the operator-facing risk lives at L2 (hash) and L4 (Fiat-Shamir), not at the AIR or proximity layer.
Block 1 shows the red-classification arithmetic: a pairing-based system’s bit margin is zero in the CRQC adversary model.
# Block 1: red-classification for a pairing-based L2. The bit margin# collapses to zero once Shor recovers the discrete logarithm on the# pairing-friendly curve. Source: Shor 1994.def bit_margin_pairing(field_bit: int) -> int: if field_bit <= 0: raise ValueError("field_bit must be positive") # Shor runs in polynomial time in field_bit on a quantum computer, # so the post-quantum bit margin at L2 is zero regardless of the # field width chosen. return 0
print(bit_margin_pairing(field_bit=381))# ==> 0Every Python block this chapter prints is also a standalone file in the companion repository, under chapter-code/ch35/, one file per block. Appendix C covers the clone and the environment they run on.
The amber classification at L2 is not a single number. It depends on hash output width, on the FRI proximity gap, on query count, and on grinding bits. The per-system arithmetic lives in Blocks 3, 4 and 5 below.
Three case studies
Section titled “Three case studies”Zcash: Sapling and Orchard side by side
Section titled “Zcash: Sapling and Orchard side by side”Specification and context. Zcash is a privacy-preserving cryptocurrency. Sapling and Orchard are two shielded pools that coexist in the active consensus rules of the Zcash network as of early 2026: ZIP 252 deploys the NU5 network upgrade that activated Orchard on mainnet at block height 1687104 (Hopwood et al., 2026; Hopwood & teor, 2021). A shielded transaction carries a proof that the sender knows a valid note, the nullifier derivation is correct, and the balance equation holds. The verifier accepts the proof if and only if the statement passes. Sapling verifies Groth16 proofs over BLS12-381 (Groth, 2016; Hopwood et al., 2026). Orchard verifies Halo 2 proofs over the Pallas and Vesta curve cycle (Bowe et al., 2019; Hopwood et al., 2022).
L1 arithmetization. Sapling uses R1CS, Orchard uses the PLONKish arithmetization of Halo 2.
L2 commitment. Sapling binds the proof through the Groth16 pairing equation: three group elements, one pairing equation, knowledge soundness is proved in the generic bilinear group model rather than reduced to a standard assumption (Groth, 2016, sec. 3.2). A discrete-logarithm solver on the pairing curve recovers the setup trapdoor, which the paper’s own simulator turns into proofs of any statement. Orchard binds the proof through the inner-product argument (IPA) of Halo 2 (Zcash, 2026), run over the Vesta curve of the Pallas-Vesta cycle (Hopwood et al., 2026, sec. 5.4.9.6), whose soundness reduces to the discrete-logarithm problem on that curve by the argument Halo introduced (Bowe et al., 2019). Both L2 constructions fall to Shor in polynomial time on a sufficiently large quantum computer (Shor, 1994).
L3 protocol. Groth16 is an algebraic NIZK argument with no Fiat-Shamir step. Halo 2 is an interactive IPA sigma compiled non-interactively via Fiat-Shamir.
L4 non-interactivity. Sapling’s non-interactivity comes from the Groth16 common reference string (CRS). The CRS was generated by the dedicated two-phase Sapling MPC: the universal Powers of Tau followed by Sapling-specific circuit parameter generation, run in 2017—2018 (Bowe, 2018). That ceremony is separate from the 2016 Sprout ceremony, which produced the original Zcash circuit parameters. The trust posture is CRS-based; no Fiat-Shamir oracle is invoked at verification (Groth, 2016). Orchard’s non-interactivity comes from Fiat-Shamir over the IPA transcript. Halo 2 removes the Sapling-style trusted setup but still runs Fiat-Shamir over a group-based L2. The L4 posture is therefore dominated by the L2 red cell: a Shor adversary forges the IPA opening before the oracle-model analysis matters.
PQ posture. Sapling lands in the (L2 red, L4 red) cell. Orchard lands in the same cell by a different route. Both inherit the zero bit margin from Block 1 against a CRQC adversary under the discrete-log and pairing assumptions. Block 2 applies the red classification to the Sapling parameters. The Orchard bit margin follows by the same argument on Pallas and Vesta.
# Block 2: Sapling Groth16 over BLS12-381. Block 1's result applied to# the specific Zcash deployment. Source: Hopwood, Bowe, Hornby, Wilcox# (2025), Groth (2016).def shor_pairing_margin(curve_bits: int) -> int: if curve_bits <= 0: raise ValueError("curve_bits must be positive") # The L2 pairing equation reduces to discrete log on BLS12-381. # Shor breaks the discrete log in polynomial time, so the concrete # bit margin is zero regardless of the curve's classical bit width. return 0
print(shor_pairing_margin(curve_bits=381))# ==> 0CNFL routing. Sapling’s CNFL surface splits into a soundness route and a separate privacy route, and the two must be analyzed independently: proof-transcript privacy and note-encryption privacy are distinct attack surfaces. The soundness route is forward forgery via the CRS. A future quantum adversary recovers the CRS trapdoor (broken by Shor on BLS12-381) and forges new Sapling proofs against the legacy verifier (Renz, 2026). Trust in the historical proofs erodes alongside it. Once the trapdoor is recovered, a proof the adversary forges for a false statement is indistinguishable from an honest one under the same legacy verifier, so an old proof stops being evidence that its statement was true. The proof is not retroactively invalidated and the statement it attested to does not become false. What is lost is the verifier’s ability to tell the two apart (Renz, 2026).
The privacy route runs through Sapling note encryption, which uses half-ephemeral Diffie-Hellman key agreement over the Jubjub curve. The specification sets epk = KA.DerivePublic(esk, g_d) and sharedSecret = KA.Agree(esk, pk_d), where the diversified base is g_d = DiversifyHash(d) and the diversified transmission key is pk_d (Hopwood et al., 2026). Together (d, pk_d) are the recipient’s payment address, and that detail decides the whole route. esk is the discrete logarithm of epk to the base g_d, not to a fixed generator, so an adversary holding only the output description cannot even pose the Shor instance: d travels inside the encrypted note plaintext. The address supplies g_d and pk_d at once, and from there Shor recovers esk, the shared secret follows, and the note plaintext (amount, diversifier, commitment randomness) decrypts retroactively.
Because Sapling payment addresses are routinely published in order to receive funds, that precondition is usually satisfied in practice. It is still a precondition, and it is not visible on chain: an observer holding the block chain alone does not have the attack. The outgoing ciphertext is a second way in, since it carries esk and pk_d under a key derived from the sender’s outgoing viewing key, which makes a leaked ovk a classical route to the same plaintext. The Groth16 proof transcript is unaffected on either path. It is statistically zero-knowledge, so no witness information is derivable from the proof even by an unbounded adversary. The proof layer is therefore not the privacy liability under quantum attack; the note-encryption layer is, conditional on recipient-side material.
Orchard routes CNFL through the IPA verifier by the same forward-forgery argument: Halo 2’s IPA commitment reduces to discrete log on Vesta (Bowe et al., 2019; Zcash, 2026), and Shor recovers the same forgery capability. Its privacy route has the same shape as Sapling’s, a quantum-vulnerable elliptic-curve key-agreement layer at the note-encryption level with the same address-side precondition, separate from the proof layer.
Transition path. A PQ-resilient Zcash shielded pool requires a successor proof system whose L2 is not discrete-log-based, paired with a successor note-encryption scheme whose key agreement is not elliptic-curve Diffie-Hellman. Two candidate proof-system families are FRI-based STARKs (hash-only L2, carrying the QROM-pending Fiat-Shamir caveat Part VI flags throughout) and lattice-based SNARKs (Module-LWE at L2, with production proof-size still closing on the pairing-based baseline). Migration under either family entails a coordinated network upgrade (hard fork) to deploy the successor verifier, a retirement plan for the Sapling and Orchard verifiers still in consensus rules, and a policy for historical note commitments. The Orchard upgrade did not close the PQ gap: Halo 2 replaced Groth16’s trusted setup but remained Shor-vulnerable through IPA (Bowe et al., 2019; Zcash, 2026).
The Tachyon roadmap, read 15 September 2026 and carrying no publication date, is a proposed Zcash upgrade with three tracks (Electric Coin Company, 2026). Ragu is a Rust proof-carrying-data library that follows the original Halo construction. A new shielded pool, independent of Orchard, is built on it. A payment-protocol track uses private information retrieval and post-quantum key exchange for post-quantum privacy of payment delivery, and the post-quantum goal belongs to that track. Ragu’s Halo lineage means the proof layer stays on a discrete-log commitment, so the roadmap proposes no post-quantum replacement for proof soundness. Tachyon is not yet activated on mainnet: the roadmap says activation follows community consensus and Zcash’s ZIP requirements. This chapter therefore treats Tachyon as proposed, not deployed.
ZKsync Era: composite architecture
Section titled “ZKsync Era: composite architecture”Specification and context. ZKsync Era is a zero-knowledge rollup on Ethereum. The prover produces a proof that a batch of L2 transactions is valid, the sequencer posts the proof on L1, and the on-chain verifier contract accepts the batch. The Boojum proof system, announced in July 2023 and first run in mainnet shadow mode beside the existing prover (ZKsync, 2023), changed the proving architecture substantially. L2Beat’s Era page documents it as the deployed proof system, read 15 September 2026 (L2BEAT, 2026b). Prior to Boojum the inner system was a pairing-based PLONK-style SNARK. Post-Boojum it is FRI-based over the Goldilocks field, p = 2^{64} - 2^{32} + 1, keeping the PLONKish arithmetization: the announcement says the upgraded system “continues to employ a PLONK-style arithmetization” (ZKsync, 2023).
The same announcement documents that the final on-chain proof is not the raw inner STARK. It states that in the final step “we will wrap the STARK proofs with a non-transparent pairing-based SNARK, essentially a slightly upgraded version of the current proof system, and it will be this SNARK that is verified on Ethereum” (ZKsync, 2023). The on-chain verifier therefore reads the outer wrapper proof, not the raw STARK. The concrete wrapper instance has varied across verifier versions: the V27 EVM-emulation upgrade (ZIP-9) added Fflonk verifier support to the L1 verifier contract, which now accepts both PLONK and Fflonk proofs (ZKsync Association, 2025). This chapter therefore treats the outer wrapper generically as pairing-based rather than tying the analysis to one specific SNARK construction.
L1 arithmetization. Boojum’s inner system uses a PLONKish arithmetization with lookup gates. The arithmetization class is the same family as Plonky2 (Polygon Zero Team, 2022). The outer wrapper operates on the inner proof itself and therefore inherits the arithmetization of whatever pairing-based SNARK it instantiates.
L2 commitment. The inner system binds through Merkle plus FRI over the Goldilocks field. The outer wrapper binds through a pairing-based commitment (the Groth16 verification equation or a similar pairing-based SNARK, depending on the deployed wrapper). Inner L2 is hash-based and Shor-resistant; outer L2 is Shor-broken by the same argument as Sapling.
L3 protocol. Inner: interactive oracle proof (IOP) with AIR constraints over the PLONKish skeleton. Outer: an algebraic NIZK argument whose details are configuration-dependent.
L4 non-interactivity. Inner: Fiat-Shamir over the Plonkish arithmetization plus FRI transcript, Tier 3 per the classification in Ch 33’s three-tier section, with an asymptotic QROM Fiat-Shamir bound published via the BCS lift and the deployment-parameter accounting still pending (Block et al., 2023).
Outer: pairing-based SRS / CRS for the wrapper SNARK, with the L4 trust posture depending on the concrete wrapper instance. A Groth16-style wrapper is CRS-native and invokes no Fiat-Shamir step at the wrapper layer. The PLONK and Fflonk wrappers used in ZKsync Era’s L1 verifier do invoke Fiat-Shamir: PLONK shipped in early deployment, Fflonk was added in the V27 EVM-emulation upgrade (ZKsync Association, 2025). Both are made non-interactive through Fiat-Shamir over a KZG / pairing-based transcript, with verifier challenges derived by hashing the transcript rather than sampled by an honest verifier. Either way, the wrapper’s L4 posture remains red. The wrapper’s algebraic-commitment / SRS layer falls to Shor before any QROM margin can rescue it. The Fiat-Shamir step in the Plonk family is a transcript-hashing detail downstream of the Shor-broken pairing.
PQ posture. The inner system lands at amber L2 and amber L4. The outer wrapper lands at red L2 and red L4. The composite deployed posture is dominated by the weakest link: red, because the outer wrapper verifies first against the on-chain verifier contract and any forger who breaks the outer wrapper produces an accepting transaction without ever touching the inner. Block 3 applies the Ch 34 composed-soundness formula to the inner Boojum pipeline.
# Block 3: Boojum inner FRI-STARK classical-ROM margin via the Ch 34# Section 5.5 composed-soundness formula. The proximity threshold# delta_0 = 1 - sqrt(rho) is the Johnson / Guruswami-Sudan# list-decoding radius. BCIKS Theorem 1.2 proves the proximity gap# strictly below it, and the linear bad-beta term below is the Ch 34# Section 5.5 model's rather than the theorem's error term, so the# figure printed is the model's output at that radius and not a# proven floor; Ch 34 Section 5.1 sets out the three radii. A# pipeline that sets delta_0 above it is in the conjectured regime,# which is the discount Ch 34's closing aside records as having# fallen in late 2025. The DFMS20 parameter-bump check from Ch 33's# multi-round subsection then asks whether the deployed# challenge-space width meets the model's per-round requirement# at a target PQ margin. Exact Boojum# parameters are not published at the granularity below; values are# illustrative of a Goldilocks extension-field configuration.# Source: Ch 34 Sections 5.1 and 5.5; Ch 33 'Multi-round# Fiat-Shamir'; Ben-Sasson, Carmon, Ishai, Kopparty, Saraf (2020,# proximity gap below the Johnson bound); ZKsync (2023); Block et al.# (2023, classical NI/ROM bound; the same paper's QROM# bound is one factor of q heavier).import math
def stark_classical_margin(field_bits: int, L: int, N: int, mu: int, r_FRI: int, grinding: int) -> float: if min(field_bits, L, N, mu, r_FRI) <= 0: raise ValueError("field_bits, L, N, mu, r_FRI must be positive") if grinding < 0: raise ValueError("grinding must be non-negative") if L >= N: raise ValueError("L must be less than N") rho = L / N # Johnson / Guruswami-Sudan radius. BCIKS Theorem 1.2 proves the # gap strictly below it; the model reads its terms here. delta_0 = 1.0 - math.sqrt(rho) log_bad_beta = math.log2(r_FRI * (N + 1)) - field_bits log_per_round = mu * math.log2(1.0 - delta_0) log_consistency = mu * math.log2((L - 1) / N) # Ch 34 Section 5.5: grinding attenuates the query-miss terms only. # A forger who wins on a bad fold challenge never re-grinds. composed_prob = (2.0 ** log_bad_beta + 2.0 ** -grinding * (2.0 ** log_per_round + 2.0 ** log_consistency)) return round(-math.log2(composed_prob), 1)
def dfms20_exact_cbits(k_target: int, q_bits: int, r_FS: int) -> int: if k_target <= 0 or r_FS <= 0 or q_bits < 0: raise ValueError("k_target, r_FS must be positive; q_bits non-negative") # Exact width under this chapter's DFMS20-shaped model, from Ch 33's # quantum-oracle-cost section: c_bits >= 2 log2(2 q + 1) + k / r_FS. # Exact is arithmetic about the model and not a certified QROM bound: # the model drops the corollary's additive challenge-space term. # That log is strictly greater than q_bits + 1 by a vanishing amount, # so a bound whose float value lands on an integer sits just above # it and still needs the next width up; at these q_bits the excess # is below float resolution, so the integer case is tested outright. # The approximation 2 q_bits + ceil(k / r_FS) drops the # log2(2 q + 1) correction and lands about 2 bits short. exact = 2.0 * math.log2(2 * (2 ** q_bits) + 1) + k_target / r_FS width = math.ceil(exact) return width + 1 if width == exact else width
# Illustrative Boojum inner.k_classical_boojum = stark_classical_margin(field_bits=128, L=2 ** 16, N=2 ** 20, mu=40, r_FRI=16, grinding=20)c_bits_required = dfms20_exact_cbits(k_target=128, q_bits=80, r_FS=6)print(k_classical_boojum, c_bits_required)# ==> 99.9 184The model’s classical-ROM figure at this illustrative configuration is 99.9 bits, read at the Johnson radius per the note above. Grinding buys almost all of its 20 bits here because the FRI per-round term still dominates. Exercise 2 walks a configuration past the crossover, where it does not.
The DFMS20 parameter-bump rule requires 184 bits per round to sustain a 128-bit QROM-target margin against a q = 2^{80} adversary. The rule is the protocol-agnostic model Ch 34 Section 5.3 uses rather than the FRI-specific bound, and 184 is that model’s threshold. The model is neither tight nor conservative: it keeps the multiplicative loss of DFMS20’s corollary, which exceeds the dedicated FRI loss by powers of q, and drops the corollary’s additive challenge-space term, so its widths are outputs of a stipulated rule rather than certified minima (Ch 33). No deployment-parameter composition of the FRI-specific bound has been published to replace it. Read against the model, a deployment whose per-round challenge-space width is narrower than 184 bits is not certified at k = 128. ZKsync does not publish the exact Boojum parameters at the granularity above. The values are flagged as illustrative, and the 184-bit requirement carries the same model caveat.
CNFL routing. The outer wrapper carries the dominant CNFL route per the Boojum announcement (ZKsync, 2023). A future quantum adversary recovers the wrapper’s pairing-based trapdoor (Shor), forges an accepting outer proof against the legacy on-chain verifier, and compels acceptance of any inner statement the forger chooses. The inner system carries two secondary CNFL routes. The L2 hash and Merkle binding degrades quantitatively: BHT and CNPS reduce the effective hash-collision margin against a quantum adversary unless n_hash is widened (Brassard et al., 1998; Chailloux et al., 2017). The L4 Fiat-Shamir parameter point is an assurance gap rather than a known attack. Block et al. prove Fiat-Shamir security for FRI and batched FRI in the QROM, and what those results give are upper bounds on soundness error (Corollaries 4.3 and 4.4 in Block et al., 2023). An upper bound on soundness error is not an upper bound on attack cost. A bound too loose to certify the target margin exhibits no forgery and says nothing about what an adversary can achieve. Applying the theorem to this deployment needs the actual protocol parameters and the composition terms, and if the deployed challenge width does not absorb the DFMS20 loss at the target margin, the proof establishes less than that margin for a legacy inner verifier still in service (Renz, 2026). All three surfaces remain live until both layers are replaced or reparameterized.
Transition path. The wrapper replacement is primary because the outer pairing-based SNARK falls to Shor in polynomial time and the L1 verifier reads the outer proof first (ZKsync, 2023). Candidate PQ-compatible compressors include recursive STARK folding (keeping the inner-STARK structure all the way to the on-chain verifier, at the cost of a larger on-chain proof and more verification gas) and transparent recursive SNARKs such as the Fractal construction (Chiesa et al., 2020).
In September 2024, ZKsync transferred upgrade authority from a centralized entity to its onchain governance system, ZK Nation (ZKsync Association, 2024). Three independent bodies (the Token Assembly of token holders and delegates, the Security Council of technical reviewers, and the Guardians for credo alignment) now hold the upgrade keys, and no single party can unilaterally upgrade the protocol. This is the governance path that would execute a wrapper replacement (the same path that landed the V27 Fflonk addition (ZKsync Association, 2025)). Inner parameter bumps (grinding bits, hash output width, FRI queries, challenge-space width) are secondary and reparameterize the existing pipeline without structural redesign.
Inner parameter bumps ship through the same governance mechanism (ZKsync Association, 2024, 2025).
Starknet: Stone at the root, Stwo at the leaves
Section titled “Starknet: Stone at the root, Stwo at the leaves”Specification and context. Starknet is a zero-knowledge rollup whose prover stack transitioned from ethSTARK / Stone to Stwo on mainnet in late 2025 (Ben-Sasson, 2021; StarkWare, 2025). The on-chain verifier accepts a STARK proof that a batch of L2 transactions is valid. Unlike ZKsync Era, the deployed Starknet path composes no outer pairing-based wrapper: the on-chain verifier reads a FRI-based STARK proof directly. That proof is Stone’s, over the root of SHARP’s recursion tree. Stwo’s proofs of the leaves are verified in-circuit by a Cairo verifier program below it (StarkWare, 2025a).
StarkWare’s announcement fixes the scope of the switch: Stwo is live on Starknet mainnet, replacing Stone as the network’s prover, and every Starknet block is now proven by Stwo (StarkWare, 2025b). Starknet’s documentation of SHARP (SHARed Prover), the aggregator that carries those proofs to Ethereum, fixes where Stone remains. From Starknet version 0.14.0 Stwo generates every proof SHARP aggregates except the roots of its recursion trees, which Stone still proves so that SHARP’s on-chain verifiers did not have to change. Each Stwo proof is verified off-chain by a verifier program written in Cairo, the verifications are aggregated recursively, and the Stone proof of the root is what the Solidity verifier reads (StarkWare, 2025a). That is the last publicly documented state of the path, not a claim about the contract deployed today: StarkWare wrote on 31 March 2026 that SHARP “will soon incorporate circuit-based recursive proving, and the L1 verifier (solidity) will be changed to verify a S-two circuit proof” (StarkWare, 2026), and on 7 September 2026 no public record that the change had shipped was found. Stone had also secured StarkEx for the preceding six years. This chapter makes no claim about StarkEx.
The case study splits into two parameter points, both live and composed on the deployed path rather than one retired and one current. The Stone root path is Stone’s Cairo verifier, which runs FRI over the 252-bit Cairo field itself and draws every challenge from it (StarkWare, 2023). It proves the recursion root, the proof the L1 contract enforces. The soundness arithmetic developed in Ch 34 applies directly. Block 4 reads that arithmetic at the ethSTARK Documentation v1.2 reference configuration, a small prime base field with FRI challenges drawn from an extension field, because that is the configuration the documentation prices. It is not Stone’s shipped field. The Stwo leaf path is a Circle STARK over the Mersenne-31 field p = 2^{31} - 1 (M31), a construction that replaces the smooth-order multiplicative subgroup of a classical STARK with the circle curve x^2 + y^2 = 1 (Haböck et al., 2024). It proves the leaves, and the recursive Cairo verifier is what enforces its parameters. Its published defaults target 96 bits of conjectured soundness (StarkWare, 2026a). The L2 hash-binding and L4 Fiat-Shamir analysis carries across both parameter points at the family level.
L1 arithmetization. Algebraic Intermediate Representation (AIR), the same class introduced in Ch 34’s section on AIR, LDE, and the Reed-Solomon lift (Ben-Sasson et al., 2018). Stwo uses a Circle STARK arithmetization specialized to the Mersenne-31 field (StarkWare, 2025b); the Stone root path uses the AIR-over-a-prime-field arithmetization Ch 34 covers in detail, with the 252-bit Cairo field as that prime field.
L2 commitment. Merkle plus FRI at both parameter points. The Stone root path commits and tests proximity over the Cairo field, the 252-bit prime P = 2^{251} + 17 \cdot 2^{192} + 1. Stone’s shipped Cairo parameters name that field and set use_extension_field to false, and its channel returns each challenge as an element of it, so the challenge entropy is log_2 P = 251.0 bits (StarkWare, 2023). The ethSTARK reference configuration that Block 4 models is a different one: a base field of approximately 61 bits (p = 2^{61} + 20 \cdot 2^{32} + 1) with FRI challenges drawn from an extension field per ethSTARK Documentation v1.2 Section 5.10 (Ben-Sasson, 2021; Ben-Sasson et al., 2018a). The Stwo leaf path uses FRI over the Mersenne-31 field as the base field and draws its Fiat-Shamir challenges from QM31, the degree-four extension the Stwo README names as “the secure field used for Fiat-Shamir challenges” (StarkWare, 2025b, 2026a). That challenge space is 4 log_2(2^{31} - 1) = 124.0 bits wide, a figure the DFMS20 reading below comes back to.
L3 protocol. Interactive oracle proof with AIR constraints, composition polynomial pipeline, and FRI proximity at the last stage. Starknet’s deployed pipeline uses a composition polynomial. The Ch 34 toy pipeline drops this step, so the per-system soundness arithmetic in Block 4 tracks the composition polynomial as the object under FRI proximity, not each AIR column independently.
L4 non-interactivity. Fiat-Shamir over the AIR plus FRI transcript, Tier 3 per Ch 33’s three-tier classification, with an asymptotic QROM Fiat-Shamir bound published via the BCS lift (Block et al., 2023). End-to-end QROM analysis at deployment parameters remains pending per Ch 34 Section 5.6 for both parameter points.
PQ posture. Amber L2, amber L4 at both parameter points. Block 4 is an illustrative ethSTARK-style parameter calculation that applies the Ch 34 Section 5.5 formula to a reference-like configuration. It then checks the DFMS20 parameter-bump rule against the recommended ethSTARK challenge field (Ch 34 Section 5.7 makes the same check with the same arithmetic). The block is illustrative, not a verified deployed Starknet parameter table. The ethSTARK Documentation v1.2 Section 7.1.1 gives its own concrete settings: s = 79 FRI queries for the 80-bit configuration, s = 105 for 100-bit, and s = 141 for 128-bit with 4 grinding bits on the earlier rounds and 20 on the final query round. Its Section 5.10.2 is a different analysis, provable IOP knowledge soundness, with 79 / 104 / 140 and the degree-4 extension for 128 bits. Those settings should be cited separately from this model calculation.
# Block 4: illustrative ethSTARK-style classical-ROM margin at a# reference-like parameter point (not a verified deployed Starknet# parameter table), via the Ch 34 Section 5.5 composed-soundness# formula at the Johnson-bound proximity radius (same regime note as# Block 3: the model's output at that radius, not a proven floor).# The DFMS20 parameter-bump check compares# the F_{p^4} challenge-field width (~244 bits, recommended in# ethSTARK Documentation v1.2 Section 5.10.2 for provable 128-bit# IOP knowledge soundness) against the required challenge width at# the 128-bit PQ target Ch 34 Section 5.7 uses as the headline# production example. Source: Ch 34 Sections 5.1, 5.5 and 5.7;# Ch 33 'Multi-round Fiat-Shamir' and 'Cost of the quantum oracle';# Ben-Sasson, Bentov, Horesh, Riabzev (2018); Ben-Sasson (2021,# ethSTARK documentation, §5.10.2); Block et al. (2023,# classical NI/ROM bound; the same paper's QROM bound is# one factor of q heavier).import math
def stark_classical_margin(field_bits: int, L: int, N: int, mu: int, r_FRI: int, grinding: int) -> float: if min(field_bits, L, N, mu, r_FRI) <= 0: raise ValueError("field_bits, L, N, mu, r_FRI must be positive") if grinding < 0: raise ValueError("grinding must be non-negative") if L >= N: raise ValueError("L must be less than N") rho = L / N delta_0 = 1.0 - math.sqrt(rho) log_bad_beta = math.log2(r_FRI * (N + 1)) - field_bits log_per_round = mu * math.log2(1.0 - delta_0) log_consistency = mu * math.log2((L - 1) / N) # Ch 34 Section 5.5: grinding attenuates the query-miss terms only. # A forger who wins on a bad fold challenge never re-grinds. composed_prob = (2.0 ** log_bad_beta + 2.0 ** -grinding * (2.0 ** log_per_round + 2.0 ** log_consistency)) return round(-math.log2(composed_prob), 1)
def dfms20_exact_cbits(k_target: int, q_bits: int, r_FS: int) -> int: if k_target <= 0 or r_FS <= 0 or q_bits < 0: raise ValueError("k_target, r_FS must be positive; q_bits non-negative") # Ch 33's exact form; a value that lands on an integer rounds up. exact = 2.0 * math.log2(2 * (2 ** q_bits) + 1) + k_target / r_FS width = math.ceil(exact) return width + 1 if width == exact else width
# Illustrative ethSTARK-style reference point at blowup 16, mu = 48,# r_FRI = 20, grinding = 20. Not a verified deployed Starknet# parameter table; see ethSTARK Documentation v1.2 Section 7.1.1 for# its concrete settings (s = 79 / 105 / 141 queries at 80 / 100 / 128# bits, with grinding; Section 6 is the round-by-round soundness proof# and prints none of them). The challenge-field# width 244 corresponds to F_{p^4} per ethSTARK Documentation v1.2# Section 5.10.2 for provable 128-bit IOP knowledge soundness; the# conjectured-soundness path uses F_{p^3} at 183 bits. The DFMS20# bump target is k = 128 to match Ch 34 Section 5.7's headline# production example.k_classical_ethstark = stark_classical_margin(field_bits=244, L=2 ** 20, N=2 ** 24, mu=48, r_FRI=20, grinding=20)c_bits_required_k128 = dfms20_exact_cbits(k_target=128, q_bits=80, r_FS=6)c_bits_deployed = 244print(k_classical_ethstark, c_bits_required_k128, c_bits_deployed)# ==> 116.0 184 244The model’s classical-ROM figure at the illustrative configuration is 116 bits, again read at the Johnson radius. This models a reference-like ethSTARK configuration; it is not a verified deployed Starknet parameter table. The ethSTARK documentation specifies 80, 100 and 128 bit settings at the same configuration class, priced in the random-oracle model with grinding counted (Ben-Sasson, 2021, sec. 5.10), and its Section 7.1.1 gives the provable-soundness settings: s = 79 query paths for 80-bit security, s = 105 for 100-bit, and s = 141 with extra grinding for 128-bit. Those settings claim less margin from more query paths than the model above does, which measures what the model omits rather than any disagreement about the proximity radius. Read 116 as this three-term model’s output at mu = 48, not as a Starknet parameter claim.
The r_FS = 6 value counts the protocol’s distinct public-coin rounds rather than the r_FRI = 20 FRI fold rounds. Ch 34 Section 5.3 documents the configuration-dependent definition and the partition that goes with it. The ethSTARK IOP has r_eth = 3 + |fri_step_list| rounds: three fixed protocol steps (trace oracle, constraint randomness, DEEP query) plus one challenge per FRI commit-phase layer. Six is therefore three non-FRI stages and a three-layer step list. The toy collapses to r_FRI + 1 = 4 instead, one trace commitment plus one challenge per fold.
The DFMS20 parameter-bump check at k = 128, q = 2^{80}, r_FS = 6 requires 184 bits per round, the threshold of a model that is neither tight nor conservative (Ch 33): the check applies the protocol-agnostic DFMS20 rule rather than the FRI-specific bound. Ch 33’s subsection on the DFMS20 hypotheses explains why FRI is sized under a dedicated bound, and Ch 34 Section 5.6 records that the deployment-parameter composition of that bound is what remains pending. Against the model, the F_{p^4} 244-bit challenge field clears the requirement by 60 bits, and the F_{p^3} 183-bit field used in the conjectured-soundness configuration falls one bit short. A one-bit shortfall against a stipulated model is no verdict either way. The e = 4 lift that ethSTARK Documentation v1.2 §5.10.2 recommends for provable 128-bit IOP knowledge soundness, which Ch 34 Section 5.7 works through, rests on that document’s own provable analysis rather than on this model. Stone’s shipped Cairo field, at log_2 P = 251.0 bits of challenge entropy, sits 67 bits above the same threshold (Ch 34 Section 5.7). Stwo’s QM31 challenge field, at 124.0 bits, sits 60 bits below it. That is a proof gap and not a break, read the way Ch 34 Section 5.7 reads every number of this kind: a bound too loose to certify k = 128 at a parameter point means the proof does not establish 128 bits there, the model certifies nothing by itself, no deployment-parameter composition of the FRI-specific bound has been published to replace it, and Stwo’s own published target is 96 bits of conjectured soundness rather than the 128 the model is sized for (StarkWare, 2026b). What the arithmetic says is that a QROM certification of Stwo at k = 128 cannot come from this model. What it does not say is that anyone forges a Stwo proof.
No QROM-proven soundness number at the deployed parameters exists in the published literature for either parameter point, though the asymptotic QROM bound for FRI itself does (Block et al., 2023). The 116-bit figure is the three-term model’s output with grinding, not a proven floor, and the 184-bit and 60-bit figures inherit the DFMS20-model caveat.
Stwo is the one system in this chapter whose parameters are published rather than illustrative. The stwo-cairo README gives the defaults outright, pow_bits = 26, log_blowup_factor = 1 and n_queries = 70, targeting 96 bits of conjectured soundness (StarkWare, 2026b). Read on 18 September 2026, that README and Stwo’s own both open with a notice that development moved to StarkWare’s proving repository at the end of July 2026, so the numbers are the last ones this repository published rather than the active project’s. The word conjectured is carrying the sentence, and Block 5 shows where.
# Block 5: Stwo's published defaults, read at all three decoding# radii. A blowup of 2^log_blowup gives rate rho; each of the# n_queries FRI query paths misses a delta_0-far codeword with# probability at most (1 - delta_0), and grinding adds pow_bits on# top. Source: starkware-libs/stwo-cairo README (the defaults);# Ch 34 Section 5.1 (the three radii); Ben-Sasson, Carmon, Ishai,# Kopparty, Saraf (2020); Crites and Stewart (2025).import math
def query_miss_bits(n_queries: int, pow_bits: int, log_blowup: int, regime: str) -> float: if min(n_queries, log_blowup) <= 0 or pow_bits < 0: raise ValueError("n_queries, log_blowup positive; pow_bits" " non-negative") rho = 2.0 ** (-log_blowup) if regime == "capacity": delta_0 = 1.0 - rho elif regime == "johnson": delta_0 = 1.0 - math.sqrt(rho) elif regime == "unique": delta_0 = (1.0 - rho) / 2.0 else: raise ValueError(f"unknown regime: {regime!r}") return round(-n_queries * math.log2(1.0 - delta_0) + pow_bits, 1)
stwo = {"n_queries": 70, "pow_bits": 26, "log_blowup": 1}print(query_miss_bits(**stwo, regime="capacity"), query_miss_bits(**stwo, regime="johnson"), query_miss_bits(**stwo, regime="unique"))# ==> 96.0 61.0 55.1The 96 is exact, and it is exact for a reason. At the capacity bound 1 - rho = 1/2 each query path contributes precisely one bit, so 70 paths plus 26 grinding bits is 96 with nothing rounded. Move to the Johnson bound, the radius BCIKS’s proven interval runs up to without including, and the same published parameters give 61. That 35-bit difference is the discount, and Crites and Stewart removed the conjecture it rested on in late 2025 (Crites & Stewart, 2025).
Two things that arithmetic does not say. It is not a claim that Stwo has 61 bits of security: this is the query-miss term alone, and StarkWare’s own analysis prices terms the model above omits. It is also not a charge of concealment, because the README prints the word conjectured in the same sentence as the number. What it is, is the operator-facing point of Part VI reduced to three published integers. The proven-versus-conjectured axis is where a deployed proof system’s margin actually lives, and it is the axis least often reported beside the headline figure.
CNFL routing. Two amber surfaces at both parameter points. The L2 hash and Merkle binding degrades quantitatively under BHT and CNPS unless n_hash is widened against the quantum adversary (Brassard et al., 1998; Chailloux et al., 2017). The L4 Fiat-Shamir parameter point carries the DFMS20 conditional. The chapter’s three-term model asks whether the deployed parameter point absorbs the DFMS20 loss by the target margin, and Ch 34 is explicit about what the answer is worth: a generic reduction loss becomes a statement about a deployment only once the protocol’s hypotheses, its interactive bound, its hash assumptions and its actual parameters have been instantiated in a published analysis, so passing the model does not establish that either verifier is secure against a future quantum forger, and failing it exhibits no forgery (Renz, 2026). There is no L2 group-DLP route at either parameter point. The Shor-on-curve forgery path that dominates Sapling, Orchard, and the ZKsync outer wrapper is therefore structurally absent. The on-chain verifier is upgradeable through the documented governance framework, so a redeployment with reparameterized constants is the mechanism by which both surfaces would be closed. Which constants close them is what the missing analysis has to say. Until one is published for the composed Stone-root and Stwo-leaf path, a redeployment closes the gap the model measures, which is not necessarily the gap that exists.
Transition path. The remediation class is parameter changes rather than an L2 or L4 redesign, because both amber surfaces are quantitative margins and neither has a Shor route. Which changes suffice is the question the previous paragraph leaves open, so the list that follows names candidates, and the composed analysis is what fixes their values. Increase hash output size to widen the BHT and CNPS margins. Widen the FRI challenge space per DFMS20 to absorb the QROM loss. The F_{p^3} to F_{p^4} extension lift ethSTARK Documentation v1.2 §5.10.2 recommends is the smallest such bump in the ethSTARK reference configuration, and it does not apply to Stone, whose Cairo verifier already draws its challenges from the 252-bit field. Tighten grinding bits to taste. Formally verify the QROM compilation of the deployed pipeline and publish the proof. Ship the reparameterized verifier through the upgrade authority of the contracts it touches, which L2BEAT records at the read date (L2BEAT, 2026a). The shared SHARP verifier sits behind a 2-of-4 multisig with an eight-day delay, the Starknet core contract behind a 2-of-6 multisig with the same delay, and a 9-of-12 Security Council can upgrade the core contract with no delay. The architecture does not change. Proof size and verification gas cost grow with the widening, and they are measured on the resulting implementation rather than read off the model.
The Stone-to-Stwo move is itself the existence proof that this chain can swap prover stacks through that channel. It went live on Starknet mainnet in late 2025 and changed neither the L2 commitment class nor the L4 compilation: both paths are Merkle plus FRI under Fiat-Shamir before and after (StarkWare, 2025b). A parameter bump is a strictly smaller change than the one already shipped.
On 30 June 2026 StarkWare published a quantum-readiness roadmap that operates on layers this soundness analysis does not touch. It replaces Pedersen hashing with BLAKE2 across state commitments, contract-address derivation, and the network configuration hash. Part of that has since shipped as a release: Starknet v0.14.3 moves the operating-system program hash and configuration hash the core contract checks from Pedersen to a BLAKE hash, with mainnet dated 6 July 2026 in its prerelease notes (StarkWare, 2026d). The v0.14.4 prerelease notes of 9 September 2026 schedule mainnet for 5 October 2026 pending governance approval, and they treat v0.14.3 as the version in force for their SNIP-36 transaction prover, whose v0.14.4 verifier rejects proofs generated under the v0.14.3 prover (StarkWare, 2026e). No after-the-fact deployment record was found, so the date is the release schedule’s. The trie and contract-address changes remain published direction rather than live. It also states a direction toward post-quantum consensus and account signatures using a scheme such as Falcon-512 (StarkWare, 2026e). That roadmap targets the chain’s hashing and signature layers rather than the FRI-proximity soundness of the STARK verifier analyzed here, so the amber L2 and L4 posture and the parameter-bump transition above both stand. It is current-state context, not a change to the soundness conclusion.
Per-attack-surface cryptanalysis and the QROM-pending caveat
Section titled “Per-attack-surface cryptanalysis and the QROM-pending caveat”The exposition below is organized by attack surface, not by system. Each heading names the attack and states what each of the three case studies inherits.
Shor at L2. Sapling, Orchard, and the ZKsync Era outer wrapper fall to a polynomial-time Shor attack on the discrete logarithm of a specific curve (BLS12-381 for Sapling, Pallas and Vesta for Orchard, a pairing-friendly curve for the outer wrapper). No parameter increase within the existing architecture closes this route. The L2 commitment must be replaced with a non-group-based primitive. The transition paths for Zcash require a successor proof system, and no published Zcash roadmap proposes one. Tachyon’s Ragu track follows the original Halo construction, whose commitment is discrete-log based, and its post-quantum goal is payment privacy through private information retrieval and post-quantum key exchange (Electric Coin Company, 2026). The transition path for ZKsync requires the outer-wrapper replacement to a PQ-compatible compressor. Both are structural changes, not parameter tuning.
BHT and CNPS at L2. Boojum inner, the Stone root path, the Stwo leaf path, and every Merkle-plus-FRI system degrade quantitatively under quantum collision-finding (Brassard et al., 1998; Chailloux et al., 2017). BHT’s 2^{n_hash/3} bound reduces a 256-bit hash to 85-bit PQ strength under QRACM; CNPS’s 2^{2 n_hash/5} bound reduces the same hash to about 102 bits without QRACM. Ch 32’s Merkle subsection tabulates the crossover widths and respects the SHAKE128 collision-strength cap of 128 bits regardless of output length per FIPS 202 Appendix A.1. Widths at or above 384 must use SHA-384, SHA-512, SHA3-384, SHA3-512, or SHAKE256. The operator’s choice is to lift n_hash to 384 or 512 where the target PQ margin is 128 bits, or to accept a lower margin at the original width. This route closes with a hash-width bump.
DFMS19 and DFMS20 at L4. The three-move sigma compilation (Tier 1, DFMS19, loss (2q+1)^2 * epsilon, so (2q+1)^2 / |C| at the Schnorr floor) and the multi-round one (Tier 2, DFMS20, loss (2q+1)^{2r} on the interactive soundness error, so (2q+1)^{2r} / |C|^r under Ch 33’s per-round model) price the Fiat-Shamir QROM soundness at the per-round challenge-space width, the first as a theorem and the second as Ch 33’s stipulated model (Don et al., 2019, 2020). The parameter-bump rule is c_bits >= 2 log_2(2q + 1) + k for three-move or c_bits >= 2 log_2(2q + 1) + k/r per round for DFMS20, rounded up to the next integer and never down. The sign is +k. Ch 33’s quantum-oracle-cost section derives the form, and its Table 33.1 shows the approximation 2 q_bits + ⌈k/r⌉ landing about 2 bits short of it. A deployed system reads its per-round width off the rule for its own r_FS, and what that width buys is a model output: it certifies a target only once the corollary’s additive term and the protocol’s actual interactive error have been supplied (Ch 33). The cost per proof is one round of additional hash evaluation. The amortization stays small because r_FS is single-digit in every Part VI case study.
FRI-based SNARK deployment-parameter QROM accounting pending at L4 (Tier 3). Block et al. 2023 proves Fiat-Shamir security for FRI and batched FRI in both the classical ROM and the QROM, the quantum half via the BCS state-restoration lift (Block et al., 2023). The quantum statement is adaptive soundness and knowledge error Theta(q * eps_fs) against O(q)-query quantum adversaries. What is missing is the concrete composition at deployment parameters. No published QROM accounting carries that bound through Merkle binding, hash width, grinding, batching and recursion for Boojum inner, for Plonky2 / Plonky3, for the Stone root path, or for the Stwo leaf path. Block and Tiwari 2024 perform the plain-FRI part of that composition in the classical ROM only, with batching and recursion left out (Block & Tiwari, 2024, sec. 3.3). Stwo’s circle-STARK construction post-dates both papers.
Every concrete FRI-STARK soundness number against a quantum adversary is therefore conditional on that pending accounting, not on a missing QROM theorem for FRI. Ch 34 Section 5.6 lays out the caveat and Ch 35 inherits it: the amber Boojum inner, the amber Stone root, and the amber Stwo leaves all carry it in prose, not just in the table.
Composition polynomial and per-column soundness. The Ch 34 toy pipeline drops the composition polynomial that production STARK systems use. A deployed system (Boojum inner, the Stone root path, the Stwo leaf path) composes all AIR columns into a single composition polynomial before the FRI proximity test runs. The Ch 34 soundness formula applies to the composition polynomial, not to each column independently. Operators reading the ethSTARK documentation or the Boojum upgrade announcement should track the composition polynomial as the object of FRI proximity. The per-column view is pedagogical and understates the work FRI does in production.
What each transition path closes and what it leaves open. Zcash’s path is a successor shielded pool with non-group-based L2 paired with a non-ECDH note-encryption scheme. It closes the L2 red cell, the L4 red cell, and the ECDH privacy route simultaneously. The migration is the largest in scope across the three case studies, because L2 replacement cascades into arithmetization, circuit design, and on-chain verifier rewrite. The Tachyon roadmap does not propose this redesign: it proposes a new shielded pool on a Halo-based proof layer and post-quantum privacy for payment delivery, and neither is activated on mainnet (Electric Coin Company, 2026). The proof-system half of Zcash’s path has no published roadmap.
ZKsync’s path is outer-wrapper replacement. It closes the outer red cell but leaves the inner amber cell in place. The inner still carries the QROM-pending caveat and the BHT / CNPS hash-width question.
Starknet’s path is parameter changes at the inner, with the values still to be set. It closes the pending caveat once the proof-system community publishes the QROM accounting at deployment parameters. The Stone-to-Stwo switch at the leaves itself shipped on mainnet in late 2025 with no change to the on-chain verifiers (L2BEAT, 2026a; StarkWare, 2025a, 2025b). That transition is an existence proof that Starknet can swap prover stacks without structural L2 or L4 redesign. The BHT / CNPS question remains open, the same way as for ZKsync inner. The gas-cost delta follows from those values once they are set, and is measured rather than derived from the model.
Migration cost, parameter bump, and pending-literature risk
Section titled “Migration cost, parameter bump, and pending-literature risk”Table 35.3. Transition-path comparison across Zcash, ZKsync, and Starknet.
| System | L2 posture | L4 posture | CNFL dominant route | Transition scope | Parameter bump | Pending literature |
|---|---|---|---|---|---|---|
| Zcash Sapling | red (pairing) | red (CRS) | L4-via-CRS soundness, this book’s placement, which Renz reads at L2 with no Fiat-Shamir layer; ECDH-Jubjub privacy conditional on the recipient address (d, pk_d) (Hopwood et al., 2026; Renz, 2026) | successor proof system + non-ECDH note encryption (no published roadmap for the proof system; Tachyon proposes post-quantum payment privacy on a Halo-based proof layer, not activated) (Electric Coin Company, 2026) | N/A, replacement | none gating (Shor is settled) |
| Zcash Orchard | red (IPA / DLP) | red (FS over IPA) | L4-via-FS soundness, ECDH privacy conditional on recipient address material (Bowe et al., 2019; Hopwood et al., 2026) | successor proof system + non-ECDH note encryption | N/A, replacement | none gating |
| ZKsync Era (outer) | red (pairing / SRS) | red (CRS for Groth16-style, Fiat-Shamir over KZG / pairing transcript for PLONK and Fflonk per V27 (ZKsync Association, 2025)) | L4-via-CRS or FS-over-pairing | wrapper replacement to PQ-compatible compressor (Chiesa et al., 2020), governance via ZK Nation (ZKsync Association, 2024) | N/A for the wrapper, replacement | none gating for the replacement itself |
| ZKsync Era (inner) | amber (FRI) | amber (Tier 3) | L2 hash binding + L4 parameter point (QROM accounting pending) | parameter bumps | n_hash, c_bits, grinding, queries | FRI QROM-at-deployment pending; asymptotic bound proven, concrete composition published in the classical ROM only (Block et al., 2023; Block & Tiwari, 2024) |
| Starknet Stone (the recursion root, the proof the L1 contract reads) | amber (FRI over the 252-bit Cairo field) | amber (Tier 3) | L2 hash binding + L4 parameter point (QROM accounting pending) | parameter bumps, shipped as a verifier upgrade | n_hash, c_bits, grinding, queries | FRI QROM-at-deployment pending (Block et al., 2023) |
| Starknet Stwo (every Starknet mainnet block, verified in-circuit below the Stone root; no claim made about StarkEx) | amber (FRI over M31 at the leaves) | amber (Tier 3) | L2 hash binding + L4 parameter point (QROM accounting pending) | parameter bumps, shipped as a prover-side upgrade as the Stone-to-Stwo switch was (StarkWare, 2025b) | n_hash, c_bits, grinding, queries | FRI QROM-at-deployment pending, Stwo-specific deployment-parameter QROM audit also pending (Block et al., 2023) |
# Block 6: taxonomy grid classifier. Takes a dict describing a# deployed system's L2 and L4 layers and returns the grid cell color# per Figure 35.1 plus the CNFL route per the two specializations from# the math-preliminaries section of this chapter. Red dominates amber# dominates green. Grid: Table 31.2 in Ch 31. Renz (2026) Section 6# names the two specializations; assigning them to layers is this# chapter's own analysis.L2_COLORS = {"pairing": "red", "ipa_dlp": "red", "fri": "amber", "lattice_pcs": "amber"}L4_COLORS = {"crs": "red", "fs_over_dlp": "red", "fs_tier1": "amber", "fs_tier2": "amber", "fs_tier3_classical_rom": "amber"}
def classify(system: dict) -> dict: if "l2" not in system or "l4" not in system: raise ValueError("system dict must include l2 and l4 keys") l2_color = L2_COLORS.get(system["l2"]) l4_color = L4_COLORS.get(system["l4"]) if l2_color is None: raise ValueError(f"unknown l2 value: {system['l2']!r}") if l4_color is None: raise ValueError(f"unknown l4 value: {system['l4']!r}") order = {"red": 0, "amber": 1, "green": 2} dominant = min(l2_color, l4_color, key=lambda c: order[c]) if dominant == "red": if system["l2"] == "pairing": cnfl = "pairing forward forgery plus retroactive trust erosion" else: cnfl = "DLP forward forgery plus retroactive trust erosion" else: # The amber route depends on what the L2 commitment binds with: # a FRI Merkle tree binds by hash, a lattice PCS by SIS. l2_route = {"fri": "L2 hash binding (BHT/CNPS)", "lattice_pcs": "L2 SIS binding"}[system["l2"]] cnfl = l2_route + " plus L4 Fiat-Shamir parameter point, QROM-pending" return {"cell": (l2_color, l4_color), "posture": dominant, "cnfl_route": cnfl}
sapling = classify({"l2": "pairing", "l4": "crs"})orchard = classify({"l2": "ipa_dlp", "l4": "fs_over_dlp"})boojum_outer = classify({"l2": "pairing", "l4": "crs"})boojum_inner = classify({"l2": "fri", "l4": "fs_tier3_classical_rom"})ethstark = classify({"l2": "fri", "l4": "fs_tier3_classical_rom"})print(sapling["posture"], orchard["posture"], boojum_outer["posture"], boojum_inner["posture"], ethstark["posture"])# ==> red red red amber amberThe on-chain verifier contract reads the ZKsync Era outer wrapper first, so the deployed composite posture is dominated by the outer cell until the wrapper is replaced.
Where Part VI ends and Part VII picks up
Section titled “Where Part VI ends and Part VII picks up”Part VI took a proof system apart and asked which layer a quantum adversary reaches. Ch 31 set the four layers. Ch 32 sized the commitment families that sit at L2. Ch 33 classified the Fiat-Shamir compilations that sit at L4. Ch 34 composed a full FRI-based STARK and its soundness budget, and this chapter read three deployed systems off the resulting grid. The unit of analysis throughout was the proof system: one object, four layers, one verdict per cell.
Part VII changes that unit from the proof system to the chain. A blockchain at chain-tip in 2026 carries five cryptographic surfaces, and the on-chain verifier that Part VI spent five chapters on is one of them. The other four are signature surfaces: the per-spend transaction, the wallet key rotation, the consensus attestation, and the governance vote. Those run on classical signatures at chain-tip, ECDSA, Schnorr and BLS, and Part VII migrates them to the standardised primitives of Parts II and III rather than to anything Part VI built. Ch 36 sets that taxonomy on a fictional chain called Strand and says outright that the proof system is Part VI’s subject, deferring to Ch 34 for the construction and to this chapter for the grid placement. Ch 40 is where the four-layer decomposition returns, applied to a deployed verifier contract. It opens by saying it picks up where this chapter leaves off.
The thread crosses back once more, and it crosses as a negative. Ch 39 migrates the consensus signature, where the BLS payload covering a million validators is 125,096 bytes and the same validator set under ML-DSA-65 is 3.3 billion bytes, a factor of 26,452. Almost all of that BLS payload is the participation bitmap; the aggregate signature itself is 96 bytes. That chapter names two mitigations, a SNARK-based aggregation wrapper and a threshold post-quantum signature on the Quorus model, and it records that neither is chain-deployed at chain-tip 2026. The threshold path replaces a validator set’s independent signatures with one signature under a joint key, which is a different construction from aggregating the independent ones. Part VI’s machinery is one of those two proposed answers to Part VII’s hardest size constraint, and neither is shipping.
That inversion is what carries across the boundary. Part VI analysed what is deployed and found the margins resting on conjectures, one of which fell while this Part was being written. Part VII deploys what is standardised and finds the sizes prohibitive. Neither Part is entitled to assume the other’s problem is solved.
Exercises
Section titled “Exercises”-
A hypothetical SNARK has L2 = bulletproofs (IPA over secp256k1) and L4 = Fiat-Shamir over the IPA transcript. Classify it in the grid. State the CNFL route. Name the minimum-cost migration step if the operator targets PQ parity at 128 bits.
-
Use Block 3’s
stark_classical_marginto compute the classical-ROM margin at a hypothetical Boojum configuration withfield_bits = 128,L = 2^{18},N = 2^{22}(blowup 16),mu = 48,r_FRI = 18,grinding = 20. Which of the three terms in the Ch 34 Section 5.5 formula dominates the sum? Then compare against the original illustrative configuration (L = 2^{16},N = 2^{20},mu = 40): by how many bits does the larger trace buy margin? -
A system publishes
c_bits = 96per Fiat-Shamir round,r_FS = 6, and claims 80-bit PQ soundness at aq_bits = 80query budget. Check the DFMS20 parameter-bump rule in its exact form,c_bits >= 2 log_2(2q + 1) + k/r. Does the parameter point satisfy the rule? If not, state the minimumc_bitsper round that does atk = 80, and say what that number does and does not establish about the claim. -
ZKsync Era’s outer wrapper replacement candidates include recursive STARK folding (keeping the on-chain verifier STARK-only) and a transparent recursive SNARK such as Fractal (Chiesa et al., 2020). State one operator-facing tradeoff between the two options at the on-chain verifier gas cost. Cite the L2 and L4 classifications of each candidate.
-
Place a fourth deployed zero-knowledge system of your choice (Aleo, Polygon zkEVM, Mina, or another) in the (L2, L4) grid using the same case-study procedure. Cite one primary source per claim.
Worked solutions and editorial notes for these exercises are in Appendix D, Chapter 35. A separate track, for rebuilding rather than reading: the package exercises/ch35-case-studies has every routine the chapter teaches but does not print replaced by a stub. Run PQC_IMPL=exercises pytest tests/ch35 to grade your version against the suite that proves the reference one.
References
Section titled “References”Last updated: