EIP-7782 Reducing block latency (Reduce Block Latency)
No call decision · Consensus & staking · EIP status Draft · created 2024-10-05
Cuts Ethereum's slot time from 12 seconds to 6 seconds. Block and blob sizes stay the same and only the interval between blocks is halved, which halves the confirmation latency and the time to finality.
Why it is needed
Today Ethereum produces one block every 12 seconds. Users wait that long on average to get a transaction confirmed, and the epoch used for finality takes 384 seconds. Raising throughput by enlarging blocks has limits. The source notes that it is hard to grow blocks beyond 10 MiB without major changes to the network. Instead, keeping block size the same and producing blocks twice as often gives the same effect, while bandwidth use is spread evenly instead of arriving in bursts. More frequent blocks mean prices on decentralized exchanges (DEXs) update more often, which reduces liquidity providers' losses (LVR), and rollups tied to L1 block time also get faster.
What changes
Today
- One block is produced every 12 seconds, and transaction confirmation happens at that interval
- The epoch is 384 seconds (32 slots × 12 seconds), so finality is that slow
- Large blocks propagate all at once every 12 seconds, so bandwidth use spikes
- Attestation deadlines are set at the points that divide the slot into thirds (1/3, 2/3)
After EIP-7782
- A block is produced every 6 seconds, so confirmation latency is halved
- The epoch shrinks to 192 seconds (32 slots × 6 seconds), so Casper-FFG finality becomes faster
- Halving the gas and blob limits per block keeps throughput per second and block size the same while spreading bandwidth evenly
- The attestation schedule is readjusted in milliseconds (0ms proposal, 3000ms attestation, 4500ms aggregation)
Who is affected
- Users: Transactions are confirmed in about 6 seconds. The perceived speed improves significantly.
- L2s and based rollups: L1 settlement latency is halved. Based rollups, whose sequencing is tied to L1 block time, become faster directly.
- Client teams and validators: Slot scheduling, gas limit voting, and attestation deadline handling must all be updated for the new timing. Message frequency doubles, which also increases the network processing load.
- DEX liquidity providers: More frequent blocks reduce LVR and tighten spreads, which improves trading conditions.
In depth
Introducing the SLOT_SCHEDULE setting
Adds a new SLOT_SCHEDULE parameter to the consensus layer configuration. It specifies SECONDS_PER_SLOT per epoch, and the original example is a schedule that changes from 12 seconds at EPOCH 348618 to 6 seconds at EPOCH 355368. However, the source states that these values and the schedule are purely examples and the actual values are outside the scope of this specification. In other words, the transition point is set separately.
Reinterpreting the gas limit and halving it
The first execution block after the fork must set half of the previous gas limit. From this fork, every gas limit setting is reinterpreted as "gas per 12 seconds". For example, if a user setting or the default gas limit vote was 36,000,000, the client must vote for 18,000,000. All values are rounded down to integers. The per-block limit is halved but blocks come twice as often, so total processing capacity per hour stays the same.
Halving the blob target and limit
The per-block blob target and limit are also halved and rounded down to the nearest integer. By the same logic as the gas limit, this keeps overall blob throughput while not enlarging any single block and spreading bandwidth use evenly over time. The source explains that it keeps the existing p2p network maximum to avoid sudden load spikes and lets nodes without ample bandwidth keep participating.
Millisecond readjustment of attestation deadlines
All clients must change so that deadlines can be set in milliseconds. Currently the slot is divided into thirds: the block is proposed at 0, and attestations and aggregates are sent at the 1/3 and 2/3 points. This EIP replaces that with a new uneven schedule: block proposal at 0ms, attestation at 3000ms, and aggregation at 4500ms. The window after the proposal is the longest, so that block propagation, which takes the longest, has enough time.
Security considerations: message frequency and fork choice
With shorter slots, the network must handle more frequent messages without congestion. As mitigations, the source recommends network optimization and the use of efficient client software. For consensus integrity, it says it must be confirmed that the fork choice rule stays robust against reorg attacks and that the finality mechanism works correctly under the new timing. It states that there are no backward compatibility issues.
Status: Draft, no fork decision
This EIP is in Draft status, so the specification may still change. Key values such as the transition epoch are only examples and are not finalized. On the call record, it was discussed in AMA #14 on 08.29 but no decision was made, and there is no decision yet to include it in any specific fork. The source's requires lists EIP-7623 and EIP-7778 as prerequisites.