This EIP reduces the minimum consensus-layer (CL) block-serving window from 33,024 epochs to 8,192 epochs.
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.
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.
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.
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:
Replace compute_min_epochs_for_block_requests() with:
All existing block-serving and backfill requirements that use
compute_min_epochs_for_block_requests() apply with the new value.
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.
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.
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.
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.
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:
current_epoch = 500_000, clients MUST serve signed blocks seen from
epoch 491_808 through epoch 500_000.491_807 MAY return ResourceUnavailable.
The requesting peer MUST NOT penalize the serving peer for this response.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 and related rights waived via CC0.