\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.
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.
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:
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:
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.
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):
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.
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.
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.
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:
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 a 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 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:
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.
Create your free account to unlock your custom reading experience.