How to address things on blockchains

Generally, addressing something means to unambiguously identify it. The address should also contain some information that helps to find the addressed thing. An email inbox is identified by an email address, the server is noted after the @-sign, a paper letter is addressed with name of recipient, street, number, ZIP-Code, city and country. In this example, the goal is to ensure that a message sent to an address can in principle reach its target and won’t accidentally go anywhere else. Additionally, when talking about a thing, addressing it unambiguously makes sure everyone is talking about the same. Addressing becomes identifying. In case of the ACTUS protocol, a protocol for finance on blockchain, unambiguous addressing is important to reference an asset across chains, in legal documents and compliance procedures.

At the first glance it’s an easy one, at least for Ethereum: just provide the address of a contract or an externally owned wallet and you’re good. But, unfortunately, it’s not that easy if we assume a multi-chain, multi-fork future.

Here are some of the challenges:

Today’s solution

Let’s take an interesting ERC-20 compatible token, the DAI stable coin, as an example and build and address schema for it.

protocol:some-on-chain-identifier

This becomes variant #1:

ethereum:0x89d2...0359

(the dots are there for readability and represent the missing hex characters, ENS could also be used)

This is basically what is done today. You select the name of the blockchain in a tool like MetaMask and then send Ether to an account with a certain address.

It works today, because ambiguity is still limited. In a multi-chain, multi-fork ecosystem, this won’t be the case.

The challenge

Darn! Ethereum and Bitcoin have already forked several times! Even though only one alternative Ethereum history has been long term sustainable (Ethereum Classic), there may and likely will be others in future. If I say: pay 5 ETH to my address 0x… on "Ethereum" — can you be sure to what fork it should go? Ethereum has concepts to separate different Ethereum based chains: chain IDs and network IDs . Chain IDs are mainly a measure against replay-attacks . They are part of transaction signing and will make sure that a transaction is only valid on a network with the specified chain ID. Ethereum’s mainnet chain ID is 1, ETC’s chain ID is 61. The network ID is 1 on both networks, though. This gives us a new way to address the DAI token contract for variant #2:

ethereum:0x89d2...0359?network-id=1&chain-id=1

This is a bit better — but there are some new problems which lead us to discard this solution:

Hash based addressing

So we need a more universal solution. Ethereum mainnet is a blockchain that started on July 30th, 2015 with the block number 0 and block hash 0xd4e5...8fa3 . The block hash in Ethereum is the Keccac 256 hash of the block’s header data. It’s (near) impossible to create a different piece of data that will result in the same hash. Thus, we can identify a blockchain with the security level of that blockchain by referring to a hash of a data item in the chain, e.g a block hash, or a transaction hash.

protocol:some-on-chain-identifier?with-block-hash=0x...

ethereum:0x89d2...0359?with-block-hash=0x91b3...1aa8

Variant #3 states:

I’m addressing an Ethereum blockchain that contains a block with the hash 0x91b3...1aa8. On that blockchain I specifically refer to the contract with the address 0x89d2...0359.

The annoying phenomenon of forks

In the above illustration of a fork it’s visible that contract A is part of the history of both, the yellow and the purple chain while contract B is only part of the purple chain. If you address contract A as shown in Variant A, the asset it represents, e.g. a token, will exist on both chains. Its balances and execution rules may be different, though. To make this unambiguous, one could address the following way:

protocol:some-on-chain-identifier?recent-blockhash=0x...

ethereum:0x89d2...0359?recent-blockchash=0x455b...7578

This variant #4 ensures that only a blockchain is addressed that contains a hash which exists at a recent state of https://medium.com/at-par the chain. The recent-block-hash parameter must be as up to date as possible (but as final as necessary) to minimize the ambiguity risk.

Resolving addresses

The above schemes 3 & 4 lead to addresses consisting of multiple hashes, each 256 byte long (on Ethereum). Unfortunately, these hashes don’t contain any information to help identify the blockchain fork actually containing them. One way to solve this is a resolve service. It can be done by centralized provider like ITSA that provides the necessary information to identify and asset. Or it can be a key-value store on a decentralized service (e.g. IPFS) that takes a hash and resolves it to a blockchain including a proof of its existence there. The resolve service becomes more efficient by adding the first block hash of a chain to the address. This reduces the search space to forks of the blockchain with that genesis block .

Fork-resistant addresses

We have reduced the problem to finding the earliest block hash on a chain, the latest known block hash on that chain which is believed to be final and an identifier, e.g. a transaction hash or a smart contract address. The age of the latest hash is a parameter to the fork risk of the address.

Addressing the DAO token on Ethereum mainnet

a) Address of item: 0x89d2...0359 b) Earliest known hash: 0xd4e5...8fa3 c) Latest known hash: 0x3743...3348

Variant 5: ethereum:0x89d2...0359?early-block-hash=0xd4e5...8fa3&recent-block-hash=0x3743...3348

Revisiting the illustration from the beginning of this article we can unambiguously address contract A in the purple fork at block time of block #5 by referencing

To verify the address there needs to exist a valid hash-chain from hashOf(block 0) to hashOf(block 5) AND _addressOf(contract A) _ must exist in that chain’s history. However, the purple chain may fork again some time in the future and could make the address ambiguous, again.

Using the address

Say you have received an address for a blockchain asset and have successfully resolved it to a debt token contract (e.g. an ACTUS Principal at Maturity contract or a Dharma debt token) on mainnet Ethereum, using an IPFS or ITIN based resolver. In order to buy a share of that contract you will have to actually interact with the correct network. The tool that you use to make the transaction could do the following to assist you:

Conclusion

Addressing on blockchains is far from solved. None of the approaches known to me are satisfactory, yet. If we don’t solve this properly, there could be instances of “blockchain fishing” in the future — a new branch of scams that impersonates a whole chain. To deal with this proactively, we need to raise awareness and cooperate on solutions. We look forward to and are actively supporting standardization efforts such as ITSA and multiaddr .

In this article we looked at addressing blockchains and accounting for forks. Intentional or unintentional network splits, finality related challenges, sub contract addressing and connecting to the nodes network are further challenges that will be investigated in another post.

Subscribe to the at par blog to be notified.

Disclaimer

The author is affiliated with ConsenSys AG and atpar AG . All opinions are his own an not opinions of the companies. No investment advice.