# Annotated Ethereum Roadmap This document aims to serve as an entry point for the various items on [the Ethereum roadmap](https://storage.googleapis.com/ethereum-hackmd/upload_1a45d0f8e3eff90c4832d9cb2700a441.jpg), 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](https://twitter.com/domothy) 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](https://github.com/ethereum/consensus-specs/tree/dev/specs/phase0) (annotated version by [Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md) and [Danny Ryan](https://notes.ethereum.org/@djrtwo/Bkn3zpwxB)) * October 27th, 2021 - **Warmup fork (Altair)** – Consensus client developpers had a trial run at coordinating a hard fork upgrade * Altair introduced *[sync committees](https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md#introduction)* to support light clients, and tweaked some penalties. * [Altair Announcement](https://blog.ethereum.org/2021/10/05/altair-announcement) * [Altair specifications](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair) ([annotated version](https://github.com/ethereum/annotated-spec/blob/master/altair/beacon-chain.md)) * ["What's new in ETH2" edition about Altair](https://hackmd.io/@benjaminion/eth2_news/https%3A%2F%2Fhackmd.io%2F%40benjaminion%2Fwnie2_211105) * September 15, 2022 - **Merge! No more PoW** – The big merge between the consensus layer and the execution layer, at [block number 15,537,394](https://etherscan.io/block/15537394) ### What's next * **Withdrawals** – Enabling validators to withdraw all or part of their stake * [Capella fork](https://github.com/ethereum/consensus-specs/tree/dev/specs/capella) specifies the changes on the consensus layer * [EIP-4895](https://eips.ethereum.org/EIPS/eip-4895) specifies the changes on the execution layer * [Tim Beiko's FAQ about withdrawals](https://github.com/timbeiko/eth-roadmap-faq#withdrawals) * [Withdrawals meta-spec](https://notes.ethereum.org/@ralexstokes/validator-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](https://ssv.network) and [Obol](https://obol.tech/) 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](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) 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](https://www.reddit.com/r/ethfinance/comments/usvce5/explained_how_bls_signatures_give_ethereum_a/) * Potential candidate: [Horn](https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219) * **Single slot finality (SSF)** — Finalize the chain every slot (12 seconds) instead of every other epoch (12.8 minutes) * [Paths toward SSF](https://notes.ethereum.org/@vbuterin/single_slot_finality) * 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](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763) 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](https://ethresear.ch/t/secret-non-single-leader-election/11789) 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](https://hackmd.io/@vbuterin/stark_aggregation) 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](https://nakamoto.com/credible-neutrality/) * [Various twitter threads about MEV](https://twitter.com/bertcmiller/status/1402665992422047747) * [Write-up about MEV and PBS](https://pseudotheos.mirror.xyz/i7sv9SFb1e64W2ax_kYwp68O0M2NdACtOu9Hj12SPP8) * [List of links about PBS](https://notes.ethereum.org/@domothy/pbs_links) ### What's done * **Extra-protocol MEV markets** – The [MEV-Boost](https://github.com/flashbots/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](https://www.mevwatch.info/) * See [the Cost of Resilience](https://writings.flashbots.net/the-cost-of-resilience/) and [SUAVE](https://writings.flashbots.net/the-future-of-mev-is-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](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) * [Research into constraining builders without burdening proposers](https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808) * **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](https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029) * [Committee-driven MEV smoothing](https://ethresear.ch/t/committee-driven-mev-smoothing/10408) would render the protocol aware of MEV * [Capping the validator set through economic incentives](https://notes.ethereum.org/@vbuterin/single_slot_finality#Economic-capping-of-total-deposits) 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](https://www.mev.wiki/solutions/mev-minimization) 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](https://www.youtube.com/watch?v=KP5ppCRH0iM) which mentions decentralized block building * Talk on [decentralizing builders](https://www.youtube.com/watch?v=fAgrIdyWIqc) * [Some ideas regarding distributed block building](https://github.com/flashbots/mev-boost/issues/139) ## 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"](https://www.reddit.com/r/ethereum/comments/ryk3it/my_first_impressions_of_web3/hrrz15r/) 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](https://vitalik.ca/general/2021/01/26/snarks.html) * [Anatomy of a STARK](https://aszepieniec.github.io/stark-anatomy/) * [zkSNARKS explained like you're someone who knows some math and some coding](https://www.reddit.com/r/zkTech/comments/tfjvrj/zksnarks_explained_like_youre_someone_who_knows/) * [On the role of Polynomial Commitment Schemes in scaling Ethereum](https://scroll.io/blog/kzg) ### What's done * **Most serious EVM DoS issues solved** – Mainly gas pricing issues, [fixed in the Berlin upgrade](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80) * **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](https://a16zcrypto.com/building-helios-ethereum-light-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](https://twitter.com/trent_vanepps/status/1573342059129229312), [estimated timeline](https://notes.ethereum.org/@CarlBeek/kzg_ceremony_timelines), [specifications](https://github.com/ethereum/kzg-ceremony-specs) * [Overview of EIP4844 implementation timeline](https://twitter.com/liamihorne/status/1595592154650288129) * **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](https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571/6)) * **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](https://notes.ethereum.org/@domothy/verkle_links) * 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](https://vitalik.ca/general/2021/12/06/endgame.html) 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](https://www.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022/if7auu7/?context=1) * **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](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80) 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](https://eips.ethereum.org/EIPS/eip-4444) ### What's next * **History Expiry** — Reduces storage requirements, sync time and code complexity by letting old history expire * See this [twitter thread](https://twitter.com/lightclients/status/1462576116359569411) * Relies on implementation of EIP-4444, which is contingent on **alternate history access** through other means (like [Portal Network](https://www.portal.network/)) * [Vitalik's AMA on History Expiry](https://www.reddit.com/r/ethereum/comments/qzvsfq/impromptu_technical_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](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) * Relies on: * **Base state expiry spec** — How we actually do it, see [a potential roadmap](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) (and other [options](https://hackmd.io/@vbuterin/state_expiry_paths)) * **Address space extension** — [Increase the size of addresses](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) 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](https://ethereum.github.io/execution-specs/autoapi/ethereum/frontier/bloom/index.html) work to allow more efficiently searching of historical events * **Serialization harmonization** — The execution layer uses [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/) for data serialization, while the consensus layer uses [SSZ](https://ethereum.org/en/developers/docs/data-structures-and-encoding/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](https://eips.ethereum.org/EIPS/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](https://hackmd.io/@vbuterin/selfdestruct) explains the why and how of removing this opcode * Relevant EIPs: [EIP-4758](https://eips.ethereum.org/EIPS/eip-4758) and [EIP-4760](https://eips.ethereum.org/EIPS/eip-4760) and [discussion](https://ethereum-magicians.org/t/eip-4758-deactivate-selfdestruct/8710) * **Simplify gas mechanics** — Involves removing a lot of gas-related EVM features mentioned [here](https://hackmd.io/@vbuterin/evm_feature_removing) * **Precompiles -> EVM implementations** — Get rid of [precompiled contracts](https://www.evm.codes/precompiled?fork=merge) 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](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/account-abstraction/), but also small tweaks to existing things. ### What's done * **EIP-1559** — This famous [EIP](https://eips.ethereum.org/EIPS/eip-1559) came with [many benefits](https://mirror.xyz/domothy.eth/eY7ZM06oXF-m4xughor2nzXapPJ6TxCqRsVzFxzQsbs) beyond just burning ETH * **ERC-4337 specification** — This [ERC](https://eips.ethereum.org/EIPS/eip-4337) aims at introducing Account Abstraction without modifying the core protocol * [Initial explainer on ERC-4337](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a) ### What's next * **Endgame EIP-1559** – Enhance EIP-1559 by making it [multidimensional](https://ethresear.ch/t/multidimensional-eip-1559/11651), [more like an AMM-curve](https://ethresear.ch/t/make-eip-1559-more-like-an-amm-curve/9082) and [time-aware](https://eips.ethereum.org/EIPS/eip-4396) * **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]](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), [[2]](https://twitter.com/lightclients/status/1593270266909450241), [[3]](https://www.reddit.com/r/ethereum/comments/ztso6h/a_simple_explanation_of_eof_evm_object_format/) * **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](https://hackmd.io/@vbuterin/evm_feature_removing) to get rid of complexity * **Account abstraction track** leading to the **Endgame account abstraction**. See [Vitalik's descriptions](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Convert-an-EOA-into-a-smart-contract-wallet) 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](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#aside-randao-seeds-and-committee-generation) and other things * See [this ethresear.ch post](https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365) 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](https://ethereum-magicians.org/t/some-medium-term-dust-cleanup-ideas/6287)