Description
Currently a supported eth network protocol version is sent from sentry to the node.
The sentry being an RLPx proxy knows very little about eth (only the status exchange is covered).
It uses the version only to forward it to connected peers.
Versions 66 to 68 are 100% compatible from the sentry's point of view.
The task of working with eth specifics lies on the node, and there it could be possible to work with supported compatible peers simultaneously (e.g. 66 and 67).
Therefore it makes more sense that the supported eth versions are passed from the node to sentry instead.
There would be an administration benefit that when an eth version changes, multiple sentries don't need to be reconfigured, because currently they require a fixed --p2p.protocol option.
Proposal
Add a new method:
message HandshakeRequest {
repeated Protocol eth_versions = 1;
}
rpc Handshake2(HandshakeRequest) returns (google.protobuf.Empty);The node would accept a new option:
--p2p.eth.versions x,y,z
For example: --p2p.eth.versions 66,67
means that the node should start with support for both versions, and issue a Handshake2 call to sentry with them.
The sentry that receives it should then forward all versions (both eth/66 and eth/67) to connected peers in RLPx Hello.