Secure Network Joining

[whyrusleeping]

Nodes joining the filecoin network will need to determine what the ‘correct’ chain is. This can be difficult if there are a good number of adversarial nodes in the network. A newly joining node may connect to malicious nodes, be given other malicious nodes, and be given a bad chain. The new node needs a way to determine that these nodes are bad, and that the chain they are told about isn’t the canonical one.

A simple approach

A relatively easy solution would be for nodes to specify nodes that they know are ‘good’. These can be nodes run by well known people (the Filecoin team, large exchanges, foundations, etc). We can trust that the chain head that they tell us is the latest, is actually the latest and correct chain head to start syncing from.

This generally works, but is a little centralized, and breaks down under more adversarial conditions (if too many people rely on a given node, that node could be susceptible to DoS attacks).

Increased Resilience

The problem we’re trying to solve is “How do I discover the real chain after joining the network through a potentially untrusted entry node?”.

If the nodes you initially connect to are malicious, then they can simply serve you malicious other peers to all of your requests, and effectively prevent you from ever discovering the real network.

So given that, we need to assume the ‘bootstrap’ nodes to be non-malicious. The nodes that they introduce us to may be malicious, or they might not be. Each of the nodes we connect to will give us their ‘best’ chain, and other peers. A peers ‘best’ chain information should contain the hash of several checkpoint blocks that the consider ‘final’. The ‘other peers’ set contains other known peers, and a signed set of checkpoints from those peers.

To securely bootstrap, first pull peers out of a non-malicious peer source, and connect to them. Record each of their chain infos. Now, while your bootstrapping heuristic is below a given threshold, loop, and randomly sample peers from the set of unconnected-to peers, and connect to them, adding their checkpoints and other peers to the local store (be sure to keep track of which peers recommended which other peers). If at any point a peer returns a conflicting checkpoint from the checkpoint set returned for them by the introducer, that peer should be considered malicious, disconnected from, and removed from the set of peers you introduce others to. If at any point the checkpoint sets for your queried peers conflict (you have peers with different checkpoint histories) TODO.

The specific selection of the bootstrapping heuristic could be left up to the implementation. Simple ones may be just check how many peers you’ve connected to and checked, more complicated ones may take into account work proven by different parties, IP address distributions, or even trust graphs.

[whyrusleeping]

It is worth noting that bitcoin tries connecting to random IPv4 addresses in an attempt to find other bitcoin nodes. And they used to connect to an IRC channel and use that for node discovery. We should look into interesting alternative node discovery protocols.

[sternhenri]

I think this needs to explicit some necessary assumptions about the way FIL work in order for the proposals to make sense:

• FIL assumes no long-lived network partitions
• FIL assumes >51% of the network is honest

I think you are making the point that because of the second assumption, honest nodes' "best chain" will be heavier than those of malicious nodes. Are you? If so, that should be stated explicitly and we should add that in bootstrapping you discard all but the heaviest best chain up to a threshold. Still doesn't resolve the eclipsing issue though.

Thereafter, the larger issue I think is the mention of the "non-malicious peer source." I think that involves some measure of centralization (as with BTC or others). We may want to just take it as our running solution and talk about how we mitigate DoS threats by having a somewhat decentralized list of "trusted bootstrap nodes" that gets refreshed at frequent intervals based on checkpoints. Note that it would be nice to have bootstrapping and network partition detection use the same-ish mechanism. (both imply having more than we currently have on finality, so to start we would want to use n chosen trusted peers :/)

[sternhenri]

Being worked on here: filecoin-project/specs#106