Implement RFC 8: store parachain bootnodes in the relay chain DHT

[tomaka]

This PR is about implementing polkadot-fellows/RFCs#8
(note: I'm opening this issue before the RFC is accepted because I assume it will be unanimously accepted, will close if it's not the case)

There are two different but related aspects to this RFC that need to be implemented:

• Parachain nodes should register themselves in the DHT.
• Parachain nodes should discover other nodes from the DHT.

The DHT registration described in the RFC should use Kademlia::start_providing.
Looking for other nodes should use get_providers.

As I mention in the RFC text, I believe that rust-libp2p already hashes the key.
The RFC says that the key is sha256(concat(scale_compact(para_id), randomness)), but since rust-libp2p already hashes it, what you need to pass as parameter is instead just concat(scale_compact(para_id), randomness).

Since the authority discovery system is already using Kademlia, I would expect the wiring between the parachain node and the relay chain Kademlia to not encounter any major obstacle. The authority discovery system is not using Kademlia's providers system but straight-up Kademlia records, so you probably need to add a few functions that are similar to the existing one but not exactly the same.

The way I would expect the registration to be implemented is to start a background task that in a loop: queries Babe_current_epoch & Babe_next_epoch, updates the providers registration if necessary, then sleeps for a few minutes.
Implementing it this way means that for each node the registration would take a different amount of time (up to a few minutes) between the moment when the Babe epoch changes and the moment when the registration updates, which as mentioned in the RFC is a good thing in order to avoid a spike of traffic to the nodes handling the DHT records.

Are you willing to help with this request?

Only by answering questions regarding the RFC.

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/smoldot-updates-threads/4471/4

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/smoldot-updates-threads/4471/8

[tomaka]

cc polkadot-fellows/RFCs#59

If someone is implementing this any time soon, they might want to keep in mind that polkadot-fellows/RFCs#59 aims to make the mechanism slightly more generic than what is described in RFC 8.

[dmitry-markin]

We had some internal discussions regarding the issue, and it seems it is quite easy to generate enough peer IDs to either:

1. Displace all 20 parachain providers from the nodes keeping the target provided key for the para_id.
2. Completely take over all the nodes keeping the providers on the relay chain DHT.

For (1) the amount of peer IDs to generate to get closer to the target key than all the parachain nodes is in the order of number of parachain nodes, and for 20 such IDs is in the order of 20 * N_of_para_nodes, because we can generate one peer ID at a time checking if it's closer than the parachain providers.
For (2) the total amount of peer IDs to generate is 20 * N_of_relay_chain_nodes.

To have close to 1 probability of taking over the bootnodes the amount of peer IDs to generate is higher, but the order is still the same.

@tomaka am I missing something?