Blockchain Interoperability — Moving Assets Across Chains
Since Bitcoin emerged as the world’s first peer-to-peer currency, it has become common practice to represent assets on blockchains. Assets may be protocol-level cryptocurrencies, such as Bitcoin and Ether or they may be implemented in smart contracts, in the form of fungible or non-fungible tokens. In any case, there is now a very large eco-system of decentralized assets, represented on a number of different blockchains. Making these blockchains work with each other in a way that allows trading or moving assets between different chains is a challenge, mainly because blockchains are designed to be self-contained ecosystems. Breaching the boundaries this ecosystem introduces risks related to trust and security. Therefore, any blockchain interoperability solution has to be designed carefully.
When dealing with assets on different blockchains, there are two main interoperability scenarios: trading an asset on one chain for another asset on another chain or representing an asset on several chains and moving instances from one chain to another. These two cases are different in nature and need to be implemented differently. Let’s look at the easier case of trading one asset for another first, before discussing strategies for moving assets across chains.
Trading Assets on Separate Chains
Atomic Swaps
Let’s assume Bob wants to make a trade with Alice, buying 10 Ether with 1 Bitcoin. Of course, this is currently a bad deal for Bob, but let’s forget about exchanges rates for a moment and use these numbers for simplicity. Bob and Alice could use a trusted third party to do this trade, for example a centralized cryptocurrency exchange. However, in the true spirit of decentralization, Bob and Alice do not wish to use a middleman and prefer to rely on the built-in trust of the two blockchain protocols involved.
The desired property of the asset swap is atomicity. This means that either both transfer operations happen, or none at all. One of the parties receiving the asset without also transferring the counter value is not an option. The resulting operation is, therefore, called an atomic swap.
Hash-locks
There is a simple strategy that Bob and Alice can use to perform their atomic swap without trusting each other and without relying on a trusted third party. They can use hash-locks on both chains to perform the two transfer operations atomically.
This works as follows: Alice sends Bob 10 Ether through a smart contract. However, the contract is locked with a secret that needs to compute to a hash visible in the contract. Note, that hash functions are one-way functions, so the transaction can only be unlocked by providing the secret only known to Alice at this stage.
Bob now uses the same hash as a lock on a Bitcoin transaction to Alice. He does not know the secret yet, but he knows its hash value. Once Alice sees that Bob has locked the correct amount of Bitcoin with the same hash, she can unlock the Bitcoin transaction by supplying the original secret that computes to the required hash. By doing though, she not only releases the funds but at the same time publishes the secret on the blockchain. Bob, who has now learned the secret, uses it to unlock the Ethereum transaction directed to him.
Timeouts
But what would happen if Alice never unlocked the Bitcoin transaction? Well, both transactions would remain stuck forever. Therefore, atomic swaps require a timeout. If the transaction is not completed by providing a secret within a time t, the funds should be refunded.
In our case, Alice creates the first transaction and creates the secret. Consider the case of the timeouts of both transactions being of equal duration. If Alice waited until just before the timeout, she could cheat Bob by not giving him enough time to unlock the funds destined to him. They would just be refunded to Alice. Therefore, the transaction from Bob to Alice should have a shorter timeout, typically t/2. This ensures that both parties have the same amount of time to unlock their funds.
Protocol Support
Atomic swaps are possible between blockchains that provide the necessary primitives for timeouts and hash-locks. This includes most chains that provide some simple form of smart contracts. Bitcoin’s scripting language is sufficient for this. The instruction set does not have to be Turing complete.
Of course, Bob and Alice, as normal users, should not have to know how to set up an atomic swap manually. Protocols, such as Interledger make implementing atomic swaps easy and allow building systems that facilitate payments across different ledgers.
One problem with atomic swaps is that they are slow, in particular on blockchains with probabilistic finality. Platforms, such as Bitcoin and Ethereum, may occasionally fork, due to blocks being produced simultaneously. This means that transactions may be undone. The probability of this occurring decreases with every block added to the chain. For this reason, Bitcoin transactions are generally considered confirmed after six subsequent block generations. Therefore, atomic swap implementations need to allow for this and not release assets too early.
Portable Assets
One-way and Two-way Pegs
The second use case for blockchain interoperability is moving an asset from one chain to another. The asset may exist on both chains, with the total amount in existence being the constant sum on each chain. This may be useful in a number of scenarios, for example moving a token used in a permissioned blockchain on to a public chain for trading on an exchange, or interfacing two consortium networks with a common asset representation.
In order to implement such a scheme, the asset representation on one chain needs to be pegged to the representation on the other chain. If n tokens are moved from one chain to another, the balance on the source chain must decrease by n tokens and the balance on the destination chain must increase by n tokens simultaneously. The total number of tokens on both chains must remain constant. This is usually achieved by burning or immobilizing tokens on the source chain and minting or unlocking tokens on the destination chain. If the solution only allows moving assets in one direction, such a peg is called a one-way peg. In the case of an asset being moveable in either direction, the beg is called a two-way peg.
Custodian Bridges
Moving tokens from one chain to another introduces a trust issue. This trust issue is quite different from the trust issue resolved by atomic swaps. Trading two different assets on different chains simultaneously requires two individuals to find a way to trust that their two transactions are executed atomically. However, in the case of portable assets the whole network needs to be able to trust a single account to increase its balance on one chain by the same amount as it decreases it on the other chain.
This required trust can be provided by custodians. Custodians are trusted intermediaries that are in charge of locking assets (or burning them) on the source chain and unlocking (or minting) them on the destination chain. Usually, a custodian bridge consists of accounts on each chain, possibly a smart contract. Assets are immobilized on one chain by locking them into the custodian account and simultaneously unlocked by the custodian account on the other chain. For this to work, the total supply of a token essentially exists twice, once on each chain. On each chain, the custodian account immobilizes exactly the same amount as the number of tokens in circulation on the other chain.
Single Custodians versus Multi-signature Federations
Single custodian accounts require a centralized trusted third party to act as a notary. This may be acceptable in some circumstances, for example, in the case of two consortium chains interfacing through a regulator. However, in general, trusted third parties are contrary to the blockchain principles of decentralization and trustless operations.
Therefore, a common solution is to turn the custodian account into a multi-signature account and to use several notaries. A majority of notaries must agree to lock or unlock funds. Choosing these notaries wisely is very important. We will discuss further on this article how some blockchain frameworks designed for interoperability deal with this issue.
Relay Solutions
Relays are systems implemented on one blockchain that allow events and state on another blockchain to be read and validated. They tend to make use of Merkle trees and Merkle proofs or similar cryptographic concepts. Transactions can be cryptographically referenced using such as data-structure. Any changes are detectable by executing cryptographic proofs. Transactions that are relayed can be cryptographically verified.
Relays can be used to connect sidechains to existing blockchains. Plasma is a solution for implementing sidechains connected to the Ethereum network.
Interoperable Blockchain Frameworks
Multi-chain Solutions
Some more recent blockchains are designed as frameworks to build networks of blockchains. Polkadot, Cosmos and THORchain are emerging multi-chain architectures, designed for interoperability. These three platforms can be used to implement networks of blockchains. This is made possible by incorporating relay technology and multi-signature custodian bridges into the protocol architecture.
The three platforms can be used to build asset exchange networks and decentralized exchanges with various degrees of specialization. However, whilst Cosmos and Polkadot are more general purpose, THORChain is optimized for cross-chain asset trading and decentralized exchanges.
This specialization is not just evident in the efficient multi-chain architecture but also by the fact that Continuous Liquidity Pools are built into the protocol as a means of providing liquidity.
Chain Relays
Polkadot, Cosmos and THORChain rely on a root chain that acts as a gateway for a number of parallel chains to communicate. This approach is very similar to side-chain relays but built into the protocol.
Essentially, the root chain stores Merkle roots of transactions that occur on individual chains. It also provides an incentive layer for validators and acts as a way of verifying cross chain transactions.
This allows compatible chains to directly connect to other compatible chains at the protocol level and form a network of blockchains. These native chains may be very different in nature, but all provide block finality to ensure cross-chain transactions are fast and secure.
Connecting External Chains
In order to connect to existing blockchains, all three platforms use special native chains that mimic the external legacy chains. Multi-signature custodian bridges are used to move assets from a legacy chain to its native equivalent and vice versa.
Cosmos employs the whole validator set as signatories on multi-signature accounts on external blockchains with which the platform interfaces.
The Bifröst interoperability protocol, designed for THORChain, proposes the creation of bridges with a configurable number of notaries, chosen from the set of validators. The chosen validators are randomly replaced at certain intervals. The signature threshold required for releasing assets is also configurable, with the protocol supporting m of n, n-1 of n and n of n multi-signature schemes. Notary nodes must also relay transactions and report the block height correctly (within a certain threshold), or they are penalized by the staking protocol.
As in the case of atomic swaps, bridges from multi-chain frameworks to external chains have to deal with the fact that some blockchains do not provide true block finality but rely on a probabilistic model. Bridges must act as finality adapters in this case, usually by choosing a reasonable number of added block confirmations as a threshold for pseudo-finality.
Multi-chain solutions also require governance procedures to manage the process of deciding when and how to create interoperability chains to external chains.
Final Thoughts
As we have seen, blockchain interoperability involves various trade-offs between security, consistency, and performance. It is unlikely that one approach can cover all use cases. For instance, enterprise architectures interfacing permissioned consortium chains will have other requirements than decentralized exchange solutions for public networks.
Blockchain architects must, therefore, be aware of a number of techniques. Frameworks and libraries providing the building blocks for blockchain interoperability are beginning to emerge to facilitate such solutions.
At Cryptronics, we specialize in designing reliable and secure blockchain architectures. If you have a blockchain solution and wish to verify security, or require custom design and development for a decentralized application, feel free to contact us.
Disclosure: The author of this article is involved with the THORChain project.
