This is part of a series of articles I’m writing on the Ethereum Name Service (ENS) in retrospective of the ENS Workshop in London, August 2017. I’m going to encapsulate some of the ideas that were produced from this event, to help the larger Ethereum community prepare for changes and contribute to ongoing conversations. If you’d like to get more involved with ENS, you can always visit the Gitter channel, or start a discussion on the Github repository.

In the ENS today, names usually look like your-name.eth or something similar. If you’re very fancy, you’ve seen a subdomain, like something.special.eth . In fact, ENS allows any number of sub-paths, each owned by its own “registrar”, which can be a smart contract, executing any of its own rules.

That means if you own is-the-best.eth , you can compliment your friends by giving them names like nick.is-the-best.eth , and pointing at their addresses. You could also create a sub-registrar contract that issues names with whatever logic you encode it with. For example, you might write your own auction bot to sell off your sub-domains!

If you are simply given or sold a subdomain from someone else today, you’re currently at their mercy, much like a subdomain or sub-path on the web today. I don’t own medium.com/danfinlay , and at any time they could change it on me, or forget to register their own domain, and I could lose my name, and the same is true for basic name assignment in ENS.

However, since this is Ethereum, we’re able to write rules to add guarantees to these systems. One guarantee we would like to offer is this:

It should be possible for a user to acquire a subdomain from a sub-registrar in a way that gives them maximal confidence in their ability to keep that name.

Today, the owner of a domain can always pass ownership of that domain to a smart contract, and by verifying that smart contract, those users can can verify that the owner of the domain cannot reassign the names they assign their users. However, if a domain owner did this today, they may not be able to upgrade their deed when the new registrar is posted, so it’s not currently safe to pass possession of an ENS deed to a contract you do not fully control!

To give users of a sub-registrar the highest confidence available, the ENS Workshop’s best advice is this:

The deed to the domain, and so its ability to give out names should be held by a smart contract which can detect when an ENS upgrade is going to be available, only then allowing the original owner to prepare an upgrade path, and transfer ownership of the deed to that upgrading contract, ideally in a machine-verifiable way. This will give that sub-domain owner time to prove to their sub-sub-domain owners and the community at large that this subdomain is going to transition to the new system without interruption. If this promise is machine-readable, clients will be able to easily warn users when subdomains are not scheduled for normal upgrade.

This period of proving should be accompanied by warnings and pressure from clients (like MetaMask, MyEtherWallet, Mist, and Status, all of whom had representatives present) to indicate to users if a name is liable to expire soon or unexpectedly change. These clients agreed a lot of UX collaboration will be important over aspects of ENS security like this.

Additionally, if renewal fees are adopted in the future (not currently planned, but considered), it may be a good idea is for these sub-registrar contracts to allow their users to help pay their renewal fees, which can help the names live through any original-owner negligence (but still not necessarily through an ENS upgrade).

We learned this is not an easy problem, and so while we came up with a viable solution for sub-registrars to give new guarantees that allow arbitrary ENS upgrades, it would be interesting to see if similar guarantees could be achieved without the opportunity for sub-registrar owners to change their rules during ENS upgrades, although at least this concern is partly mitigated by the upgrade signaling period.

What will this look like in the future?

Most people seemed to agree that helping users register a first name when setting up an account was a nice option, and that will probably be done usually at a small price.

While wallet makers might encourage their users to use addresses on their sub-domains, longer term, Nick Johnson hopes to make a very open marketplace for subdomain owners to sell their names at competitive prices, which means in the future, if you want a name, you might not use the root registrar at all, you might be able to get a good name on a subdomain you like at a competitive price in a single transaction.

Since the root registrar needs to move the slowest, to give the entire system the highest stability guarantees, the most creative innovation in name allocation and conflict resolution may end up taking place on sub-registrars, and so I look forward to seeing what people come up with.