Current contract
The eth wire protocol does not require every peer to store every historical
body and receipt. A peer advertises the range that it actually serves.
Headers remain part of the full chain-sync surface from genesis. Bodies and
receipts can start at a later earliest block.
Retention and serving
A client keeps enough data to honor its advertised range. If pruning changes
the lower bound, it updates the range through BlockRangeUpdate.
The wire contract does not define the storage representation. A client can use an archive database, freezer files, snapshots, or another checked store.
Synchronization effects
Initial sync can combine peers with different ranges. It fetches headers from any suitable peer and assigns body and receipt requests only to peers that advertise the needed blocks.
Portal or another archive source can supply data that no connected eth peer
retains. That retrieval path does not change eth message validity.
Failure handling
- Do not request known out-of-range bodies from a peer.
- Update the advertised range after pruning.
- Do not claim a range that local storage cannot serve.
- Distinguish one unavailable response from a repeated false range claim.
Design rationale
Explicit ranges let archive and pruned nodes share the same eth protocol.
They also let sync schedulers direct old-history work to the correct peers.
History
EIP-7642 defined the eth/69 history-range advertisement after clients gained permission to expire old bodies and receipts.