Quick Transaction Confirmation: A New Direction to Improve Ethereum User Experience

An important aspect of the blockchain user experience is transaction confirmation speed. In recent years, Ethereum has made significant progress in this area. Thanks to EIP-1559 and stable block times after the transition to PoS, transactions sent by users on L1 are typically confirmed within 5-20 seconds, roughly equivalent to the credit card payment experience. However, further reducing confirmation times is still valuable, as certain applications even require sub-second latency. This article will explore several viable solutions to enhance Ethereum's transaction confirmation speed.

Overview of Existing Technology

single-slot finality

Currently, the Gasper consensus of Ethereum adopts the architecture of slot (Slot) and epoch (Epoch). Every 12 seconds a slot, some validators vote on the chain head, and within 16.4 minutes 32 slots (, all validators take turns voting once. These votes are interpreted as messages in the PBFT-like consensus algorithm, providing strong economic guarantees of finality after two epochs )12.8 minutes (.

In recent years, this method has gradually revealed its flaws: first, the complexity is high, and the interaction between slot-level and epoch-level mechanisms can easily go wrong; second, the 12.8-minute waiting time is too long. Single Slot Finality ), SSF( replaces this architecture with a Tendermint-like mechanism, allowing block N to be finalized before N+1 is generated. SSF retains the "inactive leakage" mechanism, allowing the chain to continue operating and recover even when more than 1/3 of the validators are offline.

The main challenge of SSF is that each staker needs to publish two messages every 12 seconds, which brings a huge load to the chain. Although there are some mitigation solutions, such as the recent Orbit SSF proposal, users still need to wait 5-20 seconds to confirm transactions.

![Vitalik proposed the Epoch and slot scheme: provides faster transaction confirmation times for ETH, enhancing the end-user experience])https://img-cdn.gateio.im/webp-social/moments-17ece382908feb26098bc5db069ff84b.webp(

) Rollup pre-confirmation

In recent years, Ethereum has been following a rollup-centric roadmap, designing L1 to support foundational features such as data availability for L2 protocols ### like rollups, validiums, and plasmas (, providing equivalent security for users on a larger scale.

This has led to a division of labor within the Ethereum ecosystem: L1 focuses on censorship resistance, reliability, and core functionality improvements, while L2 more directly serves user needs. However, L2 aims to provide users with confirmations faster than 5-20 seconds.

In theory, creating a decentralized sorter network is the responsibility of L2. A small group of validators may sign blocks every few hundred milliseconds and stake assets as guarantees. The headers of these L2 blocks will eventually be published to L1.

But the L2 validator set may act maliciously: first signing block B1, then signing a conflicting B2 and submitting it early. Once discovered, they will lose their staked assets. There are already instances of centralized versions, but rollups are progressing slowly in developing decentralized ordering networks. Requiring all L2s to achieve decentralized ordering seems somewhat unfair, as it is almost equivalent to creating an entirely new L1. Therefore, it has been proposed that all L2) and L1( share a pre-confirmation mechanism within the scope of Ethereum: the base pre-confirmation.

) Basic Pre-confirmation

The basic pre-confirmation assumption is that Ethereum proposers are highly complex MEV-related participants, leveraging this complexity by incentivizing them to take on pre-confirmation service responsibilities.

The basic idea is to create standardized protocols, allowing users to pay an additional fee to guarantee that their transaction will be included in the next block immediately, as well as a statement on the transaction result. If the proposer defaults, they will be penalized.

This mechanism can be used for L1 transactions as well as for L2 blocks based on rollups.

![Vitalik proposed the Epoch and slot scheme: to provide ETH with faster transaction confirmation times and enhance the end-user experience]###https://img-cdn.gateio.im/webp-social/moments-cebb5794aeeb2ebb84fbdc0ea0ba2666.webp(

Future Outlook

Assuming we achieve single-slot finality, using technologies like Orbit to reduce the number of signature validators per slot, while also advancing the goal of lowering the 32 ETH staking threshold. The slot duration may be extended to 16 seconds, and then using rollup pre-confirmation or base pre-confirmation to provide users with faster confirmations. Ultimately, we arrive at a new epoch - slot architecture.

The deep-seated reason for this architecture being difficult to avoid is that the time required to reach a rough consensus on something is far less than the time needed to achieve the maximum "economic finality."

The main reasons include the number of nodes and the "quality" of the nodes. "Approximate consensus" only requires a small number of nodes, while economic finality needs the participation of a majority of nodes. A specialized subset of nodes can reduce the approximate protocol time to about 2 seconds.

Therefore, the epoch-slot architecture seems to be the right direction, but there are differences between different implementations. It is worth exploring a stronger separation of concerns between the two mechanisms, rather than being tightly coupled like Gasper.

![Vitalik proposed the Epoch and slot scheme: providing faster transaction confirmation times for ETH, enhancing the end-user experience])https://img-cdn.gateio.im/webp-social/moments-c36acc8d123e717d8dbd2c0b79a7a7ca.webp(

Selection of L2

Currently, there are three reasonable strategies for L2:

1. Technically and conceptually "based on" Ethereum, optimizing its foundational attributes and values. It can be seen as a "brand shard" and can also boldly innovate in areas such as new VM design.

2. Become a "server with blockchain scaffolding", fully leverage the advantages of centralization, while ensuring security through validity proof, exit mechanisms, and other means.

3. Compromise solution: a fast chain with about a hundred nodes, Ethereum provides additional interoperability and security. This is the current path for many L2 projects.

For certain applications like ENS, key storage, and some payment protocols, a block time of 12 seconds is sufficient. Other cases require an epoch-slot architecture, where "epoch" refers to Ethereum's SSF, and "slot" varies depending on the application.

The key question is to what extent Ethereum's native epoch-slot architecture can achieve. If the slot time can be reduced to 1 second, the space for the third solution will be greatly reduced.

Currently, we are still far from the final answers to these questions. The evolution of block proposer complexity remains highly uncertain. Novel designs like Orbit SSF provide ample space for exploration. The more options we have, the better experience we can offer to L1 and L2 users, and we can also simplify the work for L2 developers.

![Vitalik proposed the Epoch and slot scheme: providing faster transaction confirmation times for ETH, enhancing the end-user experience])https://img-cdn.gateio.im/webp-social/moments-2f66d4acd57a4e15f003a65c51b5471e.webp(