The Ethereum Roadmap: Six Phases, Every Major Upgrade

The Merge is the only roadmap phase that is fully complete. As covered in detail in our Ethereum history research, The Merge replaced Ethereum’s Proof of Work consensus mechanism with Proof of Stake on September 15, 2022. The change reduced energy consumption by 99.95%, cut new ETH issuance by 87%, and enabled validators to participate in consensus by staking ETH instead of operating mining hardware.

The Merge’s importance extends beyond the energy and issuance changes. It restructured Ethereum’s security model in ways that the later roadmap phases depend on. Proof of Stake created a validator set in which validators stake ETH as economic security. The Scourge’s MEV solutions, The Verge’s light client design, and The Purge’s simplified state verification all build around this structure. The Merge was therefore a prerequisite, not just a standalone improvement.

What The Merge did not do matters just as much as what it did. It did not reduce gas fees on Ethereum mainnet. That requires The Surge’s Layer 2 scaling solutions. It also did not increase Ethereum’s transaction throughput. That requires The Surge as well.

The belief that The Merge would produce immediate fee reductions became one of the most widespread misconceptions in Ethereum’s history. Its absence also contributed to the ETH price underperformance that characterized the period immediately following the upgrade.

The Surge is Ethereum’s scaling phase, a program of upgrades designed to enable the network to support 100,000 transactions per second through Layer 2 rollups and mainnet data availability improvements.

The main idea behind The Surge is that Ethereum does not need to process every transaction on its main chain. Instead, rollup networks process transactions off-chain and periodically submit compressed proofs of those transactions to the Ethereum mainnet for permanent settlement. Ethereum mainnet provides the security guarantees and data availability that rollups need without executing every individual transaction itself.

For rollups to work efficiently, the Ethereum mainnet needs to provide cheap, abundant data availability. This is the space where rollups can post their compressed transaction data for the validation window. The Surge focuses on expanding this capacity through a sequence of different approaches.

Dencun and EIP-4844: The First Major Surge Step (March 2024)

The Dencun upgrade activated on March 13, 2024, and implemented EIP-4844, also known as proto-danksharding. It introduced “blobs,” a new data type designed specifically for rollup data submission. Blobs are larger data chunks, up to 128KB each, that remain attached to Ethereum blocks for a 4096-slot (~18 day) window. During that period, rollups can access and verify the data. Ethereum then prunes it.

Blobs are cheaper than calldata, the previous mechanism rollups used, because they bypass Ethereum’s execution layer entirely.

The effect on rollup transaction costs was immediate. L2 fees dropped 80-90% almost immediately after Dencun activated. Average transaction costs on Arbitrum, Optimism, and Base fell to fractions of a cent. As a result, the “L2 scaling is too expensive” criticism that had been leveled at Ethereum’s rollup-centric approach became less valid overnight.

Fusaka and PeerDAS: The Second Major Surge Step (December 2025)

Fusaka’s hard fork activated on mainnet in early December 2025 and focused on data availability, including Peer Data Availability Sampling (PeerDAS). PeerDAS lets validators verify small samples of rollup data instead of downloading all of it. This supports more rollup data per block without requiring much more powerful hardware. It also works alongside higher data capacity at the protocol level.

PeerDAS is a more advanced approach to data availability than EIP-4844’s blob system. Instead of requiring each node to download all blob data to verify its availability, PeerDAS allows nodes to sample small random portions of the data. Using coding theory, specifically erasure coding, a node can verify with high statistical confidence that the full data is available by checking a small sample.

As a result, the network can handle more data without requiring each node to have proportionally more bandwidth and storage.

Fusaka’s PeerDAS implementation increases the number of blobs Ethereum can handle per block from 6 after Dencun to approximately 48-64 in its initial phases. The goal is to eventually support 128 or more. Each blob supports approximately 100,000 L2 transactions in current rollup designs. At 64 blobs per block and 12-second block times, Ethereum’s L2 throughput capacity approaches The Surge’s 100,000 TPS goal.

Fusaka also included the Community Gas Limit doubling. The community doubled the gas limit from 30 million to 60 million, the first such increase since 2021. This directly expands Ethereum mainnet’s transaction capacity for operations that do not route through L2s. It also reduces congestion for use cases that need mainnet settlement.

MEV, or Maximal Extractable Value, is the profit that validators and block builders can extract by controlling the order, inclusion, and exclusion of transactions in each block. When a DeFi arbitrage opportunity exists between two prices, the entity that controls block construction can ensure its own arbitrage transaction executes first. When a liquidation is pending, the block builder can ensure its bot is first to trigger it.

MEV exists in any system where transaction ordering has economic value. However, Ethereum’s current architecture concentrates that value among a small number of advanced block builders. This creates fairness concerns and adds pressure toward centralization.

The Scourge aims to address MEV through two primary approaches now being implemented: enshrined Proposer-Builder Separation (ePBS) and Fork-Choice Enforced Inclusion Lists (FOCIL).

Enshrined Proposer-Builder Separation (ePBS): Glamsterdam

A major feature of Glamsterdam is enshrined proposer-builder separation, known as ePBS. This change moves block construction into the protocol itself, reducing Ethereum’s dependence on a handful of external block builders that currently dominate the market. As data volumes rise under Fusaka, those builders could gain even more influence. ePBS is designed to prevent that outcome by formalizing how builders bid for blocks and how validators participate in the process.

Currently, Ethereum uses an off-protocol system called MEV-Boost. Validators outsource block construction to specialized builders and accept the highest-paying block from whichever builder wins the auction. This works reasonably well, but it creates dependence on off-protocol software and concentrates power among the handful of builders advanced enough to consistently win auctions.

ePBS moves the builder-proposer relationship directly into the protocol. This makes the process verifiable, auditable, and resilient to off-protocol failures.

Glamsterdam progress is slow but steady. Enshrined Proposer-Builder Separation (ePBS) implementation is proving trickier than anticipated, while other features such as gas repricing have their own complexities to work through. The challenge is moving a complex auction process that currently operates off-chain into the protocol without disrupting the existing MEV supply chain that validators depend on for revenue.

FOCIL: Hegota

Fork-Choice Enforced Inclusion Lists address a specific MEV abuse: transaction censorship. If a block builder wants to censor a specific transaction, preventing it from being included in blocks for competitive or other reasons, the current architecture does not provide a strong mechanism to prevent this.

FOCIL creates a protocol-level system in which a committee of validators can create inclusion lists that block builders must honor. This ensures that any valid transaction submitted to the network eventually gets included, regardless of whether its inclusion benefits or harms the block builder’s MEV extraction.

The following upgrade, Hegota, has chosen FOCIL as its major feature, with a commitment to work on Account Abstraction as part of the minor feature set. The combination of ePBS in Glamsterdam and FOCIL in Hegota represents a systematic approach to making Ethereum’s transaction ordering credibly neutral. The goal is to prevent both builder control of ordering for profit and validator censorship of specific transactions.

Ethereum’s current data structure for storing its state, the complete record of all account balances, smart contract code, and storage, uses a Merkle Patricia Trie. To verify that a specific account has a specific balance, a node needs to trace a path through this trie and check each hash along the way. The node also needs access to all the data in the trie to perform this check. As a result, running a full Ethereum node requires storing the entire state, currently measured in hundreds of gigabytes and growing continuously.

The Verge replaces the Merkle Patricia Trie with Verkle trees, a cryptographic data structure that enables much more compact proofs of state facts. A Verkle proof that an account has a specific balance is orders of magnitude smaller than the equivalent Merkle proof. The result is that a node can verify whether a proposed block correctly updates Ethereum’s state without storing the entire state locally. It needs only the compact proof attached to the block.

This enables stateless clients, nodes that verify blocks without storing state and instead rely on proofs provided by full nodes. A stateless client could run on a phone, a Raspberry Pi, or a smart TV. This would expand the population of participants who can independently verify Ethereum’s state without trusting a third party.

The Impact of Stateless Clients

Running a full Ethereum node currently requires dedicated hardware with substantial storage. The Verge seeks to make meaningful verification participation accessible to consumer devices.

Beyond Glamsterdam, another roadmap milestone is The Verge, which focuses on Verkle trees. This system restructures how Ethereum stores and verifies the network’s state. Instead of requiring full nodes to store the entire state locally, Verkle trees enable them to verify blocks with compact proofs and reduce storage requirements.

Fusaka has already addressed part of this work. It included early Verkle tree work, specifically the implementation of the Verkle state trie conversion tooling. However, the full Verkle transition is a multi-upgrade effort that will continue through Glamsterdam and beyond.

The Verge also overlaps with Ethereum’s post-quantum security roadmap. The current Verkle tree implementation uses cryptographic assumptions that a sufficiently powerful quantum computer could break. The long-term Verge implementation will need quantum-resistant proof systems, and researchers are incorporating that requirement into the work now.

As covered in our quantum resistance research, Ethereum’s Lean roadmap targets full post-quantum signature support by 2029 through seven sequential hard forks.

Ethereum’s current design requires full nodes to store the complete history of every transaction that has ever occurred on the network, going back to the genesis block in July 2015. That history now exceeds 1 terabyte of data and grows by approximately 300 gigabytes per year. As historical data accumulates, running a node becomes harder over time. The Verge’s statelessness approach does not solve this problem because it addresses state storage, not history storage.

The Purge addresses this through two mechanisms. History expiry, implemented through EIP-4444, allows nodes to discard historical block data beyond a certain age, initially 1 year and potentially shorter in future iterations, without being considered dishonest. Individual nodes do not need to store all history if the network collectively keeps that history accessible through distributed storage. This is similar to how BitTorrent distributes file storage across participants rather than requiring any single participant to hold everything.

State expiry is more complex. It involves expiring unused portions of Ethereum’s state, including account data and contract storage that has not been accessed for a long period. Participants would then need to provide proof of existence if they want to use expired state. Implementing state expiry requires the Verkle tree changes from The Verge to be in place first, making it dependent on that phase’s completion.

The Purge also includes protocol simplification. This means removing technical debt from Ethereum’s specification that has accumulated over the years. EIPs that add complexity without proportional benefit, legacy execution mechanisms that are no longer needed, and redundant features that could be removed without breaking existing applications are all candidates for removal.

Vitalik Buterin has expressed a goal of making Ethereum’s protocol specification simple enough for a single competent developer to understand and implement. The current specification does not meet that standard.

The Splurge is the catch-all phase for improvements that do not fit neatly into the other five categories but still matter to Ethereum’s long-term quality. Several components are being implemented alongside the more focused phases instead of waiting for The Splurge to begin formally.

Account Abstraction

Account abstraction is one of the most important user experience improvements in The Splurge. Ethereum currently has two types of accounts: externally-owned accounts (EOAs), whose private keys control, and contract accounts, which code controls. EOAs have several limitations. Users must manage private keys directly. They can only initiate transactions by signing with those keys. They also do not support flexible authentication schemes such as multi-signature requirements or social recovery.

EIP-7702, implemented in Pectra (May 2025), was the first major step toward account abstraction. It allows EOAs to temporarily behave like smart contracts for individual transactions. The Hegota upgrade commits to Account Abstraction as part of its minor feature set. This moves Ethereum toward a model where every wallet can support flexible authentication, sponsored transactions, where a third party pays gas on a user’s behalf, and recovery mechanisms that do not depend on a single private key.

Full account abstraction could change the user experience considerably. Today, onboarding new users to Ethereum requires them to manage private keys, buy ETH for gas, and understand the difference between wallet types. Account abstraction enables wallet designs where users authenticate with familiar methods such as fingerprint, face ID, or passkey. Applications can sponsor gas, and recovery can work without requiring users to write down a seed phrase. These changes could lower the technical barrier to Ethereum adoption.

EVM Improvements

The Ethereum Virtual Machine, the runtime environment that executes smart contract code, has received progressive improvements through various upgrades. The EVM Object Format (EOF), which restructures how contract code is organized, validated, and deployed, has been in development for years and is expected to ship in upcoming upgrades. EOF enables better code analysis by tools and optimizers. It also provides clearer separation between code and data sections and enables certain safety improvements that the current unstructured bytecode format prevents.

May 7, 2025: Shipped

Pectra (Prague + Electra)

Pectra was the broadest upgrade since The Merge. Key achievements included increasing the maximum effective validator balance from 32 ETH to 2,048 ETH, allowing large operators to consolidate validators; implementing EIP-7702, which allows EOAs to temporarily function as smart contracts; improving blob capacity and throughput; and adding several smaller improvements to the execution and consensus layers.

December 3, 2025: Shipped

Fusaka (Fulu + Osaka)

Fusaka implemented PeerDAS, expanding Ethereum’s blob capacity from 6 to approximately 48-64 per block through data availability sampling that does not require proportionally more node bandwidth. The gas limit doubled from 30 million to 60 million. Fusaka also included early Verkle tree conversion tooling. These changes represent the largest single expansion of Ethereum’s data availability capacity since Dencun.

H2 2026: Targeted

Glamsterdam

Implementation of Ethereum’s next upgrade, Glamsterdam, is well underway. Progress is slow but steady, and enshrined Proposer-Builder Separation (ePBS) is proving trickier than anticipated. The main feature is ePBS, which moves block construction into the protocol. Block-level access lists are included as a complementary feature to enable faster block validation. Gas repricing changes are also in scope. The upgrade moved from an earlier H1 2026 target to H2 2026.

2027: In Planning

Hegota (Heze + Bogota)

Hegota has chosen its major feature, FOCIL, with a commitment to work on Account Abstraction as part of the minor feature set. FOCIL (Fork-Choice Enforced Inclusion Lists) addresses transaction censorship at the protocol level. Account abstraction improvements continue the EIP-7702 work from Pectra. The full feature scope is still being finalized as of mid-2026.