Vitalik's new article: How to shorten Ethereum's transaction confirmation time?

Original title: Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times

Original author: Vitalik Buterin

Original translation: Luffy, Foresight News

 

An essential feature of a good user experience on a blockchain is fast transaction confirmation times. Today's Ethereum has made great progress compared to five years ago, thanks to the stable block time after the merger of EIP-1559 and PoS. Transactions sent by users on L1 can be reliably confirmed within 5-20 seconds, which is close to the experience of credit card payment. However, Ethereum's user experience still needs further improvement, because some applications do require transaction delays of hundreds of milliseconds or even shorter. This article will introduce some practical solutions to speed up Ethereum transaction confirmation times.

 

Overview of Existing Ideas and Technologies

 

Single Slot Finality

 

Today, Ethereum's Gasper consensus uses a slot and epoch architecture. Every 12 seconds (the length of a single slot), a subset of validators publishes a vote on the latest block of the blockchain, and all validators have a chance to vote once within 32 slots (6.4 minutes, an epoch contains 32 slots). These votes are then reinterpreted as messages in a consensus algorithm similar to PBFT, which provides very strict economic guarantees after two epochs (12.8 minutes), which is finality.

 

Over the past few years, we have become increasingly dissatisfied with this approach. The main reasons are: (i) it is complex, and there are many interaction errors between the slot-by-slot voting mechanism and the epoch-by-epoch finality mechanism; (ii) 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 Tendermint consensus, where block N is finalized before block N+1 is produced. The main difference from Tendermint is that we retain the "inactivity leak" mechanism that allows the blockchain to continue to operate and recover when more than 1/3 of validators are offline.

 

Single slot finality scheme design

 

The main challenge with SSF is that it seems to imply that every Ethereum staker needs to publish two messages every 12 seconds, which is a large burden on the blockchain. There are some clever ideas to alleviate this, including the recent Orbit SSF proposal (https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928). Even so, this scheme can significantly improve the user experience by speeding up "finality", but it does not shorten the time that users need to wait for 5-20 seconds.

 

Rollup Pre-Confirmation

 

For the past few years, Ethereum has been following a Rollup-centric roadmap, designing the Ethereum base layer (L1) around supporting data availability and other features. These features are used by L2 protocols such as Rollup (also Validiums and Plasmas), which can provide users with the same level of security as Ethereum, but their transaction scale is much larger than L1.

 

This has created a separation of concerns in the Ethereum ecosystem: Ethereum L1 can focus on censorship resistance, reliability, stability, and maintaining and improving certain core basic functions, while L2 can focus on user experience with different cultural and technical trade-offs. But if you go down this path, there is an inevitable problem: L2 focuses on serving users who want faster confirmations within 5-20 seconds.

 

So far, creating its own "decentralized sorting" network has become an unshirkable responsibility for L2. Maybe every few hundred milliseconds, a small group of validators will sign blocks, and they will stake their tokens in these blocks. Eventually, the block headers of these L2 blocks will be published on L1.

 

 

The L2 validator set can cheat: they can sign block B1 first, and then sign block B2 that conflicts with B1, and submit it to the chain before B1. But if they do this, they will face penalties and lose their deposits. In practice, we have seen centralized versions of this practice, but Rollups have been slow to develop decentralized ordering networks. You can say that requiring L2s to all do decentralized ordering is a unfair trade: it is equivalent to asking Rollups to do the same work as creating a brand new L1. For some reason, Ethereum Foundation researcher Justin Drake has been promoting a way to give all L2s (and L1s) access to a shared Ethereum preconfirmation mechanism: based preconfirmations.

 

Based preconfirmations

 

The preconfirmations-based approach assumes that Ethereum proposers will be highly sophisticated actors for MEV-related reasons (see here for my explanation of MEV, and also see proposals ). The preconfirmations-based approach exploits this complexity, incentivizing these sophisticated proposers to provide preconfirmation services.

 

 

The basic idea is to create a standardized protocol by which users can offer additional fees in exchange for immediate guarantees that their transactions will be included in the next block and a statement about the results of executing that transaction. If the proposer breaks the promise made to any user, they will be punished.

 

As mentioned above, the based preconfirmations mechanism provides guarantees for L1 transactions. If the Rollup is "Based Rollup" (Note: Based Rollup was proposed by Justin Drake in March 2023 and is a Rollup whose ordering is completely completed by L1), then all L2 blocks are L1 transactions, so the same mechanism can be used to provide preconfirmations for any L2.

 

What do we actually see?

 

Assume that we achieve single-slot finality. We use techniques like Orbit to reduce the number of validators signing each slot, so that we can also reduce the minimum stake amount of 32 ETH, which is a two-pronged approach. As a result, the slot time may gradually increase to 16 seconds. We then use Rollup preconfirmations or Based preconfirmations to provide users with faster guarantees. What do we get now? An epoch-and-slot architecture.

 

 

The “they’re the same diagram” meme has been overused, so I’ll just throw together an old diagram I drew a few years ago along with the L2 pre-confirmation diagram to describe Gasper’s slot-and-epoch architecture, and I hope I’ve made it clear.

 

There’s a deep philosophical reason why people will inevitably use epoch-and-slot architectures: reaching approximate consensus on something inherently takes less time than reaching maximal “economic finality” consensus on something.

 

A simple reason is the number of nodes. While the old progressive decentralization/finality time/overhead tradeoff looks much milder now thanks to super-optimized BLS aggregation and ZK-STARKs in the near future, the following points are still fundamentally true:

 

“Approximate consensus” requires only a small number of nodes, while economic finality requires a significant fraction of all nodes.

 

 

 

· Once the number of nodes exceeds a certain size, you need to spend more time collecting signatures.

 

In current Ethereum, the 12-second slot is divided into three sub-slots for (i) block publication and distribution, (ii) attestation, and (iii) attestation aggregation. With a much smaller number of attesters, we can reduce this 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 also rely on a specialized subset of nodes to reach approximate agreement (and still use the full validator set for finality), we can reasonably get this down to about 2 seconds.

 

So I think (i) the slot-and-epoch architecture is clearly correct, but (ii) not all slot-and-epoch architectures are created equal, and we need to explore the design space more fully. In particular, schemes that are not as tightly intertwined as Gasper are worth exploring.

 

What should L2 do?

 

In my opinion, there are currently three reasonable strategies that L2 can adopt:

 

· Be "based" both technically and spiritually. In other words, L2 is a better channel for delivering the technical properties of Ethereum's base layer and its value (high decentralization, censorship resistance, etc.). In the simplest form, you can think of these Rollups as "branded shards", but they can also be more ambitious, and they have conducted a lot of experiments on new virtual machine designs and other technical improvements.

 

· Become a "server with blockchain scaffolding", and use it to its fullest. If you start with a server, and then add (i) STARK validity proofs to ensure that the server follows the rules, (ii) guaranteed rights for users to exit or force transactions, and potentially (iii) freedom of collective choice, either through coordinated mass exits or the ability to vote to change the sorter, then you have gained a lot of the benefits of on-chain while retaining most of the efficiency of the server.

 

· The compromise: a fast blockchain with 100s of nodes that relies on Ethereum for additional interoperability and security. This is the de facto current roadmap for many L2 projects.

 

For some applications (such as ENS, keystores, and some payment scenarios), a 12 second block time is sufficient. For applications that need shorter confirmation times, the only solution is a slot-and-epoch architecture. In all three cases, “epoch” is Ethereum’s SSF (perhaps we could redefine the acronym to mean something other than “single slot”, e.g., it could be “Secure Speedy Finality”). But in each of the three cases above, “slot” is different: · Ethereum’s native slot-and-epoch architecture · Server pre-confirmation · Committee pre-confirmation

 

A key question is, how good can we make something in category (1)? In particular, if it gets really good, then category (3) seems to make little sense. Category (2) will always exist, because anything “based” doesn’t work with off-chain data L2, such as Plasma and Validium. But if Ethereum’s native slot-and-epoch architecture can be shortened to 1 second “slot” (i.e., pre-confirmation) time, then the space for category (3) becomes much smaller.

 

Today, we are still far from having final answers to these questions. There is still considerable uncertainty about the answer to this key question: How complex will block proposers become? Designs like Orbit SSF are very novel, so the design space of slot-and-epoch schemes similar to Orbit SSF needs more exploration. The more options we have, the better we can do for users on L1 and L2, and we can also simplify the work of L2 developers.