Update EIP-7542: Update to eth/70

Merged by EIP-Bot.

EIPS/eip-7542.md

@@ -1,20 +1,20 @@
 ---
 eip: 7542
-title: eth/69 - available-blocks-extended protocol
+title: eth/70 - available-blocks-extended protocol
 description: Adds more info in the handshake about available block range and adds message types to request block ranges and the send them
 author: Ahmad Bitar (@smartprogrammer93) <smartprogrammer@windowslive.com>
-discussions-to: https://ethereum-magicians.org/t/eip-eth-69-available-blocks-extended-protocol-handshake/16188
+discussions-to: https://ethereum-magicians.org/t/eip-eth-70-available-blocks-extended-protocol-handshake/16188
 status: Draft
 type: Standards Track
 category: Networking
 created: 2023-10-21
-requires: 5793
+requires: 7642
 ---
 ## Abstract
 
 The purpose of this EIP is to introduce a method that allows an Ethereum node to communicate the range of blocks it has available. By knowing the block range a node can serve, peers can make more informed decisions when choosing whom to request blocks from or whom to connect to, especially when looking for specific block ranges. This can lead to more efficient network behavior.
 
-This EIP proposes extending the Ethereum wire protocol (`eth`) handshake, introducing a new version, `eth/69`, which will contain information regarding the block range a node can serve. Furthermore, it extends the protocol with two new message types to share the updated block ranges when requested.
+This EIP proposes extending the Ethereum wire protocol (`eth`) handshake, introducing a new version, `eth/70`, which will contain information regarding the block range a node can serve. Furthermore, it extends the protocol with two new message types to share the updated block ranges when requested.
 
 ## Motivation
 
@@ -24,36 +24,36 @@ As a bonus, This change enhances the efficiency of synchronization by allowing a
 
 ## Specification
 
-- Advertise a new `eth` protocol capability (version) at `eth/69`.
-  - The old `eth/68` protocol should still be kept alive side-by-side, until `eth/69` is sufficiently adopted by implementors.
-- Modify the `Status (0x00)` message for `eth/69` to add an additional `blockRange` field right after the `forkid`:
-  - Current packet for `eth/64`: `[protocolVersion, networkId, td, bestHash, genesisHash, forkid]`
-  - New packet for `eth/69`: `[protocolVersion, networkId, td, bestHash, genesisHash, forkid, blockRange]`,
+- Advertise a new `eth` protocol capability (version) at `eth/70`.
+  - The old `eth/69` protocol should still be kept alive side-by-side, until `eth/70` is sufficiently adopted by implementors.
+- Modify the `Status (0x00)` message for `eth/70` to add an additional `blockRange` field right 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 blockRange]`,
   where `blockRange` is `[startBlock: uint64, endBlock: uint64]`.
 
 - Introduce two new message types:
   - `RequestBlockRange (0x0b)` - A message from a node to request the current block range of a peer.
   - `SendBlockRange (0x0c): [startBlock: uint64, endBlock: uint64]` - The response to `RequestBlockRange`, informing the requesting node of the current available block range of the peer.
 
-Upon connecting using `eth/69`, nodes should exchange the `Status` message. Afterwards, they can use the `RequestBlockRange` and `SendBlockRange` messages to keep informed about peer block range changes.
+Upon connecting using `eth/70`, nodes should exchange the `Status` message. Afterwards, they can use the `RequestBlockRange` and `SendBlockRange` messages to keep informed about peer block range changes.
 
 Nodes must retain connections regardless of a peer's available block range, with an exception, if a node's peer slots are full and it lacks connections to peers with the necessary block range, it may disconnect to seek such peers.
 
 ## Rationale
 
 Including the available block range in the `eth` handshake allows for immediate understanding of peer capabilities. This can lead to more efficient networking as nodes can prioritize connections based on the data they need.
-The new message types are introduced to allow nodes to reuqest updated available block range from other nodes since the range can change by the node syncing or pruning blocks.
-Maintaining connections with peers that dont have the desired range ensures network resilience, while the exception facilitates efficient block sync under full peer capacity.
+The new message types are introduced to allow nodes to request updated available block range from other nodes since the range can change by the node syncing or pruning blocks.
+Maintaining connections with peers that don't have the desired range ensures network resilience, while the exception facilitates efficient block sync under full peer capacity.
 
 ## Backwards Compatibility
 
-This EIP extends the `eth` protocol handshake in a backwards incompatible manner and proposes the introduction of a new version, `eth/69`. However, `devp2p` allows for multiple versions of the same wire protocol to run concurrently. Hence, nodes that have not been updated can continue using older versions like `eth/68` or `eth/67`.
+This EIP extends the `eth` protocol handshake in a backwards incompatible manner and proposes the introduction of a new version, `eth/70`. However, `devp2p` allows for multiple versions of the same wire protocol to run concurrently. Hence, nodes that have not been updated can continue using older versions like `eth/69`, `eth/68` or `eth/67`.
 
 This EIP doesn't affect the consensus engine and doesn't necessitate a hard fork.
 
 ## Test Cases
 
-Testing will involve ensuring that nodes can correctly communicate and understand the block range information during the handshake. Additionally, it will involve ensuring nodes can correcly request and share updated block range when requested.
+Testing will involve ensuring that nodes can correctly communicate and understand the block range information during the handshake. Additionally, it will involve ensuring nodes can correctly request and share updated block range when requested.
 
 ## Security Considerations