This EIP introduces new forward-compatibility requirements for implementations of the devp2p Wire Protocol, the RLPx Discovery Protocol and the RLPx TCP Transport Protocol. Clients which implement EIP-8 behave according to Postel's Law:
Be conservative in what you do, be liberal in what you accept from others.
Implementations of the devp2p Wire Protocol should ignore the version number of hello packets. When sending the hello packet, the version element should be set to the highest devp2p version supported. Implementations should also ignore any additional list elements at the end of the hello packet.
Similarly, implementations of the RLPx Discovery Protocol should not validate the version number of the ping packet, ignore any additional list elements in any packet, and ignore any data after the first RLP value in any packet. Discovery packets with unknown packet type should be discarded silently. The maximum size of any discovery packet is still 1280 bytes.
Finally, implementations of the RLPx TCP Transport protocol should accept a new
encoding for the encrypted key establishment handshake packets. If an EIP-8 style RLPx
auth-packet is received, the corresponding ack-packet should be sent using the rules
below.
Decoding the RLP data in auth-body and ack-body should ignore mismatches of auth-vsn
and ack-vsn, any additional list elements and any trailing data after the list. During
the transitioning period (i.e. until the old format has been retired), implementations
should pad auth-body with at least 100 bytes of junk data. Adding a random amount in
range [100, 300] is recommended to vary the size of the packet.
Changes to the devp2p protocols are hard to deploy because clients running an older version will refuse communication if the version number or structure of the hello (discovery ping, RLPx handshake) packet does not match local expectations.
Introducing forward-compatibility requirements as part of the Homestead consensus upgrade will ensure that all client software in use on the Ethereum network can cope with future network protocol upgrades (as long as backwards-compatibility is maintained).
The proposed changes address forward compatibility by applying Postel's Law (also known as the Robustness Principle) throughout the protocol stack. The merit and applicability of this approach has been studied repeatedly since its original application in RFC 761. For a recent perspective, see "The Robustness Principle Reconsidered" (Eric Allman, 2011).
All clients currently contain statements such as the following:
These checks make it impossible to change the version or structure of the hello packet. Dropping them enables switching to a newer protocol version: Clients implementing a newer version simply send a packet with higher version and possibly additional list elements.
The relaxation of discovery packet decoding rules largely codifies current practice. Most existing implementations do not care about the number of list elements (an exception being go-ethereum) and do not reject nodes with mismatching version. This behaviour is not guaranteed by the spec, though.
If adopted, the change makes it possible to deploy protocol changes in a similar manner to the devp2p hello change: simply bump the version and send additional information. Older clients will ignore the additional elements and can continue to operate even when the majority of the network has moved on to a newer protocol.
Discussions of the RLPx v5 changes (chunked packets, change to key derivation) have faltered in part because the v4 handshake encoding provides only one in-band way to add a version number: shortening the random portion of the nonce. Even if the RLPx v5 handshake proposal were accepted, future upgrades are hard because the handshake packet is a fixed size ECIES ciphertext with known layout.
I propose the following changes to the handshake packets:
These changes make it possible to upgrade the RLPx TCP transport protocol in the same manner as described for the other protocols, i.e. by adding list elements and bumping the version. Since this is the first change to the RLPx handshake packet, we can seize the opportunity to remove all currently unused fields.
Additional data is permitted (and in fact required) after the RLP list because the handshake packet needs to grow in order to be distinguishable from the old format. Clients can employ logic such as the following pseudocode to handle both formats simultaneously.
The plain text size prefix is perhaps the most controversial aspect of this document. It has been argued that the prefix aids adversaries that seek to filter and identify RLPx connections on the network level.
This is largely a question of how much effort the adversary is willing to expense. If the recommendation to randomise the lengths is followed, pure pattern-based packet recognition is unlikely to succeed.
This EIP is backwards-compatible, all valid version 4 packets are still accepted.
go-ethereum libweb3core pydevp2p
devp2p hello packet advertising version 22 and containing a few additional list elements:
Implementations should accept the following encoded discovery packets as valid. The packets are signed using the secp256k1 node key
ping packet with version 4, additional list elements:
ping packet with version 555, additional list elements and additional random data:
pong packet with additional list elements and additional random data:
findnode packet with additional list elements and additional random data:
neighbours packet with additional list elements and additional random data:
In these test vectors, node A initiates a connection with node B. The values contained in all packets are given below:
(Auth₁) RLPx v4 format (sent from A to B):
(Auth₂) EIP-8 format with version 4 and no additional list elements (sent from A to B):
(Auth₃) EIP-8 format with version 56 and 3 additional list elements (sent from A to B):
(Ack₁) RLPx v4 format (sent from B to A):
(Ack₂) EIP-8 format with version 4 and no additional list elements (sent from B to A):
(Ack₃) EIP-8 format with version 57 and 3 additional list elements (sent from B to A):
Node B derives the connection secrets for (Auth₂, Ack₂) as follows:
Running B's ingress-mac keccak state on the string "foo" yields the hash
Copyright and related rights waived via CC0.