Number: HIP-000?
Title: Handshake SLDs
Type: Standards
Status: Pre-draft
Authors: Vlad Smirnov <http://smirnov/>
Created: 2021-07-30
A naive approach to second level domain management by handshake.
My only personal motivation to introducing the second level domain names to handshake is to increase the utility of HNS tokens.
However for the rest of the world, which hopefully is much less self-focused than I am there could be a lot more to it than raising the value of HNS coin.
For example of the use cases for Handshake SLDs is usernames in different services. NameBase was one of the first to use Handshake domains for blog identities.
Now I own smirnov/
handshake TLD, and I have 4 sons. What if I want to pass to my sons nikita.smirnov
, denis.smirnov
etc for their global identities? Right now its not possible. Wouldn't it be nice if one could implement a Auth2.0-like identity using handshake names and that would support both the TLDs and SLDs, and wouldn't require multi-chain intergations?
There may be many more usecases where having handshake manage SLDs is logical and natural.
Whatever the use cases, the argument of handshake creators is that handshake should remain root-zone management only. Handshake is TLD-specific. That's fine, I can live with this, however we see now the implementation of SLDs on ENS. Now me, as DNS integrator, would have to integrate both ENS (ethereum based) and Handshake (to make sure the tld is delegated to ENS) into my app.
If the trend continues, Handshake will be just a ledger of delegated TLDs to Ethereum. And pretty much all integrators will just have a coinlist-like static file of known TLDs delegated to ENS.
If that's the case, wouldn't it be easier to just move functionality of Handshake (pretty primitive I must say) to ethereum too? Ethereum is also PoW (at least at the moment), its more widely accepted. So why invent a wheel?
My motivation is to increase the variety of ways how Handshake can be used, and increase the burn of HNS, so we remove some pretty obvious inlationary characteristics of HNS coins.
At the moment there is a suggestion to delegate the DNS for SLDs to external decentralised services such as (for instance) ENS smart contract on Ethereum or any ethereum-compatible blockchain. This approach has been described in HIP-0005 by Mike Carson and Matthew Zipkin.
While this is possible, the owner of the TLD looses all control over the domain. This is the only way to guarnatee that the owners of SLDs will never loose access to their domains. This is because Ethereum smart contracts can not communicate to HNS blockchain.
Ofcourse one could setup their domains to resolve via ENS according to HIP-0005 while still keeping control of the top level domain name. But that would mean that owners of SLDs would have no guarantee that they will continue to control the DNS zones of their domains if the owner for example looses control over his domain name or sells it.
I suggest allowing the owners of TLDs to transfer their top level domains to special hns addresses that will
- leave the owner of TLD in control (for the holder to be able to transfer the domain).
- forbid the owner of the TLD to modify the NS servers to anything but the spv node. that means spv node for the NS query for TLD. shall reply with the same IP that was queried by dns server, redirecting the SLD ns requests to itself. It means the spv node must be aware of its own IP address it advertised to its DNS users.
We should add a "managed by hns" status to each domain within handshake system. When set, this status is irreversible, the current holder of the domain will never be able to modify the NS server records for the TLD, it will forever be delegated to be managed by handshake. The new owners of the top level domain will inherit this property, which is guarantee to all the owners of next level domain that their posesion will not be tampered with regardless of the ownership of the upper level domain.
When a DNS user queries an spv node it works pretty much the same way as it works now, no changes to spv interaction with user of the full node is neeeded aside the fact that it will now allow for .
simbol in the DNS queries to the spv node.
The auctions may also work in a very similar manner. There will be differences though.
- If a '.' is encontered by hsd in an auction-related actions, the fact that the owner of an upper level domain has delegated the DNS of sublevel domains to hns needs to be validated. A special action needs to be introduced that irreversibly sets a domain name (TLD or SLD, or some deeper level domain) into the "managed by hns" state.
- When setting the status of domain to "managed by hns", the owner must specify how the acquisition of sub level domains should be handled. There may be a few ways to handle it. The current action system - where domains are purchased on auction, a dutch auction.
At the moment, an auction is the only method of spawning a new toplevel domain name within handshake. However, a new owner of TLD may decide to apply a different method of the subdomain spawn. One could just set a fixed price for every subdomain, or create a dutch auction for new domain names. The new sub domain spawns may be handled differently by each owner of each TLD, however if there is a fee involved in obtaining a new sub domain name - it makes sense to let the owner of upper level domain decide what portion of this fee shall go to the owner of the upper level domain name, and what portion of its shall be burnt in the same way as it is burnt right now at the end of the actions.
This is where my self-driven motivation for raising value of HNS coin comes in, the additional level domain management will give additional utility for the coin raising the demand for the HNS and enlarging the userbase. The reselling burn will add to deflationary pressures too.
Yes, I know the deflation and tokenomics were the side effects and the necessary evil to achieve the real objectives of HNS... Not the vice versa. But listen, I am also a user of HNS, and I am only expressing MY personal motivation. It may not be accepted by community, but it would be really amazing to have all level domain NS managed by one dedicated service rather than forcing a user integrate multiple solutions and query a few differnt services in order to perform a name lookup.
Sub level domains wouldn't exist in the system if the upper level domain wasn't irreversibly marked as "managed by hns". Hence all name transfers shall be allowed even if a name contains "." separator.
Interactive and non-interactive name swaps for second level domains shall be allowed, there is no difference between second and top level domain names in that regard. If a domain name exists on the handshake you hsould be able to swap it.
Of course this is possible, you sign a zone file with your DNSSEC keys and host it somewhere that HNS resolvers can find it (DNS nameserver or HIP5 bridge like maybe to IPFS or Sia). I think if you want to formalize this proposal, you need to focus explicitly on decentrazlied, censorship-resistant subdomains enforced by consensus. In particular, enforced by the same consensus as HNS.
I've already addressed your concerns about how HIP5 threatens the existence of HNS, I think you can leave that out as well. Let's hear your technical proposal and stay focused.
This is a worthy discussion to have and I usually refer users to Brantly's article on Medium. In my opinion, the benefit of a novel blockchain is a mitigation of layer 1 risk (Ethereum miners censoring e-hns for whatever reason, gas price spikes due to uniswap activity, etc) and scaling: HNS was designed to be streamlined and be really really good at one thing only: DNS. The light client and Urkel Tree were designed explicitly for this goal and these are the reasons why HNS was not launched on the back of some other existing chain.
This can be done with a script address similar to the anyone-can-renew script used by
forever
. You can provably own the name in a script that allows TRANSFERs but not UPDATEs. Of course, there is a huge hole in this: the current TLD owner can just transfer the name out of the script to a regular address, and then send an UPDATE from that address. SLD holders will see this transaction on the blockchain and will have 2 days to complain about it.One primitive that might make this contract "smarter" is if the TLD owner using this script pre-signed a CANCEL transaction and then published it. It might include extra conditions like a time-lock or multisig component to prevent abuse, but might give the SLD holders a bit of leverage to keep the TLD owner in check. Maybe there is some construction where a TRANSFER is allowed, but only if the new owner ALSO holds the name with the same no-update script.
I'm not sure what you mean here. What do you mean by "SPV node"? This sentence seems really important to your design goal but doesn't make sense to me: A TLD owner can "modify NS servers to the spv node?" The SPV node must be aware of its own IP address? It sounds kind of like what the hsd authoritative root server does: it claims authority over the root zone, see here where the root NS generates the referal to itself and here where its own IP address (
127.0.0.1
by default) is returned as a location record.Chat with me on telegram if you're confused about what an SPV node is or maybe I can help figure out what you meant.
Funny, this actually reminds me of HIP-5, but we could register another pseudo-TLD to the list (like
_eth
) that could perhaps be_hns
! Then maybe the prefix data could be a namehash to lookup data in the urkel tree. That sort of feels like it could be a soft-fork or an application-layer protocol, but the hard part will be the auctions... I'll keep reading...We have to be very careful that we don't disrupt the DNS protocol. The dot character has a very special meaning, and recursive and authoritative resolvers respond to it in ways we can not change without breaking interoperability in a big way. The
.
symbol is already allowed in DNS queries to all DNS servers (light client, full node, recursive resolver, authoritative nameserver...)If we allow dots in names on Handshake that will be a hard fork. In addition, HNS names are limited to 63 characters. This means that if your TLD is 60 characters long, subdomains that follow your protocol will be limited to 2 characters plus a dot. If you want to double the max name length on HNS, that is a hard fork.
Implementation
Ok I'm boiling down your ideas here into a set of possible protocol changes:
HNS names (this is a hard fork):
.
) (TODO: are we gonna recurse this into 3rd level domains, etc?)HNS root authoritative name server (this is application, no protocol fork needed):
hipxxxx._hns
(wherexxxx
is the eventual HIP number of this proposal)Locking names (this is a soft fork):
One way to do this is for chain validators to check for the NS record mentioned above. It will be the exact same for all TLDs that use this protocol:
Auctioning/Buying SLDs (this could be either a soft or hard fork):
Burn (no additional protocol changes required)
The simplest way to do this is add nothing at all to the protocol except what has already been mentioned. SLD buyers would be able to OPEN regular auctions for names like
nikita.smirnov
using the existing auction and covenant system. The downside to this is that like the current auction and covenant system, the winner's coins are simply burned and the TLD owner gets nothing.Auction (hard fork)
Change the rules for the REGISTER covenant if the name contains a dot (is a dSLD according to this proposal):
value
(second highest bid) MUST be paid to the TLD owner's address (whatever address is in the output of the coin that owns the TLD) in the NEXT OUTPUT of the transaction containing the REGISTER covenant.value
to0
. (this is just a subtlety of our UTXO/NFT system and doesn't affect users).value
of the REGISTER covenant itself is then also0
.Auction (soft fork)
New covenants can be added to HNS with a soft fork: non-upgraded nodes will regard such transactions as non-standard and refuse to relay them to other peers, but will accept them in blocks. However, updating name owners and saving data into the Urkel tree are functions reserved by the existing set of covenants and non-upgraded nodes will need to be tricked using the existing covenants to achieve this. I don't even want to think about how to achieve this in detail because we're already looking at a hard fork for this proposal, but it would be something like:
Final thoughts
Think about scalability. If you follow the implementation examples I provided, the blockchain will remain hard-capped at 63,000,000 or so names and that will INCLUDE TLDs and dSLDs, because everything is on chain. If the community wants to expand this and potentially give up some scalability, that number can be increased with a hard fork. The actual limit is enforced by the number of RENEWs allowed in a block (currently 600).