Chapter 36: Quantum threat model for blockchains

A blockchain at chain-tip in 2026 is a stack of cryptographic surfaces, not one cryptographic object. Each spend, each block proposal, each address derivation, each on-chain proof, each governance vote sits on a different surface, with a different primitive, a different lifecycle, and a different relationship to the recorded ledger. Saying a chain “uses ECDSA” or “uses BLS” does not pin down the exposure. Each surface inherits a different X (data lifetime), a different Y (migration time), and the same Z (the unknown CRQC arrival modeled in Ch 01). Part VII walks the surfaces in turn and the operator’s migration playbook for each. This chapter sets the threat model and the surface taxonomy that the rest of Part VII threads through.

Two threats specialize to public ledgers. The first is at-rest public-key exposure. Any public verification key recorded on-chain, recoverable from a transaction, reused across protocols, revealed in a script, or otherwise linked to live assets becomes a later Shor target. The signature alone is not the target; the public verification key is, and address formats differ in when they reveal it.

Output or account type	When the verification key becomes visible
P2PKH, P2WPKH	At first spend. Until then the key sits behind HASH160 (RIPEMD-160 of SHA-256), so a once-spent address has revealed it and a never-spent one has not.
P2TR (Taproot)	At output creation. BIP-341 puts the 32-byte Taproot output key in the scriptPubKey and points to BIP-340 for the x-only public-key and Schnorr verification rules (Wuille, Nick, & Ruffing, 2020; Wuille, Nick, & Towns, 2020).
Ethereum externally owned account	At first transaction. The protocol recovers the secp256k1 public key from the signed digest and signature on every spend.

The second threat is the on-spend race. A transaction that first reveals a public key while sitting in the mempool gives a fast-clock CRQC running Shor a race window between broadcast and finality. In that window the CRQC recovers the private scalar in time to front-run the legitimate spend (Aggarwal et al., 2018; Babbush et al., 2026). The first threat is the same Shor break against the discrete-log assumption covered in Ch 04 applied to a static target; the second applies it to a live race.

Bitcoin and Ethereum carry the threat. Bitcoin’s transaction layer checks ECDSA over secp256k1 in legacy and SegWit version 0 spends and BIP-340 Schnorr over the same curve in Taproot spends (Wuille, Nick, & Ruffing, 2020; Wuille, Nick, & Towns, 2020). Ethereum externally owned accounts authorize protocol transactions with ECDSA over secp256k1. Smart-contract wallets and account-abstraction paths (Ethereum Request for Comments, ERC-4337) can introduce custom verification logic, but the dominant base-account model remains secp256k1 ECDSA. The post-merge Ethereum consensus layer signs attestations with BLS over BLS12-381. The two names abbreviate different author lists: BLS is the Boneh-Lynn-Shacham signature scheme, and BLS12-381 is a curve from the Barreto-Lynn-Scott family. Every one of those primitives is Shor-vulnerable. The migration is not a hypothetical. It is the work Part VII walks.

Strand at chain-tip in 2026

The running example is a fictional Layer-1 chain named Strand. The name is fictional to keep the surface taxonomy crisp without pinning every detail to a single deployed protocol. Strand is otherwise unremarkable: a public, permissionless, proof-of-stake chain with a Layer-2 rollup ecosystem, deployed since 2024. The chain threads through the rest of Part VII. Ch 37 migrates the transaction signature and Ch 38 migrates the wallet derivation. Ch 39, Ch 40, and Ch 41 cover the consensus signature, the on-chain verifier, and the governance multisig in turn.

Strand carries five cryptographic surfaces, one per category in the taxonomy below. Four are signatures; the fifth is a proof-verification and hash-parameter surface that the rest of the chapter holds open as a distinct surface type.

Surface	Strand deployment	Primitive at chain-tip 2026
Transaction	Per-spend authorization on every Layer-1 transaction	ECDSA over secp256k1
Consensus	Per-slot attestation by every active validator	BLS over BLS12-381
Wallet	BIP-32 hierarchical deterministic (HD) derivation, ECDSA at the leaf	ECDSA over secp256k1
On-chain verifier	FRI-based STARK verifier contract for a Layer-2 rollup anchored on Strand	SHA-256 inside the FRI commitment
Governance	5-of-9 Schnorr threshold signature on protocol-parameter updates	Schnorr over secp256k1

Three planning scenarios ground the discussion, two of them policy dates and one a hypothetical.

Planning scenario	Date	$Z$ (years from 2026)
NCSC 2025 migration horizon: complete post-quantum migration, no CRQC arrival date named (UK National Cyber Security Centre, 2025)	2035	9
NSM-10 NSS quantum-resistant goal: policy goal for National Security Systems (US National Security Agency, 2024)	2035	9
Hypothetical mid-arrival scenario, used in Part VII for the surfaces with longer migration tails	2040	14

Neither policy date is a probability distribution. Both are deadlines for completing work rather than forecasts of when a CRQC arrives.

The motivating example walks each Strand surface through the Mosca calculation under each Z. The three scenarios reduce to two distinct $Z$ values, and the figure below overlays those two with the X plus Y line for each Strand surface marked. Two of the five surfaces breach the inequality under Z equal to 9 (transaction, wallet); the other three sit inside the migration window under that scenario. Under Z equal to 14, only the transaction surface still breaches. The chapter uses Z equal to 9 and Z equal to 14 as planning stress-test values, not as probability forecasts.

Figure 36.1. Which Strand surfaces breach Mosca's inequality under each scenario. Bars in red breach under both Z values; bars in amber breach under Z equal to 9 only; bars in green sit inside the migration window under both Z values. The axis is drawn at a single scale (8.67 pixels per year), so bar widths can be read directly against the Z markers. The transaction surface sits at the public-ledger archival horizon (50 years here, a fixture cap standing in for keys that are never rotated), so its Mosca window is dominated by X regardless of Y.

Mosca’s inequality on a public ledger

The threat model carries through from Ch 01. The adversary is the offline quantum adversary defined in Ch 01: a large, fault-tolerant, programmable quantum computer with enough logical qubits to run Shor on a 256-bit elliptic-curve discrete log, paired with state-level classical resources for collection and retention. The adversary has been recording every block since the genesis block and continues to record. The knowledge model is unchanged: public algorithm, public ledger, indefinite waiting time.

Mosca’s inequality, restated (Mosca, 2018), gives the migration urgency. Let $X$ be the data lifetime in years, $Y$ the migration time in years, and $Z$ the years until a CRQC arrives. The asset is exposed when

X + Y > Z.

The exposure window in years is $\max(X + Y - Z, 0)$ .

For a generic enterprise asset (covered in Ch 01), $X$ is bounded by the data-retention policy and the deprecation cadence of the deploying organization. For a blockchain transaction signature on a public ledger, $X$ is bounded only by what an attacker can archive, not by what every node retains. Ordinary Bitcoin nodes may prune (BIP-159 pruned mode) and Ethereum has been moving toward history expiry under proposals such as EIP-4444. Explorers, archival services, indexers, researchers, and adversaries can retain public-key exposures indefinitely regardless. Once a public verification key is on the public ledger, $X$ for the exposure layer is bounded only by how long the attacker chooses to wait.

The blockchain specialization of Mosca’s inequality therefore reads $X$ in two layers. The exposure lifetime is how long the public key remains observable to an attacker, which is effectively unbounded once on-chain. The value lifetime is how long that key still controls assets, authority, or consensus weight. $Y$ remains the network-wide migration coordination time (limited by hard-fork cadence and validator-set rotation), and $Z$ is the same Z that grounds Part I.

The signature game also carries through. EUF-CMA, defined in Ch 06, gives the adversary adaptive query access to a signing oracle and asks for a forgery on any unsigned message. The public-ledger specialization is sharper than the generic case: a public ledger is the signing oracle’s transcript, and the adversary has read access to every signature ever recorded under each public verification key. The chain itself is the transcript. The adversary does not need to query a live oracle. The key recovery itself runs on the public verification key, not on the signature in isolation. Once Shor recovers the private scalar from a public key the adversary observed on-chain, every prior message under that key forges trivially. Every future message until the key is rotated forges as well.

Under the classical adversary, ECDLP hardness keeps the private scalar out of reach and the EUF-CMA game is sound. Under the quantum adversary, Shor recovers the private scalar in polynomial time and the EUF-CMA forgery is constructive. Mosca’s inequality on a public ledger therefore measures two windows. The live forgery window is the $Y$ part: how long unmigrated signers continue to sign. The recorded forgery window is the exposure part of $X$ : how far back the chain’s history reaches for keys that are still value-relevant.

The five surfaces

A generic blockchain at chain-tip in 2026 carries five cryptographic surfaces. Each surface deploys a different primitive, sits at a different point in the lifecycle, and inherits a different X. Four of the five are signatures. The fifth (the on-chain verifier) is a proof-verification and hash-parameter surface and is included in the taxonomy because it inherits the same operator-migration framing.

The classifier is a lookup, not a derivation. The chapter package’s classify_all walks a list of asset records, reads the primitive field, and returns the quantum-vulnerability class.

# Block 1: pedagogical slice of blockchain_threat.surface_taxonomy.classify_all (stdlib only).
PRIMITIVE_CLASSIFICATION = {
    "ECDSA-secp256k1":   "shor-vulnerable",
    "Schnorr-secp256k1": "shor-vulnerable",
    "BLS-BLS12-381":     "shor-vulnerable",
    "EdDSA-Ed25519":     "shor-vulnerable",
    "SHA-256":           "hash-quantum-degraded",
    "ML-DSA-65":         "post-quantum-standardized",
    "SLH-DSA-128s":      "post-quantum-standardized",
}

STRAND_ASSETS = [
    {"surface": "transaction",       "primitive": "ECDSA-secp256k1"},
    {"surface": "consensus",         "primitive": "BLS-BLS12-381"},
    {"surface": "wallet",            "primitive": "ECDSA-secp256k1"},
    {"surface": "on-chain-verifier", "primitive": "SHA-256"},
    {"surface": "governance",        "primitive": "Schnorr-secp256k1"},
]


def classify(asset):
    primitive = asset["primitive"]
    assert primitive in PRIMITIVE_CLASSIFICATION, f"unknown primitive: {primitive!r}"
    return PRIMITIVE_CLASSIFICATION[primitive]


for asset in STRAND_ASSETS:
    print(f"{asset['surface']:<18} {asset['primitive']:<19} {classify(asset)}")
# ==> transaction        ECDSA-secp256k1     shor-vulnerable
# ==> consensus          BLS-BLS12-381       shor-vulnerable
# ==> wallet             ECDSA-secp256k1     shor-vulnerable
# ==> on-chain-verifier  SHA-256             hash-quantum-degraded
# ==> governance         Schnorr-secp256k1   shor-vulnerable

Every Python block this chapter prints is also a standalone file in the companion repository, under chapter-code/ch36/, one file per block. Appendix C covers the clone and the environment they run on.

Four of the five Strand surfaces are Shor-vulnerable; the fifth is hash-quantum-degraded (Grover lowers the effective security level but does not yield a polynomial-time break, and Brassard-Høyer-Tapp lowers collision resistance to roughly $2^{n/3}$ queries in the quantum-accessible-memory model). See the Cryptanalysis section below. The four Shor-vulnerable surfaces are the migration target for Part VII. The hash-quantum-degraded surface (the on-chain verifier) is a parameter-bump candidate, not a primitive swap.

The Mosca window for each surface is the second pedagogical block. The function evaluates $\max(X + Y - Z, 0)$ given non-negative-integer inputs.

# Block 2: pedagogical slice of blockchain_threat.mosca_window.evaluate (stdlib only).

# Z = 9 models a 2035 planning scenario measured from 2026. NCSC and
# NSM-10 / CNSA 2.0 use 2035 as a migration deadline, not as a
# predicted CRQC arrival date.
Z_2035_PLANNING = 9

STRAND_XY = [
    ("transaction",       50, 5),
    ("consensus",          2, 1),
    ("wallet",            10, 4),
    ("on-chain-verifier",  3, 2),
    ("governance",         4, 3),
]


def mosca_window(x, y, z):
    assert x >= 0 and y >= 0 and z >= 0
    breach = x + y - z
    return breach if breach > 0 else 0


for surface, x, y in STRAND_XY:
    window = mosca_window(x, y, Z_2035_PLANNING)
    flag = "BREACH" if window > 0 else "ok"
    print(f"{surface:<18} X={x:>2} Y={y:>2} Z={Z_2035_PLANNING:>2}  window={window:>2}  {flag}")
# ==> transaction        X=50 Y= 5 Z= 9  window=46  BREACH
# ==> consensus          X= 2 Y= 1 Z= 9  window= 0  ok
# ==> wallet             X=10 Y= 4 Z= 9  window= 5  BREACH
# ==> on-chain-verifier  X= 3 Y= 2 Z= 9  window= 0  ok
# ==> governance         X= 4 Y= 3 Z= 9  window= 0  ok

Two of the five Strand surfaces breach the inequality under Z equal to 9: the transaction surface (window 46) and the wallet surface (window 5). The other three sit inside the migration window. The transaction surface is the dominant exposure regardless of Z because its X is bounded only by the lifetime of holdings whose keys are never rotated. The wallet surface’s exposure is shorter but still nonzero, driven by the assumption that an HD-wallet master seed remains in use for ten years before rotation.

The five surfaces in turn:

Transaction signatures

Per-spend or per-state-update signature on a Layer-1 transaction. Bitcoin checks ECDSA over secp256k1 in legacy and SegWit version 0 spends and BIP-340 Schnorr over the same curve in Taproot spends (Wuille, Nick, & Ruffing, 2020). Ethereum signs every transaction with ECDSA over secp256k1. Both are Shor-vulnerable. The exposure-lifetime $X$ is the chain’s archival horizon: every public verification key revealed on-chain sits in the ledger or in adversary archives indefinitely, observable by anyone running an archive node or scraping a block explorer. Exposure alone is not the risk. Value lifetime is. What makes the transaction surface’s $X$ unbounded for a chain is that a chain cannot rotate its holders’ keys: dormant and lost holdings, and any address a holder never migrates, keep exposed keys value-relevant for as long as the ledger exists. The Strand fixture caps that at 50 years so the arithmetic has a number, and the cap is a planning assumption rather than a measurement.

The forgery against this surface attacks any address whose public verification key is exposed on-chain. A CRQC in 2035 can take any once-exposed public key and forge new transactions that the chain accepts as valid spends from that key. The exposed key may sit in a P2PK output, a once-spent P2PKH or P2WPKH address, a Taproot output key, or an Ethereum externally owned account that has transacted. The recovery uses Shor on the public key, not on the signature in isolation. If the key still controls funds in 2035, the funds are at immediate risk. If the key was rotated and emptied before 2035, the historical exposure leaks the secret but no live funds remain.

An address that has only ever received funds in a P2PKH or P2WPKH output and has never spent keeps its public key hidden behind HASH160 (RIPEMD-160 of SHA-256). That blocks the direct Shor-on-public-key attack until first spend. It does not provide a full 256-bit hash margin: HASH160 has a 160-bit output, so generic quantum preimage search against it is roughly $2^{80}$ Grover queries rather than $2^{128}$ . The more immediate transaction-layer risk remains the on-spend race when the public key is first revealed. The Tradeoffs section below covers the rotation tradeoffs. Ch 37 covers the migration playbook.

Consensus signatures

Per-slot attestation by every active validator in a proof-of-stake system, or block-proposer signature in a leader-based protocol. Ethereum post-merge signs attestations with BLS over BLS12-381. The aggregation property of BLS is the core efficiency: tens of thousands of attestations aggregate into one constant-size signature per slot, and the verifier checks one pairing equation. A Shor break on the underlying pairing-based assumption breaks the aggregated signature along with the per-validator signature (Shor, 1994). The entire BLS construction is Shor-vulnerable.

Consensus signatures have short message relevance but not necessarily short key lifetime. Ethereum validators sign attestations every epoch with long-lived validator BLS signing keys that remain registered in the validator set until exit. Old attestations lose consensus relevance quickly (finality is reached and the slashing window closes), but a recovered validator key remains economically relevant for the rest of that validator’s active period. The $X$ used in the Strand running example (2 years) is therefore a value-relevance horizon, keyed to validator-set rotation and exit cadence under churn-limited withdrawals, not a per-epoch attestation lifetime.

The stack-of-surfaces framing applies even within the consensus surface itself. In Ethereum’s design, the validator’s BLS signing key (used for attestations and slashing) is distinct from the withdrawal credentials that control the underlying staked ETH. The withdrawal credentials typically name a separate secp256k1 execution-layer address, either in the original execution-address form or in the compounding form the EIP-7251 max-effective-balance design added. Validators that never updated still carry the legacy hashed-BLS credential. A Shor break on the BLS validator key grants control of consensus weight and slashable behavior. The staked principal sits on a different cryptographic surface and migrates on its own timeline.

The migration time $Y$ is also short, because the consensus protocol is the most active consensus-rule change point in any chain. Ch 39 covers the post-quantum candidates and the aggregation tradeoff. The post-quantum candidates currently aggregate poorly.

Wallet and key-rotation signatures

The signature primitive used inside the wallet, including HD derivation and address rotation. Bitcoin wallets commonly use BIP-32-style HD derivation, the canonical Bitcoin HD-wallet standard, with BIP-39 mnemonic seeds and BIP-44 path conventions on top. Ethereum wallets and custody stacks commonly use the same BIP-32 / BIP-39 / BIP-44 derivation pattern in practice, but the Ethereum protocol does not require a specific HD scheme. The leaf signs with ECDSA over secp256k1 in both ecosystems. The seed is the long-lived secret. Addresses derived under it inherit the same vulnerability.

The $X$ for a wallet is bounded by the seed’s lifetime. A custody operator rotates seeds rarely (years to decades for cold storage) and frequently (per address, per session) for hot wallets. Stateful hash-based signatures (XMSS in Ch 15) carry a state-management constraint that rules out any custody shape replicating one key’s state across devices, because independent copies of the same key cannot reliably coordinate a one-time-key index. Shapes where each signer keeps its own counter inside a single device, hardware-only cold storage and independent-key multisig cold, remain viable. SLH-DSA (Ch 17) removes the state requirement and is attractive where statelessness and conservative hash-based assumptions dominate. ML-DSA is likely the practical baseline where signature size and verification cost dominate the user experience and the per-transaction fee. The right candidate is surface-specific. Ch 38 covers the wallet-rotation specifics.

On-chain verifier

The on-chain verifier is not itself a signature surface. It is a proof-verification and hash-parameter surface: a smart-contract function that checks a cryptographic proof submitted by a third party. The proof is typically a SNARK or a STARK. The verifier contract is part of the deployed protocol. Strand’s verifier checks FRI-based STARK proofs of state transitions for a Layer-2 rollup anchored on the Layer-1 chain. The verifier hashes inputs with SHA-256, which Grover degrades but does not break. The relevant cost is the Brassard-Høyer-Tapp collision bound rather than full preimage recovery. The proof system itself (the FRI-based STARK) is the Part VI subject. Ch 34 walks the construction, and Ch 35 places a deployed instance of the same shape, Starknet’s on-chain verifier, on the (L2 x L4) grid and computes its bit margin.

The $X$ for a verifier contract is the active-verifier horizon: how long the deployed parameter set and proof-system instantiation remain authoritative before a parameter bump or proof-system swap is required. Old accepted proofs remain part of history but do not leak a signing secret. The forward risk is false future proof acceptance while the verifier remains the authoritative checker. The $Y$ is the on-chain upgrade cadence: smart contracts are immutable by default, so a verifier swap requires a hard fork or a contract-replacement deploy. Ch 40 covers the operator’s playbook for both paths.

Governance signatures

Multisig, threshold, or validator-set rotation signatures used to authorize protocol-parameter updates, fee changes, or treasury decisions. Strand uses a 5-of-9 Schnorr threshold signature over secp256k1. Bitcoin uses multisig P2SH and P2WSH outputs for treasury custody; Ethereum uses smart-contract multisig (Gnosis Safe and similar). Every classical instantiation is Shor-vulnerable.

The X for a governance signature is bounded by the rotation cadence of the governing key set. The Y is bounded by the multi-stakeholder coordination overhead, which is typically the longest of any blockchain migration step. Ch 41 covers the hard-fork mechanics and case studies.

The five surfaces map back to the Ch 25 five-touchpoint CBOM at the surface level (each surface is a touchpoint type) and to the Ch 30 four-phase migration program at the timeline level (discovery, first-wave, broad-rollout, end-of-migration).

The figure below maps the five surfaces around a chain-tip block, with quantum-vulnerability shading per surface.

Figure 36.2. Which primitive each Strand surface deploys, and which quantum attack reaches it. The four red surfaces are Shor-vulnerable and need a primitive swap; the amber surface is hash-quantum-degraded (Grover and Brassard-Høyer-Tapp lower the effective security level but do not yield a polynomial-time break) and is a parameter-bump candidate. Vulnerability class is not migration order, and the figure does not encode urgency: two of the four red surfaces, consensus and governance, sit inside the migration window under Z equal to 9. Each surface inherits a different X, a different Y, and the same Z from Ch 01. The Mosca figure above is what ranks them.

Cryptanalysis: four attack categories

The taxonomy of quantum attacks against the blockchain surfaces groups into four categories.

The first category is the signature break: Shor against any discrete-log signature. ECDSA over secp256k1, Schnorr over secp256k1, and EdDSA over Ed25519 rely on elliptic-curve discrete-log hardness; BLS over BLS12-381 relies on pairing-based hardness assumptions in a pairing-friendly elliptic-curve group. Shor’s discrete-log algorithm runs in polynomial time on the curve subgroups used by all four families (Shor, 1994), so a CRQC recovers the private scalar in each case. The signature break attacks the transaction, consensus, wallet, and governance surfaces of the running example. The mitigation is a primitive swap to a post-quantum signature: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), or a stateful hash-based scheme like XMSS for surfaces with state-management tolerance. Ch 37 through Ch 39 and Ch 41 cover the per-surface playbook.

The second category is the hash break: quantum attacks against the hashes used inside block headers, Merkle trees, address derivation, and proof systems. Grover gives a square-root speedup for unstructured preimage search, so SHA-256’s quantum preimage cost falls to about $2^{128}$ ideal serial hash queries rather than $2^{256}$ (Grover, 1996). Quantum collision search follows the Brassard-Høyer-Tapp bound of roughly $2^{n/3}$ queries for an $n$ -bit hash output, so SHA-256 collision search sits around $2^{85.3}$ quantum queries, with about as many entries of quantum-accessible memory, rather than the classical $2^{128}$ birthday bound (Brassard et al., 1998). The hash break does not break the chain; it lowers the effective security level. The mitigation is a parameter bump (SHA-512 or SHA3-512 in place of SHA-256, or a longer Merkle tag) rather than a primitive swap. The hash break is the dominant concern only on the on-chain verifier surface, where the FRI commitment relies on the underlying hash’s collision resistance.

The third category is the KEM break: Shor against any key-encapsulation mechanism in the operator’s stack. Current production blockchain designs do not deploy KEMs as an on-chain validity primitive: the ledger rules for block validity, block production, and consensus signing do not depend on a KEM. The KEM break is therefore out of scope for the on-chain surface taxonomy below. It is not out of scope for blockchain operations as a whole. Node-to-node transport (Ethereum’s RLPx, libp2p, TLS for RPC, Noise framings between custody devices), RPC infrastructure, custody-system encryption, and bridge or relayer operations all carry KEM or key-agreement primitives that belong in the operator’s CBOM as a separate off-chain surface. Their migration tracks the Ch 28 TLS playbook and is independent of the on-chain primitives.

The fourth category is the proof-system break: a quantum attack against the on-chain verifier’s proof system. Pairing-based SNARK deployments such as Groth16, and PLONK-family systems instantiated with KZG polynomial commitments over BN254 or BLS12-381, are Shor-vulnerable through their pairing-friendly curve assumptions. PLONK-style arithmetizations instantiated with transparent hash-based commitments have a different quantum profile and follow the FRI-STARK analysis instead. Hash-based proof systems (FRI-based STARKs, transparent SNARKs over hash commitments) are post-quantum candidates, with caveats on the Fiat-Shamir transform’s QROM security analyzed in Part VI. Ch 40 walks the operator’s migration playbook for the on-chain verifier. Part VI covers the underlying protocol theory. The proof-system break is bounded above by the underlying primitive break: a Shor break on the pairing breaks every KZG-PLONK or Groth16 verifier on the chain regardless of what the verifier contract does.

Tradeoffs

For a chain-level operator the transaction surface is the first-wave target regardless of how the other four cost axes compare, because the chain cannot bound its holders’ key lifetimes and the Mosca window is dominated by $X$ . An operator who controls every key on the surface (a custodian, an exchange) inherits the wallet surface’s rotational $X$ instead, and ranks by the same arithmetic with that input. Each surface trades off differently against four cost axes. Ledger permanence asks whether public-key exposure or active-verifier authority is bounded by rotation or runs forever. Hard-fork cost asks which consensus-rule change is required. Key-rotation friction asks how often the surface’s key set turns over. Gas-cost impact asks the per-verification cost in gas or the equivalent fee unit. The table below pairs each surface with the relevant axes. The entries describe Strand’s assumed migration path, and Bitcoin- or Ethereum-specific fork mechanics are called out where they diverge.

Surface	Ledger permanence	Hard-fork cost	Key-rotation friction	Gas-cost impact
Transaction	Public-key exposure: forever (archival). Funds-at-risk: until rotation.	UTXO-style (Bitcoin): soft fork that adds a long-exposure-resistant output type alongside the existing ones, per the BIP-360 P2MR draft. Account-model (Ethereum): protocol-level signature change, account abstraction, or smart-wallet validation path.	Per address; per spend if account model	High (PQ verification cost is a per-transaction tax)
Consensus	Message relevance per epoch. Validator key lifetime spans the validator’s active period	Hard fork (consensus-rule change)	Per validator-set rotation	Off-chain (validator client cost, not gas)
Wallet	Tied to seed lifetime	None on-chain (off-chain client change)	Per address derivation	None on-chain
On-chain verifier	Active-verifier lifetime (forward-risk only: old accepted proofs do not leak secrets)	Soft fork or contract-replacement deploy	Per parameter set	High (proof verification dominates rollup gas cost)
Governance	Per multisig rotation	Multi-stakeholder coordination	Per rotation cadence	Moderate (per governance vote)

The four cost axes do not align. The transaction surface carries the longest exposure-lifetime $X$ but, in the UTXO model, needs no hard fork at all: a soft-fork output-type proposal such as BIP-360’s P2MR design (Beast et al., 2024). BIP-360 by itself reduces long-exposure public-key risk by changing how outputs commit to spending conditions. It is not a complete post-quantum signature migration, and short-exposure / on-spend protection requires a separate quantum-resistant signature proposal alongside it. Account-model chains (Ethereum) do not get the UTXO output-type shortcut and need a protocol-level signature change, account abstraction, or smart-wallet validation.

The consensus surface carries short message-relevance but a long-lived validator BLS key, and the most expensive hard-fork path, because a consensus-rule change requires every node to adopt simultaneously. Wallet migration has no on-chain cost. User-facing friction is the constraint. The on-chain verifier is the gas-cost bottleneck: PQ proof verification is currently a leading gas-cost contributor in deployed STARK rollups, and Ch 40 quantifies the per-proof cost on Strand. Governance is moderate on every axis because it is the slowest-moving surface by design.

The deciding tradeoff is between ledger permanence and hard-fork cost. The transaction surface inherits effectively unbounded exposure-lifetime $X$ and forces the operator to migrate before $Z$ regardless of $Y$ . The on-chain verifier inherits permanent history but a bounded active-verifier $X$ : old accepted proofs remain on-chain but do not leak a signing secret, and the forward risk is false future proof acceptance while the verifier remains authoritative. Surfaces with rotational $X$ (consensus, wallet, governance) bound exposure-lifetime by the rotation cadence and let the operator size $Y$ against a known $Z$ . The first wave of a chain’s migration is the transaction surface, regardless of how cheap any other surface looks under the cost-axis comparison, because it is the one surface whose $X$ the chain’s governance cannot shorten by rotation.

Exercises

Mosca compute under Strand consensus. Strand’s consensus surface deploys BLS over BLS12-381. Use the chapter’s running-example values $X = 2$ and $Y = 1$ . Compute Mosca’s inequality under $Z$ equal to 9 (NCSC 2035) and confirm the consensus surface does not breach. Then compute under an aggressive early-CRQC scenario at $Z$ equal to 2 and report the breach window.
Surface taxonomy on a fictional rollup. A fictional Layer-2 rollup anchored on Strand has three surfaces: a STARK verifier contract (SHA-256 inside FRI), an operator-key signature on every state-update batch (Ed25519), and a validator-set signature on operator-key rotations (BLS over BLS12-381). Apply the surface taxonomy to each. State which surfaces are first-wave, which are second-wave, and which are parameter-bump candidates.
Open-ended classification. Take the table of primitives in the chapter package’s PRIMITIVE_CLASSIFICATION lookup and sort each into one of three buckets: (a) deployed on Bitcoin or Ethereum at chain-tip in 2026, (b) standardized as a NIST PQC algorithm, (c) neither. State your classification and the source you used.
Rank-order migration urgency. Take the Strand five-surface running example and rank-order the surfaces by migration urgency under $Z$ equal to 9. Justify each position with the surface’s $X$ and $Y$ values from the chapter, and name the dominant cost axis for the top three.
Map to the CBOM and the program. Map each Strand surface to a Ch 25 CBOM touchpoint type and to a Ch 30 four-phase program phase (discovery, first-wave, broad-rollout, end-of-migration). Justify each mapping in one sentence.

The chapter package at solutions/ch36-blockchain-threat-model and the test suite at tests/ch36 ground the running example and the two computations the exercises reuse. Solutions to Exercises 1, 2, and 4 are in Appendix D, Chapter 36. Exercises 3 and 5 are open-ended and have editorial-note treatments rather than worked answers.

A separate track, for rebuilding rather than reading: the package exercises/ch36-blockchain-threat-model has every function the chapter teaches replaced by a stub. Run PQC_IMPL=exercises pytest tests/ch36 to grade your version against the suite that proves the reference one.

References

Aggarwal, D., Brennen, G. K., Lee, T., Santha, M., & Tomamichel, M. (2018). Quantum Attacks on Bitcoin, and How to Protect Against Them. Ledger, 3, 68–90. https://doi.org/10.5195/ledger.2018.127

Babbush, R., Zalcman, A., Gidney, C., Broughton, M., Khattar, T., Neven, H., Bergamaschi, T., Drake, J., & Boneh, D. (2026). Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations. PRX Quantum, 7(3), 031001. https://doi.org/10.1103/j3xf-bw18

Beast, H., Heilman, E., & Foxen Duke, I. (2024). BIP-360: Pay-to-Merkle-Root (P2MR). Bitcoin Improvement Proposal (Draft). https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki

Brassard, G., Høyer, P., & Tapp, A. (1998). Quantum Cryptanalysis of Hash and Claw-Free Functions. LATIN ’98: Theoretical Informatics, 1380, 163–169. https://doi.org/10.1007/bfb0054319

Grover, L. K. (1996). A fast quantum mechanical algorithm for database search. Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC), 212–219. https://doi.org/10.1145/237814.237866

Mosca, M. (2018). Cybersecurity in an era with quantum computers: will we be ready? IEEE Security & Privacy, 16(5), 38–41. https://doi.org/10.1109/MSP.2018.3761723

Shor, P. W. (1994). Algorithms for quantum computation: discrete logarithms and factoring. Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), 124–134. https://doi.org/10.1109/SFCS.1994.365700

UK National Cyber Security Centre. (2025). Timelines for migration to post-quantum cryptography. NCSC guidance. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines

US National Security Agency. (2024). Commercial National Security Algorithm Suite 2.0 Frequently Asked Questions, Version 2.1. NSA Cybersecurity Advisory. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

Wuille, P., Nick, J., & Ruffing, T. (2020). BIP-340: Schnorr Signatures for secp256k1. Bitcoin Improvement Proposal. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

Wuille, P., Nick, J., & Towns, A. (2020). BIP-341: Taproot: SegWit version 1 spending rules. Bitcoin Improvement Proposal. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

Last updated: Sep 15, 2026