Original Author: Vitalik

Compiled by: Odaily Planet Daily, Nan Zhi

One of the important attributes of a good blockchain user experience is fast transaction confirmation time. Today, Ethereum has made significant improvements compared to five years ago. Thanks to EIP-1559 and the stable block time after the transition 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 using a credit card for payment. However, further improving the user experience is valuable, as some applications even require delays of a few hundred milliseconds or even shorter. This article will explore some practical options for Ethereum to improve transaction confirmation time.

Overview of Existing Ideas and Technologies

Single Slot Finality

Currently, Ethereum's Gasper consensus uses a single slot and Epoch architecture. Every 12 seconds, a slot, and a portion of validators vote on the head of the chain, and within 32 slots (6.4 minutes), all validators have the opportunity to vote once. These votes are then reinterpreted as a message similar to the PBFT consensus algorithm, and after two Epochs (12.8 minutes), they provide a very strong economic guarantee called finality.

In recent years, we have become increasingly dissatisfied with the current approach for two main reasons. Firstly, this approach is very complex, with many interaction errors between slot-to-slot voting mechanisms and Epoch-to-Epoch finality mechanisms. 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 the Tendermint consensus, where block N is finalized before block N+1 is generated. The main difference from Tendermint is that we retain the "inactivity leak" mechanism, which allows the chain to continue running and recover when more than 1/3 of validators are offline.

The main challenge of single slot finality is that it means every Ethereum staker needs to publish two messages every 12 seconds, which is a significant burden on the chain. There are some clever ideas to mitigate this issue, including the recent Orbit SSF proposal. Although this significantly speeds up "finality" to improve the user experience, it does not change the fact that users still need to wait 5-20 seconds.

Rollup Pre-confirmation

In recent years, Ethereum has been following a roadmap centered around rollups, designing the Ethereum base layer (L1) to support data availability and other functions, which can then be used by L2 protocols (such as rollups, validiums, and plasmas) to provide users with the same level of security at a larger scale.

This has led to a separation of concerns within the Ethereum ecosystem: Ethereum L1 focuses on censorship resistance, reliability, stability, and maintaining and improving certain core functions of the base layer, while L2 focuses on more direct user interaction through different cultures and technologies. However, moving along this path has inevitably led to a problem: L2 wants to provide faster confirmation for users than 5-20 seconds.

So far, at least in theory, it is the responsibility of L2 to create its own "decentralized sequencer" network. A small group of validators may sign blocks every few hundred milliseconds and stake their assets behind these blocks. Ultimately, the headers of these L2 blocks will be published to L1.

However, L2 validator sets can engage in "fraud": they can sign block B1 first, then sign a conflicting block B2 and submit it to the chain before B1. But if they do so, they will be detected and lose their staked assets. In fact, we have already seen practical cases of centralized versions, but on the other hand, progress in developing decentralized sequencer networks for rollups has been slow. It could be argued that requiring all L2s to perform decentralized sequencing is unfair: we are essentially asking rollups to do the same work as creating a completely new L1. Therefore, Justin Drake has been promoting a method that allows all L2s (and L1) to use a shared pre-confirmation mechanism within the Ethereum scope: base preconfirmation.

Base Pre-confirmation

The base pre-confirmation method assumes that Ethereum proposers are highly complex participants related to MEV. The method based on pre-confirmation utilizes this complexity by incentivizing these complex proposers to accept the responsibility of providing pre-confirmation services.

The basic idea of this method is to create a standardized protocol where users can provide additional fees to ensure immediate guarantees that their transactions will be included in the next block, as well as a declaration of the results of executing the transaction. If proposers violate any commitments made to any user, they can be penalized.

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

What Are We Actually Looking At?

Assuming we have implemented single slot finality. We use technology similar to Orbit to reduce the number of validators signing each slot, but not too much, so that we can also make progress in reducing the minimum staking limit of 32 ETH. The slot time may increase to 16 seconds, and then we use rollup pre-confirmation or base pre-confirmation to provide faster confirmation for users. In the end, what do we get: an epoch-slot architecture.

There is a profound philosophical reason why the epoch-and-slot architecture seems so difficult to avoid: it takes less time to reach rough consensus on something than to reach maximum "economic finality" on something.

One simple reason is the number of nodes. Although the old linear trade-off between decentralization/finality time/overhead now looks mild due to super-optimized BLS aggregation and upcoming ZK-STARKs, the following reasons cannot be ignored:

• "Approximate consensus" only requires a small number of nodes, while economic finality requires most nodes.
• Once the number of nodes exceeds a certain scale, more time is needed to collect signatures.

In today's Ethereum, the 12-second slot is divided into three sub-slots: block publishing and distribution, proving, and proof aggregation. If the number of validators is significantly reduced, we can reduce it to two sub-slots and use an 8-second slot time. Another, more practical, and larger factor is the "quality" of the nodes. Another major factor is the "quality" of the nodes. If we can also rely on a specialized subset of nodes to achieve approximate consensus (and still use the full validator set to determine finality), we can reduce it to about 2 seconds.

So in my view, the epoch-and-slot architecture is clearly the right approach, but not all epoch-and-slot architectures are equal, and it is valuable to explore the design space more fully. The direction worth exploring in depth is not as tightly integrated as Gasper, but with a stronger focus on separating the two mechanisms.

How Should L2 Proceed?

In my view, L2 currently has three reasonable strategies:

• Technically and spiritually "based". That is, they optimize Ethereum's base layer technical properties and its values (high decentralization, censorship resistance, etc.). In its simplest form, you can think of these rollups as "branded shards," but they can also have larger ambitions, experimenting with new virtual machine designs and other technical improvements.
• Become a "server with blockchain scaffolding" and fully utilize it. If you start from a server and then add STARK validity proofs to ensure the server follows the rules; ensure user exits or the right to force transactions; the freedom of collective choice, through coordinated large-scale exits or by changing the sequencer's votes, then you have most of the benefits of on-chain while retaining most of the efficiency of the server.
• A compromise approach: a fast chain with a hundred nodes, providing additional interoperability and security for Ethereum. This is the current practical roadmap for many L2 projects.

For some applications (such as ENS, key storage, and some payment protocols), a 12-second block time is already sufficient. For those applications that are not suitable, the only solution is the epoch-and-slot architecture. In all three cases, "epoch" is Ethereum's SSF, but the slot is different in the three cases mentioned above:

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

A key question is, how well can we do in the first category? In particular, if it becomes very good, then the significance of the third category seems less. Because all "based" solutions are not applicable to off-chain data L2s such as plasmas and validiums, the second category will always exist. If a native Ethereum epoch-and-slot architecture can reduce slot time to 1 second, then the space for the third category becomes much smaller.

Today, we are still far from the ultimate answers to these questions. A key question is: how complex will block proposers become, which is still an area with considerable uncertainty. Designs like Orbit SSF are very novel, so exploring the design space, such as incorporating Orbit SSF into the epoch-and-slot, is still worth fully exploring. The more options we have, the better we can do for L1 and L2 users, and the easier we can make the work for L2 developers.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。