Annotated Ethereum Roadmap

Table of Contents

This document aims to serve as an entry point for the various items on the Ethereum roadmap, with a quick summary along with links for those who want to dive deeper.

It is meant as a living document, feel free to contact me if any of the information presented here is unclear, inaccurate, outdated or missing better links.

Note: As indicated by arrows on the roadmap, the various stages listed are not consecutive, various efforts are happening in parallel.

The Merge

Goal: Have an ideal, simple, robust and decentralized proof-of-stake consensus

What’s done

What’s next

  • Secret leader election (SLE)
    • Today, the validator selected to propose a block (the leader of the slot) is known a bit ahead of time, enabling a potential DoS attack specifically targetting leaders of upcoming blocks
    • ethresear.ch post about a Single SLE protocol based on random shuffling: No one knows who will be the slot’s leader except the leader themselves, until they reveal their block along with a proof of their leadership
    • non-single secret leader election might be an option too
  • Single Slot Finality — Finalize the chain every slot (12 seconds) instead of every other epoch (12.8 minutes), relies on:
    • Per-slot participation selection — Figure out the best SSF-compatible way to choose how validators are selected to attest to slots, aggregate signatures, etc.
    • SSF specification — Figure out the best way to do Single Slot Finality
  • Increase validator count — Once we have SSF, having more validators participate as hardware/bandwidth becomes better is a good ongoing goal (somewhat similar to gas limit increases, etc.)
  • Quantum-safe aggregation-friendly signatures - Part of the long-term effort to make Ethereum safe from quantum computers before it becomes a plausible concern
    • The cryptography underlying the BLS signature scheme used is known to be broken by quantum computers, but the alternative signatures schemes known to be quantum-safe aren’t as efficiently aggregated as BLS (Hence the need for a scheme that is both quantum-safe and aggregation-friendly)
    • The two leading quantum-safe approaches are STARK-based and Lattice-based

The Surge

Goal: 100,000 transactions per second and beyond (on rollups)

“on rollups” is key – The Surger will not result in 100,000 TPS on Layer 1. Changes made to Ethereum’s core protocol all aim at helping rollups scale massively.

A key concept underlying The Surge is Data Availability (or DA): the endgame involves making the availability of data itself a validity check: Just like nodes won’t follow a fork containing an invalid state transition (e.g. someone arbitrarility printing themselves millions of ETH), nodes won’t follow a fork with unavailable data – which is critical for fully trustless scaling via rollups.

Here are some relevant links to familiarize yourself with the concepts underlying The Surge:

What’s done

  • EIP-4844 specification - see eip4844.com for more info and a FAQ
    • Specs found here for the execution layer and here for consensus layer
    • The KZG ceremony also happened flawlessly
  • (Prototype) Optimistic rollup fraud provers – Allows anyone to submit a proof that a rollup sequencer acted maliciously
  • (Prototype) ZK-EVMS – A single rollup sequencers creates a proof of EVM computation that can be verified quickly and cheaply by everyone else (including a smart contract on L1)

What’s next

  • EIP-4844 implementation – roll out EIP-4844 to mainnet (schedule for the Dencun upgrade ~Q1 2024)
  • Basic rollup scaling - relies on the following:
    • EIP-4844 - The scaling is still deemed basic/limited, due to the nature of “every node downloads all the data” restricting the viable capacity of blobspace
    • Limited training wheels for rollups (see the proposed milestones)
  • Full rollup scaling - relies on:
    • peerDAS — a design for safely expanding Ethereum’s blobspace beyond 4844’s parameters
    • Efficient DA self-healing: Being able to efficiently reconstitute all the data in the harshest network conditions (e.g. malicious validators attacking, or prolonged downtime of a big chunk of nodes)
    • No training wheels for rollups: fully decentralized sequencers, trustless fraud provers, immutable contracts, etc.
  • Quantum-safe, trusted-setup-free commitments — Part of the long-term effort to make Ethereum safe from quantum computers before it becomes a plausible concern
    • While efficient and powerful, the polynomial commitment used everywhere (KZG) is not quantum-safe and requires a trusted setup. Research into a more ideal commitment suitable for the long term is ongoing, with the eventual goal to “hot swap” KZG under the hood (it’ll probably be STARKs)

The Scourge

Goal: mitigate centralization concerns in the Ethereum PoS design, particularly around MEV and liquid staking / pooling

Relevant links:

What’s done

  • Extra-protocol MEV markets – The MEV-Boost middleware allows the average validator to profit from MEV without having to run sophisticated MEV strategies themselves.

What’s next

MEV track

Staking economics / experience track

  • Raise max effective balance – Enable the consolidation of large stakers into a single validator, drastically lowering the number of attestations to reduce bandwidth load on the beacon chain
  • Improve node operator usability — See other items like Verkle trees and SNARKs that make validator clients much more light weight, but also UX improvements are welcome in here too (e.g. make running a node a simple install-and-run experience)
  • Reducing minimum balance — 32 ETH is a big deterrant for solo staking, reducing it is becoming more and more of a security
    • The Paths to SSF document highlights several potential staking designs where the 32 ETH minimum is reduced or outright removed
  • Explore solutions to liquid staking centralization — Mitigating centralization concerns around big liquid staking pools controlling

The Verge

Goal: verifying blocks should be super easy - download N bytes of data, perform a few basic computations, verify a SNARK and you’re done

This section is essentially about filling “the client gap” by making light clients finally viable: Not everyone wants to or can run a full node. The Verge aims to introduce trustless or trust-minimized alternatives that are easy to run and don’t require a lot of storage and bandwidth. The ultimate endgame of The Verge is having these light clients provide security guarantees that are equal to today’s full nodes.

Everything relies on zero-knowledge technology such as SNARKs and STARKs, which themselves rely on polynomial commitment schemes. Here are some links about that:

What’s done

  • Most serious EVM DoS issues solved – Mainly gas pricing issues, fixed in the Berlin upgrade
  • Basic light client support (sync committees) – Thanks to sync committees, it is easy to build light clients that follow the consensus layer
    • See how Helios client is leveraging sync committees (with a good write-up on how these committees work)
  • Verkle tree specification and implementation — The plan for how Verkle trees are going to work is coming along nicely!

What’s next

  • SNARK-based light clients – SNARKify the sync committee transition to quickly prove which validators form the current sync committee
    • Helios is working on leveraging the power of SNARKs in their light client implementation
  • Verkle trees - Replace the data structure used for the global state by a more efficient one, making state proofs much shorter (enabling stateless clients!) as well as more zk-friendly
  • Fully SNARKed Ethereum – The following 3 items put together constitute a major milestone toward Ethereum’s Endgame of having extremely efficient and trustless block verification:
    • SNARK for Verkle proofs – By merging Verkle proofs into a single SNARK, blocks will contain a short standalone proof about the parts of the state they modify, so it won’t be necessary to verify the whole state of block N-1 to verify that block N modified it correctly.
    • SNARK for consensus state transition – Move away from the merely trust-minimized sync committees onto fully trustless verification of everything happening on the consensus layer
    • SNARK for L1 EVM — Leveraging the efforts done by rollup teams on zk-EVM by integrating it in L1 directly
  • Explore EVM verification precompile — Being able to verify EVM execution inside the EVM itself, inception-style. More detail here
  • SNARK / STARK ASICs – Having hardware specifically designed to be fast at crafting SNARK or STARK proofs
  • Move to quantum-safe SNARKs (e.g. STARKs) – Part of the long-term effort to make Ethereum safe from quantum computers before it becomes a plausible concern
    • SNARKs are efficient be rely on cryptography known to be broken by quantum computers, while STARKs aren’t

The Purge

Goal: simplify the protocol, eliminate technical debt and limit costs of participating in the network by clearing old history

What’s done

  • Most serious EVM Denial-of-Service issues solved - Mostly solved by all the gas repricings done in the Berlin upgrade
  • Beacon chain fast sync – All the development effort towards syncing from a recent finalized epoch rather than from genesis (known as “checkpoint sync” in most consensus clients)
  • EIP-4444 specification – See the EIP specification

What’s next

  • History Expiry — Reduces storage requirements, sync time and code complexity by letting old history expire
  • State expiry – Fix the whole “pay once, have your data stored forever by everyone” problem regarding the state
    • The idea is to automatically expire unused portions of the state and only keeping a verkle tree root that users can use to revive expired state should they need it
    • Vitalik’s AMA on State Expiry
    • Relies on:
      • Address space extension — Increase the size of addresses from 20 bytes to 32 bytes to protect against collisions and add data about the state’s period
      • Application analysis — Figure out how it might break current applications/contracts and how they can adapt
  • LOG reform — Simplify the way event logs work to allow more efficiently searching of historical events
  • Serialization harmonization — The execution layer uses RLP for data serialization, while the consensus layer uses SSZ this would get rid of RLP in favor of using SSZ everywhere
  • Remove old transaction types — Stop supporting old transaction types (see EIP-2718) to remove code complexity from clients (at the cost of some backwards compatibility)
  • EVM simplification track
    • Ban SELFDESTRUCT — This opcode is the root of many problems
    • Simplify gas mechanics — Involves removing a lot of gas-related EVM features mentioned here
    • Precompiles -> EVM implementations — Get rid of precompiled contracts in favor of direct EVM implementations (namely big modular arithmetic, see The Splurge)

The Splurge

Goal: Fix everything else

All the nice-to-have things that aren’t required for the higher priority stuff belong in The Splurge. The biggest item is account abstraction, but also small tweaks to existing things.

What’s done

What’s next

  • Endgame EIP-1559 – Enhance EIP-1559 by making it multidimensional, more like an AMM-curve and time-aware
  • EVM improvement track along with the simplification track from The Purge leading to the EVM endgame
    • EVM Object Format (EOF) — A set of multiples EIPs allowing validating and versioning EVM bytecode when it is deployed. Various explainers: [1], [2], [3]
    • Big modular arithemetic – A lot of the roadmap’s cryptography relies on modular arithmetic over very large numbers, which could be done more efficiently in the EVM directly
    • Further EVM improvements — Anything else that’s worth adding to improve the EVM – or removing to get rid of complexity
  • Account abstraction track leading to the Endgame account abstraction. See Vitalik’s descriptions on the following items for more detail:
    • ERC-4337 – Developing compliant smart wallets that actually gain adoption
    • Voluntary EOA conversion — With an EIP, allow a normal account to irreversibly add code to convert into it into a contract, namely to become a 4337-compliant smart wallet.
    • In-protocol enshrining — Make the above conversion mandatory for all existing accounts
  • Verifiable Delay Functions (VDFs) — Essentially “non-parallelizable proof of work” which would enhance the randomness used in PoS and other things
  • Explore solution for dust accounts – Rescuing “dust funds” that costs more gas fees to move than they are worth. See a bunch of ideas here
  • Explore deep cryptography, stay up-to-date with latest cryptographic magic to see how it can be integrated inside net cryptoeconomic gadgets. Things like:
  • Explore delay-encrypted mempools — To enhance mempool privacy, reduce censorship, reduce toxic MEV