For applications that require shorter confirmation times, the only solution is the slot-and-epoch architecture.

Author: Vitalik Buterin, Co-founder of Ethereum

Translator: Luffy, Foresight News

A crucial feature for a good user experience on the blockchain is fast transaction confirmation times. Ethereum has made significant progress compared to five years ago, thanks to the stable block generation time after the implementation of EIP-1559 and the PoS merge. Users can now receive reliable confirmations for transactions sent on L1 within 5-20 seconds, approaching the experience of credit card payments. However, there is still room for improvement in Ethereum's user experience, as some applications require transaction delays of a few hundred milliseconds or even shorter. This article will introduce some practical solutions to speed up Ethereum's transaction confirmation times.

Overview of Existing Ideas and Technologies

Single Slot Finality

Currently, Ethereum's Gasper consensus adopts a slot and epoch architecture. Every 12 seconds (the duration of a single slot), a subset of validators will vote on the latest block on the blockchain. Within 32 slots (6.4 minutes, an epoch consists of 32 slots), all validators have the opportunity to vote once. These votes are then interpreted as messages similar to those in the PBFT consensus algorithm, providing very strict economic guarantees after two epochs (12.8 minutes), which is finality.

In recent years, we have become increasingly dissatisfied with this approach. The main reasons are: (i) it is very complex, with many interaction errors between the per-slot voting mechanism and the per-epoch finality mechanism; (ii) 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 blockchain to continue running and recover when more than 1/3 of validators are offline.

Design diagram of the SSF solution

The main challenge of SSF is that it seems to imply that every Ethereum staker needs to publish two messages every 12 seconds, which is a significant burden for the blockchain. There are some clever ideas to mitigate this situation, including the recent Orbit SSF proposal (https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928). Nevertheless, while this solution can significantly improve user experience by speeding up "finality," it does not shorten the 5-20 seconds that users need to wait.

Rollup Preconfirmation

In recent years, Ethereum has been following a roadmap centered around Rollup, focusing on supporting data availability and other features designed for the Ethereum base layer (L1). These features are used by L2 protocols such as Rollup (as well as Validiums and Plasmas), which can provide users with the same level of security as Ethereum but on a much larger scale.

This has led to a separation of concerns in the Ethereum ecosystem: Ethereum L1 can focus on censorship resistance, reliability, stability, and maintaining and improving certain core functions, while L2 can focus on user experience through different cultural and technical trade-offs. However, if you continue down this path, there is an inevitable problem: L2 focuses on serving users who want faster confirmations within 5-20 seconds.

So far, creating your own "decentralized ordering" network has become an unavoidable responsibility for L2. Every few hundred milliseconds, a small subset of validators will sign blocks, staking their tokens in these blocks. Eventually, the block headers of these L2 blocks will be published on L1.

L2 validator sets can cheat: 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 face penalties and lose their stake. In practice, we have seen a centralized version of this practice, but progress in developing decentralized ordering networks for Rollup has been slow. You could say that requiring all L2 to perform decentralized ordering is an unfair trade: this is equivalent to requiring Rollup to do the same work as creating a brand new L1. For some reason, Ethereum Foundation researcher Justin Drake has been promoting a method for all L2 (and L1) to access a shared Ethereum preconfirmation mechanism: based preconfirmations.

Based Preconfirmations

The based preconfirmations method assumes that Ethereum proposers will become highly complex participants for MEV-related reasons (see here for my explanation of MEV, and see proposal). The based preconfirmations method leverages this complexity to incentivize these mature proposers to provide preconfirmation services.

The basic idea is to create a standardized protocol through which users can provide additional fees to guarantee immediate inclusion of their transactions in the next block and receive a declaration about the result of executing the transaction. If proposers violate commitments made to any user, they will be penalized.

As mentioned above, the based preconfirmations mechanism provides guarantees for L1 transactions. If Rollup is "Based Rollup" (note: Based Rollup was proposed by Justin Drake in March 2023 and is a Rollup where ordering is entirely done by L1), then all L2 blocks are L1 transactions, and the same mechanism can be used to provide preconfirmations for any L2.

What are we actually seeing?

Assuming we implement single slot finality. We use a technology similar to Orbit to reduce the number of validators signing in each slot, so we can also reduce the minimum staking amount to 32 ETH, killing two birds with one stone. As a result, the slot time may gradually increase to 16 seconds. Then we use Rollup preconfirmation or Based preconfirmations to provide faster guarantees for users. What do we have now? An epoch-and-slot architecture.

The meme "They're the same picture" has been overused, so I'll just put together an old chart I drew a few years ago with the L2 preconfirmation chart to describe Gasper's slot-and-epoch architecture, I hope I can explain it clearly.

There is a profound philosophical reason why people always inevitably use the epoch-and-slot architecture: achieving approximate consensus on something fundamentally takes less time than achieving maximal "economic finality" consensus on something.

A simple reason is the number of nodes. Although due to highly optimized BLS aggregation and soon-to-come ZK-STARK, the old progressive decentralization/finality time/overhead tradeoff now looks more moderate, fundamentally, the following points are still correct:

• "Approximate consensus" only requires a small number of nodes, while economic finality requires a significant portion of all nodes.
• Once the number of nodes exceeds a certain scale, you need to spend more time collecting signatures.

In the current Ethereum, the 12-second slot is divided into three sub-slots for (i) block publishing and distribution, (ii) proving, and (iii) proof aggregation. If the number of provers is much smaller, we can reduce it to two sub-slots and have an 8-second slot time. Another factor that is actually more important is the "quality" of the nodes. If we can also rely on specialized subsets of nodes to achieve approximate consensus (and still use the full validator set to achieve finality), we can reasonably shorten it to about 2 seconds.

Therefore, I believe that (i) the slot-and-epoch architecture is obviously correct, but (ii) not all slot-and-epoch architectures are the same, and we need to explore the design space more fully. In particular, schemes that are not as tightly interwoven as Gasper are worth exploring.

What Should L2 Do?

In my view, currently L2 can take three reasonable strategies:

• "Based" both technically and spiritually. In other words, L2 is a better conduit for the technical properties and values of the Ethereum base layer (highly decentralized, censorship-resistant, etc.). In its simplest form, you can think of these Rollups as "branded shards," but they can also be more ambitious and experiment with new virtual machine designs and other technical improvements.
• Become a "server with a blockchain scaffold" and make full use of it. If you start from a server and then add (i) STARK validity proofs to ensure the server complies with the rules, (ii) guarantees of user exits or forced transactions, and possibly (iii) the freedom of collective choice, whether through coordinated large-scale exits or the ability to vote to change the orderer, then you have gained many on-chain benefits while retaining most of the efficiency of the server.
• A compromise: a fast blockchain with 100 nodes, relying on Ethereum for additional interoperability and security. This is the current roadmap for many L2 projects in practice.

For some applications (such as ENS, keystores, and some payment scenarios), a 12-second block time is sufficient. For applications that require shorter confirmation times, the only solution is the slot-and-epoch architecture. In all three cases, the "epoch" is Ethereum's SSF (perhaps we can redefine the acronym to mean something other than "single slot," such as "Secure Speedy Finality"). But in the above three cases, the "slot" is different:

• Ethereum's native slot-and-epoch architecture
• Server preconfirmation
• Committee preconfirmation

A key question is, how well can we do something from category (1)? In particular, if it becomes very good, then category (3) seems to be less meaningful. Category (2) will always exist because anything "based" does not apply to off-chain data L2, such as Plasma and Validium. But if Ethereum's native slot-and-epoch architecture can be shortened to 1 second "slot" (i.e., preconfirmation) time, then the space for category (3) will become much smaller.

Today, we are still far from getting the final answers to these questions. How complex will block proposers become? The answer to this key question still has quite a bit of uncertainty. Designs like Orbit SSF are very novel, so there is still much exploration needed in the design space for slot-and-epoch schemes similar to Orbit SSF. The more choices we have, the better we can do for users on L1 and L2, and we can also simplify the work for L2 developers.

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