Zooko's triangle, why not use the DHT?

1

So here’s my idea, I’m not sure it is an original idea nor that it is a counter-example to Zooko’s triangle.
So the website owner has a domain name and he hashes it. The peer who has the peerID closest to this hash stores the key-value pair (hash of domain name->CID or IPNS link). When I want to lookup a domain name, I hash it and find the correct peer, who returns to me the correct CID or IPNS link.

Thanks for reading. Again, I would be really surprised if this idea has not already come up, so it makes me think that there must be some problem that I have not considered.

1 Like
2

@JacopoStanchi Zooko’s triangle addresses a more fundamental problem that might explain the tradeoffs with your suggestion.

One way to look at the triangle is that you get to pick 2 out of 3 from Unique Choosable Names, Partition Tolerance, Non-Consensus. The reason for this is simple, if Alice and Bob are in two different partitions that cannot communicate and both decide they want to choose what the name “bestHuman” maps to (Alice chooses herself, and Bob himself). Without some global agreement/consensus about whether Alice or Bob is qualified to decide the value of “bestHuman”, there will be different answers in each partition (resulting in either no partition tolerance or no unique choosable names depending on how you look at it).

In your case the problem is that if we replace “bestHuman” with “bestHuman.com” in the above scenario both Alice and Bob can push to the DHT “bestHuman.com” => Alice/Bob CID. If the DHT nodes used DNS (a consensus system) to resolve “bestHuman.com” and store that value and were trusted to do so by the network then we could ask the DHT for values. However, at that point it would be faster and more secure to go to DNS directly.

Hope this was helpful. If you’re interested in Zooko’s triangle/naming things I would take a look at how to combine/layer different 2 out of 3 systems to make it feel a lot like you have all 3. For instance, if you combined IPNS (Partition Tolerant and Non-Consensus, but no Unique Choosable Names) with a consensus system with Partition Tolerance and Unique Choosable Names (e.g. DNS, blockstack, ENS, etc.) then you can end up with interesting properties depending on how you combine the systems together.

1 Like
3

First off thank you for your answer, I had a little bit lost hope to get an answer here.

I understand the problem when 2 people want to get the same domain name, but that’s simply a business model problem. For example, let’s say Charlie is the node chosen to store the key-value pair of bestHuman.com. He is the one to choose to who he rents the domain name given that he will get all the traffic of their website. He can put this domain name in auction between Alice and Bob and give it to the highest bidder for example. But to limit the single-point of failure, we can make several nodes store the key-value pair instead of one (Charlie).

Even on Blockstack or ENS you have to pay to get a domain name, otherwise the same problem would occur on those systems. Besides, I am not really fond of solutions that involve a blockchain. The Bitcoin blockchain exceeded 200gb, imagine how much larger a blockchain containing all the DNS would be, and you have to store it on every computer of the network! I am not fond of the DNS either, I want a system that would still work even after a global disaster, when all the DNS servers don’t work anymore and the web hosting companies (GoDaddy, OVH,…) have shut down.

The idea is merely a minimal valuable product, if it has fundamental flaws it must be abandoned right away, but if it has subsidiary problems like “what will be the business model of such name system?” it can be fixed.

In any case, I understand that the idea I gave is at fault on the “security” attribute of the Zooko triangle. But everything that involves a DHT has the same security problems: “what if a node lies?”, “what if a node does not respond?”… And IPFS already uses a DHT, so I assume we fixed some of its problems OR we don’t care about it.

Where did you find the formulation “Unique Choosable Names, Partition Tolerance, Non-Consensus”? I like it because I think it is more precise than “human-meaningful, secure, distributed”. Besides, if the reason behind the Zooko triangle is simple, why is it still a conjecture? It must have been proven and now it is a theorem, no?

5

If nodes can lie, but you still want it to be decentralized, then you need a consensus. If I remember well, IPNS waits until a quorum of 16 nodes agree on how to resolve the name, which is super slow and less safe than what a blockchain can offer.

The scalability issue of blockchains that you are pointing can have solutions. For example, having a separate network of nodes that only store domain name specific transactions already limits the size drastically. Then when the blockchain becomes too large, everybody can agree on not cloning the blocks older than 10 years, and start cloning from a new reference block.

7

For any large-scale DNS-like deployment backed by a blockchain it would make sense to store the zonefiles off-chain (in, for example, IPFS) and only store the pointers to the zonefiles on-chain.

8

For me using the blockchain is like “You want to decentralize the DNS? Then store the whole DNS on each computer!” We cannot afford to waste resources like that, especially right now, whether it be energy (PoW) or hard disks. The notion of security of the blockchain is peculiar as well. While asymmetric cryptography showed us that security can just be chosing a 256 bits private key randomly, the blockchain definition of security is “bruteforce harder than the attacker”. Waste of resource doesn’t have to be a cost for security. Even if you have a blockchain dedicated to only storing domain names, I’m convinced it would widely exceed the size of the bitcoin and ethereum blockchains combined. Changing the reference of the blockchain every 10 years wouldn’t help much, the DNS-blockchain would still be too large to store on a common PC.
The blockchain would also store all the domain-names that are no longer used, and while it can be good for archiving, it also stores a lot of trash.

9

@kivutar IPNS’ quorum is sort-of, but not really a consensus mechanism. IPNS’ main security protection is that each record is signed with a private key corresponding to the IPNS key name. This means that the only attacks really viable against the network are denial of service (DoS) and rollback (where a malicious user shows you a record older than what should be available to you).

@JacopoStanchi It’s not about the business model so much as it is the “security” tradeoffs. The first thing is that there is no one node that will for all time be the “closest” to a particular value since if Charlie’s node goes offline, it’s possible that now Dan is the closest node to bestHuman and so the content of bestHuman will change. Similarly Emily can generate a new public-private key pair with a peerID that happens to be closer to bestHuman than even Charlie. This breaks traditional DNS semantics since there is no one party in control of the name bestHuman.

For a comparison let’s look at the bad things that happen when DHT nodes lie in IPFS, IPNS, and your DHT-DNS proposal:

IPFS: Node gives you the wrong or no multiaddresses for who has the content you’re looking for = DoS. However, because the key of the IPFS entry is the hash of the content no-one can trick you into downloading bad content.
IPNS: As described above is subject to DoS, and potentially also rollback (IPNS has some mechanisms like describing the end-of-life on a record that potentially help with rollback at the expense of more DoS).
DHT-DNS: DoS and also just making up content (e.g. sending you malicious content, which you then execute on your machine thinking it’s good content)

btw the “Unique Choosable Names, Partition Tolerance, Non-Consensus” is something I made up (still trying to tweak it to sound better/be cleaner), so thanks :slight_smile:. I think the reason the Zooko’s triangle stuff is not a theorem has to do with a lack of clear mathematical formulation (and therefore proof) of what each side of the triangle means.

“Human Readable, Decentralized, Secure” has three words with fairly ambiguous meaning (there are conflicting definitions for all three of these words). The ambiguity both gets a point across, but also leaves room for interpretation/getting around the problems. For example, people have been touting blockchains as the miracle cure to Zooko’s triangle based on it being Decentralized. However, blockchains are multiple entities acting together as one entity which is mostly anti the point being expressed by Zooko’s triangle. This “solution” then occurs simply by utilizing the ambiguity in the word “Decentralized”. It’s worth noting that even my formulation is not as precise as it could be and while is pretty analogous to the CAP theorem may not map exactly.

Anyhow, sorry for the long response but hope it was useful/interesting :smile:

10

@adin
Firstly thank you again, and thanks also to everyone who replied to my post (yes, even the one spouting russian gibberish).

I have an idea to solve the problem of nodes lying or going offline. If Charlie lies, I agree that it is not possible to validate the authenticity of what he returns, unlike with IPNS and IPFS use of the DHT. But consider this: Charlie and Dan all store the key value-pair, and each get the same amount of money from the highest bidder (let’s say Alice). When Frankie does a lookup of bestHuman.com, he first ask Charlie and get a given CID. But Charlie might lie, Frankie thinks, so he also asks the closest node to Charlie, Dan, and he gets the same answer. Charlie and Dan might lie, Frankie thinks, so he also asks the next closest node, Emily. Emily didn’t receive any money from Alice, so she didn’t store the key-value pair and reply that to Frankie. So now Frankie knows that 2 nodes gave him the same CID, so he is pretty sure that this is a good answer.
If Alice wants a safer name resolve, she can “hire” more nodes to store the key-value pair. The more you pay, the safer it becomes.

But I agree this is not perfect, Emily can lie, Charlie and Dan can plot together… But it would require an increasingly large computational power to create multiple peerIds in order to lie. I think this problem gave me enough food for thought for the day :smiley:

I think the Zooko conjecture can be worded in mathematical lexicon using graph theory, computability, etc. But maybe a simpler way to formally prove it is to write all the rules underlying the network in first-order logic and let an automatic prover or a proof assistant do the work. Sorry I’m also studying mathematical logic at the moment so I’m a bit carried away :smile:

12

@mcdee
Pointing to a zone file stored in IPFS only moves the problem elsewhere. First off, it’s interesting to think about something: what would the DNS-blockchain contain?

  • If it’s a mapping “domain-name => CID of website” it means that it’s at least 1000 times larger than the current biggest blockchain. Each time you make the slightest change to your website, its CID changes so you have to change the record accordingly, and thus create a new transaction in the blockchain. Such a blockchain would basically contain the CIDs of all the versions of all the websites ever created. That’s not feasible.
    And pointing to zone files does not help. The zone file would change every time you make the slightest change to your website, and incidentally, the “DNS root zone file” will have to change aswell (think of the DNS root zone file as an IPFS folder, if you change a file in it you also change the CID of the folder), so we have to create yet another transaction in the blockchain. So every time you correct a typo in your website the blockchain gets bigger.

  • If it’s a mapping “domain-name => IPNS link” it becomes more reasonable. There is only one transaction per domain-name but the blockchain is still huge (and I uphold, too big to store in a standard personal computer). Besides, you would get all the shortcomings of IPNS (lookup time of 1 minute, use of the DHT,…).

13

Just a plug here that the interesting thing about IPNS is basically that it’s a signed record where the public signing key is also the “name” of the record. Whether you choose to distribute that record via DHT, PubSub, DNS, or your favorite protocol is up to you. There’s actually a bunch of on-going work on distributing IPNS records over PubSub and distributing IPNS records over DNS (not to be confused with DNSLink).

This is to say that if the idea of having “domain-name => IPNS link” stored in some consensus system (whether control is centralized or not) is interesting there are definitely ways to improve your system’s characteristics by just changing how the IPNS records are distributed. If you’re interested in PubSub or DNS distribution of IPNS feel free to follow and/or comment on the issues. Additionally, if you have another system for how to distribute these records feel free to implement it and as long as it conforms to the ValueStore interface (in go-ipfs) it should be very straightforward for you to plug it in.