Written by: Vitalik Buterin, Co-founder of Ethereum
Compiled by: Luffy, Foresight News
An essential feature of a good blockchain user experience is fast transaction confirmation time. 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 user 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 time.
Overview of existing ideas and technologies
Single slot finality
Ethereum's Gasper consensus now uses a slot and epoch architecture. Every 12 seconds (the length of a single slot), a subset of validators will issue a vote on the latest block of the blockchain, and all validators have the opportunity to vote once within 32 slots (6.4 minutes, one 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, with many interactions between the per-slot voting mechanism and the per-epoch finality mechanism; and (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 solution design diagram
The main challenge with SSF is that it seems to require each Ethereum staker to publish two messages every 12 seconds, which is a significant burden on the blockchain. There are some neat ideas to mitigate 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 solution can significantly improve the user experience by speeding up "finality", but it does not shorten the time users need to wait 5-20 seconds.
Rollup Pre-Confirmation
Over 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 size is much larger than L1.
This creates a separation of concerns in the Ethereum ecosystem: Ethereum L1 can focus on censorship resistance, reliability, stability, and maintaining and improving certain core infrastructure features, while L2 can focus on user experience through different cultural and technical trade-offs. But if you go down this path, an inevitable problem will arise: L2 focuses on serving users who want faster confirmations within 5-20 seconds.
So far, it has become the responsibility of L2 to create its own "decentralized sorting" network. Maybe every few hundred milliseconds, a small number 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, 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 deposit. In practice, we have seen centralized versions of this practice, but Rollups have been slow to develop decentralized ordering networks. You could say that requiring L2s to all do decentralized ordering is a unfair trade: it's 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, see also the proposal). 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 an immediate guarantee that their transaction 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?
Suppose 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 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 have 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 is a deep philosophical reason why people inevitably use epoch-and-slot architectures: reaching approximate consensus on something takes inherently less time than reaching maximal “economic finality” consensus on something.
One simple reason is the number of nodes. While the old progressive decentralization/finality time/overhead tradeoff looks more benign now thanks to hyper-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 portion of all nodes.
Once the number of nodes exceeds a certain size, it will take more time to collect signatures.
In current Ethereum, the 12 second slot is divided into three sub-slots for (i) block publishing 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.
Therefore, I think that (i) the slot-and-epoch architecture is clearly correct, but (ii) not all slot-and-epoch architectures are equal, and we need to explore the design space more fully. In particular, schemes that are not as tightly interwoven as Gasper are worth exploring.
What should L2 do?
In my opinion, there are currently three reasonable strategies that L2 can adopt:
Whether it is technical or spiritual, it must be "based". That is to say, 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 take advantage of it. 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, whether through coordinated mass exits or the ability to vote to change the sorter, then you have gained a lot of the benefits of being on-chain while retaining much of the efficiency of a server.
The tradeoff: 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 require shorter confirmation times, the only solution is the slot-and-epoch architecture. In all three cases, "epoch" is Ethereum's SSF (perhaps we can redefine the acronym to mean something other than "single slot", for example, it could be "Secure Speedy Finality"). But in the above three cases, "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 critical 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.
