Introduction

lambda_vm is an open-source zkVM that proves correct execution of RISC-V (RV64IM_Zicclsm) programs. It is built on STARKs over the Goldilocks field with LogUp lookup arguments, it is transparent (no trusted setup) and post-quantum secure. Our goal is proving Ethereum execution: taking blocks produced by clients such as ethrex and turning them into succinct proofs that can eventually be verified on-chain. We are developing the VM together with our partners from lambdaclass and 3MILabs. The virtual machine is going to be used in our proof aggregation service, as well as for proving ethrex L2 with our rollup-as-a-service.

This is part of the long-term roadmap of Lean-Ethereum, which aims to scale Ethereum to gigagas L1 and teragas L2s using zk, while ensuring that the system is post-quantum secure. The development of AI agents has made writing code way easier and faster, allowing us to iterate ideas at a greater pace and find bugs, but this has come at the cost of increased complexity of the codebases (not that human-written codebases were necessarily simpler) and subtler bugs. The need for better performance has made many teams developing zkVMs make their proof systems and virtual machines more complex, making it harder to reason about the codebase and understand the inner workings. Following a similar approach and philosophy to ethrex, we focused on developing lambda_vm with a minimalistic codebase, with as few abstractions and external dependencies as possible. This reduces the surface attack area, makes it easier to audit and reason about the codebase, and formally verify it. The core cryptographic primitives are inside the codebase (around 15,000 lines of code), the executor of the virtual machine is around 3,500 lines of code, and the cryptographic description of the virtual machine (tables, trace generation, constraints) is around 30,000 lines of code. The GPU version is counted separately, but having a full description of the code in Rust to run on CPU allows any developer to fully understand how the zkVM works.

On the Ethereum Foundation's zkEVM track, lambda_vm passes 72 of 72 RISC-V ISA compliance tests, becoming the first zkVM to do so. The same track also sets the bar we are building toward, from permissive open-source licensing of every component used to prove Ethereum execution to real-time proving.

This is a periodic status update. It covers where the project is heading and what landed over the last few weeks. The codebase is under active development and not yet meant for production use.

Roadmap

The public roadmap is available in the following site. The milestones are:

• Proving full Ethereum blocks
• Proving Ethereum blocks, practical proofs
• Ethereum proofs verifiable on-chain
• Real-time proving of Ethereum blocks

This strategy allows us to first focus on providing the basic functionality needed, scaling it, then making it practical and verifying it on-chain, and then focusing on making it really fast.

The work focuses on:

• ECDSA accelerator: verifying ECDSA signatures using RISC-V instructions is expensive to prove, so instead we delegate it to a specialized component that handles that part.
• GPU backend: proving is computationally heavy but is also heavily parallelizable, so leveraging GPUs gives great speedups.
• Recursion: allows proving that we verified one or more proofs. This enables compressing multiple proofs into a single one and reducing proof sizes.
• Continuations/sharding: allows us to prove efficiently larger programs.
• On-chain verifier
• Accelerators: specialized components that allow us to prove efficiently commonly used primitives, such as hash functions (which would otherwise be expensive to prove using RISC-V instructions only)
• Distributed proving: working with many GPUs to attain real-time proving.
• Security audits
• Formal verification
• Optimizations

Current state

These last weeks we completed the overhaul of the CPU and chip tables, improving proving times by 25%. The work included shrinking the CPU byte ALU (#644), computing the static and preprocessed commitments only once per construction (the bitwise and Keccak round-constant tables in #630, instruction decoding in #640, and the memory pages in #645), and fusing the DEEP composition into a single pass (#594). Along the way we also tightened soundness in a set of under-constrained chips (#652).

We completed the elliptic curve scalar multiplication and digital-signature accelerator, which reduced the number of cycles needed to prove transactions using ethrex, where ECDSA signature recovery is one of the dominant costs. This enables us to prove blocks with many transactions efficiently. We then made the accelerator's witness generation 7.7× faster (#866) and removed wasteful affine conversions in ecrecover (#859). Modifications to the guest program have resulted in lower proving times, with upcoming PRs landing that improve proving times by at least 30%.

The GPU implementation is proceeding as expected. Rounds 1 to 4 of the prover already dispatch on the GPU, from the LDE and commitment (#582), through the constraint composition and out-of-domain evaluation (#637), to the DEEP composition and FRI commit phase (#648), all built on the math-cuda pipeline (#578). Constraint/composition evaluation now also runs on the GPU (#798), the trace stays resident on the device across rounds (#799), and the LogUp auxiliary trace is built on the GPU as well (#762). We have several upcoming PRs that should accelerate the GPU by a factor of 2.

We also landed sharding/continuations, after focusing on the development of strategies and their benchmarking, with an emphasis on clarity and performance. On top of that, we have been hardening the recursion path: the verifier now runs over real blocks at real query counts and consumes continuation proofs in place (#844, #845, #847), and we streamlined the transcript by dropping ChaCha20 in favor of direct sponge-squeeze challenges (#841). We also continue with optimization of primitives (see #650), and periodically reviewing the codebase to improve code quality.

Recursion is now past the strategy stage and landing in code, while we continue to develop further accelerators and improvements to the guest program to achieve competitive proving times.