One of the important attributes of a good blockchain user experience is fast transaction confirmation time. 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, which is comparable to the experience of using a credit card. However, further improving the user experience is valuable, and certain applications even require delays of a few hundred milliseconds or less. This article will explore some practical options for improving transaction confirmation time on Ethereum.
Existing Ideas and Technological Overview
Single Slot Finality
Rollup Preconfirmation
Based Preconfirmations
What are we actually looking at?
How should L2 do it?
Currently, Ethereum’s Gasper consensus uses a single slot and epoch structure. There is one slot every 12 seconds, and a subset of validators vote 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 interpreted as messages in a consensus algorithm similar to PBFT, providing strong economic guarantees 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. First, this method is complex, with many interaction errors between slot-to-slot voting and epoch-level finality mechanisms. Second, 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 one-third of validators are offline. While we have seen practical examples of centralized versions, the development of decentralized ordering networks has been slow. It could be argued that requiring all L2s to have decentralized ordering is unfair, as it is asking rollups to do almost the same work as creating a brand new L1. Therefore, Justin Drake has been promoting an approach that allows all L2s (as well as L1) to use a shared preconfirmation mechanism across Ethereum called “Based Preconfirmations”.
Based Preconfirmations assume Ethereum proposers, who are highly complex participants in the MEV ecosystem. The method utilizes this complexity by incentivizing these complex proposers to accept the responsibility of providing preconfirmation service. The basic idea is to create a standardized protocol where users can provide additional fees to ensure immediate guarantees of inclusion in the next block, as well as a statement about the execution result of the 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, and the same mechanism can be used to provide preconfirmations for any L2.
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 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 recent years, Ethereum has followed a rollup-centric roadmap, designing Ethereum Layer 1 (L1) to support data availability and other functionalities for L2 protocols such as rollups, validiums, and plasmas that can provide users with security at a larger scale. This has led to a separation of concerns within the Ethereum ecosystem, with L1 focusing on censorship resistance, reliability, stability, and maintaining and improving core functionalities of the base layer, while L2 focuses on directly interacting with users through different cultures and technological approaches. However, if we continue down this path, an inevitable problem arises: L2s want to provide faster confirmations than 5-20 seconds.
Currently, it is theoretically the responsibility of L2s to create their own “decentralized ordering” network. A small group of validators may sign blocks every few hundred milliseconds and commit their staked assets behind these blocks. Eventually, the headers of these L2 blocks will be published to L1.
However, L2 validators can engage in “fraud” by signing block B1 first, then signing a conflicting block B2 and submitting it to the chain before B1. But if they do so, they will be caught and penalized. We have already seen practical cases of centralized versions, but on the other hand, rollups have been slow in developing decentralized ordering networks. It can be said that requiring all L2s to have decentralized ordering is unfair, as it is asking rollups to do almost the same work as creating a brand new L1. Therefore, Justin Drake has been promoting an approach that allows all L2s (as well as L1) to use a shared preconfirmation mechanism across Ethereum called “Based Preconfirmations”.
The “Based Preconfirmations” approach assumes that Ethereum proposers are highly complex participants in the MEV ecosystem. The method utilizes this complexity by incentivizing these complex proposers to accept the responsibility of providing preconfirmation service.
The basic idea is to create a standardized protocol where users can provide additional fees to ensure immediate guarantees of inclusion in the next block, as well as a statement about the execution result of the 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, and the same mechanism can be used to provide preconfirmations for any L2.
In conclusion, there are three reasonable strategies for L2s currently:
1. Technically and philosophically “Based”: They optimize Ethereum’s base layer technical properties and its values (high decentralization, resistance to censorship, etc.). In the simplest form, you can consider these rollups as “branded shards,” but they can also have larger ambitions and experiment with new virtual machine designs and other technological improvements.
2. Become a “server with blockchain scaffolding” and make full use of it. If you start from a server and then add STARK validity proofs to ensure that the server follows the rules; ensure the user’s right to exit or enforce transactions; the freedom of collective choice through coordinated large-scale exits or changing the votes of orderers, then you have gained most of the benefits of being on-chain while retaining most of the efficiency of a server.
3. Compromise: A fast chain with a hundred nodes that offers additional interoperability and security for Ethereum. This is the practical roadmap for many L2 projects today.
For certain applications such as ENS, key storage, and partial payment protocols, the 12-second block time is already sufficient. For those that do not apply, the only solution is the epoch-and-slot structure. In all three cases, the “epoch” is Ethereum’s SSF, but the slots differ in the above three cases:
– A native Ethereum epoch-and-slot structure
– Server preconfirmations
– Committee preconfirmations
A key question is how well can we do in the first category? In particular, if it becomes very good, the significance of the third category diminishes. As all “Based” schemes do not apply to L2s with off-chain data like plasmas and validiums, the second category will always exist. If a native Ethereum epoch-and-slot structure can reduce slot time to 1 second, then the space for the third category becomes much smaller.
We are still far from the final answers to these questions today. 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 into the epoch of an epoch-and-slot scheme. 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.
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…