Discussing Feasible Solutions for Improving Ethereum Transaction Confirmation Speed

An important metric of the blockchain user experience is transaction confirmation time. In recent years, Ethereum has made significant progress in this area. Currently, transactions sent by users on L1 can typically be confirmed within 5 to 20 seconds, which is roughly comparable to the credit card payment experience. However, further reducing confirmation time is still valuable, as certain applications require sub-second latency. This article will explore several possible solutions for Ethereum to improve transaction confirmation times.

Overview of Existing Technology

Single-slot finality

The Gasper consensus mechanism currently adopted by Ethereum is based on a slot and epoch structure. Each slot lasts for 12 seconds, during which a subset of validators votes on the head of the chain. Within 32 slots (6.4 minutes), all validators have the opportunity to vote once. These votes are interpreted as messages in a PBFT-like consensus algorithm, and after two epochs (12.8 minutes), they provide strong economic guarantees of finality.

However, this approach has issues of complexity and excessive time. Single Slot Finality (SSF) proposes to replace the existing architecture with a mechanism similar to Tendermint, which completes the final confirmation of the current block before generating the next block. The main challenge of SSF is the need for a large amount of message interaction every 12 seconds, which places a significant burden on the chain. Although there are some mitigation solutions, such as the Orbit SSF proposal, users still have to wait 5-20 seconds to confirm their transactions.

Rollup Pre-confirmation

Ethereum has always followed a rollup-centric roadmap, designing L1 as a foundational layer that supports data availability and other functionalities for L2 protocols. This layered architecture allows L1 to focus on censorship resistance, reliability, and core functionality improvements, while L2 directly serves user needs.

In theory, L2 can create its own "decentralized sorter" network, signing blocks every few hundred milliseconds. However, it seems unrealistic to require all L2s to implement decentralized sorting. Therefore, a proposal has been made to allow all L2s and L1 to share a pre-confirmation mechanism: basic pre-confirmation.

Basic Pre-confirmation

The basic pre-confirmation assumption is that Ethereum proposers are complex MEV participants. This method incentivizes these proposers to provide pre-confirmation services. Users can pay an additional fee to receive an instant guarantee that their transaction will be included in the next block. If the proposer violates the commitment, they will face penalties.

This mechanism is applicable not only to L1 transactions but also to "Ethereum-based" rollups, where all L2 blocks are essentially L1 transactions and can therefore enjoy the same pre-confirmation mechanism.

Possible Development Directions

Assuming single-slot finality is achieved and the number of validators signing each slot is reduced using technology similar to Orbit. The slot duration may increase to 16 seconds, while using rollup pre-confirmation or base pre-confirmation to provide users with faster confirmations. This effectively creates a new epoch-slot architecture.

The epoch-slot architecture seems unavoidable, primarily because the time required to reach a rough consensus is much shorter than the time needed to achieve the maximum level of "economic finality". This involves factors such as the number of nodes and the "quality" of the nodes.

Possible Strategies for L2

There are currently three main strategies for L2:

1. Technically and conceptually "based on" Ethereum, optimizing its underlying layer attributes and values.
2. Become a "server with blockchain scaffolding", fully utilizing centralized efficiency while retaining the advantages of decentralization.
3. Compromise: Combining the speed of the chain with the security of Ethereum.

For different applications, a block time of 12 seconds may be sufficient. For applications that require faster confirmations, the only solution is the epoch-slot architecture. The key question is how well Ethereum's native epoch-slot architecture can perform, as this will affect the development space for other solutions.

Currently, we are still far from the final answers to these questions. The complexity of block proposers, the potential of new technologies like Orbit SSF, and other uncertainties exist. Exploring more design solutions helps provide better services for L1 and L2 users and simplifies the work for L2 developers.