This EIP proposes the creation of a new subprotocol, etha, enabling Ethereum nodes to communicate available block spans via a bitmask. Each bit represents a 106_496-block span within each 1_064_960 block range of chain history. Nodes use this bitmask to signal stored spans and commit to storing future spans as they are created. This allows peers to make informed decisions about data availability without first connecting and querying for it. The bitmask repeats every 1_064_960 blocks for straightforward reasoning about data availability probabilities.
The etha subprotocol has the same functionality to serve historical data using message types copied from the eth protocol, enabling efficient data retrieval.
With EIP-4444, nodes may prune historical data while others continue serving it. Determining data availability by connecting and requesting blocks is inefficient consuming unnecessary bandwidth. This EIP addresses this inefficiency by enabling nodes to shard chain history into 106_496 block segments and signal availability via a bitmask.
By introducing a separate subprotocol, etha, nodes can exchange this information seamlessly and retain the ability to serve historical data without impacting existing eth protocol versions.
etha.etha subprotocol as follows:
[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid, blockBitmask]blockBitmask is a 10-bit bitmask, with each bit representing a 106_496-block range per 1_064_960 blocks of history.The etha subprotocol MUST include support for the following messages from the eth/69 protocol to facilitate historical data serving:
GetBlockBodies.GetReceipts.The semantics and payload structures for these messages are identical to their counterparts in the eth/69 protocol, ensuring compatibility for historical data serving.
blockBitmask to on upon startup and backfill the corresponding 106_496-block span.blockBitmask repeats every 1_064_960 blocks, enabling efficient representation of historical data locality across epochs.Upon connection using etha, nodes exchange the handshake message with the blockBitmask. This single handshake eliminates the need for additional message types.
Alternatively, the blockBitmask could be derived or encoded into the Ethereum Node Record (ENR), enabling nodes to advertise block spans without a handshake. As an example, the blockBitmask can be derived from the secp256k1 field of the ENR. However, this method lacks the authentication and reliability of the handshake approach. Additionally, there is not guarantee that the node you are connecting to supports the etha subprotocol.
The bitmask approach provides a flexible means to represent and retain block data while committing to future spans. This mechanism aligns with the pruning proposed in EIP-4444, while ensuring that historical and future data spans remain available across the network.
A similar bitlist approach is already used in the Consensus Layer for attestation subnets, making it a familiar and efficient method for representing data spans. Additionally, committing to future spans ensures better predictability and stability for data locality.
The etha subprotocol separates this functionality from eth ensuring nodes dont hammer other nodes with requests on historical ranges that they do not posses on the eth protocol.
The range sizes of 106,496 and 1,064,960 blocks were chosen because they are multiples of Era1’s maximum block range of 8,192, which allows for straightforward storage and representation using Era1 files.
The etha subprotocol is independent of the eth protocol. This EIP does not affect the consensus engine or require a hard fork.
There are some considerations:
This document is CC0-licensed; rights are waived through CC0.