Designing a Name Service - Part 1: Introduction

Research and Development
1

Designing a Name Service - Part 1: Introduction

This article is also available as part of our Tezos Name Service publication on Medium. That’s where you can find our future articles on the topic as they become available, but we will post them here too for easy discussion.

In January, Gabriel Alfour proposed possible naming and identity systems and talked about how they could become parts of the Tezos ecosystem in the future.

In this series of posts, we would like to expand on one of the ideas - building a vanity naming system. We are going to discuss architectural questions and dilemmas that are necessary to solve for such a system to be successful.

Motivation

Using addresses can become an obstacle for the practical use of Tezos as a currency. It’s clear that a string like tz1VSUr8wwNhLAzempoch5d6hLRiTh8Cjcjb is usable when transferred by a computer program or using the operating system’s clipboard, but it is unwieldy in most other types of communication. It cannot be memorized or even realistically communicated through human speech or visual media.

Building a system where participants are in charge of creating their aliases presents a straightforward solution. If it is the best solution is a bit less clear, but more on that later. People are already used to creating names for their e-mail boxes, Instagram accounts, or their web pages. The topic of this discussion is providing them with this familiar approach inside the Tezos ecosystem.

What Is Tezos Name Service

The main function is to translate a meaningful and user-friendly alias to a Tezos address and potentially vice versa. This translation should be globally consistent so that all participants on the blockchain see the same address for a given alias.

A parallel that’s often drawn is to the DNS, a familiar and universally adopted system. Admittedly, DNS becomes an obvious inspiration for similar schemes.

The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities.

An example of an alias in a system inspired by the DNS could be alice.tez. Alice bought it from the central registrar managing tez and then assigned it the address of her personal wallet. When she sends money to Bob, he will see alice.tez in his wallet’s received transactions, because Alice has also set up a reverse record mapping her address back to alice.tez.

Who Are the Users

Both individuals and organizations might be interested in using the service. We believe that supporting both groups alike is needed to drive adoption rates in the long run. Unnecessary obstacles for adoption by organizations and businesses should be identified and avoided.

Objectives

Ease of Use

Usability is ultimately a make-or-break factor and needs to be considered strongly, but it can mean many things to many people. Intuitively, we can start to see if our system is usable by asking a few cursory questions:

  • Are the names memorable?
  • How difficult is it to type them?
  • Are they easy to read on a screen?
  • Are they pronounceable? Can I tell my wallet name to someone on a phone call?
  • Does it allow for a registration process that’s smooth and easy to understand? What about the management of the user’s existing domains?

Security

Various technical and non-technical security risks need to be identified and (if possible) mitigated. For our purposes, let’s assume our building blocks are inherently secure - for example, that the Tezos implementation is correct and private keys of name owners are stored securely.

I’m going to list some areas that need to be explored, but this list is by no means exhaustive.

  • Spoofing attacks.
    There are many ways attackers can try to spoof vanity names. Using lookalike characters (goog1e.com instead of google.com) or prepending the spoofed name to a name owned by the attacker (google.com.phising-inc.com) are just two examples. Name spoofing is an ongoing problem for the DNS.
  • Front Running Purchases or Bids.
    This a notorious issue on blockchain systems. Currently on Tezos, any pending transaction can be publicly seen in the mempool. A speculator seeing an unmasked purchase and assuming the name is valuable can submit his purchase with a higher maximum fee. If successful, they will snatch the name from the original requester. This is commonly solved by introducing a commit/reveal scheme.
  • Complexity of Smart Contracts.
    The chance of introducing a vulnerability in a smart contract tends to grow rapidly with complexity. Auctions or other complex logic implemented in smart contracts need to be scrutinized and possibly formally verified. The history of attacks targeting insecure smart contracts handling substantial value is well documented.
  • Security of the Root Node
    Hierarchical systems like the DNS require that a root node exists. In DNS, the root servers are responsible for resolving top-level domains such as .com and .net. This gives the holder(s) of the root node complete control over the child nodes. If the security of the root node is compromised, the whole system is compromised as well.

Availability and Fairness

The availability of names is another very important aspect. By availability, we mostly mean that the users can choose a name that’s useful and meaningful to them. The names will not be created equal and some will necessarily be more sought after than others. For organizations, the ability to retain established trademarks is crucial and we believe it is one of the areas worth exploring.

Then we need to look at fairness - specifically how to make sure a domain that is made available at a publicly known time is sold to a buyer offering a fair market price. A first-come-first-served implementation might be problematic. As Tezos bakers can freely choose transactions for inclusion in the next block (within certain parameters), it’s also easy to see the incentive to behave unfairly and pick “friendly” registrations to be processed first.

A special version of this problem is the time of launch of the name service. A naive initial offering making all names available at a specific time will lead to users competing to register and a massive spike of transaction fees essentially transferring the market value of registered names to bakers, even if they behave fairly.

Affordability

In an ideal scenario, the price should not be an obstacle to acquiring a meaningful name. We are not building a for-profit project. At the same time, we need to discourage participants from name-squatting. The correct price might prove difficult to select, as individual buying power differs dramatically around the world.

Affordability and fairness may seem incompatible because paying fair market value can sometimes be unaffordable. However, we believe that in reality, most namespaces will allow users to find an alternative meaningful name with lower market value.

Stability

It’s necessary to provide users with enough confidence that a name will resolve to the correct address after some time has passed. In DNS, this is achieved to some degree by imposing a minimum time period for registrations and giving existing owners the option of prolonging their registrations at any time until the domain expires. As this action needs to be initiated by the user, it still allows losing names to error or carelessness.

Internationalization

If we want the system to be used globally, we must support names in many different character sets. This is self-evident when we understand that only about one-third of the world’s population uses the Latin alphabet or some derivation.

This opens up some new challenges. The susceptibility to spoofing is made much higher, as some look-alikes in different languages are graphically indistinguishable from each other. For example, a name like apex.tez can easily be spoofed by any of the 15 different look-alike names that can be created by combining letters from Latin and their Cyrillic homoglyphs а, р, е, and х. The Chinese traditional and simplified alphabets are even more open to look-alike attacks because a lot of characters are present in both alphabets.

Extensibility

Ideas to explore in this section include:

  • Custom registration logic.
    In a hierarchical structure, we can let the owners of names create their own rules for registering child names. For example somewallet.tez might decide they will offer free names like johnsmith.somewallet.tez to promote their wallet.
  • Custom resolve logic.
    This is currently limited by Tezos having no capability to make function calls on other contracts synchronously. The great news is, that it is already being worked on.
  • Custom types of records.
    Our system can potentially associate names to more than just their assigned addresses. We could store records with arbitrary meta-data that participants find useful, for example { address: "tz1...", email: "alice@company.com" }. There can be some overlap with the traditional responsibilities of an identity system, but that doesn’t have to be a bad thing necessarily.

Upgradeability

Learning something from a similar project on Ethereum - the ENS - we see it beneficial to be able to make hotfixes on existing contracts. After discovering a vulnerability in one of their smart contracts, the ENS team had to migrate all data to a new contract and issue an announcement urging wallet developers to update their software to the new address as quickly as possible.

Upgradeability is usually achieved by creating a proxy contract that only contains the address of the actual contract in its storage. This is not a substitute for writing secure code, but it can limit the impact in case of a security issue.

Transparency

Last but not least, it should be transparent how the financial proceeds from registered names are used. One idea might be funding further development related to the name service ecosystem (adding support in wallets or similar), or even funding projects in the Tezos ecosystems itself.

Conclusion and Next Steps

We have explained the motivation for building a name service and outlined objectives that we believe are important for success.

Next, we will follow up with a series of posts where we dig deeper into individual questions and open topics that need the attention of the community. Some of the topics discussed will likely be:

  • structure and namespace,
  • name distribution & pricing,
  • name rules and validation,
  • retaining trademarks, and
  • secondary market.

Further Reading

About the Team

The team at Agile Ventures has been working with Tezos since the early alphanet days. We have created two open-sourced projects focused on helping developers interact with the Tezos data and events easier and are hosting publicly available endpoints on TezosLive.io.

Join the Conversation

We are excited to start a discussion on this topic with the community! Do you have an opinion on what a successful name service should look like? Did we miss something? Let’s share ideas.

And if you want to chat, come join TNS Group on Telegram!

11 Likes
2

Great write up, exciting project.

Will you foresee that a name becomes available again after a certain period of inactivity? That way, if someone loses keys, the name is not lost forever?

1 Like
3

I like this especially.
Do you have any ETA on the project? This year?

4

Thanks!

I think a likely model is that users won’t be owning names indefinitely, but renting them, like in DNS. A name will be freed up automatically when the owner stops extending, which should also help discourage domain squatting.

We definitely plan to write a bit more on the topic in the very near future.

1 Like
5

It all depends on what the community consensus will be when it comes to a minimal viable feature set.

It would be great to have something out soon, but I also think there is not much room for do-overs when it comes to this kind of service. Let’s see.

1 Like