Allow resolving bootnodes through WebTorrent or IPFS

[tomaka]

I'm opening this issue just to keep notes of a discussion on Element with Gav.

Rather than hardcode a list of bootnodes in the chain spec, the WebTorrent DHT could be used in order to grab that list.

Full nodes that want to be bootnodes would register themselves as seeders of a dummy torrent file and publish in the WebTorrent DHT an entry containing their port, WebRTC certificate hash, and PeerId.

This is a long term issue that requires a lot of work.

See also:

• https://webtorrent.io/
• http://bittorrent.org/beps/bep_0003.html
• http://bittorrent.org/beps/bep_0044.html

[tomaka]

Unfortunately, WebTorrent uses WebRTC only to connect together the browsers that want to download a torrent. The DHT doesn't use WebRTC (it's the same DHT as the regular Bittorent, so over UDP). The WebTorrent library doesn't support looking into the DHT, it only supports using a tracker over WebSocket.

[tomaka]

I've opened polkadot-fellows/RFCs#8 for parachains

[tomaka]

Another possibility is IPFS, who are working on integrating WebRTC: libp2p/go-libp2p#2337

[tomaka]

go-ipfs have just released experimental WebRTC support: https://github.com/ipfs/kubo/releases/tag/v0.24.0#experimental-transport-webrtc-direct

[tomaka]

Unfortunately, storing the bootnodes on IPFS has a pretty big flaw: only 20 bootnodes can be stored at a time, after which new ones will be (silently) ignored.

This means that adding yourself to the list of bootnodes is first come first serve. Consequently, an attacker can try register 20 fake/malicious nodes to clog this mechanism, or even do an eclipse attack. And if they succeed, it's "forever" as long as the fake/malicious nodes don't go offline for more than 48 hours.

Additionally, this mechanism is also attackable on the IPFS side. Only the 20 DHT nodes closest to a certain key store the providers of that key. This means that an attacker can try to generate public keys until they find 20 keys closest to the one where the bootnodes are registered, then spawn malicious IPFS nodes that use these keys. If they succeed, they control the list of bootnodes.

In polkadot-fellows/RFCs#8, the DHT key at which the bootnodes are stored is rotated periodically using the relay chain randomness. This more or less solves the second problem (the IPFS-side attack). At each rotation, there is a rush to register yourself first, and who actually arrives first is random (as it depends on the way the block announce propagates and the ping time of the DHT nodes that store the record), so it more or less solves the first problem as well.
For the relay chain bootnodes, however, we don't have access to any randomness. Even if the key at which the bootnodes are registered was rotated over time, this rotation is predictable.