Blockchain Interoperability

Motivations for chain interoperability

Within the public blockchain space, different projects have been staking out different regiions of the tradeoff space between security, privacy, efficiency, flexibility, platform complexity, developer ease of use and even what could only be described as political values.

In the private and consortium chain space, the notion that there exist different chains for different industries - and even different chains within the same industry - is even less controversial and arguably universally understood as obvious.

In such a world, one natural question that emerges is: how do these chain interoperate?

Interoperable chains open up a world where moving assets from one platform to another, or payment-versus-payment and payment-versus-delivery schemes, or accessing information from one chain inside another (e.g., "identity chains" and payment systems) becomes easy and even implementable by third parties without any additional effort required from the operators of the base blockchain protocols.

Classification of interoperability types from a computer-science-theoretic point of view

Interoperability is, to some extent, fundamentally about (reliable) correlation.

Forward causation: chain A can cause an event on chain B (a.k.a., chain B can read chainA; because if something happens on A can cause something to happen on B, it means that B is able to read or observe A such that B is impacted by A)

• Doable by relay and notaries

Reverse causation: chain B can cause an event on chain A

• Doable by relay and notaries

Dependency is when actions on both chains can arise dependently on some additional outside event.

• Doable by hash locking and notaries

Potential use cases of interoperability

Portable Assets

being able to take one unit of Fedcoin (a hypothetical government-issued digital asset) from its "home ledger" that is ultimately authoritative on its ownership, securely move it to another chain, trade it, use it as collateral or otherwise take advantage of it on that chain, and be confident that the option to move the Fedcoin back to its home ledger is always available if desired.

In other words, assets can move back and forth between different blockchains. There should be assurance that when an asset left the chain, it can be accepted to comeback to the chain.

Payment-versus-payment or payment-versus-delivery

This concept is often called "atomic swap": meaning there is a guarantee that either both transfers happen or neither transfer does.

Essentially, the goal is to allow user X to transfer digital asset bundle A to user Y in exchange for Y transferring digital asset bundle B to user X (where A and B are on different chains, and X and Y have accounts on each chain), in a way that is guaranteed to be atomic and secure.

Cross-chain oracles

a smart contract on one chain that performs some action with some address only when it receives proof that an identity oracle on another chain specifies that the address is a particular unique identity.

Note that the chain being read does not change over the course of this kind of interoperation event.

Asset encumbrance

Lock up asset bundle A on chain X and have locking conditions be dependent on activity on chain Y

General cross-chain contracts

For example, paying dividends on chain X to holders of an asset whose ownership is registered on chain Y

On terminology

On sidechain

The word "sidechain" is often used in reference to cross-chain portable digital assets, although much of the use of this language is misleading and confusing in several ways:

"a side chain is a blockchain that validates data from other blockchains"

The phrase "chain A is a sidechain of chain B" implies a relationship of subservience that in many case cannot be reasonably said to exist.

Hence, it is arguably better to use phrases such as "chain B can read chain A", a "relay of chain A exists on chain B", or "D is a cross-chain portable digital asset with home ledger A that can also be used on chain B", rather than talking about whether or not a given chain is a "sidechain".

Strategies for chain interoperability

Centralized or multig notary schemes

A party or a group of parties agree to carry out an action on chain B when some event on chain A takes place.

How a notary mechanism work: a trusted entity or set of entities that is trusted as a group is used in order to claim to chain X that a given event on chain Y took place, or that a particular claim about chain Y is true.

• Example: Interledger project developed by Ripple
  • Use Byzantine-fault-tolerant consensus algorithm in order to achieve consensus among a set of notaries on whether or not a given event took place
  • Then issues a signature that can be used to finalize payments conditional on this consensus.

Another related scheme: federated pegged sidechain:

• Purpose: for having cross-chain-moveable assets
• The pegging in one or both directions is accomplished by means of a multisig scheme.
• Example: Liquid, a BTC-backed sidechain
  • One can move BTC into a multisig address controlled by a federation of participants in order to receive a token on the Liquid chain
  • The token is conjured into existence on the Liquid chain once the Liquid chain consensus sees that the BTC transaction has taken place.
  • The pegged token then can be freely traded on the Liquid
  • One can destroy the tokens. At that point, the federation that controls the multisig will send an equivalent amount of BTC from the multisig to the party that destroyed the token (i.e., 1-for-1 backing).

Sidechains / Relays

Systems inside of one blockchain that can validate and read events and / or state in other blockchains.

Relays are a more direct method for facilitating interoperability, where instead of relying on trusted intermediaries to provide inforamtion about one chain to another, the chains effectively take on the task of doing that themselves.

Think of relays as oracles or smart contracts that relay the detail of one blockchain to another, so that smart contracts on the other blockchain can access these details.

How relays work:

• Context:
  • Suppose that a smart contract executing on chain B wants to learn that either a particular event took place on chainA, or that some particular object in the state of chain A contained some value at some particular time.
  • Suppose also that chain A is designed similarly to Bitcoin or Ethereum in that it has a notion of blocks and block headers, where a block header is a compact piece of information that represents the block in some cryptographically authenticated way.
• Process: essentially running a light client verification inside a smart contract on a chain.
  • Create a contract on chain B that take block headers of chain A and use the standard verification procedure of A to verify those headers (e.g., verifying proof-of-work, verifying that 2/3 of validators' signatures have signed the blockchain header)
  • Once the relay have verified that the block header has been finalized, the relay can then verify any desired transaction, or account / state entry, separately by verifying a single branch of the Merkle tree against the block header.
    • A smart contract on a relay on chain B that wants to verify a particular transaction, event or state information on chain A would verify a branch of the cryptographic hash tree of chain A, then verify the block header that the root of this branch is inside, and if both checks pass it would accept that the transaction, event or state information is correct.
    • Noted that these relevant bits of data (i.e., from the Merkle tree) must be fed into chain B by a user.
  • Example: BTCRelay: a smart contract on Ethereum that can read the Bitcoin chain.

Weaknesses of relays:

• Race condition attack
  • Scenario:
    • Party A wants to sell 50 ETH for 1 BTC and deposits the 50 ETH into a contract that essentially says "whoever provides a proof that they sent 1 BTC to address X gets 50 ETH"
    • Party B comes along and send the 1 BTC
  • Attack:
    • Party A can themselves send 1 BTC into their own contract and try to claim the ETH from themselves before party B can
    • With some probability, party A might be able to redeem the proof and get 50 ETH out of the contract before B, leaving A with 2 BTC and 50 ETH and B with nothing.
• Asynchrony: if one or both chains are using a consensus algorithm that finalizes slowly, it takes a long time for one chain to verify that the other chain consensus on some operation, thus limiting the speed of cross-chain operations.
  • Thus, relays can work very well on chains that have rapid finality, but not good when the networks are slow

Hash-locking

Setting up operations on chain A and chain B that have the same trigger, usually the revelation of the preimage of a particular hash.

Hash-locking is a technique for achieving cross-chain atomic operations without requiring blockchains to know much about each other.

How hash-locking works:

1. A generates a random secret $s$, and computes the hash of the secret, $hash(s) = h$ and send $h$ to B.
2. A and B both lock their asset into a smart contract (A locks first, B locks after seeing A's asset successfully locked). It means that two contracts exist. The following rules apply:
   1. On A's side, if the secret is provided within 2X seconds, then the asset is transferred to B, otherwise, the asset is sent back to A
   2. On B's side, if the correct secret (i.e., the value whose hash is h) is provided within X seconds, then the asset is transferred to A, otherwise it is sent back to B
3. A reveals the secret within X seconds in order to claim the asset from B's contract.

Note that this is provably atomic. If A reveals s within X seconds, then this provides at least an X second window within which B can claim their asset. A could make a mistake and reveal s too late, preventing them from recovering their own asset, but this would be their own fault and is easily avoidable. If A reveals s between X seconds and 2X seconds, then A would not get their asset but B does, but once again this would be A's fault. If A reveals s after 2X seconds (or never), then both sides recover their own asset. If A never locks their asset, B doesn't lock their asset either. If B doesn't lock their asset (or locks it incorrectly, eg. with the wrong deadline for s), A can simply never reveal s, and thereby recover their asset.

Note that hash locking is only useful for atomic operations; it is not useful for asset portability or cross-chain oracle use cases.

The reason why it is not ueful for cross-chain oracle use cases is simple: accessing a cross-chain oracle is inherently a passive operation with respect to the chain that is being read, and hash-locking is an inherently active operation on both sides.

The reason why it is not useful for asset portability is somewhat more subtle: the hash-lock atomic swap protocol preserves the invariant that the total supply of each asset on each chain remains the same, and hence it cannot actually move assets from one chain to another.

(In other words, the swap assumes a fair exchange: some assets from one chain for some other assets on the other chain. Asset portability means that the supply of assets would be reduced from one chain and increased on the other chain, as the assets cross the chain.)

Security issues (to be moved to a proper file later):

• Race condition attacks: (impacting relay and similar kind of solutions)
  • Scenario:
    • Party A wants to sell 50 ETH for 1 BTC and deposits the 50 ETH into a contract that essentially says "whoever provides a proof that they sent 1 BTC to address X gets 50 ETH"
    • Party B comes along and send the 1 BTC
  • Attack:
    • Party A can themselves send 1 BTC into their own contract and try to claim the ETH from themselves before party B can
    • With some probability, party A might be able to redeem the proof and get 50 ETH out of the contract before B, leaving A with 2 BTC and 50 ETH and B with nothing.

Research topics (to be moved to a proper file later):

Cross-chain hash locking can also be combined with state channel techniques in order to create faster exchanges that mitigate [the exchange rate fluctuation] problem by taking advantage of state channel's greater speed compared to the base blockchain layer; this is still an active area of research and development.

Other good points to file for later consideration:

Legal contracts are not absolute; they depend on both the reliability of the underlying legal system and the solvency of the participants, and so come approach will be required for evaluating their reliability. Arguably, a large part of the value proposal of "collateralised smart contracts" in general is that while purely economic guarantees are in some ways less powerful than legal ones, it is much easier to see and formally evaluate exactly how strong they are, so techniques that rely purely the "wet code" of law should be used carefully. Combining legal agreements with decentralisation (requiring multiple parties to act in some way and relying on only a majority of them to be honest) is another possible middle road.