[throwaway82652]

I'm sorry but absolutely none of those applications need blockchains or even benefit from them at all. If you want to discuss this I could go into extreme detail why that's the case. I can understand being excited about the promises made by them but at some point we all need a good reality check. Having curiosity doesn't suggest any particular kind of acceptance, we can actually accept that something is universally useless and not worth our time. I'm not saying this because I want to crap on people's startups, I'm saying this because they could make a lot better products if they weren't getting wrapped up in this.

[everfree]

I actually wouldn't mind you going into detail about why naming systems like ENS do not benefit from being on a blockchain, as they seem to me to be one of the more obvious use cases.

If the default path of technology were such that our current DNS system were based on a blockchain smart contract system, and then someone proposed a new system with single points of failure, reliant on trusted recursive resolvers, registrar middlemen, a trusted root zone for every country, and a tacked-on CA system that requires fully trusting N-of-N organizations dotted across every jurisdiction on the globe whose job is to verify address resolution from multiple network perspectives, plus OCSP and CT servers to enforce revocations and maintain certificate history - both of which are problems directly caused by a non-blockchain system design - they would be laughed out.

With ENS:

* The blockchain itself is the root of trust, because every name entry has an associated owner entry and every owner entry has a public key entry, which can be used to encrypt and authenticate content.

* Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software.

* Users can register names directly by using a piece of software, without requiring registrar companies.

* The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers.

* In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS.

If you want to go into "extreme detail", now is the time. Please tell me why I am wrong.

[throwaway82652]

>they would be laughed out.

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. 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. 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'll address each of your points.

>The blockchain itself is the root of trust

Which is the single point of failure.

>Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software.

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.

>Users can register names directly by using a piece of software, without requiring registrar companies.

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. 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.

>The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers.

This is also incorrect, you're trusting parties to host the system on the blockchain which are the "privileged servers".

>In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS.

The solution here would be to just add more redundancy to DNS, blockchains again don't do anything special.

[everfree]

> 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.