Update EIP-7801: Update eip-7801.md

Merged by EIP-Bot.

EIPS/eip-7801.md

@@ -1,9 +1,9 @@
 ---
 eip: 7801
-title: eth/70 - Sharded Blocks Protocol
-description: Replaces block range with a bitmask representing 100,000-block spans in the handshake, committing to future block ranges
+title: etha - Sharded Blocks Subprotocol
+description: Introduces the etha subprotocol for serving historical blocks data.
 author: Ahmad Bitar (@smartprogrammer93) <smartprogrammer@windowslive.com>, Giulio Rebuffo (@Giulio2002), Gary Schulte (@garyschulte) <garyschulte@gmail.com>
-discussions-to: https://ethereum-magicians.org/t/eip-7801-eth-70-sharded-blocks-protocol/21507
+discussions-to: https://ethereum-magicians.org/t/eip-7801-etha-sharded-blocks-subprotocol/21507
 status: Draft
 type: Standards Track
 category: Networking
@@ -13,51 +13,62 @@ requires: 7642
 
 ## Abstract
 
-This EIP introduces a method enabling an Ethereum node to communicate its available block spans via a bitmask, where each bit represents a 100_000-block span within each 1_000_000 block range of chain history. Nodes use this bitmask to signal which spans of historical data they store and commit to storing future spans as they are created. This enables peers to make informed decisions about data availability without first connecting and querying for availability. The bitmask repeats every 1 million blocks, making for a somewhat simple to reason about probability of data availability.
+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 100_000-block span within each 1_000_000 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 million blocks for straightforward reasoning about data availability probabilities.
 
-The proposal extends the Ethereum wire protocol (`eth`) with version `eth/70`, introducing a `blockBitmask` field in the handshake.
+The `etha` subprotocol has the same functionality to serve historical data using message types copied from the `eth` protocol, enabling efficient data retrieval.
 
 ## Motivation
 
-With [EIP-4444](./eip-4444.md), nodes may begin pruning historical data while others continue to serve it. The current approach of connecting and requesting specific blocks to determine data availability is inefficient, consuming unnecessary bandwidth. This EIP addresses this by sharding chain history into 100_000 block segments, and allows nodes to signal which shards they store via a bitmask.
+With [EIP-4444](./eip-4444.md), nodes may prune historical data while others continue serving it. Determining data availability by connecting and requesting blocks is inefficient consuming unnexessary bandwidth. This EIP addresses this inefficiency by enabling nodes to shard chain history into 100_000 block segments and signal availability via a bitmask.
 
-By using a bitmask in place of a range, nodes provide a snapshot of data locality and future storage commitments, supporting efficient data requests.
+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.
 
 ## Specification
 
-- Advertise a new `eth` protocol capability (version) at `eth/70`.
-  - The existing `eth/69` protocol will continue alongside `eth/70` until sufficient adoption.
-- Modify the `Status (0x00)` message for `eth/70` to add a `blockBitmask` field after the `forkid`:
-  - Current packet for `eth/69`: `[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid]`
-  - New packet for `eth/70`: `[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid, blockBitmask]`,
-  where `blockBitmask` is a 10-bit bitmask, with each bit representing a 100_000-block range per 1_000_000 blocks of history.  
+### Subprotocol Handshake
 
-- Define node behavior based on the bitmask as follows:
-  - **Bitmask Initialization**: Upon startup, nodes **MAY** set at least one bit in the `blockBitmask` to `on` and backfill that 100_000-block span to ensure data availability for that shard.
-  - **Shard Retention Probability**: Nodes **SHOULD** retain new block spans according to their bitmask, with participating nodes providing at least 10% of the chain history.
-  - **Additional Shard Retention Buffer**: Retained shard ranges should also include 1_000 blocks prior to and after the shard boundary.  This will prevent edge effects where a typical range request size of 200 blocks which crosses a 100k shard boundary cannot be satisfied by any single node.
-  - **Commitment to Future Ranges**: Participating nodes **MUST** retain 100_000 block spans which correspond to their advertised bitmask as blocks are added to the chain
-  - **Bitmask Space**: The 100_000 range `blockBitmask` repeats every 1 million blocks, enabling efficient representation of historical data locality across epochs.
+- Introduce a new subprotocol named `etha`.
+- Define the handshake message for the `etha` subprotocol as follows:
+  - Handshake packet: `[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid, blockBitmask]`
+  - `blockBitmask` is a 10-bit bitmask, with each bit representing a 100_000-block range per 1_000_000 blocks of history.
+  - the rest of the elements are as defined in eth/69
 
-Upon connecting using `eth/70`, nodes exchange the `Status` message, including the `blockBitmask`. This single handshake message, which includes the bitmask, eliminates the need for additional message types.
+### Supported Messages
 
-Nodes should maintain connections regardless of a peer’s bitmask state, except when peer slots are full. In this case, nodes may prioritize connections with peers that serve more relevant shards.
+The `etha` subprotocol **MUST** include support for the following messages from the `eth/69` protocol to facilitate historical data serving:
 
-If a node is interested in querying a specific block span, it can use the bitmask to determine which peers are more likely to have the data. If the peer they are connected to does not have the data, they can disconnect and connect to another peer, until they find what they have been looking for.
+- **GetBlockBodies (0x05):** Request block bodies.
+- **BlockBodies (0x06):** Response to `GetBlockBodies`.
+- **GetReceipts (0x0f):** Request receipts.
+- **Receipts (0x10):** Response to `GetReceipts`.
 
-### ENR variation
+The semantics and payload structures for these messages are identical to their counterparts in the `eth/69` protocol, ensuring compatibility for historical data serving.
 
-This EIP could be implemented without a new protocol version by adding a new field to the Ethereum Node Record (ENR) to advertise the bitmask. This would allow nodes to advertise their available block spans without requiring a handshake. However, this approach would not provide the same level of assurance as the handshake, as the ENR is not authenticated. Also, it would make the discovery process much simpler, as nodes would only need to check the ENR to determine if a peer has the data they need.
+### Node Behavior
+
+- **Bitmask Initialization**: Nodes **MAY** set at least one bit in the `blockBitmask` to `on` upon startup and backfill the corresponding 100_000-block span.
+- **Shard Retention Probability**: Nodes **MUST** retain new block spans according to their bitmask, aiming to cover at least 10% of chain history.
+- **Additional Shard Retention Buffer**: Nodes **SHOULD** retain 1_000 blocks before and after shard boundaries to accommodate edge cases.
+- **Commitment to Future Ranges**: Nodes **MUST** retain spans corresponding to their advertised bitmask as new blocks are added.
+- **Bitmask Space**: The 100_000 range `blockBitmask` repeats every 1 million 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.
+
+### ENR Extension
+
+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.
 
 ## Rationale
 
 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.
+
 ## Backwards Compatibility
 
-This EIP introduces `eth/70`, extending the handshake in a backward-incompatible manner. However, `devp2p` allows concurrent versions of the same protocol, so nodes can continue using older protocol versions (e.g., `eth/69`, `eth/68`, `eth/67`) if they lack support for `eth/70`.
+The `etha` subprotocol is independent of the `eth` protocol.
 
 This EIP does not affect the consensus engine or require a hard fork.