Skip to content

Instantly share code, notes, and snippets.

@tynes
Created February 25, 2020 19:26
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tynes/b7368c34a6471427132e35b093b5635e to your computer and use it in GitHub Desktop.
Save tynes/b7368c34a6471427132e35b093b5635e to your computer and use it in GitHub Desktop.
hsd ENS Support

Handshake can be used to resolve names with a sliding scale of trust assumptions. In general, the more trust that the user places in the system, the better user experience. The easiest way to resolve Handshake names involves configuring DNS settings and not worrying at all about blockchain state. This means that the user is trusting the DNS service provider to properly validate all state transitions and relying on traditional means of DNS security. Running a light client as a DNS server removes the trust assumption that the name state is coming from the heaviest chain. The light client will sync the headers (technically a subset of the header, designed specifically to be lightweight), verify the proof of work is correct and ask for urkel proofs over the p2p network to validate against the tree root contained in the block header. The p2p connections are optionally encrypted with brontide (BOLT #8) and use an elligator-squared construction to obsfucate public key transmission from passive adversaries. This allows for plausible deniability when resolving names over the Handshake network. The security model can be improved if full nodes can gossip an urkel multiproof along with the blockheader such that the light client can validate all state transitions. Running a full node will allow for the validation of all state transitions as all blocks are downloaded and validated. This is more resource intensive but design decisions like a 10 minute blocktime helpt to keep the costs relatively low. The full node runs two DNS resolvers: an authoritative server over the Handshake root zone and a recursive resolver for everything else. If a user sends DNS requests to the recursive resolver, it allows Handshake to operate as a drop in extension to the current system. Depending on the top level domain in the question, the recursive resolver will query the ICANN system or the blockchain database. It is possible to build in custom resolvers for other sorts of names here. If a request to .eth is received, the question can be proxied to an Ethereum node to resolve the ENS name and return the data in DNS wire format. This would enable users to resolve all of the Handshake names, all of the ICANN names and all of the ENS names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment