Vitalik's New Paper: How to Shorten Ethereum's Transaction Confirmation Time?
TechFlow Selected TechFlow Selected
Vitalik's New Paper: How to Shorten Ethereum's Transaction Confirmation Time?
For applications requiring shorter confirmation times, the only solution is the slot-and-epoch architecture.
Navigating Web3 tides with focused insightsAuthor: Vitalik Buterin, Co-founder of Ethereum
Translation: Luffy, Foresight News
A key requirement for good blockchain user experience is fast transaction confirmation. Today’s Ethereum has made significant progress compared to five years ago, thanks to EIP-1559 and the transition to Proof-of-Stake (PoS), which provides stable block times. Transactions sent on Layer 1 (L1) can now be reliably confirmed within 5–20 seconds—approaching the usability of credit card payments. However, further improvements in user experience are still needed, as some applications require transaction latencies in the hundreds of milliseconds or even less. This article outlines practical approaches to accelerate Ethereum transaction confirmations.
Overview of Existing Ideas and Technologies
Single Slot Finality
Current Ethereum Gasper consensus uses a slot-and-epoch structure. Every 12 seconds (the duration of one slot), a subset of validators publishes votes on the latest block. Over 32 slots (6.4 minutes—one epoch consists of 32 slots), all validators get one chance to vote. These votes are then interpreted as messages in a PBFT-like consensus algorithm, providing strong economic finality guarantees after two epochs (12.8 minutes)—this is known as finality.
Over the past few years, dissatisfaction with this approach has grown. The main reasons are: (i) it's complex, with many interaction bugs between per-slot voting and per-epoch finality mechanisms; and (ii) 12.8 minutes is too long—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 key difference from Tendermint is that we retain the “inactivity leak” mechanism, allowing the blockchain to continue and recover even if more than 1/3 of validators go offline.
Design diagram of single slot finality
The main challenge with SSF is that it appears to require every staker to publish two messages every 12 seconds, which would place a heavy burden on the network. Clever ideas exist to mitigate this, including the recent Orbit SSF proposal (https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928). Nevertheless, while such schemes significantly improve UX by accelerating "finality," they do not reduce the 5–20 second user wait time.
Rollup Preconfirmations
In recent years, Ethereum has followed a rollup-centric roadmap, designing its base layer (L1) to support data availability and other functions used by Layer 2 protocols like Rollups, Validiums, and Plasmas. These L2s offer users security comparable to Ethereum but at much higher transaction throughput.
This creates a separation of concerns: Ethereum L1 can focus on censorship resistance, reliability, stability, and core infrastructure improvements, while L2s prioritize user experience through different technical and cultural trade-offs. If you follow this path, an inevitable question arises: Can L2s serve users who want faster confirmations—within 5–20 seconds?
So far, building their own "decentralized sequencing" networks has become an unavoidable responsibility for L2s. Typically, every few hundred milliseconds, a small set of validators signs a block, staking their tokens behind it. Eventually, these L2 block headers are published on L1.
The L2 validator set could cheat: they could sign block B1, then sign a conflicting block B2, and submit B2 before B1 on-chain. But if they do so, they risk losing their stake. In practice, we’ve already seen centralized versions of this. However, progress toward decentralized sequencing among rollups has been slow. Requiring every L2 to build decentralized sequencing may be an unfair burden—it's akin to asking rollups to do the same work as launching a new L1. For these reasons, Ethereum Foundation researcher Justin Drake has promoted an alternative: enabling all L2s (and even L1) to access a shared Ethereum preconfirmation mechanism called based preconfirmations.
Based Preconfirmations
The based preconfirmations approach assumes that Ethereum proposers will become highly sophisticated due to MEV-related incentives (see here for my explanation of MEV, and also see this proposal). Based preconfirmations leverage this complexity by incentivizing advanced proposers to provide preconfirmation services.
The core idea is to create a standardized protocol where users pay extra fees in exchange for a guaranteed inclusion of their transaction in the next block, along with a statement about the expected outcome of execution. If a proposer violates any such commitment, they face penalties.
As described, the based preconfirmations mechanism provides guarantees for L1 transactions. If a rollup is a "Based Rollup" (a concept proposed by Justin Drake in March 2023, where sequencing is fully handled by L1), then all L2 blocks are effectively L1 transactions and can use the same mechanism to provide preconfirmations for any L2.
What Are We Actually Seeing?
Suppose we implement single slot finality using techniques like Orbit to reduce the number of validators signing each slot. This could allow us to simultaneously lower the minimum 32 ETH staking requirement—a double win. As a result, slot times might gradually increase to 16 seconds. Then, we use rollup preconfirmations or based preconfirmations to give users faster guarantees. What do we end up with? A slot-and-epoch architecture.
The meme “they’re the same diagram” has been overused, so I’ll simply place an old chart I drew years ago side-by-side with the L2 preconfirmation diagram to illustrate Gasper’s slot-and-epoch structure—I hope this makes the point clear.
There’s a deep philosophical reason why people inevitably converge on slot-and-epoch architectures: reaching approximate agreement on something takes fundamentally less time than achieving maximum “economic finality.”
A simple reason is node count. While older assumptions about the progressive decentralization / finality time / overhead tradeoff have softened due to optimized BLS aggregation and upcoming ZK-STARKs, the following remains fundamentally true:
-
“Approximate agreement” requires only a small number of nodes, whereas economic finality requires a substantial portion of all nodes.
-
Once the number of nodes exceeds a certain scale, collecting signatures takes more time.
In current Ethereum, the 12-second slot is divided into three sub-slots for (i) block proposal and dissemination, (ii) attestations, and (iii) attestation aggregation. If there were far fewer attesters, we could reduce this to two sub-slots and achieve 8-second slots. An even more important practical factor is node “quality.” If we can rely on a specialized subset of nodes to reach approximate agreement (while still using the full validator set for finality), we could reasonably shorten this to around 2 seconds.
Therefore, I believe (i) the slot-and-epoch architecture is clearly correct, but (ii) not all slot-and-epoch architectures are equal—we need to explore the design space more thoroughly. In particular, designs that are less tightly coupled than Gasper deserve attention.
What Should L2s Do?
In my view, L2s currently have three reasonable strategies:
-
Go fully “based,” both technically and philosophically. That is, L2s act as superior conduits for Ethereum’s base-layer properties and values—high decentralization, censorship resistance, etc. At its simplest, you can think of these rollups as “brand shards,” but they can be more ambitious, experimenting heavily with new VM designs and other technical improvements.
-
Become a “server with blockchain scaffolding,” and make full use of it. Start with a server, then add (i) STARK validity proofs to ensure rule compliance, (ii) guaranteed user exit or forced transaction rights, and possibly (iii) collective governance—either via coordinated mass exits or voting to change the sequencer. This gives you many on-chain benefits while retaining most of the efficiency of a server.
-
A middle ground: a fast blockchain with 100 nodes relying on Ethereum for additional interoperability and security. This is the de facto roadmap for many L2 projects today.
For some applications (e.g., ENS, keystores, and certain payment scenarios), a 12-second block time is sufficient. For those requiring shorter confirmation times, the only viable solution is a slot-and-epoch architecture. In all three cases, the “epoch” component would be Ethereum’s SSF (perhaps we should redefine this acronym beyond “single slot”—for example, “Secure Speedy Finality”). But in the above cases, the “slot” differs:
-
Ethereum-native slot-and-epoch architecture
-
Server-based preconfirmations
-
Committee-based preconfirmations
A key question is: how good can we make category (1)? In particular, if it becomes very good, category (3) seems largely redundant. Category (2) will always exist because anything “based” does not apply to off-chain-data L2s like Plasma and Validium. But if Ethereum-native slot-and-epoch architecture can achieve 1-second “slot” (i.e., preconfirmation) times, the space for category (3) shrinks dramatically.
Today, we are far from definitive answers to these questions. How complex will block proposers become? This critical question remains highly uncertain. Designs like Orbit SSF are very new, so the design space for Orbit-style slot-and-epoch schemes needs further exploration. The more options we have, the better we can serve users on both L1 and L2—and the easier we can make life for L2 developers.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@VitalikButerin
