Information Brief: Lattice-Based Post-Quantum Signatures for Ethereum
Prepared for the Ethereum Foundation
February 2026 (v1.1)
Executive Summary
Many discussions still confuse ML-KEM (FIPS 203, key encapsulation) with transaction signing. That is a category error.
ML-KEM is for establishing shared secrets (ciphertext + shared key). It cannot sign transactions or provide non-repudiation.
The correct primitives for post-quantum transaction signing are lattice-based signature schemes: primarily ML-DSA (FIPS 204, Dilithium) and — to a lesser extent — FN-DSA (FIPS 206, Falcon).
One finding is consistent across every layer examined (crypto, execution, consensus, L2, P2P, MEV, light clients, mobile, FOCIL, etc.):
ML-DSA-65 signatures are ~50× larger than ECDSA (3,309 bytes vs 64 bytes).
This size jump creates cascading problems for:
- block propagation & uncle rates
- mempool pressure & DoS surface
- state/archive growth
- L2 blob throughput (optimistic rollups lose ~51× tx-per-blob)
- ZK proving time (100–500× circuit cost explosion)
- light-client bandwidth & mobile battery/thermal load
- MEV builder economics
- FOCIL inclusion-list capacity (drops ~98% without fixes)
Without strong mitigations, full post-quantum transaction signing at Ethereum scale becomes economically and technically non-viable.
Three interventions stand out as essential:
- EVM precompiles for ML-DSA verification (~2 M gas → ~50 K gas) — plausible for Hegota (H2 2026) if prioritized soon.
- STARK-based signature aggregation compressing hundreds of signatures into ~100–200 KB verifiable proofs (current leading candidates: Plonky3, RISC Zero, SP1).
- Protocol-layer fixes — FOCIL IL size increase (8 KB → ~400 KB), signature-weight units, P2P compression (index instead of full sig per tx), checkpoint sync, ERC-4337 paymaster gas abstraction, etc.
The EF “Harden the L1” track correctly flags post-quantum security, but the consensus-layer roadmap remains silent on concrete PQC milestones. The reason is simple: efficient post-quantum signature aggregation is still unsolved — and that is currently the binding constraint.
This brief synthesizes the cross-layer reality and offers immediately actionable next steps.
Quick Technical Framing (Corrected)
- ML-KEM → node-to-node encryption, encrypted mempools, hybrid TLS
- ML-DSA / FN-DSA → drop-in replacement for ECDSA/EdDSA transaction & attestation signing
- SLH-DSA → conservative hash-based fallback (much larger)
Recommended starting point: ML-DSA-65 (NIST Level III, ~96-bit quantum security)
High-value / governance keys: ML-DSA-87 (Level V)
FN-DSA-512 (~666-byte signatures) is tempting for size, but Level I quantum security (~64-bit via Grover) makes it unsuitable for long-lived account keys.
Key Impacts & Mitigations (Layer by Layer)
Signature Size (50×)
→ propagation latency, mempool bloat, state growth, L2 blob costs all scale linearly
Mitigations: precompiles, P2P sig compression (send once per block + index), calldata repricing (1 gas/byte for sig fields), post-finality sig pruning
Consensus Layer
BLS: 512 attestations → 48 bytes
Naive ML-DSA: ~1.7 MB/slot
Only realistic path so far: recursive STARK proofs of ML-DSA batch verification (~100–200 KB proofs, ms verification)
Transitional ideas: random committees (128–256 vals) + STARK, or rotated designated aggregator
User Transactions / Account Abstraction
EIP-4337 & EIP-7702 already allow per-account signature schemes
With precompile: ~92 K gas total via 4337 (vs ~21 K today)
Paymasters can sponsor the delta → cost-neutral UX during transition
L2 Rollups
Optimistic → sequencer aggregates → Merkle root on L1 (~100× compression)
ZK → lattice ops in SNARKs explode proving time/cost (100–500×)
Path: move to STARK proving (quantum-safe by design) or keep sig verification off-circuit
Mobile & Light Clients
No hardware PQC in Secure Enclave / StrongBox today (3–5 year gap expected)
Larger sigs break QR codes, eat cellular data, raise battery/thermal load
STARK aggregation is the single biggest mobile/light-client enabler
Censorship Resistance (FOCIL / EIP-7805)
Current 8 KB IL limit → ~2 ML-DSA tx vs ~100 ECDSA
Attester budget (4 s) exceeded without SIMD/precompiles
Pre-Hegota recommendations: ~400 KB IL, signature-weight units, random-sample verification, on-chain censorship telemetry
Security Hardening
Constant-time NTT + masking (for >$100 K stake keys) + TVLA validation mandatory
Cloud staking → prefer Nitro Enclaves / SEV-SNP + bare metal for high-value keys
Migration UX
Tiered urgency (green/yellow/orange/red), one-tap AA migration, cloud/social-recovery backups first, hybrid classical+PQ for high-value accounts during transition
Alignment with EF Roadmap
“Harden the L1” already lists PQC. This brief adds:
- clear ML-KEM vs ML-DSA correction
- quantified cross-layer impacts
- concrete Hegota-era recommendations
- diagnosis of why consensus-layer PQC has no timeline yet (aggregation unsolved)
This is offered in good faith as input to help harden L1 and keep Ethereum secure long-term.
Feel free to use, fork, critique, or ignore any part — the goal is just to move the conversation forward.
What do people think — is aggregation really the blocker, or are there better paths I’m missing?
Should we be pushing harder for precompiles in Hegota, or accept user-layer migration via AA is the realistic 2026–27 path?
Looking forward to the discussion.