The Delta Foundation for P2P Distributed Systems Engineering

Bootstrap access to the distributed network

Introduction

When a node first shows up on a decentralized network, it faces a problem of connecting to its first peers so it can discover the topology of the network and start gaining access to data.

The issue is the first link from a peer to the decentralized network requires an anchor, usually static, which can be abused, attacked or taken over.

This topic discusses a few ways to go about working aroung the issues.

Several nodes

Always as much as possible have several bootnodes. Ideally the whole network can operate as a bootnode.

Local multicast

This is taken after SecureScuttlebutt. On a local network, it should be possible to issue a multicast packet with the nodes known to the peer, associated with a network identifier. This in turns allows new nodes showing on the network to connect to the peer.

This is possibly useful to keep connections alive with a local network.

The multicast packet in the case of SSB is sent to the network every 5s.

Ideas:

  • Add a router extension for DD-WRT that calculates the peers and broadcasts to the network.

Cycling through nodes

Several nodes mean you want to have some randomness when you connect to them. As much as possible, pick one at random. Keep consuming the list of nodes until one responds, and use the peers it sends you to connect to more peers.

Dynamic list of initial peers

Initial peers or bootnodes can be dynamic.

Store the list of peers in a static website resource

One can store a list of peers on a readily available static resource on the web, such as S3, Dropbox, Github. When the node starts, it is given the URLs of such resources to load from.

Store the list of peers in a dynamic resource

One can store a list of peers on a dynamically replicated data source such as IPFS.

Store the list of peers on a replicated resource

One can store a list of peers as a TXT record on a DNS server.

One can also store all initial peers as IPs under the same A record. This requires all bootnodes to use the same port number (an additional SRV entry can be used to specify the port).

It’s also possible to extend that use case so the right peers are returned based on GeoDNS. See this post for a high level introduction to the concept.

Securing the initial link

The biggest issue when connecting initially is to ensure the validity of the first peers it connects to. This is a particularly vulnerable time and can be the subject of eclipse attacks with Kademlia, so it is of great importance to have security at this time.

All the storage options listed above can be spoofed or destroyed. To work around this issue, the node should be configured with the public key of the issuer of the bootnodes list.
When providing the list of bootnodes, the issuer should sign the list with the private key, and attach the signature. This way it will be possible for a node to check that the list of initial nodes is correct.

I had a discussion with Felix Lange of the EF who pointed me at this Ethereum Improvement Proposal: https://eips.ethereum.org/EIPS/eip-1459