Introducing Tezos Domains

Project Updates
1

Introducing Tezos Domains

Previously, we have published the following articles discussing ideas and design choices that we felt needed to be explored for a successful name service on Tezos:

Now we offer our first proposal for smart contract design and we give reasons for some of the design decisions.

matt-duncan-IUY_3DvM__w-unsplash
matt-duncan-IUY_3DvM__w-unsplash3000Ă—1803 1000 KB

New Name

After discussing this among ourselves and community members (naming things is one of the two hardest problems in computer science after all), we decided on Tezos Domains. Very special thanks go to Jonas Lamis (Tezos Capital & StakerDAO) who offered to donate the tezos.domains DNS domain.

Smart Contract Design Proposal

The current proposal is available at docs.tezos.domains. Please keep in mind it’s an early draft and it’s likely to change quite a bit.

Design Decision Rationale

Why auctions and not just First-In-First-Serve registration?

FIFS registration would be certainly easier to implement, but the service would risk “land rush” at launch or at expiration times. We intend to use the FIFS model for domains that have had no buyers previously.

Why open auction and not Vickrey auction?

Blind auctions like Vickrey auction have drawbacks that make them less suitable:

  • If bids are to be sealed, every bidder has to take two actions: transfer funds with a bid hash and (days later) reveal matching bid data. Not only it makes for confusing user experience, but the bid data (containing a user secret) have to be stored securely for longer periods. For browser-based dApps it means a technical problem with no easy solution.
  • Sealed bids are not “really really” sealed. Because the bidding phase requires sending your funds, the users are essentially revealing their bid amounts. While, in theory, a user can post fake bids to confuse competitors, there is no clear advantage of faking larger amounts than the real bid. The main feature of a Vickrey auction - truthful bidding as the dominant strategy - seems doubtful if there are strong clues about competing bids.
  • Blind auction is not a good price discovery mechanism - users are more likely to under- or over-pay for their domains, potentially making the market less effective.

Why proxy contract(s)?

A proxy contract is needed as an upgrade mechanism - both in case of a serious defect or when a new version (with new functionality) is deployed. We understand that amendable contracts are controversial, but it has been shown many times that they are extremely practical in real life (see The DAO on Ethereum or the ENS Migration for examples).

Why administrative multisig?

It is a short-term solution that allows upgrades and data corrections in case of a catastrophe. Starting with a multisig allows us to move fast in getting the service to mainnet. The long-term plan is to create a DAO that will exclusively oversee the administration of the service.

What about Unicode and look-alike attacks?

Many community members have expressed concerns about supporting Unicode character space in the context of look-alike attacks. The consensus is that, in this case, the security features of the service are more important than usability, and we tend to agree.

That being said, we still want to support Unicode names in the future, as long as the risks are mitigated sufficiently. The current plan is to launch the service supporting Latin (pure ASCII) names ending with the .tez top-level domain. One additional top-level domain exclusively for a chosen Unicode script can be launched as a proof-of-concept (allowing names in Cyrillic under .тез has been suggested). Limiting TLDs to certain Unicode scripts means that neither whole-script and mixed-script confusable names can be created in one namespace. We hope this will prove to be a useful strategy.

Thanks

We would like to thank Tezos Foundation for supporting the project and making it possible.

Our thanks also go to the many community members that have given their feedback and valuable advice:

  • Alex Eichhorn (TzStats from Blockwatch Data)
  • Arthur Breitman
  • Andreas and Pascal (Airgap, Beacon, TezBlock from Papers)
  • Carlo van Driesten (BMW AG & vDL Digital Ventures GmbH)
  • Gabriel Alfour (Ligo)
  • Igor Tkach, Eugene Mishura, Jacob Arluck, Charlie Wiser and Julien Hamilton (TQ Tezos)
  • James and Tyler (Dexter, Magma Wallet from camlCase)
  • Johann Tanzer (TulipTools)
  • Jonas Lamis (Tezos Capital & StakerDAO)
  • Michael Zaikin (Baking Bad, TzKt, Atomex, Better Call Dev)
  • Mike Radin and Vishakh (Galleon, Conseil, Nautilus Cloud from Cryptonomics)
  • Nicolas and Steve (Cortez from Nomadic Labs)

Next Steps

The work on the design of the smart contracts will continue for the near future. All comments and suggestions are very welcome as we polish the overall architecture. We plan to deploy a first testnet prototype in the coming weeks.

We will also start working on two projects that tie into the big picture of Tezos Domains:

  • A lightweight indexer that offers querying capabilities specifically for Tezos Domains. The API will allow accessing data that is not available through direct RPC calls to a Tezos node: listing domains according to certain criteria, accessing purchase history, and so on.
  • A prototype of a browser-based dApp that provides lookup functionality, gives details about any domain and it’s subdomains, and allows owners to manage their domains. It will also provide a UI for buying domains using the FIFS model and eventually allow participation in auctions.

Join the Conversation

As always, we want to invite everyone to join the discussion. Do you have a comment on the current proposal? Did we miss something? Let’s share ideas!

And if you want to chat, come join the Tezos Domains Group on Telegram!

10 Likes
2

Very impressive! Congratulations and good work!

1 Like
4

Hello there,

Few comments from a user perspective (you may disregard this opinion as I might be late to the discussion and off topic.)

Before starting, I would have been interested in understanding the why and what for, form this project (if you can say it of course), what/who are you targeting. I felt I was missing the purpose to be able to get the reasoning behind most choices.

Name: I am a strong Tezos supporter but doesn’t understand why blockhains projects always need to put the infrastructure in the name.

If I make a boat in steel, I will not call it “KruppGroup Boat” or at best we could call it “Steel Boat” by its material or “functionalities” like speed boat.

So, I would understand “Crypto Domains” or “Liberty/freedom Domains” or “UND” like “Un-censorable Domains” but have a bit of difficulty with Tezos Domains. Nobody knows Tezos appart us, the geek community. Many now, might have heard of Bitcoin, few of Ethereum, but Tezos is far behind in brand recognition from a non-crypto tiny world.

(Same goes with: ENS vs Unstoppable Domains) I do prefer more the latter and understand it better.

Same goes with the “ .tez” part. Extension like .com / .org / .fr / .io are giving me additional information but .tez only tells me it is on Tezos, it’s not like a common word, and bring no information to 99% of Internet users.

I would prefer a .block .chain or .uncensored

Auction vs FIFS: No strong opinion here. And maybe depends on implementation I suppose. If someone wants do buy a domain name and he is alone, I hope no Auction should be triggered. So I suppose, Auction is here at first where FIFS happen more in the future? :confused:

Please don’t make a mechanism where you need to buy, and re-buy domains over time like monthly. Otherwise we lose the concept of property. To me it’s like NFT.

And same here, if a government kills a publisher or put him to jail or if he get broke. The domain becomes for sale and the info is lost ?

Proxy Contract: To me this one is a crucial point (from my understanding) - Could you ensure the incapacity from an “Admin” to censure any domain? Let’s say, someone publish an article a government doesn’t like via a Tezos Domain.

Could they push you to delete the content ? If this is a yes, then I see very little value added (Again, from my understanding of the project, I might be completely wrong, and not seeing other aspects)
To me it is important as that is a key differentiation factor for those type of services. If this can be challenged, then, better use a classic Internet DNs.

Administrative multisig: I should dig this aspect to understand what’s behind.

Unicode and look-alike: You conclude Security over Usability, which may indicate here, you are not interested in adoption but building something reliable for latter, I might not follow and again not understand the purpose of this TD. Plus, here the security of the system is not challenged, it’s mainly the end user who might be impacted by not being attentive. Couldn’t those be solved with a “flag” or kinda good old “google rating” and a mention not to trust any newly created/unflagged/un-rated address.

Arriving to the end :slight_smile:

I based my comments on the very little knowledge I have about DNs. I might be completely wrong in many ways to catch the idea, but I hope you take those comments from someone who might represent the “average random internet user”, who one day might need to publish something in an un-censorable way without having to be an expert. Those points are sometimes very difficult to see from technocrats and very smart devs.

But here again, I might be wrong also in who are you targeting and the purpose of this project.

Cheers,
S

3 Likes
5

Let me give it my best shot :wink:

Before starting, I would have been interested in understanding the why and what for, form this project (if you can say it of course), what/who are you targeting. I felt I was missing the purpose to be able to get the reasoning behind most choices.

The user base we are thinking of at the moment are all Tezos users - people who have their Tezos wallets and probably own some Tezos currency. There are definitely good prospects of supporting other blockchains or completely generic meta-data. They are not the primary motivations right now though.

You can check out the first article for some broader context.

Edit: TLDR the project is meant to associate primarily names to Tezos addresses.

Name: I am a strong Tezos supporter but doesn’t understand why blockhains projects always need to put the infrastructure in the name.

To be honest, I don’t have a strong opinion on the name. Two points that come to my mind are:

  • Names should easily associate with a concept, if possible. As we are not seeing this project as a generic dictionary of things yet, we wanted to include Tezos as part of the name.
  • Projects can be renamed, reformed and restructured. When the service becomes more, it can always be reflected in the name.

Auction vs FIFS: No strong opinion here. And maybe depends on implementation I suppose. If someone wants do buy a domain name and he is alone, I hope no Auction should be triggered. So I suppose, Auction is here at first where FIFS happen more in the future? :confused:

The FIFS model is meant to trigger when demand for a domain is zero. When the service (or a new TLD) launches, we can’t make this prediction, so an auction would be triggered for all new domains. However a domain that had no bids goes into FIFS and can be purchased immediately.

As for the rental model - yes we currently plan on requiring renewals. There are two opposite approaches:

  • You require renewals and try to maximize the utilization of the namespace. The theory goes, if people are required to renew their domains, the domains are likely to be utilized much more efficiently. People who don’t use their domains will not keep renewing.
  • You treat the domains as tokens - register and forget. This can be a popular approach because people don’t have to make take additional actions or think about renewals at all. One problem is that there is virtually infinite supply of names and people are likely to exhaust usable names much sooner. Another one is that names can be lost over time - people can lose their private keys or forget about the name they register. Thinking about names as “non-perishable” NFTs can be problematic in the long run.
  • Proxy Contract: To me this one is a crucial point (from my understanding) - Could you ensure the incapacity from an “Admin” to censure any domain? Let’s say, someone publish an article a government doesn’t like via a Tezos Domain.

In theory, yes. In practice, if the contract is controlled by a DAO, it’s very unlikely that the DAO will agree on a censorship action without extremely good reasons.

Unicode and look-alike: You conclude Security over Usability, which may indicate here, you are not interested in adoption but building something reliable for latter, I might not follow and again not understand the purpose of this TD. Plus, here the security of the system is not challenged, it’s mainly the end user who might be impacted by not being attentive. Couldn’t those be solved with a “flag” or kinda good old “google rating” and a mention not to trust any newly created/unflagged/un-rated address.

While it’s a good idea in general, there are technical limits to what can be achieved on-chain. We are trying hard to make blockchain the “single source of truth”, especially when it comes to a flag that relates to security. For this reason, our approach is to come up with an “all-or-nothing” validation that we know can be implemented on-chain, at the risk of it being more restrictive. Our goal right now is to keep the door to Unicode open and deploy extensions when any new Unicode namespace is properly analyzed and implemented on-chain.

2 Likes
6

I quite like .chain actually

7

Hey,

Many thanks for the fast and detailed reply !

Ok, now that some elements are clearer I feel less of a strong argument on the Naming convention decided if the target is Tezos family.

However, I will keep a sceptical mind on the censurability and ownership aspects.

On the rental model: I fully understand your point. To me this feature reduces both un-censurability and ownership.

Again, and it might be very personal, but I feel un-censurability is far more important as a functionality than blocking or loss of domains (especially when new extension can be created thus creating a new infinity of new " usable" domains all the time while keeping previous ones.)

And on the ownership aspect:
Maybe my mind is not well built (cultural bais?) but sometime I believe if something belongs to me forever I am more willing to buy it. (Same goes with buying a land and renting it for 100 years even knowing I won’t live 100 years)

On the backdoor: I might agree with a DAO being stronger, but still. A big Government pressure, could use a strength argument. (i.e. “Vote to take this web site down, or we make the whole currency illegal on our territory” - any decentralise autonomous participants would have a double pressure to vote for censoring (from Tz community (non-dao) having no interest in the website yet a risk from its content, and personal direct Financial incentive to vote it down))

I am saying this with again a naive understanding, but read recently that some great firewall in certain country east were censoring block explorers and parsers for Ethereum.

Anyway, as always, there are always trade-offs, and as you mentioned you are targeting a specific niche. I suppose users looking for Ownership or Un-censorship shouldn’t look at this project in its original form.

(And I am sorry for asking then, but I have to ask, why not using a traditional Internet DNs? What is the key advantages, or the value added of this service? (Maybe I don’t see something))

I wish you good luck for this project, and congratulation for starting it, and will definitely keep an eye on it :slight_smile:

Cheers,
S

8

Ideally you want the service to work with very little outside intervention, so creating new TLDs should not be counted on in the long run.

There already is a project doing that - OpenAlias. You can check Part 2 for why we felt it might not be the best approach.

Thanks!

1 Like
9

I understand that un-censurability is one of the key aspects here. Have you considered registering .tez TLD on Handshake network. That could make the TLD itself free from interferences any. Then, the DAO can set policies for .tez domains.

10

Thanks for the suggestion! Integrating with DNS alternatives and naming systems on other blockchains is something we want to keep an eye out for. Right now we don’t see a clear winner in this space, but it’s on our radar.