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.
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.
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.
SECONDS_PER_SLOT) from 12 seconds to 8 seconds in the Ethereum consensus specifications.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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.