Hyperzone HIP-5 Protocol for Trustless SLDs and Decentralized Zone Storage

Usage

➜ cd /path/to/hsd
➜ npm install hip5-hyperzone

To run a node with the extension, execute:

➜ NODE_PRESERVE_SYMLINKS=1 hsd --plugins hip5-hyperzone

To test the extension, run:

➜ NODE_PATH=node_modules ./node_modules/hip5-hyperzone/test.sh

Introduction

Handshake provides a trustless, open, and globally consistent namespace that operates as a root DNS zone, but it is not intended to do more than that. As a result, there remains a gap between Handshake and other blockchain-based naming systems.

Here we propose two HIP-5 protocols that glue together to fill the gap between Handshake and other naming systems, such as ENS for which SLDs are trustless and records are uncensorable, while eliminating drawbacks such as blockchain costs and slow update times of storing records on chain.

1. a protocol for decentralized authoritative record storage and resolution that preserves the main advantage to storing records on-chain and eliminates the main disadvantage, (near) uncensorability and slow TTL respectively.
2. a protocol for aliasing SLDs to TLDs dynamically to enable trustless SLDs on the Handshake blockchain

Handshake TLD owners can use this protocol to offer SLDs for registration via Vickrey auctions, and hsd nodes using this protocol can resolve records from an eventually consistent, cryptographically verifiable, distributed zone store with greater censorship resistance than what can be achieved with centralized nameservers.

A robust implementation of a protocol along these lines might facilitate wider adoption of Handshake and its positioning as an essential piece of infrastructure for a more decentralized internet.

Decentralized Zone Storage

The main requirements for decentralized zone storage are: a public-key addressable data structure storing DNS records that is verifiably written by the owner of the public key and sparsely replicable, so that resolvers don't need to have the full data structure to locate (e.g. via the public key over a DHT or by querying connected protocol-capable hsd nodes) and verify individual records.

The hypercore protocol is one candidate distributed data structure with satisfactory properties, on top of which zone storage can be written. Hyperzone is an experimental implementation of such a data structure that can be replicated with peers discovered via a DHT using the Replicator library. Other distributed zone protocols might choose to use a different data structure and protocol.

If a Handshake TLD {tld} sets a HIP-5 NS record "{public-key}._hyperzone", then any HIP-5 extension implementing the hyperzone protocol must upon receiving queries:

1. Locate a peer in possession of a replica of the hyperzone addressed by the public key {public-key}.
2. Verify and resolve records from that hyperzone.
3. Listen for peers with updates to the hyperzone.
4. Cache and replicate the hyperzone with peers.

We will leave the particular discovery mechanisms, caching strategies, and replication strategies used to individual implementations. Particular nodes should probably have control over some of these strategies, and experimentation may be required to optimize zone availability while minimizing replication and networking costs.

TLD Aliases

If a Handshake TLD {tld} sets a HIP-5 NS record "{hip5data}._aliasing", then any HIP-5 extension implementing the aliasing protocol must:

1. For any SLD {label}.{tld}, compute the {alias}: the base32 encoding of the blake3 hash of {label} concatenated (as strings) with the first label of {hip5data}.
2. Forward the original DNS query for {label}.{tld} to {alias} after substituting {label}.{tld} for {alias}, then return the response after substituting {alias} for {label}.{tld}.

A TLD owner wishing to open their TLD for SLD registration should set a single HIP-5 NS record as above with a unique public key as hip5 data, then set their TLD to renew-only. They can use the public key to prove that they originally owned the TLD.

A HIP-5 extension supporting the aliasing protocol might also resolve top-level records for the TLD using the public key as a decentralized zone address, as we do in the experimental implementation discussed below. If it does, it must specify the distributed zone protocol that it is using as a sublabel, such as: {public-key}._hyper._aliasing. For this reason, only the first label of {hip5data} should be used to compute {alias}.