DHTs simply enable key/value pair storage and retrieval across many machines. They don’t usually make any guarantees about the authenticity, provenance, timelines, or the integrity of data sources. In fact, since many DHTs are used for illegal file sharing—like Napster, BitTorrent, Shareazaa—they are designed to protect the anonymity of uploaders to keep them out of trouble. File sharing DHTs frequently serve virus-infected files, planted by uploaders trying to infect pirates’ machines. There’s no accountability for these actions or reliable ways to ensure that bad data doesn’t spread.
By embedding validation rules as a condition for the propagation of data, our DHT has an ‘immune system’ that identifies and isolates bad activity. In particular, each piece of data must be signed by its author and be part of an unmodified ‘chain’ of activities leading back to the beginning of their participation. This can provide a similar level of consistency and rule enforcement as blockchain ledgers, without the bottlenecks of global consensus.
The Holochain DHT leverages these signed source chains to ensure that data hasn’t been with tampered with and to hold dishonest agents accountable for their actions. On top of these two base rules, application-specific validation rules ensure that a community can carry on its activities even in the face of attacks.
The Holochain DHT also emulates aspects of a graph database, enabling people to connect links to other hashes in the DHT tagged with semantic markers. This helps solve the problem of finding the data that you want to retrieve from the DHT. For example, if I have your user identity hash, I could query it for links to blog articles you’ve published to a Holochain; I can find the articles without knowing either their hash or their content. This is part of how we eliminate the need for tracking/indexing nodes on which many DHTs rely.