ArticlePDF Available

Abstract

A blockchain is designed to be a self-sufficient 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 different 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 definition of a blockchain. Under a weaker definition of blockchain, we demonstrate 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 first place. We also observe that all practical existing interoperable blockchain frameworks work indeed by exchanging already created tokens between two blockchains and not by offering the possibility to transfer tokens from one blockchain to another one, which implies a modification of the balance of total created tokens on both blockchains. It confirms that having interoperability is only possible by creating a ‘2-in-1’ blockchain containing both ledgers.
About Blockchain Interoperability
Pascal Lafourcade1and Marius Lombard-Platet2,3
1Universit´e Clermont-Auvergne, LIMOS CNRS UMR 6158,
Aubi`ere, France
2epartement 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-sufficient 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 different 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 defini-
tion of a blockchain. Under a weaker definition 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 first 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 offering the possibility to transfer tokens from one blockchain to
another one, which implies a modification of the balance of total created
tokens on both blockchains. It confirms that having interoperability is
only possible by creating a ‘2-in-1’ blockchain containing both ledgers.
Keywords: Decentralized ledger, interoperability
1 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
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 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 inter-
operability, providing a formal definition of a blockchain and of interoperabil-
ity. We then prove that, by definition, 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 define
it later on. In an ILP transaction from blockchain Ato blockchain B, one
must find 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 specific
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 define 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 definition 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 xAlgorithm(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 difference of Aand B.)
2.1 Blockchain Definition
Various definitions 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 certificate 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.
Definition 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 defined 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) = Wt.
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 effects on the
blockchain.
At this point, transactions are appended (or not) to the blockchain after a
call to Mine. We hereby give a formal definition of what a valid transaction is.
Definition 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 affect the state of the ledger. Because Mine has access
to the whole ledger, it can take into account the smart contract’s side effects.
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.
Definition 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 first 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.
Definition 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 prefix
of L0.
This definition makes a blockchain immune against history rewriting (and
double spending), as it is computationally hard to rewrite old blocks.
2.2 Interoperability Definition
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 definition.
Definition 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 ωAA,
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 first result is to show that it is impossible to have interoperability between
two blockchains in general.
5
Theorem 1. Under the definitions 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 LBB\ωB, then ConsensusAwill refuse
any block containing t.
However, ConsensusAonly takes A, S as arguments, where Sis a set of tuples
(Li,Wi) (see Definition 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 LBB\ωB; this implies that
B\ωB=, i.e., ωB= ΩB, which is a contradiction with the hypothesis of
Definition 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-sufficient: 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 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 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 definition, is now
noted ConsensusA(A,,·). Similarly, the non-interoperable version of Mine is
now noted as MineA(LA,,WA,).
Definition 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 define accounts. An account ownership is defined
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) specifies the sender’s
public key, the receiver’s public key, an amount and a signature of the previous
fields 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 first 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 fulfil the previous requirements. First, let us
define 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 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 valid transaction on the other blockchain. This
definition 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 definition we give is enough for practical
uses.
Definition 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 ϕ:TATBsuch 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
Definition 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 definition
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 effects on the state of the
blockchain will be equivalent to the effects on the state of the image blockchain:
in both cases, the acceptable elements after the transaction are the same (up
to a bijection). This definition 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 definition does not affect 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 define 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 define: 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 define 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 definition 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
affected 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 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.
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
... Even though the core concept and capabilities between the blockchain platforms and networks remain similar, due to the inherent nature of the technology, they are not readily interoperable [4]. Therefore, these networks must be appropriately integrated to achieve interoperability. ...
... In [24] the authors defined it as semantic dependence between distinct ledgers of blockchains for the purpose of transferring or exchanging data/ value, with assurances of validity or verifiability. Authors in [4] expect that, if one blockchain's network rules accept a transaction from another network, then they are interoperable with each other. Authors in [25] and [12] cited a technical report from the National Institute of Standards and Technology defining interoperability as the ability of one system to change the state of another blockchain system. ...
... 4, 2022 ...
Article
Full-text available
Interoperability is identified as one of the major design constraints for blockchain technology. Cross-blockchain technology is fast evolving as the demand for value transfer among different blockchain systems is growing. A generic cross-blockchain design methodology for interoperability requires a set of suitable components to facilitate the integration process. One of the main challenges in the integration is to protect the integrity of the shared data. Various integration systems and their components may operate with different underlying security assumptions and this may lead to compromise of the overall security. In this paper we review the latest advancement in blockchain integration systems and provide a comprehensive analysis of integration characteristics for cross-blockchain technology and then define the essential components and modes of integration. Based on the outcome of our review, we propose a novel integration design decision framework that identifies key assumptions and critical characteristics of the cross-blockchain technology. The proposed framework facilitates the best-practice decision-making process. This reduces the potential for design errors and the associated security risks and performance degradation of the overall system. INDEX TERMS blockchain interoperability, cross-blockchain technology, blockchain integration system, cross-blockchain protocol, cross-blockchain integration framework.
... Blockchain allows for improved and more secured integration of third-party products [82][83][84][85], while reducing the danger of revealing sensitive information to such parties. In addition, interoperability [86][87][88] fosters the promotion and acceptance of blockchain by providing a common way for involved agents to interact with one another via blockchain transaction ledgers and integrated networks, ensuring the validity of each engaged party. ...
... Information systems [79][80][81][82][83][84][85][86][87][88][89][90][91][92][93][94][95][96][97][98] (1) Improved and more secured integration of third-party products; (2) a common way for involved parties to interact with one another; (3) validating data and ensuring the transaction integrity; (4) tracking a product's origin more readily. ...
Article
Full-text available
Blockchain is a modern technology that has revolutionized the way society interacts and trades. It could be defined as a chain of blocks that stores information with digital signatures in a distributed and decentralized network. This technique was first adopted for the creation of digital cryptocurrencies, such as Bitcoin and Ethereum. However, research and industrial studies have recently focused on the opportunities that blockchain provides in various other application domains to take advantage of the main features of this technology, such as: decentralization, persistency, anonymity, and auditability. This paper reviews the use of blockchain in several interesting fields, namely: finance, healthcare, information systems, wireless networks, Internet of Things, smart grids, governmental services, and military/defense. In addition, our paper identifies the challenges to overcome, to guarantee better use of this technology.
... The blockchain system supports commercial scenarios such as insurance, credit investigation, asset securitization, intellectual property rights and registration; in the future, they will establish their own blockchain platforms in more fields. The cross-chain technology of blockchain is an important technical method for interoperability and scalability between interconnected blockchains [22,23]. However, not only the security of data but also the realization of data is the focus of business concern in data production management, especially in quantum computing environments. ...
Article
Full-text available
There is an obvious demand for blockchain to break the "data island" by crossing chains. Notary signature is one of the common cross-chain methods, and its security depends on the security of the signature algorithm. However, with the development of quantum computing, classical authentication of blockchain based on mathematical cryptography algorithms is not secure enough to prevent quantum attacks. Designing a signature algorithm to ensure the security of blockchain transactions in the post-quantum era is a problem to be solved at present. In the existing quantum signature algorithms, there are some problems, such as the arbitrators are not completely trusted, the quantum measurement loss is not traceable, and the transaction efficiency is low. Hence, our main work is as follows: (i) A cross-chain transaction model is proposed, which includes a quantum multi-signature notary mechanism and an assets quantum-freeze algorithm. (ii) The quantum multi-signature scheme can not only prevent forgery and denial, but also trace back malicious notaries. Moreover, it has the advantages of low storage overhead, decentralization, and high efficiency. (iii) Quantum freeze scheme can prevent messages from being tampered with when the system allocates transferred data or assets to the connector after transaction verification. It effectively improves system transaction security and ensures privacy.
... Even authors provide the current state of the art in cross-chain communication, their work does not focus on identifying security and privacy challenges regarding these protocols. On the other hand, [29] strictly follows the formal definition of interoperability and proves that it is impossible for two blockchains to interact with each other. The paper highlights that relaxing the definition gives the possibility to create a 2-in-1 blockchain with two ledgers. ...
... The authors in [26] conducted the study which discusses the need for generic interoperable blockchain protocol that is capable of exchanging tokens and data. However, the authors in [19] claimed the interoperability to be an impossible factor in the classic blockchain network. In [25], the researchers proposed the new definition of heterogeneous blockchain interoperability which states that two blockchains are interoperable if they are able to exchange cryptocurrencies. ...
Preprint
Blockchain has introduced new opportunities with the potential to enhance systems and services across diverse application domains. Fundamental characteristics of blockchains such as immutability, decentralisation, transparency and traceability have a profound role in this. However, integration with contemporary systems and among disparate blockchain-based applications is a non-trivial challenge primarily due to differences with respect to platforms, consensus mechanism, and governance. Although this challenge has received some attention from the research community, it requires careful analysis to analyse existing work and ascertain gaps to achieve effective and efficient solution to this challenge. This paper presents a thorough systematic review of existing research within blockchain interoperability highlighting significant contributions. Leveraging this analysis, the paper presents an internet-inspired framework (Chain-Net) to facilitate interoperability within blockchain-based systems whereby two systems within independent Blockchain networks can securely exchange data with each other. This is achieved by using gateway module at each network. This module is lightweight node registered by Blockchain network, equipped with discovery service to lookup a target blockchain, and is responsible for forwarding cross-chain transactions to gateway module at the target blockchain. Gateway module plays a vital role in Chain-Net model, as it holds a cross-chain transaction in a pending state until a confirmation is received from the target blockchain, thus maintaining the record integrity between the two chains. The paper presents our efforts to evaluate the proposed blockchain interoperability framework against a success criteria based on our analysis of the blockchain interoperability challenge.
... Even authors provide the current state of the art in cross-chain communication, their work does not focus on identifying security and privacy challenges regarding these protocols. On the other hand, [27] strictly follows the formal definition of interoperability and proves that is impossible for two blockchains to interact with each other. The paper highlights, that relaxing the definition gives the possibility to create a 2-in-1 blockchain with two ledgers. ...
Preprint
Blockchain technology has achieved increased interest over the last few years. Transferring data and value across different blockchains is one of the biggest obstacles to further expansion. Blockchain interoperability allows different networks to communicate and transfer data between them and are increasingly crucial for blockchain applications. However, the concern about security and privacy in blockchain interoperability arises naturally. This work aims to provide the state-of-the-art related to security and privacy challenges in blockchain interoperability. We conducted a multivocal literature review (MLR) and analyzed 16 scientific and 30 grey literature, respectively. Our MLR identified security and privacy challenges in interoperable blockchain networks while presenting mitigation regarding these vulnerabilities. We have also identified further research directions to mitigate and prevent future attacks and exploitation.
... Blockchain is a chain of transactions, where each unit of the chain called "block" includes some transactions (none or one), and consensus is needed to create a new block (Lafourcade & Lombard-Platet, 2020). Blockchain is a suitable technique to digitalize operational procedures, including documentation, bill of lading and customer clearance (Balci, 2021a). ...
Article
Full-text available
The so-called “Fourth Industrial revolution”, also termed as “Industry 4.0” in the wider literature, is associated with several cutting-edge technologies. Indicative examples in this category are advanced applications like Artificial Intelligence (AI), Big Data Analytics (BDA), Cloud Computing and Internet of Things (IoT), which are already influencing the maritime industry. It is indicative of the fact that there are several construction projects of autonomous ships, such as the Yara Birkeland and the Autonomous Spaceport Drone Ship (ASDS), which are heavily reliant on technologies associated with the Industry 4.0 concept. The maritime transport industry is already transitioning into a new operations paradigm, often termed as “shipping in the era of digitalization”. Shipping companies promote digitalization as the future of the maritime industry and their efforts to set up strategies are already in progress. Examining those visions and strategies in relation to digitalization would be beneficial to better understand the way towards which the maritime industry is heading. This paper is aiming to identify the characteristics of that pool of future plans via a qualitative review and with a particular focus on major maritime commercial actors, based on shipping companies' relevant action plans that were gathered online. A conclusion standing out is that major shipping companies have embraced digitalization to increase cost-efficiency, raise competitiveness and meet the needs of their customers.
Article
Full-text available
Despite the hype about blockchains and distributed ledgers, no formal abstraction of these objects has been proposed. To face this issue, in this paper we provide a proper formulation of a distributed ledger object. In brief, we define a ledger object as a sequence of records, and we provide the operations and the properties that such an object should support. Implementation of a ledger object on top of multiple (possibly geographically dispersed) computing devices gives rise to the distributed ledger object. In contrast to the centralized object, distribution allows operations to be applied concurrently on the ledger, introducing challenges on the consistency of the ledger in each participant. We provide the definitions of three well known consistency guarantees in terms of the operations supported by the ledger object: (1) atomic consistency (linearizability), (2) sequential consistency, and (3) eventual consistency. We then provide implementations of distributed ledgers on asynchronous message passing crash-prone systems using an Atomic Broadcast service, and show that they provide eventual, sequential or atomic consistency semantics. We conclude with a variation of the ledger - the validated ledger - which requires that each record in the ledger satisfies a particular validation rule.
Conference Paper
Full-text available
Bitcoin is the first and most popular decentralized cryptocurrency to date. In this work, we extract and analyze the core of the Bitcoin protocol, which we term the Bitcoin backbone, and prove two of its fundamental properties which we call common prefix and chain quality in the static setting where the number of players remains fixed. Our proofs hinge on appropriate and novel assumptions on the “hashing power” of the adversary relative to network synchronicity; we show our results to be tight under high synchronization. Next, we propose and analyze applications that can be built “on top” of the backbone protocol, specifically focusing on Byzantine agreement (BA) and on the notion of a public transaction ledger. Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashing power is bounded by \(1/3\). The public transaction ledger captures the essence of Bitcoin’s operation as a cryptocurrency, in the sense that it guarantees the liveness and persistence of committed transactions. Based on this notion we describe and analyze the Bitcoin system as well as a more elaborate BA protocol, proving them secure assuming high network synchronicity and that the adversary’s hashing power is strictly less than \(1/2\), while the adversarial bound needed for security decreases as the network desynchronizes.
Article
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
Ethereum: A next-generation smart contract and decentralized application platform
  • V Buterin
V. Buterin, Ethereum: A next-generation smart contract and decentralized application platform (2014). URL https://github.com/ethereum/wiki/wiki/White-Paper
The ripple protocol consensus algorithm
  • D Schwartz
  • N Youngs
  • A Britto
D. Schwartz, N. Youngs, A. Britto, The ripple protocol consensus algorithm (2014). URL https://ripple.com/files/ripple_consensus_whitepaper.pdf
Crypto-currency blockchain explorers
  • Cryptoid
CryptoID, Crypto-currency blockchain explorers (2019). URL https://chainz.cryptoid.info/
  • S Johnson
  • P Robinson
  • J Brainard
S. Johnson, P. Robinson, J. Brainard, Sidechains and interoperability, arXiv e-prints (2019). arXiv:1903.04077.
A protocol for interledger payments
  • S Thomas
  • E Schwartz
S. Thomas, E. Schwartz, A protocol for interledger payments (2015). URL https://interledger.org/interledger.pdf
  • W Martino
  • M Quaintance
  • S Popejoy
W. Martino, M. Quaintance, S. Popejoy, Chainweb whitepaper (2018). URL http://kadena2.novadesign.io/wp-content/uploads/2018/08/ chainweb-v15.pdf
Pure functions, laziness, i/o, and monads
  • B Milewski
B. Milewski, Pure functions, laziness, i/o, and monads (2014). URL https://www.schoolofhaskell.com/school/starting-withhaskell/basics-of-haskell/3-pure-functions-laziness-io