Human Readable User Addresses in IOTA

[lzpap]

Introduction

User accounts in a DLT are controlled via public-key cryptography. The public key of the user's key-pair is hashed to arrive at the public address under which funds are locked in the ledger.

Since an address is technically a hash, even if it is prepended with human readable parts as in the case of bech32 encoding, it is long stream of seemingly random characters to the human eye.

To prevent the user from having to manually enter such random characters, UX solutions try to work around the problem by encoding addresses into QR codes or simply always providing the copy-paste functionality.

A more native approach are name resolvers, like ENS, which are pretty similar to the DNS system of the Internet: they associate human readable names to machine readable objects.

In this document we will discuss a protocol native name service for IOTA.

Goals

A DLT name service solution has to provide at least the following features:

• All names resolve to a single account in the ledger, there can never be duplicated entries. (Consistency)
• Anyone can register a not-yet occupied name. (Accessibility)
• Names can be transferred on-chain. (Transferability)

Additionally there may be more supported features such as time-based name renting, sub-domains and so on. We will examine these nice-to have features later, let's focus on the basics first.

Why not take ENS?

The Ethereum Name Service seems to work well for the Ethereum blockchain and satisfies the requirements we defined above, however, it relies on the execution of native smart contracts. Such contracts take care of name registration, but also of name resolution, as they can be called on-chain to return the public key(s) mapped to a name.

The need for smart contracts is simple: there has to be a single object that defines the name mapping, which is a shared global state. Transactions on the Ethereum blockchain have access to this global shared state, therefore any transaction can just reference a user account by name and leave the resolution up to the smart contracts.

In UTXO based ledgers such as IOTA, there is no such shared global state available in the transaction context, and as a result, there are no smart contracts that could provide the name resolution. We need a different mechanism to implement a name service on IOTA.

Global Shared State in UTXOs

Our goal is to implement a mapping table in the ledger that maps human readable names to addresses. How can we define and maintain such a global shared state available to all transactions while still respecting the parallel, asynchronous nature of UTXOs?

For starters, let's divide and conquer the problem into two parts:

• a name registry system, and
• a name resolver system.

Name Registry in UTXO

A name registry is simply a mapping table between human readable names and address.

The ledger state of a UTXO comprises of all current unspent transaction outputs. The name registry must be part of the ledger state as it needs to be verified and maintained by the network.

We can't put the mapping table directly into an output, as it has unbounded size and at couple hundred entries we already wouldn't be able to fit it into a transaction.

The name registry has to be kept off-chain, but a commitment to its current state has to be stored in an output.

Notice, that off-chain doesn't mean that network nodes are blind to it: it only means, that the actual data is not put into the protocol. The data still has to reside in the snapshot file, so that new nodes joining the network can fetch it from neighbors and verify its content based on the on-chain events.

So we have a registry stored in network nodes and verifiable on the ledger, but how do users interact with it? By posting transactions in the ledger.

A transaction consumes previously created outputs and creates new outputs while respecting the ledger transition rules. We can leverage transactions to post commands to the name registry, for example, insert a new entry in it:

When the network processes this transaction, it applies the command in the white UTXO to the off-chain stored name registry (yellow), and checks whether the commitment of the updated name registry in the blue UTXO is valid. If not, the transaction is deemed invalid.

The name registry is referenced in the ledger by its own UTXO state machine, as described in draft TIP-18.

We designed a simple system which maintains a global shared state off-chain, but verifiable and modifiable on-chain.

Name Resolution in UTXO

Our end goal with a name service is to be able to resolve names to addresses on-chain. Since the registry is referenced via a single UTXO, it becomes a bottleneck, because only one user at a time can include it in a transaction to:

• advance the UTXO state machine of the name registry (add a new name)
• or to resolve a name already present in the registry.

The reason for exclusivity of these two operations is to ensure consistency of the registry, that is, no one can reference a no-longer valid state of the registry for resolution.

While we could live with the fact that name registration must happen in series as it is a one-time and rather rare operation for a user, it is unacceptable to rely on sequential name resolution.

We need a clever trick to make this work: What if we could reason about the content of the registry without having to explicitly look at it?

That is exactly what we aim to do by minting NFT-like proof outputs in the ledger that certify that whoever owns this proof owns the given entry in the off-chain name registry:

Note, that once the proof has been minted, we don't even need to hold the owner address in the registry, it is enough to say that the proof has been minted.

The white UTXO with the name proof then becomes a UTXO state machine as well which has to carry the proof at all times. Among others, this proof output can be:

• included in transactions to prove ownership of outputs locked under its name (bar.iota in our example), hence unlocking them.
• transferred to any other address, so that the name can be auctioned off or simply the keys behind can be rotated.
• used itself as a name registry for sub-domains, for example we could register foo.bar.iota and go over the same process again recursively.

And since each proof output is independent of other proof outputs, name resolution of different names happens in parallel, exploiting the UTXO ledger model to its full extent.

With such a powerful functionality, it becomes possible to simply send funds to bar.iota and leave the name resolution to the owner of the name who wants to consume it:

Use of Name Service on L2 Smart Contracts

The concept described above is implemented purely on layer 1, without the need for smart contracts. But what if we wanted to use these name in let's say an layer 2 smart contract chain?

ISC already has concepts of NFT accounts in its core account contract, which are really similar to named accounts. The only problem is that such accounts can only send on-ledger (L1) requests to smart contract chains, since it is impossible to verify the ownership of the account off-ledger.

However, we could modify the core accounts contract of ISC to support registering a public key to named accounts which can sign requests off-ledger.

Challenges

This document only gives a high level summary of the protocol native IOTA Name Service, and it deliberately omits implementation details and challenges, such as:

• How to define the genesis of the name registry?
• How to optimize access to the single instance of the name registry?
• How to prevent spamming of the name registry?
• How to prevent front-running during name registrations?
• How to register sub-names in name proofs?
• What should be the cost of registering a name?
• Should names expire?
• Can you rent a name for give time period?
• At what registry size does verifying the name registry transitions becomes hardware constrained during transaction validation?
• What tools are needed to minimize the possible conflict creation by users simultaneously trying to register names?

These questions will be answered in a follow-up TIP that defines the IOTA Name Service.

Conclusion

It is possible to design IOTA Name Service as a protocol feature on layer 1, which has several benefits:

• Parallel name resolution of human readable names directly on protocol level. Users can send funds to any name (foo.iota).
• Recursive sub-domain name registration for owned names.
• Easy transfer and time based lending of owned names.

Implementing such a system would greatly enhance user experience of IOTA, especially that of non-technical and non-crypto native people.

What do you think? Let's share ideas and discuss what is the best way to make IOTA appealing to everyday people.

[muXxer]

My initial take on the questions:

How to define the genesis of the name registry?

We could hardcode to generate the initial name registry outputs in a global snapshot file or at a specific milestone where the protocol version increases.

How to optimize access to the single instance of the name registry?

Split the name registry by 256 different name registry outputs and use the first byte of the hash as the "prefix" to find the correct name registry.

How to prevent spamming of the name registry?

State transitions should only be valid if you put enough "dust deposit" into the updated name registry output.
That deposit should actually be a fee, so you are not able to get it back. This way it gets expensive for an attacker to spam the registry output with valid state transitions.

How to prevent front-running during name registrations?

We could require an additional nonce (PoW over hash of the name to register and the pubkey that gets registered) inside the transaction that updates the name registry output. This way no one can frontrun the registration a specific hash when he sees a new "registration transaction" on the tangle so easily.

How to register sub-names in name proofs?

Maybe the name outputs have their own off-protocol local-state as well?
Reuse the same kind of system but on name output level.

What should be the cost of registering a name?

In my opinion it should be rather expensive. 1-10 Mi for example. Maybe even more if the name is shorter?

Maybe we could also come up with an auction system instead of a "first-come first-served"?
For example the first one that registers an unused name has to put a name, a deposit, a public key and a timestamp in the list.
Then the auction starts and in the next e.g. 24h everyone can replace that entry by putting a higher dust deposit in the output.
The state transition is only valid if the same timestamp for that entry is kept, and the former dust deposit is paid out to the former public key.

After the 24h state changes are not allowed anymore for that specific entry, but the highest bidder is able to claim the name.

To prevent spamming attacks on the name output by biding we require the additional PoW nonce or we could also offload that auction to a "auction output", which can be used to claim the name at the end of the auction itself.

Should names expire?

I don't see a reason why, and imagine your name output expires but you still have a lot of funds on it 🤯

Can you rent a name for give time period?

It would be nice to have a "governor" field in the name outputs, so that you could delegate the sub-name to someone else.
But we really need to discuss if that is an actual use case.... because the governor could simply gain ownership over coins from the person that rented the name output. Maybe with timelocks, and the person that rents the output needs to take care to move the owned funds before the timelock for the governor expires himself?

At what registry size does verifying the name registry transitions becomes hardware constrained during transaction validation?

I have no clue yet :D

What tools are needed to minimize the possible conflict creation by users simultaneously trying to register names?

A route in an indexer plugin, that points to the latest valid name registration transaction that is issued on-tangle would be nice.
This way honest users could simply chain these registration together, with a lower chance of conflicts (there would still be the chance of race-conditions ofc).

[clbargain]

this is great stuff! keep up the good work!🙌

although I would be concerned if an auction type system gets in place for registering names as whales can take over a majority of good names..

[Dr-Electron]

Should names expire?

I don't see a reason why, and imagine your name output expires but you still have a lot of funds on it 🤯

I would actually prefer it 😅 . Would lead to less lost names forever 🤔 And you could also automate the renew process if needed, right?

[r-sw-eet]

Should names expire?

I don't see a reason why, and imagine your name output expires but you still have a lot of funds on it 🤯

I would actually prefer it 😅 . Would lead to less lost names forever 🤔 And you could also automate the renew process if needed, right?

Expiration is totally valid, but why loss of funds? The funds should still be on the iota adress, the only thing expiring is the link from the name to the adress. Comparing to DNS, if my domain is not renewed, i dont loose my webspace with my content, only the "nice/humanreadable" reference to it...

[Thoralf-M]

What's the issue with an indexer to do the name resolution before sending a transaction, so the final output would just get the Ed25519 address of the owner in the unlock condition instead of the name? That way the outputs couldn't get lost even if the name expires and it would also reduce the required logic in the protocol

[lzpap]

Why would you trust a random node's indexer plugin? I can just set up my own indexer to resolve all names to my address and provide this for free to any wallets.
With the approach above, you don't trust the node but you trust the protocol.

[Thoralf-M]

You shouldn't trust random nodes, but you should use a trusted node anyways, otherwise it can always send you wrong or just no information

[lzpap]

That's exactly why we added InputsCommitment in TIP-20 to the transaction essence: even if the node sends you rubbish the protocol discards the transfer.

Even if I trust a node, what if it gets hacked or there is a man in the middle?

[Thoralf-M]

Well DNS resolvers also work this way, but yeah you don't send your money directly there

[sdellava]

Good work.

I only have one suggestion that I would call "extensive": this proposal can be described as a method for mapping an off-tangle resource to an on-tangle resource.

I would take the opportunity to generalize this method to create a mapping between a generic URI and an address in the tangle (or an index).

There are multiple use cases for this type of mapping. For example, chunks of an IPFS resource can be stored in IOTA messages. Mapping the chunk's url representation to an IOTA index or address can allow access to the chunck stored and retrieved from the tangle. This opens up the possibility of storing NFT content on tangle.

The same approach allows web pages to be stored on the tangle, making the association between address and content static.

etc. etc.

[muXxer]

With the coming stardust upgrade, we already have metadata fields, where you can store whatever data you want.

[danteiota]

Great work, thanks for putting this together @lzpap!

At Disentangle we have thought about some of the questions listed here, mostly on how to best ensure a fair & sustainable distribution of domains. Here are some features that may (or may not) be used to counter domain squatting, scams, impersonations and potential permalocks (i.e. domains locked forever due to lost private keys):

• Reserve a list of most 'vulnerable' domains from public sale
  • Alexa Top 100k
  • Verified Twitter profiles
• Enable cross-integration with existing names
  • Social media handles (akin to Solana Name Service with Twitter)
  • ICANN web2 domains (like .com) - maybe if meeting certain criteria, e.g. older than >1 month
• Renewal system
  • Relatively small but significant amount (e.g. $5/year for 5+ character domains, which hinders domain squatting & avoids permalock)
• Auction system
  • Before genesis registry instantiation, leave a very long period for all community members to request any reasonably desired domain(s) - e.g. 3 to 6 months, and perhaps ask to provide a short one-sentence explanation per domain
  • We thought about permanently implementing a shorter period (e.g. 3 days) afterwards, but discarded this idea after reading numerous community complaints on UX and on last-minute sniping - e.g. using the “Ending Soonest” tab in Solana Name Service. A reasonably cheap renewal system seems to provide a significantly more effective and satisfactory UX
• We also thought of limiting the maximum # of allowed domains per wallet address (e.g. 50), but discarded this idea because it doesn't seem logical to impose an arbitrary limit. If users want to buy hundreds of legitimate names (e.g. for every employee in their company, or for owners of numerous IoT devices), that should be their right to do so

[r-sw-eet]

* _We also thought of limiting the maximum # of allowed domains per wallet address (e.g. 50), but discarded this idea because it doesn't seem logical to impose an arbitrary limit. If users want to buy hundreds of legitimate names (e.g. for every employee in their company, or for owners of numerous IoT devices), that should be their right to do so_

So, there really should not be an arbitray limit.

• But the more names point to the same adress, the more it should cost. Incremental price steps after 10, 20, 50 names and so on. (e.g.) Or have a threshold of lets say 10 for free, then go exponential (parameters tbd)

Because name hoarding should not be a thing. (I know, everybody can have x adresses, thats why the price should reflect that)
Regarding your example: Why the hell, should my company have an employees name for their wallet? Isnt DLT space the goal for everyone to have/handle his/her wallets? Not my keys, not my crypto. If it is to get some tips from a customer, setup a new wallet , reference it with name.company.iota and give her the goddamn key.

• Subnames should be way cheaper, if not free (if possible)

• To determine the incremental price steps, we should make a list of usecase(s) categories where you would need multiple names.

Do I really need my toaster to have its own name? No. Do i need for every character in every game i play or every nickname i have on social media a name? Nope...

[r-sw-eet]

Maybe start more restrictive and have people complain and explain their particular usecase. This way we know how it is being used (initially). Better safe than sorry :)

[WernerderChamp]

I wonder if it even makes sense.
If somebody wants to hoard names, he could bypass it using multiple wallets.

I also don't see any technical reason why it would be bad to have a lot of names linked to one address aside from name hoarding (which can be bypassed as I described)

[WernerderChamp]

• Personally, I'd prefer a system where you have to pay a yearly fee to keep your human readable name up. There should be counter-incentives to name hoarding, where people buy up massive amounts of names in hope to sell them for a profit. While I am surely aware that there is no way to fully prevent it, adding running costs will ensure people aren't risking to much.
  My proposal would be 10Mi/year (with the option to lower it if the price goes way up), you can renew for up to 3 years in advance. If your registration expires, there is a 28 day grace period where it will stay reserved for you. After this its back on the market. This also prevents names from getting lost permanently.

• A point that has not been discussed yet is the allowed charset for those names. We should not be too lenient here, as lookalike characters make phishing easy. My suggestion would be to allow alphanumerics and some other simple characters from the ASCII charset. Names should also be lowercase only due to lI (upercase i and lowercase L) issue.

• Length of the names has also not been defined yet. I'd suggest to make names at least 3 characters. There also needs to be an upper bound somewhere, maybe 127 chars including subdomains? I doubt longer names have any use other than to fill the database. Nobody is going to type that much.

• Yearly costs should be way higher for short names, given the limited amount (assuming 40 possible characters, there are just 64000 3-digits). I expect any meaningful 3-digit word (e.g. ear, pay, nft, god) to be worth a lot. I'd therefore suggest 15x for 3-digit, 4x for 4-digit and 2x for a 5-digit name. This also discourages from using those names as an investment.

• As somebody already mentioned, there might be an issue with some names. Some names e.g. associated with the core protocol (foundation, edf, dao, treasury) should definitly be blocked. Furthermore, there might be some names that could be valuable for phishing, e.g. the names of exchanges and important crypto people. I think the community should come up with a sort of blacklist, those names are pre-registered before the protocol goes live and either can't be used at all or are ensured to be given to the right people. That's an entire debate of its own through, not going to go too deep into that here.

• I would suggest an auction system, as implementing first come - first serve is going to cause a massive botfight around valuable names. I have a rough idea for this, going to make a more detailed post about it if I find it working. It would be a pretty short auction.

• We could theoretically go with first come first serve if we do an initial auction. This does not need to be 100% decentralized, just need to ensure fairness