EIP-8383 Shorter consensus layer block retention period (Reduce CL Block Retention Window)
Hegota Considered for Inclusion · Networking & nodes · EIP status Draft · created 2026-08-17
Reduces the minimum retention period for old beacon blocks that consensus layer nodes must serve to peers from 33,024 epochs to 8,192 epochs (about 36 days). It changes a single configuration value without a hard fork.
Why it is needed
Consensus layer (CL) nodes store recently signed beacon blocks and serve them when other nodes request them. A newly joining node starts from a trusted checkpoint and syncs to the current head, but after that it must still backfill old blocks for the period set by the rules. This period is currently 33,024 epochs, so even if the checkpoint is only a few hours old, the node must download almost five months of blocks. This number is the weak subjectivity period computed for the worst case (MAX_SAFETY_DECAY = 100). Actual checkpoint sync, however, uses SAFETY_DECAY = 10, and under the current mainnet configuration that bound is 3,532 epochs. In effect, nodes keep a much longer history than the real safety policy requires. If a checkpoint is older than the policy allows, a newer checkpoint is needed anyway, so holding older blocks beyond that point does not make anything safer. Shortening the retention period reduces sync bandwidth, disk usage, disk writes, backfill time, and the upload bandwidth of peers.
What changes
Today
- Nodes must keep signed beacon blocks for the last 33,024 epochs and serve them to peers.
- A node that has finished checkpoint sync must also backfill this entire period, so even starting from a checkpoint a few hours old it needs almost five months of blocks.
- This period is the weak subjectivity period computed for the worst case (MAX_SAFETY_DECAY = 100), and it is much longer than the 3,532 epochs given by the SAFETY_DECAY = 10 bound that the actual policy uses.
After EIP-8383
- The minimum retention period is reduced to 8,192 epochs (about 36.4 days).
- The backfill range becomes shorter, which reduces sync bandwidth, disk usage and writes, backfill time, and upload bandwidth.
- The retention period becomes a fixed configuration value, so clients know the pruning and serving boundaries in advance.
- No hard fork is required, and clients that want to keep more history may do so.
Who is affected
- Node operators: The amount of old blocks that must be downloaded when bringing up a new node drops sharply, easing the disk and bandwidth burden.
- Consensus client teams: Changes the MIN_EPOCHS_FOR_BLOCK_REQUESTS value and the compute_min_epochs_for_block_requests() implementation, and handles the mixed-deployment period in which old clients request older blocks.
- Execution client teams: Some consensus clients rebuild old execution payloads from the execution layer (EL), so the number of blocks the consensus layer keeps can set a lower bound on the number of payloads an execution client that expires history needs to keep.
- Peers: A request for blocks older than 8,192 epochs may receive a ResourceUnavailable response, and the requester must not penalize the other node for it.
In depth
Changed value: MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192
The mainnet block serving configuration sets MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192. The function compute_min_epochs_for_block_requests() is changed to return Uint64(MIN_EPOCHS_FOR_BLOCK_REQUESTS) as is, instead of computing the value from the live consensus state. The existing block serving requirement and backfill requirement that use this function both apply unchanged with the new value. Converted to time, 8,192 epochs × 32 slots × 12 seconds = 3,145,728 seconds, about 36.4 days. The old value of 33,024 epochs corresponds to almost five months.
Why 8,192 epochs
The old value of 33,024 epochs is a worst-case calculation of the weak subjectivity period, using MAX_SAFETY_DECAY = 100. However, the checkpoint sync policy uses SAFETY_DECAY = 10, and under the current mainnet churn parameters the weak subjectivity bound is 3,532 epochs. The protocol does not require any particular multiple of this bound. The smallest power of two greater than 3,532 is 4,096, but this EIP chose the next power of two, 8,192. Because this is the first reduction from 33,024, the value is set conservatively.
Why a fixed configuration value instead of live state
The weak subjectivity period depends on the consensus state. A fixed configuration value, by contrast, lets clients predict their pruning, backfill and serving boundaries. The networking requirement no longer has to be derived from the live consensus state each time. Also, if a checkpoint is older than the policy allows, that node needs a newer checkpoint anyway, so holding more blocks after the old checkpoint does not make it safe. This is the basis for shortening the retention period to be close to the weak subjectivity bound.
Backfill burden after checkpoint sync
A checkpoint sync node starts from a trusted finalized state and syncs forward to reach the head. However, to meet the block serving requirement it must also backfill the range set by MIN_EPOCHS_FOR_BLOCK_REQUESTS. Forward sync establishes the current consensus view, while backfill is mainly done to serve history to peers. So even when starting from a checkpoint a few hours old, the node ends up downloading almost five months of blocks. Shrinking the window reduces sync bandwidth, disk usage, disk writes, backfill time and peer upload bandwidth. Also, some consensus clients use the execution layer to reconstruct old execution payloads, so the number of blocks the consensus layer keeps can serve as a lower bound on the number of payloads an execution layer that expires history must keep.
Recommendation for long periods of non-finality
One reason for keeping several months of old blocks is to prepare for situations where the chain goes without finality for a long time. The source points out that this amounts to overloading the SAFETY_DECAY constant for two purposes, the weak subjectivity period and the blocks used to serve history. So during long periods of non-finality, it recommends that both execution clients and consensus clients keep all unfinalized blocks. This decouples finality from the weak subjectivity period, so the block retention period no longer needs to be set long as a safeguard against non-finality.
Compatibility, mixed deployment and test cases
This EIP does not require a hard fork. Clients may continue to keep longer history. However, the serving expectations between peers change, so during a period when the new and old values run side by side, old clients may request blocks between 8,192 and 33,024 epochs old. The source notes that some nodes already do not serve history (clients that turn it off by default) and therefore expects no impact on the network. Client tests MAY cover the following with MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192. When current_epoch = 500_000, signed blocks from 491_808 through 500_000 MUST be served, a request for epoch 491_807 MAY return ResourceUnavailable, and the requester MUST NOT penalize the peer for this response.
Security: weak subjectivity invariant
This EIP does not change SAFETY_DECAY or the checkpoint freshness calculation. It only narrows the window in which blocks for bootstrapping are guaranteed. For safety, there is a condition that 8,192 epochs must be larger than the maximum weak subjectivity period under the current mainnet policy. Consensus spec tests MUST verify that, under the configured mainnet policy, the maximum weak subjectivity period is smaller than MIN_EPOCHS_FOR_BLOCK_REQUESTS, and they must use the current weak subjectivity calculation to do so. If another protocol change alters the weak subjectivity bound, this invariant must be confirmed to hold before activation.
Source status and fork discussion
The source status is Draft, so the value and the detailed specification may still change. In the core developer call records, EIP-8383 was accepted as a Hegota Proposed for Inclusion (PFI) at 08.20 ACDC #185. At 09.21 ACDT #97, the CL block serving window and BAL retention period for Glamsterdam were not decided on that call and were deferred to asynchronous discussion and ACDE. Three options were raised: keep 33,024 epochs, reduce to about 14,299, or reduce to 8,192 (EIP-8383, a Hegota candidate and so out of scope), and it was agreed not to block the testnet launch. At 09.24 ACDE #246 and 10.01 ACDC #188 there was only discussion and no decision. At 10.29 ACDC #190, EIP-8383 was moved to Hegota Considered for Inclusion (CFI).