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 likeIPFS. While this attack can never be fully prevented, it can be mitigated. Bitcoin nodes only connect to one peer per /16 IP block.
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.
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 data outside of the DHT. 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.
❤️❤️
Обсуждают сегодня