The essential feature of blockchain for a good user experience is fast transaction confirmation time. Compared to five years ago, Ethereum has made great progress, thanks to the stable block time after the EIP-1559 and PoS merge. Transactions sent by users on L1 can be reliably confirmed within 5-20 seconds, which is close to the user experience of credit card payments. However, further improvement is needed because some applications require transaction delays of hundreds of milliseconds or even shorter.
The existing ideas and technology overview of single slot finality (SSF)
The current Ethereum consensus mechanism uses a slot and epoch architecture. Every 12 seconds (the duration of a single slot), a subset of validators will vote on the latest block of the blockchain. Within 32 slots (6.4 minutes, an epoch contains 32 slots), all validators have the opportunity to vote once. These votes are then reinterpreted as messages similar to the consensus algorithm in PBFT, which provides very strict economic guarantees after two epochs (12.8 minutes), which is finality.
In the past few years, dissatisfaction with this approach has grown. The main reasons are: (i) it is very complex, with many interaction errors between the voting mechanism of each slot and the finality mechanism of each epoch; (ii) 12.8 minutes is too long, and no one is willing to wait that long.
Single slot finality (SSF) replaces this architecture with a mechanism similar to the Tendermint consensus, where block N is completed before block N+1 is generated. The main difference from Tendermint is that it retains the “inactivity leak” mechanism, which allows the blockchain to continue running and recover when more than 1/3 of the validators are offline.
The main challenge of SSF is that it implies that every Ethereum staker needs to publish two messages every 12 seconds, which is a significant burden on the blockchain. There are some clever ideas to mitigate this, including the recent Orbit SSF proposal. However, although this approach can significantly improve the user experience by speeding up “finality,” it does not shorten the time users need to wait for 5-20 seconds.
Rollup Preconfirmation
In the past few years, Ethereum has followed a roadmap centered around supporting data availability and other features designed for the Ethereum base layer (L1). These features are used by L2 protocols such as Rollup, Validiums, and Plasmas, which can provide users with the same level of security as Ethereum but on a much larger scale.
This has created a separation of concerns in the Ethereum ecosystem: Ethereum L1 can focus on anti-censorship, reliability, stability, and maintaining and improving certain core basic 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 confirmation within 5-20 seconds.
So far, creating its own “decentralized ordering” network has become an indispensable responsibility of L2. Every few hundred milliseconds, a small subset of validators will sign blocks and stake their tokens in these blocks. Eventually, the block headers of these L2 blocks will be published to 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, they will face penalties and lose their stake. In practice, we have seen a centralized version of this practice, but Rollup has made slow progress in developing decentralized ordering networks. You could say that requiring L2 to have decentralized ordering is an unfair trade: it is equivalent to requiring Rollup to do the same work as creating a completely new L1. For some reason, Ethereum Foundation researcher Justin Drake has been promoting a method for all L2 (and L1) to access shared Ethereum preconfirmation:
Based preconfirmations.
The basic idea is to create a standardized protocol through which users can provide additional fees to guarantee their transactions are included in the next block immediately and receive a declaration about the results of executing the transaction. If the proposer violates the commitment to any user, they will be penalized.
As mentioned above, the based preconfirmation mechanism provides guarantees for L1 transactions. If Rollup is a “Based Rollup” (proposed by Justin Drake in March 2023, it is a Rollup that is completely ordered by L1), then all L2 blocks are L1 transactions and can use the same mechanism to provide preconfirmation for any L2.
What are we actually seeing?
Assuming we achieve single slot finality, we use technologies similar to Orbit to reduce the number of validators signing each slot, so we can also reduce the minimum stake of 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 will only put an old chart I drew years ago together with the L2 preconfirmation chart to describe the Gasper slot-and-epoch architecture. I hope I can explain this clearly.
There is a profound philosophical reason why people always inevitably use the epoch-and-slot architecture: achieving approximate consensus on something essentially takes less time than achieving “economically final” consensus to the maximum extent.
A simple reason is the number of nodes. Although the old progressive decentralization/finality/time/cost trade-offs now seem more moderate due to super-optimized BLS aggregation and soon ZK-STARK, fundamentally, the following point is still correct:
“Approximate consensus” only requires a small number of nodes, while economic finality requires a considerable 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 block publication and distribution, proof, and proof aggregation. If the number of validators is much less, 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 still rely on a specialized subset of nodes to achieve approximate agreement (and still use the full validator set to achieve finality), we can reasonably shorten it to about 2 seconds.
Therefore, I think (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 opinion, there are three reasonable strategies that L2 can adopt:
Be “based” both technically and spiritually. This means that L2 is a better transmission channel for the technical attributes and values of the Ethereum base layer (highly decentralized, anti-censorship, etc.). To put it simply, you can think of these Rollups as “branded sharding,” but they can also be more ambitious and conduct a lot of experiments with new virtual machine designs and other technical improvements.
Become a “server with blockchain scaffolding” and make full use of it. If you start from the server and then add (i) STARK validity proofs to ensure that the server complies with the rules, (ii) the right to guarantee user exits or enforce transactions, and possible (iii) collective choice freedom, whether through coordinated mass exits or the ability to change the orderer through voting, then you have gained many benefits on-chain while retaining most of the efficiency of the server.
A compromise: a fast blockchain with 100 nodes that relies on Ethereum to provide additional interoperability and security. This is the current roadmap for many L2 projects.
For some applications (such as ENS, keystores, and some payment scenarios), a 12-second block time is enough. For applications that require shorter confirmation times, the only solution is slot-and-epoch architecture. In all three cases, the “epoch” is the SSF of Ethereum (perhaps we can redefine the acronym to mean something other than “single slot,” such as “Secure Speedy Finality”). But in the above three cases, “slot” is different:
The slot-and-epoch architecture of Ethereum-native
Server preconfirmation
Committee preconfirmation
A key question is how well we can do something in category (1)? In particular, if it becomes very good, then category (3) seems to be less meaningful. Category (2) will always exist because nothing “based” applies to off-chain data L2, such as Plasma and Validium. But if the Ethereum-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 a fair amount of uncertainty. Designs like Orbit SSF are very novel, so the design space for slot-and-epoch schemes similar to Orbit SSF still needs more exploration. The more choices we have, the better we can do for users on L1 and L2, and we can also simplify the work of L2 developers.