EIP.tools

EIP.tools

⚠️ DraftStandards Track: Networking

EIP-7719: P2P History Network

Instead of each node storing a full copy of historical history divide the responsibility amongst the nodes on the network.

Authors
Created2024-06-05
Discussion Linkhttps://ethereum-magicians.org/t/eip-7719-p2p-history-network/20231
Requires

Markdown

https://raw.githubusercontent.com/ethereum/EIPs/64...
Pull Request#8630PR closed (unmerged)

EIP-GPT summary

Contents
AbstractMotivationSpecificationRationaleSecurity ConsiderationsCopyright

Abstract

An overlay network over Discv5 based off the Portal Wire Protocol EIP-7718. 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.

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 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 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 and related rights waived via CC0.

EIP.tools

EIP.tools

Search, read, and map Ethereum improvement proposals, ERCs, RIPs, and CAIPs from one focused interface.

Farcaster
by @apoorveth