Enshrined Minimal Vm For Post-Quantum Signature Aggregation

Issue 70 Edition 2026-03-11 7 min read

General

Sources: 1 • Confidence: Medium • Updated: 2026-03-14 12:28

Key takeaways

LeanVM is intentionally not general-purpose and is optimized for signature aggregation rather than competing with broader ZKVMs such as OpenVM or SP1.
LeanVM’s main benchmark metrics are 2-to-1 recursion time and XMSS aggregation throughput rather than hash-only microbenchmarks.
LeanVM currently achieves proof sizes below 256 KB and can reach about 150 KB with more aggressive rate settings while targeting close to 128-bit security.
Post-quantum proofs and signatures are much larger than BLS aggregates, making network propagation cost a first-class constraint alongside aggregation throughput and recursion time.
Ethereum’s Python specification repository is used as the executable definition of consensus rules and tests for client teams, and it includes the post-quantum signature scheme and aggregation logic used to run multi-client devnets.

LeanVM is intentionally not general-purpose and is optimized for signature aggregation rather than competing with broader ZKVMs such as OpenVM or SP1.
Lean Ethereum’s consensus-layer post-quantum signature aggregation uses hash-based signatures (XMSS/LeanSig) whose aggregation is proven via a SNARK implemented through LeanVM.
LeanVM was chosen over a fixed circuit primarily to support variable numbers of signatures and variable recursion patterns within a single aggregation step.
LeanVM is directly inspired by Cairo and uses a very small instruction set with four opcodes and only two precompiles.
Because LeanVM would be enshrined into Ethereum consensus, its design prioritizes extreme simplicity to enable formal verification and reduce catastrophic bug risk.
LeanVM removes Cairo’s allocation pointer (AP) register.

LeanVM’s main benchmark metrics are 2-to-1 recursion time and XMSS aggregation throughput rather than hash-only microbenchmarks.
On the main branch, LeanVM aggregates above roughly 500 XMSS signatures per second on a Mac M4, down from about 1000 previously due to simplifying the prover to support recursion.
Some performance techniques were removed from LeanVM because they made recursion slower and the verification program larger and harder to reason about.
LeanVM programs are written in a high-level DSL that compiles to the four-opcode ISA, and the DSL is being moved from Rust-like syntax to Python-like syntax to align with the Python specification and recursion verifier implementation.
LeanVM’s prover commits three AIR tables with stacked polynomials and Weir, uses a logup to prove interactions, and uses sumcheck plus openings to finalize verification.

LeanVM currently achieves proof sizes below 256 KB and can reach about 150 KB with more aggressive rate settings while targeting close to 128-bit security.
LeanVM uses the 31-bit KoalaBear prime field and increases the extension degree to 5 rather than 4 to approach 128-bit security for Weir in the Johnson regime.
LeanVM uses Weir as its polynomial commitment scheme, described as FRI plus an additional check intended to shrink proof size by reducing the rate each round.

Post-quantum proofs and signatures are much larger than BLS aggregates, making network propagation cost a first-class constraint alongside aggregation throughput and recursion time.
Because consensus validators must run on low-end devices, LeanVM performance work targets CPU (not GPU) and focuses on parallelization, SIMD, and low-level primitive optimizations in Plonky3, including Poseidon2.

Ethereum’s Python specification repository is used as the executable definition of consensus rules and tests for client teams, and it includes the post-quantum signature scheme and aggregation logic used to run multi-client devnets.
About ten Ethereum client teams participate in regular coordination and devnet testing for post-quantum and LeanVM-related assumptions.

Post-quantum proofs and signatures are much larger than BLS aggregates, making network propagation cost a first-class constraint alongside aggregation throughput and recursion time.

What exact on-chain or consensus-level requirement drives the stated need for thousands of XMSS aggregations per second, and how is that requirement derived?
What are the verifier costs (CPU time, memory, and implementation complexity) for LeanVM proofs under the targeted security settings, on low-end validator hardware?
What are the end-to-end network impacts (propagation latency, bandwidth usage, and stale/uncle behavior) when post-quantum proofs/signatures are gossiped under realistic conditions?
What is the current maturity and external validation status of the LeanVM design and its proving system (audits, formal verification artifacts, or multi-client implementation results)?
How portable is LeanVM to aggregating other post-quantum signature schemes in practice, and what concrete changes (ISA, precompiles, prover, or verifier) would be required?

If post-quantum signature aggregation is enshrined, demand could shift toward specialized proving stacks optimized for recursion, proof size, and verifier simplicity rather than general-purpose ZKVMs.
Consensus-level emphasis on bandwidth and low-end validator limits suggests infrastructure value may accrue to approaches that minimize proof sizes and propagation costs for post-quantum artifacts.
Use of an executable Python specification and multi-client devnets implies a pathway where implementations aligned with spec-driven testing gain credibility and adoption if post-quantum aggregation progresses.

Multi-client devnets demonstrate stable operation with post-quantum aggregation logic and LeanVM-style proofs, with reported propagation latency and bandwidth impact under realistic gossip conditions.
Public benchmarks show improving 2-to-1 recursion time and sustained XMSS aggregation throughput while keeping proof sizes near the stated 150 to 256 KB range at near 128-bit security targets.
Verifier performance measurements on low-end validator hardware show acceptable CPU time, memory use, and implementation complexity for the targeted security settings.

End-to-end network testing shows post-quantum proofs and signatures materially degrade propagation, raising stale rates or requiring unacceptable bandwidth increases.
Verifier costs on low-end hardware are too high, forcing redesigns that increase proof size or complexity beyond consensus-friendly limits.
External validation reveals immaturity in the proving system or LeanVM design, such as failed audits or inability to reproduce results across client implementations.