Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-868: add sequence number to ping and pong #952

Merged
merged 2 commits into from
Mar 28, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 46 additions & 15 deletions EIPS/eip-868.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down