Implementing HRAs

A DAG (Source)

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:

[{“txid”:”txid here”,
“vout”:number}]’
‘{“data”:”<HRA:3H812iH5mUzjQN7BnDN5oVHnmXhN9J3sC8:@HumanReadableAddress”,
“Change Address”:changeaddress}’]

The Benefits of On-Chain HRAs

  • 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!

You can reach myself at rasikh@arcadiamgroup.com or checkout our website here