Alert Source Discuss
⚠️ Draft Standards Track: Core

EIP-7782: Reduce Slot Time for Lower Peak Bandwidth

Reduce Ethereum's slot time from 12s to 8s to increase throughput by ~33%, distribute bandwidth usage, and improve rollup latency.

Authors Ben Adams (@benaadams)
Created 2024-10-05
Discussion Link https://ethereum-magicians.org/t/eip-7782-reduce-slot-time-for-lower-peak-bandwidth/21271
Requires EIP-7623, EIP-7778

Table of Contents

Propose reducing Ethereum’s slot time from 12 seconds to 8 seconds to increase transaction throughput by one-third. This approach distributes bandwidth usage over time, lowering peak bandwidth requirements without increasing individual block or blob counts. It requires EIP-7623 and EIP-7778 to ensure network stability and efficiency with the higher block rate.

Abstract

This EIP suggests decreasing the slot time in Ethereum’s Proof-of-Stake (PoS) consensus mechanism from 12 seconds to 8 seconds. The reduction increases the number of slots per unit time, boosting the network’s transaction processing capacity by approximately 33%.

Unlike directly increasing the gas limit or blob limit; which would raise peak bandwidth demands, this proposal distributes the increased bandwidth evenly over time, preventing spikes in network load and preserving node accessibility for participants with varying bandwidth capacities.

This change requires the implementation of EIP-7623 to adjust calldata costs accordingly and EIP-7778 to remove gas smuggling via refunds to maintain network performance.

Motivation

Distributing Bandwidth and Reducing Peak Usage

  • Avoiding Peak Bandwidth Increases: Increasing the gas limit from 30 million to 40 million or the blob limit from 6 to 8 directly raises the size of individual blocks or blobs, leading to higher peak bandwidth requirements that can strain network resources and disadvantage nodes with limited bandwidth.

  • Distributing Bandwidth Over Time: Reducing the slot time increases the frequency of blocks, spreading bandwidth usage more evenly and avoiding sudden peaks in network load.

  • Throughput Enhancement: A reduction from 12 seconds to 8 seconds per slot equates to a one-third decrease in time, resulting in a one-third increase in slots per unit time. This mirrors the throughput gains from increasing the gas limit or blob limit by one-third.

Complementing EIP-7623

  • EIP-7623 Alignment: EIP-7623 increases calldata costs to reduce maximum block size and variance. Implementing it alongside the slot time reduction ensures that blocks remain manageable in size and that the network can handle the increased block frequency without compromising security or efficiency.

Specification

Slot Time Reduction

  • Change the Slot Time Parameter: Modify the slot time (SECONDS_PER_SLOT) from 12 seconds to 8 seconds in the Ethereum consensus specifications.

Adjustments to Timing Parameters

  • Epoch Length:

    • Slots per Epoch: Maintain the current number of slots per epoch (32 slots).
    • Epoch Duration: With a 8-second slot time, each epoch would last 256 seconds (4.267 minutes) if the number of slots per epoch remains unchanged.

  • Timeouts and Deadlines:

    • Attestation Deadlines: Adjust attestation aggregation and broadcast deadlines to align with the new slot duration.
    • Proposer Deadlines: Update block proposal timing to ensure proposers have sufficient time to prepare and broadcast blocks.

  • Synchronization Protocols:

    • Networking Parameters: Update networking protocols to account for increased message frequency and ensure timely block and attestation propagation.

Validator Operations

  • Increased Frequency:

    • Block Proposals: Validators will propose blocks more frequently due to shorter slots.
    • Attestations: Validators will need to perform attestation duties at shorter intervals.

  • Resource Management:

    • Client Performance: Optimize validator clients to handle increased operational demands without excessive resource consumption.
    • Bandwidth Usage: Ensure that validators with lower bandwidth capacities can handle the increased frequency of messages.

Rationale

Based Rollup Latency

  • Reducing the slot time from 12 seconds to 8 seconds significantly improves the latency for based-rollup Layer 2 solutions as they are directly effected by L1 latency.

Throughput Increase Without Raising Peak Bandwidth

  • Maintaining Individual Block Sizes: By keeping block and blob sizes unchanged, we avoid increasing peak bandwidth requirements.

  • Distributing Workload: More frequent blocks distribute the network’s workload over time, leading to smoother operation and reduced risk of congestion.

Complementing EIP-7623

  • Managing Block Sizes: EIP-7623 increases calldata costs for DA-heavy transactions, reducing the maximum possible block size. This is essential when reducing slot time to prevent oversized blocks from causing propagation delays.

  • Network Efficiency: Together, the proposals ensure that the network can handle increased throughput without compromising on security or decentralization.

Validator Capability

  • Operational Feasibility: Validators are expected to handle the increased frequency, as the computational workload per block remains consistent. There is enough performance in the network for ELs to process at higher rates (as the L2s run the same EL clients at far higher rates). There is also enough time for consenus to be reached as there is enough network slack to play timing games.

  • Resource Optimization: Client software can be optimized to manage resources effectively under the new conditions.

Alternative to Increasing Block Size or Blob Count

  • Avoiding Drawbacks: Larger blocks or more blobs can lead to longer verification times and propagation delays, potentially centralizing the network. Reducing slot time circumvents these issues.

Backwards Compatibility

  • Network Upgrade Required: This change is backward-incompatible and necessitates a hard fork.

  • Client Updates: All Ethereum clients must update to accommodate the new slot time and related protocol adjustments.

  • Smart Contracts and DApps:

    • Block Timing: Applications relying on block timestamps or assuming a 12-second slot time may need adjustments.
    • Event Timing: Event-driven applications should be tested to ensure proper functionality with increased block frequency.

Test Cases

  • Simulation of Network Conditions:

    • Latency Scenarios: Test the network under various latency conditions to assess block propagation success rates.
    • Bandwidth Constraints: Evaluate performance with nodes of varying bandwidth capacities.

  • Validator Performance Metrics:

    • Resource Utilization: Monitor CPU, memory, and network usage of validators.
    • Duty Compliance: Ensure validators can meet attestation and block proposal deadlines.

  • Consensus Stability Tests:

    • Fork Scenarios: Simulate potential fork conditions to detect any consensus vulnerabilities.
    • Finality Assurance: Verify that the network reaches finality consistently.

Network Propagation Considerations

  • Latency and Bandwidth:

    • Propagation Speed: Assess and optimize the network’s ability to propagate blocks and attestations within the reduced slot time.
    • Gossip Protocol Enhancements: Implement improvements to the gossip network to facilitate faster dissemination of consensus messages.

  • Optimizations:

    • Block and Attestation Compression: Use efficient serialization and compression techniques to reduce message sizes.
    • Peer Selection Strategies: Optimize peer selection to prioritize connections that enhance propagation speed.

Consensus Adjustments

  • Fork Choice Rule:

    • LMD GHOST Adjustments: Verify that the Latest Message Driven Greediest Heaviest Observed SubTree (LMD GHOST) fork choice algorithm operates correctly with increased block frequency.

  • Finality Mechanism:

    • Casper FFG Stability: Ensure that the Casper Friendly Finality Gadget (FFG) finality mechanism remains stable and reliable under the new timing conditions.

Implementation

  • Client Modifications:

    • Update Slot Time: Change the SECONDS_PER_SLOT constant to 8 seconds.
    • Adjust Timing Parameters: Modify all time-dependent logic, including epochs, timeouts, and scheduling.

  • Protocol Specification Updates:

    • Consensus Specs: Update the Ethereum consensus specifications to reflect the new slot duration and any related parameter changes.
    • Networking Protocols: Adjust networking specifications to handle increased message frequency.

  • Deployment Plan:

    • Testnets: Implement the changes on test networks (e.g. Sepolia, et al) for extensive testing.
    • Monitoring: Use monitoring tools to observe network performance and identify issues.

  • Community Coordination:

    • Communication: Inform all stakeholders, including node operators, validators, exchanges, and DApp developers.
    • Support and Resources: Provide documentation and support for updating client software and applications.

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), "EIP-7782: Reduce Slot Time for Lower Peak Bandwidth [DRAFT]," Ethereum Improvement Proposals, no. 7782, October 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7782.