ethlambda: A Beacon Chain Client for Post-Quantum Ethereum
Today marks a huge milestone in ethlambda: after months of developing and polishing the client, we are excited to announce the official release of ethlambda v1.0.0! 🎉
This landmark release comes with full support for both Fusaka and Glamsterdam, marking the beginning of an exciting new chapter in our mission to push the boundaries of Ethereum consensus client development.
If you’ve been following along, the beacon chain client itself isn’t new. We announced it a while back, and since then it has been running nodes on mainnet, staking on Sepolia and Hoodi, and carrying our validators through the Glamsterdam hard fork on Sepolia without a single issue. Version 1.0.0 makes it official: ethlambda is ready for mainnet validators.
Instructions for running it are in our repository.
ethlambda started life as a client for Lean Ethereum, where we spent our time on devnets testing new fork-choice rules, post-quantum signature aggregation and validator scaling. That work taught us a lot about building consensus software fast and building it correctly. We are now bringing all that knowledge to the beacon chain that secures Ethereum today, alongside the lessons from building ethrex, our execution client.
Running on Mainnet and Testnets
We run ethlambda nodes on mainnet and use it for staking on the Hoodi and Sepolia testnets. On Sepolia, our validators recently completed the Glamsterdam hard fork transition while running ethlambda. The transition went smoothly, without a single issue.
A fork transition is one of the most demanding moments in a client’s life. Every node must switch to the new rules at the same slot, and any divergence immediately becomes apparent through missed duties or a split view of the chain. Successfully navigating a transition with live validators is a test that no unit test suite can replace, and it is a big part of why we are comfortable calling ethlambda production-ready.
Metrics for the nodes running on our servers are available at: https://metrics.ethlambda.xyz
Built on Lean Ethereum and ethrex
The team behind ethlambda is not starting from scratch. Through our work on Lean Ethereum, we iterated on consensus rules devnet after devnet, scaled our networks to more than a thousand validators, and tracked down problems such as late block arrival that only appear under real-world load. This gave us a working understanding of where consensus clients spend their time and where they break.
ethrex gave us the other half: years of experience writing a lean, fast Ethereum client in Rust, keeping the codebase simple enough to reason about, and optimizing it once it was correct. We are applying both sets of lessons to ethlambda, with the same emphasis on simplicity and the same willingness to rewrite hot paths when the profiler tells us to.
Performance
Today, ethlambda performs on par with other beacon chain clients, processing blocks in under 300 ms on our servers. This is only our starting point. With ethrex, we took a working client and continued profiling and optimizing it, release after release. We intend to do the same here: identify the limits of each component, measure them, and push them further.
We will publish benchmarks and comparisons as this work progresses.
Our Next Steps
Besides working on performance, our current priority, we are working on making our validator client feature-complete and adding several more Beacon API endpoints. In addition, we are pursuing several other initiatives in parallel.
Hegotá
We have already implemented the EIPs scheduled for Hegotá, the fork after Glamsterdam, and are in the process of joining the Hegotá interoperability devnets. Taking part in these devnets early is how a client helps shape a fork rather than simply following it, and it is how we spent much of our time working on Lean Ethereum.
Post-Quantum Cryptography
We are starting work on bringing post-quantum cryptography to the beacon chain. This is where our Lean Ethereum background pays off most directly: we have hands-on experience with leanXMSS and leanSPHINCS, the hash-based signature schemes designed for Lean Ethereum, and we know firsthand what they demand from a client in terms of signature size, verification cost, and aggregation.
A Single-Binary Ethereum Node
Running Ethereum today means running two programs: a consensus client and an execution client, configured separately and communicating with each other over the Engine API. We are experimenting with a different setup: a single ethlambda binary that embeds ethrex, allowing one program to function as a complete, standalone Ethereum node.
This is still experimental. The goal is a node that is simpler to install, configure, and operate, with tighter integration between the two layers than is possible with separate processes.
Security audits
A client that secures real stake benefits from outside review, not just our own testing. With that in mind, we are exploring an external security audit.
Try It
ethlambda v1.0.0 is available now. If you run a node or validator, we encourage you to try it. Client diversity is one of Ethereum’s strongest defenses, and every new production client helps only if people actually run it.
The code is open source, and issues, pull requests, and questions are all welcome. To share feedback or follow along, join the ethlambda Telegram group, follow us on X, or visit our website.
