client/authority-discovery: Add option to specify relevant authority set

[mxinden]

Today the Substrate authority discovery module retrieves the AuthorityIds of all validators of the current validator set from the authorities() runtime API.

Polkadot Collators don't want to connect to all nodes within the current validator set, but instead only to those nodes that are currently assigned as validators of their parachain.

This issue suggests to make AuthorityDiscovery listen on a channel for incoming Commands where the only enum variant would be Command::SetAuthorities(Vec<AuthorityId>) (for now). Instead of considering all validator nodes for the peer set priority group it would then only consider the subset.

The channel can be an implementation detail by wrapping it in a AuthorityDiscoveryClient:

struct AuthorityDiscoveryClient(Sender<Command>)

impl AuthorityDiscoveryClient {
  async fn set_authorities(authorities: Vec<AuthorityId>) {
    self.0.send(Command::SetAuthorities(authorities)).await;
  }
}

FAQ

• Why not introduce a new method set_authorities on the AuthorityDiscovery struct?

  The AuthorityDiscovery struct is spawned as a Future onto an executor. Thus there is no way to call such method after spawning.

[tomaka]

Instead of doing this, what do you think of:

• Continue to let the authority-discovery discover all validators, as it does today.
• The authority-discovery would no longer automatically update the peerset. It would just be a passive service running in the background.
• Add some method somewhere to query the list of peerids/addresses of a given validator from the authority-discovery.

This way, when Polkadot knows the list of validator IDs we need to be connected to, it would ask the authority-discovery for the corresponding PeerIds/addresses, and do the peerset update itself.

This generally seems to me like a better way to design the system.

[mxinden]

#6760 is a first proof of concept for the suggestion above allowing to retrieve the cached addresses for a given AuthorityId.

Next steps:

• As of today the AuthorityDiscovery looks up the addresses for the current validator set every 10 minutes. It only ever caches the addresses of the current validator set, not the previous nor the next. In order to smooth the session transition we likely want to cache the previous and next set as well.

• Instead of fetching the addresses from the DHT on demand, client/authority-discovery: Introduce AuthorityDiscoveryService #6760 uses the cached addresses prefetched every 10 minutes. With client/network: Add peers to DHT only if protocols match #6549 lookups on the DHT should increase in speed. With More insight into Kademlia queries. libp2p/rust-libp2p#1567 Kademlia returns the time a lookup took. Exposing these via Prometheus should answer the question whether lookup times are fast enough to happen on-demand.