Human Readable Addresses on The Koinos Blockchain (Part 1)

Part 1: A Brief History on Human Readable Name Services

This is a three part mini-series presented by BurnKoin, the first mining pool on the Koinos Blockchain. Visit burnkoin.com for more information.

Blockchains identify accounts using a string of alphanumeric characters that have no specific pattern or recognizable words. When we submit transactions, we are told to copy and paste addresses to avoid mistakes, but this isn’t always possible, so we must always verify manually.

Manual verification of the full address is cumbersome, so we often settle on verifying just the last 5 (if not, more!) characters and assume the rest is the same, but this is hardly the best solution, especially as blockchains become increasingly more feature packed and complex.

Take the image below for example. How long does it take to verify that the two images are actually the same, if they even are?

Are these images the same? It’s unlikely you’ll be unable to perform any other tasks when trying to verify if the images are the same. This is the same problem all Blockchain users face.

By extension, consider these two address, are they the same or different?

1AdzuXSpC6K9qtXdCBgD5NUpDNwHjMgrc9
1AdzuX5pC6k9qtXdCBgD5NUpDNwHjMgrc9

The lack of human readable names on blockchains create a truly frustrating and nerve wrecking experience for beginners and advance users alike. This becomes more apparent when you experience fake websites that route transactions to disingenuous smart contracts.

To improve the experience, human-readable name services like ENS and Unstoppable Domains (UD) were created on top of smart contract platforms such as Ethereum. Native implementations have also been used on graphene blockchains such as HIVE, EOS, XPR and WAX.

There is no doubt that human readable name services have provided a massive improvement to the user experience but they currently have limitations that need to be overcome for mass adoption.

THE STRUCTURE OF HUMAN READABLE NAMES

Human readable names are simple to decipher, but there are a few things going on in the background that prevent them from being as powerful as they could be due to current implementation limits. Let’s take a brief dive into how they function.

SIMPLE MAPS

On some blockchains, human readable names are much like usernames seen in any centralized service. They are highly individualized and you can choose any string of numbers and characters that represents you. The blockchain associates the human readable name with a wallet address using a simple digital map and are not associated with anything else other than the wallet address that is matched to it. Native implementations may offer more options, but you can never truely customize these features.

Creating, maintaining and adding to these digital maps will consume valuable blockchain resources, which is why account creation is often limited, otherwise the creators would go bankrupt creating user names, but at least they are free to the user, a very important distinction.

Although free, the limitations on accouunt creation prevents the blockchain from leveraging network growth effects. STEEM for example,(the blockchain which HIVE is forked from) once saw an explosion in price causing users to try and sign up on steemit.com. However, due to the resources required to sign up, many potential users were simply rejected.

Furthermore, the user accounts do not go beyond the blockchain itself. An individual user cannot get a unique identity on a dApp without creating and managing a whole other identity.

The handle @motoengineer for example, is my username on HIVE and no matter where I go in the ecosystem and my entire HIVE history travels with me everywhere I go on HIVE. I am @motoengineer unless I create another entire account.

COMPLEX MAPPING WITH NFTs

Human readable names services, such as ENS, offer a much more complete and feature rich system since they are managed through smart contracts and NFTs, allowing them to improve without under going a hard fork like their blockchain native counter parts.

Note: On The Koinos Blockchain, smart contracts have built in upgrade options ranging from the private key holder, through governance, a proxy or fully immutable!

ENS names follow a format that resembles domain names, a pattern that we recognize from the world wide web. They typically involve a Top Level Domain (TLD), Second Level Domain (SLD), and Sub-Domains (SD).

Let’s look at an imaginary human readable domain such as: kui.burnkoin.eth (kui is my first name in case you’re wondering!)

If we knew burnkoin.eth is a genuine address issued by the top level domain, then whenever we interact with the burnkoin smart contract, we simply read the address instead of verifying contract addresses.

This is much like verifying you are on google.com and not g00gle.com.

Furthermore, we can also see that sub-domains can be issued as user names. This means that we can be confident that kui.burnkoin.eth is a real user under burnkoin.eth.

This is also much like knowing you are on the REAL google docs web app because you see doc.google.com not docs.g00gle.com

The ramifications of this will be further discussed in Part 3!

Another example would be kui.eth

By sharing my human readable domain to someone else, they can easily send payment to my wallet by sending it to kui.eth instead of my actual wallet address.

WHICH IS BETTER?

When applications are purpose specific and have a narrow range of operation, simple maps provide a great way to create human readable names to improve the user experience. These maps are cheap and simple to manage and use.

Koinos already employs human readable name services for smart contracts using simple maps for a better developer experience. For example, the VHP token smart contract is mapped to the human readable name “Virtual Hash Power token” and is mapped to 1AdzuXSpC6K9qtXdCBgD5NUpDNwHjMgrc9.

The image below shows several smart contracts with their human readable names and the registered address IDs.

Taken from https://koinosblocks.com/contracts

This provides enhanced developer experience whenever the VHP contract gets upgraded and the original address gets abandoned. dApps don’t need to repoint to the new contract name because the map does it for them!

This is a great example of how simple maps are a great solution for well defined use cases.

However, when applications are broad and require adaptable tools that aren’t well defined yet, NFT type name services like ENS provide a more flexible, organized and tiered method of name management. An added benefit to ENS is that it is a smart contract and anyone can utilize it (permission-less), making it more flexible for dApps to customize to their specific use case.

This simple distinction makes NFT type naming services more flexible and feature rich for dApps.

What does this have to do with Koinos?

Koinos presents a unique opportunity to create a cohesive human readable name system that brings together users, dApps and most importantly Mana.

Now that you have a better understanding of basic human readable name services, we’ll dig into some of the challenges facing these methods in part 2 of this 3 part mini series. Lastly, in part 3, we’ll offer a Koinos native solution that enhances the human readable name experience well beyond what current implementations can offer. Stay tuned!