Flashbots researchers have voiced support for EIP-8198, an Ethereum proposal designed to introduce variable slot timing and create a pathway toward faster block production. The proposal would replace Ethereum’s fixed 12-second slot assumption with runtime-configurable timing, allowing developers to reduce slot duration progressively as network constraints are better understood.
Authored by Carl Beekhuizen, the EIP-8198 “Quick Slots” specification proposes first removing hardcoded timing assumptions across Ethereum clients. The infrastructure-first approach is intended to make future slot-time changes easier to implement, rather than requiring extensive client refactoring each time developers want to test a shorter interval.
Quick Slots Takes a Phased Approach
Flashbots researcher Burak Öz has backed the proposal as a framework for gradually reducing slot times while identifying technical bottlenecks along the way. The proposal deliberately avoids treating a specific slot duration as the primary objective, instead prioritizing the infrastructure needed to adjust timing safely as performance data improves.
Its first phase would update functions such as compute_time_at_slot, background scheduling and fork-transition logic so that timing derives from dynamic configuration. Removing the assumption that every slot lasts exactly 12 seconds would give Ethereum clients greater flexibility around future timing changes.
The second phase focuses on characterizing consensus-layer performance through dedicated devnets and benchmarks. Areas requiring evaluation include blob propagation, attestation aggregation and other processes that must complete within each slot. Shorter slots leave less time for blocks and consensus messages to propagate, making network reliability a critical constraint on how aggressively timing can be reduced.
A third phase would progressively remove unused timing headroom based on those tests. EIP-8198 currently uses eight seconds as a reasonable initial placeholder, but the specification allows that target to change. The final slot duration would depend on empirical performance rather than being fixed in advance.
Faster Slots Face Decentralization Trade-Offs
Reducing slot times could improve Ethereum’s responsiveness by allowing transactions to land more quickly and shortening waits for applications that depend on new blocks. The proposal is aimed at improving user experience without simply increasing throughput by forcing more work into each block.
Researchers are also considering the decentralization implications. Shorter timing windows can favor validators with stronger connectivity or advantageous geographic positioning because they have less time to receive, validate and propagate information. Any slot reduction therefore has to balance lower latency against the ability of geographically and technically diverse validators to remain competitive.
Discussion around the proposal has also explored using a SLOT_SCHEDULE that maps different epochs to configured slot durations. Such a structure could make future timing adjustments more systematic, reducing the need to introduce new hardcoded timing tables whenever Ethereum developers want to modify slot length.
EIP-8198 remains a draft and would require further testing before any deployment decision. Quick Slots should therefore be viewed as infrastructure for safely exploring faster Ethereum block times, not as confirmation that eight-second slots are coming to mainnet.