Vitalik releases six key routes for Ethereum's latest route

Today, Vitalik released the latest roadmap for Ethereum. On the basis of the previous five key routes, a new key route, The Scourge, was added to solve transaction censorship and MEV risks. So far, the future development and evolution of Ethereum will be mainly divided into six key routes, namely: The Merge, The Surge, The Scourge, The Verge, The Purge, and The Splurge. It is worth noting that these six key routes are being promoted simultaneously. Below, we will also briefly describe each key route based on this latest roadmap.

The Merge

The main goal of this route is to build a decentralized, robust and simple PoS consensus mechanism. Ethereum has successfully switched to PoS, and the next step is to fix the security of network validators and sporadic functions:

● Activation of the beacon chain withdrawal function: It is currently the main content of EIP-4895 and is ready to be deployed during the Shanghai upgrade. As for the specific implementation time, at the latest Ethereum core developer meeting, developers could only vaguely estimate it to be within a few months.

● Distributed Validators (DV): Distributed validator technology is designed to distribute the work of Ethereum validators to a group of distributed nodes. Compared with the traditional technology of running validator clients on a single machine, it can improve security, online resilience, etc. For details, see the DV technical specifications.

● Single Secret Leader Election (SSLE): Single secret leader election. Currently, the beacon chain adopts Single Leader Election, which means that the proposer selected by each slot will be made public in advance, making them vulnerable to DoS attacks. By encrypting and hiding this process, only the proposer knows his or her identity, which can effectively mitigate potential risks.

● Single Slot Finality (SSF): Single Slot Finality. Currently, Ethereum blocks require 64 to 95 slots (about 15 minutes) to achieve finality. However, Vitalik believes that there are sufficient reasons to shorten the finality time to one slot to achieve a better user experience. For details, see SSF.

The Surge

The main goal of this route is to promote Rollup-centric expansion and achieve 100,000 TPS per second. It is mainly divided into two stages:

● Achieve initial expansion of Rollup: EIP4844 introduces a new transaction type to Ethereum. This transaction type carries short-lived blob data, which will reduce the overhead of rollup by 10-100 times. At the same time, combined with the preliminary OP Rollup fraud proof and the assistance of ZK-EVMs, initial expansion can be achieved.

● Achieve full expansion of Rollup: While optimizing and improving the foundation of the former, focus on optimizing data availability DA, such as the client side of data availability sampling, P2P design, etc.

The Scourge

The main goal of this route is to ensure that reliable, credible and neutral transactions are included in the blocks, avoid network centralization and MEV-related risks, and the key milestone is to achieve the separation of block proposers and builders at the protocol level, namely Proposer-Builder Separation/PBS.

In the design of PBS, the block proposer is responsible for collecting transactions from the memory pool and creating a list crList containing block transaction information and passing it to the block builders. The block builders reorder the transactions in crList and build blocks with the purpose of maximizing MEV, and then submit their bids to the block proposer, and the block proposer will select the one with the highest bid as the valid block.

After implementing PBS, Ethereum developers further proposed the Smoothing MEV solution, which aims to reduce the gap in MEV captured between each validator. The ultimate goal is to make the reward distribution of each validator as close to uniform as possible, thereby ensuring the stability of the protocol consensus, while also considering the potential possibility of MEV destruction.

The Verge

The main goal of this route is to lower the threshold for validating blocks, and it includes two key milestone checkpoints:

● Verkle Trees: The Merkle tree is optimized around the Verkle tree design, making it possible for validators to participate in transaction verification without having to store all states.

● Fully SNARKed: SNARKs are fully introduced into the Ethereum protocol, such as EVM, Verkle proofs, and consensus state transitions. Even in the era of quantum computing, we can switch to quantum-secure STARKs.

The Purge

The main goal of this route is to simplify the Ethereum protocol, eliminate technical debt, and limit the cost of validators participating in the network by clearing historical data, reducing the storage requirements of nodes, and even eliminating the need to store full node data, thereby improving node efficiency and indirectly increasing TPS. This mainly includes two key milestone checkpoints, History Expiry and State Expiry. Since this route is more technical, we will not discuss them for now.

The Splurge

This route mainly includes some piecemeal optimization and fixes, such as account abstraction, EVM optimization, and random number scheme VDF.

Related links

DV:

https://github.com/ethereum/distributed-validator-specs

SSF:

https://web3caff.com/zh/archives/38886

Smoothing MEV:

https://ethresear.ch/t/committee-driven-mev-smoothing/10408

Verkle Trees:

https://vitalik.ca/general/2021/06/18/verkle.html