Learn about the implementation progress of the Ethereum roadmap in one article
Compilation of the original text: The Way of DeFi
Compilation of the original text: The Way of DeFi
Note: This document is intended to serve as an entry point for various projects on the Ethereum roadmap, providing a quick summary and links for those who want to delve deeper.
It is a living document, please feel free to contact me if any information provided here is unclear, inaccurate, out of date, or lacks better links.
As indicated by the arrows on the roadmap, the phases listed are not sequential and the various efforts are happening in parallel.
1. The Merge
Goal: To have an ideal, simple, robust and decentralized Proof of Stake (PoS) consensus.
what has been done
1. December 1, 2020 - Beacon chain launched.
Introducing an Ethereum consensus layer secured by ETH staked by validators;
Called Phase 0 in the consensus specification (Vitalik and Danny Ryan's annotated version);
2. October 27, 2021 - Warm up fork (Altair) - Consensus client developers trial run a coordinated hard fork upgrade.
Altair introduced a sync committee to support light clients and tweaked some penalties;
Altair Announcement;
Altair specification (annotated version);
"What's new in ETH 2" article on Altair;
3. September 15, 2022 - merged! No more PoW - Consensus layer and Enforcement layer had a big merge at block 15,537,394.
what's next
1. Withdrawal – enables validators to withdraw all or part of their staked ETH stake.
Capella forks specify changes to the consensus layer;
EIP-4895 specifies changes to the execution layer;
Tim Beiko's frequently asked questions about withdrawals;
Withdrawal meta specification with additional information;
2. Distributed validators - introduce multi-signatures, where n individuals share the same validator, and m-of-n must agree on how it will behave.
Enhancing staking by preventing accidental slashing and making it more accessible (for example, by distributing the required 32 ETH trustlessly among multiple participants);
This is not something within the protocol, teams like SSV and Obol are working on it;
3. View merging - adjust fork selection rules (how validators vote) to mitigate a class of attacks.
Essentially enabling honest validators to "impose" their opinion of the correct head of the chain to reduce the chances of malicious validators splitting votes and later reorganizing blocks at their will;
ethresear.ch posts with lots of (very technical) research background;
4. Improved Aggregation - Ethereum strives to support as many validators as possible, but having each validator vote on each block (and verifying the votes of all other validators) is too bandwidth-intensive. The next best thing is aggregated signatures, but that has its limitations and can be done better.
A popular science post about the benefits of BLS aggregation;
Potential candidate: Horn;
5. Single slot finality (SSF) - the chain is determined for each slot (12 seconds), not by epoch (12.8 minutes).
Pathway to SSF;
In addition to improved signature aggregation, we need to address two other things:
(1) SSF Consensus Algorithm - The existing SSF-compatible algorithm is not enough, we want an algorithm that can keep the chain active even if more than 1/3 of the validators are offline;
(2) 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?
6. Secret leader election (SLE)
Today, the validators (slot leaders) selected to propose a block are known in advance, allowing potential DoS attacks to specifically target the leader of an upcoming block.
ethresear.ch's post on a single SLE protocol with random shuffling: No one knows who will be the leader of a slot except the leader themselves until they reveal their blocks and their proof of leadership.
Non-single secret leader election may also be an option.
7. Support for more validators - an ongoing long-term effort: Safely supporting more validators is always desirable.
8. Quantum-safe aggregation-friendly signatures - making Ethereum safe from quantum computer attacks.
The cryptography behind the BLS signature scheme used by Ethereum is known to have been broken by quantum computers, but known quantum-safe alternative signature schemes do not aggregate as efficiently as BLS signature schemes (hence the need for a method that is both quantum-safe and aggregate-friendly). plan);
Two leading quantum security methods are based on STARK and Lattice;
9. Implement EIP-4844 - Apply EIP-4844 to the Ethereum mainnet.
A "ceremony" will be required to create a credible setup: explanations, estimated timelines, specifications;
EIP-4844 implementation timeline overview;
10. Basic rollup expansion - depends on the following:
EIP-4844 - Scaling is still considered fundamental/limited due to the "every node downloads all data" nature that limits the usable capacity of blobspaces;
Rollup limited training wheels (see proposed milestones);
11. Complete rollup expansion - depends on the following:
P2P Design for Data Availability Sampling: All the Efforts and Research Involved in Networks Required for Data Sharding
DA sampling client: develop a lightweight client that can quickly determine whether data is available through random sampling of several kilobytes
Efficient DA self-healing: able to efficiently reconstruct all data under the worst network conditions (e.g. malicious validator attacks, or prolonged downtime of a large number of nodes)
Rollups without training wheels: fully decentralized sequencers, trustless fraud provers, immutable contracts, etc.
12. Quantum security and the promise of untrusted settings - make Ethereum immune to quantum computers.
While polynomial commitments (KZGs) are efficient and powerful, they are not quantum-safe and require a trusted setup. Research into a more ideal long-term commitment is ongoing, with the ultimate goal of "hot-swapping" KZG under the hood;
2. The Scourge
Related Links:
Related Links:
Guided by reliable neutrality;
Various tweets about MEV;
Articles on MEV and PBS;
A list of links on PBS;
what has been done
1. MEV market outside the protocol - MEV-Boost middleware allows ordinary validators to profit from MEV without having to run complex MEV strategies themselves.
The solution itself is not complete as it has censorship issues;
See Resilience Costs and SUAVE for ideas and plans to make these off-agreement markets more resilient;
what's next
1. Inclusion lists or alternatives - let block proposers impose restrictions on block builders, i.e. force them to include transactions.
( 1 ) contains list annotations;
(2) Research on constraining block builders without burdening block proposers;
2. In-protocol PBS – Incorporate a market for block builders directly into the protocol.
3. MEV burn - Let the blockchain capture the value extracted from the on-chain economy.
(1) Direct destruction of MEV proposals through proposer auctions;
(2) Committee-driven MEV smoothing will enable protocols to be MEV-aware;
(3) Limiting the validator set through economic incentives will indirectly burn MEV through negative issuance;
4. Application Layer MEV Minimization - Not directly related to L1, this project involves developers taking MEV into account when designing dapps. Here are some examples of dapps that employ the MEV minimization strategy.
Distributed builder track
As block proposals remain decentralized, we now have a separate problem of block building becoming centralized. Even with all the other projects on the roadmap aiming to minimize the worst possible negative effects of centralized block building, being able to distribute block building across multiple nodes is still a major benefit.
Blob construction - finding ways to offload the high bandwidth and processing demands of data sharding across multiple nodes where common consumer hardware can run;
Pre-confirmation service - gives users a strong guarantee that their transaction will be included in the next block;
Lead Protection - Minimizes toxic MEVs such as sandwich transactions to keep distributed builds reliably neutral;
It's still an active area of research with very open design considerations, so it's unclear whether the first two items should be included in the protocol (hence the question mark status on the roadmap).
Here are some related links:
Talk about merged block construction, which mentions decentralized block construction: https://www.youtube.com/watch?v=KP 5 ppCRH 0 iM
Talk to decentralized block builders: https://www.youtube.com/watch?v=fAgrIdyWIqc
Some thoughts on distributed block building: https://github.com/flashbots/mev-boost/issues/139
3. The Verge
Goal: Verifying a block should be super simple - download N bytes of data, perform some basic calculations, verify a SNARK and you're done.
This phase is essentially filling the "client gap" by eventually implementing light clients: not everyone wants or is able to run a full node. The goal of The Verge is to introduce trustless or trust-minimized alternatives that are easy to run and don't require a lot of storage and bandwidth. The ultimate goal of The Verge is for these light clients to provide the same security guarantees as today's full nodes.
Everything relies on zero-knowledge techniques such as SNARKs and STARKs, which themselves rely on polynomial commitment schemes. Here are some related links:
Briefly introduce how zk-SNARKs are implemented;
Analysis of STARK;
If you know some mathematics and programming, this article can let you understand what zk-SNARKs are;
About the role of the Polynomial Commitment scheme in scaling Ethereum;
what has been done
1. Solved the most serious EVM DoS problem - mainly the gas pricing problem, which has been fixed in the Berlin upgrade.
2. Basic light client support (synchronization committee) - Thanks to the synchronization committee, it is easy to build light clients that follow the consensus layer.
Check out how the Helios client utilizes synchronous committees (and a great article on how these committees work)
what's next
1. SNARK / STARK ASIC - hardware built specifically for creating proofs.
2. Verkle tree - replace the data structure used for global state with a more efficient data structure:
(1) A linked list of Verkle trees;
(2) The key benefit is to have very short proofs that light clients can easily verify to verify things like account balances using only block headers - they can already leverage sync committees to verify that a given block The block header is actually part of the main chain;
(3) Rely on figuring out the correct specification, how to transition safely, and how it will affect the EVM gas cost of updating/editing state (also reliant on disallowing SELF-DESTRUCT in The Purge);
3. SNARK-based light client – SNARKify synchronization committee transition to quickly prove which validators the current synchronization committee is composed of
4. Fully SNARKed Ethereum - The following 3 items together constitute a major milestone for Ethereum to have extremely efficient and trustless block verification finality:
(1) SNARK for Verkle proofs - By incorporating Verkle proofs into a SNARK, blocks will contain a short, independent proof of the partial state they modify, so there is no need to verify the entire state of block N-1 to verify Whether block N modifies it correctly.
(2) SNARKs for consensus state transitions — moving from trust-minimized sync committees to fully trustless verification of everything that happens on the consensus layer.
(3) SNARKs for L1 EVM - Leverage the rollup team's efforts on zk-EVM by integrating zk-EVM directly into L1 (see post on enhrined rollups).
5. Increase L1 gas limit - by removing today's burden of "every node needs to store everything" to verify blocks in a trustless way, having larger blocks will make it easier to get more L1 scalability ( This will automatically compound all L2 extensions)
6. Turn to quantum-safe SNARKs (such as STARKs) - to make Ethereum immune to quantum computer attacks (the effectiveness of SNARKs relies on cryptography known to be cracked by quantum computers, while STARKs do not).
4. The Purge
Goal: Simplify the protocol, eliminate technical debt, and limit the cost of participating in the network by cleaning up old history.
what has been done
1. Eliminate most gas refunds - all gas repricing done in the Berlin upgrade.
2. Beacon chain fast synchronization - all development work is synchronized from the most recently completed epoch, not from the origin (called "checkpoint synchronization" in most consensus clients).
3. EIP-4444 specification—see EIP specification.
what's next
1. History Expiration - Reduce storage requirements, synchronization time, and code complexity by expiring old history.
(1) See this twitter post;
(2) Depends on the implementation of EIP-4444, which depends on accessing alternative history through other means (such as Portal Network)
(3) Vitalik's AMA on historical expiration;
2. Status Expiration - Solve the whole "pay once, store data forever" problem about status.
(1) The idea is to automatically expire unused parts of the state, and only keep a verkle tree root that the user can use to restore the expired state when needed;
(2) Vitalik's AMA about status expiration;
(3) Rely on: Base State Expiration Specification - How we actually do it, see potential roadmap (and other options);
Address Space Expansion - Increase address size from 20 bytes to 32 bytes to prevent collisions and add data about state cycles;
Application analysis - find out how it might break current applications/contracts and how they fit;
3. Log reform - Simplify the way the event log works to search for historical events more efficiently.
4. Serialization coordination - the execution layer uses RLP for data serialization, while the consensus layer uses SSZ, which will get rid of RLP and use SSZ everywhere.
5. Remove old transaction types - stop supporting old transaction types (see EIP-2718) to remove code complexity from clients (at the cost of some backward compatibility).
6. EVM simplified track.
(1) Disable SELFDESTRUCT - this opcode is the source of many problems (related EIPs: EIP-4758 and EIP-4760 and discussion);
(2) Simplify the gas mechanism - involves removing many of the gas-related EVM features mentioned here;
(3) Precompilation --> EVM implementation -- get rid of precompiled contracts and support direct EVM implementation (that is, large modular operations, see The Splurge);
5. The Splurge
Goal: fix everything else
All nice improvements not needed for higher priority upgrades, belong to The Splurge. The biggest improvement item is account abstraction, but also small tweaks to existing things.
what has been done
1. EIP-1559 - This famous EIP has many benefits besides burning ETH.
2. ERC-4337 Specification - This ERC aims to introduce account abstraction without modifying the core protocol (the initial explanation article of ERC-4337).
what's next
1. EIP-1559 in the final stage – EIP-1559 is enhanced through multiple dimensions.
2. EVM improvement track and a simplified track from The Purge to the final stage of EVM.
(1) EVM Object Format (EOF) — a set of EIPs that allow for verification and versioning of EVM bytecode when deployed. See this explainer article and twitter thread;
(2) Large modular operations - much of the cryptography in the roadmap relies on very large numbers for modulo operations, which can be done more efficiently directly in the EVM;
(3) Further EVM improvements - anything else worth adding to improve the EVM - or anything removed to remove complexity;
3. Account abstraction track leading to final stage account abstraction. For more information, see Vitalik's description of the following items:
(1) ERC-4337 - Develop compatible smart wallets for real adoption;
(2) Voluntary EOA conversion - through EIP, ordinary accounts can be irreversibly added codes to convert them into contract accounts, that is, smart wallets that meet the 4337 standard;
(3) Intra-agreement conversion - making the above conversion mandatory for all existing accounts;
4. Verifiable Delay Function (VDF) - essentially "non-parallelizable proof-of-work" that will enhance randomness in PoS among other things (see ethresear.ch post on VDFs and their potential uses)
5. Exploring solutions for dust accounts - saving "dust funds" that cost more to move than they are worth. There are a bunch of ideas here: https://ethereum-magicians.org/t/some-medium-term-dust-cleanup-ideas/6287
