EIP-8383: Reduce CL Block Retention Window

Reduces the required beacon block retention window to 8192 epochs

Abstract

This EIP reduces the minimum consensus-layer (CL) block-serving window from 33,024 epochs to 8,192 epochs.

MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192

The existing window comes from a worst-case weak-subjectivity calculation, using MAX_SAFETY_DECAY = 100.

We use SAFETY_DECAY = 10 for checkpoint sync, so with the current mainnet churn parameters, this policy gives a weak-subjectivity bound of 3,532 epochs.

Note: The proposed 8,192-epoch window amounts to roughly 36 days.

Motivation

Consensus clients retain recent signed beacon blocks. Peers request these blocks through BeaconBlocksByRange and BeaconBlocksByRoot.

Checkpoint sync uses this history; a node gets a trusted weak-subjectivity checkpoint and syncs from that checkpoint to the current head.

The current block-serving window includes more history than the configured weak-subjectivity policy requires because it uses maximal safety decay instead of the configured value of 10.

If a checkpoint is older than the weak-subjectivity policy permits, the node needs a newer checkpoint anyway, so blocks after the old checkpoint do not make it safe.

Some CL clients use the execution layer (EL) to reconstruct historical execution payloads, so the number of historical blocks that the CL chooses can serve as a lower bound for the number of payloads a history-expiring EL should store.

Backfill after checkpoint sync

A checkpoint-synced node starts from a trusted finalized state and uses forward sync to reach the head.

To meet the block-serving requirement, the node must also backfill the range defined by MIN_EPOCHS_FOR_BLOCK_REQUESTS.

So forward sync establishes the current consensus view, and backfill primarily lets the node serve history to peers. This means that even a checkpoint that is only hours old can require almost five months of block downloads.

A smaller window reduces synchronization bandwidth, disk use, disk writes, backfill time, and peer upload bandwidth.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Set the mainnet block-serving configuration to:

MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192

Replace compute_min_epochs_for_block_requests() with:

def compute_min_epochs_for_block_requests() -> Uint64:
    """
    Return the minimum epoch range over which a node must serve blocks.
    """
    return Uint64(MIN_EPOCHS_FOR_BLOCK_REQUESTS)

All existing block-serving and backfill requirements that use compute_min_epochs_for_block_requests() apply with the new value.

Rationale

Why 8,192 epochs

The protocol does not require a specific multiplier over the current weak-subjectivity bound. The value 4,096 is the smallest power of two above the current 3,532-epoch bound. This EIP selects the next power of two, 8,192, as a conservative initial reduction from 33,024 epochs.

8_192 epochs * 32 slots/epoch * 12 seconds/slot
= 3_145_728 seconds
≈ 36.4 days

Configured retention window

The weak-subjectivity period depends on the consensus state, whereas a fixed configuration value gives clients predictable pruning, backfill, and serving boundaries.

Clients therefore do not need to derive a networking requirement from live consensus state.

Long periods of non-finality

One motivation for storing months-old blocks is the case of long periods of non-finality. This would imply that the SAFETY_DECAY constant is being overloaded for both weak-subjectivity periods and blocks for serving history. We recommend that during long periods of non-finality, clients (EL and CL) store all unfinalized blocks to decouple the relationship between finality and the weak subjectivity period.

Backwards Compatibility

This EIP does not require a hard fork.

Clients can choose to continue to retain more history.

The change does modify peer-serving expectations; during a mixed deployment, an older client can request blocks that are between 8,192 and 33,024 epochs old. Since some nodes already do not serve history (their clients disable it by default), this should have no effect on the network.

Test Cases

Consensus-specification tests MUST assert that the maximum weak-subjectivity period under the configured mainnet policy is less than MIN_EPOCHS_FOR_BLOCK_REQUESTS. The tests MUST use the current weak-subjectivity calculation.

Client tests MAY cover these cases with MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192:

1. At current_epoch = 500_000, clients MUST serve signed blocks seen from epoch 491_808 through epoch 500_000.
2. A request for epoch 491_807 MAY return ResourceUnavailable. The requesting peer MUST NOT penalize the serving peer for this response.

Security Considerations

Weak-subjectivity invariant

This EIP does not change SAFETY_DECAY or the checkpoint-freshness calculation. It narrows the guaranteed window for bootstrap availability.

For security, we require 8,192 epochs to exceed the maximum weak-subjectivity period under the configured mainnet policy.

If a protocol change modifies the weak-subjectivity bound, make sure that this invariant holds before activation.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Kevaundray Wedderburn (@kevaundray), "EIP-8383: Reduce CL Block Retention Window [DRAFT]," Ethereum Improvement Proposals, no. 8383, August 2026. Available: https://eips.ethereum.org/EIPS/eip-8383.