Crypto Gloss

Ethereum Roadmap

Ethereum’s roadmap describes a foundational shift from “build a computer and see what people build on it” to “complete a complex, multi-year engineering program to scale this specific kind of computer.” After The Merge (completed September 2022), Ethereum shifted from Proof-of-Work to Proof-of-Stake — the first major roadmap milestone. What follows is a structured plan to scale Ethereum’s throughput to ~100,000+ transactions per second through rollups, reduce the centralization pressures from MEV, make the state manageable to run on commodity hardware, and improve the full-node experience until any consumer laptop can validate the full chain. Vitalik Buterin maintains and updates the roadmap; the canonical view is a hexagonal diagram showing six “phases” that simultaneously build toward a complete system. No phase is strictly sequential — progress happens in parallel across all six.

The Six Phases Overview

Phase Status Primary Goal
The Merge ✅ Complete (Sep 2022) PoW → PoS transition
The Surge 🔄 In Progress 100,000+ TPS via rollup scaling
The Scourge 🔄 Research/Planning MEV minimization, censorship resistance
The Verge 🔄 Active Development Stateless clients via Verkle trees
The Purge 🔄 EIP stages History/state expiry, simplify protocol
The Splurge 🔄 Research Remaining improvements

The Merge (Complete)

What happened (Sep 15, 2022):

  • Ethereum transitioned from Proof-of-Work to Proof-of-Stake
  • Energy consumption reduced ~99.95%
  • Issuance dropped ~90% (no miner block rewards)
  • Foundation for all future roadmap phases was established

Key properties enabled:

  • Validator-based consensus (enables future PBS, single-slot finality)
  • Reduced issuance (ETH supply dynamics changed)
  • The “Paris” fork + Beacon Chain merge

The Surge: Scaling via Rollups + Danksharding

The Surge is Ethereum’s scaling roadmap — targeting 100,000+ TPS for the overall Ethereum ecosystem.

EIP-4844 / Proto-Danksharding (Complete, Dencun Upgrade, March 2024)

What it did:

  • Introduced “blobs” — a new transaction type specifically for rollup data
  • Blobs are attached to blocks but stored only temporarily (~18 days)
  • Key insight: rollups only need data available long enough for fraud provers to challenge (optimistic) or for users to reconstruct state; permanent storage is wasteful
  • Result: Rollup transaction costs dropped 10–100x after Dencun; OP, ARB, Base saw fee reductions from $0.50+ to <$0.01

Numbers:

  • Each block: 3 target blobs, 6 maximum blobs (EIP-4844)
  • Each blob: ~128KB
  • Temporary availability window: ~18 days

Full Danksharding (Planned, 2025–2028)

Full Danksharding is the complete vision — scaling from ~0.375 MB/block blob space to ~128 MB/block:

Data Availability Sampling (DAS):

  • Nodes don’t download all blob data — they randomly sample small chunks
  • If enough nodes together sample all chunks, the full blob data must be available
  • This allows light clients to verify data availability without downloading 128MB/block

Erasure Coding:

  • Blob data is redundantly encoded (2D Reed-Solomon)
  • A node only needs any 50% of encoded chunks to reconstruct 100% of original data
  • Enables DAS to work with probabilistic guarantees

Result when complete: 128 MB/block blob capacity → supports thousands of rollup transactions per second at near-zero cost

Rollup-Centric Scaling Philosophy

Ethereum’s current approach: don’t scale the base layer for execution; let rollups handle execution; scale the base layer for DATA (blob availability).

Why this works: Rollups (Arbitrum, Optimism, Base, zkSync, etc.) inherit Ethereum security but execute off-chain. They only need to post data or validity proofs to Ethereum. Danksharding makes this data posting extremely cheap at scale.

The Scourge: MEV and Censorship Resistance

The Scourge addresses MEV (Maximal Extractable Value) — the value extracted by block producers through transaction ordering — and its centralizing effects.

Proposer-Builder Separation (PBS)

Problem: Currently, block proposers (validators) also build blocks — they choose transaction ordering, enabling MEV extraction. This creates pressure toward centralization (big players with better MEV extraction attract more stake).

PBS solution:

  • Block builders: Specialized entities that construct optimal block orderings (maximize fee revenue + MEV)
  • Block proposers: Validators who simply choose the highest-bidding block builder’s block and sign/propose it
  • Separation: Proposers don’t know block contents (blind signing) — they can’t MEV-extract themselves; they just earn the bid

Current state: MEV-Boost (Flashbots) is an off-protocol PBS implementation; already used by ~90% of validators. Enshrined PBS (ePBS) would make this part of the Ethereum protocol itself, removing centralized relay dependency.

FOCIL (Fork Choice Enforced Inclusion Lists)

Problem: Builders (who create blocks) can censor specific transactions by excluding them.

FOCIL solution:

  • Validators create an “inclusion list” of transactions they observe in mempool
  • Block builders MUST include transactions from the inclusion list
  • Builders retain ordering freedom; validators enforce inclusion
  • Censorship cost: a builder would need validators to voluntarily leave a transaction out, which requires majority validator collusion

Attester-Proposer Separation (APS)

Future upgrade: separate the proposer role further so that large staking entities (Lido, Coinbase) have less influence over individual block contents.

The Verge: Stateless Clients via Verkle Trees

The Verge is about removing the requirement for Ethereum nodes to store the full state.

The State Problem

Current Ethereum “state” (all account balances, contract storage, code): ~200GB and growing

Full node requirement today: Download and maintain 200GB+ of state plus historical data

Problem: This excludes mobile devices, consumer laptops (without SSDs), and IoT from running full nodes — centralizing validation to professional operators with large storage.

Verkle Trees

Current Ethereum data structure: Merkle Patricia Trie (MPT)

  • To prove a specific account’s balance: need a “witness” containing ~50 intermediate hashes
  • Witness size: ~2KB per account

Verkle Tree (replacement):

  • Polynomial commitment-based structure
  • Proof of account state: ~150 bytes per account (15x smaller)
  • Key property: A full state witness for any “stateless” block validation can fit in reasonable size

Stateless validation (goal):

  • Block producers include a “witness” proving all state accessed during block execution
  • Validators can verify a block WITHOUT storing any state locally
  • Only the witness data (produced with the block) is needed
  • Full node can operate with near-zero storage

Verkle tree migration: Requires converting Ethereum’s existing MPT to Verkle tree format — complex, one-time in-protocol migration

The Purge: History Expiry and Protocol Simplification

EIP-4444 (History Expiry):

  • Full nodes no longer required to serve historical data older than 1 year
  • Historical data becomes the responsibility of specialized archival services (Portal Network, EthStorage, The Graph)
  • Reduces full node storage requirements significantly

State Expiry (Research Stage):

  • Inactive state (accounts, contracts not touched in N years) “expires” and is removed from active state
  • Users can “revive” expired state by providing a proof of what the state was
  • Reduces growing state problem — but complex because applications must handle state revival

Protocol Simplification:

  • Remove legacy transaction types, opcodes, and edge cases accumulated since 2015
  • Simplify the Ethereum gas model
  • Reduce overall protocol surface area → fewer bugs, easier to implement new clients

The Splurge: Remaining Improvements

The Splurge covers miscellaneous important upgrades:

EIP-1559 improvements: Better fee market stability; current “max base fee” mechanism still has edge cases

Account Abstraction (ERC-4337 on-chain / EIP-7702): Fully native smart contract wallets including gas sponsorship, batched transactions, social recovery; 2024 Pectra upgrade included EIP-7702 for quasi-native AA

VDF (Verifiable Delay Functions): RANDAO manipulation resistant randomness — prevents validators from influencing block randomness by withholding attestations; needed for secure randomness in certain applications

Single-Slot Finality: Currently Ethereum finalizes blocks after 2 epochs (~12 minutes). Single-slot finality would finalize each slot (~12 seconds) — dramatically improving user experience for applications requiring finality before proceeding.

Progress Tracker

Completed:

  • ✅ The Merge (Sep 2022)
  • ✅ EIP-4844 / Proto-Danksharding blob transactions (Dencun, March 2024)
  • ✅ EIP-7702 account abstraction basics (Pectra, May 2025)

Active/Near-term:

  • 🔄 Verkle tree implementation and testing
  • 🔄 ePBS design finalization
  • 🔄 FOCIL implementation
  • 🔄 Full Danksharding DAS research
  • 🔄 EIP-4444 history expiry testing

Social Media Sentiment

The Ethereum roadmap is simultaneously one of the most ambitious engineering programs in software and a source of perennial “when shipping” criticism. The Dencun upgrade’s EIP-4844 blob transactions were broadly celebrated as a genuine milestone — rollup fees dropped dramatically immediately after launch, validating the rollup-centric scaling thesis. Verkle trees are seen as the most technically challenging near-term upgrade; progress has been steady but slow. The PBS/FOCIL/Scourge work is well-received by researchers but less visible to everyday users. Single-slot finality is the most anticipated UX improvement. The criticism that Ethereum keeps “moving the goalposts” (roadmap phases shifted vs. original plans) is partly valid — many upgrades took longer than projected — but the eventual delivery of each phase (Merge took 7 years from conception) demonstrates the core team’s execution ability. Solana’s parallel fast-block architecture puts pressure on Ethereum to deliver The Surge; rollup fee reductions from EIP-4844 have been the most impactful near-term response.

Last updated: 2026-04

Related Terms

Sources

Buterin, V. (2023). Ethereum Roadmap Overview. ethereum.org/en/roadmap/.

Dankrad Feist, Buterin, V., & others. (2022). EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposal 4844.

Buterin, V. (2022). A Nearly Last Call for EIP-4444. ethereum-magicians.org.

Feist, D., et al. (2021). From 4844 to Danksharding: A Path to Scaling Ethereum DA. Ethereum Research Forum.

Buterin, V. (2023). Verkle Trees for Ethereum Block Witnesses. ethereum.org/en/roadmap/verkle-trees/.