ethlambda

ethlambda: devnet 5 and beyond

LambdaClass

16 Jun 2026 • 6 min read

We already introduced ethlambda, our Lean Consensus client. We also wrote a blog post about devnet 4, which introduced recursive aggregation. Now that devnet 5 is implemented and in interop testing, it's a good time to recap the devnets so far and look at the candidates for the ones to come.

Previous devnets

Each devnet introduced a new piece of the protocol's complexity. Devnets 0 and 1 didn't use real cryptographic signatures; they existed to kickstart client interop. Devnet 2 added real cryptography.

Devnet 3 introduced the aggregator role, with one level of signature aggregation. Devnet 4 added a second level, both in aggregators and in the block proposer. Aggregators previously combined raw signatures into multi-signatures; now they recursively aggregate multiple multi-signatures into a single one.

Devnet 5: full-block aggregation

In devnet 4, blocks included a leanVM proof for each attestation they carried. With a limit of 16 attestations per block, and an average proof size of around 200KB, a block could weigh several MBs. This slows down network propagation and limits how many attestations a proposer can include before their block fails to propagate on time.

Devnet 5 addresses this with full-block aggregation. Instead of gossiping one single-message aggregate per attestation, we now gossip a single block proof: a multi-message aggregate covering all of them, no larger than one of the old per-attestation proofs. A block carrying max attestations drops from several MBs to around 200KB.

Ethlambda and other clients have implemented devnet 5, and teams are running interop devnets to find issues. We're also benchmarking proposer and aggregator work, searching for performance improvements that help validators meet their target times.

The next few devnets

The Lean teams haven't settled the content of the next devnets yet; these are the features we consider the most likely candidates.

Devnet 6: the decoupled protocol

Previous devnets focused on the cryptographic pipeline; this one would focus on consensus. We previously talked about the current consensus mechanism of Lean Consensus, a combination of LMD-GHOST and 3SF-mini. Both have problems, but earlier devnets used them because they're simple and well understood. Devnet 6 would replace them.

The replacements aren't finalized yet, but the main candidate is a mix of three algorithms: Goldfish, RLMD-GHOST, and a trailing finality gadget. The division of labor stays the same as today: a fork-choice algorithm tells us which block is our head, and a finality gadget tells us which block is the base of our reorgable tree.

Goldfish

We previously talked about Goldfish: an algorithm similar to LMD-GHOST, with a more rigorous approach to synchronization between peers. It's a candidate for the role of heartbeat: a high-throughput fork-choice algorithm that keeps the network producing blocks at a fast pace, even during periods of asynchrony. Its main difference with LMD-GHOST (and the one that gives it its name) is that it considers only votes emitted during the last slot. Forgetting old votes is what makes it safe for a subset of the validators to act as a "heartbeat committee", known as the "post-quantum heartbeat": a small committee emitting head votes reduces bandwidth requirements and removes signature aggregation from the hot path, enabling lower latency and shorter slot times.

RLMD-GHOST: Recent Latest Message Driven GHOST

RLMD-GHOST sits between LMD-GHOST and Goldfish. LMD-GHOST counts each validator's latest vote no matter how old it is; Goldfish counts only votes from the last slot. RLMD-GHOST counts votes from the last N slots, with N a protocol parameter. Remembering more votes makes its output more stable: it doesn't depend on a single slot's votes arriving on time.

That stability is what the protocol needs to pick targets for justification. Besides head votes, validators cast source-target votes, the raw material of the finality gadget: the source is a block they consider justified, and the target is the block they want to justify next. Picking the source is easy: it's the latest justified block according to their head. Picking the target takes more care, since justification only advances if a supermajority of validators votes for the same target. We call this block the "safe target", and today we compute it by running LMD-GHOST on the subset of blocks with a supermajority of head votes, meaning most validators confirmed having seen them. In the new design, RLMD-GHOST takes over this role: its longer memory makes its output a good safe target, and also a starting point for Goldfish.

Finality gadget

Fork-choice alone gives us no long-term security. If malicious nodes make up most of a validator committee, they can choose an arbitrary chain of blocks as the new canonical chain. The easiest way to bound this damage is with a finality gadget, embedded in the state transition function, which adds a finalized checkpoint to the chain state. Fork-choice won't look further back than that checkpoint. The Goldfish paper already includes a basic finality gadget: the last κ blocks can be reorged, and older ones count as finalized. 3SF-mini, Casper, and similar algorithms do better, reaching lower finalization latency during periods of synchrony.

Devnet 7: end-to-end integration

Like any blockchain, the Lean Chain consists of many validators coming to consensus on which chain of blocks is the right one, and therefore on what the current state is. Until now, this state held only consensus data: the list of validators, which blocks were justified, which were finalized. The focus of this devnet would be connecting the consensus layer to the execution layer, so that the state also includes information from execution and the latest processed transactions.

Validator balances, including variable stake weights per validator, are tied to execution and validator deposits. This makes them easier to add as part of the execution requests integration, the mechanism the execution layer has for sending requests to consensus. Once those land, we should be able to support dynamic validator sets too, using the same deposit and withdrawal flow that forms the beacon chain validator lifecycle.

The end goal is to bring ZK proofs into the protocol, enabling validators to skip re-execution. Validator nodes then won't need execution clients at all; only builders and state-serving nodes will execute payloads. Integrating with live execution clients is a first step towards this.

After that

One of the priorities of upcoming Ethereum hard forks is censorship resistance. The most important EIP in this regard is FOCIL, Fork-Choice enforced Inclusion Lists. With it, a small group of validators builds an inclusion list of transactions that the next block must include.

There are also research efforts in the networking stack. ethp2p is a p2p networking stack purpose-built for Ethereum, designed to hit the low latency targets of Lean Consensus. It replaces generic sequential store-and-forward propagation with object-specific broadcast: erasure-coded broadcast for large objects like execution payloads, and specialized schemes for smaller ones like attestations, all on top of a minimal QUIC-based transport. A future devnet could be a good testing ground for it.

The next Ethereum hard fork plans to enshrine Proposer-Builder Separation in-protocol, and future devnets will port that change. Researchers are still discussing Attester-Proposer Separation as a possible improvement for both the beacon and lean chains, along with the generalized "Rainbow Staking" model. The Lean Chain would be a good place to prototype these ideas.

The protocol will also include validator rewards and penalties at some point. Designing them will take research, drawing on lessons from Ethereum's years running Proof-of-Stake. The new consensus changes what counts as misbehavior, so slashing conditions and inactivity penalties will differ from the beacon chain's, aiming for punishments that are less harsh without losing security. Proposer rewards should follow the same path, with a better thought-out issuance curve that reduces inflation.

Where to read more

If you want to read more about any of these, here are some resources that served as inspiration for this post:

The Lean Consensus spec, leanSpec, is available on its GitHub repo. Ethlambda is our Rust implementation of it, with its source code available in our GitHub repo.

Join us on Telegram for daily development updates and follow us on X for announcements and our weekly community calls.