An Eclipse Attack is an attack in which an honest node’s immediate peers are all dishonest, blocking or modifying communication between the honest node and the larger network. This attack is specific to gossip-based peer-to-peer networks such as Bitcoin, Holochain, and DHTs like IPFS. While this attack can never be fully prevented, it can be mitigated. Bitcoin nodes only connect to one peer per /16 IP block, for instance.
Holochain reduces the impact of Eclipse Attacks by providing basic, built-in guarantees of data integrity. Each piece of data carries its author’s signature, so adversaries can never tamper with others’ data.
However, intrinsic data integrity merely protects the integrity of existing data. Even though Holochain can guarantee that data hasn’t been tampered with, adversaries in an Eclipse Attack could still make life miserable for an honest node by blocking the transmission of data. Holochain’s networking layer is still under heavy development, so our mitigation strategies are not yet set in stone, but one crucial element is the ‘bootstrapping’ process, in which a node finds peers with whom to gossip.
These possibilities are under consideration:
- Avoid connecting with too many peers in a certain IP block, as with Bitcoin.
- Provide a bootstrapping server that provides a large number of randomly chosen peers to which a node can connect.
- If a node’s introduction to a new DHT is facilitated by one of their peers in an existing DHT, that peer can act as their ‘harbour pilot’ into the new DHT. This process can take advantage of existing human or digital trust and reputation factors.
- Nodes can ask their initial peers for assurances of trust based on reputation or identity verification.
- A node can look for a ‘sentinel node’, a trusted node that is known to generally be online and connected with a healthy portion of the network. If that sentinel node can’t be contacted, the node can shut down its activity and try to reconnect to a new set of peers.
Finally, application developers can take steps to further protect their users:
- Put appropriate processes in place, such as identity verification, to govern membership in a DHT and place a limit on the number of DHT nodes each real-world identity can create. This reduces the chances of a malicious actor cheaply creating a large number of nodes to stage a Sybil Attack against the network, which then makes Eclipse Attacks easier.
- Design validation rules requiring high-stakes entries to carry proof of their author’s reputation, ideally by referring to ‘portable verifiable claims’ that don’t depend on the current state of the network. This doesn’t prevent an Eclipse Attack, but it does give an honest node the power to detect suspicious peers and reject data originating from them.