Alert Source Discuss
⚠️ Draft Standards Track: Core

EIP-7782: Reduce Block Latency

Reduce Ethereum's slot time from 12s to 6s to decrease latency by 50%, distribute bandwidth usage, and improve UX.

Authors Ben Adams (@benaadams), Dankrad Feist (@dankrad)
Created 2024-10-05
Discussion Link https://ethereum-magicians.org/t/eip-7782-reduce-block-latency/21271
Requires EIP-7623, EIP-7778

Abstract

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.

Motivation

  • Protocol Carrying Capacity It is impractical to increase block sizes beyond 10MiB without substaintial networking changes. However it is practical to decrease slot time to achieve similar effect while also improving the UX at same time.
  • Enhanced UX: Confirmations now arrive in ~6 s instead of 12 s.
  • Faster Finality: Epochs shrink from 384 s (32 × 12 s) to 192 s (32 × 6 s), accelerating Casper‑FFG finality.
  • L2 Interoperability: Layer 2 rollups see half the settlement delay on L1, improving throughput and reducing reorg risk period.
  • Based rollups: Based rollup sequencing is tied to L1 block time so faster blocks directly improves based rollups.
  • DEX Economics: More frequent blocks decrease LVR (Loss Versus Rebalancing), which improves the economics for liquidity providers. More liquidity means lower spreads (reduced slippage).
  • Bandwidth Smoothing: Doubling slot rate distributes bandwidth evenly without increasing peak block size; nodes with modest capacity remain supported.

Specification

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.

Adjustment to gas and blob limits

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.

Attestation deadlines

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:

  • Block proposal at 0 ms
  • Attestations at 3000 ms
  • Aggregates at 4500 ms

Rationale

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.

Backwards Compatibility

No backwards compatibility concerns.

Security Considerations

  • 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.
    • Finality Gadgets: Confirm that finality mechanisms function correctly under new timing conditions.

Copyright and related rights waived via CC0 1.0 Universal.

Citation

Please cite this document as:

Ben Adams (@benaadams), Dankrad Feist (@dankrad), "EIP-7782: Reduce Block Latency [DRAFT]," Ethereum Improvement Proposals, no. 7782, October 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7782.