### **Motivation** A new version of the eth protocol has been released (eth/69) and some clients are supporting both eth/68 and eth/69 at the same time. We need a way of being able to encode/decode the msg from both versions of the protocol. Also, we need a way to remove easily the old version when it becomes deprecated. The new version includes changes in the status and receipts messages and a new message RangeBlockUpdate. ### **Description** A new file structure was created to accommodate the new implementation: crates/networking/p2p/rlpx/eth/ crates/networking/p2p/rlpx/eth/eth68/ -> (status.rs and receipt.rs) crates/networking/p2p/rlpx/eth/eth69/ -> (status.rs and receipt.rs) In the new eth/69 protocol the messages status and receipts have been changed, so a new intermediate structure was created to address this. The encode for each version is decided by the type of the inner struct, but the decode is not that straight forward as we don't know what version of msg we received. For the status msg was easier, as we received the eth version inside the msg we can decide which version of the protocol we are using. For the receipt msg, the only difference is the bloom field. A new function `has_bloom` has been implemented to detect when a msg have the bloom field to process it as a eth/68. The newer eth/69 receipts msg won't have the bloom field (it can be calculated from the logs). Also, as the new structure is a proxy to the different version of the structure some new getters were needed. The new msg BlockRangeUpdate was introduced with eth/69. This message includes the earliest block available, the latest block available and the its hash. This messages is been send once every epoch (aprox 6 mins). In some places, the `receipts` need to be encoded using the _bloom_ field to validate the receipt_root of a block header. The function encode_inner_with_bloom was used for these cases. ### **Future improvements** - We're not using the received `BlockRangeUpdate` message, we can use this information to discard peers quickly. - The function `has_bloom` probably could be improved or at least not use private decode functions. - As mentioned before, this implementation is made with the assumption that eth/68 is going to be deprecated in the future. - We are currently not running the latest version of hive that includes the Closes #2805 & #2785 References: [EIP-7642](https://eips.ethereum.org/EIPS/eip-7642#rationale) [geth implementation](ethereum/go-ethereum#29158) [eth/69](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)

[EIP-7642] Implement eth/69 #2785

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions