The Case for Handshake
A Compelling Bid to Decentralize Domain Names
The idea of replacing Certificate Authorities (CAs) with a blockchain solution has been around since the early days of bitcoin. After all, the Domain Name System (DNS) is essentially a protocol for maintaining a secure, distributed list of which URLs point to which IP addresses. And what is a blockchain but a more-secure, distributed way of maintaining a linked list?
It might seem (at first glance) like replacing the backbone of the internet would require major surgery. But it doesn’t, really: it could be surprisingly seamless, and the benefits would be considerable. If the antiquated CA system were supplanted by a secure, performant blockchain, the internet’s resiliency to both attack and censorship would take a major leap forward.
Various blockchain projects, such as Namecoin (which is still under active development), have tried to solve this problem, and have encountered instructive difficulties. Today, some of the best minds in the space have learned from those early missteps, and the most promising of the current efforts is Handshake.
In this piece we will introduce Handshake and explain why we believe in its potential to learn from the mistakes made by previous similar efforts, and finally deliver on a decentralized naming system for the internet.
Why Does Handshake Make Sense?
What Is It?
Handshake is public blockchain that will serve as a global list of top-level domain names. By pointing your browser to resolve requests via the Handshake network instead of at your local DNS resolving server, you’ll essentially be looking up websites’ IP addresses on the Handshake blockchain, instead of those maintained on DNS resolvers that are centralized.
Does that mean that NYTimes.com will direct you to some squatter’s scam site? No. Handshake works seamlessly with the existing DNS system. The domain names of the top 100,000 websites on the internet are being set aside for their legitimate owners to claim on Handshake [3]. Therefore, major websites will, in many cases, seamlessly add their existing names to the Handshake network, making Handshake essentially a new road to familiar destinations. Should major websites not claim their names, their domain names on Handshake will at worst lead to blank pages, and not those of scammers.
But Handshake will open up a world of new possibilities. For example, anyone will be able to register new top-level domains (TLDs), exploding the limited universe of .com, .org, .io, and the like. For example, instead of buying “mysurname.com”, I could simply forget about the .com and buy the TLD “mysurname” by itself. If I had a popular surname, I could then sell sub-domain access to it: “john.mysurname”.
The possibilities are endless — this is part of the fun. Handshake enables us to not only decentralize access to DNS resolution to improve upon internet censorship, but it makes the internet fun, and unique again. Which we believe is a key factor in the growth and adoption of any new novel technology: making it fun and inviting for everyone.
Why Do We Need It?
It’s easy to suppose that DNS isn’t broken, so we needn’t fix it. But it is more broken than most people realize; many assume that there is currently no need to fix something they don’t immediately perceive to be broken. However, DNS is riddled with a set of critical vulnerabilities that Handshake aims to solve.
A fundamental weakness in the current system is that, in order to trust any website, we must also trust the Certificate Authority that has issued the TLS or SSL certificate that notifies our browser the website is trustworthy (pay attention the little green lock to the left of the URL on this website).
These CA entities (GoDaddy, Globalsign, etc.) are very fallible, as shown by the 2011 attack on a Dutch CA, DigiNotar. When an attacker gained access to DigiNotar’s systems, fake certificates were issued, allowing the attacker to impersonate websites including Google, Yahoo, Mozilla, and The Tor Project on victims’ browsers. The targets of that attack were located in Iran, and the identity of the attacker remains unknown. But this compromise to the security of the internet was so fundamental that it should give all of us pause, and force us to reconsider some of the vital infrastructure that the internet depends on everyday.
Handshake domain names are secured by the Handshake blockchain itself, not by a centralized organization or the government. The owners of Handshake domain names are not people and companies with their names on registrars’ spreadsheets, but simply cryptographic public addresses. This eliminates failure points and fundamentally upgrades the security of the DNS architecture, making it more resilient.
Security & Usability
Previous attempts to resolve names through a blockchain, such as Namecoin, Ethereum’s ENS, and Blockstack (more on those, here), have encountered difficulties in striking a balance between the competing values of security, usability, and centralization. We believe Handshake has done a great job of balancing these values by building different “security modes” suitable for different applications.
Full Nodes
Let’s unpack that concept of “security modes” further. The most secure possible way to resolve names is by running a full node on the Handshake blockchain (HSD, a fork of bcoin written in node.js). But this is resource intensive and not feasible for normal users. Mostly developers, miners, and service providers will need to maintain a full database sync of the entire HNS chain. While this is the most secure way to interact with the handshake blockchain, it is not the only way.
Steps for running a full node. See more in-depth installation instructions here.
Cloning
$ git clone https://github.com/handshake-org/hsd.gitInstallation
$ cd hsd$ npm install$ ./bin/hsd
Light Client Resolvers
The next highest “security mode,” SPV, (often referred to as a “light node” or “light client”) allows users who install an SPV resolver to enjoy almost the same security level as a full node, with a tiny fraction of the computational and storage overhead. SPV stands for “Simple Payment Verification”, and is a way for an individual to resolve names on the Handshake blockchain without having to download the blockchain’s full state (i.e. everyday users). This is how most people will access Handshake via their favorite browser.
Run a Light Client Resolver (HNSD)
For more platform specific instructions, visit GitHub.
Cloning
$ git clone https://github.com/handshake-org/hnsd$ cd hnsd
Installation
$ ./autogen.sh && ./configure && make$ echo ‘nameserver 127.0.0.1’ | sudo tee /etc/resolv.conf > /dev/null$ sudo setcap ‘cap_net_bind_service=+ep’ /path/to/hnsd$ ./hnsd — pool-size=1 — rs-host=127.0.0.1:53
Integration Library & More
That is not the only way users can interface with HNS resolvers and the network. Handshake domains can also be accessed via an integration library called libhns (which is a modified fork of c-ares, a C library for asynchronous DNS requests); this lets users access it without installing or reconfiguring anything at all. While the integration library relies on authenticated resolvers, and therefore lacks the full security and decentralization benefits of the other methods, it is still arguably more secure than the legacy system.
And finally, the last way you can interact with the Handshake blockchain is by changing your local resolv.conf file (settings for your system’s default DNS server) to point at other public Handshake resolvers. At this point you are giving your security up to others in the network and leaving them to resolve your names for you, instead of running a resolver locally. Although this works, it’s the least secure method due to your dependence on other nodes to process those requests.
Additionally, if all of the above are still too technical, the soon-to-launch firm Namebase has created a Google Chrome extension that allows your browser to resolve HNS names for you (which is very akin to MetaMask if you’re familiar with the Ethereum ecosystem). You can test that out, here.
Privacy
In Handshake, the P2P layer used to communicate with peers and propagate transactions is end-to-end encrypted by default [3]. Handshake has implemented a Noise Protocol, similar to the one used by the Lightning Network’s LND. If you find yourself having someone else resolve your names on your behalf, that peer will only be able to see a hash of the HNS name being resolved.
Your privacy is important, especially when traversing the decentralized web; Handshake has taken many steps technically to ensure those who utilize HNS can maintain the utmost privacy possible. They also have plans in the works to improve privacy going forward (See: Zone Replication and DNSCurve) that could enable peers in the network to act as “proxies”, resolving the requests for you, providing you even more privacy.
Further plans and thoughts on how the core contributors are potentially seeking to improve privacy — that fall outside the scope of this post — can be found in the paper.
Adoption
As detailed above, Handshake enables access to existing top-level domains and integrates seamlessly with the existing DNS system. Thus, resolving domains through Handshake will not be mutually exclusive with accessing the internet as we do now. New or reconfigured browsers will enable a seamless, even invisible transition for casual users. Therefore, Handshake will expand the landscape by opening up an indefinite number of new top level domains, while offering more secure access to existing websites.
That initial and continued adoption will be driven by the following factors:
- Software developers building accessibility tools and robust library integrations
- Users desiring superior security and ability to circumvent censorship
- Businesses or content providers building compelling content in the domain space looking to be more unique and experimental
The actual question is whether these factors will outweigh the forces of inertia well enough to allow Handshake to garner the adoption necessary for this alternative, but compatible system to proliferate. We believe that they will, in the medium-to-long term, thanks in part to the strength of the security proposition and the embedded stakeholder incentives (detailed in Part 2, below).
Auctions
All Handshake domains will be made available in weekly Vickrey auctions, occurring for the first year after launch, with certain TLDs becoming available only after specific block-heights (the HNS blockchain when queried for a specific name will inform you when the bidding period will begin for your particular name). These auctions are conducted with HNS, and facilitated through on-chain, smart-contract-like covenants. These can be participated in through a command line interface or through a GUI such as Namebase.io.
Registrations
Once a user wants to register a name on HNS, they initialize the start of a bid by submitting a transaction to the auction covenant, which starts the “bidding period” (which a user needs HNS in order to facilitate).
Once this period has passed, the “Reveal Period” begins, anyone that submitted a bid on that name will then need to “REVEAL” their bid by revealing the full pre-image of the bid to the covenant.
Finally once all bids are revealed, the winner of the auction can then use their reveal output to call the REGISTER function of the covenant contract.
Renewals
Renewals are another function of the HNS auction covenant. Once you have registered your name on Handshake, you will need to renew it regularly. The way you do that is by calling the “UPDATE” covenant action. However, in order to prevent people gaming renewals, you have to submit a “block hash” in order to reset the renewal timer for your Handshake name. This aids to ensure that whoever registered those names is still in control of the private keys to TRANSFER or manage their registered name accordingly.
Ever transferred a domain name? Transferring names is possible with Handshake as well. Simply call the TRANSFER function, and pass it the address for the new owner. This initializes a 48hr counter, that once it has expired, the new owner can redeem the TRANSFER and FINALIZE the output, successfully transferring that name into their ownership.
It will be interesting to see how these auctions play out. We foresee a lot of early activity as people try to claim highly desirable domains. (Again — taking existing names will not be permitted. Handshake is reserving the Alexa top 100,000 domains to be claimed by their current owners.)
Because Handshake is opening up an indefinite number of new root level domains, thus exploding the supply of attractive domains, it is hard to say how much value domain squatters will capture — this is very much uncharted territory. We believe, however, that most of the value Handshake creates will emerge in the long term, as people begin to appreciate its value as a public commons. Nonetheless, if Handshake’s larger vision plays out, those who bid smartly on domains in the early days will probably do well as the popularity of this alternative system continues to grow in adoption.
This leads us to Handshake’s stakeholder incentive model.
Handshake’s Cryptoeconomic Experiment
FOSS Incentives
Cryptoeconomics is a young field, and best practices are still being developed. But Handshake’s model of stakeholder incentivization is one of the more interesting experiments we have seen. The mainnet rollout gives an enormous number of developers a meaningful stake in growing the ecosystem.
A little background: After being incubated by the Purse.io team, Handshake raised $10.2 million from investors (including blue-chips like A16z, Founders Fund, Sequoia Capital, Greylock Partners, Polychain Capital and Pantera Capital). For their capital, the investors received 7.5% of the initial supply of HNS coins. Rather than retaining those funds to operate, however, the Handshake team will now allocate that entire USD sum to open source projects and/or nonprofits that are facilitating the growth of the network, and they’ve already actively begun disbursement of the funds.
Another 7.5% of the tokens are held by the developers who contributed pre-launch towards the completion of the system itself during its inception. But the remaining 85% of the tokens will be strategically allocated to stakeholders whose alignment with Handshake will be just as important to its long-term success.
Specifically:
- 65% of the HNS will be given en masse, without obligation, to qualified open source developers (who can register and sign-up, here).
- 7.5% to ICANN, CAs and other strategically important projects (such as the browser developer Brave Software, Inc.).
- 7.5% to preexisting domain name holders.
- 5% to selected open source projects and/or nonprofits in conjunction with the aforementioned USD grants.
In short, Handshake is giving a meaningful no-strings-attached stake to just about anyone and everyone whose buy-in could make or break the project. That means a lot of influential people are going to give Handshake a serious look.
Even if the service becomes popular, that doesn’t tell us everything we need to know. The value of HNS tokens will ultimately be a function of the demand to use them — and this need not necessarily track the popularity of Handshake. Let’s take a look at the likely drivers of that demand.
DNS Market Size
The domain name market is notoriously hard to size. But across all top level domains, new registrations are currently occurring at a rate of 6–8 million names per year.[1] That means that every year, domain customers are generating 6–8 million new income streams of roughly $10/domain per annum. [2] (This number would be higher if more and better names were available, as they will be on Handshake.) And the secondary market may represent an even larger portion of the yearly expenditure on domain names given their additional liquidity.
Thus, it is safe to say that Handshake is targeting a large pie. If the incentivized stakeholders in the project — ICANN, Mozilla, GoDaddy, Brave, etc., plus new businesses springing up around Handshake such as Namebase.io — manage to drive substantial adoption, it is not hard to envision HNS coins substantiating and exceeding their initial valuation of $136 million.
Moreover, the demand for names themselves is likely to grow if Handshake is widely adopted, because it will open up more attractive options — breaking the hegemony of the traditional TLDs. New top level domains have proven to be a huge hit — just look at the growing popularity of country code TLDs:
But let’s take a step back for a second. If Handshake is wildly successful, where will the created value reside? You might argue that the equity in the network will reside predominantly in the value of the HNS domain names. Thus, if HNS is to retain its value, its value must be correlated to the value of the sum of those names. If network users decide they would rather hold names than coins, there might be a problem.
We believe the value of HNS will, at least for the first year or so of the network’s existence, remain closely correlated to the value of the Handshake namespace. To explain why, let’s take inventory of the various uses of HNS:
- Bidding on name auctions
- Paying network and renewal fees
- Payment for person-to-person name transactions
- Experimentation with the HNS blockchain as developers build novel services on top
- Holding for future speculative value and gain
These five uses are, in our view, ordered from the most important driver of value to the least. Speculation does not drive fundamental value; and since transfers of existing domains need not occur in HNS (people can pay each other off-chain), they will not drive unique demand for HNS. And the size and scope of the network fees is hard to estimate at this early stage. Therefore, the clearest driver of the value of HNS is demand to use it in domain auctions, as per its intended utility.
Handshake has made an important decision that all HNS tokens spent in the domain auction system should be “burned.” This puts deflationary pressure on HNS prices in the open market. The size of the deflationary effect will be proportional to the amount of HNS being spent in auctions, because every HNS spent to the auction covenant is an HNS burned. Therefore, early auction bidders might think twice before spending too freely. Conversely, those who sit out the early auctions will not be at too great a disadvantage, and it would be sensible to observe the markets and see how things evolve (it will likely be erratic for a short while, as expected in a new market with limited liquidity, be wary). This dynamic should encourage HNS holders to strike a reasonable balance between buying domains and holding on to the tokens. It also conforms with current thinking that coin-supply “sinks” are necessary for medium-of-exchange tokens to have predictable value.
After the best domain names have been purchased during the auctions in Handshake’s first year, the amount of valuable “stuff” that can only be acquired with HNS will have decreased. Handshake will still, however, have a long tail of unclaimed names. HNS will still be necessary to buy these names, as well as for network and renewal fees. Thus, while HNS’s value beyond the year mark is slightly harder to predict, it should remain correlated to the value of the Handshake namespace as a whole, as well as any novel services built on top in the future via Plasma Child Zones [3] and whatever else may lie in the imagination of impending developers.
Namespace Expansion
One of the most important worries is that Handshake will inaugurate a new round of domain-squatting. If squatting becomes a real or perceived problem early on, it could hinder adoption.
Handshake has therefore taken meaningful steps to mitigate squatting. These include:
- Distributing HNS to hundreds of thousands of FOSS developers in small amounts, so that domain auctions are unlikely to be dominated by whales; and
- Releasing sets of names in weekly auctions during the first year, rather than all at once, so that the most desirable names won’t all be snapped up right after launch.
Despite these mitigating steps, a certain degree of squatting is bound to happen. There are two big reasons we don’t think it will spoil the ecosystem.
First, the existing DNS system is a squatter’s paradise. Everyone doing new business on the internet must squeeze into tiny cracks of unoccupied namespace. And CA’s such as Verisign are exacting enormous, wasteful rents. We simply don’t have a system worth defending.
Second, and perhaps more importantly, Handshake is radically expanding the namespace. By opening up an indefinite number of new top level domains, Handshake should loosen the grip of traditional TLDs like .com, by acclimating users to the idea of pointing their browsers at “anything.whatever”. The expanded possibilities will reduce the cachet of any particular top level domain, making it harder for bad actors to accrue market power (further disincentivizing squatting, as no one will know which names will be most valuable). This higher degree of extensibility might likewise bring the domain name system a few steps closer to the ideal of a public commons. We like it and we think users will too.
Conclusion
For the reasons outlined in Part 1, Handshake makes sense and adds real long-term economic value. But there are a lot of brilliant projects out there that land with a thud and/or could get usurped by a copycat.
However, for the the reasons outlined Part 2, we don’t believe Handshake will end up like its predecessors. By (a) giving up more than the usual amount of control, and (b) intelligently incentivizing stakeholders, Handshake has given itself a better-than-usual chance at being one of those brilliant projects that fulfills its potential.
Many of the internet’s inherent weaknesses have been revealed over the years, with both market and government powers gradually eroding the web that many of us grew up on. We’re excited to watch the growth of Handshake in the coming years, and hope that it will mobilize more developers to help make the internet into what many of the early pioneers thought it could be.
We look forward to supporting the teams and entrepreneurs that see this ripe opportunity to bring the benefits of a more private and secure internet for all — maintaining it for the generations of the future. If you are interested, we hope you’ll reach out.
By:
Cryptoeconomic Advisor, Amentum: Matthew Prewitt
Twitter:@m_t_prewitt
Founding Partner & Cryptoeconomic Sys. Engineer, Amentum: Steven McKie
Twitter: @Steven_McKie
Special thanks to Alex Evans of Placeholder VC for taking the time to review this post.
References
[1] Verisign Report: https://www.verisign.com/assets/domain-name-report-Q22018.pdf
[2] E.g., https://www.namecheap.com/domains.aspx.
[3] Handshake Paper: https://handshake.org/files/handshake.txt
Honorable Mention: Though it fell outside the scope of this post, a new type of cryptographically provable key-value store was created specifically for Handshake, the Urkel Tree. It’s a base-2 merkelized trie made as an alternative to Ethereum’s base-16 trie. If you’re nerds like us, you’ll want to check it out.
Disclaimer: Amentum is an initial investor in Handshake (HNS), and plans to invest in Namebase.io as well. This piece is intended only as an expression of our thinking about the Handshake public blockchain, and should not be deemed investment advice.
Subscribe to our Newsletter to get this in your inbox:
Other Article & Resource(s):
