With Handshake’s explosive growth the past few months, the entire alternative naming space has taken note. As a result, we wanted to take this opportunity to directly address the differences in execution, and vision between some of the projects in the space, starting with Handshake and the Ethereum Naming Service (ENS).

The goal
Handshake’s goal is to entirely replace the root zone file. Currently, the root zone file is governed by ICANN. Rather than giving control to an organization accountable to no one, the Handshake community’s goal is that the file is governed and distributed by the Handshake blockchain itself.

Meanwhile, “ENS focuses first and foremost on providing decentralised, trustworthy name resolution for web3 resources such as blockchain addresses and distributed content.” [1]

These are substantially different goals, and by no means are they inherently competing with each other. We hope this opens a dialogue between the Handshake community and ENS team.

Centralization
The foundation of every system is the flow of information throughout the system. Controlling information flow allows you to control the system. For that reason, Handshake is entirely focused on ensuring that domain ownership, the most fundamental resource on the Internet, is managed by its owner and its owner alone. This is a radical departure from the current Internet, where domain ownership at the root is managed by ICANN.

ENS is more concerned with providing tooling for web3 resources than allowing for permissionless ownership of domains. Similar to ICANN, the ENS root is managed by keyholders that have full control over the root, and can take domains at any point. Again, from the ENS docs, “[...] keyholders can replace the contracts that govern issuing and managing domains (on .eth or any other top-level domain), giving them ultimate control over the structure of the ENS system and the names registered in it.” [2]

Payments
When getting a name via a Handshake auction, the $HNS you spend on that name is burned, meaning it doesn't go to anyone. $ETH spent on an ENS domain goes directly to a multisig wallet controlled by their group of 7 keyholders.

When you purchase a name on Handshake, the money you spend vanishes, creating a deflationary effect, driving the price of $HNS up, and supporting the community members that are currently holding the token.

When you purchase a name on ENS, you’re sending money directly to a wallet controlled by a small group of people who are able to spend that money at their discretion.

Blockchain Development
When you transact on ENS, you’re competing with everyone else using Ethereum. At the time of writing, you’d have to pay $210 just to be able to submit your request to purchase a domain to the Ethereum blockchain, on top of the price of the domain itself. This is one of many issues that arise when you use a multi-purpose blockchain like Ethereum to solve a specific problem like DNS resolution.

The beauty of the Handshake blockchain is that it has one job, and one job only: to replace the root zone file currently controlled by ICANN. The database used by Handshake, the Urkel Tree, was uniquely chosen for its ability to handle DNS search, and because of the explicit limitations that Ethereum’s Merkle Patricia Tree presented [3]. This is just one of the many considerations made when designing the Handshake blockchain that make it more suitable for naming than a generalized blockchain. Beyond that, it ships with a lightweight resolver that can be run by, and embedded into nearly any app or device.

Collisions
A name collision occurs when the same name is used to refer to different things in different namespaces. Handshake and ENS alike are highly incentivized to minimize collisions in the name of increasing adoption.

With the existing namespace, Handshake is fully compatible. As our current namespace extends, Handshake allows it to be done in a fully decentralized way.

Handshake was designed to reduce as many name collisions as possible with the present-day Internet. With browser adoption of Handshake on the horizon, it’s possible for a near seamless transition for casual Internet users, while still making millions of new names available. This does not mean that there will never be name collisions. While ICANN’s gTLD program is still a few years out, there will likely be TLD name collisions in the future if ICANN issues new TLDs.

ICANN historically has only issued a maximum of 500 new TLDs per year. In contrast, 500k TLDs were registered on Handshake in the first year, and the registration growth has been accelerating. This means that only a small percentage of Handshake TLDs (< 0.1%) will ever conflict with future ICANN TLDs.

Regardless of the number of conflicts, Handshake’s ultimate goal is to maintain compatibility with the existing internet namespace while becoming the authoritative namespace of the internet of tomorrow.

ENS does not expand upon the existing namespace outside of the .eth TLD. The ENS team’s goal is to reduce collisions at all costs (although unlikely, the .eth TLD itself is reserved by ICANN for the country of Ethiopia, and could present conflicts in the future).

It is for this reason that ENS only makes secondary domains available to their users. The exception to this is if you are already an ICANN TLD owner. For that reason, ENS’s vision represents less of an overhaul of the current Internet governance, and more of a technical shift in how domain names are implemented. It is inherently tied to how domain name ownership is currently governed on the Internet.

Handshake enables anyone to become their own TLD owner, and compete with the monopolies that have gatekept ownership on the Internet via a $185k application fee.

Why the root zone?
With that said, the question still remains: why did Handshake decide to focus on decentralizing the root zone file itself when it could have simply created a decentralized TLD, and provided secondary domains under that?

The creators of Handshake spoke at HandyCon, the first Handshake conference, and answered this question directly. You can find their answer here [4], or continue reading for a summary of their response.

Using a dedicated TLD to put your new namespace under - similar to how ENS is using .eth - does seem a lot nicer at first. You don’t have to worry about name collisions, or about conflicting with the current powers that be.

However, if your goal is to create a more secure Internet, one that reduces the web’s reliance on Certificate Authorities, and actually helps fight censorship on the web, you’re going to need a decentralized way to track domain ownership.

Whenever you request a domain by typing in your URL bar, and pressing enter, a symphony begins. Your browser parses the domain before realizing you’re making a DNS request. It then reaches out to your modem which traverses the database of domains it has cached. If it can’t find the IP address of the domain you’re looking for there, your request makes its way through your ISP, and beyond.

The DNS software used by all of these systems is complex, but it works well. However, trying to create secure sites that don’t rely on Certificate Authorities underneath another TLD is incompatible with these systems. If you wanted to create a secure root underneath a TLD, SSL certificates, load balancers, reverse proxies, and all the other billions of applications and protocols that interact with DNS would need to be rewritten. Handshake allows us to achieve a decentralized root without changing the way any of this supporting infrastructure functions.

And that’s because we don’t need to change it. It’s not until your request gets all the way to the top, to the root zone file itself, that there’s an issue. Control of that root zone file is currently held by ICANN. Similarly, control of ENS’s root zone file is held by a group of 7 people chosen by their creators.

This is the only part of the whole system that Handshake seeks to change. Instead of telling your computer to reference the list that can be edited by ICANN, or by ENS’s keyholders at any time, it tells your computer to look at the immutable root zone file managed by the Handshake blockchain.

As existing domain owners join Handshake, that new root zone file should include the exact same information that the current one does. It will immutably log who owns each of the 1503 TLDs currently controlled by ICANN, just as ICANN intends. It will then include information about who owns all of the new TLDs that ICANN has not yet created that already have an owner on Handshake. And to promote a smoother transition to this new Internet, when Handshake was created, the TLD equivalents of the top 100,000 website domains were set aside for their owners to claim.

This was all done so that the space outside the reserved names, the hundreds of millions of TLDs that ICANN charges $185k to apply for ownership of, can be made available to anyone regardless of financial status. ENS chooses to only let users acquire names that they already own within the ICANN system, or names under the TLDs that they have control over.

Conclusion
All in all, these two projects envision an Internet with privacy at its core. Both want to see the power of individuals increase relative to the existing monopolies that control the Internet. We just have different approaches to how to get there, and have set up different levels of security to ensure users are protected from centralized control along the way.

With Handshake, we have the opportunity to flip a single switch, to simply tell computers to reference Handshake’s root zone file instead of ICANN’s, in order to achieve an Internet that places privacy at its core. Everything we do is an attempt to make this vision a reality.

We hope this helps paint a picture of our vision for Handshake, and addresses the concerns brought up by the ENS team. We also hope this accurately represents their project, and intentions. We look forward to seeing what the future of the decentralized web has in store, and welcome collaboration with ENS, and any other naming projects along the way.

References
[1]