discv5: define ENR exchange

[ethereum]

discv5: define ENR exchange

[fjl]

Simple idea for pull-style sync: Add highest-known sequence number of destination node to the PING packet. Define that nodes should return their local record in PONG if seq is higher than the one in PING.

[FrankSzendzielarz]

Thinking about the 1st question, can we list some of the scenarios under consideration?:

• Node changes IP/port
• Node changes its identity?
• Node changes id scheme
• Other stuff in the ENR that does not affect the id/handshake eg: "Client Name: geth" or some such...

If the node is changing the IP/port, then push or pull it's an attack scenario [i.e. 1) I establish handshake, 2) my enr goes into peer dht 3) i tell peer 'hi I am now on a different ip' but my source IP is spoofed] So....maybe prefer to push (well, the peer can't pull from an old ip or port) but in this case the recipient verifies the incoming UpdateMe message with the WhoAreYou (and nonce) to verify ?
Problem: what if two nodes need to update themselves to each other at the same time? They wouldn't be able to without an intermediary. Unsolvable non-issue?

If the Node is changing identity...similar? But the node should be able to announce in advance? Over existing channel, send "UpdateMe" and again re-establish channel.

If nothing channel-related updated, take UpdateMe message , process and preserve existing channel?

[fjl]

Been thinking about this in the context of EIP-868 last few days. We need a similar mechanism for v4 to implement record sync on top of the new enrRequest. I'll implement it as follows:

When a node pings us or we receive a pong reply, the sequence number in the message is compared
to the one in the local node table. If our local copy has lower sequence number, we enqueue a request to retrieve the latest version using enrRequest.

[fjl]

Best solution so far: since FINDNODE takes distance, requesting distance zero is equivalent to enrRequest.

[FrankSzendzielarz]

Yes, for v4. And for v5 bucket zero could represent the same thing. However for the scenario that IP changes, the node may still need a Push message of some type, or otherwise the handshake would need to be reestablished I suppose.