search

ethereum / devp2p

Ethereum peer-to-peer networking specifications
984 stars 275 forks source link

discv5: define ENR exchange #80

Closed fjl closed 5 years ago

fjl commented 5 years ago

The recent handshake proposal in #60 ensures that ENR of the initiator of a discovery request will be shared with the recipient. The spec also includes the PING and PONG messages which can exchange the node's respective ENR sequence numbers.

We still need to define how ENR 'sync' will work. When a node generates a new record, its neighbors should become aware of the new record quickly. Should nodes 'push' their new record or have it 'pulled' by neighbors as part of liveness checks? Should PING / PONG include the record or should we have an explicit REQUESTENR packet like in EIP-868?

Another question is how requesters get the record of the recipient during handshake. We assume that some version of the record is known to the requester before sending its first packet, but it might not necessarily be the latest version. Should information about the recipient's ENR sequence number be included in the handshake? If so, should the requester pull the new record after the handshake?

fjl commented 5 years ago

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 commented 5 years ago

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

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 commented 5 years ago

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 commented 5 years ago

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

FrankSzendzielarz commented 5 years ago

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.