Original title: "Annotated Ethereum Roadmap"

Compilation of the original text: domothy, ETH Chinese site

This article is based on the latest Ethereum roadmap to annotate the content, aiming to let readers understandEthereum RoadmapEach section above provides entry points, and each section provides a brief overview.

Note: As indicated by the arrows on the roadmap, the various parts listed are not continuous work, and their advancement is parallel.

The Merge

Goal: To achieve an idealized, concise, robust and decentralized PoS consensus mechanism.

work done

December 1, 2020 — Beacon Chain Launch

• Introduce the Ethereum PoS consensus layer, and the verifier pledges ETH to maintain the network security of this layer;

• The beacon chain is called in the consensus specificationstage 0(Vitalik'sAnnotated versionand Danny Ryan'sAnnotated version）；

• October 27, 2021 - Warm up fork (Altair) - Consensus layer client developers did a test run on coordinating hard fork upgrades.

• light clientlight client, and made some adjustments to the penalty;

• Altair Mainnet Upgrade Announcement；

• Altair specification（Annotated version）；

• 「What’s new in ETH 2 」The issue in which Altair is explained;

September 15, 2022 — Merge! PoW Retirement - inBlock height 15537394Complete the merger of the consensus layer and the execution layer.

next step

Withdraw — Allows a validator to withdraw all or part of the deposit

• CapellaForks specify changes in the consensus layer;

• EIP-4895 Specifies changes in the execution layer;

• Tim Beiko on withdrawalFAQ；

• Withdrawal meta specifications and other information；

Distributed validators — "Multi-sig, but for staking", a technique where n people share the same validator and m-of-n must agree on how it should behave.

• Strengthens the staking mechanism by preventing accidental slashing and making it easier to participate (e.g. by trustlessly splitting the required 32 ETH among multiple participants);

• This is not the work of the agreement,SSVandOboland other teams are working on this research;

• View merge — adjust fork selection rules (how validators vote) to mitigate one type of attack.

• In essence, it is to "force" honest verifiers to see the correct chain head, so as to reduce the chance of malicious verifiers splitting votes and reorganizing blocks that are beneficial to them;

• ethresear.ch postThere's a lot of (very technical) background on this research in ;

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 to aggregate signatures, but this has its limitations and can be done better.

• About the benefits of BLS aggregate signatureexplain post；

• Potential candidate signature techniques:Horn；

Single slot finality (SSF) - Finalize the chain state every other slot (12 seconds) instead of every other epoch (12.8 minutes).

• The road to finality in a single slot(Chinese Version);

• In addition to improving signature aggregation, we had to figure out two things:

- SSF consensus algorithm - the existing SSF-compatible algorithm is not enough, we want an algorithm that can keep the chain alive even if more than 1313 validators are offline;

- SSF Validator Economics - If we end up having to limit the number of validators, how do we limit the participation rate, and what sacrifices do we need to make?

Secret Leader Election (SLE)

• Currently, the validators selected to propose a block (the leaders of a single slot) are known slightly in advance, allowing potential DoS attacks to specifically target the leaders of upcoming blocks;

• ethresear.chThere is a post about a protocol for single-secret leader election based on random shuffle: no one knows who will be the leader of this slot except the leader themselves until they publish their block along with the leader proof;

• Non-Single Secret Leader Electionmight also be an option;

Supporting More Validators — An Ongoing Long-Term Effort: Safely supporting more validators is always our goal.

Quantum-safe, aggregate-friendly signatures — Making Ethereum quantum-safe is part of our long-term effort to make Ethereum quantum-safe before quantum computers become a legitimate concern.

• The BLS signature scheme used is based on cryptography known to be broken by quantum computers, but alternative signature schemes known to be quantum-safe do not aggregate signatures as efficiently as BLS (hence the need for a scheme that is both quantum-safe and aggregation-friendly);

• The two main quantum security schemes areBased on STARKand Lattice-based;

The Scourge (resolve hidden dangers)

Related Links:

Related Links:

• Guided by trusted neutrality；

• Multiple tweets about MEV；

• Articles on MEV and PBS；

• List of Links on PBS；

work done

MEV marketplace outside the protocol — The MEV-Boost middleware allows ordinary validators to profit from MEV without having to run complex MEV policies themselves.

• This solution is not complete by itself because it hasreview questions；

• Read the article "The Cost of Resilience"and"The Future of MEV is SUAVE” to learn about plans to make the MEV market outside of these agreements more resilient;

next step

Packet list or alternatives — let block proposers place constraints on block builders, i.e. force them to include transactions.

• Notes on packing lists；

• Investigate how to constrain builders without burdening proposers；

In-protocol PBS — write the block building market directly into the protocol.

MEV burn — Allows the blockchain to capture value that would otherwise have been extracted from the on-chain economy.

• proposalproposal；

• Committee-driven MEV distribution makes the protocol aware of MEV；

• Setting an upper limit on the validator subset through economic incentives will indirectly destroy MEV through negative issuance；

Application Layer MEV Minimization — This work is not directly related to L1, it involves developers needing to keep MEV in mind when designing their dapps. Here are a few examples of DApps adopting the MEV minimization strategyexample。

Distributed builder route. Since the block proposal process is kept decentralized, we now have a separate issue where block building becomes centralized. Even though everything else on the roadmap is designed to minimize the worst-case scenario of centralization of block building, being able to distribute block building across many nodes is still a great benefit.

• Blob structure - finding ways to offload the high bandwidth and processing requirements of data sharding across many nodes that ordinary consumer-grade hardware can run on;

• Pre-confirmation service - giving users a strong guarantee that their transaction will be included in the next block;

• Frontrunning protection - Minimize toxic MEV, such as sandwich attacks, so that the distributed build process remains trustworthy neutral;

Related Links:

Related Links:

• Presentation on post-merger block building, mentioning decentralized block building

• A presentation on decentralized builders

• Some Thoughts on Distributed Block Construction

The Verge (Border)

Goal: Verifying a block should be super easy - download N bytes of data, perform some basic calculations, verify a SNARK and you're done.

This part is basically about filling the "Shortcomings on the client side”: 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 or bandwidth. The ultimate goal of The Verge is for these light clients to provide the same security guarantees as current full nodes.

This all relies on zero-knowledge techniques like SNARKs and STARKs, which themselves rely on polynomial commitment schemes. Here are some links on this:

• Introduce why zk-SNARK is possible(Chinese Version)

• Dissecting STARK

• Assuming you are someone who knows some math and programming, explain zkSNARK to you

• The Role of Polynomial Commitment Schemes in Scaling Ethereum

work done

The worst EVM DoS issue was fixed - mainly Gas pricing, which was fixed in the Berlin upgrade.

Basic light client support (synchronization committee) — Thanks to the synchronization committee, it is easy to build light clients that follow the consensus layer.

• learnHelios clientHow sync committees are utilized (good explanation of how these committees work);

next step

EIP-4844 Implementation — Deploy EIP-4844 on the main network

• A "ceremony" will be required to create trusted initialization:explain、specification、specification；

• EIP-4844 Implementation Timeline Overview；

• Basic Rollup Scaling — Relies on the following to work:

• EIP-4844 - achieved scalability is still considered basic/limited due to the "every node downloads all data" nature that limits the usable capacity of the blobspace;

• The limited training wheel phase of rollup (the article proposes to remove the rollup training wheelroute map）；

Full Rollup Scaling — Relies on the following work:

• P2P Design of DAS (Data Availability Sampling): Some work and research involving data sharding network connectivity issues;

• Data availability sampling client: develop a lightweight client that can quickly determine whether data is available by randomly sampling a few kilobytes;

• Efficient DA self-healing: able to efficiently rebuild all data under the worst network conditions (e.g. malicious validator attack, or long downtime of large block nodes)

• Rollup without training wheels: fully decentralized sequencer, trustless fraud proofs, immutable contracts, etc.;

The promise of quantum-safe, trusted-initialization — making Ethereum quantum-safe is part of our long-term effort to make Ethereum quantum-safe before quantum computers become a legitimate concern.

• While efficient and powerful, polynomial commitments (KZG) used everywhere are not quantum safe and require a trusted initialization. Research on the promise of more ideal long-term usage is ongoing, with the ultimate goal of hot swapping KZG under the hood;

SNARK / STARK Application-Specific Integrated Circuit — hardware dedicated to creating proofs.

Verkle tree — replaces the data structure used for global state with a more efficient version.

• List of Links for Verkle Tree

• The key benefit is the ability to generate very succinct proofs that can be easily verified by light clients to verify things like account balances by looking only at headers - they can already leverage sync committees to verify that a given block header is actually part of the main chain;

• Need to write a suitable specification, ensure safe migration, and figure out how it will affect the EVM Gas overhead of updating/editing state (this also depends on the work of canceling "SELF-DESTRUCT" in The Purge part);

SNARK-Based Light Clients — Generate SNARK proofs of state transitions in the Sync Committee to quickly prove which validators make up the current Sync Committee.

Ethereum based entirely on SNARK — the following 3 items together make up the "The final picture of EthereumAn important milestone for the implementation of extremely efficient and trustless block verification:

• SNARKs for Verkle Proofs - By incorporating Verkle proofs into a single 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 block N Is it modified correctly;

• SNARKs for consensus state transitions — from trust-minimized sync committees to fully trustless verification of everything happening on the consensus layer;

• SNARKs for L1 EVM - Leveraging work done by the rollup team on zk-EVM, integrating zk-EVM directly into L1:

- Read about Rollup written in the protocolpost；

Increase L1 Gas Cap — Trustless validating blocks by removing the current burden of “every node needs to store everything” will make it easier to form larger blocks for more L1 scalability (this will automatically enhance the effect of all L2 expansion).

Moving to quantum-safe SNARKs (like STARKs) — Making Ethereum quantum-safe is part of our long-term effort to make Ethereum quantum-safe before quantum computers become a legitimate concern.

• SNARKs are based on cryptography known to be crackable by quantum computers, while STARKs are not;

The Purge

Goals: Simplify the protocol, clear technical debt, and limit the cost of participating in the network by cleaning historical data.

work done

Clear most Gas returns — allGas repricingWork has been done on the upgrade in Berlin.

Beacon Chain Fast Sync — All development work has been done to sync from the most recently finalized epoch (called "checkpoint sync" in most consensus layer clients) instead of from genesis.

EIP-4444 Specification - Readlearn.learn.

next step

Historical Data Hibernation — Reduces storage requirements, synchronization time, and code complexity by hibernating old historical state.

• read this articlelong twitter；

• Rely on the implementation of EIP-4444, i.e. by other means such asPortal Network) to access historical state alternatives;

• Vitalik for historical data hibernationAMA；

State Dormancy — Regarding the state, fix the problem of "one-time payment, data permanent storage".

• The idea is mainly about having unused parts of the state automatically hibernate, leaving only a verkle tree root that the user can use to activate the dormant state if needed;

• Vitalik for the state dormancy mechanismAMA；

• Depends on these jobs:

- Basic stateful hibernate specification: how we intend to implement it, see thispotential roadmap(andother options）；

- Address space extension:increase address size, increased from 20 bytes to 32 bytes to prevent conflicts and increase data about the status cycle;

- Application analysis: figure out how it will break current applications/contracts, and how these applications/contracts need to adapt;

Log Reform - Simplifiedevent logwork in order to more efficiently search for historical events.

Serialization Coordination - Execution layer usesRLPData serialization, and the consensus layer uses SSZ, which will gradually abandon RLP and useSSZ。

Removed old transaction types — Stop supporting old transaction types (seeEIP-2718 ) to remove code complexity on the client side (sacrificing some backward compatibility).

EVM simplification route

• Cancel SELFDESTRUCT — this opcode is the source of many problems:

- 《Practical workaround to eliminate SELFDESTRUCT" explains why and how to remove this opcode;

- Related EIPs:EIP-4758 、 EIP-4760 as well asdiscuss；

• hereherementioned;

• Precompilation -> EVM implementation — Abandon precompiled contracts and adopt direct EVM implementation (that is, large modular operations, see The Splurge);

The Splurge

Goal: Perfect other stuff.

All the good stuff that doesn't need a higher priority belongs in this section of The Splurge. the biggest one isaccount abstraction,But there are also small tweaks to existing content.

work done

EIP-1559 — the famousEIPBrought itmany benefits, not just destroying ETH.

ERC-4337 specification — theERCAims to introduce account abstraction without modifying the core protocol

• Interpretation of ERC-4337；

next step

The final form of EIP-1559 — by makingmulti-dimensionandAMM Curveandperceived timeof.

The EVM refinement route and the simplified route in The Purge together form the final form of the EVM.

• EVM Object Format (EOF) — A set of multiple EIPs that allows verification and versioning of EVM bytecode as it is deployed. Please read thisandandtwitter post；

• Large Modular Operations — Much of the cryptography in the roadmap relies on modular operations on large numbers, which can be done more efficiently directly in the EVM;

• Further refinement of the EVM — anything else worth adding to improve the EVM, orremovesomething to remove complexity;

The account abstraction route that implements the final form of the account abstraction. For more information on the following, see Vitalik'sdescribe：

• ERC-4337 — development of compatible, practically adopted smart wallets;

• Voluntary conversion of EOA accounts - through an EIP, ordinary accounts are allowed to irreversibly add codes to convert them into contracts, that is, to become 4337 compatible smart wallets;

• Written in the agreement — to force the above conversion for all existing accounts;

Verifiable Delay Functions (VDFs) — essentially “non-parallel proof-of-work” that willEnhancing the randomness used in PoS and other things。

• see thispost, an introduction to VDFs and their potential uses

herehereSee a bunch of ideas.