Content uploaded by Marius Lombard-Platet

Author content

All content in this area was uploaded by Marius Lombard-Platet on Aug 23, 2020

Content may be subject to copyright.

About Blockchain Interoperability

Pascal Lafourcade1and Marius Lombard-Platet2,3

1Universit´e Clermont-Auvergne, LIMOS CNRS UMR 6158,

Aubi`ere, France

2D´epartement d’informatique de l’ENS, ´

Ecole normale sup´erieure,

CNRS, PSL Research University, Paris, France

3Be-Studys, Geneva, Switzerland

Abstract

A blockchain is designed to be a self-suﬃcient decentralised ledger: a

peer verifying the validity of past transactions only needs to download

the blockchain (the ledger) and nothing else. However, it might be of

interest to make two diﬀerent blockchains interoperable, i.e., to allow one

to transmit information from one blockchain to another blockchain. In

this paper, we give a formalisation of this problem, and we prove that

blockchain interoperability is impossible according to the classical deﬁni-

tion of a blockchain. Under a weaker deﬁnition of blockchain, we demon-

strate that two blockchains are interoperable is equivalent to creating a

‘2-in-1’ blockchain containing both ledgers, thus limiting the theoretical

interest of making interoperable blockchains in the ﬁrst place. We also ob-

serve that all practical existing interoperable blockchain frameworks work

indeed by exchanging already created tokens between two blockchains and

not by oﬀering the possibility to transfer tokens from one blockchain to

another one, which implies a modiﬁcation of the balance of total created

tokens on both blockchains. It conﬁrms that having interoperability is

only possible by creating a ‘2-in-1’ blockchain containing both ledgers.

Keywords: Decentralized ledger, interoperability

1 Introduction

Blockchain was ﬁrst introduced in 2008 by Nakamoto in [1]. In their paper,

the anonymous author(s) described the ﬁrst 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 diﬀerent blockchains exist, there is no direct way of reaching

interoperability, at least without a trusted third party. Consider for instance a

1

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 beneﬁts

when following the protocol. However the question of trustless interoperability

in the general context remains open.

Contributions We introduce a theoretical background to blockchain inter-

operability, providing a formal deﬁnition of a blockchain and of interoperabil-

ity. We then prove that, by deﬁnition, interoperability between two public

blockchains is impossible. However, we contend that there may be special con-

ditions under which two blockchains can be interoperable. This leads us to prove

the equivalence between two interoperable public blockchains and a ledger em-

ulating 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 deﬁne

it later on. In an ILP transaction from blockchain Ato blockchain B, one

must ﬁnd an escrow having enough money on B(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 Aand to

‘reappear’ on B, 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 speciﬁc

network. So in our terminology, we say that Kadena is a ”N-in-1 blockchain”,

2

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 deﬁne a blockchain and interoperabil-

ity. 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 deﬁnition of the blockchain. Before concluding, in Section 5, we prove

that interoperability is equivalent to having a blockchain with two ledgers.

2 Preliminaries

Sets and tuples are noted in calligraphic font: A, algorithms in serif: Mine.

When a deterministic algorithm, say Algorithm, returns some value xfrom some

input i, we use the notation x←Algorithm(i). If Algorithm is randomised, we

use the notation x$

←− Algorithm(i). A list of elements e1, . . . , en(in this order)

is represented by [e1, . . . , en]. We denote concatenation of two lists aand bwith

akb. The set of elements belonging to Abut not to Bis noted A\B (this set is

also called the diﬀerence of Aand B.)

2.1 Blockchain Deﬁnition

Various deﬁnitions of blockchain have already been given [10, 11]. In this work,

we rather give a formalization of blockchains, which we believe is easier to use

for proving theoretical results such as the one in this paper.

Intuitively, a blockchain is a chain of transactions. More precisely, each

element of the chain (each block) contains several transactions (or one or none),

as well a proof needed for consensus to take place. For instance in Bitcoin [1]

or similar Proof of Work blockchains, the proof is a nonce (a random number

such that the hash of the block is below a threshold value); in a Proof-of-Stake

such as the Casper version for Ethereum [2] the proof consists of the successive

bets on what the next block will be; in a Proof-of-Elapsed-Time as designed by

Intel [12], the proof is instead a certiﬁcate obtained from the SGX (a trusted

enclave). Note that it exists blockchains not requiring proofs (for instance,

one can argue that PBFT consensus does not require proof ), in which case we

consider the proof is empty.

Deﬁnition 1 (Blockchain).Let Tbe a set of transactions and Pbe a set of

proofs. A blockchain is a tuple of elements B= (L,W,Emit,Mine), where:

•A ledger Lis a list of transactions with their proofs deﬁned by: L=

[([t1,1, t1,2, . . . ], p1),...,[([tn,1, tn,2, . . . ], pn)] with ti,j ∈ T and pi∈ P.

• W is such that W ⊂ T ,Wis called the pool of waiting transactions.

3

•Emit is a deterministic algorithm taking one transaction t∈ T and Was

input, and returning an updated pool Emit(t, W) = W∪t.

•Mine is an algorithm taking L,Wand returning a new ledger L0, a new

pool W0, where for any W ⊂ T , and for (L0,W0)$

←− Mine(L,W), we have

that L0is of the form Lk[(transacs, p)], where transacs is a list containing

all elements from W\W0, and p∈ P a proof.

Furthermore, after a call to Emit or Mine, the ledger Land the waiting pool

Wof Bare updated with the values returned by said algorithms. In other words,

Mine and Emit are not pure functions [13], as they have side eﬀects on the

blockchain.

At this point, transactions are appended (or not) to the blockchain after a

call to Mine. We hereby give a formal deﬁnition of what a valid transaction is.

Deﬁnition 2 (Valid Transaction).Let B= (L,W,Emit,Mine)be a blockchain,

and let tbe a transaction (t∈ W),tis a valid transaction for B(currently

in state L) if and only if there exists a block in the ledger returned by Mine

containing t.

As we can see, the validity of a transaction depends on the state of the

ledger; if a transaction is valid at one point, it may not be valid forever, and

reciprocally. For instance, a transaction from user U to user V is valid only as

long as U has enough funds. Yet, after the emission and the insertion of the

transaction in the blockchain, U may issue other transactions, emptying their

wallet. This is the classical issue of double spending.

The same is true for smart contracts: here, they are seen as a special subset

of transactions, and they aﬀect the state of the ledger. Because Mine has access

to the whole ledger, it can take into account the smart contract’s side eﬀects.

Note that Mine is a randomized algorithm, and as such, there is no guar-

antee that all users will agree on the same ledger. Because blockchain is a

decentralised ledger, state synchronisation must be ensured. For this, we intro-

duce a synchronisation algorithm, called Consensus.

Deﬁnition 3 (Decentralised Blockchain).A decentralised blockchain is a tuple

B0= (L,W,Emit,Mine,Consensus)where:

• B = (L,W,Emit,Mine)is a blockchain,

•Consensus is a deterministic algorithm, taking as input B, a set Sof tu-

ples (Li,Wi)such that ∀(Li,Wi)∈ S, we have that (Li,Wi,Emit,Mine)

is a blockchain. Furthermore, for (L∗,W∗)←Consensus(B,S), then

(L∗,W∗)∈ S ∪ (L,W). In other words, from a list of potential new

blocks, Consensus chooses (or accepts) one of them, or rejects them all

(and returns (L,W)).

•After a call to Consensus,B0’s ledger and waiting pool components are

replaced with the values returned by said algorithms.

4

The idea of Consensus is that when a peer updates their local version of

the blockchain, they ﬁrst receive possibly more than one new version (i.e., new

blocks) from peers. However only one of these new blocks will be accepted, and

all the network must agree on this block.

Deﬁnition 4 (Secure Blockchain).We say that a decentralised blockchain (L,W,

Emit,Mine,Consensus)is secure if it is computationally hard for a user to craft

a new ledger L0and a new transaction pool W0such that for all Ssuch that

(L0,W0)∈ S, we have both that Consensus(B,S) = (L0,W0)and Lis not a preﬁx

of L0.

This deﬁnition makes a blockchain immune against history rewriting (and

double spending), as it is computationally hard to rewrite old blocks.

2.2 Interoperability Deﬁnition

The concept of interoperability is to enable two blockchains to work together.

A classic blockchain Aaccepts transactions because given the current state of

A’s ledger, the transaction does not violate A’s rules. Similarly, we say that

a blockchain Athat is interoperable with blockchain Baccepts transactions

because, given the current state of Aand B’s ledgers, the transaction does

not violate A’s rules. Furthermore, if the rules for said transaction only imply

conditions on A’s ledger, then the transaction does not require Bto be valid,

and as such does not make use of the interoperability. So an interoperable

transaction on Amust be dependent on B’s ledger: if B’s ledger is equal to

some values, then the transaction is valid; otherwise it is invalid.

We now give a formalization of this deﬁnition.

Deﬁnition 5 (Blockchain Interoperability).Let A= (LA,WA,EmitA,

MineA,ConsensusA)and B= (LB,WB,EmitB,MineB,ConsensusB)be two de-

centralised blockchains. Let ΩA(resp. ΩB) be the set of all possible values for

A’s ledger LA(resp. LB). Ais interoperable with Bif there exists:

•a transaction t∈ T ,

•a non-empty subset ωA⊂ΩA,

•a non-empty proper subset ωB ΩB

such that there exists a block containing tthat is accepted by ConsensusAif

LA× LB∈ωA×ωB, and rejected otherwise.

Aand Bare interoperable if they are both interoperable with each other.

3 General Impossibility of Interoperability

Our ﬁrst result is to show that it is impossible to have interoperability between

two blockchains in general.

5

Theorem 1. Under the deﬁnitions 3 and 5, blockchain interoperability is im-

possible.

Proof. Assume that an interoperable transaction texists. Then there is a set

ωBof possible ledger values of Bfor which a block containing tis accepted by

ConsensusA, if LB∈ωB. Moreover, if LB∈ΩB\ωB, then ConsensusAwill refuse

any block containing t.

However, ConsensusAonly takes A, S as arguments, where Sis a set of tuples

(Li,Wi) (see Deﬁnition 3). As a consequence, ConsensusAis independent from

B, and especially from LB. Then, if tis accepted by ConsensusAwhen LB∈ωB,

then tis also accepted by ConsensusAwhen LB∈ΩB\ωB; this implies that

ΩB\ωB=∅, i.e., ωB= ΩB, which is a contradiction with the hypothesis of

Deﬁnition 5, namely that ωBis a proper subset of ΩB.

This result is actually quite straightforward if we remember that a blockchain

is, by construction, made to be self-suﬃcient: no blockchain can rely on external

data. Especially, no blockchain can rely on another blockchain for asserting the

validity of a transaction. Hence, interoperability is a contradiction of one of the

intrinsic characteristics of blockchain.

The interpretation of the result is as follows: without additional assumptions,

interoperability between two blockchains is impossible. Therefore, to achieve

interoperability further assumptions need to be made. For instance, in the

two-way pegged blockchain mechanism, a dispute period is required for each

interoperabilty operation; as the blockchain cannot know by itself whether the

proposed SPV proof is the one of the latest block.

4 Interoperability with a Weaker Deﬁnition

Even though blockchain is not suited for interoperability stricto sensu, we can

generalise our blockchain deﬁnition, in order to make a blockchain interoperable.

Hypothesis 1. We assume that for two blockchains A= (LA,WA,EmitA,MineA,

ConsensusA)and B, with Aboth MineAand ConsensusAhave access to both A

and B:ConsensusAis of the form ConsensusA(A,B,S), and MineAis of the

form MineA(LA,LB,WA,WB).

We now use the notation ConsensusA(A,B,·) to note the new consensus

algorithm. Hence, the ‘version’ of Consensus in the previous deﬁnition, is now

noted ConsensusA(A,∅,·). Similarly, the non-interoperable version of Mine is

now noted as MineA(LA,∅,WA,∅).

Deﬁnition 6 (Interoperable transaction).Under the assumption hypothesis 1,

a transaction ton the blockchain Ais said to be interoperable with Bif tcan be

accepted by ConsensusA(A,B,·)but cannot be accepted by

ConsensusA(A,∅,·).

In this context, we have the following result.

6

Theorem 2. Under Hypothesis 1, it is possible to build interoperable blockchains.

Proof. Note that we already know that interoperable blockchains exist, such

as Kadena [9] or other blockchains listed in [5], but we give an example of

interoperable blockchain in our own theoretical framework.

Consider two decentralised blockchains A= (LA,WA,EmitA,MineA,ConsensusA)

and B. On the blockchains we deﬁne accounts. An account ownership is deﬁned

by the knowledge of a private key, and for simplicity the public key is assimi-

lated to the account itself. A transaction t∈ TA(resp. TB) speciﬁes the sender’s

public key, the receiver’s public key, an amount and a signature of the previous

ﬁelds by the sender’s private key. An account ion blockchain A(resp. B) is

designed by iA(resp iB).

We build blockchain Bso that it is interoperable with blockchain Ain the

following sense: a user can ‘create’ money on Bif and only if at least the same

amount of money has been consumed on A, by sending it to a ‘bin’ account.

We ﬁrst note that accounts owned by nobody exist. In our scheme, in most

cryptosystems the public key 0 (consisting of only zeroes) is not linked to any

private key. Thus, while the account 0Aexists and money can be transferred

on this account, it cannot be claimed by anyone.

Let us construct Bin order to fulﬁl the previous requirements. First, let us

deﬁne the interoperability transactions t∗(mB, pkB), which sends some amount

of money mBfrom 0Bto the account pkBon B.t∗(mB, pkB) is only valid

if1there is at least one transaction on LAsending mto the account 0A, with

m>mB.

Then, let us construct MineB: a transaction tis valid for MineB(LB,LA,WB,WA)

if and only if tis valid for MineA(LA,∅,WA,∅), or if both statements are true:

•tis an interoperability transaction transferring some amount of money m

from 0Bto an account on B,

• LAcontains a transaction sending at least mon the zero-address 0A.

Similarly, ConsensusB(B,A,·) is conceived to accept new ledgers that would

have been accepted by ConsensusA(B,∅,·), as well as ledgers where the new

blocks are constituted solely of transactions that are accepted by ConsensusA(B,∅,·)

and valid interoperability transactions (valid in the meaning that at the time

of their incorporation in the ledger, the sender has enough funds to emit the

transaction).

With this construction, we immediately get that Bis interoperable with A:

a user can transfer assets from Ato B, which is shown by the fact that some

transactions (here denoted t∗) are only valid on Bif the sender has enough funds

on A.

1Note that for a real cryptocurrency more checks would be needed for any practical use,

notably because of the fact that in the current setting, anyone can withdraw mfrom 0Bas

many times as they want. However, for the sake of simplicity, we only describe a simple, naive

interoperability operation here, so these checks are omitted.

7

5 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 ﬁrst bit of the transaction

is 0, then apply the transaction to the ﬁrst ledger, and if 1 to the second.

We say that two blockchains are equivalent if any valid transaction on one

blockchain corresponds to one valid transaction on the other blockchain. This

deﬁnition implies that two equivalent blockchains will have very similar evolu-

tions of their ledgers. As Mine is not deterministic, we cannot ensure that the

two ledgers will be identical, but the deﬁnition we give is enough for practical

uses.

Deﬁnition 7 (Blockchain equivalence).Let there be two blockchains A= (LA,

WA,EmitA,MineA)and B= (LB,WB,EmitB,MineB)accepting transactions

from TAand TB, respectively. Aand Bare said to be equivalent if there exists

a bijection ϕ:TA→TBsuch that, if both ledgers are equivalent, then there is

an equivalence of the valid transactions. In mathematical terms, ϕ(LA) = LB⇒

∀tA∈ TA, tAis a valid transaction for A ⇔ ϕ(tA)is a valid transaction for B).

Note that ϕ(LA) is the generalization of ϕto ledgers: if LA= [[t1,1, t1,2, . . . ],

. . . , [tn,1, tn,2, . . . ]], then ϕ(LA) = [[ϕ(t1,1), ϕ(t1,2), . . . ],...,[ϕ(tn,1),

ϕ(tn,2), . . . ]], in the case of a ledger without proofs. If the ledger has proofs (see

Deﬁnition 1), ϕwould need to work on a projection of the ledger: a projection in

which every poof is removed. This subtlety has been removed from the deﬁnition

for the sake of simplicity.

For instance, let us assume that two blockchains are equivalent, and two

smart contracts being the reciprocal image of each other. This means that

whatever transaction triggers one smart contract, the eﬀects on the state of the

blockchain will be equivalent to the eﬀects on the state of the image blockchain:

in both cases, the acceptable elements after the transaction are the same (up

to a bijection). This deﬁnition does not guarantee that the smart contract will

behave identically: for instance, one could image a smart contract updating a

useless write-only variable, which by deﬁnition does not aﬀect the set of fu-

ture acceptable transactions as it is write-only. However, it ensures that the

behaviour of the blockchain is strictly the same in both cases.

Theorem 3. A decentralised blockchain Ainteroperable with a blockchain Bis

equivalent to a decentralised blockchain Ccontaining both Aand B’s ledgers.

Proof. Let A= (LA,WA,EmitA,MineA,ConsensusA) and Bbe two decentralised

blockchains, with Abeing interoperable with B.Abeing interoperable with

B, we have MineAof the form MineA(LA,LB,·), and ConsensusAof the form

ConsensusA(A,B,·).

8

Let TA(resp. TB) be the set of transactions for A(resp. B). Note that TA

contains interoperability transactions. Let Cbe the tuple C= (LC,WC,EmitC,

MineC,ConsensusC).

We deﬁne the set of transactions for C,TC= (TA× ∅)∪(∅×TB). Let cA

(resp. cB) be the canonical projector of TCon TA(resp. TB).

For (LAk[(transacsA, pA)],W0

A) = MineA(LA,LB, cA(WC)) and

(LBk[(transacsB, pB)],W0

B) = MineB(LB, cB(WC)), we deﬁne: MineC(LC,WC) =

(LCk[(transacsA× ∅k∅ × transacsB, pA×pB),(W0

A× ∅)∪(∅×W0

B)])

Simply put, MineCis a parallelisation of MineAand MineB: a block proposed

by MineCis a block comprised of the transactions accepted by MineAand MineB.

Similarly, ConsensusCis built as a parallelisation of ConsensusAand ConsensusB.

If ConsensusA(A,B, cA(SC)) = (L∗

A,W∗

A) and ConsensusB(B, cB(SB)) = (L∗

B,W∗

B),

then we deﬁne ConsensusC= (LA× ∅k∅ × LB,WA×∅∪∅×WB).

By construction, we see that Cis a decentralised blockchain. Furthermore, by

construction each transaction accepted by MineCis either accepted by MineAor

MineBand, conversely, each transaction accepted by MineAor MineBis accepted

by MineC, hence the equivalence of the blockchains.

In practice, Theorem 3 means that creating two interoperable blockchains is

equivalent to creating one blockchain, with a ledger divided into two separate

registries: a ‘2-in-1‘ blockchain. So while creating interoperable blockchains

(with a lax deﬁnition of a blockchain) is possible, we argue that the conceptual

interest of doing so is limited. However, it may be interesting to create an

interoperable blockchain on top of an already existing blockchain. Doing so

allows both blockchains to fully operate, without the older blockchain being

aﬀected by anything. Nonetheless the obvious restriction is that only one of the

two blockchains will be interoperable with the other, with all the limits implied

by this fact.

6 Conclusion

In this paper, we explored the possibility of making two blockchains interop-

erable. We showed that, under classical deﬁnitions, it is impossible to make a

blockchain interact with anything other than itself. If we relax the deﬁnition,

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.

References

[1] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system (2009).

URL http://www.bitcoin.org/bitcoin.pdf

9

[2] V. Buterin, Ethereum: A next-generation smart contract and decentralized

application platform (2014).

URL https://github.com/ethereum/wiki/wiki/White-Paper

[3] D. Schwartz, N. Youngs, A. Britto, The ripple protocol consensus algorithm

(2014).

URL https://ripple.com/files/ripple_consensus_whitepaper.pdf

[4] CryptoID, Crypto-currency blockchain explorers (2019).

URL https://chainz.cryptoid.info/

[5] S. Johnson, P. Robinson, J. Brainard, Sidechains and interoperability,

arXiv e-prints (2019). arXiv:1903.04077.

[6] S. Thomas, E. Schwartz, A protocol for interledger payments (2015).

URL https://interledger.org/interledger.pdf

[7] V. Buterin, Chain interoperability (2016).

URL https://www.r3.com/wp-content/uploads/2017/06/chain_

interoperability_r3.pdf

[8] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller,

A. Poelstra, J. Tim´on, P. Wuille, Enabling blockchain innovations with

pegged sidechains (2014).

URL http://www.opensciencereview.com/papers/123/

enablingblockchain-innovations-with-pegged-sidechains

[9] W. Martino, M. Quaintance, S. Popejoy, Chainweb whitepaper (2018).

URL http://kadena2.novadesign.io/wp-content/uploads/2018/08/

chainweb-v15.pdf

[10] J. Garay, A. Kiayias, N. Leonardos, The bitcoin backbone protocol: Anal-

ysis and applications, in: Advances in Cryptology - EUROCRYPT, 2015.

[11] A. F. Anta, K. Konwar, C. Georgiou, N. Nicolaou, Formalizing and imple-

menting distributed ledger objects, SIGACT News (2018).

[12] IBM Hyperledger Consortium, Hyperledger sawtooth (2017).

URL https://sawtooth.hyperledger.org/docs/core/releases/

latest/index.html

[13] B. Milewski, Pure functions, laziness, i/o, and monads (2014).

URL https://www.schoolofhaskell.com/school/starting-with-

haskell/basics-of-haskell/3-pure-functions-laziness- io

10