Chapter 35: Case studies: Zcash, ZKsync, Starknet
Three deployed zero-knowledge systems, three different choices at L2 and L4, and two post-quantum postures: red for Zcash and for ZKsync’s outer wrapper, amber for Starknet and for ZKsync’s inner proof. 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 Stone to Stwo on mainnet in late 2025, announced on 3 November 2025 (StarkWare, 2025b), with L2BEAT’s milestone log dating the switch to 19 October (L2BEAT, 2026a). 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 occupy two of the grid’s six cells between them. 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 straddles both cells: its red outer (pairing wrapper) sits with Sapling and Orchard and its amber inner (FRI) with Starknet, so its inner and outer proofs 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. Of the three deployed systems, it is the only one where neither L2 nor L4 falls to a Shor adversary. Whether its Fiat-Shamir compilation meets a post-quantum target at the deployed parameters, or which changes would make it, is a question for a QROM analysis of the composed deployment, which Ch 34 Section 5.6 records as unpublished.
Zcash Sapling at quantum landfall, revisited
Section titled “Zcash Sapling at quantum landfall, revisited”Ch 31 closed on 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 system 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. Table 35.2 lists the three L2 classes and three L4 classes that cover the systems deployed in 2026 and gives the reason each carries the color it does. The figure groups those classes by color. 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 |
| 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 | Module-SIS binding, with parameters tuned against classical and quantum sieving (Ch 32) |
| L4 | pairing CRS trust | red | the trapdoor falls with the curve |
| L4 | FS over a DL argument | red | L2 falls to Shor before QROM matters |
| L4 | FS over a hash transcript | amber | asymptotic QROM bound proven for FRI and batched FRI that fold by two over a smooth multiplicative subgroup (Block et al., 2023), none for circle FRI (Ch 34), 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.
A pairing-based system’s bit margin is zero in the CRQC adversary model, whatever the field width, because Shor’s algorithm solves in polynomial time the discrete logarithm problem whose hardness its L2 binding needs (Shor, 1994). Ch 32’s Block 2 runs that break on a toy KZG setup, with brute force standing in for Shor: it recovers the trapdoor from the SRS and forges an opening to an evaluation of its choosing.
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 1, 2 and 3 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).
Since the NU6.3 network upgrade, new Orchard-protocol value goes to a new shielded pool. NU6.3 took effect on mainnet at block height 3428143, mined on 28 July 2026. It created the Ironwood pool as another use of the Orchard protocol, and from that height the Orchard pool can only be spent from, not added to (Hopwood, 2026; Nighthawk Apps, 2026). Ironwood’s proofs are therefore Orchard’s Halo 2 proofs, and what this section says about Orchard’s four layers holds for Ironwood too.
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 uses a multi-round public-coin protocol with an inner-product-argument opening, 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 of a red L2 against a CRQC adversary under the discrete-log and pairing assumptions, Sapling’s on BLS12-381 and Orchard’s by the same argument on Pallas and Vesta.
CNFL 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-SIS binding 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).
NU6.3 also made every new Ironwood note quantum-recoverable (Hopwood, 2026). The recovery itself is a future protocol that ZIP 2005 outlines without specifying, to be introduced, potentially, in a later upgrade. If the discrete-log-based shielded protocols are switched off before an attack, it would let holders recover Ironwood funds, and ZIP 2005 expects it to remain secure against quantum adversaries. Its security argument assumes a post-quantum knowledge-sound proof system, which ZIP 2005 deliberately does not choose. Funds still in the Sprout, Sapling or Orchard pools could not be recovered (Hopwood & Grigg, 2025).
ZIP 2005 says the change “does not by itself make the protocol secure against quantum adversaries”. It leaves privacy unchanged for every pool: Ironwood’s note encryption stays open to harvest-now-decrypt-later by an adversary who also holds the receiver address, the precondition set out above for Sapling and Orchard (Hopwood & Grigg, 2025). It moves neither cell in the grid. Ironwood’s proofs still rest on a discrete-log commitment, and what NU6.3 added is a note format that makes such a recovery possible.
The Tachyon roadmap, read as it stood on 19 October 2026 and carrying no publication date, is a proposed Zcash upgrade with three tracks (Project Tachyon, 2026). Ragu is a Rust proof-carrying-data library that follows the original Halo construction. A new shielded protocol with a simplified key structure is built on it, acting as a pool independent of the existing Orchard pool. It is not NU6.3’s Ironwood pool, which reuses the Orchard protocol. In a payment-protocol track, one approach uses private information retrieval and post-quantum key exchange for post-quantum privacy of payment delivery, the roadmap’s only post-quantum goal. 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 had not been activated on mainnet by 19 October 2026: 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, as the page stood on 19 October 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 KZG, the pairing-based polynomial commitment of the PLONK and Fflonk wrappers the L1 verifier accepts (Ch 32). 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) over a PLONKish arithmetization of gates, copy constraints and lookups. Boojum does not use AIR, whose constraints span rows of the trace (README in Matter Labs, 2026). Outer: the polynomial-identity protocol of PLONK or Fflonk, 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. The published asymptotic QROM Fiat-Shamir results for FRI, obtained through the Chiesa-Manohar-Spooner lift, are the theoretical starting point (Block et al., 2023; Chiesa et al., 2019). They do not certify Boojum’s complete transcript. Block et al. do not treat Boojum by name and state their results for FRI that folds by two, where Boojum folds by 8 (Ch 34 Section 5.6). The same section records that no QROM composition at Boojum’s deployment parameters had been published.
Outer: the L4 mechanism depends 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 1 applies the Ch 34 composed-soundness formula at an illustrative configuration of the inner Boojum pipeline.
# Block 1: 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 Section 5.1's note records as having# fallen in late 2025. The DFMS20-shaped challenge-width rule from# Ch 33's multi-round subsection then gives the model's per-round# requirement at a target PQ margin. The values below are# illustrative of a Goldilocks extension-field configuration. No# claim is made that any Boojum layer uses them.# 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 184Every 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 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 query-miss term, log_per_round in the listing, still dominates. Exercise 2 walks a configuration past the crossover, where it does not.
The DFMS20-shaped challenge-width rule sets 184 bits per round as its threshold for a 128-bit QROM target 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. 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). Ch 34 Section 5.6 records that no deployment-parameter composition of the FRI-specific bound for the production FRI pipelines this Part reads had been published to replace it. For the larger folds of Stone and Boojum, and for Stwo’s circle FRI, it records that the bound itself had not been stated.
Read against the model, a deployment whose per-round challenge-space width is narrower than 184 bits falls short of the model’s threshold at k = 128, which is no verdict either way. The Block 1 values are illustrative, and the chapter does not claim that any Boojum layer uses them. Block 1 also sets r_FRI = log_2 L, which counts the rounds of FRI that folds by two, while Boojum folds by 8 (Ch 34 Section 5.6). Its 99.9 bits are therefore the model’s figure for two-to-one FRI at illustrative values, not a Boojum margin. 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. It establishes the target margin for a legacy inner verifier still in service only if the FRI-specific bound, composed at the deployed parameters, meets that margin, and the DFMS20-shaped model settles neither direction (Renz, 2026).
The wrapper surface stays live until the wrapper is replaced. The two inner surfaces stay live until the inner layers, as deployed or as changed, are shown to meet the target margin.
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 share the ordinary upgrade path, 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)). Widening the inner hash output raises the BHT and CNPS margins on established bounds, as for Starknet below. Grinding bits, FRI queries and challenge-space width are secondary candidates that would reparameterize the existing pipeline, and whether they suffice, or whether the inner STARK needs more, depends on a QROM analysis of the composed deployment.
Any inner parameter change would ship through the same governance mechanism (ZKsync Association, 2024, 2025). A separate expedited path, for emergency responses and security patches, skips the Token Assembly and needs all three of the Security Council, the Guardians and the ZKsync Foundation to approve (Ch 40).
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 transitioned from Stone to Stwo on mainnet in late 2025 (StarkWare, 2025b). 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, 2026c). No public record that the change had shipped by 19 October 2026 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 2 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, 2026b). 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., 2018b). 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 2 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 2 tracks the DEEP composition polynomial, the combination of trace and composition-polynomial quotients that FRI tests, 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. For the Stone root’s prime-field FRI, the published results give an asymptotic QROM Fiat-Shamir bound through the Chiesa-Manohar-Spooner lift (Block et al., 2023; Chiesa et al., 2019). They do so only once extended to Stone’s larger folds and its interaction trace, an extension Ch 34 Section 5.6 records as unstated. None of those theorems covers the Stwo leaves’ circle FRI, whose round-by-round soundness the S-two whitepaper proves with a non-interactive bound in the classical random oracle model only, deferring the QROM (Carmon et al., 2026). 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 2 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-shaped challenge-width 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 2: 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 1: the model's output at that radius, not a proven floor).# The DFMS20-shaped challenge-width 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# worked 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 model's# target is k = 128 to match Ch 34 Section 5.7's headline# worked 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. They come from an analysis the three-term model does not reproduce, so they are not a check on the model’s 116 bits in either direction. 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 documentation’s Theorem 5 gives r_eth = 3 + |fri_step_list| rounds, and its proof counts one more. The proof counts each verifier draw: the constraint randomness, the DEEP query, the FRI combination randomness, one challenge per FRI commit-phase layer and the query round. On the theorem’s count, six is a three-layer step list, and pairing that list with r_FRI = 20 folds is illustrative rather than a published configuration. The toy collapses to r_FRI + 1 = 4 instead, one challenge per fold and then the query round.
The DFMS20-shaped challenge-width check at k = 128, q = 2^{80}, r_FS = 6 gives 184 bits per round, the threshold of a model that is neither tight nor conservative (Ch 33): the check applies the protocol-agnostic DFMS20-shaped rule rather than the FRI-specific bound. Ch 33’s subsection on the DFMS20 hypotheses explains why FRI is sized under a dedicated bound. Ch 34 Section 5.6 records what remains pending: the deployment-parameter composition of that bound, its reach to deployed rates, its extension to Stone’s larger folds and interaction trace, and any QROM statement for Stwo’s circle FRI.
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, and the model certifies nothing by itself.
For Stwo’s circle FRI, Ch 34 Section 5.6 records that no QROM statement had been published, let alone a deployment-parameter composition. Stwo’s own published target is also 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.
Ch 34 Section 5.6 records that no QROM-proven soundness number at the deployed parameters had been published for either parameter point. An asymptotic QROM bound for the Stone root’s prime-field FRI rests on extending the published smooth-subgroup results to Stone’s folds and interaction trace, an extension that section records as unstated. For Stwo’s circle FRI the published result is round-by-round soundness with a classical-ROM compilation (Carmon et al., 2026). 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.
Block 3 differs from Blocks 1 and 2, which use illustrative configurations: it reads Stwo’s own published defaults. The stwo-cairo README gives them outright, pow_bits = 26, log_blowup_factor = 1 and n_queries = 70, targeting 96 bits of conjectured soundness (StarkWare, 2026b). On 19 October 2026 that README and Stwo’s own both opened with a notice that development had moved to StarkWare’s proving repository at the end of July 2026, so the numbers are the last ones this repository published. The word conjectured is carrying the sentence, and Block 3 shows where.
# Block 3: 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 word 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 conditional of the DFMS20-shaped model. The chapter’s three-term model asks whether the deployed parameter point absorbs the DFMS20-shaped loss by the target margin. 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. Passing the model therefore 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 is the channel a change at the Stone root would take. At L4 the analysis Ch 34 Section 5.6 records as unpublished has to say whether the deployed constants meet the target, which changes would suffice if not, and whether constants alone are enough. Until one is published for the composed Stone-root and Stwo-leaf path, a redeployment sized by the model closes the gap the model measures, which is not necessarily the gap that exists.
Transition path. Neither amber surface has a Shor route, so neither faces the structural replacement Shor forces on Zcash and the ZKsync wrapper. That absence does not show that parameter changes suffice. Increase hash output size to widen the BHT and CNPS margins, a tradeoff that rests on established bounds (Ch 32) and need not wait for a QROM analysis, though whether the configuration then meets the target does.
At the L4 Fiat-Shamir parameter point, where the challenge space and grinding sit, the first step is that analysis: formally verify the QROM compilation of the deployed pipeline and publish the result. Its outcome could certify the deployed parameters, justify particular changes, or leave the question unresolved. The candidate changes are a wider Fiat-Shamir challenge space, which the DFMS20-shaped model prices, and more grinding bits, and their sufficiency depends on that outcome. The F_{p^3} to F_{p^4} extension lift ethSTARK Documentation v1.2 §5.10.2 recommends is the smallest such widening in the ethSTARK reference configuration, and it applies to neither deployed parameter point. Stone already draws its challenges from the 252-bit field, and Stwo from QM31, a degree-four extension of M31.
Any reparameterized verifier would ship through the upgrade authority of the contracts it touches, which L2BEAT’s Starknet page listed as it stood on 19 October 2026 (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. If the candidates suffice, the architecture does not change. Proof size and verification gas cost grow with any 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. 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). It shows that the chain can change its prover, not which change, if any, the analysis would call for.
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 (StarkWare, 2026e). Part of that has since shipped: 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 scheduled for 6 July 2026 in its prerelease notes (StarkWare, 2026d). Starknet’s status page records the v0.14.3 mainnet upgrade complete on 8 July 2026 (Starknet, 2026a). The v0.14.4 prerelease notes of 9 September 2026 scheduled mainnet for 5 October 2026 pending governance approval, and they list no change to the hash functions behind state commitments or contract addresses (StarkWare, 2026f). The status page records the v0.14.4 mainnet upgrade complete on 6 October 2026 (Starknet, 2026b). The trie and contract-address changes remain published direction rather than live.
The roadmap 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 transition path 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). Ironwood falls with Orchard. 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. Public goals for a fully post-quantum Zcash exist (Swihart, 2026), but a search of the project’s roadmaps, ZIPs and research discussions as they stood on 19 October 2026 found no published specification selecting that proof system. Tachyon’s Ragu track follows the discrete-log-based Halo construction, and its post-quantum goal is payment privacy (Project Tachyon, 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) loses (2q+1)^2 * epsilon, so (2q+1)^2 / |C| for an interactive soundness error of 1 / |C|: DFMS19’s reduction with the residue-free coefficient of DFMS20’s Theorem 2. The multi-round one (Tier 2, DFMS20) loses (2q+1)^{2r} on the interactive soundness error, so (2q+1)^{2r} / |C|^r under Ch 33’s per-round model. Both 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 challenge-width 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 under the DFMS20-shaped model, 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 per-round width read off the DFMS20-shaped rule is a teaching-model output, not a deployment minimum: it certifies a target only once the corollary’s additive term and the protocol’s actual interactive error have been supplied (Ch 33). The three-move width rests on DFMS19 only under the premise that the interactive error is 1 / |C| against quantum provers. For the FRI pipelines of this chapter the applicable analysis is a QROM analysis of the composed deployment (Ch 34 Section 5.6), and what any widening costs is measured on the implementation, not read off the model.
FRI-based SNARK deployment-parameter QROM accounting pending at L4 (Tier 3). Ch 34 Section 5.6 records the gaps between the published QROM results for FRI and the deployed pipelines, each with its date, and this chapter’s three FRI surfaces inherit them. It records that none of the five pipelines it names, these three among them, had an end-to-end QROM accounting at deployment parameters. Boojum inner and the Stone root run FRI over a smooth multiplicative subgroup, so they also carry the open question whether the published theorems reach deployed rates. Both need the unstated extension to larger folds, and for the Stone root the extension has to cover its interaction trace too. The Stwo leaves carry the missing QROM statement for circle FRI.
Every concrete soundness number against a quantum adversary for these pipelines is therefore conditional on the gaps that apply to its pipeline. The amber Boojum inner, the amber Stone root, and the amber Stwo leaves all carry the caveat in prose, not just in Table 35.3.
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 its constraints (AIR for the Stone root and the Stwo leaves, PLONKish gates for Boojum) into a composition polynomial. FRI does not test that polynomial alone: in the ethSTARK documentation it tests the DEEP composition polynomial, a random linear combination of quotients built from the trace columns and the composition polynomial’s columns (§3.8 and §3.9.1 in Ben-Sasson, 2021). The Ch 34 soundness formula applies to that combination, not to each column independently. Operators reading the ethSTARK documentation should track it 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 had been activated on mainnet by 19 October 2026 (Project Tachyon, 2026). For the proof-system half of Zcash’s path, the search described under Shor at L2 found public goals (Swihart, 2026) but no published specification.
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.
At the L4 Fiat-Shamir parameter point, Starknet’s path starts with an analysis rather than a change: the QROM accounting at deployment parameters and, for the Stwo leaves, a QROM statement for circle FRI. Their publication would not by itself be a favorable result. They could certify the deployed parameters, justify particular changes, or leave the question open. Parameter changes at the Stone root and the Stwo leaves are a candidate route.
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, not evidence that no redesign will be needed. The BHT / CNPS question remains open, the same way as for ZKsync inner. Any gas-cost delta follows from the changes once they are set, and is measured rather than derived from the model.
Migration cost, candidate parameters, and pending-literature risk
Section titled “Migration cost, candidate parameters, 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 | Candidate parameters | 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 (public goals (Swihart, 2026) but no published specification selecting the proof system on 19 October 2026; Tachyon proposes post-quantum payment privacy on a Halo-based proof layer, not activated on that date) (Project Tachyon, 2026) | N/A, replacement | none gating (Shor is settled) |
| Zcash Orchard and Ironwood | red (IPA / DLP) | red (FS over IPA) | L2-via-IPA soundness (Shor recovers the generators’ discrete-log relations and forges the opening), 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)) | L2-via-KZG (Shor recovers the SRS trapdoor and enables false openings) | 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) | hash-width bump on established bounds, other parameter changes as candidates pending the QROM analysis | n_hash, c_bits, grinding, queries | FRI QROM-at-deployment pending; asymptotic bound proven for two-to-one FRI only, its extension to Boojum’s folds of 8 unstated and its reach to deployed rates open, as Ch 34 Section 5.6 records, and a classical-ROM analysis of the plain FRI sub-routine only (Block et al., 2023; Block & Tiwari, 2024; Matter Labs, 2026) |
| 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) | hash-width bump on established bounds, other parameter changes as candidates pending the QROM analysis, any change shipped as a verifier upgrade | n_hash, c_bits, grinding, queries | FRI QROM-at-deployment pending, the asymptotic bound an extension of published results that Ch 34 Section 5.6 records as unstated, and those results’ reach to deployed rates open (Ben-Sasson, 2021; Block et al., 2023; Chiesa et al., 2019) |
| 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) | hash-width bump on established bounds, other parameter changes as candidates pending the QROM analysis (the Stone-to-Stwo switch itself changed no on-chain verifier (StarkWare, 2025a, 2025b)) | n_hash, c_bits, grinding, queries | no QROM statement for circle FRI, as Ch 34 Section 5.6 records (the S-two whitepaper’s bound is classical-ROM only) (Carmon et al., 2026) |
# Block 4: 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": "fs_over_dlp"})boojum_inner = classify({"l2": "fri", "l4": "fs_tier3_classical_rom"})stone_root = classify({"l2": "fri", "l4": "fs_tier3_classical_rom"})print(sapling["posture"], orchard["posture"], boojum_outer["posture"], boojum_inner["posture"], stone_root["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 standardized 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. Neither was chain-deployed when the book checked, on 19 October 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.
That inversion is what carries across the boundary. Part VI analyzed 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 standardized 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 1’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 price the two changes one at a time against the original illustrative configuration (L = 2^{16},N = 2^{20},mu = 40,r_FRI = 16). By how many bits does the larger trace, with itsNandr_FRI, move the margin atmu = 40, and by how many do the extra queries move it at the original trace? -
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-shaped challenge-width 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: