---
eip: 8383
title: Reduce CL Block Retention Window
description: Reduces the required beacon block retention window to 8192 epochs
author: Kevaundray Wedderburn (@kevaundray)
discussions-to: https://ethereum-magicians.org/t/eip-8383-reduce-cl-block-retention-window/29449
status: Draft
type: Standards Track
category: Networking
created: 2026-08-17
---

## Abstract

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

```text
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](https://www.rfc-editor.org/rfc/rfc2119) and
[RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).

Set the mainnet block-serving configuration to:

```text
MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192
```

Replace `compute_min_epochs_for_block_requests()` with:

```python
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.

```text
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](../LICENSE.md).