Reduce Ethereum's slot time from 12 s to 6 s, halving on‑chain latency and epoch duration. This doubles slot throughput while keeping block and blob sizes unchanged, smoothing bandwidth usage. The change delivers better user experience, faster Layer 2 interaction, tighter DEX pricing, reduced MEV, and quicker finality.
On the consensus layer, a new parameter is added to the configuration:
SLOT_SCHEDULE:
- EPOCH: 348618
SECONDS_PER_SLOT: 12
- EPOCH: 355368
SECONDS_PER_SLOT: 6
The parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.
The first execution block after the fork needs to specify half the previous gas limit. With this fork, all gas limit settings are reinterpreted as "gas per 12 seconds". I.e., if the user configuration or otherwise default gas limit vote was 36,000,000, the client should now vote for 18,000,000. All values are rounded down to integers.
The blob target and limit are also halved, rounded down to the nearest integer.
All clients need to be reconfigured so that deadlines can be configured in milliseconds for finer granularity. Currently the slot is split into three equal intervals, with proposal happening at time 0, and attestations and aggregations being sent at one thirds and two thirds of the slot time. We change this to a new uneven schedule, in order to give sufficient time for block propagation, which takes the most time:
This proposal balances user experience, economic efficiency, and network stability:
UX & Finality: Halving slot time directly reduces confirmation latency and halves epoch duration, delivering faster feedback to users and speeding up Casper-FFG finality.
Economic Efficiency: Increased block frequency tightens DEX price spreads, lowers slippage, and diminishes arbitrage and MEV opportunities, improving on-chain trading conditions.
L2 & Based Rollups Synergy: Layer 2 rollups, especially based rollups, benefit from reduced L1 settlement delays, enhancing throughput and user-perceived performance in rollup ecosystems.
Network Stability: Maintaining existing p2p network maximum smooths bandwidth usage over time, avoiding peak-load spikes and preserving accessibility for nodes with diverse bandwidth capacities.
No backwards compatibility concerns.
Network Congestion:
Increased Message Frequency: The network must handle more frequent messages without congestion.
Mitigation: Implement network optimizations and encourage the use of efficient client software.
Consensus Integrity:
Fork Choice Stability: Ensure that the fork choice rule remains robust against potential reorganization attacks.
Copyright and related rights waived via CC0 1.0 Universal.