Lean Ethereum: the biggest overhaul of Ethereum since The Merge

TL;DR

On July 4, 2026, Vitalik introduced Lean Ethereum as the protocol's "third major iteration" after The Merge, an overhaul that could replace nearly every major building block of the protocol within three to four years.

Lean Ethereum isn't a single upgrade but rather a long-term trajectory for the network. If we go by the Strawmap, the collaborative working document published by the Ethereum Foundation this past February, seven forks are expected to shape Ethereum's path through 2029.

Put simply, the core idea behind Lean Ethereum is to deeply simplify the protocol's architecture. After more than a decade of technical accumulation, Ethereum is looking to rebuild its core around a reduced set of cryptographic primitives, primarily based on hash functions and proof verification.

At the same time, the consensus, data, and execution layers would be gradually redesigned to reconcile fast finality, scaling, privacy, and resistance to quantum computers.

It's worth understanding that this transition goes well beyond simply replacing signatures. It concerns validators, accounts, the KZG commitments of blobs, as well as certain proof systems. The quantum challenge reveals an asymmetry with Bitcoin here: Ethereum has more vulnerable components, but it also has a stronger coordination capacity to organize their replacement.

So the promise of Lean Ethereum is as ambitious as it is complex, since it ultimately comes down to simplifying the protocol while integrating new security and performance guarantees. The primitives already exist, but integrating them into a global, multi-client network secured in production remains a considerable challenge. The Strawmap is thus a strong signal about the direction Ethereum should take, but still a weak one on the operational front.

---

From Beam Chain to Lean Ethereum

The origins of Lean Ethereum trace back to Devcon Bangkok in November 2024, when researcher Justin Drake presented the "Beam Chain," a deep overhaul of Ethereum's consensus layer.

At the time, the Beacon Chain, launched on December 1, 2020, rested on an architecture whose base specification had been frozen five years earlier. The successive forks gradually evolved it without questioning its foundations, while advances in research on consensus, MEV, and zero-knowledge proofs (ZK proofs) had progressively opened up new possibilities.

The Beam Chain proposed precisely to bring these advances together into a coherent rebuild, while clearing part of the technical debt accumulated over the years.

Among the breaks under consideration were, among others, lowering the staking minimum from 32 to 1 ETH, slots cut to four seconds, finality reached in three slots with single-slot finality on the horizon, and above all the integration of post-quantum signatures based on hash functions, compatible with efficient verification via cryptographic proofs.

The scope, however, remained deliberately narrow. It's worth recalling that Justin Drake rejected the label "Ethereum 3.0" at the time, noting that the Beam Chain only reshaped the consensus layer, not the virtual machine or the data layer.

The ambition then broadened in July 2025, when he extended this approach to all three layers of the protocol, consensus, data, and execution, each redesigned from first principles. At that stage, two objectives structured this vision:

• The first, "fortress mode," consists of making Ethereum an infrastructure capable of surviving anything, from nation-state attacks to quantum computers.
• The second, "offensive mode," seeks to scale both the L1 and blobs simultaneously.

In this approach, hash-based cryptography becomes the common foundation of the strategy, with the ambition of improving both the protocol's performance and its quantum resistance.

This vision was ultimately formalized in early 2026. Developed as a starting point during an Ethereum Foundation workshop in January, then made public by EF Protocol on February 25, the Strawmap structures these long-term ambitions around five axes: a faster L1, a "gigagas" L1 targeting roughly 10,000 TPS, a "teragas" capacity corresponding to about 1 GB of data per second for Layer 2s and, theoretically, 10 million TPS, and finally a post-quantum Layer 1 with privacy built in natively.

The three pillars appear as modernized versions of the current components: Lean Consensus is presented as a "Beacon Chain 2.0" and the heir to the Beam Chain project, while Lean Data is described as the "blobs 2.0" iteration, and finally Lean Execution as an "EVM 2.0."

The common thread stays the same, namely reducing the number of critical primitives and the complex interactions that the various client implementations must reproduce without diverging.

Become Premium

Unlock all our research and get the right insights, at the right time.

---

The three pillars

Lean Ethereum breaks the protocol overhaul into three layers: consensus, data, and execution. Each addresses different constraints, yet they all converge toward a shared cryptographic foundation. This architecture underpins the Strawmap and highlights the dependencies that should guide the rollout of the various building blocks.

Lean Consensus

The first pillar picks up the vision initially presented under the name Beam Chain, now folded into Lean Consensus. Its goal is to bring the finality delay down from around fifteen minutes to a few seconds.

Three-slot finality is still at the research stage, while the most recent work is exploring Minimmit, a mechanism capable of finalizing a block after a single wave of votes, potentially in around eight seconds.

In exchange, the theoretical threshold for tolerating faulty or malicious validators would drop from roughly 33% to 17%. Slots, for their part, could be brought down to four seconds.

For the user, the intended benefit is fairly simple: a transaction would be considered definitively finalized within a few seconds, versus around fifteen minutes today. Consensus would remain organized around one validator proposing the block and others attesting to it, but with shorter cycles and aggregated votes to avoid the saturation of the network.

In practice, three major changes would restructure this overhaul: replacing BLS signatures with post-quantum signatures, a cleaner separation between the role of those who propose blocks and those who attest to them, and finally the potential lowering of the staking minimum from 32 to 1 ETH in order to broaden direct participation in the network.

This layer would also rely on a new generation of peer-to-peer protocols, notably Gossipsub v2, capable of absorbing shorter slots and a higher number of validators.

Lean Data

The second pillar, presented as the "2.0" version of blobs, concerns the availability of data published on Ethereum by rollups. Its goal is to gradually replace KZG commitments with quantum-resistant mechanisms based on hash functions.

Concretely, when a user makes a transaction on a rollup, it's aggregated with others, executed off Ethereum, and then the data needed to verify it is published in a blob. With PeerDAS, each validator no longer needs to download all of this data, since each one only retrieves a fraction of it in order to check that the whole set remains available.

Lean Data therefore isn't meant to directly change the user's journey or Layer 1 finality. Rather, its goal is to increase rollup capacity without forcing every validator to download more data. On top of that, if the supply of blobspace grows faster than demand, this extra capacity could also reduce Layer 2 costs.

Data availability is central to their security, since without access to the published transactions, an optimistic rollup can no longer be properly verified or challenged. Even a zk-rollup, whose proof guarantees the validity of the computation, can become unusable if no one can reconstruct its state. A data availability failure wouldn't necessarily break Ethereum's consensus, then, but it could block or weaken the Layer 2s that depend on its blobs.

Today, KZG relies on a trusted setup, an initial ceremony that generates public parameters from a secret meant to be destroyed. Its security then depends on the hardness of the discrete logarithm problem, which theoretically prevents recovering that secret from the published parameters.

A sufficiently powerful quantum computer could nonetheless recover the secret hidden behind this setup, then forge false proofs that pass off as available and reconstructible data that in reality isn't.

In this scenario, validators could then consider a blob available when its data would in fact be irrecoverable, which would notably make it possible to block the rollups involved. Google Quantum AI's paper classifies this scenario among so-called "on-setup" attacks, meaning that once created, the exploit would remain usable until the trusted setup is replaced.

This transition nonetheless imposes a trade-off. The hash-based constructions under consideration, notably those relying on Merkle trees and FRI-type protocols, don't natively offer the linearity of KZG commitments and proofs. Yet this property makes it easier to reconstruct and do two-dimensional sampling of data. In that sense, its disappearance could force either a less efficient DAS or additional commitments and proofs produced by builders.

For rollups already using another data availability layer, such as Celestia, Lean Data would have no direct effect since they don't depend on Ethereum's blobspace. That said, this evolution could strengthen Ethereum's competitiveness against alternative availability layers by increasing blobspace capacity, potentially reducing its cost if supply grows faster than demand, and replacing KZG with a post-quantum commitment system.

Lean Execution

The third pillar aims to gradually replace the systematic re-execution of transactions with proof verification.

Today, every full node, through its execution client, replays transactions in order to verify the new state. In a model based on zkEVMs, specialized actors would execute the block and produce one or more proofs of its validity, which the other nodes could verify at a lower cost than the full re-execution they perform today.

Eventually, execution could rest on recursive proofs based on hash functions and on a much simpler machine, designed from the outset to generate these proofs efficiently. RISC-V is among the options being studied, while the Lean ecosystem is also exploring an even more minimal architecture, specifically suited to proofs. The EVM could then become a compatibility layer running on top of this new base, rather than the protocol's execution engine.

To the overhaul of the execution engine is added that of the state it manipulates, which Vitalik presents as probably the most radical part of the plan. Today, accounts, balances, contracts, and DeFi positions accumulate in a single state that every full node must keep and update. The idea would be to contain this layer's growth while adding new types of storage, more constrained but far more extensible, suited to ERC-20s, NFTs, and part of DeFi.

In the scenario put forward for 2030, Ethereum would keep around 2 TB of classic state, to which nearly 100 TB of this new storage would be added. This migration would remain optional, but applications adapted to this new architecture could see the cost of certain operations cut by more than tenfold.

Finally, privacy also becomes a cross-cutting constraint. The mempool, the new state structures, and the protocol's future components will have to be designed from the ground up to accommodate intermediary-free privacy protocols that are resistant to quantum computers.

A shared cryptographic foundation

The three pillars converge toward the same family of cryptographic primitives: signatures based on hash functions to replace BLS signatures in consensus, commitments of the same type to succeed KZG in the data layer, and hash-based zkVMs to gradually replace transaction re-execution with the simple verification of proofs.

For validators, the approach currently favored relies on XMSS, a scheme that organizes Winternitz-type one-time signatures within a Merkle tree. Since these signatures can't be aggregated directly like BLS signatures, they would first be compressed using recursive proofs before being verified by the protocol.

The choice of hash function nonetheless remains open. Poseidon2 initially figured among the leading candidates thanks to its efficiency in proof circuits, but recent cryptanalyses have led researchers to avoid any dependence on a single function. The favored approach now consists of designing an architecture agile enough to swap one hash function for another should that become necessary.

In practice, this vision brings together two properties sought by Lean Ethereum. On one hand, it no longer relies on discrete logarithm problems that are vulnerable to Shor's algorithm. On the other, it makes it possible to efficiently integrate the verification and aggregation of signatures within a single proof system.

How far can the validator's role be lightened?

Vitalik sketched out an even more radical version of consensus. In this architecture, much of the information kept permanently for each validator today would be replaced by periodic proofs produced by the validators themselves.

Concretely, each validator would regularly generate a STARK proof attesting that the evolution of its balance, given its participation in consensus, has indeed been computed since its previous proof.

This approach could sharply reduce the size of the consensus state and, in theory, make it possible to support several million validators. It wouldn't make every cost disappear, however, since with a million validators, the daily proofs would still represent more than a hundred STARKs per slot on average, which would themselves have to be aggregated.

This proposal nonetheless remains exploratory. An intermediate approach would consist of entrusting, at each slot, the advancement of the blockchain to a random committee of around 256 validators, versus nearly 30,000 called on to attest today, while the entire network would continue to participate separately in the finality mechanism.

The principle recalls that of Algorand, where small committees are randomly selected to propose and certify blocks. The comparison has its limits, though, since in this architecture the committee wouldn't replace the full set of validators. It would serve only to advance the blockchain in the short term, while finality would continue to be ensured separately by the entire network.

---

The post-quantum migration of the trust hierarchy

Reducing Lean Ethereum to a simple signature replacement would be misleading. In reality, the transition concerns a large part of the protocol's cryptographic architecture, with each layer exposed to different risks.

The ECDSA signatures of accounts and the BLS signatures used by validators rest on elliptic curves, which means a quantum computer running Shor's algorithm could derive the private key from the public key.

KZG commitments, for their part, are vulnerable on two levels: their ability to guarantee that a proof corresponds to only a single dataset, but also the secret from their trusted setup, which could be reconstructed. To this are added, at the scale of the ecosystem, proof systems based on elliptic curves as well as the admin keys that control certain Layer 2s, bridges, and contracts.

Vitalik identifies four major cryptographic building blocks to replace: the BLS signatures used by validators, KZG commitments, the ECDSA signatures of accounts, and certain application-level proof systems.

In practice, this transition to post-quantum alternatives has to be spread across several upgrades. Current goals target completing the main post-quantum building blocks of the Layer 1 by around 2029, while the full migration of the execution layer and the ecosystem should require several additional years.

This acceleration is also explained by changing estimates regarding the capabilities of quantum computers. In late March 2026, a study by Google Quantum AI, co-authored notably by Justin Drake and Dan Boneh, estimated that a 256-bit elliptic curve could be compromised with fewer than 1,500 logical qubits, or fewer than 500,000 physical qubits in the architecture studied, a threshold roughly twenty times lower than previous estimates.

Google has, for that matter, set itself a goal similar to Ethereum's, with a migration of its own cryptographic systems planned for around 2029.

---

Ethereum and Bitcoin facing quantum: a coordination asymmetry

Whether for Bitcoin or Ethereum, the fundamental vulnerability is shared: Shor's algorithm threatens ECDSA and Schnorr on Bitcoin the same way ECDSA and BLS weigh on Ethereum. Yet the two networks don't expose the same components and don't face the same migration difficulties.

In Bitcoin's case, roughly 6.7 million BTC currently sit in outputs whose public key is already exposed, including 1.7 million in old P2PK scripts, on top of those exposed via Taproot. Conversely, a user who keeps their BTC in P2PKH or P2WPKH outputs without spending avoids exposure, but that will no longer be the case once a spend has taken place.

On Ethereum, as soon as an externally owned account issues a transaction, its public key becomes durably visible, with no way to hide it again short of simply switching accounts. Among the 1,000 richest accounts, those whose public key is already visible concentrate on their own around 20.5 million ETH, or nearly 17% of the total supply.

Above all, the vulnerability is not limited to a single asset class. It spans multiple layers of both the protocol and its broader ecosystem. Whereas Bitcoin primarily exposes certain UTXOs and transactions at the moment they are spent, Ethereum faces a broader and more systemic attack surface.

As a result, Bitcoin has fewer cryptographic building blocks to replace, but it must still reach consensus on the migration process and determine the fate of BTC that will never migrate. BIP-360 and BIP-361 already outline potential transition paths, but at this stage they remain draft proposals.

Ethereum, on the other hand, has more vulnerable components, but benefits from having already incorporated their replacement into a coordinated roadmap. In that sense, Ethereum’s potential advantage does not stem from lower exposure, but rather from its ability to orchestrate the transition.

---

Glamsterdam: The First Building Blocks of Lean Ethereum

Ethereum’s next network upgrade, Glamsterdam, expected in the second half of 2026, will not deliver Lean Consensus, STARK-based execution, or post-quantum cryptography. However, it does prepare the protocol for the scalability leap envisioned by Lean Ethereum.

In practice, two proposals form the backbone of this fork. The first, EIP-7732, natively integrates proposer-builder separation into the protocol, a role that is currently handled largely by MEV-Boost and external relays.

By more cleanly separating block construction from validation while extending the propagation window from roughly two seconds to around nine seconds, ePBS makes it possible to handle larger blocks without slowing consensus. This serves as a foundational building block for Lean Ethereum, whose objective is to significantly increase throughput while maintaining short slots and fast finality.

The second proposal, EIP-7928, introduces an explicit map of the accounts and state segments accessed or modified by each block. This enables nodes to preload the required data and execute independent transactions in parallel. The final results included in this map also allow certain state updates to be processed without requiring the full re-execution of every transaction.

This architecture therefore lays the groundwork for the parallel execution model and the gradual reduction of re-execution envisioned by Lean Execution. Combined with gas repricing and client optimizations, Glamsterdam is expected to pave the way for raising Ethereum’s gas limit from 60 million today to approximately 200 million per block.

Glamsterdam therefore lays the groundwork for greater capacity, parallel execution, and a more scalable block pipeline, while also reducing Ethereum’s reliance on external relays. The following fork, Hegotá, will introduce FOCIL, a mechanism that allows multiple validators to simultaneously contribute transactions that must be included in a block, thereby strengthening censorship resistance. Although FOCIL was originally planned for Glamsterdam, it was ultimately removed in order to keep the fork’s testing scope manageable.

According to Vitalik, this will likely be the last fork that remains largely "pre-Lean" in nature. Beginning with the following fork, tentatively referred to as I*, upgrades are expected to adopt the Lean architecture much more directly.

Note: I refers to the first fully Lean-oriented fork following Hegotá. L*, several upgrades later, would correspond to the bundled deployment of Lean Consensus.**

---

The Real Challenge: Integration

Lean Ethereum’s main source of fragility does not lie in a single monolithic fork, but rather in a complex dependency graph. Several components can only be delivered once the underlying cryptographic primitives, zkVMs, peer-to-peer networking layer, and multiple client implementations have all reached sufficient maturity. As a result, delays in any one of these areas can cascade throughout the entire roadmap.

The consensus layer represents a special case. While its redesign spans seven successive forks, several of Lean Consensus’ core components could ultimately be bundled into a dedicated upgrade, tentatively designated L*, concentrating a greater share of implementation risk around a single milestone.

In principle, the technological foundations already exist. STARKs and hash-based signature schemes are fully functional today. The real challenge lies in integrating them into a global, multi-client protocol operating under demanding constraints: real-time proof generation, large-scale recursion, massive signature aggregation, shorter slots, and hardware requirements that remain compatible with decentralization.

The remaining gap is therefore no longer one of raw performance. Leading zkVMs are already capable of proving 99% of Ethereum blocks in under ten seconds. Instead, the challenge is to make the system sufficiently reliable and accessible by producing proofs that are secure, compact, easy to verify, and generated on hardware that does not restrict participation to a handful of specialized operators. This is precisely why the roadmap includes the intermediate milestones discussed earlier: optional ZK clients, independent proofs, and progressively off-chain proof aggregation.

This ambition also comes at a time when the Ethereum Foundation is operating with fewer resources. Its 2026 budget was reduced by approximately 40%, followed by the elimination of 54 positions. Vitalik has maintained that the technical ambitions outlined in the Strawmap remain unchanged, but questions surrounding execution capacity have inevitably become more legitimate.

This tension has also fueled a public disagreement over the timeline. Dankrad Feist, a former researcher at the Ethereum Foundation (now working at Tempo), has argued that a three-to-four-year horizon is unnecessarily slow, calling instead for the entire roadmap to be completed within a single year, particularly by leveraging LLMs.

Interestingly, the Strawmap explicitly states that its timeline assumes development remains primarily human-driven, suggesting that AI-assisted development could substantially compress these estimates.

---

Ethereum and Solana: Two Overhauls, Two Philosophies

On July 16, Solana released the first alpha version of Agave 4.3, the client branch that will begin the validator transition toward Alpenglow, the comprehensive redesign of its consensus mechanism. At the very moment Ethereum is formalizing Lean, the other major general-purpose Layer 1 is also rebuilding its foundations, albeit through a fundamentally different philosophy.

To understand the contrast, it is worth recalling that Ethereum and Solana were built around almost opposite design principles. Solana was designed to concentrate execution, data availability, and consensus within a highly performant Layer 1, relying on increasingly powerful hardware and vertical scaling.

Ethereum, by contrast, has consistently sought to preserve solo staking on relatively accessible hardware while prioritizing client diversity and the protocol’s credible neutrality, delegating a significant share of execution to rollups.

Ultimately, both networks are now attempting to address the limitations of their original architectures. With Alpenglow, Solana is replacing its historical consensus mechanism, notably removing Proof of History and validator votes embedded directly within blocks in order to simplify the protocol and dramatically reduce latency. Ethereum, through Lean, aims to increase Layer 1 capacity and throughput by relying on cryptographic compression, progressively replacing transaction re-execution with proof verification.

Lean Ethereum’s objective is therefore to deliver faster finality, greater capacity, and a better user experience without proportionally increasing the hardware requirements imposed on validators, while simultaneously introducing new privacy and post-quantum security primitives.

Ultimately, the greatest challenge will be execution. Lean must eliminate a significant portion of the technical debt accumulated over the past decade while temporarily introducing an entirely new set of dependencies, all at a time when the Ethereum Foundation is operating with 54 fewer employees.

Become Premium

Unlock all our research and get the right insights, at the right time.