| > No they wouldn't because almost all of those properties are actually desirable, and the only real achievement of ENS is to approximate all of that. What properties? What I've listed are operational requirements, which blockchain systems have much less of. Some desirable properties I can think of are reliability, security, and geographic redundancy, all of which a blockchain system could match or exceed. Getting rid of the CA/OCSP/CT system would be a huge start security-wise, and getting rid of trusted operators for particular TLDs would be helpful reliability-wise. > Remember that the whole reason you're even using a blockchain (in the Ethereum sense) is because it artificially makes it too expensive for ordinary people to fork the chain. It has no purpose otherwise. "The chain" is a geographically distributed database, an ideal kind of data structure for keeping track of names. If forked, the database is no longer useful. The protocol's purpose is to maintain that data structure, which is enough. There doesn't need to be an "otherwise", because that data structure has desirable properties that no other type of protocol can replicate. > If you can come up with a cheaper and more efficient way to do that then there's no reason to use a blockchain. I do believe that a blockchain is actually much cheaper and more efficient than the network of thousands of licensed and privileged organizations that we currently have. A proof-of-work blockchain is not more efficient, of course, but a proof-of-stake blockchain is. You could eliminate a lot of jobs in devops and reliability engineering, and replace them with hobbyists running blockchain client software on a home server. > Which is the single point of failure. Properly designed blockchains have no single point of failure. The only point of failure is the protocol itself, which you could also say about DNS. Ethereum has had a massive target on its back for many years now, yet has had zero downtime. > This is not actually desirable, you have no way of knowing whether someone is actually doing this correctly and not sending you fake records unless you use some other trust mechanism. The fundamental purpose of a blockchain is to come to consensus on data without any trusted parties. When you query data from a blockchain like Ethereum, that data is signed off by the network's consensus algorithm, so you can trust that it hasn't been altered. Data integrity is a basic blockchain concept. On the contrary, it's your recursive resolver in the current DNS system that you have no way of knowing is sending you fake records. As client DNSSEC adoption is effectively nonexistent (and registrar and domain adoption is spotty too), your recursive resolver can send you just about anything. Unless you use some other trust mechanism, you have no idea whether the IP it gives you for a certain name is valid. > This is not true at all because most users need to go through a number of middlemen to interact with the blockchain in any way. Not true. People do that because it's convenient, but all you need to start resolving is to download geth and query the resolver contract. You don't need any middlemen. > In practical terms you aren't getting rid of registrar companies by doing this, you're just farming the task out to miners/validators who get paid to run the smart contract. That's true, but a swarm of unprivileged computers with an m-of-n trust profile and uptime guarantee is preferable to your registrar with a 1-of-1 trust profile and uptime guarantee. The blockchain behaves predictably as long as m-of-n validators are honest - a company behaves however it wants to, and could throw you under the bus at any point due to incompetence or corporate malice (see the story of "How I Lost My $50000 Twitter Username"). > This is also incorrect, you're trusting parties to host the system on the blockchain which are the "privileged servers". The trust profile is totally different, though. DNS requires 1-of-1 trust for each TLD. ENS requires m-of-n trust across a swarm. If one DNS TLD server goes down or defects, an entire section of the internet goes down. If one blockchain validator goes down or defects, the network boots them off (validator exit) and nothing happens. > The solution here would be to just add more redundancy to DNS DNS is already very redundant. How would you add more reliability without completely rearchitecting the protocol, or adding a concept of "a chain of blocks of data" that registries pass around and vote on the validity of? > blockchains again don't do anything special. We might have to agree to disagree. I think it's self-evident that something "special" was achieved, otherwise people would have forgotten about them a decade ago and moved on. |