PodBrowser
Zero Knowledge

lean Ethereum Part 4: leanVM, a Custom VM for Signature Aggregation

Wednesday, 11 March 2026 · 2 min read · Listen to the episode ↗

The discussion focuses on Lean VM, a minimal ZK VM for post-quantum signature aggregation on Ethereum's consensus layer, designed to simplify operations with only four opcodes for efficiency. It emphasizes improvements in signature aggregation performance, aiming to exceed 1,000 XMSS signatures per second through optimizations and potential GPU acceleration. Additionally, Lean VM's architecture prioritizes security enhancements, aiming for over 100 bits of security, while facilitating collaboration among client teams on implementation and testing.

Anna Rose introduces a discussion on Lean VM, a minimal ZK VM designed for post-quantum signature aggregation on Ethereum's consensus layer, featuring insights from Thomas Couragé and Emil from the Ethereum Foundation. The conversation emphasizes the advantages of using a VM over a fixed circuit for signature aggregation, allowing for varying numbers of signatures and recursive aggregation, which is crucial for validators to add final XMSS signatures. The Lean Ethereum upgrade aims to create a post-quantum secure consensus layer utilizing hash-based signatures aggregated through a specific SNARK.

Lean VM is designed with simplicity in mind, featuring only four opcodes and two precompiled contracts, optimized specifically for signature aggregation. This minimalism extends to its proving system, which uses straightforward multilinear systems to avoid complexities that hinder recursion in previous systems. Emil's ongoing efforts focus on enhancing Lean VM's simplicity and infrastructure reusability, with open discussions and weekly calls to address client specifications and cryptography updates.

The design of Lean VM is compared to Cairo, highlighting its simplicity due to the absence of the AP register and its use of a high-level DSL that compiles to low-level opcodes. Implementation choices prioritize CPU optimization for validators on low-end devices, with improvements to the Poseidon 2 hash function being crucial for performance in field multiplication.

The conversation also touches on the integration of a separate repository into Plunky 3 and introduces Weir as a hash-based replacement for Fry, which offers smaller proofs and optimized performance. Current proof sizes on LinVM are below 256 kilobytes, with aggressive optimizations reducing them to around 150 kilobytes. There is a strong emphasis on achieving higher security than 100 bits for Ethereum, necessitating a degree 5 extension of the Qwala-Ber prime field for close to 128 bits of security.

Benchmarking methods are discussed, focusing on both low-level and higher-level benchmarks for the VM. Emil notes that while Lean VM can aggregate over 500 XMSS signatures per second, performance has decreased due to the implementation of recursion. The goal remains to achieve around 1,000 XMSS aggregated per second, with potential for GPU acceleration to exceed this rate. The Python specification outlines the consensus and execution layers for client teams, encompassing Ethereum's fork choice, networking layer, validator roles, state transition function, and the new post-quantum signature scheme. Collaboration with ten client teams is ongoing for testing and validation, with weekly calls to discuss implementation topics. The discussion concludes with an emphasis on the importance of benchmarking and aligning theoretical assumptions with practical realities.

This summary was generated from the episode transcript and can contain mistakes.