202602261544-ethereum-roadmap

🎯 Core Idea

Ethereum’s roadmap is a public, evolving plan for improving the protocol’s scalability, security, sustainability, and usability. The key framing on ethereum.org is that Ethereum will scale primarily via a rollup-centric approach: most users transact on Layer 2 rollups, while Ethereum L1 provides settlement and data availability, and continues to ship protocol upgrades that make rollups cheaper and reduce the trust users must place in rollup operators.

In practice, the roadmap is best understood as a dependency graph rather than a linear timeline. Some upgrades are already shipped (for example, proto-danksharding via EIP-4844 in the Dencun upgrade), while others are multi-year research and engineering efforts (for example, full danksharding, single-slot finality, and statelessness). The roadmap also makes explicit that several improvements are about the long-run health of the network rather than immediate throughput, such as client/protocol simplification and planning for eventual post-quantum cryptography.

This card tracks the core threads described on ethereum.org and the rationale behind them: making data cheaper for rollups, strengthening the proof-of-stake protocol against reorg/censorship/DoS classes of attacks, improving wallet UX through account abstraction, and keeping node operation feasible for ordinary users through changes like Verkle trees and stateless verification models.

🌲 Branching Questions

➡ What is the roadmap optimizing for, and why is Ethereum described as rollup-centric?

Ethereum’s roadmap is optimizing for scaling without sacrificing decentralization and security. The core idea is that L1 blockspace is scarce and expensive if it is used as a general-purpose execution environment for all users, because every node must process and store the results. Rollups move execution off L1 and use Ethereum mainly as a settlement and data availability layer. This lets Ethereum keep a relatively conservative base layer while still enabling high throughput and low fees for end users on L2s.

The rollup-centric framing also acknowledges two practical constraints that show up in today’s rollup ecosystem. First, fees on rollups are dominated by the cost of publishing data back to L1, so making L1 data posting cheaper is one of the highest leverage changes Ethereum can make for user fees. Second, many rollups started with centralized components (sequencers, limited prover sets, or other trust assumptions) to bootstrap. The roadmap explicitly calls out reducing those trust requirements over time, which connects scaling work with decentralization work rather than treating them as separate concerns.

➡ How do blobs (proto-danksharding) and full danksharding reduce rollup fees, and what remains after EIP-4844 shipped?

Proto-danksharding (EIP-4844) introduces blob-carrying transactions: a cheaper, temporary data storage mechanism intended primarily for rollups. Because rollups need data to be available for verification and challenge windows but do not need it to live on-chain forever, temporary blob storage reduces costs versus permanent calldata. Ethereum’s Dencun upgrade shipped this change in March 2024, and ethereum.org describes blob data as being pruned after roughly 18 days.

Full danksharding is the follow-on design that greatly increases the available blob capacity per block, aiming to make rollup data extremely cheap at scale. ethereum.org describes a trajectory from a small number of blobs in proto-danksharding toward a much larger number in full danksharding, with the end goal of enabling very high rollup throughput and very low fees.

What remains after EIP-4844 is not just more blobs. Full danksharding requires the network to efficiently confirm data availability at much higher data volumes and introduces engineering pressures around who computes and distributes certain proofs quickly enough for the protocol’s timing constraints. This is why ethereum.org repeatedly lists prerequisites like proposer-builder separation and data availability sampling.

➡ Which roadmap items are primarily about security and censorship resistance, and how do they relate to each other?

Single-slot finality (SSF) aims to reduce time-to-finality from roughly minutes to a single slot. ethereum.org frames this as eliminating the window in which short reorgs can be exploited for MEV or censorship and simplifying the consensus machinery that has historically required patches. The roadmap also emphasizes a tradeoff triangle: faster finality increases the pressure on validator hardware and networking unless the protocol can process attestations more efficiently.

Proposer-builder separation (PBS) is presented as both an economic and censorship-resistance upgrade. By splitting block building from block proposing, the roadmap aims to avoid a world where only sophisticated, centralized operators can compete effectively due to MEV extraction, and to enable protocol-level anti-censorship mechanisms such as inclusion lists and encrypted transaction designs. PBS is also tied directly to scaling because builders may be the specialized actors capable of handling heavier workloads required by danksharding.

Secret leader election (SLE) addresses a different threat model: denial-of-service attacks that target known upcoming proposers. ethereum.org notes that today’s proposer schedule is public and can be mapped to IPs, creating a DoS risk that especially harms home validators and can be exploited for profit. SLE designs aim to keep proposer identities hidden until the moment they propose, reducing the attack surface.

Together, these items push Ethereum toward a model where proposers are harder to target, block contents are harder to censor by a small set of actors, and finality is achieved fast enough to reduce the value of short-term manipulation.

➡ What is the path toward nodes for everyone, and what trade-offs does it introduce?

The roadmap treats the ability to run a node on modest hardware as foundational for decentralization. ethereum.org highlights that disk requirements and unbounded state growth are major barriers today, and that making data cheaper alone is not sufficient if storage requirements keep growing without bound.

Verkle trees are positioned as a critical enabling step. They change Ethereum’s state data structure so that compact witnesses can prove the correctness of state accesses and updates. With witnesses small enough to propagate quickly, validators can verify blocks without needing a full local state database, which is the core promise of stateless clients.

The broader statelessness and expiry cluster includes history expiry, state expiry, and weak statelessness. ethereum.org describes these as research-phase, long-horizon changes that shift how historical and state data is stored and served. A central trade-off is that if ordinary nodes do not store all history or state, the ecosystem must still ensure data availability through other mechanisms (peer-to-peer networks, specialized archival providers, rollup operators, or other community infrastructure). That introduces new coordination and potential centralization risks, even if the protocol can verify correctness given at least one honest source.