--- eip: 7719 title: P2P History Network description: Instead of each node storing a full copy of historical history divide the responsibility amongst the nodes on the network. author: Kolby ML (@KolbyML) discussions-to: https://ethereum-magicians.org/t/eip-7719-p2p-history-network/20231 status: Draft type: Standards Track category: Networking created: 2024-06-05 requires: 7643, 7718 --- ## Abstract An overlay network over Discv5 based off the _Portal Wire Protocol_ [EIP-7718](./eip-7718.md). This overlay network is called the Portal History Network and serves headers, block bodies, and receipts. Look ups on the network are done via block hash. All data has strong validity conditions, but proving path will differ based certain fork transitions. ## Motivation Historical blocks and receipts currently occupy more than 700GB of disk space (and growing!). Therefore, to validate the chain, users must typically have a 2TB disk. With lightweight sync strategies based on the PoS weak subjectivity assumption, which was possible after the merge, storing all the block history was no longer required to sync and played a centralizing force increasing the storage requirements and sync times to participate in the Ethereum Network. Instead of each Ethereum node storing a full copy of the block history, imagine that this burden was divided amongst all nodes enabling each node to store a fraction of the blocks, but having access to all historical blocks as a collective lowering the cost for everybody, while maintaining the current JSON-RPC interfaces. ## Specification Specification of the _Portal History Network_ are on [ethereum/portal-network-specs](https://github.com/ethereum/portal-network-specs/blob/bc7f4d0d930f79a610f54ab3160bd3ee93e92cae/history/history-network.md). ## Rationale Block history look up's are optimized for contacting the least amount of nodes and to obtain single pieces of history. Models for doing bulk downloads of block history are being researched, for the majority of post [EIP-4444](./eip-4444.md) optimizing for faster single block look up times is considered more important. Validation for block headers will use different proving paths depending which block range they are from. For pre-merge headers the embedded accumulator of [EIP-7643](./eip-7643.md) is used for header validation, for merge till capella _HistoricalRootsBlockProof_ the frozen accumulator in the beacon state is used, but can be embedded in the client as well. For Capella onwards minus 8192 blocks _HistoricalSummariesBlockProof_ the accumulator in the beacon state is used. The latest 8192 blocks are already contained by the EL and CL node which can be used to validate that the headers are valid. TBD ## Security Considerations Needs discussion. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).