diff --git a/EIPS/eip-868.md b/EIPS/eip-868.md index 41732b42fe4a8..5cfa2b48c6d97 100644 --- a/EIPS/eip-868.md +++ b/EIPS/eip-868.md @@ -18,35 +18,66 @@ resolution of Ethereum Node Records (ENR). To bridge current and future discovery networks and to aid the implementation of other relay mechanisms for ENR such as DNS, we need a way to request the most up-to-date version -of a node record. +of a node record. This EIP provides a way to request it using the existing discovery +protocol. # Specification -Implementations of Node Discovery Protocol v4 should support two new packet types, a request -and reply of the node record. The new packets are: +Implementations of Node Discovery Protocol v4 should support two new packet types, a +request and reply of the node record. The existing ping and pong packets are extended with +a new field containing the sequence number of the ENR. -### enrRequest (0x05) +### Ping Packet (0x01) -RLP: `[ expiration ]` +```text +packet-data = [version, from, to, expiration, enr-seq] +``` -When a packet of this type is received, the node should reply with an enrResponse packet +`enr-seq` is the current sequence number of the sending node's record. All other fields +retain their existing meaning. + +### Pong Packet (0x02) + +```text +packet-data = [to, ping-hash, expiration, enr-seq] +``` + +`enr-seq` is the current sequence number of the sending node's record. All other fields +retain their existing meaning. + +### ENRRequest Packet (0x05) + +```text +packet-data = [ expiration ] +``` + +When a packet of this type is received, the node should reply with an ENRResponse packet containing the current version of its record. -To guard against amplification attacks, the sender of enrRequest should have replied to a -ping packet recently. The expiration field, a UNIX timestamp, should be handled as for all -other existing packets, i.e. no reply should be sent if it refers to a time in the past. +To guard against amplification attacks, the sender of ENRRequest should have replied to a +ping packet recently (just like for FindNode). The `expiration` field, a UNIX timestamp, +should be handled as for all other existing packets i.e. no reply should be sent if it +refers to a time in the past. -### enrResponse (0x06) +### ENRResponse Packet (0x06) -RLP: `[ requestHash, ENR ]` +```text +packet-data = [ request-hash, ENR ] +``` -This packet is the response to enrRequest. +This packet is the response to ENRRequest. -- `requestHash` is the hash of the entire enrRequest packet being replied to. +- `request-hash` is the hash of the entire ENRRequest packet being replied to. - `ENR` is the node record. -The recipient of the packet should verify that the node record is signed by node who -sent enrResponse. +The recipient of the packet should verify that the node record is signed by node who sent +ENRResponse. + +## Resolving Records + +To resolve the current record of a node public key, perform a recursive Kademlia lookup +using the FindNode, Neighbors packets. When the node is found, send ENRRequest to it and +return the record from the response. # Copyright