Handshake: Retrospective After the First Year
Roughly one year ago, we added Handshake to the core set of APIs supported by Skynet. Handshake at the time satisfied two different critical gaps in Skynet’s infrastructure. The first — and at the time the most important — was the ability to support dynamic data. Our Handshake integration pre-dates SkyDB, and when it was launched it was the only way that we could offer dynamic applications to our users. Every update required a transaction on the Handshake blockchain, but this was far preferable to being unable to update pages and applications at all.
The second critical gap was human friendly naming for Skynet files, pages, and applications. Where the first gap has been superseded by SkyDB, Handshake remains by far the best and most prolific option for human friendly naming within the Skynet ecosystem, to the point that every single serious Skynet application uses a Handshake name to identify itself. Needless to say, we’ve been very grateful for the role that Handshake has played in our ecosystem — Handshake has unquestionably had a dramatic positive impact on the overall usability of Skynet.
The Good
Handshake was very easy to integrate. We had to set up a docker container, expose a few API endpoints, figure out SSL wildcards, and then we were pretty much finished. I don’t remember at this point exactly how long all of that took, but it was definitely under a month, and perhaps even half of that time.
We also really like that Handshake is a fully independent blockchain with an independent currency. Fees are low, governance is predictable and entirely focused around the naming system, and in general its pretty easy to send coins to someone to help them buy a name.
Another thing that we really like is how lightweight the client is. Every single server on our Skynet portal runs a handshake client, and it consumes very few resources. We don’t have to stress about the burden of running a Handshake node because there essentially is no burden. A blockchain that does exactly one thing can do that thing efficiently.
Finally, the Handshake community is passionate about much of the same things that we are passionate about. This is amazing, because it means it’s very easy for us to work with them, get code merged, do joint community initiatives, and otherwise work together frequently to accomplish common goals.
The Bad
This isn’t necessarily a problem, but almost the entire Handshake ecosystem operates on top of Namebase. They are a centralized service that sells most of the domains, custodians most of the domains, and negotiates most of the transactions between users who are buying and selling domains. Namebase holds such a central part of the ecosystem because they’ve built such a convenient and user-friendly front-end for working with Handshake.
The reason this isn’t necessarily a problem is that we know how to perform nearly every major function of Namebase in a decentralized way. Perhaps the easiest thing to do would be to build a Skynet application that can manage Handshake domain custody. We would need to add an API to the Skynet portals that allow users to make Handshake transactions, and then we would need to make a web-app that can build and sign Handshake transactions which update the status of a domain.
We could extend that app to support bidding for new domains, and then we could extend it again to support buying and selling domains with untrusted parties using atomic swaps. Technically these steps are a little more challenging, but still well within reach of what we know how to build using Skynet today.
The major challenge has been finding someone who is sufficiently motivated to pursue such an app. There isn’t much financial incentive, and for the most part everybody really trusts Nambase — it’s a small, passionate team of familiar faces and it’s a group of people that have no reason at all to become bad actors. For that reason Skynet Labs — along with everyone else — has done the convenient thing and just continued to use Namebase.
The Ugly
The user experience around acquiring domains on Handshake is awful. The biggest issue is that there is a two week delay between buying a new name on Handshake and being able to use it. If you have a cool new idea for an app or domain hack, you can’t share that utility under its true name for a full two weeks, which is a substantial issue for short term projects like those built at hackathons.
It’s also a point of frustration for long term projects as well. The Skynet Labs team has had multiple instances where we’ve had to delay an announcement or use a throwaway Handshake name because it took too long to acquire the correct name. To have good UX, we really need users to be able to acquire names quickly, ideally in under an hour.
The other major problem with Handshake auctions is that they are Vickrey auctions. At a surface level, this sounds like a good thing. Vickrey auctions leverage game theory to ensure that the winner of a given auction is always the person who is willing to bid the most. While these auctions are excellent in theory, in practice most users don’t understand the game theory well enough to bid correctly, and even more importantly most users don’t understand how valuable a given name is.
The main adversary in the DNS space is scalpers — people who buy up domain names at a low price and resell them at a high price. Handshake scaplers are professionals who fully understand the game theory behind the Vickrey auctions and who also understand how valuable names are. This creates several common scenarios where scalpers end up stealing names from users and re-sell those names back to the users at 10–100x the original price. Within the Sia community, we see users lose their first name something like 80% of the time.
The core issue is that the Handshake auctions require skill to execute correctly. Users don’t have much skill, and adversaries have lots of skill. Handshake would be a lot better if it had a bidding system that assumed users were unskilled and naive, and attempted to optimize the outcome for users assuming that they made bad or uninformed decisions.
Proposed Improvements to the Domain Buying Process
The main goal of the Vickrey auction is to frustrate scalpers. At the end of the day, we want people who will actually be using the domains to pay as little as possible to acquire those domains, and we want people who are speculating on domain names to starve out. If there is a bidding war on a name, ideally that war is happening between two people who actually plan to use the name, as opposed to happening between one person who actually wants the name, and one parasite who is just looking to extract as much value as possible.
One potential method of solving this problem would be to add additional namespaces. Currently, Handshake only has the “.hns” namespace, which means there’s only a single opportunity to get the name you want, and if its a high contention name like “blockchain”, you may not be able to get it at all.
What we could do instead is have something like 30 unique namespaces, each with an exponentially growing cost. For the sake of simplicity, we’ll call them “.1”, “.2”, “.3”… etc. Buying a “.1” domain requires the purchaser to burn 1 HNS. Buying a “.2” domain requires burning 2 HNS, a “.3” requires burning 4 HNS, and so on. Buying a “.30” would require burning roughly 1 billion HNS.
This does two things. First, it gives everybody 30 distinct opportunities to buy their preferred name. More importantly though, it completely eliminates a scalper’s ability to make a profit by buying up names early. If a scalper buys the “.1” and “.2” and “.3” domains, they need to spend 7 HNS total. To make a profit, they need to sell at least one of their domains for more than 7 HNS. But the potential buyer could just buy the “.4” domain for 8 HNS, meaning that the scalper has very little room to make money.
The main game that scalpers play is a numbers game. They know that out of 100 domains that they squat, they are only likely to make a profit on 5–10 of them. In order for scalping to make sense, scalpers need to be able to make a 10–100x return on the domains they are able to sell, because they have to make back the losses on names that they fail to acquire.
By breaking up the domain space like this, we completely disrupt the business model of scalpers, and also ensure that everyone has an opportunity to get their preferred name. The result is an ecosystem with a lot less speculation, and a lot more utility for anyone who wants a nice domain name.
The Road Ahead
Despite the challenges, Skynet has overall had a very good experience with both the Handshake technology and the Handshake community. We are happy to continue supporting Handshake.
If at some point in the future a new naming system appears that is able to capture all of Handshake’s advantages while also addressing some of its shortcomings, we would like to support both Handshake and the new naming system. We would also be thrilled if Handshake decided to add additional namespaces with different auction rules that improve the overall UX of acquiring names.
Until that point, we’ll keep trucking. Handshake works well today, solves important problems in the Skynet ecosystem, and we’re happy to have them as a part of the crypto ecosystem.
