You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
### **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)
0 commit comments