Allow querying the owner of a key on the networking layer

[tomaka]

Add a DHT whose entries are keys, and whose associated values are a list of PeerId and listening addresses of nodes which own the key. The entries are signed.

This should be done by modifying network-libp2p. We can add a method to Service to start a request for a specific key. On success, we should automatically connect to the node which owns the key. The OpenCustomProtocol that reports the successful connection should indicate that this corresponds to a fulfilled request. Also add a new variant in ServiceEvent for requests that time out or fail.

[tomaka]

The Kademlia variant that libp2p uses has GET_PROVIDERS and ADD_PROVIDER messages that are specifically made for that. However they don't allow signing their record. We will probably need our own variant of Kademlia unfortunately.

[Demi-Marie]

DHT = Distributed Hash Table?

[tomaka]

Yes

[mxinden]

Current plan / status:

1. Making itself discoverable

   1. Retrieve its external addresses
   2. Adds its network peer id to the addresses
   3. Sign the above with its authority key (for now consensus)
   4. Put the signature and the addresses on the libp2p Kademlia DHT

2. Discovering other validators

   1. Retrieve the current set of authorities (currently only consensus, not finality)
   2. Start DHT queries for the ids of the authorities
   3. Validate the signatures of the retrieved key value pairs
   4. Add the retrieved external addresses as priority nodes to the peerset

A work in progress version of the above is in #3247.

[xlc]

I am wondering how this plays with sentry node setup? i.e. validator node that is protected and only accessible via a sentry node
paritytech/polkadot#264

[mxinden]

The idea would be the following:

An operator would configure its validator with a set of multi-addresses of its sentry nodes, e.g. via a command line flag or a configuration file. Instead of putting its own external address (which would not be routable on the public internet) on the dht, it would put the external addresses of its sentry nodes on the dht.

With the above, validators trying to connect to other validators can find the multi-addresses of a validator or the multi-addresses of a validator's sentry nodes on the dht.

Does that answer your question @xlc?

[xlc]

Yes that makes total sense.

[mxinden]

Given that both the /core as well as the /srml authority discovery modules are merged I will close here. @tomaka please correct me if I am missing something from your initial issue description.