Implementing HRAs

Implementing Human Readable Addresses in a user-friendly and expedient way is often considered as the hallmark of the cryptocurrency arms-race to user adaption.

On-Chain HRAs

One very basic method to implement HRAs is to use a burnable address format. A burnable address format is where a small amount of currency is burned in a transaction to create a hard link between an address to an HRA.

For example, a very basic implementation within a transaction structure could look like:

On-Chain HRAs are very simple to implement and are a simple way to get started with human-readable addresses

Tracking hard links can be an easy process (by scanning the blockchain for triggers to detect HRA transactions)

Keeping an internal list of hard links can be done simply

Having an HRA be treated as a unique key and “throwing” all further transactions attempting to claim the header can be done both locally or through full node “info” requests

The Cons of On-Chain HRAs

On-Chain HRAs are not a scalable method for long term use, over long periods of time, the increase in data per address generating transaction could add up significantly both through the increase in chain-size on devices and through the increased size in the average transaction (through the address generation)

The processing power that would be needed to scan both previously generated and new blocks would build up and could become a time-consuming process

The fee needed to initiate a transaction could be seen as a roadblock to new users

Shared State HRAs

Another solution to implement HRAs is using a Shared State across all nodes, not dissimilar to Hedera Hashgraph’s Gossip within a Gossip implementation.

Creating a directed, acyclical graph (DAG) with cryptographic proofs to allow for claiming of HRAs could be an quick and easy way to create a scaling solution. On top of that, making requirements on signing processes and balance requirements can allow for simplified spam protection.

The Benefits of Shared State HRAs

Simplified Implementation

Spam Protection via Balance Requirements

Low-Data Usage

Easily Referable on Mobile and SPV Devices

Secure and Flexible Process

The Cons of Shared State HRAs

Implementations require an off-chain solution

Not Replayable on a Blockchain as State Changes are unlikely to be stored

Can be Cost Prohibitive Depending on Complexity

Conclusion

Out of the two solutions mentioned, Shared State HRAs sound by far to be most scalable option, despite the known issues on both replay-ability and being Off-chain.

On-Chain HRAs can still be a good solution for limited or bespoke uses such as creating an HRA for developer donations.

Interested in implementing HRAs onto your Blockchain? Arcadia can help you on your implementation journey!

Software Development can be a costly, clustered, and complicated process. This goes doubly so for machine learning and blockchain projects. While this is often the case in projects industry wide, with Arcadia it doesn’t have to be.

Never miss a story from The Arcadia Group, when you sign up for Medium. Learn more