EIP-4444 cuts the history retention window from 33,024 to 14,299 epochs
Serguey Asael Shinder1 min readThe Ethereum Improvement Proposals repository has merged a change to EIP-4444, the proposal that lets execution clients stop serving old chain history. The edit lowers the parameter HISTORY_PRUNE_EPOCHS from 33,024 to 14,299 epochs.
Under EIP-4444, clients must stop serving historical block headers, bodies and receipts older than that window on the peer-to-peer layer, and they may prune that data locally. The proposal states that forcing clients to stop serving old data is deliberate: it pushes anyone who needs full history to other sources instead of relying on some clients serving it optionally, which the authors say would degrade quality over time. It also expects the change to reduce bandwidth use on the network.
The reasoning for the number itself did not change. The proposal still sets the window to match the consensus layer's block retention window, because some consensus clients rely on their paired execution client to store execution payloads, and those clients must be able to serve complete beacon blocks for as long as the consensus network requires them to be available. That retention window, the text says, is derived from the maximum weak subjectivity period, so it remains long enough for checkpoint sync while bounding execution clients' disk use. The merged commit updates the abstract, the parameter table and the rationale section to the new figure.
What it means
The change is a number in a specification, but it sets how much history every node is expected to hand out to peers. A shorter window means less disk and less bandwidth for node operators, and more reliance on archive providers, portal networks and data files for anyone who needs older blocks. Because the value is tied to the consensus layer's window rather than chosen independently, it will move again whenever that window does.