What Is 'Lean Ethereum,' Ethereum's Long-Term Roadmap? A Look at Its Shape Five Years From Now

Overview

On July 4, 2026, Ethereum co-founder Vitalik Buterin posted on X about Ethereum’s long-term technical plans. What he laid out is a vision called “Lean Ethereum”—a plan to gradually replace the major parts of Ethereum over the next three to four years. vitalik-lean

Lean Ethereum represents Ethereum’s third generational transition, following “The Merge.” The changes span almost the entire protocol: consensus (agreement on which block is the correct chain), block production, transaction execution, data availability, cryptography, gas (transaction fees), state storage, and client architecture. vitalik-lean

That said, there is no single giant update called “Lean Ethereum” shipped all at once. The “Strawmap” published by the Ethereum Foundation’s Architecture team lays out a path that carries out seven forks by 2029—roughly one every six months—introducing multiple technologies in line with their dependencies. The Strawmap itself notes that this is neither a prediction nor an official promise, but merely one relatively coherent path among many possibilities. strawmap

This article follows, year by year, how Ethereum would change one, three, and five years from now if this plan proceeds smoothly. To sum up the conclusion in a single line, Ethereum is trying to become the following kind of network.

From a chain where nodes around the world repeat the same computation, to a chain where a small number of executors perform the heavy computation and nodes around the world verify the results through cryptographic proofs.

Through this transition, Ethereum aims to achieve, all at once, major scaling of L1 and L2, second-level finality (the time until a transaction can be said to be irreversible), quantum resistance, privacy, and verifiability by individuals.

Note: This article is based on information as of July 13, 2026. The Strawmap is not a fixed development schedule but a draft for Ethereum researchers and developers to share a long-term direction. The timing, names, and contents of the upgrades described here may change. Please check primary sources for the latest situation.

Why Is Lean Ethereum the “Third Ethereum”?

Ethereum has already gone through major design changes before.

In the first generation, Ethereum—centered on Proof of Work (producing blocks through a computational race) and the EVM (Ethereum Virtual Machine, the execution environment that runs smart contracts), which went live in 2015—realized a public blockchain that was a “world computer” capable of executing smart contracts.

The second generation begins with The Merge in 2022. Ethereum shifted to Proof of Stake, in which validators who have staked ETH maintain the network. After that, Dencun introduced Blobs for L2 (a temporary data area for cheaply posting L2 data), and Pectra implemented EIP-7702, which lets ordinary accounts (EOAs, Externally Owned Accounts) use smart contract features. Fusaka in December 2025 activated PeerDAS, a mechanism that lets each node confirm data availability without holding all the Blob data. fusaka fusaka-peerdas

Lean Ethereum is called the third generation because it does not simply speed up the existing Ethereum but seeks to rebuild its internal structure from the ground up. While preserving compatibility with existing applications and assets as much as possible, it will change the consensus, execution, data, and cryptographic schemes running underneath.

From the outside it remains Ethereum, but many components are swapped out. Just as The Merge exchanged the consensus mechanism without asking users to move their ETH or DeFi positions, Lean Ethereum is expected to proceed while minimizing disruption to existing applications. vitalik-lean

The Five Final Goals the Strawmap Sets Out

The Strawmap presents five final goals that lie even further out than the individual technical proposals. strawmap

Each goal is not achieved through a single development approach. Quantum resistance, for example, is not merely a matter of wallet signatures; it requires revisiting the cryptography used at every layer of Ethereum—validator voting, Blob data availability, execution proofs, and privacy proofs. That is precisely why the goals need to be pursued together on a shared foundation.

A Simultaneous Approach Across Three Layers

Lean Ethereum thinks of L1 as divided into the following three layers.

• Consensus Layer: Decides which block to adopt as the chain and when to judge that finality has been reached.
• Data Layer: Guarantees that data such as the Blobs that L2s post to Ethereum can actually be retrieved on the network.
• Execution Layer: Executes transactions such as transfers, tokens, DeFi, and NFTs, and updates Ethereum’s state.

Lean Ethereum points toward using hash-based cryptography and zero-knowledge proofs (a technology that lets you prove to someone only that a computation or fact is correct, without revealing its contents) as a shared technical foundation across all three layers. The consensus layer centers on quantum-resistant signatures, the data layer on quantum-resistant data availability, and the execution layer on a zkVM (a virtual machine that can demonstrate the correctness of computation with zero-knowledge proofs) that produces proofs in real time. vitalik-lean

A Five-Year Roadmap

The following is not a fixed schedule laid out in the Strawmap. It is a scenario that reconstructs the changes over roughly the next five years—divided into yearly milestones and an end state—based on Ethereum’s official roadmap as of July 2026, the Strawmap, Vitalik’s explanations, and the dependencies among the technical proposals. Note that the more distant the timing, the higher the uncertainty.

One Year Out (2027): Separating Block Proposal and Production to Gain a Foothold Toward Larger Block Sizes

As of July 2026, Ethereum’s official roadmap lists Glamsterdam and Hegotá as in development. The main candidates for Glamsterdam are ePBS and Block-Level Access Lists (commonly called BAL). What Hegotá will adopt is still under discussion at this point. eth-roadmap The Strawmap’s assumption is that the substance of Lean Ethereum will enter gradually through the subsequent I-series, J-series, and L-series forks (all still tentative names), with the consensus that forms the core of Lean placed in the later L-series forks. strawmap

ePBS (Enshrined Proposer-Builder Separation) is a proposal to build into the Ethereum protocol itself the separation between the Builder that assembles a block and the validator (Proposer) that proposes it. eip-7732 BAL (Block-Level Access Lists) is a proposal that has a block declare in advance which accounts and storage it will access at execution time, making it possible to parallelize transaction validation and state updates. eip-7928 Both serve as the foundation for “processing larger blocks safely within a realistic time” toward later large-scale expansion. We cover the details of how they work as the centerpiece of the Glamsterdam update in a dedicated explainer article.

Ethereum around 2027 is not yet the finished form of Lean Ethereum. But it reaches a state where the roads and bridges that will support the later Gigagas L1 begin to be laid.

Two Years Out (2028): “Verifying Proofs” Instead of “Re-executing on Every Node”

In Ethereum today, essentially every node executes the same transactions. If a block contains 10,000 operations, each node computes the same 10,000 and confirms that it reaches the same state root (a hash value summarizing the state of all accounts).

With this approach, increasing throughput means raising the CPU, memory, and storage performance of every node at the same time. Scaling L1 by 100x or 1,000x while keeping it feasible for ordinary users to run a node becomes difficult.

This is where Lean Ethereum places real-time zkVMs and recursive STARKs at the center. A STARK is a proof scheme that lets you verify that a computation was performed correctly without repeating the computation itself. A Prover (a specialized executor that produces proofs) executes the transactions and generates a proof stating that “from this input, following these rules, this output was obtained.” Other nodes do not repeat the same computation from scratch; they only verify that the proof is correct.

Because a STARK can be built around hash functions, it not only compresses a huge computation into a small proof but also, unlike many SNARKs (another zero-knowledge proof scheme) that rely on elliptic-curve cryptography (a widely used form of public-key cryptography considered weak against quantum computers), has the advantage of being easier to make quantum-resistant. Furthermore, with recursive proofs, multiple transaction proofs and block proofs can be aggregated into a single smaller proof.

Vitalik explains that letting many nodes avoid re-executing blocks via a zkEVM (a zkVM that makes EVM execution the subject of proofs) is a central means of scaling L1 execution at large scale. vitalik-lean

However, if the Prover’s proof generation does not fit within the block’s processing time, it cannot be used on today’s blockchain. Finishing the proof within the block’s processing time requires all of a high-performance Prover, a proof-friendly VM, parallel execution, BAL, and an efficient P2P network. Around 2028, proofs are expected to begin entering as a standard component of Ethereum L1, not merely an L2 technology.

Multidimensional Gas: Managing Different Resources Separately

Advancing in parallel with proof-centric execution is multidimensional gas. In today’s Ethereum, operations of differing nature—CPU computation, storage reads, creating new state, cryptographic computation, and so on—are essentially converted into a single gas unit. Gas is the fee unit that measures the amount of processing a transaction takes to execute.

This is like limiting an airplane’s weight, passenger count, fuel, and baggage size all with a single number. In one block, the CPU may have room to spare while state writes have hit their limit. Conversely, state access may be light while cryptographic computation alone is extremely heavy.

Multidimensional gas measures computation, state, data, and so on as separate resources and sets a per-block ceiling for each. EIP-8011 is a proposal that, without greatly changing the feel of operations at the transaction level, meters multiple resources such as computation and state individually at the block level. This reduces the need to limit the entire block low to match the worst case of a single resource, and may allow greater throughput within the same safety limits. eip-8011

To users, gas still looks like a single fee, but inside the protocol multiple resources are controlled by their own ceilings. Ethereum’s scaling shifts from simply raising the gas limit toward safely using up the resources that are going spare.

Three Years Out (2029): Lean Consensus and Quantum Resistance

The Strawmap sketches a rough path of carrying out seven forks by 2029. Ethereum’s quantum-resistance roadmap also sets a planning target of putting the core quantum-resistant infrastructure in place by around 2029. Neither, however, has a fixed date. strawmap pq-roadmap

Sorting Out “Block Proposal” and “Block Finality”

In today’s Ethereum, a new block is proposed about every 12 seconds, but it takes roughly 15 minutes for that block’s finality to be established. Finality refers to a state in which the block cannot be reverted without causing the loss of at least one-third of the staked ETH. ssf

Single-Slot Finality, which Ethereum has been aiming for, is the vision of completing both block proposal and finality within the same slot (the block-production window allotted about every 12 seconds). ssf In Vitalik’s new explanation, a simpler consensus is under consideration that separates the selection of the available chain from finality processing and reaches finality in one or two rounds. vitalik-lean

If this is realized, it can greatly shorten the time in which a user sees “shown as successful in the wallet but not yet final.” For exchanges, bridges, L2s, and payment apps as well, there is no longer any need to wait a long time for L1 finality, improving capital efficiency and user experience.

On the other hand, processing a large volume of validator votes in a short time demands high performance from nodes. It would be pointless to speed up finality by excluding solo validators. So Lean Consensus seeks to redesign the composition of voters, signature aggregation, the P2P network, and the proof system together, reconciling all three of speed, security, and decentralization. justin-drake

Quantum Resistance Is Not Just a Wallet Problem

Coping with quantum computers has long been one of Ethereum’s long-term challenges. In Vitalik’s July 2026 explanation, however, the priority of quantum resistance was raised significantly. In particular, a quantum-safe design for the Blobs that L2s use is said to need to be nailed down quickly. vitalik-lean

There are four main areas in Ethereum that need quantum resistance. pq-roadmap

Validator signatures are especially difficult. Current BLS signatures have the major advantage of being able to aggregate hundreds of thousands of signatures into a single small signature. But because BLS is based on elliptic-curve cryptography, it risks being broken by quantum computers and cannot be made quantum-resistant as-is. At the same time, quantum-strong signatures (such as hash-based ones) are generally large in size and hard to compact the way BLS does, so simply swapping them in would strain the network’s bandwidth. So Lean Consensus is researching a proposal that combines leanXMSS, a hash-based signature, with leanVM, which aggregates signatures via proofs, to reconcile quantum resistance with BLS-level aggregation. pq-roadmap

Account Abstraction Becomes the Migration Path

Ordinary Ethereum accounts assume ECDSA signatures. To use a quantum-resistant signature, the account itself needs to be able to choose “which signature scheme it recognizes as valid.”

EIP-8141’s Frame Transaction is a proposal that decomposes transaction validation, gas payment, and execution into multiple Frames, letting a smart contract define the authentication method. This lets wallets handle not just ECDSA but also quantum-resistant signatures, multi-signatures, social recovery, and gas sponsorship as native protocol features. eip-8141

Quantum resistance is likely to take the form of users and wallets migrating to new signature schemes gradually through account abstraction, rather than swapping every wallet at once on a single day.

Four Years Out (2030): Layering “Blockchain State,” the Most Disruptive Change

For computation there is the zkEVM. For data there is DAS (data availability sampling). But the hardest thing to solve in scaling Ethereum is state.

State is the data representing Ethereum’s present—ETH and ERC-20 balances, NFT owners, smart contract code, DeFi positions, and so on. Computation can be compressed into proofs. Blobs can be deleted after a certain period. But current balances and contract contents must be actually stored by someone and available for reference when the next block is produced.

Vitalik explains that while computation can be made roughly 1,000 times cheaper through proofs as a rough guide, creating new state can only be reduced by about 20 times, and there is no means to scale today’s state as-is at the same magnitude. What is proposed, therefore, is a two-tier state design. The existing tier—flexible but expensive—is kept as it is, and alongside it a separate new tier is provided that is easier to scale massively but comes with stronger constraints. The idea is to let you choose which tier to place data in depending on the use case. vitalik-state

As an image of 2030, Vitalik gives an example of holding about 2 TB of the existing state and about 100 TB of the new, easier-to-scale state. vitalik-lean This is an example meant to illustrate the design direction. State that many users access synchronously and dynamically, like existing Uniswap pools, may remain on the existing tier. Meanwhile, ERC-20 balances, NFTs, and relatively simple DeFi positions are said to be easy to move to the new state format. Migration is not mandatory, but redesigning an app for the new format is said to allow fees to be lowered substantially. vitalik-state

What Form Will the New Tier’s State Take?

The new tier’s state is not a single finished design; several forms are under consideration depending on the use case. Examples include a UTXO-style model (close to Bitcoin’s approach), which treats balances as individual spendable records rather than one enormous shared ledger, and transient state, which is removed from the active set after a certain period and revived with a proof only when needed. Other forms mentioned include a format that declares in advance which state it accesses to make distributed storage and parallelization easier, and a format that efficiently manages a “this value has already been spent” marker for privacy-preserving transactions. vitalik-lean

The state change is the part of Lean Ethereum with the greatest impact on developers. Rather than simply writing low-gas code, Solidity developers will need to design “which data to store in which kind of state.” vitalik-state

Will the EVM Disappear?

For the execution layer, Lean Ethereum is considering changes large enough to be called “EVM 2.0.” While the current EVM has backward compatibility and a huge developer ecosystem, it was not designed on the premise of producing zero-knowledge proofs efficiently.

In the future, there is a proposal to use inside the protocol a VM with a small instruction set, well suited to formal verification and STARK proofs, such as RISC-V or leanISA. This does not mean abruptly abolishing Solidity or existing EVM contracts, however. In the long term, one conceivable arrangement keeps the EVM as a compatibility layer or compilation target for developers rather than a machine that Ethereum executes directly internally. Users and ordinary developers would use an EVM-compatible environment as before, with a different, proof-friendly instruction set running underneath. vitalik-lean

That said, Vitalik himself notes that the vision of fully moving the EVM to the compiler side is still a matter for the distant future. Including which of RISC-V and leanISA to adopt, it is at the research stage at this point.

The End State: For Whom Does What Change?

Once the changes so far are all in place, Ethereum moves toward a form in which heavy execution is entrusted to specialized Provers and Builders, while ordinary nodes, wallets, smartphones, and browsers verify recursive STARKs and confirm correctness for themselves. Quantum-resistant cryptography and L1-native private transfers are added on top. Even as processing becomes specialized, verification is still done by yourself as before. vitalik-lean

How this change lands depends on your position. From here, staying within the scope of Vitalik’s explanations and the Strawmap, we look at the impact on users, operators, and developers each.

Ordinary Users (People Who Use Transfers, DeFi, and Wallets)

The most tangible change is the speed of finality. Once finality is measured in seconds, waiting times for payments, deposits to exchanges, bridges, and transfers between L2s shrink significantly. As L1 and L2 scaling progresses, the fees for transfers and trades fall as well.

On the security side, accounts can migrate to quantum-resistant signatures, preparing for the emergence of quantum computers decades ahead. Moreover, because recursive STARKs can be verified even from a browser or smartphone, you can confirm the chain’s correctness yourself without trusting a company that provides RPC. If L1-native private transfers arrive, the option to use it without revealing balances or transfer details also grows.

Stakers and Validator Operators

The impact on staking operations grows large. In Lean Consensus, validator signatures are replaced from BLS with hash-based schemes such as leanXMSS, and vote aggregation, the P2P network, and the proof system are redesigned together. In the process of speeding finality to the second level, there arises a need to process a large volume of votes in a short time, and the performance demanded of nodes changes too. That said, a design that does not shut out solo validators in exchange for speed is taken as a premise.

The block-production mechanism also changes. With ePBS, the separation of Builder and Proposer is built into the protocol, and the dependence on an out-of-protocol third party (the Relay) that mediates block production disappears. Because the division of labor in which specialized Provers and Builders handle heavy execution and proof generation advances, operators will reconsider which role they take on and how much to delegate to the outside. Changes to key management accompanying the migration to quantum-resistant signatures are also a point worth checking in advance.

L2 and Rollup Developers

The core for L2s is the major expansion of data availability. Blob capacity grows toward a Teragas-scale target, and DAS (a scheme in which each node samples and checks a portion of the data) widens the room for many L2s to run at extremely low cost. Along with this, because Blob commitments move from KZG to a hash-based quantum-resistant scheme, the assumptions on the data-posting side change too.

L1 execution and finality becoming faster and cheaper changes L1’s character as an L2’s settlement and data-posting destination. How batches are posted and how fees are estimated will be reworked on the premise of the expanded Blob capacity and multidimensional gas.

Wallet and App Developers

The entry point for wallets is account abstraction. Once EIP-8141’s Frame Transaction is in, not just ECDSA but quantum-resistant signatures, multi-signatures, social recovery, and gas sponsorship can be handled as native protocol features. The EOA moves from “a box that keeps holding a single private key” toward a programmable account that can choose its authentication method and recovery means.

For app developers, and especially Solidity developers, the largest impact is the two-tiering of state. Rather than simply writing low-gas code, they will need to design “which data to store in which kind of state.” Redesigning for the new state format leaves room to lower fees substantially. As for the execution environment, even if the internals are replaced with RISC-V or leanISA, the arrangement envisions developers continuing to use an EVM-compatible environment as before. This, however, is a matter for the distant future.

Problems That Remain Even If Lean Ethereum Is Realized

The Strawmap is ambitious and holds many roadmaps, but there are numerous challenges that remain unsolved at this point.

Prover Centralization

If generating proofs in real time requires huge GPU clusters or specialized hardware, Provers concentrate among a small number of companies. Because it is necessary to keep not only anyone able to verify blocks but also individuals and small operators able to produce blocks, the competitiveness of the proof market and the feasibility of Provers on consumer hardware become important.

Builder Centralization and Censorability

Even with ePBS bringing Builders into the protocol, the Builders able to maximize profit may become few and centralize. FOCIL is a mechanism that creates an Inclusion List (a list of transactions that should be included) stating “this transaction should be included in the next block,” and validators do not vote for a block that ignores it. It is a design meant to keep the final authority over which transactions to include from being monopolized by the Builder, even while using specialized Builders. eip-7805

Storage and Distribution Load from a Bloated Blockchain State

Block verification is sped up by proof data. But executing transactions and having applications process current balances requires nodes that hold the actual state. Even if the 100 TB of new state is distributed across multiple nodes, an incentive to store the data and serve it when requested needs to be designed. Vitalik, too, lists the storage, synchronization, and RPC provision of the enormous state (providing the connection by which apps query nodes for balances and state) as a first-class research challenge. vitalik-state

What Ethereum Aims For: Improving Convenience While Preserving Self-Verifiability

Lean Ethereum’s goal is to keep a state in which, while handling enormous computation and data, users around the world can confirm the network’s correctness themselves without trusting a particular company. To that end, Ethereum is trying to advance a division of labor in which the heavy work is specialized while verification of correctness is done by yourself.

If this structure is realized, Ethereum will be able to greatly scale L1 and L2 while making the chain verifiable even from a browser, wallet, or smartphone. At the same time, quantum-resistant cryptography secures safety decades ahead, and native privacy builds a foundation you can use without publishing every balance and transaction to the world.

Omakase, as a Staking Service Provider (SSP) for Ethereum staking, continuously tracks client support for Lean Ethereum and the operational changes around block production and key management.