Why Does Interoperability Matter?

Distributed systems have to make trade-offs to function effectively in an asynchronous environment like the internet — one without a global clock to define the ordering of events. Blockchain-based networks, designed to carry immense value, must also guard against malicious, or byzantine, actors. At the consensus level, these trade-offs can include limiting the number of participating nodes to provide consistent ordering of events between them (as in DPOS, PBFT algos), or adopting a probabilistic view of the ordering to ensure the continued functioning of the network (Nakamoto consensus). At the application level, trade-offs exist around the expressiveness of a blockchain network’s programming capabilities, as the size of its design space is correlated with the size of its attack surface. The list goes on…

The point is that there is no one-size-fits-all solution for blockchains and each distinct combination of designs offers differences in security, privacy, efficiency, flexibility, platform complexity, developer ease-of-use and even political values. There will be times when some properties are more beneficial than others; for instance, sending one $1M payment requires a different level of security and scalability than sending one million $0.01 payments, and a different set of features than issuing a digital collectible in a video game. The Internet of Value, then, will be most useful if it accommodates the full spectrum of use cases — something that may be impossible, and is at the very least impractical, with one blockchain alone.

To contextualize this: Bitcoin can’t speak the language of Ethereum and vice versa. This means we can’t spend bitcoin on the Ethereum network, nor can we make use of Ethereum’s smart contracts on the Bitcoin network. As blockchains march toward the future in increasing numbers, the need for interoperability grows.

Strong interoperability could shield users from the the trade-offs that blockchains make and allow them to interchangeably leverage the optimizations of different consensus mechanisms and virtual machines, in many cases off-loading tasks that are better accomplished on other chains and letting each focus on its core competencies. If we end up in a world of many blockchains, interoperability can make them more useful, user-friendly, efficient and scalable.

So How Do We Get Interoperability?

First, to describe how we get interoperability, we need to be a little more specific about what it means. In this context, interoperability can be split into two categories:

1. Exchange of digital assets — for example, making bitcoin spendable in Ethereum dApps
2. Exchange of arbitrary data — such as making payments to a supplier on Ethereum based on the GPS location of an asset tracked on Stellar

Exchanging digital assets can mean a number of things, so let’s call it the ability to transfer and exchange assets originating from different blockchains, without trusted intermediaries (e.g. centralized exchanges). This functionality can be constructed atop blockchains that have fairly simple programming capabilities, as users on both sides can easily produce publicly verifiable signatures for actions that enable atomic transfers, or transfers that only complete if both sides do their part.

Exchanging arbitrary data (a superset of exchanging digital assets) can be thought of as the ability to make advanced blockchain-to-blockchain API calls, which can go as far as having smart contract code on one chain verify the consensus finality of events on other chains directly. This ability lets us use data on one chain to effect state changes on another, as in the example above. It also lets us create synthetic versions on one chain of an asset that is home to another chain, making that asset usable on a state machine that occupies a different part of the trade-off space. This is the more difficult type of interoperability, as most blockchains are passive systems that can’t produce a signature that can be easily verified by others, and thus need more complex proofs about their state to be understood by outside parties. However, this category of interoperability can enable a broader swath of use cases than value transfer alone.

There are exciting projects across both categories, some focusing on value transfer alone and others with broader ambitions of unlocking full cross-chain communication. As with blockchains themselves, these projects make their own set of trade-offs, mainly with respect to their levels of trust-minimization and compatibility with existing networks. It’s worth noting upfront that these are not mutually exclusive solutions and can in many cases be integrated with one another.

As Vitalik notes in this paper on chain interoperability, there are 3 primary technical approaches to achieving interoperability:

1. Notary schemes (exchange of arbitrary data)
2. Relays (exchange of arbitrary data)
3. Hashed timelocks (exchange of digital assets only)

I’ll briefly touch on notary schemes, but will focus a bit more on projects implementing relays and hashed timelock contracts.

Notary Schemes

Notary schemes employ a trusted federation to attest to events on another chain. This federation will verify to chain A that an event on chain B took place or that some statement about chain B is true. The notaries will come to agreement through some consensus algorithm and will then issue a signature that can be used to finalize payments on chain A conditional on this consensus. This type of scheme can be used to implement what’s known as a federated pegged sidechain, where the federation will be in control of a multisig address on chain A, such that assets locked up in the multisig can be issued synthetically on the sidechain (chain B) — making them usable on a different state machine. This has been implemented in Liquid, a BTC-backed sidechain created by Blockstream, that makes it possible to spend synthetic bitcoin on a ledger that has the functionality to issue new digital assets.

Notary schemes are one of the simplest ways to achieve the full suite of cross-chain interoperability, however they come at the cost of placing trust in a federation of notaries. They are useful insofar as their trust model is acceptable — a premise that may limit their social scalability, a concept described by Nick Szabo as perhaps the most valuable advantage of blockchains over traditional methods of record-keeping.

Relays

Instead of having a federation that verifies events on another chain, relays allow the chains to do this themselves. A relay is a contract on chain A that functions as a light client of chain B, using chain B’s standard verification procedure to verify block headers fed into the contract. This gives chain A the ability to understand event changes on chain B — an ability that can be used to create lots of interesting cross-chain applications. For example, BTCRelay is a smart contract on Ethereum that can read the Bitcoin chain. It has been used to create applications such as EthereumLottery, where the lottery used Bitcoin block headers as a source of randomness. However, with BTCRelay, interoperability is one-way; Bitcoin can’t read the Ethereum chain as there is no Ethereum relay contract on Bitcoin.

Several projects are working on relay architectures that enable two-way interoperability between chains, through a central hub called a relay chain. Relay chains are distinct blockchains that function as light clients for connected “member” blockchains. Member chains can leverage information on other chains by messaging through the relay chain, which tracks part of the state of all connected chains and can be given a degree of control over assets on those chains. For example, a member chain could give the relay chain validators control over a multisig address that locks up certain assets, and those assets could then be represented synthetically on another member chain. This would allow any member chain to execute transactions on its own state machine using the synthetic versions of assets from different home ledgers.

Relay chain architectures work best with chains that have certain characteristics, including flexible multisig capability and fast consensus finality, and as such are creating software development toolkits that make it easy for developers to create these types of blockchains.

The most prominent efforts in this area are Cosmos and Polkadot, who offer the Cosmos SDK and Substrate SDK, respectively. These SDKs handle basic networking and consensus logic, letting developers focus on implementing business logic rather than being bogged down by the complications of constructing a blockchain. The resulting blockchains are easily compatible with all other blockchains constructed using the same SDK, which can ultimately create an environment where many chains with different state transition logic are interoperable with one another.

The biggest differences between Polkadot and Cosmos lie in the responsibilities of their relay chains and the compositional environment they offer developers. Polkadot has a more complex relay chain where validators are responsible for the validity and availability of member chain blocks. Because the network at whole can be viewed as one unified state machine, it allows for full blockchain-to-blockchain APIs and provides each member chain with a layer of shared security. This also simplifies upgrade processes.

Cosmos, on the other hand, has a simpler relay chain where validators aren’t responsible for the validity or availability of member chain blocks, leaving security to the member chains themselves and providing interoperability between them on an ad hoc basis. The Cosmos relay chain supports sending proof carrying objects between chains rather than arbitrary blockchain-to-blockchain function calls. This means it initially will be limited to cross-chain exchanges of value, but can later extend its functionality to perform more complex cross-chain operations. By limiting the responsibilities of its relay chain, however, Cosmos provides increased flexibility for developers in designing their state machines.

The downside of the relay architecture is that it is very difficult to connect existing blockchains that don’t have the desired characteristics, including both Bitcoin and Ethereum. Cosmos and Polkadot both use variants of proof of stake (POS) and the Practical Byzantine Fault Tolerant (PBFT) family of consensus algorithms, which limit the number of nodes that actively participate in consensus in exchange for increased throughput and fast consensus finality. These are experimental mechanisms and will need to be thoroughly tested in the wild before we can be confident in their ability to provide sufficient security. In light of this, Cosmos and Polkadot present potentially advantageous new paradigms for constructing blockchain networks rather than solutions targeted to existing blockchains.

Hashed Timelocks

The most practical technical approach to interoperability is, as one might expect, also the most limiting in terms of functionality. A hashed timelock contract (HTLC) is a class of blockchain-based payments that uses hashlocks and timelocks to require the receiver of a payment to either acknowledge receipt prior to a deadline or forfeit the ability to claim the payment, returning it to the payer. HTLCs allow for cross-chain atomic swaps and fully funded bi-directional payment channels between assets on certain types of blockchains.

The most prominent use of HTLCs is in the Lightning Network (LN), a protocol that enables high-volume, low-latency micropayments without the need for trusted intermediaries. LN uses HTLCs to create a network of payment channels, where transactions are executed off-chain and the net balances can be settled at any time on the underlying blockchain(s). LN is mostly viewed as a scaling solution for Bitcoin, but because HTLCs allow for cross-chain atomic swaps, it can also enable the exchange of value across connected blockchains. However, these blockchains must be structurally similar to Bitcoin, and LN is currently only compatible with Bitcoin and Litecoin.

The Interledger Protocol (ILP) extends this concept beyond blockchains to any arbitrary payment network. Instead of using actual HTLCs to construct fully funded payment channels, ILP uses an abstracted version of the same logic that doesn’t rely on the underlying network’s native support for HTLCs. ILP is a network of entities called connectors that handle currency exchanges and route payments through payment channels between one another. ILP departs most notably from LN by allowing connectors to extend credit to one another, incurring some counterparty risk in order to increase their payment bandwidth but maintaining the flexibility to settle net balances on-chain intermittently to ensure payment. Importantly, the protocol makes sure that all counterparty risk is borne exclusively by the connectors and isolated from end-users.

ILP simplifies value transfer between payment networks by sending payments in tiny packets through the most efficient route of connectors until they reach their destination. Connectors are akin to translators that can choose which languages they will translate between; it’s as if a message were input in English, broken into words and routed through a network of translators, ultimately being reassembled and output in Chinese. This allows the network to treat all value packets similarly, drawing parallels to how the internet routes packets of data and ultimately enabling streaming payments and microtransactions in any currency — something no blockchain or payment network can presently accomplish.

ILP is a neutral protocol and no configurations have to be made to the networks that are connected to it. This means ILP can serve as a value transfer layer between not only Bitcoin and Ethereum, but also Bitcoin and traditional payment networks and applications like SWIFT and Venmo. However, ILP’s simple and neutral design necessitates that its functionality is limited to value transfer.

Conclusion

In this post I covered why interoperability is growing in importance, broke down the main types of interoperability and gave a brief high-level introduction to some of the key projects that are working to make blockchains communicate as effectively as possible. Each approach that I went through carries a different set of capabilities and limitations.

Notary schemes are the most centralized approach of the three, but are relatively easy to implement and can offer the full spectrum of interoperability. Relays offer similar capabilities in a more trust-minimized setting, but have drawbacks in terms of compatibility with existing networks; ultimately, they present an alternative direction for the evolution of blockchains. HTLCs represent the most trust-less and practical approach of the three, but are limited in scope to the exchange of value, and cannot be used to create synthetic representations of assets on different ledgers.

The most viable and important near-term impact of interoperability, however, is arguably in the exchange of value category, as programmable money is the first real killer app of blockchains. For this reason, I expect HTLC-based approaches (Lightning Network, Interledger) to be the first to gain traction. In fact, these networks may be the catalysts that ultimately make cryptocurrencies usable on a large scale. Relay chains, on the other hand, may have a larger impact on the way new blockchains are built in the future. Importantly, none of these approaches are mutually exclusive. In fact, Interledger is compatible with the Lightning Network, Cosmos and Polkadot, and Cosmos and Polkadot can build bridges between each other. This intertwining of blockchain-based networks is made possible by their reliance on digital signatures and cryptographic proofs, allowing for a close tie-in between payment networks that may ultimately be what defines the Internet of Value.

Thanks to Spencer Bogart, Evan Schwartz and Zaki Manian for helpful feedback and discussions.