Summary
This proposal introduces post-quantum signature aggregation with leanVM in shadow mode. BLS remains the only authority for aggregates: consensus validity depends on BLS alone, exactly as today. leanVM aggregates and proofs are produced and verified alongside BLS, but their results have no effect on consensus. They are only measured, compared, and reported. When PQ/AI day arrives, an emergency hard fork simply retires BLS and enables leanVM in full.
By “PQ/AI day” we mean the point at which quantum computers, or AI-assisted cryptanalysis, make BLS unsafe to rely on.
Motivation
Ethereum has to be ready for post-quantum signatures well before BLS is actually broken. Waiting until the last moment would mean deploying new, complex code to mainnet in a hurry. Giving leanVM authority early has its own risk: leanVM is new code that hasn’t been tested in production. However carefully it is built and audited, we can’t rule out a soundness bug that accepts an invalid proof, or a liveness bug that rejects a valid one.
The main benefit of shadow mode is that Ethereum isn’t put at risk from a leanVM bug before PQ/AI day arrives. Because leanVM has no authority, a leanVM bug can’t break Ethereum’s security or halt the chain. At the same time, leanVM runs on mainnet under real load, so by the time it needs authority it is battle-tested code rather than something enabled in a hurry.
Specification (high level)
- Validators produce both a BLS signature and a post-quantum hash-based signature.
- Aggregators produce both a BLS aggregate and a leanVM aggregate proof.
- Consensus validity is determined only by BLS. A missing, invalid, or late leanVM proof never makes a block or attestation invalid.
- Clients verify leanVM proofs and record the result. Any disagreement between leanVM and BLS is logged and exposed through metrics.
- When PQ/AI day arrives, an emergency hard fork simply retires BLS and enables leanVM in full. Because leanVM has already been running on mainnet in shadow mode, this fork only switches authority and does not deploy new cryptography.
Details of signature formats, proof propagation, and networking will follow
Rationale
Shadow mode gives us mainnet-grade testing of leanVM at no cost to consensus
- Clients gain operational experience with leanVM under real load and advers
- Every disagreement between leanVM and BLS is a concrete bug report, found before it can do damage.
- Researchers and auditors can keep scrutinizing leanVM while BLS still prot
- Performance, proof size, and bandwidth can be measured on real traffic before any parameters are locked in.
Until PQ/AI day, Ethereum’s security is exactly what it is today. After PQ/AI day, the network relies on a system that has already processed years of real mainnet aggregates.
Security considerations
Because leanVM has no authority, it cannot weaken consensus security. A soundness bug in leanVM can’t get an invalid aggregate accepted, and a completeness bug can’t get a valid one
rejected. Consensus security until PQ/AI day equals BLS security, as it does
The remaining risk is to node availability: a leanVM implementation bug, sucource use, could still affect the node running it. Clients should isolateleanVM verification so that it can’t affect consensus processing. For example, they should run it on a separate thread or process with timeouts and resource limits, and treat any
failure as a recorded mismatch rather than an error.
Costs
Compared to a leanVM-only approach, the post-quantum signatures, leanVM prooe needed anyway. The only extra cost of shadow mode is keeping BLS runningalongside them:
- Bandwidth: a BLS signature is 96 bytes, while hash-based post-quantum signatures are measured in kilobytes. The BLS part is only a small fraction of the post-quantum overhead.
- Computation: BLS signing, aggregation, and verification are cheap compng leanVM proofs.
- Code: BLS is already implemented and battle-tested in every client, so keeping it adds almost no new code.
- Fork: a leanVM-only approach needs a hard fork to enable leanVM. Shadod fork that retires BLS when PQ/AI day arrives. Because leanVM is alreadyrunning by then, this fork only switches authority.
In return for this small overhead, a leanVM bug can’t put Ethereum at risk before PQ/AI day.
Feedback is very welcome, especially on incentives and on the emergency fork.