Post-Quantum Ethereum Isn't a Crypto Problem - It's a Verification Architecture Problem

The Assumption Nobody Questions

Every Ethereum transaction is authenticated by ECDSA over secp256k1. The security of this construction rests on one assumption: that computing a discrete logarithm over an elliptic curve is hard.

For classical computers, it is. For a sufficiently capable quantum computer running Shor's algorithm, it is not.

Here's the number that should concern you: breaking secp256k1 requires approximately 2,330–3,000 logical qubits. IBM's Condor processor demonstrated 1,121 physical qubits in 2023. The gap is closing on a credible trajectory.

The real threat isn't "a quantum computer breaks Ethereum tomorrow." The real threat is harvest now, decrypt later: adversaries collecting signed transactions today, at zero marginal cost, to exploit once quantum capabilities mature. That window is already open for any account that has ever broadcast a transaction.

The naive fix — swap ECDSA for ML-DSA or FALCON — fails immediately. Not because of cryptography. Because of systems architecture.

The Three Ways PQ Verification Breaks Ethereum's Validation Model

1. Bounded Execution Failure

Ethereum's mempool has a fundamental invariant: verification cost must be bounded for any admissible input. ECDSA via ecrecover satisfies this trivially — it's a precompile at a fixed 3,000 gas.

For ML-DSA-44, the picture is different. The verification algorithm executes Number Theoretic Transform (NTT) arithmetic over a polynomial ring Rq = Zq[X]/(X^n + 1). The dominant cost term is the matrix-vector product Az, requiring k*l polynomial multiplications where (k, l) = (4, 4) for ML-DSA-44.

G_poly >= k*l * 2n * log2(2n) * alpha_mul
       >= 16 × 512 × 9 × 8
        = 589,824 gas (NTT alone)

Add calldata (2,420B signature + 1,312B public key = 59,712 gas at EIP-2028 pricing) and auxiliary hash operations, and you're approaching the gas limit of an entire block for a single signature verification.

More critically: this bound is structural, not incidental. Raising G_max to accommodate ML-DSA-44 at NIST Level 1 recreates the violation at Level 3 (k=l=6) and Level 5 (k=l=8). No fixed gas bound can contain PQ verification across all security levels. This is a theorem, not a configuration problem.

2. Gas Non-Determinism

ERC-4337 bundlers simulate validateUserOp off-chain before inclusion. For ECDSA accounts, simulation is faithful — the ecrecover precompile has zero JIT divergence because it executes outside the EVM interpreter loop.

For Solidity-implemented NTT arithmetic, execution environments diverge. EVM JIT warm-up — where the first invocation of a tight loop incurs compilation overhead — introduces 8–15% gas divergence between off-chain simulation and on-chain execution for 1,024-iteration NTT loops.

The operational consequence: a bundler may include a UserOperation based on simulated gas G_hat(u) <= G_limit, while on-chain execution hits G(u) > G_limit. The transaction fails, but the bundler's deposit still covers the full gas cost. This damages bundler economics in a way that compounds at scale.

3. Adversarial Worst-Case Triggering

For hash-based schemes like SLH-DSA, the Merkle tree traversal path is determined by the signature itself. An adversary cannot forge a valid signature — that would break EU-CMA security. But they can submit structurally well-formed, cryptographically invalid inputs whose verification consumes maximum computation before rejection.

This enables denial-of-service without valid signature forgery: amplify validator workload at negligible signing cost.

These three failure modes are independent. Fixing any one of them does not fix the others.

Benchmark: What PQ Verification Actually Costs

Empirical measurements on a mainnet fork (evmone 0.12, Solidity 0.8.24, optimized compilation):

Scheme	Calldata	Compute	Total	vs. ECDSA
secp256k1 (precompile)	1,024	3,000	~6,000	1×
ML-DSA-44	59,712	1,780,000	~1,840,000	307×
FALCON-512	25,008	965,000	~990,000	165×
SLH-DSA-128f	272,128	349,000	~621,000	104×
ML-DSA-44†	59,712	180,000	~240,000	40×
FALCON-512†	25,008	85,000	~110,000	18×
SLH-DSA-128f†	272,128	20,000	~292,000	49×

† Projected with client-native NTT/hash precompile support

Notice the asymmetry in SLH-DSA-128f: calldata (272,128 gas) dwarfs compute (349,000 gas) because the 16,976-byte signature dominates. Its economic viability depends heavily on calldata pricing improvements — blob-based mechanisms like EIP-4844 become relevant here.

The analytic model for ML-DSA-44 estimates ~600,672 gas purely from arithmetic. Empirical measurement shows ~1,840,000 gas — an overhead factor of 3.06×. This gap is dominated by EVM interpreter dispatch costs per opcode, which arithmetic-only models don't capture.

The Architecture Failure in Existing Approaches

Why ERC-4337 Alone Isn't Enough

ERC-4337 gives you programmable validation via validateUserOp. This is the right deployment surface. But vanilla ERC-4337 has no mechanism for enforcing mempool-safe gas bounds on high-cost verification routines.

Without a typed gas estimator interface, an ML-DSA-44 verifier under vanilla ERC-4337 must set verificationGasLimit by convention — with no formal guarantee that the actual cost is bounded. The bundler inclusion decision is heuristic, not provably safe.

Why ERC-7579 Doesn't Solve It Either

ERC-7579 modular smart accounts allow post-quantum validator modules in principle. In practice:

• No requirement to expose a gas estimator
• No constraint on worst-case verification cost
• No separation between pre-validation and full cryptographic verification
• No enforcement of scheme isolation during validation (a validator module can DELEGATECALL external contracts during signature verification, introducing reentrancy risk outside the EU-CMA security model)

A PQ validator deployed under ERC-7579 inherits all three incompatibilities from Theorem 1.

PQSigAbstract: The Architecture

The core insight is simple but non-obvious: the right fix is not to adjust gas limits. It's to restructure where full verification occurs.

PQSigAbstract introduces a modular verification architecture with four structural properties that jointly ensure mempool safety, gas determinism, commitment security, and EU-CMA preservation.

System Flow

UserOperation submitted
        ↓
  V1: Pre-Validation (mempool)
  ├── CheckFormat (O(1))
  ├── CheckGasLimit via O(1) estimator
  ├── CheckCommitment C = H(pk || m || σ || nonce || addr)
  └── CheckNonce (standard ERC-4337)
        ↓
  [Bundler includes UO — gas bounded, commitment locked]
        ↓
  V2: Full Cryptographic Verification (on-chain)
  └── V_PQ(pk, H(m), σ) — full NTT/hash computation
        ↓
  V1 ∧ V2 = 1 → Transaction valid
  V1 = 1, V2 = 0 → State reverts, penalty gas charged

The Verification Module Interface

Every registered verifier must expose a typed interface with a provably bounded gas estimator:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface IVerificationModule {
    /// Unique scheme id: keccak256(abi.encode(name, version, paramHash))
    function schemeId() external view returns (bytes32);

    /// NIST security level (1-5)
    function securityLevel() external view returns (uint8);

    /// True iff algebraic aggregation is supported
    function supportsAggregation() external view returns (bool);

    /// Gas upper bound — MUST NOT revert, O(1) compute.
    /// Must satisfy gas-soundness and gas-tightness with kappa <= 1.05.
    function estimateGas(uint16 pkLen, uint16 sigLen)
        external pure returns (uint256);

    /// Core verification predicate.
    /// MUST be a view function (no state writes).
    /// MUST NOT call external contracts outside precompiles.
    function verify(
        bytes calldata publicKey,
        bytes32 msgHash,
        bytes calldata signature
    ) external view returns (bool);
}

The estimateGas function is a pure, O(1) computation. Bundlers call it before simulating a UserOperation, enabling early rejection of infeasible operations without executing the full verification routine.

Two invariants are enforced at registration:

Gas Soundness: The estimator must upper-bound actual execution cost for all valid inputs. G_V(pk, ·, σ) ≤ G(|pk|, |σ|) for all pk, σ.

Gas Tightness (κ ≤ 1.05): The estimator cannot over-reserve by more than 5%. Excessive overestimation reduces effective block utilization. For ML-DSA-44, κ ≈ 1.02 is achieved via the closed-form cost model.

Scheme Isolation: The verify function cannot make external calls outside approved precompiles {0x01, ..., 0x08}. This eliminates external-state dependency — a malicious VM cannot invoke attacker-controlled contracts during unrelated UserOperation verification.

Why the Commitment Binding Matters

The two-phase split creates an obvious attack surface: submit a lightweight signature in V1, substitute a heavier one in V2. The commitment prevents this:

C = H(pk || m || σ || nonce || addr)

Any modification to any component invalidates the commitment and causes V1 to reject the modified UserOperation. The nonce binding also prevents replay: a signature valid for nonce n cannot be replayed at nonce n' ≠ n without producing an invalid commitment.

EU-CMA Security Preservation

The two-phase architecture preserves existential unforgeability under chosen-message attacks. The proof is a standard reduction:

V1 accepts no signatures independently — it checks only structure, commitment, and gas. A UserOperation is accepted only when both V1 and V2 return 1. V2 performs the identical full cryptographic verification that a single-phase design would perform.

Therefore: any adversary's advantage against the two-phase protocol equals their advantage against the underlying EU-CMA game for the PQ scheme. The two-phase structure adds no attack surface beyond the underlying scheme.

The Scheme Registry: Versioned, Isolated, Quarantined

The Scheme Registry maintains lifecycle state for each registered verification module:

Proposed → (governance vote) → Quarantine → (t >= t_activate) → Active → (governance vote) → Deprecated

A quarantine period ≥ 30 days is enforced on-chain. During quarantine, accounts may bind to the scheme, but compliant bundlers reject UserOperations that reference it. This gives the ecosystem an observation window to identify vulnerabilities before any accounts depend on the scheme for authentication.

The scheme identifier incorporates the VM bytecode hash:

schemeId = H(schemeName || version || H(VM.bytecode))

A minor VM modification — even a bug fix — produces a distinct schemeId, requiring explicit re-registration. This prevents silent parameter drift where changes in implementation alter verification semantics without being acknowledged.

Account-local binding is maintained in the account's own storage, not the registry:

binding(addr) = {schemeId, pk, schemeId_fallback}

The optional fallback enables graceful degradation. Critically, a registry compromise cannot retroactively alter existing bindings — the registry governs scheme availability but does not control account-level authentication state.

Lazy Probabilistic Aggregation

ERC-4337's IAggregator interface assumes BLS-style algebraic aggregation: n signatures collapse to a constant-size aggregate verifiable in O(1) pairings. ML-DSA and SLH-DSA don't support this — their security constructions bind each signature to its signer-message pair non-linearly.

For non-aggregatable schemes, the lazy aggregation protocol achieves O(√n) amortized on-chain cost:

Step 1 (Commitment): Bundler computes C = H(abi.encode{(pk_i, m_i, σ_i)}_{i=1}^{n}) and posts it on-chain in the bundle header.

Step 2 (Random Sampling): Post-commitment, derive a random seed:

r = H(C || PREVRANDAO || B)

PREVRANDAO (post-Merge randomness beacon) is used rather than BLOCKHASH — the proposer cannot bias it without incurring consensus penalties.

Step 3 (Selective Verification): From r, select a subset S ⊂ [n] of size s = ⌈√n⌉ for on-chain verification. Remaining signatures are provisionally accepted under commitment C, subject to a dispute window Δ_d.

Step 4 (Dispute Resolution): Any participant may challenge an unverified signature during Δ_d. Failed verification triggers a bundler penalty equal to the dispute bond.

The soundness analysis: for a bundle containing m invalid signatures among n total, the probability all m avoid selection is:

ε_lazy = C(n-m, s) / C(n, s)

For the single-invalid-signature case: ε_lazy = 1 - 1/√n. Over k=10 independent bundle rounds with n=16: detection probability ≈ 0.944, requiring a dispute bond ≥ 18× the per-UO forgery profit for economic security.

The dispute window introduces a finality delay. An adversary who predicts which signatures won't be disputed (low-value UserOperations with weak economic incentive to challenge) can exploit this. Δ_d and the bond size must be calibrated jointly.

The EIP-7702 Migration Vulnerability

EIP-7702 requires an ECDSA-signed delegation transaction as the initial step in smart account migration. A quantum-capable adversary observing this in the public mempool can:

1. Recover the ECDSA private key from the delegation signature via Shor's algorithm
2. Construct a competing delegation to an attacker-controlled account
3. Front-run the user's delegation transaction

The commitment-protected migration protocol addresses this:

Phase A (pre-migration): Commit to the future PQ public key on-chain without exposing it:

C_PQ = H(pk_PQ || addr_EOA || salt)

Phase B (delegation): The target account's initialize function verifies:

H(pk_PQ || addr_EOA || salt) == C_PQ

An attacker who recovers the ECDSA private key from the Phase B transaction cannot derive pk_PQ from C_PQ without inverting H. Grover's algorithm provides a quadratic speedup, reducing preimage security from 128 bits to 64 bits — computationally infeasible under current and near-term projected quantum capabilities.

Security Analysis

Attack Surface Enumeration

Attack Vector	Mitigated By	Mechanism
Signature substitution between V1 and V2	Commitment binding	C = H(pk || m || σ || nonce || addr)
Replay across nonces	Nonce in commitment	Standard ERC-4337 nonce + commitment
Adversarial worst-case gas triggering	V1/V2 split	Full verification deferred to gas-bounded V2
DoS via mempool flooding with expensive inputs	Gas-sound estimator	Bundlers reject based on O(1) estimate
Scheme parameter drift	bytecode hash in schemeId	Modification requires explicit re-registration
Registry compromise affecting existing accounts	Account-local binding	Registry controls availability, not auth state
EIP-7702 quantum front-running	Commitment-protected migration	Pre-committed pk_PQ cannot be derived from C_PQ
Lazy aggregation fraud	Dispute bond + PREVRANDAO	Economic penalty exceeds forgery profit

EU-CMA Preservation

The formal security bound: for any PPT adversary A interacting with PQSigAbstract,

Adv^PQSigAbstract_A ≤ Adv^EU-CMA_{Σ,B}

This holds regardless of A's ability to exploit the registry, aggregation protocol, or migration pathway — each component reduces to the security of the underlying PQ scheme.

Trade-Offs

What Works

Immediate deployability: PQSigAbstract requires no consensus rule changes. The VM interface, Scheme Registry, and two-phase validation protocol are all deployable as smart contracts on the existing EVM with full ERC-4337 v0.7 compatibility.

Scheme agnosticism: Any NIST PQC scheme can be registered. ML-DSA for lattice-based security, SLH-DSA for hash-based conservative assumptions, FALCON for compact signatures.

Tiered adoption: At 20 gwei / $2,000 ETH, ML-DSA-44 verification costs ~$0.07 vs. ~$0.0002 for ECDSA. For institutional custodians and DAO governance, this overhead is negligible relative to protected asset values. Consumer adoption waits for PQ precompiles (18–49× ECDSA range).

Forward compatibility: The VM interface's pluggable architecture allows transparent migration to precompile-backed VMs by updating scheme binding — without changing public keys or migrating assets.

What Breaks or Remains Open

Finality delay in lazy aggregation: The dispute window Δ_d introduces latency for unverified signatures. This is a fundamental trade-off of probabilistic verification — not a bug, but a design parameter requiring careful calibration.

Stateless client compatibility: Ethereum's stateless client roadmap (EIP-6800, Verkle trees) requires state witnesses for all accessed storage. Encoding VM parameters in contract bytecode provable via code witnesses restricts dynamic parameter updates.

Quantum-safe address derivation: Ethereum addresses are derived from ECDSA public keys. Accounts that have broadcast at least one transaction expose their public key on-chain permanently. This is distinct from, and arguably more challenging than, PQ signature integration.

Cross-chain consistency: Layer-2 networks differ in mempool policies and gas pricing. Cross-chain VM registry synchronization and unified gas models across rollup environments remain open research questions.

ZK-PQ verification path: Generating a PLONK or Groth16 proof of a valid ML-DSA signature reduces on-chain cost to approximately 300,000 gas — within 50× of ECDSA — at the cost of 200–500ms proof generation latency client-side. The estimateGas and verify functions provide natural integration points for ZK-backed VM implementations, but this direction is not yet specified.

Deployment Trajectory

Near term (deployable today): Reference VM implementations for ML-DSA-44 and FALCON-512 deployed on mainnet, Scheme Registry initialized in quarantine mode. No coordination beyond smart contract deployment.

Medium term (pending PQ precompiles via EIP process): Existing accounts transparently migrate to precompile-backed VMs by updating scheme binding. The 15–20× gas cost reduction in Table II unlocks consumer-scale adoption.

Long term (RIP-7560 native account abstraction): VM interface elevated from application-layer convention to consensus-layer standard. Scheme Registry transitions to a protocol governance mechanism with scheme approval integrated into the EIP process.

Compatibility Matrix

Feature	ERC-4337 v0.6	ERC-4337 v0.7	RIP-7560	EIP-7702	EIP-3074
VM Interface	✓	✓	✓	✓	✗
V1/V2 Split	Partial	✓	✓	N/A	✗
Lazy Aggregation	✓	✓	✓	✗	✗
Scheme Registry	✓	✓	✓	✓	✗
Migration Protocol	N/A	N/A	N/A	✓	✗

EIP-3074 is structurally incompatible: its AUTH opcode hardcodes ECDSA recovery at the EVM level. Supporting PQ schemes in EIP-3074 patterns would require a new AUTH2 opcode accepting a schemeId parameter and delegating verification to the Scheme Registry.

Real-World Applications

Enterprise custody: Institutional custodians deploy AND-mode hybrid verification (ECDSA ∧ PQ) during the transition period. This provides immediate defense against harvest attacks while preserving backward compatibility. Staged-mode policy (defined by governance-specified block heights) allows auditable, scheduled migration to pure PQ without operational disruption.

Layer-2 rollups: PQSigAbstract is compatible with RIP-7560, enabling PQ verification modules on rollup networks without modifications to bridging or fraud proof infrastructure. The VM registry can in principle be synchronized across rollup deployments — a scheme approved on mainnet is automatically recognized by compliant rollup implementations.

Decentralized identity: Identity keys with decade-spanning lifetimes protected only by ECDSA face retrospective quantum compromise — historical transactions exposing public keys are permanently on-chain. The commitment-protected migration protocol allows on-chain key commitments to migrate to PQ public keys without exposing the new key during the transition transaction.

DeFi settlement: Formal EU-CMA preservation (Theorem 3) provides the cryptographic foundation required for security audits of settlement contracts. Lazy probabilistic aggregation reduces verification overhead for high-throughput scenarios to O(√n) amortized cost per bundle.

The Structural Argument

Post-quantum signature adoption in Ethereum is a verification architecture problem, not a cryptographic parameter problem.

The ECDSA precompile succeeds because it co-evolved with the validation model: O(1) group operations, zero JIT divergence, fixed protocol cost. PQ schemes have fundamentally different computational profiles that the existing validation model cannot accommodate.

The correct response is not to raise gas limits or build special-case precompiles for each scheme. It is to restructure the validation pipeline so that mempool admission depends only on gas-bounded structural checks, while full cryptographic verification occurs where the gas accounting model is enforced contractually.

The harvest-now-decrypt-later threat is not speculative. The migration window for long-lived accounts is effectively already open. The verification architecture required for a safe transition should be established before these risks materialize at scale.