Ethereum co-founder Vitalik Buterin has proposed enhancing transaction speeds on the Ethereum network by shifting from the current epoch-and-slot mechanism to a single-slot finality system. In his blog post on June 30, titled “Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times,” Buterin explored how this change could potentially reduce layer-1 (L1) confirmation times from seconds to milliseconds.
Since the Ethereum Merge in 2022, which transitioned the network from proof-of-work to proof-of-stake, L1 transaction confirmations have been reduced to 5–20 seconds, competitive with credit card transactions. However, Buterin highlighted the need for further speed improvements, noting that some applications require latencies in the order of hundreds of milliseconds or less.
In his proposal, Buterin suggests modifying the architecture of slots and epochs, key components of Ethereum 2.0’s Gasper consensus mechanism. Slots are 12-second intervals during which an ETH validator proposes a block, with 32 slots forming an epoch, requiring 32 validator committees to validate a block.
Buterin indicated that the Ethereum Foundation has grown dissatisfied with the current slot-by-slot and epoch-by-epoch finality process, citing its complexity and bugs. The goal is to simplify finality, currently taking 12.8 minutes, by implementing single-slot finality (SSF), a mechanism similar to Tendermint’s consensus, while retaining the ‘inactivity leak’ mechanism to ensure chain continuity if more than one-third of validators go offline.
However, SSF presents challenges, such as the need for every staker to publish two messages every 12 seconds, potentially increasing network congestion. Buterin mentioned solutions like the recent Orbit SSF proposal to address these issues. Despite these advancements, he acknowledged that Ethereum has not yet resolved all challenges related to speeding up transactions. Buterin emphasized the importance of exploring various design options to improve user experience on both L1 and L2 networks and simplify development for L2 developers.
