neonewstoday.com
In the previous article, we introduced the need for user friendly account names in blockchain. Further, we covered the first proposed approach, an alias service. This service would have allowed alias to address mapping and in-contract conversion.
The main drawback was the lack of independent control over aliases. Allowing users to own and trade aliases requires a more complex solution.
Today’s article will introduce this alternate approach, a native name service. Building on the previous design, it introduces domain names as non-fungible tokens. These NFTs are unique, under the control of the lease holder, and tradable by users.
Non-fungible tokens
Before work began on the name service, non-fungible tokens had yet to be introduced on Neo3. This meant a native NFT template needed to be created first. Currently under development, this native NFT implementation acts as the basis for all domain name assets.
Non-fungible tokens are a natural match for domain names. Rather than each being identical copies, they are distinct from each other. Like a typical web domain, two people cannot register the same domain. For example, there is only one Google.com. Additionally, they can be bought and sold like any other commodity.
Neo3’s native NFT contract follows the existing NEP-11 token standard. Alongside some variations, it is currently in use by several contracts on Neo2. NEP-11 defines the basic logic needed to create and manage unique tokens and their various properties.
Once deployed on Neo3, the NEP-11 native contract could also be inherited in other contracts. This could greatly simplify the implementation of other NFT use cases for developers.
Name Service Overview
The proposed name service will allow representation of contract addresses, wallet addresses, and other complex strings in a traditional DNS format. The lowest level is known as the root domain. It can be considered in the same way as top-level domains such as .com or .org on the Internet.
Initially a limited number of root domains will be available. In the current implementation, still under development, the root domains are neo, wallet, dapp, and org. The solution allows for up to three further levels of subdomain.
Starting at the first level (e.g. nnt.neo), these subdomains can be leased and renewed via the NNS contract. Purchasing a domain name lease will create the corresponding NFT, with the purchaser assigned as its owner. The owner can then transfer ownership when desired, which is how trading is enabled.
In its current form, operation of the name service is handled in a native contract. This contract houses three main parts: the name service NFT contract, a registry table, and a resolver.
The core logic of the NNS contract includes all the basic service functionality. This includes the ability to register, renew, and transfer domain names in the form of NEP-11 NFTs. It also adds some methods for setting parameters such as rental price, renewal price, and new root domain registration.
The registry table manages the list of all domain names along with their current owners, the validity period, and other information. It allows the creation of new domains, starting at the first-level. These are valid for a year until renewed. This validity period is then inherited by any second- or third-level subdomains.
The resolver stores resolver instances. These are method groups that enable the domain name to be correctly resolved to its corresponding string. Several record types are already supported, including A records for contract or account addresses and CNAME records for redirection.
User experience
Once complete, users should be able to directly rent first-level domain names by invoking the native contract. However, it is expected that no official contract interface will be added. This isn’t very surprising, as the native name service will also not include its own trading mechanism.
This will likely push development and operation of support infrastructure to third-party teams. For example, Neo core does not include infrastructure to trade NEP-5 tokens. Instead, various exchanges popped up to meet this need. The same result is expected with domain names NFTs. Independent platforms, such as GhostMarket, are likely to compete to provide these facilities.
Such services can also provide interfaces for renting domains from the native contract. We can also expect some wallet providers to add similar options, helping streamline the process. Both options help users by making the functionality accessible and help reduce complexity.
Once the feature is live, users should be able to completely replace their usage of public addresses on Neo. Rather than sending assets to an address like NbnPGLE386Gc6mAqhHeumKbP37zhGPXLzH, transfers and contract interactions could instead be directed to a domain like bob.nnt.neo—much easier to work with and remember!
Preventing impersonation
There are still drawbacks to the service. For example, there is the possibility of impersonation. This is common on the Internet, achieved by creating a visually similar username. Alternatively, sometimes users may squat on names that are usually associated with a known entity. Preventing this type of behavior is an ongoing battle, but there are possible options.
As with the previously proposed alias service, it is possible that domain name NFTs can be bound with a verified identity. This could be provided through NeoID. Using a solution like Vivid, domains could be tightly (or loosely) coupled with various claims/proofs about an identity. This enables customizable levels of assurance that the owner of an alias is who they claim to be.
Further, as was noted by Mengyu Liu, the shift to a domain name resolution opens the door to several potential improvements:
“Because domain name resolution is not only as simple as obtaining an address, many complex resolution logics should be abstracted into this component, such as domain name redirection, format checking, and fuzzy matching.”
Fuzzy matching is also known as approximate string matching. It’s a technique that enables comparison of different strings based on their similarities. It is often employed to help discover certain attacks, such as phishing attempts.
For example, the contract could check for domain name registry attempts with a Levenshtein distance of 1 from an existing domain name.
This would prevent registration of the domain 03.wallet if O3.wallet already existed. There is an obvious downside to this simple solution. It would also exclude registration of similar (but clearly different) domain names, such as larry.neo and harry.neo.
This could be avoided with further restrictions. For example, the contract could check only for cases that use commonly misread characters, such as “I” and “l.”
Layered together, these two rules would prevent registration of dyIan.nnt.neo if the domain dylan.nnt.neo already exists. More complex fuzzy matching logic can be used to reduce the number of false positives in this way.
This concludes the introduction to the Neo3 native name service component. Although the basis of the service appears solid, it is possible that the feature changes again in the future. It should be noted that development on the component has not moved since July. This is likely due to resources being directed towards higher priority aspects of Neo3 core development in the lead up to the launch.