Appendix D: Solutions for Chapter 40
Solutions and editorial notes for Chapter 40: Quantum threats to ZK rollups. Compute exercises have worked solutions; open-ended exercises have an editorial note describing what a strong answer addresses.
The fuller versions of these routines are in the zk_rollups package under
solutions/ch40-zk-rollups. From a clone of the companion repository,
pytest tests/ch40 runs its suite.
Appendix C has the setup.
Exercise 1
Section titled “Exercise 1”Worked solution. Per-proof gas-cost change when the L4 Fiat-Shamir hash swaps from SHA-256 to a wider-output construction, assuming a legacy SHA-256 STARK at five million gas per proof and an illustrative wider-hash multiplicative factor of one and three tenths.
The wider-hash configuration runs the same FRI verifier with a wider-output Fiat-Shamir construction at L4. The pragmatic on-chain wider-output construction at chain-tip 2026 is a multi-pass Keccak-256 over the native EVM opcode. SHAKE-256 has no EVM opcode or precompile, so a SHAKE-256 verifier would either carry a much larger gas penalty for a bytecode-implemented Keccak-f[1600] permutation or wait for a future EIP that introduces a SHAKE precompile. The effective transcript output widens (for example, from 256 to 512 bits via a two-pass Keccak), lengthening the on-chain Fiat-Shamir transcript and raising the per-proof gas by the wider-hash factor. The per-proof gas under the wider-hash configuration:
The multiplicative factor against legacy is .
The per-block proof maximum at the Ethereum gas-limit ceiling ( gas, the ETH_BLOCK_GAS_LIMIT value under the EIP-7935 EL-client-default recommendation at chain-tip 2026, Fusaka cycle):
The legacy configuration admits proofs per block, so the wider-hash swap costs the operator three proofs per block at the per-block ceiling. The thirty-percent illustrative factor represents the multi-pass Keccak construction. A bytecode-implemented SHAKE-256 would carry a much larger factor (an order of magnitude is plausible). The per-proof gas is illustrative at chain-tip 2026. A production rollup operator measures against its own deployed verifier.
The per-rollup-cycle cost depends on the per-cycle proof volume rather than the per-block ceiling. At the chapter’s default of one hundred state-transition proofs per L1 commitment cycle, the legacy configuration spends gas per cycle and the wider-hash configuration spends gas. Dividing those totals by the sixty-million ceiling gives 8.3 and 10.8, and those are gas-equivalents rather than block counts, because a proof cannot be split across two blocks. The block count comes from the per-block maximum computed above: at 12 legacy proofs per block, blocks, and at 9 wider-hash proofs per block, blocks. The two methods agree in the legacy case, where , and disagree in the wider-hash case, where rounding the gas total gives 11 against the true 12. Rounding a gas total is not the same computation as packing indivisible proofs, and it is the packing count the operator schedules against. The thirty-percent overhead carries through every quantity that scales linearly in per-proof gas, and the block count is not one of them. Sustained-throughput planning should also compare against the thirty-million EIP-1559 target rather than the sixty-million ceiling.
Exercise 2
Section titled “Exercise 2”Worked solution. The five-phase upgradeable verifier-contract upgrade choreography, the operator-side decision per phase, and the rollback path with the per-phase action that keeps rollback feasible.
The five phases of the choreography are propose, audit, multisig-approve, activate, transition window. Each phase resolves one operator-side decision.
Propose resolves which candidate configuration to migrate to. The proposer (the rollup core team or a governance member) submits the new verifier-contract bytecode plus the proof-system spec change to a public proposal queue. The decision is the (L1, L2, L3, L4) tuple the new verifier deploys.
Audit resolves the audit budget and timeline. An external auditor reviews the bytecode for soundness bugs, gas-cost regressions, and alignment with the spec. The decision is the audit-firm choice and the audit-window duration. Audit windows run days to weeks at chain-tip 2026.
Multisig-approve resolves the signer-set coordination. A governance signer set approves the activation transaction. The decision is the protocol-specific approval threshold and the per-signer turnaround commitment. Rollup governance paths at chain-tip 2026 are not a uniform multisig shape across rollups. ZKsync Era’s emergency path needs its Security Council, its Guardians and the ZKsync Foundation to reach nine, five and three signers, and ordinary changes go through the Token Assembly with the Security Council’s review and the Guardians’ veto window. Starknet’s Security Council can implement an emergency upgrade immediately at 75 percent approval, and regular upgrades wait seven days after security vetting. The phase ends when the signer set reaches the threshold and signs the activation transaction.
Activate resolves the activation block. The activation transaction lands on L1 and the verifier-contract proxy points the bytecode pointer at the new verifier. The decision is the L1 block number that activates the upgrade, typically chosen inside a low-volume window on the rollup.
Transition window resolves how long the legacy verifier accepts proofs alongside the new verifier. The legacy and new verifiers may run in parallel during the window, with the rollup committing proofs under the old configuration on one queue and the new configuration on a second queue. The decision is the duration of the parallel-run window.
The rollback path runs as a second propose-audit-multisig-approve cycle returning the verifier-contract proxy to the legacy bytecode. A misfired upgrade (a soundness bug in the new verifier, a gas-cost regression that breaks the per-cycle proof volume) burns operator funds during the time between activation and rollback. The per-phase action that keeps rollback feasible:
| Phase | Action that preserves rollback |
|---|---|
| propose | tag the proposal with a rollback-target reference to the legacy bytecode hash |
| audit | retain the audit-firm engagement so a follow-up audit on the rollback can run quickly |
| multisig-approve | retain the signer-set roster so the rollback transaction can collect signatures fast |
| activate | prepare and publish the rollback proposal in full (target bytecode hash, reviewed calldata, signer roster) so it is reviewed like any other; what stays unpublished is the authorization, collected as signatures only on incident or through the protocol’s emergency-upgrade authority if it has one |
| transition window | extend the legacy verifier acceptance to give time for the rollback before decommissioning |
The most load-bearing of the five rollback actions is the prepared rollback in activate. A reviewed, staged rollback reduces the turnaround from days (a fresh propose-audit cycle) to the signer set’s collection time plus whatever delay the protocol’s upgrade rules impose. A fully signed rollback transaction is not published in advance, because anyone holding it could broadcast a verifier downgrade the moment its nonce is valid, and pre-signing does not shorten an on-chain timelock. The transition-window extension is the second-most-load-bearing: a longer parallel window means the operator has more time to detect a misfired upgrade before the legacy verifier is decommissioned.
Exercise 3
Section titled “Exercise 3”Editorial note. A defensible answer applies the Ch 31 four-layer decomposition to a stated rollup and identifies which layers expose the on-chain surface.
The reader picks a rollup (ZKsync Era, Starknet, Linea, Scroll, Polygon zkEVM, Aztec, or another). For each layer, the answer states the candidate the rollup deploys at chain-tip 2026 and a one-line citation to the rollup’s spec or engineering blog post. The on-chain-exposed layers are L2 (commitment plus consistency) and L4 (non-interactivity plus extraction), regardless of the rollup. L1 (arithmetization) sits off-chain in the prover, and L3 (protocol logic, the IOP) mostly so, with the verifier-side algorithm (the verification key, parameter constants, opening-point selection and consistency checks) encoded on-chain, as Ch 40’s decomposition section states.
A defensible answer for ZKsync Era under the Boojum upgrade names L1=Plonkish, L2=FRI inner with pairing-based outer wrapper, L3=FRI-IOP with PLONK protocol logic, L4=a Keccak transcript at the published outer wrapper and a Poseidon2 transcript at the wrapped stage (Matter Labs, 2026; ZKsync, 2023). A defensible answer for Starknet inventories both parameter points on its composed path (Ch 34, Ch 35). At the Stone root, which is the proof the Ethereum contract reads: L1=AIR, L2=FRI, L3=FRI-IOP, L4=Keccak-256 in the published Solidity verifier’s channel, with BLAKE2s the ethSTARK document’s reference hash (Ben-Sasson, 2021; StarkWare, 2025, 2026). At the Stwo leaves, verified off-chain by the Cairo verifier program: L1=AIR over Mersenne-31, L2=Circle FRI, L3=FRI-IOP, L4=the Stwo channel, QM31 challenges under a BLAKE2s channel hash in the published stwo-cairo configuration (StarkWare, 2026b, 2026c). Which channel the deployed pipeline configures is attested only for the backend. StarkWare’s proving repository publishes a production circuit registry whose Cairo prover parameters name a BLAKE2s channel hash with pow_bits = 26, log_blowup_factor = 1 and n_queries = 70, and the repository calls that directory what the backend proves with. That is the circuit-based recursion path, read on 18 September 2026. No public record ties it to the proof a given day’s Ethereum settlement reads, and it says nothing about the Solidity verifier’s own channel. An answer that names SHA-256 has inherited the book’s toy transcript rather than read the deployment. A defensible answer also notes the post-quantum status per layer. KZG and pairing wrappers are Shor-broken. FRI is information-theoretic at the proximity layer and Grover/BHT-weakened on the Merkle commitment hash. SHA-256 at L4 is BHT-weakened to roughly 85 bits of post-quantum collision resistance under the generic-query quantum bound, which assumes about entries of quantum-accessible memory (Brassard et al., 1998).
A strong answer also identifies the operator’s first migration move per layer. ZKsync Era’s first move drops the outer pairing wrapper. Starknet’s first move widens the L4 transcript output via a multi-pass Keccak-256 construction over the native EVM opcode. SHAKE-256 has no EVM opcode or precompile at chain-tip 2026, so a SHAKE-256 verifier would either pay a bytecode-implementation tax or wait for a future EIP precompile. Both rollups share the L4 transcript-widening move as a second migration move once the L2 question is settled. That move widens the transcript’s collision margin under BHT and CNPS. The challenge-space width the QROM rule sizes is set by the field the challenges are drawn from, which a wider hash does not change, and Ch 35’s Starknet transition path lists both knobs.
Exercise 4
Section titled “Exercise 4”Worked solution. Strand verifier-upgrade cadence under given one rollup cycle per hour and a per-upgrade governance overhead of three weeks of wall-clock time.
The Strand on-chain-verifier surface from Ch 36 has and . The Mosca check at is . The surface therefore clears the strict-inequality breach threshold with a four-year margin (safe window years). No Mosca-mandated periodic rotation is required. The chapter’s recommendation function returns governance-trigger rather than every-N-rollup-cycles: the operator changes the verifier’s parameters at named governance events rather than at a fixed calendar interval. The Mosca-implied rotation interval under no breach is zero. The safe window is the years computed above. It is the rotation-interval field that reads zero in the recommendation envelope, because the chapter records governance-trigger as event-driven and carries interval in the recommendation tuple.
Wall-clock time between rotations under the Mosca-implied cadence: undefined. The cadence is event-driven, not calendar-driven. The operator coordinates a verifier-contract upgrade when a governance proposal lands, an audit firm clears a finding, or a candidate-configuration change reaches sufficient consensus.
The exercise then asks for a governance-defined maximum verifier age on top of the event-driven cadence. A defensible governance-defined ceiling is one rotation review every twelve months (a yearly verifier-bytecode review on the governance calendar). At one rollup cycle per hour, twelve months corresponds to rollup cycles between rotations. A tighter ceiling of one rotation review every six months gives cycles. A looser ceiling of one rotation review every twenty-four months gives cycles. All three ceilings sit comfortably inside the seven-year safe window the Mosca arithmetic provides.
Comparison against the chapter’s governance-trigger cadence under : the governance-defined ceiling is a policy layer on top of the chapter’s event-driven cadence rather than a replacement for it. The Mosca arithmetic clears the breach with seven years of safe window, so no scheduled rotation is required by the inequality. The policy ceiling exists to prevent the verifier parameter-set reuse window from quietly growing unbounded between governance events. The three-week per-upgrade governance overhead binds against the governance calendar rather than against the safe window. A scheduled rotation drive on top of the natural governance cadence would not change the breach decision. The breach is already cleared at years. The over-provisioned safe window is reserved for tighter scenarios. The narrow scenario forces every-N-rollup-cycles with a two-year safe window; the central scenario does not require any tightening of the natural cadence.
Exercise 5
Section titled “Exercise 5”Editorial note. A defensible mapping pairs each verifier-migration phase with a Ch 30 program phase and names the verifier-contract operator work-stream owner per the Ch 30 framework.
The verifier-contract migration sits in discovery during the audit phase and the signer-set coordination work. The audit firm reviews the candidate-configuration bytecode for soundness bugs and gas-cost regressions, and the rollup core team coordinates the multisig signer set for the activation transaction. The Ch 30 work-stream owner is the audit firm for the audit-window output and the rollup core team for the proposal-and-bytecode pipeline. The work-stream output is an audit report and a draft activation transaction.
It moves to first-wave as the candidate configuration deploys on a testnet rollup or a staging deployment. The Ch 30 work-stream owner is the rollup core team running the testnet, observing the per-proof gas and the per-rollup-cycle proof volume against the chapter’s gas-budget arithmetic. The first-wave window measures the operational footprint of the candidate configuration: per-proof gas, proof-batching shape, and per-rollup-cycle throughput.
It shifts to broad-rollout at the mainnet activation block. The rollup-side governance forum coordinates the activation block; the chain-governance forum (Ch 41) coordinates any L1-side hard-fork dependency the activation requires. The Ch 30 work-stream owner is the rollup-side governance forum (for ZKsync the Token Assembly on the ordinary path, with the Security Council’s technical review and the Guardians’ veto window, and the Security Council, Guardians and ZKsync Foundation together on the expedited one; for Starknet the Security Council for an emergency upgrade and the regular path’s seven-day delay otherwise (StarkWare, 2024; ZKsync Association, 2025)) for the activation-block decision and the multisig signer set for the activation transaction. The slashing-monitor analog for a rollup verifier-contract upgrade (the slashing-monitor pattern from Ch 39) is the rollup’s per-cycle proof-acceptance monitor, and what it compares has to be chosen carefully. Feeding one proof to both verifiers tests almost nothing: a change of hash, transcript, parameters or proof encoding normally makes a proof built for one version invalid under the other, so cross-version rejection is the expected result rather than a finding. The monitor instead takes the same public state transition, has a proof generated for each version, and checks that each verifier accepts its own, with the transition window’s version rules deciding which proofs are admissible on chain at all. A disagreement there is a compatibility or completeness problem pending diagnosis: a verifier rejecting a proof of a transition that did happen, or a prover that cannot produce one, both leave the chain refusing valid work. Soundness failure is the opposite event and a much rarer one, a verifier accepting a proof of a state transition that did not happen. The two need separate alarms and separate response paths, because only the second is a soundness break. The first is not therefore harmless: a completeness or compatibility defect an adversary can steer traffic into halts progress on valid work, which is an availability failure and exploitable as one, without any invalid transition ever being accepted.
It closes in end-of-migration with the legacy verifier decommissioned at the close of the transition window. The Ch 30 work-stream owner is the rollup-side governance forum for the decommissioning vote and the rollup core team for the proxy-pointer update that retires the legacy bytecode. The end-of-migration trigger is a stated decommissioning-block on the rollup. After that block, the legacy verifier no longer accepts new proofs.
The transition-window length gates the broad-rollout phase tempo. The chain-governance cadence (the Ethereum All Core Devs forum’s hard-fork tempo from Ch 41) is not the binding constraint there. The transition-window length runs from days (a test-only validation window) to months (a parallel-run window letting the rollup operate under both verifiers, each proving every state transition independently). Any operator-managed switchover that does not force every per-cycle commitment to land under the new verifier in the same activation block follows the transition-window cadence. The four-phase program for the on-chain-verifier surface therefore runs at the rollup-governance cadence rather than at the L1 hard-fork cadence, distinguishing it from the consensus-surface program in Ch 39 that runs at the Ethereum All Core Devs cadence.