One of the important attributes of a good blockchain user experience is fast transaction confirmation time. Ethereum has made significant improvements in this aspect compared to five years ago, thanks to EIP-1559 and the upcoming transition to Proof of Stake (The Merge). With the stable block time, transactions sent on Layer 1 (L1) of Ethereum can usually be confirmed within 5-20 seconds, similar to the experience of using a credit card for payment. However, further improving the user experience is valuable, as some applications require even shorter delays, in the range of hundreds of milliseconds. This article explores some practical options for improving transaction confirmation time on Ethereum.
Table of Contents
Toggle
Overview of Existing Ideas and Technologies
Single Slot Finality
Rollup Preconfirmations
Based Preconfirmations
What are We Actually Looking At?
How Should L2 Do It?
Currently, Ethereum’s Gasper consensus uses a framework of a single slot and epoch. There is one slot every 12 seconds, where a subset of validators vote on the chain’s head, and within 32 slots (6.4 minutes), all validators have a chance to vote once. These votes are then interpreted as messages in a consensus algorithm similar to PBFT, providing a very strong economic guarantee called finality after two epochs (12.8 minutes).
In the past few years, we have become increasingly dissatisfied with the current approach for two main reasons. Firstly, it is complex, with many interaction errors between the slot-by-slot voting mechanism and the epoch-by-epoch finality mechanism. Secondly, 12.8 minutes is too long, and nobody 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 when more than one-third of validators are offline. SSF faces the challenge of each Ethereum staker needing 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. While this significantly speeds up “finality” to improve user experience, it does not change the fact that users still need to wait 5-20 seconds.
In the past few years, Ethereum has been following a roadmap centered around rollups, designing the Ethereum base layer (L1) to support data availability and other functionalities, which are then 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 core functions of the base layer, while L2 focuses on directly interacting with users through different cultures and technological approaches. However, if we continue on this path, an inevitable problem arises: L2s want to provide faster confirmations than 5-20 seconds.
So far, it has been the responsibility of L2s to create their own “decentralized sequencer” networks. A small group of validators could sign blocks every few hundred milliseconds and commit their staked assets behind those blocks. Eventually, the headers of these L2 blocks would 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 this, they will be detected and lose their staked assets. We have already seen practical examples of this in centralized versions, but on the other hand, progress in developing decentralized sequencing networks with rollups has been slow. One could argue that it is unfair to require all L2s to do decentralized sequencing: we are asking rollups to do work almost as difficult as creating an entirely new L1. Therefore, Justin Drake has been advocating for an approach that allows all L2s (and L1) to use a shared preconfirmation mechanism within the Ethereum scope: based preconfirmations.
The method of based preconfirmations assumes that Ethereum proposers are highly complex participants involved in MEV. Based preconfirmations utilize 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 their transactions are guaranteed to be included in the next block, along with a declaration of the execution result of that transaction. If proposers violate any commitments made to any user, they can be penalized.
As described, based preconfirmations provide guarantees for L1 transactions. If rollups are “Based,” then all L2 blocks are L1 transactions, so the same mechanism can be used to provide preconfirmations for any L2.
Assuming we achieve single slot finality, we use techniques 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 reducing the minimum 32 ETH staking requirement. The slot time may increase to 16 seconds, and then we use either rollup preconfirmations or based preconfirmations to provide faster confirmations for users. In the end, we obtain an epoch-slot framework.
There is a profound philosophical reason why the epoch-and-slot framework seems so difficult to avoid: it takes less time to achieve rough consensus than it does to achieve maximal “economic finality” on something.
One simple reason is the number of nodes. Although the old linear tradeoff between decentralization, finality time, and cost has become more moderate today thanks to highly optimized BLS aggregation and upcoming ZK-STARKs, the following reasons cannot be ignored:
“Approximate consensus” requires only a small number of nodes, while economic finality requires a majority of nodes.
Once the number of nodes exceeds a certain scale, it takes more time to collect signatures.
In today’s Ethereum, the 12-second slot is divided into three sub-slots: block publication 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 bigger factor is the “quality” of nodes. If we can also rely on specialized subsets of nodes to achieve approximate consensus (while still using the full validator set to determine finality), we can bring it down to around 2 seconds.
Therefore, in my view, the epoch-and-slot framework is clearly the right one, but not all epoch-and-slot systems are equal, and it is valuable to explore the design space more fully. The directions worth further exploration are not tightly coupled like Gasper, but have a stronger focus on separation of concerns between the two mechanisms.
In my view, L2 currently has three reasonable strategies:
1. Being “Based” both technically and spiritually. This means optimizing Ethereum’s base layer technical properties and its values (high decentralization, resistance to censorship, etc.). In its simplest form, you can think of these rollups as “branded shards,” but they can also have greater ambitions, experimenting with new virtual machine designs and other technological improvements.
2. Becoming a “server with blockchain scaffolding” and fully leveraging it. If you start with a server and then add STARK validity proofs to ensure the server follows the rules; ensure the right to exit or force transactions; the freedom of collective choice through coordinated mass exits or by changing the voting of sequencers, then you have gained most of the benefits of being on-chain while retaining most of the efficiency of being a server.
3. A compromise approach: a fast chain with a hundred nodes that provides additional interoperability and security to Ethereum. This is the practical roadmap for many L2 projects today.
For some applications (such as ENS, key storage, partial payment protocols), the 12-second block time is already sufficient. For those that are not applicable, the only solution is the epoch-and-slot framework. In all three cases, the “epoch” is the SSF of Ethereum, but the slots are different for each of the three cases:
An Ethereum-native epoch-and-slot framework
Server preconfirmations
Committee preconfirmations
A key question is, how well can we do in the first case? In particular, if it becomes very good, the significance of the third case diminishes. Since all “Based” solutions are not applicable to L2s like plasmas and validiums, the second case will always exist. If an Ethereum-native epoch-and-slot framework can reduce the slot time to 1 second, the space for the third case becomes much smaller.
Today, we are still far from the ultimate 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 there is still plenty of design space to explore, such as incorporating Orbit SSF as an epoch in epoch-and-slot schemes. The more options we have, the better we can serve L1 and L2 users, and the easier we can make the work of L2 developers.
Original article link
Successful Conclusion of CoinEx Taiwan’s 7th Anniversary Celebration, Embracing the Arrival of the Web3 Era Hand in Hand with Users
Since its establishment in 2017, CoinEx has been a professional cryptocurrency trading pla…