Thoughts on Handshake Usage


#1

How do we expect Handshake to work?

Answering this question requires a lot of speculation, but I think that exploring all of the possible futures is a good idea. See the whitepaper to get up to speed: https://handshake.org/files/handshake.txt

Terms:

Top Level Domain (tld) - .foo

Domain - bar.foo

Subdomain - baz.bar.foo

Name - general name for a tld and or its domains/subdomains

Handshake is trying to solve a fundamentally different problem than Bitcoin, so scaling to Visa+ levels of transactions per second isn’t necessarily the goal. An overview of Handshake and its goal:

Handshake is a decentralized, permissionless naming protocol compatible with DNS where every peer is validating and in charge of managing the root zone with the goal of creating an alternative to existing Certificate Authorities. Its purpose is not to replace the DNS protocol, but to replace the root zone file and the root servers with a public commons.

The Handshake protocol maintains the root zone file in a decentralized manner, making the root zone uncensorable, permissionless, and free of gatekeepers.

source handshake.org

But then again, many DNS records are updated per day, so many transactions per second could be a desirable property. It would be nice to have more nuanced data to dive in deeper to, but that could be for another post.

https://zonefiles.io/ has some insight into the number of DNS records that get updated per day. It seems like about 100K to 150K domains are updated per 24 hours. Its not the best proxy because there are a limited number of TLDs in the traditional DNS system and the “medium of action” differs between the two systems. Users of the traditional DNS system are used to registering domain names on top level domains. With Handshake, users operate on top level domains. For much of the population, it would feel strange to go to a website that was hosted on a TLD. Imagine telling someone to go to foo. Foo what?

So will people using Handshake host sites at the top level domains, or will people create NS records that point to DNS nameservers that they run themselves, so that they can create a UX that users already are familiar with? ie visiting sites based on domains. This would greatly reduce the necessary transaction throughput on the network, since people would not need to submit new transactions to update their top level domain records as often. One could argue that this is not properly decentralized. Do normal domain names need to be decentralized too? It seems like an appealing problem to work on. But is decentralization even the right word/goal at this layer of abstraction?

Its not clear if Handshake will even be used like the traditional DNS system. A notable difference (from the whitepaper):

The resolution to the trilemma, Zooko’s Triangle, is between the relationship
with the name and the cryptographic identity of the owner. By making the owner
of the name a cryptographic key, one can create a certificate chain of the owner
down to the key by creating a signature signed by that owner’s key (a chain of
custody). This is not possible under the current system as the current owner of
the name is not owned by a cryptographic key, but rather trusted records held by
custodians with non-cryptographic records of named owners, e.g. the TLD “.com”
is held by Verisign.

This hints that there could be additional usecases of Handshake DNS records that don’t make sense in the traditional DNS system because the TLD owner has an ECC keypair that can be leveraged in other protocols/applications. Trusting self signed certificates is an application here. In general, a more programmable chain of trust sounds like an interesting tool. Is it possible to construct higher level abstractions to create “layer 2” abstractions? This could be the basis for decentralized domains/subdomains.

Additional and scattered thoughts to be explored in the future:

  • It no longer makes sense that self signed x509 certs should not be trusted. The signature could be verified against the public key of the name holder and the requested x509 certificate

  • The auction system releases top level domains on a weekly basis. This ought to protect the system from sorts of market implosions. Mass FOMO, liquidity squeeze, etc

  • How will fungibility impact the prices of names? The paper claims:

    • Due to the fact that the covenant behavior is only prescribed at the consensus level, this construction should be resistant to fungibility attacks in comparison to other covenants proposals.
  • What sorts of insights can come from studying the transaction graph?

  • Can a DAO run a top level domain?