mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00

Adds rule to EIP-1 that references to other EIPs must use relative path format and the first reference must be linked. (#2947 )

I have gone through and updated all existing EIPs to match this rule, including EIP-1.

In some cases, people were using markdown citations, I suspect because the long-form was a bit verbose to inline.  Since the relative path is quite short, I moved these to inline but I wouldn't be opposed to putting them back to citation format if that is desired by the authors.

In doing the migration/cleanup, I found some EIP references to EIPs that don't actually exist.  In these cases I tried to excise the reference from the EIP as best I could.

It is worth noting that the Readme actually already had this rule, it just wasn't expressed properly in EIP-1 and the "Citation Format" section of the readme I think caused people a bit of confusion (when citing externally, you should use the citation format).

2020-09-30 12:22:43 +08:00

2.5 KiB

Raw Blame History

eip	title	author	type	category	status	review-period-end	created	requires	discussions-to
868	Node Discovery v4 ENR Extension	Felix Lange <fjl@ethereum.org>	Standards Track	Networking	Last Call	2020-09-18	2018-02-02	8, 778	https://github.com/ethereum/devp2p/issues/44

Abstract

This EIP defines an extension to Node Discovery Protocol v4 to enable authoritative resolution of Ethereum Node Records (ENR).

Motivation

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. 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 existing ping and pong packets are extended with a new field containing the sequence number of the ENR.

Ping Packet (0x01)

packet-data = [version, from, to, expiration, enr-seq]

enr-seq is the current sequence number of the sending node's record. All other fields retain their existing meaning.

Pong Packet (0x02)

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)

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 (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 Packet (0x06)

packet-data = [ request-hash, ENR ]

This packet is the response to ENRRequest.

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.

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.

2.5 KiB Raw Blame History