Vitalik supports route Epoch and slot: providing faster transaction confirmation time for Ethereum

Author: Vitalik Compiled by: Nan Zhi, Odaily Planet Daily One of the important attributes of a good blockchain user experience is fast transaction confirmation time. Today, Ethereum is much improved from what it was five years ago. Thanks to EIP-1559 and the stable block time after switching to PoS (The Merge), transactions sent by users on L1 can usually be confirmed within 5-20 seconds, which is roughly equivalent to the experience of paying with a credit card. However, there is value in further improving the user experience, and some applications even require latencies of hundreds of milliseconds or less. This article will explore some practical options for improving transaction confirmation times in Ethereum. Overview of Existing Ideas and Technologies Single-Slot Finality Currently, Ethereum’s Gasper consensus uses a single-slot (Slot) and Epoch architecture. Every 12 seconds a slot, a subset of validators vote on the head of the chain, and every 32 slots (6.4 minutes), all validators have a chance to vote once. These votes are then reinterpreted as messages in a consensus algorithm similar to PBFT, giving a very strong economic guarantee called finality after two Epochs (12.8 minutes). Over the past few years we have become increasingly dissatisfied with our current approach. There are two main reasons for this. Firstly, this method is complicated and there are many interaction errors between the slot-to-slot voting mechanism and the Epoch-to-Epoch finality mechanism. Secondly, 12.8 minutes is too long and no one wants to wait that long. Single Slot Finality (SSF) replaces this architecture with a mechanism similar to Tendermint consensus, where block N is finalized before block N+1 is generated. The main difference with Tendermint is that we retain the "inactivity leak" mechanism, which allows the chain to continue running and recover if more than 1/3 of the validators are offline. (Note: Inactivity leak is a mechanism in PoS designed to punish validators who have been inactive for a long time. Once marked as inactive, their pledged ETH will continue to be punished. Tendermint is an efficient and secure Byzantine fault-tolerant consensus algorithm that allows for fast transaction confirmations and ensures that the blockchain system can still function properly in the event that some nodes are malicious or offline) The main challenge with single-slot finality is that it means every Ethereum staker every 12 seconds. Two messages need to be published, which is a lot of load on the chain. There are some clever ideas to mitigate this problem, including the recent Orbit SSF proposal. Although this significantly speeds up "finality" to improve user experience, it does not change the fact that users need to wait 5-20 seconds. (Note: Finality and the transaction being packaged into a block and confirmed are not the same event. When the transaction is confirmed but finality is not achieved, a fork or rollback may occur.)

Rollup Pre-confirmation

Past For several years, Ethereum has been following a rollup-centric roadmap, designing the Ethereum base layer (L1) to support data availability and other features, which are then made available to L2 protocols such as rollups, validiums, and plasmas to enable Provide users with the same level of security as Ethereum on a larger scale.

This creates a separation of concerns within the Ethereum ecosystem: Ethereum L1 focuses on censorship resistance, reliability, stability, and maintaining and improving the core functions of a certain base layer, while L2 focuses on updating through different cultures and technologies. Contact users directly. But if you go down this path, an inevitable problem arises: L2 wants to provide users with faster confirmations than 5-20 seconds.

So far, at least in theory, it is L2’s responsibility to create its own “decentralized sequencer” network. A small group of validators may sign blocks every few hundred milliseconds and stake their stake behind those blocks. Eventually, the header files for these L2 chunks are published to L1.

1. There is a risk of "fraud" in the L2 validator set: first sign block B1, then sign the conflicting block B2 and submit it to the chain first.

2. Rollup has been slow to implement a decentralized sorting network.
3. Requiring decentralized sorting of all L2 is unreasonable and is equivalent to requiring rollup to do the same work as creating a new L1.
4. Justin Drake proposed using a base pre-confirmation mechanism that would allow all L2 (and L1) to share Ethereum-wide pre-confirmations.

Basic Pre-Confirmation

Basic Pre-Confirmation assumes that Ethereum proposers are highly sophisticated actors related to MEV. The approach exploits this complexity by incentivizing proposers to accept responsibility for providing pre-confirmation services.

The basic idea of ​​this approach is to create a standardized protocol where users can provide an additional fee to ensure an instant guarantee that a transaction will be included in the next block, as well as a statement on the results of executing that transaction. If a proposer breaks any promise made to any user, they can be slashed.

As stated, L1 transactions are guaranteed based on pre-confirmation. If rollups are "based", then all L2 blocks are L1 transactions, so the same mechanism can be used to provide pre-confirmation for any L2.

(Note: Ethereum proposers can bundle a series of transactions into bundles and package them into blocks through the fee mechanism, ensuring transaction execution and order. For example, the well-known clamp ensures that buying and selling before a certain transaction Sell ​​later. Vitalik The solution proposed here is conceptually consistent, with this proposer locking in the trading results in advance and speeding up the execution)

What are we actually looking at?

Suppose we achieve single-slot finality. We use technology similar to Orbit to reduce the number of validators signing per slot, but not by too much so that we can also make progress on the key goal of reducing the 32 ETH staking minimum. The slot time may be increased to 16 seconds, and then we use rollup pre-confirmation or basic pre-confirmation to provide users with faster confirmation. What we got in the end: an epoch-slot architecture. fenyeThe philosophical reason for epoch-and-slot architecture

epoch-and-slot architectureThe reason why epoch-and-slot architecture is so inevitable is that it takes less time to reach a rough consensus than to reach an agreement on the economic finality of something.

Number of nodes and time overhead

The number of nodes is a key factor:

• Approximate consensus only requires a few nodes, while economic finality requires the participation of a majority of nodes.
• After the number of nodes exceeds a certain scale, the time taken to collect signatures will increase.

Optimizing slot time in Ethereum

The 12-second slot time in Ethereum can be divided into three sub-slots:

• Block release and distribution
• Proof of block production
• Proof aggregation

Passed By reducing the number of provers and leveraging a specialized subset of nodes, the slot time can be reduced to approximately 2 seconds.

Improvement of epoch-and-slot architecture

epoch-and-slot architecture is reasonable, but it is worth exploring a more optimized design:

• Separation of concerns and reducing coupling between mechanisms.

L2’s strategy

L2 currently has three reasonable strategies:

• Ethereum native: Optimize Ethereum technology and values.
• Server Architecture: Utilize blockchain scaffolding to strike a balance between server efficiency and blockchain security.
• Trade: Fast chain, security provided by Ethereum.

slot time and SSF

Some applications have a slot time of 12 seconds which is sufficient. For other applications, an epoch-and-slot architecture is required. Three slot types:

• Ethereum native epoch-and-slot architecture
• Server pre-confirmation
• Committee pre-confirmation

Conclusion

It is important to explore the design space of epoch-and-slot architecture to optimize L1 and L2 user experience, and simplify L2 development.

The above is the detailed content of Vitalik supports route Epoch and slot: providing faster transaction confirmation time for Ethereum. For more information, please follow other related articles on the PHP Chinese website!