Road to Neo3: User friendly account names

One of the most useful things about a blockchain network is that anyone can create and own an “account” by generating a cryptographic keypair. The use of cryptography for authentication means that everyone can access network resources. They are always globally available to anyone with an Internet connection.

That’s a big win for creating equal opportunity, but keypairs come with usability issues. The most challenging problem is the associated personal responsibility. Users must find a way to safeguard private keys or corresponding seed words. If their security fails, they could lose access to their assets or have them stolen.

Another prominent issue involves the public keys themselves. They are usually long and confusing strings of characters, making blockchain interaction difficult. They are more error-prone than bank account numbers or email addresses, so accidental transfers are more likely to occur.

Neo developers are working on a native domain service to improve on this design. Users will be able to map their addresses to easy-to-use domain names. This provides native compatibility at the protocol level, improving on third party solutions.

Base58 encoding

Users of Neo and other blockchains are unlikely to have interacted with an actual public key. Most users are instead familiar with public addresses, encoded representations of these keys. These addresses are designed to be a little easier to work with.

The Base58 format enabled this first step towards human readable addresses. Invented by Satoshi Nakamoto, it was first implemented in Bitcoin. Like Base64, it converts binary data to ASCII characters, with a key difference intended to improve the readability of the output.

The difference is the exclusion of six problematic characters. Four are characters that may appear similar in some fonts, “0” vs “O” and “i” vs “l”. The other two are non-alphanumeric characters, usually “+” and “/” in most Base64 implementations. 

As a result, the output of Base58 encoding is immediately more user friendly. For example, consider the Neo3 public key 02f68dd3c2966a890c8968fb9f71e55ab48dc99889b179fbd6a188056fc999c1e0. After processing, the last step being Base58 encoding, the final form is NbnPGLE386Gc6mAqhHeumKbP37zhGPXLzH.

There are a few other side benefits too. Satoshi himself commented on these in Bitcoin’s Base58 implementation:

Neo also inherits another feature of Bitcoin’s Base58 implementation, extra checksum steps. Four-bytes of error-checking code derived using SHA-256 make it possible to detect certain errors, a benefit that was noted during opposition to a proposal to remove Base58 from Neo3.

Alias service proposal

Base58 is a step in the right direction, helping make addresses quick to recognize. Despite this, data entry for transactions can still be intimidating. Even seasoned users often perform test transfers before feeling safe to move a hefty sum.

For blockchain applications to be accessible to the masses, further improvements are required. Some third-party solutions have evolved to meet this demand, such as Ethereum Name Service or its Neo-based counterpart by NEL. The downside to these services is that they are not standardized or native to the protocol. This means they are only available in applications that choose to integrate them.

The addition of native contracts in Neo3 enables the possibility of custom account name support at the protocol level. Every Neo-based application would be able to support these aliases without dependencies. A native solution would make the entire platform more user-friendly.

Discussions regarding this requirement first started at the Neo Community Assembly in 2019. Mengyu Liu, an NGD software developer, would later provide the first proposed solution.

The proposal was for a service that would let users create and bind memorable aliases to an address. To prevent impersonation, it would link together with NeoID for checking authenticity. These aliases could be registered, deleted, and modified through the native contract or service. Additional functions would be included for converting between aliases and addresses.

Several advantages were noted; the service should be lightweight and have simple economics. It would also be easy to use for developers, who could call it in-contract through the interop API.

The alias service proposal met many of the intended goals of the initial discussions. However, the approach was abandoned in favor of a DNS-style domain service. Implemented as a native contract, this service would allow users to manage their own domain names more easily. In the next article we’ll explore the design of this solution, currently under review for Neo3.