Blockchain Interoperability: An Introductory Guide

Around ten months ago we wrote in this blog post that all the research up to blockchain interoperability was completed. As explained back then, the main focus of the Research Team has been on the last protocol roadmap phase since the beginning of 2020. The goal is to deliver a scalable and decentralized blockchain interoperability solution for the Lisk ecosystem.

In the next few months, we will be disclosing all the details of this research and the Lisk interoperability solution. However, before that, let’s first see what blockchain interoperability is and why it is a critical concept in our industry. To explain this, we will give a technical introduction to the topic, the use cases, required properties, and the main techniques to achieve blockchain interoperability.

What is Blockchain Interoperability?

Blockchain interoperability is becoming the holy grail to unlock the wide adoption of blockchain technology and decentralized finance (DeFi). In the last year(s), this term has appeared in many specialized news portals, research papers, and the roadmap of many blockchain projects. In general terms, blockchain interoperability is defined as the ability of two blockchains to transmit information from one to the other.

More precisely, we say that two blockchains are interoperable if a transaction or state transition of one chain can depend on a transaction or state transition of the other chain. This general scenario is depicted in the figure below: The transaction, t1 or the state transition, s1 in chain 1 can cause a transaction t2 in chain 2. The same idea applies in the other direction for t’2 and s’2 in chain 2 and t’1 in chain 1.

A common example of this scenario is a basic cross-chain token transfer. Let’s say we are in the Lisk ecosystem where chain 1 is the Lisk mainchain and chain 2 is an existing sidechain. In this case, a user submits t1 to transfer 100 LSK tokens from the mainchain to the sidechain, and t2 credits 100 LSK tokens into the corresponding user account on the sidechain.

However, blockchain interoperability extends further beyond this example and it can be achieved in several ways with different trade-offs and for different use cases.

Why Blockchain Interoperability?

Blockchains were conceived to be self-sufficient decentralized ledgers, where the validity of any state transition, i.e., transactions and blocks, only depends on the history of the blockchain itself. This means that blockchains are independent and self-contained, which implies certain limitations:

• Limited and isolated use cases: Most existing blockchain applications serve specific use cases, from payment networks to decentralized storage systems. However, these blockchain applications will only thrive in the context of a general framework, i.e., an ecosystem, where users have access to all the different functionalities without friction.
  
  A good example is the DeFi ecosystem, which can only achieve mass adoption if users can access the set of financial tools as easily as in legacy financial systems. One may say that a single general blockchain can serve many use cases too, but then it may face a second problem: scalability.
• Limited scalability: An independent blockchain has limited capacity in the number of transactions it can process in a certain time. On-chain scaling solutions, like increasing the block size, are a valid first approach but will eventually end up facing the original problem.
  
  This can be greatly improved with interoperability since the application can scale with the number of interconnected blockchains. As an example, if a blockchain has a capacity of 15 transactions per second, n interconnected blockchains of the same nature will allow up to n × 15 transactions per second.

A solid solution to interconnect blockchains can help to improve, or even completely solve these limitations. Different blockchain applications will be able to interoperate and merge their functionality for end-users, whereas well-established but overloaded blockchains will be able to use other chains as layer-2 solutions.

So, what do we need for a blockchain interoperability solution to be solid? We can summarize the main properties needed for blockchain interoperability in the following points:

• Atomicity: When a cross-chain interaction happens, its effects are applied in both blockchains or none. Similar to the concept in databases, the interaction between blockchains cannot happen partially, it is an “all or nothing” event.
• Consistency: The interconnected blockchains have a certain history, condensed in their state, which is consistent across all chains. This implies for example that user funds can be safely transferred from chain to chain as long as the connected chains are secure.
• Decentralized and trustless: The interoperability solution does not depend on a single trusted actor. There should be well-defined incentives in the interoperability protocol so that the trust that its participants need to put into each other is minimized.

With these required properties in mind, the Lisk interoperability solution aims to establish a permissionless ecosystem of interoperable and decentralized blockchain applications. This will be the topic of our next blog post. For the moment, let’s see an outline of the different interoperability techniques so we can later frame Lisk’s approach and its expected functionalities. 

Types of Interoperability

Previously, we have shown a basic example of a cross-chain token transfer. This may appear as the typical scenario, but it is only one way to have an interaction between two chains. Here we present types of blockchain interoperability from the point of view of the functionality they enable: From the simplest one, cross-chain token exchanges, to the one that achieves a greater functionality in exchange for higher complexity, general cross-chain messages. We also give real examples of each of them so we can have a fair picture of this topic in the industry.

Cross-Chain Token Exchange

In this framework, we assume that there are two different parties interested in doing an exchange of tokens. In general, this can also happen in the same blockchain, but here we are interested in the scenario of users exchanging tokens in different chains, for example, BTC to LSK. This may also be thought of as a trade or swap of tokens since the final objective is to obtain some tokens from another user, the counterparty in another chain.

Atomic Swaps with HTLCs

A common technique for cross-chain token exchanges is atomic swaps.

To achieve a trustless swap between the two users, atomic swaps implement Hash Time-Locked Contracts (HTLC). HTLCs are time-bound smart contracts that involve locking the tokens to be exchanged and unlocking them only by revealing cryptographic proof, which can be verified by both parties. As they are time-bound, if the proof is not revealed on time by the party who initiated the exchange, the swap does not happen.

This way, atomic swaps do not require any trust between users. Apart from swaps between different chains, HTLCs are also used for layer-2 off-chain scaling solutions like the Lightning Network.

In the diagram above we can see how Alice (A) performs an atomic swap with Bob (B):

1. First, Alice submits a HTLC transaction in chain 1 with Bob as the recipient and a hash.
2. Bob performs a similar transaction in chain 2 with Alice as the recipient and the same hash.
3. Alice claims the tokens in chain 2 by revealing the hash preimage on time.
4. Bob claims the tokens in chain 1 by using the same hash preimage.

Atomic swaps based on HTLCs are simple to implement and trustless in nature. They have been used in several projects, such as Litecoin and Monero, as a means of swapping them for Bitcoin. They are also implemented in decentralized exchanges like atomex.me and atomicdex.io. However, they are not very practical, since they are usually slow and require proper syncing between chains.

Cross-Chain Token Transfer

In cross-chain token transfers, we do not need another party to exchange the tokens with. A user may simply transfer their tokens from one chain to another as we saw in the example at the beginning of this blog post. Once the transfer is completed, they should be able to use the tokens in the receiving chain without encountering any issues. The two most representative approaches for this framework can be seen below.

Federated 2-Way Peg

In federated 2-way peg schemes, token transfers are facilitated by a federation. A federation is a group of trusted intermediaries that operates a multisignature account in both chains and maintains the peg of the transferred token.

These schemes usually have a mainchain-sidechain structure, and the federation is in charge of minting and burning tokens in the sidechain, according to the token transfers on the mainchain. The Liquid Network is the best known example of a federated 2-way peg. It is a sidechain of Bitcoin which is meant to help with its scalability by offering lower fees with the L-BTC token pegged to BTC.

Federated 2-way pegs are easy to implement and can show a good performance, but they require a certain level of trust in the federation. If a majority of the federation members are malicious, the users may lose the tokens transferred to the sidechain.

Plasma Framework

This token transfer scheme was originally proposed as a layer-2 solution to scale Ethereum. A Plasma sidechain is connected to the Ethereum mainchain where it regularly posts information about its state. Many transactions can happen in the Plasma chain, and then Ethereum is only used as the settlement layer for transfers in and out of the Plasma chain.

Unlike with federated pegs, users do not need to trust the Plasma chain operators since any malicious activity in the Plasma chain can be challenged on the mainchain. If the challenge is successful, the user will recover their original funds. This comes with the major drawback of slow transfers back to the Ethereum chain. Every withdrawal request in Plasma is delayed by 7 days to allow users to challenge it. This solution also requires that users actively monitor their tokens in the Plasma chain.  

There are several working Plasma implementations with many different details and tradeoffs. Here we have just provided the general framework and features. If you want to know more, we recommend exploring the approaches taken by projects such as OmiseGO with the Plasma MVP implementation, or Loom with Plasma Cash.

General Cross-Chain Message

In this case, the interoperability solution allows the transfer of any kind of data or message between the connected chains. Our technical solution for the Lisk ecosystem will go in this direction, and potentially any custom message or transaction will be transferred between sidechains. Let’s see what this means with an example: Consider an ecosystem where, among many other blockchain applications, there is a Lisk Oracle sidechain which authenticates any off-chain data. Assume now that we deploy a general cross-chain interoperability solution in this ecosystem.

This means that we can have token transfers between sidechains, for example, users transferring tokens from the Lisk Gold sidechain to the Lisk Bet sidechain to participate in a sports bet. But more interestingly, Lisk Oracle is also able to send cross-chain messages to Lisk Bet with the sports results, and to Lisk Gold with the current price of an ounce of gold.

We can see that a blockchain interoperability solution allowing these kinds of general messages is the key to achieving a synergy of use cases and features provided by independent decentralized applications. Of course, this general framework involves a more complex interoperability protocol and it requires a sound definition of the standard messaging system between chains. Let’s examine some potential approaches in this framework.

Cross-Chain Certification

This scheme defines a specific data structure, the certificate, that is understood by the interoperable chains and serves as a sort of parcel to deliver the cross-chain messages. This certificate also carries information about its validity, for example, approval signatures from the validators of the sending chain. In principle, certificates can work in the same way in both directions. In the example shown in the figure below, chain 2 is the sending chain and chain 1 is the receiving chain.

In concrete terms, a certificate can contain the following:

• The cross-chain messages t1, t2, and t3 that were submitted on chain 2 targeting chain 1 since the last certificate.
• Certain information authenticating that the previous cross-chain messages were indeed included and finalized in chain 2. For example, this can be done by the validators of chain 2 attesting with their signatures that all the data included up to a certain block is final.

This scheme also requires a relayer, a network participant in charge of collecting and posting the certificates from one chain to the other chain. This can be done by any user or by the chain validators themselves.

Cross-chain certificates are a scalable and efficient solution that allows the passing of any kind of information between chains. However, it implies certain restrictions and requirements for the connected chains: they have to be able to generate certificates, validate them and the information inside. It seems to be the appropriate approach for an ecosystem with different blockchain applications built from a common technology stack. An example of this is the IBC standards of Cosmos which go in a direction similar to the one exposed here. However, probably the closest example of certificate-based interoperability is the one proposed in this paper by IOHK. 

Heterogeneous Blockchain Sharding

The term ‘shard’ comes from a database context and signifies a horizontal partition of a database or system. In heterogeneous blockchain sharding schemes, a central shard connects a myriad of different state transition machines. In general, these state machines do not need to be blockchains per se, they only need to fulfill certain requirements to be connected and secured by the central shard.

The best example of such an approach is the Polkadot ecosystem. In Polkadot, each of these state machines, known as parachains, relies on the central shard for their cross-chain protocol and their security. As long as the central shard is secure, the parachains will (inter)operate securely in the ecosystem. This scheme is usually referred to as ‘pooled security’. In a nutshell, every parachain prepares an ‘information blob’ in a specific format, and certain validators on the central shard make sure it is correct against a state transition function. If that is the case, then the central shard accepts the ‘information blob’ and advances the parachain. 

This ‘information blob’ may contain messages directed to other parachains. The central shard does not process the messages, but it orders, queues, and routes them following a standard protocol.

The ‘pooled security’ concept together with a message-passing protocol should allow Polkadot-like ecosystems to have trustless interactions between shards. These interactions can be of any kind, not just tokens, and they will be safely routed via the central shard. Nevertheless, these capabilities do not come without a cost. The Polkadot protocol is certainly complex, both at the implementation level and in terms of incentives for network participants. This also has an impact on scalability since only a limited number of parachains will be able to be part of the ecosystem.

As a side note, the Ethereum community is currently working to deliver a homogeneous blockchain sharding solution for Eth2.0

In the homogeneous case, instances of the same database are split across the network in different shards. There is also a mechanism to send cross-shard transactions, however, they are all part of the same blockchain platform.

Rollups

Rollups are proposed as another layer-2 solution to scale Ethereum, more flexible than the Plasma framework but with higher complexity. The idea here is to bundle or "roll-up" sidechain transactions into a single transaction and generate cryptographic proof of it. This proof, which is compact and/or generated very rarely, is then submitted to the mainchain. The mainchain is required to verify the validity of the proof, which in Ethereum is done by a specific smart contract. 

There are two types of Rollup solutions depending on the nature of the proof:

• Optimistic Rollups: In this scheme, sidechain blocks are just posted on the mainchain, without any processing, and after some time they are accepted. That is why it is called optimistic. Only if the sidechain block is challenged, the mainchain will assess the (in)validity of the block. This is done via fraud proofs. During the challenge period of a block, any user can submit a proof showing that there was something wrong with the block. Relayers, i.e., users posting the sidechain block on the mainchain, need to stake some tokens on the mainchain together with the new block. If the fraud proof is successful, then the sidechain block is rejected and the relayer loses their deposit.
• Zero-Knowledge Rollups (ZK-Rollups): All the transactions in the sidechain are bundled up and a zero-knowledge proof of their validity is generated by using ZK-STARKs. This proof is then periodically posted and validated on the mainchain. This solution is more secure than the optimistic counterpart and it does not need challenge periods. However, a general ZK-Rollup solution is still a work in progress and currently proposed implementations are closer to a cross-chain token transfer scheme than to a general interoperability solution. Moreover, ZK-STARKs are computationally very expensive to generate and complex to implement.

Conclusions

In this blog post, we have seen different approaches to achieve interoperability between blockchains with their main characteristics and uses. We definitely believe that a solid interoperability approach is a critical milestone for the mass adoption of this technology. In particular, a solution that allows passing any type of message from chain to chain can address the main limitations of blockchain technology.

Lisk’s Research Team aims to deliver a solution in this direction for the Lisk ecosystem. This will be the topic of the next blog post, where we will introduce the Lisk interoperability solution and cover its main features.