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.