Annotated Ethereum Roadmap

November 24, 2022

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

  • Withdrawals – Enabling validators to withdraw all or part of their stake
  • Distributed validators – “multisig but for staking”, where n people share the same validator and m-of-n have to agree on how it behaves
    • Enhances staking by protecting against accidental slashing, and making it more accessible (e.g. by trustlessly splitting the 32 ETH required among multiple participants)
    • This is not an in-protocol thing, teams such as SSV and Obol are working on it
  • View merge – Tweaks the fork-choice rule (the way validators vote) to mitigate a class of attacks
    • Essentially enables honest validators to “impose” their view of what the correct head of the chain is, to reduce the chance that malicious validators can split the vote and later reorganize blocks in their favor
    • ethresear.ch post with a lot of (very technical) background on the research
  • Improved aggregation — Ethereum strives to support as many validators as possible, but having every validator vote on every block (and verify every other validator’s vote) is too bandwidth-intensive. The next best thing is aggregating signatures, but that too has its limits and can be better
  • Single slot finality (SSF) — Finalize the chain every slot (12 seconds) instead of every other epoch (12.8 minutes)
    • Paths toward SSF
    • Along with improved signature aggregation, we still have to figure out two more things:
      • SSF consensus algorithm - Existing algorithms compatible with SSF aren’t sufficient, we want one that keeps the chain live even if over $\frac{1}{3}$ of validators are offline
      • SSF validator economics - If we end up having to limit the number of validators, how do we limit participation, and what sacrifices do we make?
  • 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
  • Support even more validators - Ongoing long-term effort: safely supporting more validators is always desirable
  • 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)

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

What’s next

  • EIP-4844 implementation – roll out EIP-4844 to mainnet
  • 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:
    • P2P design for Data Availability Sampling: Involves all the effort and research into the networking required for data sharding
    • DA sampling clients: Development of light-weight clients that can quickly tell if data is available or not through random sampling a few kilobytes
    • 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 and 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

The Scourge

Goal: ensure reliable and credibly neutral transaction inclusion and avoid centralization and other protocol risks from MEV

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

Distributed builder track

With block proposal staying decentralized, we now have a separate problem where block building becomes centralized. Even with all the other items on the roadmap aiming at minimizing the worst possible downsides of centralized block building, it would still be a major benefit to be able to distribute block building across many nodes.

  • Blob construction - Finding ways to alleviate the high bandwidth and processing requirements of data sharding across many nodes that average consumer hardware can run
  • Pre-confirmation services - Giving users strong assurances that their transaction will be included in the next block
  • Frontrunning protection - Minimizing toxic MEV like sandwiching to keep distributed building credibly neutral

It is still an active area of research with very open design considerations, so it is unclear if the previous two items should get enshrined in the protocol (hence the question marks on the roadmap diagram)

Here are some relevant links:

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)

What’s next

  • SNARK / STARK ASICs – Hardware built specially to create proofs
  • Verkle trees - Replace the data structure used for the global state by a more efficient one
    • List of links about Verkle Trees
    • The key benefit is having very short proofs that are easily verified by light clients to validate things like account balances using only the block header – they can already leverage sync committees to validate that a given block header is actually part of the main chain
    • Relies on figure out the proper specification, how to safely transition, and how it will affect the EVM gas costs of updating/editing the state (also relies on banning SELF-DESTRUCT from The Purge)
  • SNARK-based light clients – SNARKify the sync committee transition to quickly prove which validators form the current sync committee
  • 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 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
  • Increase L1 gas limits – By removing today’s burden of “every node needs to store everything” to trustlessly verify blocks, it will be easier to have bigger blocks for more L1 scalability (which will automatically compound all the L2 scaling)
  • 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

  • Eliminate most gas refunds - 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” 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:
      • Base state expiry spec — How we actually do it, see a potential roadmap (and other options)
      • 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