What is the future of Layer2? Buterin: Three solutions to speed up the transaction confirmation time!

Ethereum co-founder Vitalik Buterin’s latest article discusses several methods to speed up Ethereum transaction confirmation time, including Single slot finality, Rollup pre-confirmation and Based pre-confirmation mechanisms, and emphasizes Understand the importance of slot and epoch architecture in providing fast transaction confirmation.

Note: In Ethereum 2.0, Slot is a time period every 12 seconds, usually a block is generated; and Epoch is a time unit composed of 32 Slots, performed every 6 minutes and 24 seconds, responsible for the status Inspection and verification reward and punishment processing.

Single-slot finality speeds up "finalization" time

Buterin said that one of the important features of a good blockchain user experience is fast transaction confirmation time. Ethereum has improved significantly in this regard since the past five years, especially with the introduction of stable block times after EIP-1559 and the Merge, where transactions on L1 can be obtained in 5-20 seconds Confirmed, this is comparable to the experience of paying with a credit card.

However, enhancements are still needed to further improve user experience, especially for applications that require millisecond or lower latency. Some practical options for Ethereum to improve transaction confirmation speed are discussed below.

First, Buterin proposed Single Slot Finality (SSF) as an alternative to the existing Gasper consensus mechanism. Currently, although Ethereum's Gasper consensus mechanism allows transactions to be confirmed within 5-20 seconds, the 12.8-minute finality time is considered too long.

The SSF mechanism is closer to the Tendermint consensus, which can finalize the previous block before the new block is formed, and allows the blockchain to continue running through the "inactivity leakage" mechanism and recover when more than 1/3 of the validators are offline .

The main challenge of SSF is the possible increase in network load because it requires all Ethereum stakers to publish two messages per 12-second slot. The Orbit SSF proposal is a powerful solution to this problem. But even so, while this significantly improves the user experience by making finalization come faster, it doesn't change the fact that users need to wait 5-20 seconds.

SSF proposal design drawing

Rollup pre-confirmation & Based pre-confirmation

In addition, Buterin also discussed the mechanisms of Rollup pre-confirmation and Based pre-confirmation. Ethereum has always followed a Rollup-centered development route, designing L1 to support data availability and other functions, while L2 provides users with larger-scale services. However, this will face an inevitable problem: L2 needs to be confirmed for users. Users are served at speeds faster than 5-20 seconds.

Plus, it’s unfair to require all L2s to implement decentralized ordering networks, which pretty much requires them to do most of the new L1 work.

To solve this problem, Justin Drake launched a shared pre-confirmation mechanism based on Ethereum - Based pre-confirmation, making it accessible to all L2 and L1.

Based pre-confirmation approach assumes that Ethereum proposers will be highly sophisticated participants for MEV (Maximum Extractable Value) related reasons. Pre-confirmation based approaches exploit this complexity by incentivizing these experienced proposers to provide pre-confirmation services. The basic idea is to create a standardized protocol through which users can pay a premium in exchange for an immediate guarantee that the transaction will be included in the next block, and possibly a claim on the results of executing the transaction. If a proposer breaks any of their promises to users, they will be slashed.

In summary, Based preconfirmation provides guarantee for L1 transactions. If Rollup is "Based", then all L2 blocks are L1 transactions, so the same mechanism can be used to provide pre-confirmation for any L2.

3 development directions of L2

Finally, Buterin proposed three reasonable development strategies for L2:

1. Both the technical and spiritual levels are based on Ethereum: These L2 are optimized for the technical attributes and value of the Ethereum base layer (high Decentralization, censorship resistance, etc.) delivery channel. Simply put, these rollups can be considered "brand shards" and allow for extensive experimentation in new virtual machine designs and other technical improvements.

2. Server-based blockchain architecture: These L2s start with servers and then add proof of STARK validity, user rights to withdraw or force transactions, and freedom of collective choice (such as coordinating mass withdrawals or changing orderers capabilities), while maintaining server efficiency while reaping the benefits of a large number of on-chain operations.

3. Compromise: Using a hundred-node fast chain, Ethereum provides additional interoperability and security, which is the actual roadmap for many L2 projects.

Each of these three strategies has a different slot-and-epoch architecture:

• Ethereum native architecture

• Server pre-confirmation

• Committee pre-confirmation

Buterin asked the key question is, how good can we be in the first category? If the first category becomes very good, the significance of the third category may diminish. The second category will always exist, because any "Ethereum-based" solution will not work with off-chain data L2 such as plasmas and validiums.

Buterin concluded that we need more options to simplify the work of L2 developers and improve the user experience.

The above is the detailed content of What is the future of Layer2? Buterin: Three solutions to speed up the transaction confirmation time!. For more information, please follow other related articles on the PHP Chinese website!