Blockchain is one of the hot topics in software industry and has made a revolution regarding decentralized payments on an untrusted environment since Bitcoin first appearance in 2008.
Bitcoin was the first application of this technology and other projects improved or provided new features to blockchain technology. For example, Lightning Network provides better scalability for decentralized micro-payments using Bitcoin cryptocurrency, while Monero provides a privacy environment for decentralized payments with user anonymization and transaction confidentiality. Although, the most influential improvement was Ethereum that turned blockchain technology into a decentralized state machine through its Ethereum Virtual Machine. Ethereum allowed new scenarios based on Decentralized Finance like decentralized loans, gaming, digital art, trading, among others.
These blockchains are pseudonymous, decentralized and unrestricted, where any user can read or write the ledger, have a full copy of the ledger or participate in the consensus protocol. Blockchains that have these characteristics are called public blockchains.
A few years later, enterprises found blockchain properties (i.e. immutability, decentralization) suitable to improve their business process, especially the ones that involved many organizations. Supply chain, finance and international trading scenarios had been benefited after applying this technology. These blockchains differ from existing public ones as they require higher levels of regulations. User identification, user authorization and data confidentiality are required to apply this technology, so a new type of blockchain raised. Hyperledger Fabric and Corda are two examples of them.
Why blockchain interoperability?
Besides all these happy words, there are some pitfalls about blockchain, and interoperability is one of them.
Blockchain could achieve the challenge of decentralized scenarios but with a high cost. It is a closed system and interoperability is not a feature provided by design. The validation of blockchain transactions must depend on the history of the blockchain itself to avoid the double spending problem.
The double spending problem is a risk that a cryptocurrency is spent more than once. Blockchains use consensus protocols to prevent this issue, but this is not a direct task when interoperating two or more blockchains.
The double spending is a specific problem of decentralized finance scenarios, but a similar problem happens while exchanging data. For example, smart contracts inside the blockchain cannot freely query external APIs and use the provided data directly. External APIs may return different values in different request calls breaking the replicability of transaction execution.
In this post we will discuss three scenarios related to blockchain interoperability:
- Asset transfer
- Asset exchange
- Data sharing
Asset transfer involves an asset that must be moved from one blockchain to another. The asset must be burned or locked on the source blockchain and must be generated or minted on the target blockchain. For example, an NFT that represent some shoes is transferred from a user’s wallet in Ethereum to a friend of the user’s wallet in Cardano. The target blockchain must be 100% sure the NFT on Ethereum was burned or locked to mint the NFT on Cardano. Otherwise, we will be on a double spending problem issue.
Figure 1 – Asset transfer
Asset exchange involves two assets held on two different blockchains and two users that want to exchange those assets between each other. For example, two users want to exchange two NFTs, one from Ethereum and another one from Cardano. In this case, the asset must be transferred to the new owner on an atomic way to preserve consistency of the operation. If not, it may happen that only one transfer may occur leaving one user with both NFTs and the other one with none of them.
Figure 2 – Asset exchange
Finally, data sharing involves two blockchains where the source blockchain needs to query information of the target blockchain and registers it (copies it) on its ledger. For example, a smart contract on Ethereum needs to query another blockchain information to fulfil its operation. In this case, the client blockchain (blockchain that queries the information) needs mechanisms to validate the incoming data and have the guarantees that the information is valid and comes from the server blockchain (blockchain that provides the information).
Figure 3 – Data sharing
As we have seen in these scenarios, blockchain interoperability differ from traditional information systems interoperability done through REST APIs. With blockchain, technical interoperability is not enough as they need other requirements besides common data formats and communication protocols. Blockchains need semantical interoperability were the participants need to know the context information is transferred. It’s not just information, blockchains need the meaning of that information. As an example, on asset transfer or exchange scenarios, target blockchains needs to know what its exchanged to rebuild the asset and register it in its ledger.
Blockchain interoperability topologies
Blockchain interoperability may involve blockchains but also business applications. The previous scenarios may be applied using different topologies.
Figure 4 – Blockchain interoperability topologies
A first topology may involve a business application that needs to interoperate with two blockchains. For example, a business application that handles data transfer and transfers an asset from Ethereum to Cardano. The business application locks the asset on blockchain A and mints it on blockchain B. Hyperledger Cactus is an example of blockchain interoperability solution that follows this topology.
A second topology may be that a blockchain needs to interoperate directly with another blockchain. For example, a smart contract on a blockchain reads or writes the ledger of another blockchain or invokes a smart contract of another blockchain for data sharing, data exchange or data transfer. Liquid Network is a sidechain of Bitcoin network that follows this topology for asset exchange.
Finally, a blockchain may need to interoperate with an external business application to read data from the external world or send data to an external business application. For example, a smart contract may need to query external data from an Oracle to know a cryptocurrency exchange rate to accomplish a decentralized loan lending or a smart contract may need send events that are listened by an external business application. Chainlink is a popular Oracle used by smart contracts to include read information of the external world and use it on the blockchain
Conclusion
In this post we have seen different blockchain interoperability scenarios (data transfer, data exchange and data sharing) as well as examples of blockchain interoperability topologies.
In part 2 of our blockchain interoperability blog we are going to share some existing interoperability solutions that can be applied to solve these scenarios.
