Everything You Didn’t Know About the Handshake Naming System
Covenants
The Handshake blockchain does more than keep the history of domain name ownership; it implements an auction system in-protocol and on-chain, by way of prescribed “smart contracts”, called covenants, which were first described by Malte Möser, Ittay Eyal, and Emin Gün Sirer.
These covenants allow for dynamic consensus-level behavior normally absent in highly-constrained UTXO-based state machines like Bitcoin. The desire for covenant-like behavior was what spawned the birth of the application platform experiment better known as
“Using our generic consensus-level covenant system, we are able to implement almost any kind of smart contract on the blockchain layer.”
How the Auction System Works
The auction system is implemented as a consensus-level covenant, broken down into various actions described as covenant_type on the output layer (as low-level as it gets). Handshake implements a Vickrey auction, a second-price auction named after its inventor, William Vickrey. We won’t go into the decision process that led to setting up the auction structure as a Vickrey auction, but we will go into the process illustrating how a name is procured on Handshake.
To illustrate, when you want to bid on a name, you’d use the bid covenant type. You’d send money into a covenant, and the money that you bid is locked up until the auction is over. These bids, mind you, are blind bids. Meaning, you have an actual bid (e.g. 5 HNS), but you may want to produce a lockup value of 10 HNS, which obfuscates your true bid value.
What the convenant does is it takes your actual bid, concatenates it with some nonce, hashes it, and provides you with that hash. After a weeklong revealperiod, you reveal the nonce you used, which reveals your actual bid of 5 HNS. After you reveal, you withdraw 5 HNS out of the convenant as change.
(lockup value) — (actual bid)= your change
Then, your 5 HNS remains locked up for a 2 week period until the auction is closed. When the auction ends, the winner is chosen, and the losers get their money back — losers are allowed to exit the covenant.
The winner’s money, however — remember, winners pay the second highest bid — is sent to another covenant path, the register covenant. The registercovenant is designed for maintaining and updating names. All money that gets sent to that path could never exit the covenant, which means that every winners’ coins get effectively burned.
Revocation
One such covenant_type I take particular interest in is that with the REVOKEfunctionality. Similar to the function of the exit game in Plasma, revocation on Handshake is the last-resort option that allows the rightful owner of a name to revoke, or challenge, a name transfer in case the owner ever loses his or her keys. Having this option renders the incentive to steal names completely null.
DNSSEC “Ownership Proofs” for Bootstrapping the Network
Another flaw in the design of Handshake’s predecessors that will prove to be fatal is in neglecting to consider existing nameholders. If I am Microsoft and I have invested substantial amounts of capital into my brand whose value is encapsulated in my domain name, and here comes this new proposed DNS system that tells me that I don’t own this name anymore in their system — why would I ever migrate over and use that system?
With that in mind, Handshake pre-reserves the Alexa top 100,000 names claimable — within a “Sunrise period”, or a 4-year window from the date of its mainnet launch — by the rightful owners of those names. To claim their names, the owners simply produce a very specific DNSSEC proof which the Handshake protocol has cleverly repurposed to be used as secure proofs of name ownership. But here’s the thing — they’re doing this claims distribution permissionlessly, whereby the blockchain — not anybody involved with the project — gives the names to their rightful owners.
To implement this for a permissionless distribution, Brain tells us:
“It’s tricky to do it cryptographically because you don’t have all those peoples’ keys. And not very many people actually have DNSSEC set up. We were looking at DNSSEC and we realized you could actually use it for proofs of ownership — that’s not what they’re intended for. They’re intended for ensuring you’re not being man-in-the-middled, that somebody’s not changing data while the data is in-flight. But you could use it to prove ownership using a much much stricter subset of DNSSEC proofs that we’re dubbing “DNSSEC ownership proofs”.
What we do is, since most people don’t have DNSSEC set up, is we take ICANN’s existing key signing keys (KSKs). They have two of them: one they generated in 2010, and they’re about to roll over to a new key that they generated last year (2017). Basically, having these two RSA keys hard-coded into consensus rules allows anyone in the Alexa top 100,000 in the existing root zone to prove that they own a name, even if they don’t have DNSSEC currently set up — they can set it up later. The blockchain will validate the DNSSEC trust chain, starting from ICANN’s KSKs.
This was tricky to implement because 1) DNSSEC is tricky and there’s lots of strange edge cases, which is why we’re only using a small subset of DNSSEC for ownership proofs, and 2) because most of the keys are RSA keys. RSA keys are extremely large and signatures are just as large as the keys. Every cryptographic algorithm — ECDSA included — have always had really strange edge cases that you need to be aware of. Also, for RSA in particular, there are DoS vectors because keys can be of a different size. So it required us to put a lot of effort into researching DoS limits for RSA keys and edge cases with PKCS1 v1.5 signatures. We discovered edge cases in RSA signatures that I don’t think have yet been discovered on DNSSEC. I think we discovered some new ones while we were sprucing it up for a consensus protocol. It’s not mentioned in any RFCs. Even though DNSSEC has been thoroughly specified over the course of a decade in so many different RFCs, none of them mentioned the edge cases that we found. It makes the point that specifying a consensus protocol doesn’t really add much because there’s always going to be those edge cases.”
To further incentivize existing nameholders, the Handshake blockchain gives nameholders a coin reward if they redeem their names.
Here is where the use of VCs and funds come in handy. Where the ICO model potentially obsoletes them, the abundance model assigns a very relevant function for them: give these newly created coins a valuation backed by your investment amount. With their investment backing, the coins hold inherent value, even before they’re released into the free market for price discovery. At the time of writing, the VCs valuated one HNS token to be worth $0.10.
- A total of 7.5% of the 1.36 billion HNS coins are pre-allocated to existing nameholders, provided that they produce a sufficiently secure DNSSEC proof of ownership.
- Next, a total of 2.5% of the 1.36 billion coins will go to TLD owners, provided that they claim their TLDs.
The rest, left unclaimed, get burned after the Sunrise period is over.
Name Rollout Interval
People can open an auction for any name as long as it’s not on the pre-reserved name list and is within the rollout interval. The rollout interval is a weekly rollout of names that become available for bidding. Over the course of one year, all the names will be available for bidding.
To determine whether a name is within the rollout interval, similar to how ENS does it, the Handshake protocol hashes the name you want to open, runs SHA3 over the string, modulo the hash by 52, giving you the number of a specific week, multiplies that number by the average number of blocks per week, then you have the block height that your name will roll out on. Done this way, the rollout interval is deterministically random and uniformly distributed for all the names that are available.