Au cours de ces dernières années, l’écosystème blockchain a connu une explosion du nombre de technologies de registres en chaînes de blocs. Souvent basées sur des mécanismes conceptuellement semblables, elles restent pourtant profondément différentes dans la pratique. En découle une regrettable isolation des implémentations de ces technologies qui, fondamentalement, ne sont pas en mesure de communiquer entre elles. Ce que nous appelons « interopérabilité » est l’ouverture de ces systèmes les uns aux autres pour décupler la valeur délivrée. Si c’est une préoccupation encore précoce pour les entreprises qui implémentent de la blockchain, c’est un aspect assidûment étudié par la frange technique de l’écosystème. Un sujet à suivre car central dans l’adoption de masse de demain et qui se joue en ce moment.

Blockchain Interoperability: Overcoming isolation

Over the last few years, the blockchain ecosystem perceived an explosion of projects based on different mechanisms. They all propose their own blockchain design offering a large number of concepts that specify the way a given distributed ledger operates (assets definition, consensus protocols, access controls, etc.).

Undoubtedly, this outbreak of projects has pushed the development and improvement of the ecosystem. However, the aftermath was severe, the “isolation” of the capabilities offered by these blockchain networks. These networks do not communicate and cannot share data because of the lack of a common definition of what a blockchain is.

Letting these non-identical blockchains operate together despite their core differences is what we call interoperability.

Why blockchain interoperability is important?

Before we dive deeper into the subject, let us consider a concrete everyday life use case. Remember the last time you opened a bank account. You have been asked a whole set of supporting documents, including a proof of address. This procedure is part of the legal obligation, known as “Know Your Customer” (KYC), that banks need to execute before starting a business relationship with a client. What you probably did at that time was to ask your electricity provider for editing this document.

What if your certified document could be directly shared between your electricity provider and your bank?

Today, banks across the world are already using private blockchain solutions to optimize their KYC processes. However, the document collection and verification procedures are still done manually off-chain.

On the other hand, there are the service providers who are leveraging the blockchain technology to authenticate documents issued under their signature. They have developed their own solutions backed by a blockchain to verify a file’s integrity, the identity of its author and the timestamp.

Ideally, you could authorize your electricity provider to share your proof of address certified under his blockchain with your bank’s KYC blockchain. Nonetheless, as of today this cannot be accomplished: these blockchains are unable to communicate and cannot “interoperate”.

What efforts have been done to achieve this interoperability?

Back in 2016, Vitalik Buterin helped write an interoperability research paper for R3. He identified three primary categories of strategies for chain interoperation: notary scheme, hash-locking, and relays.

Notary Scheme

The first and simplest way is the use of a notary to facilitate cross-chain operations. A notary is a centralized entity that is placed between different mistrusting and asymmetric chains. It is used to claim that a given event on a subchain has taken place or that some claim is true. These notaries are non-blockchain based solutions that can act actively (listening and automatically acting based on events) or passively (issuing signed messages only when prompted). The benefit of this solution is the capability to interoperate with any type of blockchain, but it has a cost: centralization.


A second strategy known as “hash-locking”, is relatively simple but limited in its capacity. Indeed, this concept is used only for the specific portable assets use case, where it allows the trade or move of assets between different chains.

Let us take Bob and Alice, respectively parts of chain 1 based on Ethereum, and chain 2 bases on Bitcoin.

Bob wants to make a trade with Alice, buying 10 Ethers with 1 Bitcoin. In order to perform this asset trade, the entire transaction needs to be “atomic”: either both transfer operations happen, or none at all. The resulting operation is called an atomic swap. The guarantee that the two transfer operations are atomic is assured using “hash-locks”.

This works as follows:

Alice sends to Bob 10 Ethers through a transaction locked by the hash of a secret. According to the smart contract, Bob cannot receive the 10 Ethers unless he provides the secret corresponding to the hash used by Alice.

Bob uses the same hash as a lock on a Bitcoin transaction to Alice. He does not know the secret yet, but he knows its hash value.

Once Alice sees Bob’s transaction, she publishes her secret on the Bitcoin network allowing her to get the funds. By doing so, Bob can get the secret.

Bob publishes this secret on the Ethereum network to unlock Alice’s transaction and get his 10 Ethers.

Whereas the notary model is a bridge across which any type of transaction can occur, this hash-lock based technology structurally only allows the exchange of assets on a swap-like model. Despite this limitation, this solution is still relevant since there are plenty of blockchain assets that one may want to exchange.


Lastly, there is the relays strategy, significantly more difficult to implement, but a wider-ranging method.

The lightest one might be seen as a light client running on a blockchain A, let’s say an Ethereum blockchain. This client is aimed at reading states from a blockchain B, a Bitcoin blockchain for example. The blockchain B is read based on its validated block header. These headers contain a sufficient amount of information, overcoming the need for downloading the full chain. In that case, chain A is pegged to chain B. It is then able to detect an awaited transaction on chain B and to generate a transaction on chain A based on that. This method is quite simple: one-way and read-only. There are many ways to enhance this interoperation. One could, for example, implement this reading mechanism on chain B, making the interconnection bidirectional.

Promising projects and the future of blockchain interoperability

Even from 2016, these patterns are still accurate to the techniques approached by blockchain experts today. The three techniques described are the theoretical basis on top of which a whole pack of solutions are taking shape, offering a large bench for organizations in need of interoperability.

“Liquality” is using the “hash-lock” technique to build an interface that offers a secure way to swap cryptocurrencies, where counterparty risk and fees are significantly reduced by using atomic swaps.

Cosmos and Polkadot are one of the biggest names among blockchain interoperability initiatives using the “Notary Schemes” concept.

For example, Cosmos is a network of nodes that acts as an intermediary between different blockchains. Its architecture consists of a central entity — called Hub — responsible of relaying messages to each connected blockchains through a specific bridge — called Spoke.

Regarding “Relays” concept, BTCRelay and Dogethereum are the ones drawing the most attention. BTCRelay is an Ethereum smart contract that allows to read Bitcoin transactions and relay them to multiple Ethereum smart contracts. It is specifically built for these techniques in a one-way manner. On the other hand, the Dogethereum solution comes natively with an answer to the “two-way” interoperability with its native token called Doge.

Perceptibly, these solutions are racing to prove themselves as better and more adapted than the others. Despite their efforts, none of these solutions are sufficiently mature and most of them are still in the development phase. Nevertheless, this market competition is in fact truly positive to the ecosystem as it pushes the development of “market-ready” blockchain interoperability solutions.

Indeed, in order for the blockchain networks to continue evolving and drawing their path toward mass adoption, a solid interoperability strategy must be established. We believe that just as with the internet protocol where TCP/IP became the standard, one of these solutions will improve, prevail on the market, and become the blockchain standard for interoperability.

Authors: Hamza El Kacimi, Matthieu Bougeard, and Ana Tereza Mascarenhas

Toggle location