Name Service Pallet Introduction and Call for FRAME Devs to Finalise & Review

Tech Talk
1

A Polkadot name service is an idea that has been sitting on the sidelines for a while but has not been fully realised. I have recently revisited what was worked on last year and have attempted to update it into a viable proposition for the Collectives parachain.

Substrate PR:

Pallet Overview

This name service is not a carbon copy of existing services, but instead is a version of what makes sense for the Polkadot ecosystem. This name service pallet is designed to act as a singular service for all parachains, whereby registered names alias an account, and the suffix of the name aliases the parachain ID.

Important note: Name service is not a DID service, it is a means to provide friendly aliases for addresses and chains so UIs can provide a friendlier means of transferring funds.

So provided the Relay Chain registers itself on the name service with the suffix dot, the following is true for the name ross.dot:

  • ross aliases any provided account (via the set_address call)
  • dot aliases the relay chain.

Paras need to register themselves to the name service via register_domain(para_id, suffix), which is only callable by the root origin. The preferred way (and only way) for a para to register to the name service is to go through an OpenGov proposal on the Relay Chain, which upon execution can submit a register_domain call to the Collectives chain .

Pallet Features

Beyond registering and deregistering of Paras, the name service consists of:

  • a commit and reveal scheme for registering names.
  • renewing, transferring and de-registering of names.
  • ability to set an address for a name (primary use case)
  • ability to store the text-representation of the name on-chain to act as a reverse-lookup for the hash.
  • ability to set a miscellaneous text record (could act as a status message to go alongside an address in a UI).
  • recursive subdomain registrations, e.g. I could register a tree of subnodes to compose a my.polkadot.domain.ross.dot name. Each subnode supports the above address, name and text metadata.

To prevent the duplication of docs, the pallet is detailed in the pallet docs, that can be found here: https://github.com/paritytech/substrate/blob/f67e9c947147a8d7c051cb3e056844bedf4f223a/frame/name-service/src/lib.rs#L18

Ideal Use Case

The name service can be applied to any form factor of app, but mobile particularly stands out as an opportunity to promote the usage of name service. Users can hand-type addresses to send tokens without the need to copy and past addresses. The name and suffix together provide enough context for the UI to know which para tokens need to be sent to, even if support is initially limited to a single chain.

Call for FRAME devs

The name service pallet needs FRAME expertise for feedback loops and to ensure the above registration mechanism works, as well as general improvements to the pallet.

There are also more nuance requirements like having a generic address type for supporting all para address types. So some expertise is needed as to head in the right direction with these aspects.

That said, feedback on Github and code optimisations in any area of the pallet are all very welcome.

4 Likes
2

I think GeneralAdmin is probably suitable, as it is the ā€œOrigin for managing the registrarā€.

IMO this post would make more sense as a Fellowship RFC, especially w/r/t semantic patterns and how chains/UIs should interpret suffixes.

2 Likes
3

@ross would it be helpful to talk to someone at ENS to learn from them on what they would do differently if they could relaunch it?

Could we allow for:
a) a period where parachains can get priority to register their names without the risk of getting frontrun?
b) limit the creation of names to be longer?

4

A lot of the pallet code is based on ENS logic, which we extensively visited in the early innings of developing this pallet early last year. Although it is worth getting inspiration from alternative products, it is important to keep in mind that the service needs to be tailored for Polkadot and parachains. As such, as we iterate on the design it will undoubtedly become more differentiated from ENS.

a) Right now the envisioned way for a chain to register is by voting. With the Substrate kitchen sink config the MaxSuffixLength is set to 4, so there is ample room for all parachains to get unique suffixes. With the small amount of paras right now I donā€™t think frontrunning is a problem worth investing a lot of time on - priority should be getting the integrity of the pallet to a high standard and launching it on Collectives. Ultimately though chains will want suffixes that reflect their name, and after the initial rush of potentially 40-odd chains registering, the rate will dramatically slow down.

b) The pallet constant MaxNameLength (currently at 2048) can indeed be altered.

These are the runtime constants that can currently be configured:

type MaxCommitmentAge = MaxCommitmentAge;
type MinCommitmentAge = MinCommitmentAge;
type MaxNameLength = MaxNameLength;
type MaxRegistrationLength = MaxRegistrationLength;
type MaxSuffixLength = MaxSuffixLength;
type MaxTextLength = MaxTextLength;

The pallet also has configurable storage items via a root origin set_configs call. These configs can be voted in:

commitment_deposit: ConfigOp<BalanceOf<T>>,
subnode_deposit: ConfigOp<BalanceOf<T>>,
tier_three_letters: ConfigOp<BalanceOf<T>>,
tier_four_letters: ConfigOp<BalanceOf<T>>,
tier_default: ConfigOp<BalanceOf<T>>,
registration_fee_per_block: ConfigOp<BalanceOf<T>>,
per_byte_fee: ConfigOp<BalanceOf<T>>,
2 Likes
5

As mentioned by Joe, I hope to see this as a Fellowship RFC, as it is targeting a system chain.

I may have missed this in the text, but:

  1. Can you elaborate more on why this should be part of the collectives parachain?

  2. Any prior art in the Polkadot space? I recall seeing a similar (offchian) effort from the folks at SubSocial.

1 Like
6

Can you elaborate more on why this should be part of the collectives parachain?

I originally pitched the idea as an AssetHub pallet but Gav said it is probably more suited to the collectives chain as it is a service for people.

Any prior art in the Polkadot space

There have been a couple of efforts in the past by projects like the PNS project (now seems to be rebranded to a DID service) but there have not been afaik any production uses of name services in the ecosystem thus far. We originally stalled this effort in the first half of last year in the spirit of letting the community drive the initiative, a stance we took that has not paid off to date.

1 Like
7

The primary use case revolves around asset transfers, but Iā€™m not entirely certain about the registration process for parachains and the TLD. Wouldnā€™t it be confusing for users to have to use a suffix for their names? If I were designing the user interface, my goal would be to have a name that simply identifies the recipient without requiring any additional suffix. The details about the currency being transferred and the chain it happens on could be specified in other parts of the application, rather than relying on a specific name format.

Moreover, Iā€™d like to highlight that a similar service for the Polkadot ecosystem already exists, known as web3name (w3n). Since this solution is based on DID (Decentralized Identifier), it centers around connecting a friendly name to your unique DID. Users can then publish addresses where they wish to receive payments and credentials that verify their identity.

If you are interested, you can check out Nova Wallet, which already supports w3n integration. Polkassembly also support w3n and there is a w3n search.

1 Like
8

Thank you for your input, some clarifications:

Users donā€™t need to type the suffix of a name in the UI. The name is enough for the chain to query the aliased address and the para_id that sits next to that address in a tuple - and if they wish, the suffix corresponding to that para_id. This is how the UI knows which chain to send funds to. It is up to the UI whether to display the suffix or not - I would lean to displaying at least the destination chain based on that suffix, and the suffix if I wanted to reflect a traditional domain name so there is a level of familiarity of the UI.

It is very important not to conflate a name service with a DID. A DID is when your on-chain assets are linked to real world verifiable credentials. A name service is simply a means of aliasing addresses (in the name service palletā€™s case, multi-chain aliasing). A DID service is a separate component that would link name service registrations to some verifiable credential. Which I am all for, that would be a very exciting development for DIDs.

That is fantastic that other name service solutions are being developed. I highly encourage this, especially with different form factors like smart contracts. The situation remains though of a lack of a production ready multi chain name service on Polkadot, so until this is realised I highly encourage development to continue for all candidate solutions to diversify avenues.

2 Likes
9

To be clear, for ordinary users, they would register their desired name once and it would be useable for all parachains that have registered their suffix?

e.g. I register lolmcshizz.dot and this would mean that my name (lolmcshizz) can be used to send funds to my wallet on any of the chains that support it? So if HydraDX and Interlay had registered, it would work for those chains? UIs would abstract away the suffixes but my lolmcshizz.dot would actually be .dot for AssetHub, .hdx for HydraDX, .intr for Interlay, etc?

1 Like
10

A DID is a Decentralized Identifier. You can use your DID without having any credentials.

I completely agree with you. I only wanted to make sure that you are aware of other projects that already build things in this direction.

Since w3n are already used in production apps (Nova wallet uses it for sending funds), I would argue that there is at least one production ready name service. Itā€™s also a multi chain solution. It works with every chain that can be identified with the CAIP-19 specification.

Is the name service pallet limited to polkadot parachains? Would this work for Kusama as well or would there be another Pallet/Parachain on Kusama? Because this would lead to conflicts. A user on Kusama could have the same name as someone on polkadot while they are different entities.
Parachains could also register the same TLD on Kusama in that case and refer to a different chain?

11

Correct.

e.g. I register lolmcshizz.dot and this would mean that my name (lolmcshizz)

You would just register lolmcshizz, and assign an address and para_id once it is registered. Yes what you describe is how it works. .dot would probably be the relay chain.

2 Likes
12

A DID is a Decentralized Identifier.

Iā€™m not sure I subscribe to this terminology, a name hash just acts as an alias for something. It cannot identify more than what it is aliasing.

Since w3n are already used in production apps (Nova wallet uses it for sending funds), I would argue that there is at least one production ready name service. Itā€™s also a multi chain solution. It works with every chain that can be identified with the CAIP-19 specification .

Great, definitely worth exploring.

Is the name service pallet limited to polkadot parachains?

Yes, Kusama would have its own pallet instance.

13

Hey guys,

Happy to join the discussion and share with you what we have been building over the last months and give you a bit more background on how we envision the future of domains on Polkadot :slightly_smiling_face:

Over the last ten months, we have been busy building the very first ink!-based name service for the Substrate ecosystem. We are currently live on the Aleph Zero testnet and will soon hit the mainnet. Check it out under AZERO.ID (and hit us up if you want testnet access).

Moreover, we have been researching how we can expand the protocol to all Polkadot parachains with an XCM-native solution. We are working on creating a unified namespace for the whole Polkadot ecosystem that can be accessed from all parachains.

Building on the smart-contract level was a deliberate decision to show off the great advancements Parity achieved in this regard in the recent months/years with pallet-contracts & ink!. It also totally falls into line with the current blockspace and hybridchain narratives pushed forward by Gav & Rob.

The research and development of the technical architecture is supported by a W3F grant. Please read more about our motivation and our accepted W3F research grant here: XCM Domain Service by wottpal Ā· Pull Request #1733 Ā· w3f/Grants-Program Ā· GitHub.

The situation remains though of a lack of a production-ready multi-chain name service on Polkadot, so until this is realized I highly encourage development to continue for all candidate solutions to diversify avenues.

@ross We hope to fill this gap in the next months and the first version of our domain service protocol and dApp that is going live in a few weeks already includes the following features:

  • Registration of NFT-based domains

  • ENS-like role system that allows the individualization of owner, controller, and resolving address for a domain

  • Flexible metadata storage system that allows users to attach any kind of information to a domain (e.g., contact details, credentials, social media links, or wallet addresses on other chains).

  • Ability to set a primary domain for a wallet as on-chain identity. Thereby, users can specify which domain is displayed in applications that resolve domains.

  • Individual social pages with Linktree-like functionality for each domain

  • Integration SDK with easy-to-use JS/TS or React-based resolver libraries as well as snippets for direct ink! smart contract calls

  • much moreā€¦

We would like to emphasize that our focus in feature and dApp development lies on the overall user experience. We want to create an application that is easy to understand and use for all types of user groups in the Polkadot ecosystem. Even newbies should be easily able to claim domains as the first step of their Dotsama journey.

In addition, we are currently developing the following functionalities:

  • Demand-based pricing mechanism to solve the problem of domain squatting that is popular in other namespaces such as ENS

  • Native NFT-domain marketplace to create an efficient secondary marketplace for domains

  • Subdomain functionality enabling powerful community and organizational use cases

  • Privacy-preserving domain system with address obfuscation on Aleph Zero via their native zkSNARK-based privacy framework Liminal

All of these functionalities will be part of the ā€œXCMā€ domain system we are developing. It is important to note that all these efforts should be aligned and built as close to the community as possible. We are currently setting up a non-profit entity with the purpose to develop the project and push its adoption in the ecosystem. Further, a unified domain system for Polkadot is a core primitive that should not belong to a single centralized entity but should be governed by a community, users, and key stakeholders. We are currently working on a clear and structured path to decentralize the project over time.

So far, the project has been funded by a grant from the Aleph Zero foundation and a small pre-seed round with the participation of members at Aleph Zero, Parity, W3F, and other angels in the crypto space.

We look forward to an open and fruitful discussion on domains in the Substrate & Polkadot ecosystem and are happy to answer any questions that may arise!

6 Likes
14

DID refers to the W3C standard. Decentralized Identifiers (DIDs) v1.0 That is a well established name.

1 Like
15

I like the initiatives here a lot. It would be nice to finally have a fully functional and widely adopted domain system, which is something multiple people have looked into before. I think, ideally, the efforts should be somehow combined: For example, standardizing certain parts of it via an RFC but still leaving enough room for community projects to be the driving force behind it (marketing, wallet integration, additional features on top, etc.).

3 Likes
16

DID refers to the W3C standard. Decentralized Identifiers (DIDs) v1.0 That is a well established name.

Yes. I am aware of this. From the first sentence:
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity.

Verifiable is the key term here that I donā€™t see name services solving. I can prove ownership of the private key that has management access to a name hash (which could be anyone), but the name hash itself does not verify ownership of any tangible asset or real-world credential tied to an identity. Name hashes are not identities on their own.

1 Like
17

Yes of course a name service is not a DID implementation.

KILT implementation the DID standard and also provides a name service among other things for these DIDs. The DIDs can be used for payments as demonstrated by Nova Wallet.

1 Like
18

Hey! So many interesting points coming up in here!
I think itā€™s absolutely a nice thing that different projects/companies, including Parity, are coming up with their own solution to make identity management easier. I work for the KILT team, so excuse me if some of my points might be biased towards what KILT does.

DIDs, at least in the KILT case, are meant to be completely independent from accounts. So this is already one big difference between KILT web3names and any other naming service being developed and deployed. As pointed out earlier in this thread, a DID is a W3C standard, meaning its specification is being developed and adopted by a much larger crowd than the Polkadot userbase, and this was the driving force for KILT to put a lot of effort into DIDs.
Yes, a Decentralised IDentifier is, after all, an identifier, but its power does not come from it being a fancy wrapper around a bunch of public keys, but rather from the fact that they are all compatible with each other. As I mentioned few times in the past, the OpenID foundation itself, which is beyond the most popular identity delegation protocol OpenID, is working on integrating DIDs into the OpenID authentication stack, with solutions such as SIOP, OIDC4VCI and OIDC4VP. This means that, as of today, a KILT DID, or any other DID for what matters, can be used, with very little modifications, in OpenID flows right next to Facebook, Google, Apple, Auth0, and whatnot.
THIS is the power that relying on an industry standard unlocks.

The same I could say for the way of attaching identity information to such an identifier. Yes, an on-chain key-value storage in the metadata is good infrastructure, but what are the standards to write such data? How can it be processed properly by clients? WHO are the clients? Polkadot apps? What about outside of the Polkadot ecosystem? Once again, Verifiable Credentials are being used, right now, in a lot of different use cases, for instance EU COVID green passes were based on this standard. And, once again, this is the route the KILT decided to take.

Sorry for this bit of rant, but my point, in short, is that it is admirable that different projects come up with solutions to solve the account aliasing issue, but one thing to consider is that cross-domain interoperability becomes much harder if no global standard is developed and used. We at KILT have decided to participate and deploy identity standards that are guaranteed to make KILT solutions work also outside of the Polkadot and even blockchain ecosystem, as is already happening.

All in all, I would not pick winners and losers, since for me itā€™s a bit like comparing oranges to apples. Yes, you can link a Polkadot and EVM account to a KILT web3name, as you could link it to few other naming services, but at least having a DID unlocks way more opportunities not just inside the Polkadot space, but especially outside.

Cheers,
Antonio

5 Likes
19

Thank you to all who provided feedback. This thread has quickly evolved into something different to what I originally envisaged. I can see both Kilt and AZero teams raised their concerns with conflicts with their own name services, which highlights a communication issue between our teams that we should look into fixing moving forward.

I hope the community know that it is in no ones interest to duplicate works or cannibalise what in some cases is years of development, and I want to highlight that this remains at the core of the stance I opt to take here. With that premise, it is also healthy to communicate ideas and code that ultimately promote discussion and can improve the solutions being worked on. It is in every Polkadot stake-holderā€™s interest (network wide) to see a first class name service come to fruition.

That said, I think there are snippets of knowledge that can be taken from each project that explores this problem.

The pallet version of the name service for example demonstrates (1) an effective commit-reveal scheme for registering domains. (2) It implements the idea that chain storage should be backed up with a deposit as to incentivise removal when that storage is no longer useful - a deposit is left by the committer and then transferred (if different) to the owner upon revealing & finishing the registration. (3) The recursive subdomain feature also require deposits, and the expiry of which is tied to the TLD in question. (4) The ability to store the plain-text name on chain exists (again, deposit required), to act as a reverse-lookup of the hash. (5) A tier convention is used to give different pricing for 3, 4 and 5+ character domains. (6) To promote a fairer registration and fee system, the registrant must pay a ā€œlengthā€ fee that increases per number of blocks, in addition to a one-off registration fee (the tier), and of course the aforementioned deposit to incentivise de-registration & free up chain storage.

I am interested in hearing the alternatives or the opted path for the above 1-6 features, of both the Kilt and AZero solutions, so we can publicly discuss and learn together how the systems differ, and perhaps how they can be improved. As someone who has not historically followed both Kilt and AZeroā€™s solutions, this would be extremely beneficial to me at least.

UI is also a serious concern to me especially regarding Kiltā€™s current offerings. I think a discussion around how UI for the name services is evolving and the idea behind onboarding users is well worth having here.

In the event that multiple name services exist on Polkadot (Kilt and Azero.id will very likely exist together) then it is worth exploring how UIs can support both name services (and others), in the same spirit that dapps support a range of web extension wallets.

1 Like
20

Iā€™m supportive of a unified name system in Polkadot more broadly but very much understand the concerns by other identity systems. Iā€™m no expert on DIDs but I think they as well as something more simpler as you proposed does make sense.

I had one thought I wanted to bring in here: the domain name system was designed to be somewhat decentralized with countries and other organizations managing their own TLD. Couldnā€™t we build something similar where a name can be registered with an identity provider parachain such that the name resolution could happen on that chain giving more flexibility for innovation in identity systems to happen and for example for Kilt to be able to offer the DID compliant names on top of what you are proposing?

2 Likes