How LambdaClass is working in the Ethereum roadmap
Intro
The internet made information almost free to move. It never answered who owns something online, who can transfer it, and who settles the disagreement, so the answer defaulted to whoever runs the server. Ethereum is an attempt to build that missing layer in public: records, transfers, and enforcement that don't belong to a single operator.
An institution is only as credible as the software people can independently run and check. That's the part we work on. This post covers our last couple of years as core Ethereum developers, and where three of those pieces stand today: ethrex, our execution layer client; ethlambda, our lean consensus client; and Lambda VM, our zkVM.
Our journey through Ethereum
We've been into Ethereum for several years, both as users and as stakeholders. Over the years, we have helped to build and implement multiple protocols on top of Ethereum.
Our first approach to Ethereum as core developers was three years ago, when we developed lambda_ethereum_consensus, an Elixir-based Ethereum consensus layer client. We built it to contribute to Ethereum’s client diversity, which is essential for the resilience and decentralization of the network. As stated on ethereum.org: "Having many independently developed and maintained clients is vital for the health of a decentralized network."
Two years ago, we wanted to go for the full Ethereum stack, so we started working on ethrex, a Rust-based Ethereum execution layer client. Once more, we wanted to contribute to Ethereum's client diversity, this time not just with another client but, In line with the LambdaClass work ethos, with one whose codebase is simple, minimal, modular, and readable. Two years later, ethrex is working in production, performing as one of the fastest clients and having the smallest and most readable codebase.
At the beginning of this year, as a continuation of lambda_ethereum_consensus, with a focus on Ethereum's post-quantum secure future, Lean Ethereum, we began developing ethlambda, a Rust-based Lean Ethereum consensus client. Beyond contributing to client diversity, this was our first step in helping with experimental work on Ethereum. Today, ethlambda is the most stable Lean Ethereum client in interop devnets.
As part of the long-term roadmap of Lean Ethereum, which aims to scale Ethereum to gigagas L1 and teragas L2s using post-quantum secure ZK, we are also shipping Lambda VM, a verifiable virtual machine developed in collaboration with LambdaClass and 3MI Labs. This zkVM proves the 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 to provide Ethereum execution: taking blocks produced by clients such as ethrex and turning them into succinct proofs that can eventually be verified on-chain.
Three clients, three layers, one stack. That's what the rest of this post is about.
Where we stand
ethrex
After one year of development, ethrex was production-ready for the Pectra hard-fork with just 60k lines of code, performing with a throughput of 0.33 Ggas/s, while other clients like reth (which is implemented in the same programming language) were around 300k lines of code at that time (without taking into account other external libraries they relied on).
A year later, ethrex successfully transitioned through the Fusaka hard-fork, proved mainnet blocks on EthProofs, completed its first external audit, started being used by mainnet validators, and tripled its throughput, averaging 1 Ggas/s, with just 100k lines of code.
Today, ethrex is getting ready to jump to the next hard fork, Glamsterdam, expecting a double in performance to 2 Ggas/s after BALs. This time, ethrex has participated in every devnet (being included from day 0 on all of them), has been the first client to pass all the spec tests released with each devnet launch, and has also participated on its first interop, Soldøgn interop.
But we didn't stop there, ethrex is now and has been since it was production-ready, the playground for EF researchers to prototype the future of Ethereum, for the last couple of months. We are currently working on the fork immediately following Glamsterdam, Hegotá, leading the development on the future of the zkEVM with EIP-8025 (Optional Execution Proofs), Account Abstraction with EIP-8141 (Frame Transactions), Privacy with EIP-8250 (Keyed Nonces), and EIP-8272 (Recent Roots), Censorship Resistance with EIP-7805 (FOCIL), Security with EIP-7906 (Post-Transaction Assertions & Trustless Clear Signing), and Payments with Native UTXOs.
Hegota isn't our limit, as I* and L* hard-fork features are being developed on ethrex too, such as Partitioned Binary Tree (EIP-8297) by the EF and Native Rollups (EIP-8079) by us in collaboration with L2Beat and the EF, respectively.
ethlambda
After 8 months of development, ethlambda is the most stable client in interop devnets. We are up to date with the current pq-devnet-5 spec, and are actively working on experimental additions for future devnets. The next steps in the Post-Quantum chain are swapping the LMD-GHOST fork-choice algorithm and 3SF-mini finality gadget for Goldfish and BFT finality, and integrating the execution layer.
As part of our commitment to stability, we run constant devnets in our servers, where we recently ran a 512-validator devnet, the biggest to date. We also run our own suite of interop devnets, reporting any errors we find on other clients to the respective teams.
Lambda VM
Being recently added to the Ethereum Foundation's zkEVM track, Lambda VM passes 72 of 72 RISC-V ISA compliance tests, the first zkVM to do so. That track also sets the rest of the bar: permissive open-source licensing for every component used to prove Ethereum execution, and real-time proving.
As with ethrex, the codebase is minimal: as few abstractions and external dependencies as possible. The core cryptographic primitives live in the repository (~15k lines of code), the executor is ~3.5k, and the cryptographic description of the VM (tables, trace generation, and constraints) is ~30k. The GPU backend is counted separately, so the CPU implementation is a complete description of the zkVM in Rust. Most zkVMs have gone the other way, buying performance with proof systems that are harder to audit, reason about, and formally verify.
We overhauled the CPU and chip tables, improving proving times by 25%, and tightened soundness on a set of under-constrained chips. We completed the elliptic curve scalar multiplication and digital signature accelerator, which removes the dominant cost of proving ethrex transactions, ECDSA signature recovery, and made its witness generation 7.7x faster. Rounds 1 to 4 of the prover run on GPU with the trace resident on the device across rounds, and upcoming PRs should double GPU performance. Sharding/continuations landed, and the recursive verifier now runs over real blocks at real query counts, consuming continuation proofs in place.
The public roadmap has four milestones: proving full Ethereum blocks, proving them practically, verifying those proofs on-chain, and real-time proving. The same VM will prove ethrex L2 in our rollup-as-a-service and back our proof aggregation service. The codebase is under active development and not yet meant for production use.
What's next?
ethrex is heading into Glamsterdam with BALs and 2 Ggas/s, and the Hegotá features are being prototyped on it today. Ethlambda's next steps are Goldfish, BFT finality, and integrating the execution layer. Lambda VM's is the road from proving Ethereum blocks to proving them in real time.
Execution, consensus, and proving: ethrex, ethlambda, and Lambda VM are all Rust, all open source, and all small enough to read end to end.
We will talk about our experience working on ethlambda, more deep-dives on the current status of Ethereum (and Lean Ethereum), ethlambda, and ethrex, in future posts.
