⠀
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
⠀
December 1st, 2020 - Beacon chain launch
The introduction of Ethereum’s consensus layer secured by the ETH staked by validators.
Known as Phase 0 in the consensus specifications (annotated version by Vitalik and Danny Ryan).
October 27th, 2021 - Warmup fork (Altair) – Consensus client developpers had a trial run at coordinating a hard fork upgrade.
Altair introduced sync committees to support light clients, and tweaked some penalties.
Altair Announcement
Altair specifications (annotated version)
“What’s new in ETH2” edition about Altair
September 15, 2022 - Merge! No more PoW – The big merge between the consensus layer and the execution layer, at block number 15,537,394.
⠀
What’s next
⠀
Withdrawals – Enabling validators to withdraw all or part of their stake.
Capella fork specifies the changes on the consensus layer
EIP-4895 specifies the changes on the execution layer
Tim Beiko’s FAQ about withdrawals
Withdrawals meta-spec with other information
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
Explainer post on the benefits of BLS aggregation
Potential candidate: Horn
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 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 Scourge
⠀
Goal: ensure reliable and credibly neutral transaction inclusion and avoid centralization and other protocol risks from MEV.
⠀
Relevant links:
⠀
Credible Neutrality as a Guiding Principle
Various twitter threads about MEV
Write-up about MEV and PBS
List of links about PBS
⠀
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.
This solution by itself incomplete as it has issues with censorship.
See the Cost of Resilience and SUAVE for ideas and plans to make these extra-protocol markets more resilient.
⠀
What’s next
⠀
Inclusion lists or alternative – Let proposers put restrictions on block builders, namely to force them to include transactions.
Inclusion list notes.
Research into constraining builders without burdening proposers.
In-protocol PBS – Enshrine a block builder’s market directly in the protocol.
MEV burn – Letting the blockchain capture value that is otherwise extracted from the on-chain economy.
Direct MEV burn proposal through proposer auction.
Committee-driven MEV smoothing would render the protocol aware of MEV.
Capping the validator set through economic incentives would indirectly burn MEV through negative issuance.
Application-layer MEV minimization — Not directly L1-related, this item involves developpers keeping MEV in mind when designing their dapps. Here are a few examples of dapps that employ MEV minimization tactics.
⠀
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:
⠀
Talk on Block building after the merge which mentions decentralized block building
Talk on decentralizing builders
Some ideas regarding distributed block building.
⠀
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:
⠀
An approximate introduction to how zk-SNARKs are possible
Anatomy of a STARK
zkSNARKS explained like you’re someone who knows some math and some coding
On the role of Polynomial Commitment Schemes in scaling Ethereum.
⠀
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
⠀
EIP-4844 implementation – roll out EIP-4844 to mainnet
Will require a “ceremony” to create the trusted setup: Explanation, estimated timeline, specifications
Overview of EIP4844 implementation timeline
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
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
See this post on enshrined rollups
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
See this twitter thread
Relies on implementation of EIP-4444, which is contingent on alternate history access through other means (like Portal Network)
Vitalik’s AMA on History Expiry
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
Pragmatic destruction of SELFDESTRUCT explains the why and how of removing this opcode
Relevant EIPs: EIP-4758 and EIP-4760 and discussion
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
⠀
EIP-1559 — This famous EIP came with many benefits beyond just burning ETH
ERC-4337 specification — This ERC aims at introducing Account Abstraction without modifying the core protocol
Initial explainer on ERC-4337.
⠀
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. See this explainer piece and twitter thread
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
See this ethresear.ch post about VDFs and their potential use
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
