主页EIPs
EIPsEIP-7542
EIP-7542

eth/69 - available-blocks-extended protocol

Adds more info in the handshake about available block range and adds message types to request block ranges and the send them
DraftStandards Track: Networking
创建时间: 2023-10-21
关联 EIP: EIP-5793
Ahmad Bitar (@smartprogrammer93) <smartprogrammer@windowslive.com>
社区讨论原文链接编辑
1 分钟了解

相关视频
欢迎补充好内容
去提交
正文

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.

Motivation

In a first stage of EIP-4444, some nodes will still need to serve the historical data of the chain and others might be interested in starting to prune it. Currently, nodes need to connect to peers and request specific blocks to determine if a peer has the requested data. This can be inefficient, leading to unnecessary data requests and wasting both bandwidth and time. Consequently, this change empowers nodes that still want to retrieve historical data from the network to do so efficiently.

As a bonus, This change enhances the efficiency of synchronization by allowing a node to determine if a peer, potentially still in the process of syncing, has the necessary blocks available, thereby avoiding unnecessary block requests and potential empty responses.

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], 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.

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.

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 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.

Security Considerations

This change is not a standardization of not storing and serving historical blocks before the implementation of alternative historical blocks storage solutions.

Copyright and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
聚集 EIP 贡献者, 扩展以太坊
资源
GitHub
支持社区