search

ethereum / consensus-specs

Ethereum Proof-of-Stake Consensus Specifications
Creative Commons Zero v1.0 Universal
3.52k stars 953 forks source link

Discv5 Open Questions #1063

Closed mslipper closed 5 years ago

mslipper commented 5 years ago

Hi everyone,

I thought I'd compile this issue with a couple of notes regarding discv5. Inputs for these consist of research I've done into discv5 and other discovery protocols, and the discussion I had with @fjl about two weeks ago. The goal here is to kick off a discussion around discv5, and make a decision around its adoption.

Implementation Notes

discv5 uses a different transport mechanism and DHT than libp2p. As such, it cannot easily be assembled from libp2p components. That said, discv5 is an upgrade over discv4, which already sports a number of existing implementations.

Questions: How hard is it to interoperate between peers discovered via discv5 and peers communicating via libp2p? It looks possible to wrap ENRs with the appropriate multiaddr metadata for use within the libp2p peer book.

Topic Subsets

discv5 was invented in order to add support for the advertisement of topic subsets. This works well for ETH2, as we'll likely want to advertise topics for the following things:

  1. Chain ID
  2. Node type (i.e., light/full node)

Note that discv5 is a poor choice for ephemeral topics (such as shard information) because topic advertisements are long-lived.

Questions: Are there any other long-lived topic types that we will need?

Transport Mechanism

The discv5 transport mechanism consists of RLP-encoded UDP packets (see the wire protocol for the full spec). Obviously, this is different from the SSZ encodings we've been using elsewhere.

Questions: Is the encoding/transport mechanism something that we will want to change for the sake of consistency?

Encryption

discv5 generates an ephemeral key during the handshake phase of the protocol. This same key could be used to encrypt traffic between ETH2.0 nodes elsewhere in the network stack.

Question: What is the relative priority of encrypting network traffic at this time? IMO, we should punt on this until later. If it's high enough to warrant inclusion in Phase 0, are there any objections to using the ephemeral key to encrypt non-discv5 network traffic?

JustinDrake commented 5 years ago

As I understand there has been a lot of recent progress on discv5. @mslipper have you been able to answer all your questions?

hwwhww commented 5 years ago

link https://github.com/ethereum/devp2p/issues/107

mslipper commented 5 years ago

This can be closed.