Appendix D: Solutions for Chapter 36

This page collects solutions and editorial notes for the exercises in Chapter 36: Quantum threat model for blockchains. Compute and derivation 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 blockchain_threat package under solutions/ch36-blockchain-threat-model. From a clone of the companion repository, pytest tests/ch36 runs its suite. Appendix C has the setup.

Exercise 1

Worked solution. Mosca’s inequality is $X + Y > Z$, with the exposure window $\max(X + Y - Z, 0)$.

Under the running example $X = 2$, $Y = 1$, $Z = 9$:

$$X + Y = 3, \quad Z = 9, \quad \text{breach} = \max(3 - 9, 0) = 0.$$

The consensus surface does not breach, and the Mosca budget has six years of slack: $Z - (X + Y) = 6$. That is the margin left after allowing for both the migration time and the required protection lifetime, not the gap between finishing migration and $Z$. Migration alone takes $Y = 1$ year, so it would complete eight years before $Z$. NCSC 2035 sets a planning horizon, not a predicted CRQC arrival date.

Under the aggressive early-CRQC scenario $X = 2$, $Y = 1$, $Z = 2$:

$$X + Y = 3, \quad Z = 2, \quad \text{breach} = \max(3 - 2, 0) = 1.$$

The consensus surface breaches by one year. The result is consistent with the chapter’s narrative. The consensus surface inherits the shortest $X$ of any Strand surface (validator-set rotation cadence) and the cheapest $Y$ (a hard fork is the active consensus-rule change point). It is therefore the surface with the most slack against $Z$. Even so, an aggressive $Z$ that drops below the surface’s $X + Y$ produces a positive window.

Exercise 2

Worked solution. Apply surface_taxonomy.classify to each:

• STARK verifier contract, SHA-256 in FRI. SHA-256 is hash-quantum-degraded. The verifier is therefore a parameter-bump candidate: the operator swaps SHA-256 for SHA-512 (or extends the Merkle tag size) when the security margin against Brassard-Høyer-Tapp collision search is no longer comfortable.
• Operator-key signature on every state-update batch, Ed25519. Ed25519 is shor-vulnerable (EdDSA over a Shor-reducible group). The operator-key signature is a first-wave migration target.
• Validator-set signature on operator-key rotations, BLS-BLS12-381. BLS over BLS12-381 is shor-vulnerable. The validator-set signature is also a first-wave target.

Wave assignment:

• First wave: operator-key signature, validator-set signature. Both are Shor-vulnerable on a public ledger and carry public exposure.
• Second wave: not applicable in this rollup. Both Shor-vulnerable surfaces are first wave.
• Parameter-bump candidate: STARK verifier contract.

The operator’s first-wave plan therefore migrates the two signature primitives in parallel and defers the FRI parameter bump to the second wave or to the next routine verifier-contract upgrade.

Exercise 3

Editorial note. A defensible classification names a primary source per primitive. NIST FIPS 203, 204, and 205 cover the standardized PQ algorithms. The Bitcoin and Ethereum protocol specifications cover the deployed primitives. A strong answer resists the temptation to put every PQ algorithm into “standardized at NIST” without checking the actual standard.

A strong answer also notes two scoping points. First, not every primitive in the lookup table is deployed on Bitcoin or Ethereum at chain-tip in 2026. EdDSA-Ed25519 is widely deployed but not on Bitcoin Layer-1 transactions. BLS-BLS12-381 is deployed on Ethereum staking but not on Bitcoin. Second, not every NIST-standardized PQ algorithm is appropriate for the on-chain transaction surface. XMSS-MT and LMS carry state-management constraints that fail the BIP-32-style derivation pattern.

Exercise 4

Worked solution. Under $Z = 9$, the chapter’s running example gives the per-surface breach window:

Rank	Surface	$X$	$Y$	$X+Y$	Breach window
1	transaction	50	5	55	46 years
2	wallet	10	4	14	5 years
3	governance	4	3	7	0
4	on-chain verifier	3	2	5	0
5	consensus	2	1	3	0

Rank 1 (transaction) is the dominant migration urgency: $X$ is bounded only by the lifetime of holdings whose keys are never rotated, so the breach window is dominated by the chain’s permanence rather than by $Y$. The dominant cost axis is gas-cost impact (PQ verification cost is a per-transaction tax on every spend).

Rank 2 (wallet) has positive breach window even though $X$ is bounded by seed lifetime, because typical seeds last a decade and the migration time across a custody operator’s full address book is several years. The dominant cost axis is key-rotation friction (every derived address must rotate to a PQ scheme).

Rank 3 (governance) does not breach under $Z = 9$ but is the first surface to start breaching under stricter $Z$. The dominant cost axis is multi-stakeholder coordination (the governance set is the slowest-moving by design).

Ranks 4 and 5 (on-chain verifier and consensus) sit comfortably inside the migration window under $Z = 9$ and are deferred until after the first-wave transaction and wallet migrations land.

Exercise 5

Editorial note. A defensible mapping pairs each surface with a CBOM touchpoint type. Transaction signature maps to an application-layer signing touchpoint. Consensus signature maps to an infrastructure-layer signing touchpoint. Wallet maps to a key-management touchpoint. On-chain verifier maps to an application-layer signing touchpoint with a proof-system attribute. Governance maps to a governance-layer signing touchpoint.

A defensible mapping also pairs each surface with a Ch 30 program phase. Transaction and wallet sit in first-wave, since both breach under $Z = 9$. The on-chain verifier is a parameter-bump candidate whose Mosca window clears under $Z = 9$, so it sits in broad-rollout with the next routine verifier upgrade. The wallet rollout then runs on every custody operator’s own timeline. Consensus and governance sit in broad-rollout because they require hard-fork coordination across the full network.

The trap is treating high-profile or high-value surfaces as first-wave when their rotational $X$ keeps them inside the migration window under $Z$ equal to 9. The program-management framing in Ch 30 is precisely about resisting that simplification. Broad-rollout surfaces have margin against $Z$ that the first-wave surfaces do not.