Partnered With:

Annotated Ethereum Roadmap中文译版: Annotated Ethereum Roadmap中文译版

Read this article in 34 Minutes

Based on the latest Ethereum roadmap, where are we in terms of Chinese content annotation?

Original Title: "Annotated Ethereum Roadmap"

Translated by: domothy, ETH Chinese website

Translator's note: This article provides annotations based on the latest Ethereum roadmap. The following image is the Chinese version translated by ECN.

This document aims to provide entry points for readers to understand the various parts of the Ethereum roadmap. Each section has a brief overview, and if you want to delve deeper, detailed links are also included in the text.

This is a continuously updated document. If you find any information provided here to be unclear, inaccurate, outdated, or missing, please feel free to contact me at any time.

Attention: As shown by the arrows on the roadmap, the various parts listed are not consecutive tasks, and their progress is parallel.

The Merge (合并)

translates to

The Merge (合并)

in English.Target: To achieve an ideal, concise, robust, and decentralized PoS consensus mechanism.

已完成工作

translates to

已完成工作

in English.

December 1, 2020 - Beacon Chain Launch

· Introducing the Ethereum PoS consensus layer, where validators stake ETH to maintain network security.

· The beacon chain is referred to as phase 0 in the consensus specification (Vitalik's annotated version and Danny Ryan's annotated version).

October 27, 2021 - Warm-up Fork (Altair) - Consensus Layer Client Developers Conducted a Test Run in Coordinating Hard Fork Upgrades

· Altair introduced a Sync Committee to support light clients and made some adjustments to penalties.· Altair Mainnet Upgrade Announcement

· Altair Specification (Annotated Version)

· The episode in "What's new in ETH2" that explains Altair

September 15, 2022 - Merge! PoW Retirement - Consensus layer and execution layer merged at block height 15,537,394

Next steps

Withdrawal - Allows validators to withdraw all or part of their staked assets

· Capella Fork refers to the changes in the consensus layer specified.

· EIP-4895 refers to the changes in the designated execution layer.

· Tim Beiko's FAQ on Withdrawals

· Withdrawal Meta-Spec and other information

Distributed Validator - "Multisig, but for staking". In this technology, n people share the same validator and m-of-n must reach consensus on its behavior.

· Strengthen the pledge mechanism by preventing accidental seizures and making it easier to participate (for example, by trustlessly dividing the required 32 ETH among multiple participants)

· This is not work within the protocol, teams such as SSV and Obol are actively researching this.

View merge - Adjusting fork selection rules (the way validators vote) to mitigate a type of attack.

Essentially, it is to reduce the chance of malicious validators splitting votes and reorganizing blocks that are favorable to them by "forcing" honest validators to see the correct chain head.

· ethresear.ch post contains a lot of (highly technical) background information about this research.

Improved Aggregation - Ethereum is striving to support as many validators as possible, but having each validator vote on every block (and verify each other's votes) is too bandwidth-intensive. The next best thing is aggregation signatures, but this also has its limitations and can be done better.

· Explanation post about the benefits of BLS aggregate signatures

· Potential candidate signature technology: Horn

Single slot implementation of finality (SSF) - Chain state is determined every slot (12 seconds) instead of every epoch (12.8 minutes)

· The Road to Single Slot Finality (Chinese version) Besides improving signature aggregation, we also need to figure out two things:

SSF Consensus Algorithm - Existing algorithms compatible with SSF are not enough. We want an algorithm that can keep the chain active even if more than 1313 validators are offline.

SSF Validator Economics - If we ultimately have to limit the number of validators, how do we limit participation rates, and what sacrifices do we need to make?

Secret Leadership Election (SLE)

· Currently, the validator selected to propose a block (the leader of a single slot) is slightly ahead of time, which makes potential DoS attacks specifically targeted at the upcoming block leader.

· ethresear.ch has a post about a protocol for single secret leader election based on random shuffling: no one knows who will be the leader of this slot except the leader himself until they publish their block with the leader proof.

· Non-single secret leader election may also be an option.

Supporting more validators - an ongoing effort: Safely supporting more validators has always been our goal.

Quantum-safe, aggregation-friendly signature - Making Ethereum quantum-safe has been a long-standing effort of ours before quantum computers became a reasonable concern.

· The cryptography underlying the BLS signature scheme used is known to be vulnerable to quantum computers, but the alternative signature schemes that are known to be quantum-safe do not aggregate signatures as effectively as BLS (thus requiring a scheme that is both quantum-safe and aggregation-friendly).· The two main quantum security schemes are based on STARK and based on Lattice.

The Scourge (解决隐患)

Goal: Ensure a reliable and trustworthy neutral transaction packaging process, avoiding centralization and other protocol risks brought by MEV.

Relevant links: 相关链接:

· 以可信的中立为指导原则 translates to · Guided by Credible Neutrality.

· Multiple tweets about MEV

· Article about MEV and PBS

· List of links about PBS

已完成工作

translates to

Completed Work

MEV-Boost Middleware: A Market Outside of Protocols
MEV-Boost middleware allows ordinary validators to profit from MEV without having to run complex MEV strategies.

· Read the articles "The Cost of Resilience" and "The Future of MEV is SUAVE" to learn about plans that make the MEV market more resilient beyond these protocols.

Next steps

Packaging list or alternative plan - forcing block builders to include transactions by limiting them to block proposers

· Notes on packaging list Research on how to constrain builders without increasing proposers' burden

· Protocol internal PBS - directly incorporating block construction market into the protocol

MEV Destruction - Extracting Value from On-Chain Economies

· Proposal to directly burn MEV through block proposer auctions· Committee-Driven MEV Smoothing makes the protocol aware of MEV.

· Setting a 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 and involves developers remembering MEV when designing their dapps. Here are a few examples of dapps that adopt MEV minimization strategies.

Distributed Builder Pathway

Due to the decentralized nature of the block proposal process, we now have a separate issue of block construction becoming centralized. Even though all other parts of the roadmap are aimed at minimizing the worst-case scenario that centralized block construction may bring, being able to distribute block construction across many nodes is still a significant advantage.

· Blob Structure - Finding ways to reduce the high bandwidth and processing requirements of data sharding across many nodes, which can be run on ordinary consumer-grade hardware.

· Pre-confirmation service - Provides users with a strong guarantee that their transactions will be packaged into the next block.

· Front-running protection - Minimize the impact of toxic MEV, such as sandwich attacks, to maintain a trustworthy and neutral distributed building process.

This is still an active research field with very open design considerations, so it is not yet clear whether the first two boxes should be included in the protocol (hence the question mark on the roadmap). Here are the relevant links:

· The speech about merged mining mentioned decentralized block construction. It also included a link to the presentation.· Speech on Decentralized Builders

· Some thoughts on distributed block construction

The Verge (边界)

translates to

The Verge (Boundary)

in English.

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

This section is basically about filling the "client-side deficiencies" by making lightweight clients feasible: not everyone wants or is able to run a full node. The Verge aims to introduce alternative solutions that are trustless or trust-minimized, with nodes that are easy to run and do not require a lot of storage and bandwidth. The ultimate goal of The Verge is to provide the same level of security as current full nodes through these lightweight clients.

All of this relies on zero-knowledge technologies, such as SNARKs and STARKs, which themselves rely on polynomial commitment schemes. Here are some links about this:

· Introduction to how zk-SNARKs are possible Chinese version· STARK Anatomy

The content translates to:

· STARK Anatomy

· 假设你是懂一些数学和编程的人，向你解释 zkSNARK Assuming you have some knowledge of mathematics and programming, explain zkSNARK to you.

· 论多项式承诺方案在扩容以太坊中的作用
Translation:

· On the Role of Polynomial Commitment Scheme in Scaling Ethereum

已完成的工作

translates to

Completed Work

in English.

Solved the most severe EVM DoS issue - mainly the gas pricing issue, which has been resolved in the Berlin upgrade

Basic light client support (synchronous committee) - Thanks to the synchronous committee, it is easy to build a light client that follows the consensus layer.

· Learn how Helios client utilizes sync committees (explains how these committees work very well)

Next steps

EIP-4844 Implementation - Deploying EIP-4844 on the Mainnet

· A "ceremony" is required to create a trusted initialization: Explanation, Estimated timeline, Specification.

· EIP-4844 Implementation Timeline Overview

Basic rollup expansion - depends on the following work:

· EIP-4844 - The scalability implemented is still considered basic/limited because the nature of "each node downloads all data" limits the available capacity of blobspace.

· Rollup's limited auxiliary wheel phase (the article proposes to remove the Rollup auxiliary wheel in the roadmap) (Chinese version)

Complete rollup expansion - dependent on the following work:

· P2P design of DAS (Data Availability Sampling): Some work and research on network connection issues related to data sharding.

· Data availability sampling client: Develop a lightweight client that can quickly determine data availability by sampling several kilobytes of random data.

· Effective DA self-recovery: able to effectively rebuild all data under the worst network conditions (such as malicious validator attacks or long-term downtime of large nodes).

· Rollup without auxiliary wheels: fully decentralized sequencer, trustless fraud proof, immutable contracts, etc.

Quantum-safe, untrusted initialization commitment - Making Ethereum quantum-safe has been a long-standing effort before quantum computers become a reasonable concern.

· Although efficient and powerful, the widely used polynomial commitment scheme (KZG) is not quantum-safe and requires a trusted setup. Research on more ideal long-term commitment schemes is ongoing, with the ultimate goal of hot-swapping KZG at the underlying level.

SNARK / STARK dedicated integrated circuit - hardware specifically designed for creating proofs

Verkle tree - a more efficient version of the data structure used for global state

· Verkle Tree 的链接清单

The content translates to:

· List of links for Verkle Tree

· The key benefit is the ability to generate very concise proofs, which can be easily verified by light clients through the block header to verify things like account balances - they can already use synchronous committees to verify that a given block header is actually part of the main chain.

· Need to write appropriate specifications, ensure safe migration, and understand how it will affect EVM gas expenses for updates/editing status (which also depends on the work of canceling "SELF-DESTRUCT" in The Purge section)

SNARK-based light client - generating SNARK proofs for state transitions of synchronized committees to quickly prove which validators make up the current synchronized committee

Completely SNARK-based Ethereum - The following three items together constitute an important milestone in the "Final Ethereum Landscape" (Chinese version), which achieves extremely efficient and trustless block validation:

· SNARKs for Verkle Proofs - By merging Verkle proofs into a single SNARK, blocks will contain a concise independent proof about the modified portion of their state, so it is not necessary to verify the entire state of block N-1 to verify if block N has correctly modified it.

· SNARKs for consensus state transition - transitioning from a trust-minimized synchronous committee to fully trustless verification of everything happening on the consensus layer.

· SNARK for L1 EVM - leveraging the work done by the rollup team on zk-EVM, directly integrating zk-EVM into L1.

· Read the post about rollups written into the protocol

Increasing L1 gas limit - By eliminating the burden of "every node needs to store everything" to achieve trustless verification of blocks, it will be easier to form larger blocks to obtain more L1 scalability (this will automatically enhance the effect of all L2 expansion)

Turning to quantum-safe SNARKs (such as STARK) - Making Ethereum quantum-safe has been a long-standing effort of ours before quantum computers become a reasonable concern.

· The cryptography that SNARK is based on is known to be vulnerable to quantum computers, while STARK is not.

The Purge (清除工作)

translates to

The Purge (清除工作)

in English.Target: Simplify protocols, clarify technical debt, and limit the cost of participation in the network by cleaning up historical data.

已完成工作

translates to

Completed Work

in English.

· Clear most gas returns - all gas repricing work has been completed in the Berlin upgrade.

· Beacon chain fast synchronization - synchronization from the recently finalized epoch (referred to as "checkpoint synchronization" in most consensus layer clients) instead of synchronizing from the genesis, all development work in this regard has been completed.

· EIP-4444 Specification — Read EIP Specification for more information.

Next Steps

Historical data hibernation - reducing storage requirements, reducing synchronization time, and code complexity by hibernating old historical states

· Read this Twitter thread.

· A substitute solution that relies on the implementation of EIP-4444, which is accessing historical states through other means (such as Portal Network).

· Vitalik's AMA on historical data hibernation

Status Dormant - Addressing the issue of "One-time payment, permanent data storage" in terms of status

· This idea is mainly about automatically putting unused parts of the state to sleep, leaving only one Verkle tree root. If necessary, users can use it to activate the dormant state.· Vitalik's AMA on Statelessness Mechanism

· Depends on these tasks:

- Basic state sleep specification: How we plan to implement it, take a look at this potential roadmap (and other options).

- Address space expansion: Increase the address size from 20 bytes to 32 bytes to prevent conflicts and add data about state cycles.

- Application Analysis: Understand how it will disrupt the current application/contract, and how these applications/contracts need to adapt.

Log Reform - Simplify the way event logs work for more efficient searching of historical events.

Serialization Coordination - The Execution Layer uses RLP for data serialization, while the Consensus Layer uses SSZ. This will gradually lead to the abandonment of RLP in favor of SSZ.

Remove old transaction types - stop supporting old transaction types (see EIP-2718) to remove code complexity from clients (sacrificing some backward compatibility)

EVM Simplified Roadmap

· Cancel SELFDESTRUCT - this opcode is the root of many issues.

- Practical solution to eliminate SELFDESTRUCT explains why and how to remove this opcode.

- Related EIPs: EIP-4758, EIP-4760, and discussion

· Simplified gas mechanism - involves removing many EVM functions related to gas, mentioned here.

· Precompilation -> EVM Implementation - Abandon precompiled contracts and adopt direct EVM implementation (i.e. large-scale modular arithmetic, see The Splurge).

The Splurge (狂欢)

translates to

The Splurge (狂欢)

in English.

Goal: Improve other things.

All the good things that don't require higher priority belong to The Splurge section. The biggest one is account abstraction, but there are also small adjustments to existing content.

已完成的工作

translates to

Completed Work

.· EIP-1559 - This famous EIP brought many benefits, not just the burning of tokens.

· ETHERC-4337 Specification — This ERC aims to introduce account abstraction without modifying the core protocol.

- Explanation of ERC-4337

Next Steps

The final form of EIP-1559 - perfecting EIP-1559 by making it more multi-dimensional, resembling an AMM curve and perceived time

· EVM's final form is formed by the perfect route of EVM and the simplified route of The Purge.

· EVM Object Format (EOF) - a set of multiple EIPs that allow for verification and version control when deploying EVM bytecode. Please refer to this explanatory article and Twitter post.

· Large-scale modular arithmetic - Many cryptographic dependencies in the roadmap rely on a large amount of modular arithmetic, which can be more efficiently performed directly in the EVM.

· Further improve the EVM - anything else worth adding to improve the EVM, or removing something to eliminate complexity.

Implementation of the ultimate form of account abstraction - Account abstraction roadmap. For more information on the following, please refer to Vitalik's description:

· ERC-4337 - Development of compatible and practically adopted smart wallet.

· Voluntarily convert EOA accounts - through an EIP, allowing regular accounts to irreversibly add code to convert them into contracts, becoming 4337 compatible smart wallets.

· Written into the protocol - mandatory conversion of all existing accounts as described above.

Verifiable Delay Functions (VDFs) - essentially "non-parallelizable work proofs" - which will enhance the randomness used in PoS and other things

· Refer to this post for an introduction to VDFs and their potential applications.

Explore solutions for old accounts - saving these "dusty assets" requires gas costs that exceed their value. See a bunch of ideas here.