About blockchain interoperability
Introduction
Blockchain was first introduced in 2008 by Nakamoto in [1]. In their paper, the anonymous author(s) described the first decentralised ledger: a database in which anyone can write, and that is not controlled by a single or a conglomerate of identities. Since then, many other blockchains have been described: Ethereum [2], Ripple [3] and many others. In May 2019, 248 active blockchains were listed on [4].
While many different blockchains exist, there is no direct way of reaching interoperability, at least without a trusted third party. Consider for instance a client willing to convert their Bitcoins to Ether: they would need to consume the amount of Bitcoins they wants to convert and to generate the equivalent amount of Ether. While Bitcoin consumption may be reachable (by sending coins to a non-existing address, such as the address 0), it is impossible to spontaneously generate Ether (or any other kind of cryptocurrency). For now, the problem is solved with the help of trusted brokers (also called escrows), even though other solutions are on their way [5], [6].
The issue of interoperability is solved in some cases, like “atomic exchanges” and hash-locking [7], in which game theory ensures that a broker only benefits when following the protocol. However the question of trustless interoperability in the general context remains open.
Contributions We introduce a theoretical background to blockchain interoperability, providing a formal definition of a blockchain and of interoperability. We then prove that, by definition, interoperability between two public blockchains is impossible. However, we contend that there may be special conditions under which two blockchains can be interoperable. This leads us to prove the equivalence between two interoperable public blockchains and a ledger emulating both blockchains on two separate registries.
Related work The concept of sidechains (a sidechain is a blockchain attached to another blockchain, with exchanges possible between the two blockchains) has been explored in [8]. The authors describe a two-way peg in which a sidechain is fed with an SPV proof, a short proof of the transaction allowing for lightweight clients. The sidechain plays the role of a lightweight client, and can thus allow subsequent operations following the SPV proof. However, this pegging system requires a contest period, during which it is assumed that people will verify that the SPV proof does not come from a fork. Hence, additional trust is required in this model. In a paper from 2016 [7], Buterin lists ways of reaching interoperability, and focuses on trusted inter-chains exchanges, where one sends money on blockchain A and receives some in blockchain B.
Similarly, the Interledger protocol [6] (ILP) allows one to automatize money transfers while leveraging the risk of fraud, thanks to micro-transactions. Yet, ILP is more about escrow synchronization than interoperability as we define it later on. In an ILP transaction from blockchain to blockchain , one must find an escrow having enough money on (or several escrows having in total enough money), so the transfer can occur. More generally, we consider that interoperability can for instance allow money to ‘disappear’ from and to ‘reappear’ on , without the need for trusted escrows.
Interoperability has been notably implemented in the blockchain network Kadena [9], in which transfers from one blockchain of the network to another is possible. The money is destroyed on one side and generated on the other. Kadena also uses smart contracts for securing escrow transfer. However, there is no indication that Kadena can operate with chains outside of their specific network. So in our terminology, we say that Kadena is a “N-in-1 blockchain”, which is to say one blockchain, with several ledgers.
To the best of our knowledge, no theoretical work on interoperability has been done to date. Our work, rather than giving a practical implementation of an interoperable blockchain, gives a theoretical background to the topic, and explores the conceptual meaning of having interoperable blockchains.
Outline In the next section, we formally define a blockchain and interoperability. In Section 3, we prove that it is impossible by design to have interoperability between blockchains. In Section 4, we show that interoperability is possible with a weaker definition of the blockchain. Before concluding, in Section 5, we prove that interoperability is equivalent to having a blockchain with two ledgers.
Section snippets
Preliminaries
Sets and tuples are noted in calligraphic font: , algorithms in serif: Mine. When a deterministic algorithm, say , returns some value x from some input i, we use the notation . If is randomised, we use the notation . A list of elements (in this order) is represented by . We denote concatenation of two lists a and b with . The set of elements belonging to but not to is noted (this set is also called the difference of
General impossibility of interoperability
Our first result is to show that it is impossible to have interoperability between two blockchains in general. Theorem 1 Under the Definition 3, Definition 5, blockchain interoperability is impossible.
Proof Assume that an interoperable transaction t exists. Then there is a set of possible ledger values of for which a block containing t is accepted by , if . Moreover, if , then will refuse any block containing t. However, only takes as arguments, where S is a
Interoperability with a weaker definition
Even though blockchain is not suited for interoperability stricto sensu, we can generalise our blockchain definition, in order to make a blockchain interoperable.
Hypothesis 1 We assume that for two blockchains , and , with both and have access to both and : is of the form , and is of the form .
We now use the notation to note the new consensus algorithm. Hence, the ‘version’ of
Equivalence of interoperable blockchains with a single blockchain
Even though interoperable blockchains can be tweaked into existence, we argue that they are conceptually equivalent to a single blockchain. More precisely, we argue that they are equivalent to one blockchain, composed of two ledgers. Such a blockchain can be easily implemented: if the first bit of the transaction is 0, then apply the transaction to the first ledger, and if 1 to the second.
We say that two blockchains are equivalent if any valid transaction on one blockchain corresponds to one
Conclusion
In this paper, we explored the possibility of making two blockchains interoperable. We showed that, under classical definitions, it is impossible to make a blockchain interact with anything other than itself. If we relax the definition, we do get the possibility of interoperable blockchains, but doing so is equivalent to creating a ‘2-in-1’ blockchain, i.e., a blockchain with two ledgers.
Declaration of Competing Interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
References (13)
Bitcoin: a peer-to-peer electronic cash system
Ethereum: a next-generation smart contract and decentralized application platform
- et al.
The ripple protocol consensus algorithm
Crypto-currency blockchain explorers
- et al.
Sidechains and interoperability
- et al.
A protocol for interledger payments
Cited by (66)
Trust-minimized optimistic cross-rollup arbitrary message bridge
2024, Journal of Network and Computer ApplicationsComparative analysis of permissioned blockchain frameworks for industrial applications
2023, Blockchain: Research and ApplicationsBlockchain’s double-edged sword: thematic review of illegal activities using blockchain
2024, Journal of Information, Communication and Ethics in SocietyIdentifying the Barriers to Acceptance of Blockchain-Based Patient-Centric Data Management Systems in Healthcare
2024, Healthcare (Switzerland)Survey on Progress of Blockchain Interoperability Technology
2024, Journal of Frontiers of Computer Science and Technology