{
  "id": 8,
  "title": "EIP-8: devp2p Forward Compatibility Requirements for Homestead",
  "status": "Final",
  "description": "",
  "laymanDescription": "",
  "author": "Felix Lange <felix@ethdev.com>",
  "type": "Standards Track",
  "category": "Networking",
  "createdDate": "2015-12-18",
  "requires": [],
  "source": {
    "official": "ethereum/EIPs",
    "forkcastEnrichment": true
  },
  "forkRelationships": [],
  "tradeoffs": null,
  "abstract": "",
  "bodyPreview": "### Abstract 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. ### Specification 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. ```text auth-vsn = 4 auth-size = size of enc-auth-body, encoded as a big-endian 16-bit integer auth-body = rlp.list(sig, initiator-pubk, initiator-nonce, auth-vsn) enc-auth-body = ecies.encrypt(recipient-pubk, auth-body, auth-size) auth-packet = auth-size || enc-auth-body ack-vsn = 4 ack-size = size of enc-ack-body, encoded as a big-endian 16-bit integer ack-body = rlp.list(recipient-ephemeral-pubk, recipient-nonce, ack-vsn) enc-ack-body = ecies.encrypt(initiator-pubk, ack-body, ack-size) ack-packet = ack-size || enc-ack-body where X || Y denotes concatenation of X and Y. X[:N] denotes an N-byte prefix of X. rlp.list(X, Y, Z, ...) denotes recursive encoding of [X, Y, Z, ...] as an RLP list. sha3(MESSAGE) is the Keccak256 hash function as used by Ethereum. ecies.encrypt(PUBKEY, MESSAGE, AUTHDATA) is the asymmetric authenticated encryption function as used by RLPx. AUTHDATA is authenticated data which is not part of the resulting ciphertext, but written to HMAC-256 before generating the message tag. ``` ### Motivation 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). ### Rationale 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)](https://queue.acm.org/detail.cfm?id=1999945). #### Changes to the devp2p Wire Protocol All clients currently contain statements such as the following: ```python # pydevp2p/p2p_protocol.py if data['version'] != proto.version: log.debug('incompatible network protocols', peer=proto.peer, expected=proto.version, received=data['version']) return proto.send_disconnect(reason=reasons.incompatible_p2p_version) ``` 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. * If such a packet is received by a node with lower version, it will blindly assume that the remote end is backwards-compatible and respond with the old handshake. * If the packet is received by a node with equal version, new features of the protocol can be used. * If the packet is received by a node with higher version, it can enable backwards-compatibility logic or drop the connection. #### Changes to the RLPx Discovery Protocol 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. #### Changes to the RLPx TCP Handshake 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: * Adding the length of the ciphertext as a plaintext header. * Encoding the body of the handshake as RLP. * Adding a version number to both packets in place of the token flag (un"
}