EIP-868 Node discovery v4 ENR extension
Final · Networking & nodes · EIP status Final · created 2018-02-02
Adds two packets to node discovery protocol v4, the protocol Ethereum nodes use to find each other, so a node can directly request and receive another node's latest node record (ENR).
Why it is needed
To join the network, an Ethereum node must first find other nodes, using the node discovery protocol. EIP-778 defined a format called the node record (ENR, Ethereum Node Record), which holds a node's connection information and is self-signed by that node, but the existing discovery v4 protocol had no way to ask a specific node for the latest version of that record. Bridging today's discovery network with future discovery networks, and implementing alternative ways of distributing records such as via DNS, requires a means of fetching the most current record. This EIP solves the problem without creating a new protocol, by adding request and response packets on top of the discovery protocol already in use.
What changes
Today
- Discovery v4 has no packet for requesting another node's node record (ENR)
- There is no way to know whether a peer's record has been updated
- There is no lookup mechanism to support distributing records through other channels such as DNS
After EIP-868
- ENRRequest and ENRResponse packets fetch the latest record directly
- The ping and pong packets carry the record's sequence number, revealing immediately whether a peer's record has changed
- Given only a public key, a node's current record can be obtained via a Kademlia lookup followed by ENRRequest
Who is affected
- Client teams: Discovery v4 implementations must support two new packet types (ENRRequest, ENRResponse) and add an enr-seq field to ping and pong.
- Node operators: Nodes can directly announce their latest connection information to the network via a signed record.
- Discovery infrastructure developers: Serves as the foundation for implementations that distribute ENRs through other channels such as DNS.
In depth
Adding an enr-seq field to ping and pong packets
The data of the existing Ping packet (0x01) is extended to [version, from, to, expiration, enr-seq], and the data of the Pong packet (0x02) is extended to [to, ping-hash, expiration, enr-seq]. enr-seq is the current sequence number of the sending node's own record. The meaning of the remaining fields is unchanged. Because the sequence number now rides along with routine ping/pong exchanges, a node can tell whether a peer's record is newer than the version it knows without any extra packets.
The ENRRequest packet (0x05) and defense against amplification attacks
The packet data for ENRRequest is just [expiration]. A node receiving this packet must respond with an ENRResponse containing the current version of its record. To prevent amplification attacks, a node sending ENRRequest must, like with FindNode, have recently responded to a ping packet. The expiration field is a UNIX timestamp and is handled the same way as in existing packets, meaning no response is sent if it points to a time in the past.
The ENRResponse packet (0x06) and signature verification
The packet data for ENRResponse is [request-hash, ENR]. request-hash is the hash of the entire ENRRequest packet being responded to, and ENR is the node record itself. The recipient must verify that the record is signed by the node that sent the ENRResponse. This verification prevents the record from being tampered with in transit and makes the interpreted record an authoritative result.
The procedure for resolving a record from a public key
To resolve the current record for a given node public key, first perform a Kademlia-style recursive lookup using the FindNode and Neighbors packets. Once the target node is found, send it an ENRRequest and extract and return the record from the response. This reuses the existing discovery node-lookup path and simply adds one record request at the end.
Motivation and standard status
The purpose of this EIP is to provide a means of requesting the latest version of a record, in order to bridge current and future discovery networks and to support implementations of alternative ENR distribution methods such as DNS. It requires EIP-8 and EIP-778, was created on February 2, 2018, and has status Final, meaning it is a finalized networking standard.