"The epoch-and-slot architecture is obviously the right answer, but the architecture and slot solutions still need to be explored."
Original author | Vitalik Buterin
Compilation | Odaily Planet Daily Nan Zhi
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 techniques
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).
(Odaily Note: For details on the specific principles, please refer to "Detailed Explanation of the Working Principle of Ethereum POS: Epoch, Slot and Beacon Block")
Over the past few years we have become increasingly dissatisfied with our current approach. There are two main reasons for this, firstly the method is complicated and there are many interaction bugs between the slot-to-slot voting mechanism and the Epoch-to-Epoch finality mechanism, and 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 from 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.
(Odaily 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 staked ETH will continue to be punished. Tendermint is an efficient and safe Byzantine fault tolerance Consensus algorithm allows for rapid transaction confirmation and ensures that the blockchain system can still operate normally even if some nodes are malicious or offline.)
The main challenge with single-slot finality is that it means each Ethereum staker needs to publish two messages every 12 seconds, which is a significant 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.
(Odaily 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
Over the past few 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 available to L2 protocols such as rollups, validiums, and plasmas. Able to 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 being more direct through different cultures and technologies. reach users. 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, in theory at least, it has been L2's responsibility to create its own network of "decentralized sequencers." 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.
But the L2 validator set can "cheat": they can sign block B 1 first, and then sign a conflicting block B 2 and commit it to the chain before B 1. But if they do, they will be caught out and lose their pledged assets. We have actually seen practical examples of centralized versions, but rollup on the other hand has been slow to develop a decentralized sorting network. You could argue that requiring decentralized ordering of all L2s is unfair: we're asking rollup to do pretty much the same job as creating an entirely new L1. As such, Justin Drake has been promoting a way for all L2 (and therefore L1) to use a shared Ethereum-wide preconfirmation mechanism: base preconfirmation.
Basic pre-confirmation
The approach to Based preconfirmations assumes that Ethereum proposers are highly sophisticated participants associated with MEV. Pre-confirmation-based approaches exploit this complexity by incentivizing these complex 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 claim 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.
(Odaily Note: Ethereum proposers can use the fee mechanism to bundle a series of transactions into a bundle and package it into a block to ensure transaction execution and order. For example, the well-known clip ensures that buying before a certain transaction And sell it later. The plan proposed here by Vitalik is conceptually the same. Use this proposer to lock in the transaction results in advance and speed 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 end up with: an epoch-slot architecture.
There's a deep philosophical reason why epoch-and-slot architecture seems so hard to avoid: It takes less time to roughly agree on something than it does to reach agreement on something with the greatest degree of "economic finality." .
A simple reason is the number of nodes. While the old linear decentralization/finality time/overhead trade-off now looks mild due to ultra-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 a majority of nodes.
Once the number of nodes exceeds a certain size, 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, attestation, and attestation aggregation. If the number of provers is significantly reduced, we can reduce to two subslots and use 8 seconds slot time. Another bigger factor is the "quality" of the node. If we could also rely on a specialized subset of nodes to reach approximate agreement (and still use the full set of validators to determine finality), we could get this down to about 2 seconds.
So in my opinion, the epoch-and-slot architecture is clearly correct, but not all epoch-and-slot architectures are equal, and there is value in exploring the design space more fully. A direction worthy of further research is not as tightly coupled as Gasper, but with a stronger separation of concerns between the two mechanisms.
What should L2 do?
In my opinion, L2 currently has three reasonable strategies:
1. It is both technically and spiritually “based”. That is, they optimize the technical properties of Ethereum’s base layer and its values (high decentralization, censorship resistance, etc.). In their simplest form, you can think of these rollups as "branded shards," but they can also be much more ambitious, experimenting heavily with new virtual machine designs and other technical improvements.
2. Become a “server with blockchain scaffolding” and make the most of it. If you start with a server and then add proofs of STARK validity to ensure that the server follows the rules; to ensure the right of users to withdraw or force transactions; and to ensure the freedom of collective choice, either through coordinated mass withdrawal or through a vote of change orderers, then you Most of the benefits of going on-chain have been obtained while retaining most of the efficiency of the server. (Odaily Note: Scaffolding refers to a tool or method that automatically generates the basic structure and code framework of a project so that developers can quickly start coding.)
3. A middle ground: a fast chain with a hundred nodes, Ethereum provides additional interoperability and security. This is the actual roadmap for many L2 projects right now.
For some applications (e.g. ENS, key storage, some payment protocols), a 12 second block time is sufficient. For those applications where this is not applicable, the only solution is an epoch-and-slot architecture. In all three cases, the "epoch" is Ethereum's SSF, but the slot is different in each of the three cases:
An Ethereum-native epoch-and-slot architecture
Server pre-confirmation
committee preconfirmation
A key question is, how good can we be in Category 1? Especially if it gets really good, it feels like Category 3 won't mean as much. Since all "based" solutions are not applicable to off-chain data L2 such as plasmas and validiums, category 2 will always exist. If an Ethereum-native epoch-and-slot architecture could be reduced to 1 second slot time, then the Class 3 space would become much smaller.
Today, we are far from final answers to these questions. A key question is how complex block proposers will become, which remains an area of considerable uncertainty. Designs like Orbit SSF are very novel, so the design space for schemes such as Orbit SSF as an epoch in an epoch-and-slot is still worth fully exploring. The more options we have, the better we can do for users of L1 and L2, and we can make life easier for L2 developers.
Original link
This article is reprinted with permission from Odaily Planet Daily
Source
