Radiks backed by p2p databases

There was a discussion on slack about how Radiks’ mongo db storage could be replaced by a p2p storage. @jorishermans provided a pull request to include OrbitDB.

@jude gave a detailed answer to my question: “Is it that the problem is not well understood and solved or that the projects are not yet ready?” I wanted to save his answer here:

The problem is that all of these projects use a distributed hash table (DHT) for routing requests. DHTs are notoriously unreliable, have poor performance, and are easy to attack. They should not be used in open-membership p2p systems (which all of these are), since it only takes a single malicious node to do things like:

  • split the network
  • execute targeted censorship attacks (i.e. attack specific key/value pairs while leaving the rest of the system alone)
  • force look-ups to pass through attacker-controlled networks (i.e. to de-anonymize users)

The problems with DHTs are well-understood and well-documented in academic p2p literature (my favorites papers on the subject are [1], [2], and [3]). The problem with the projects that use them is that the core developers usually fall into one of the following stances:

  • They themselves do not understand how easy it is to break DHTs (this includes Ethereum, the subject of [3] no less)
  • They think it’s acceptable to ship a project that uses a DHT by default as long as a less-desirable alternative is available (this is IPFS’s stance – they unironically tell people to use DNS if you don’t like the DHT)
  • They learned too late that DHTs are problematic, and are actively trying to stop using them (this is DAT’s stance)

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/2002/01/IPTPS2002.pdf
[2] https://nymity.ch/sybilhunting/pdf/Wang2012a.pdf
[3] https://eprint.iacr.org/2018/236.pdf

When investigating a newly-discovered p2p project, one of the first things I look at is how the system handles request routing, since in my experience the design of the request-routing system is a good indicator of how well-designed the whole system is. Sadly, almost all p2p projects these days use a DHT of some kind for this (usually Kademlia). As such, I usually don’t have many good things to say about most p2p systems out there – reliance on an open-membership DHT for core functionality is a deal-breaker for me.

Furthermore, there are lots of papers that try to make open-membership DHTs robust against certain kinds of attacks, but the countermeasures they document are usually very limited in scope and/or easy to circumvent with a small amount of additional effort over the usual attacks against naive DHTs.