Author: Vitalik

Translator: Nan Zhi, Odaily Planet Daily

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, 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. A slot occurs every 12 seconds, and a subset of validators votes on the head of the chain, with all validators having the opportunity to vote once within 32 slots (6.4 minutes). These votes are then reinterpreted as a message similar to the PBFT consensus algorithm, and after two epochs (12.8 minutes), a very strong economic guarantee called finality is provided.

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 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 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.

(Note: Inactivity leak is a mechanism in PoS designed to penalize validators who are inactive for a long time, and once marked as inactive, their staked ETH will be continuously penalized.

_Tendermint is an efficient and secure Byzantine fault-tolerant consensus algorithm that allows for fast transaction confirmation and ensures that the blockchain system can continue to operate normally even when some nodes are malicious or 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. While 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.

_(Note: Finality is not the same event as transactions being included in a block and confirmed. In the case where transactions are confirmed but finality has not been achieved, forks or rollbacks may occur.)

Rollup Preconfirmation

In recent years, Ethereum has been following a roadmap centered around rollups, designing the Ethereum base layer (L1) to support data availability and other features, which can then be used by L2 protocols (such as rollups, validiums, and plasmas) to provide users with the same level of security as Ethereum on 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, if we continue along this path, an inevitable problem arises: L2 hopes to provide faster confirmation than 5-20 seconds for users.

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 practice, we have already seen actual 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 preconfirmation mechanism within the Ethereum scope: base preconfirmation.

Base Preconfirmation

The base preconfirmation method assumes that Ethereum proposers are highly complex participants related to MEV. The method of base preconfirmation leverages this complexity by incentivizing these complex proposers to accept the responsibility of providing preconfirmation services.

The basic idea of this method is to create a standardized protocol where users can provide additional fees to ensure that transactions will be immediately guaranteed to 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 preconfirmation 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 preconfirmation for any L2.

_(Note: Ethereum proposers are able to bundle a series of transactions into a bundle and include them in a block through a fee mechanism, ensuring transaction execution and order. For example, the well-known sandwich, through which it ensures buying before and selling after a certain transaction. Vitalik's proposed concept here is conceptually consistent, as it locks in transaction results in advance to expedite execution.)

What are we actually looking at?

Assuming we implement single slot finality. We use technology similar to Orbit to reduce the number of validators signing each slot, but not by 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 preconfirmation or base preconfirmation 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 maximal "economic finality" on it.

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

• "Rough consensus" only requires a small number of nodes, while economic finality requires a majority of nodes.
• Once the number of nodes exceeds a certain scale, you need to spend more time collecting 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 provers 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. If we can also rely on a specialized subset of nodes to reach rough consensus (and still use the full validator set to determine finality), we can reduce it to about 2 seconds.

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

How should L2 proceed?

In my view, there are currently three reasonable strategies for L2:

• Be "based" both technically and spiritually. That is, they optimize Ethereum's base layer technical properties and its values (highly decentralized, censorship-resistant, etc.). In its simplest form, you can think of these rollups as "branded shards," but they can also have larger ambitions, experimenting extensively with new virtual machine designs and other technical improvements.
• Become a "server with a blockchain scaffold" and fully utilize it. If you start from a server and then add STARK validity proofs to ensure that the server follows the rules; ensure the right to exit or enforce transactions; the freedom of collective choice, through coordinated large-scale exits or by changing the votes of the sequencers, then you have gained 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 epoch-and-slot architecture for Ethereum
• Server preconfirmation
• Committee preconfirmation

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 will be much smaller. 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 epoch-and-slot architecture for Ethereum can reduce the slot time to 1 second, then the space for the third category will become much smaller.

Today, we are far from the final answers to these questions. A key question is: how complex will block proposers become, which is still an area with quite a bit of uncertainty. Designs like Orbit SSF are very novel, so the design space for using Orbit SSF as an epoch in epoch-and-slot and other schemes is still worth exploring fully. The more options we have, the better we can do for users of L1 and L2, and the simpler we can make the work of L2 developers.

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