Conference PaperPDF Available

# The Burn-to-Claim cross-blockchain asset transfer protocol

Authors:

## Abstract

The future of multi-blockchain architecture depends on the emergence of new protocols that achieve communication between trustless cross-chain participants. However, interoper-ability between blockchains remains an open problem. Existing approaches provide integration through solutions using a middle-ware system, which makes it harder to gain confidence mainly in terms of security and correctness of the process. A cross-chain protocol needs to provide a self-verifiable state-proof that embeds trust in the transfer process. We propose a Burn-to-Claim cross-chain protocol to seamlessly exchange assets between networks. Our scheme transfers assets from one blockchain system to another in a way that the asset is burned from the source blockchain and claimed on the destination blockchain. Our mechanism employs combinations of crypto mechanisms such as digital signatures and time lock to operate the protocol in a distributed manner. We provide an analysis which proves that our cross-chain protocol transfers assets correctly and securely.
The Burn-to-Claim cross-blockchain asset transfer
protocol
Babu Pillai
School of ICT
Grifﬁth University
Gold Coast, Australia
babu.pillai@grifﬁthuni.edu.au
Kamanashis Biswas
Australian Catholic University
Brisbane, Australia
kamanashis.biswas@acu.edu.au
Zh´
e H´
ou
School of ICT
Grifﬁth University
Brisbane, Australia
z.hou@grifﬁth.edu.au
Vallipuram Muthukkumarasamy
School of ICT
Grifﬁth University
Gold Coast, Australia
v.muthu@grifﬁth.edu.au
Abstract—The future of multi-blockchain architecture depends
on the emergence of new protocols that achieve communication
between trustless cross-chain participants. However, interoper-
ability between blockchains remains an open problem. Existing
approaches provide integration through solutions using a middle-
ware system, which makes it harder to gain conﬁdence mainly
in terms of security and correctness of the process. A cross-
chain protocol needs to provide a self-veriﬁable state-proof that
embeds trust in the transfer process. We propose a Burn-to-
Claim cross-chain protocol to seamlessly exchange assets between
networks. Our scheme transfers assets from one blockchain
system to another in a way that the asset is burned from the
source blockchain and claimed on the destination blockchain.
Our mechanism employs combinations of crypto mechanisms
such as digital signatures and time lock to operate the protocol in
a distributed manner. We provide an analysis which proves that
our cross-chain protocol transfers assets correctly and securely.
Index Terms—blockchain, interoperability, asset transfer,
cross-blockchain protocol
I. INTRODUCTION
Blockchain technology offers an immutable, decentralized,
and transparent mechanism for transaction processing. In-
terestingly, beyond its role as a protocol for exchanging
values within a network, one might reasonably assume that
a blockchain system should be able to transfer assets between
networks. However, the current architecture of this technology
limits the transaction within the same network. A blockchain
application cannot uniformly use multiple networks and obtain
a composition of their guarantees [1]. A core reason of
this issue is that each blockchain network has its own state
assumptions of the proof-problem [3], and without restrictions,
one network cannot verify the information in a different
network. Therefore, currently, seamless composition between
two blockchain networks is difﬁcult [12].
The cross-blockchain integration would enable the in-
teroperability among distinct, potentially heterogeneous,
blockchains [8]. However, with the current protocols of
blockchain systems, it is difﬁcult to have direct interoperability
between systems [4]. There is no method in the system to
provide a cross-chain value transfer; therefore, external third-
party services are the preferred solution [1, 12]. However,
the blockchain system cannot recognise and verify any such
process carried out by a third-party provider. Today most en-
terprise blockchain applications reside on private blockchains
such as Hyperledger and Corda and unable to leverage the full
potential of the distributed ledger technology.
To address the above issues, we propose a built-in process
that is integrated with the protocol to carry out transactions and
facilitate interoperability between systems. We ﬁrst formalise
the concept of interoperability from our previous work [13]
and then introduces the Burn-to-Claim cross-blockchain proto-
col – a built-in method to address cross-chain interoperability.
We deﬁne it as a protocol which consists of two components:
an exitTransaction to generate a self-veriﬁable proof and an
entryTransaction to verify the validity of the proof in order to
re-create the asset. The contribution of this paper are threefold:
Protocol: We propose a protocol for cross-blockchain
asset transfer where transactions are performed in a
decentralised and trustworthy manner.
Workﬂow: We propose a novel and simple workﬂow
which is ﬂexible and can be adopted for digital asset
transfer among blockchain networks without violating the
key characteristics of the blockchain technology.
Analysis: We perform a preliminary analysis to show
the correctness, security and fairness of the proposed
protocol.
A. Assumptions
The following assumptions are made in the proposed protocol:
The underlying blockchain networks are secure with a
concept of transaction ﬁnality within ﬁnite time, after
which the transactions cannot be rolled back [2].
The participants involved in the cross-communication
process ‘trust’ each other to a required minimum level
and are willing to process the transaction if valid proof
is presented by the other party. The required level of trust
varies depending on the application and to be agreed by
both parties.
The network nodes are motivated to take part in the
respective proof-mechanism (mining process) on both the
chains.
A transaction output carry a single output which cor-
responds to a single asset and the networks involved
recognize and form a common understanding of the assets
they are transacting.
Under these assumptions, once a transaction is broadcasted,
the network nodes verify the transaction and include it in
a block. A blockchain system tends to synchronise using a
protocol in which the network nodes constantly try to produce
new blocks and broadcast their achievements to the entire
network. In the case of cryptocurrencies, for instance, this
behaviour is motivated by mining rewards. Here also we
assume there is an appropriate incentive mechanism to support
participation by nodes.
II. TH E BURN-TO -CLA IM P ROT OC OL
In this section we formally deﬁne the proposed Burn-to-
Claim protocol and its primitives. A summary of notations
used in this paper is available under this Git repository1.
A. Communication between networks
The Burn-to-Claim protocol consists of two main functions
for the communication between networks: exitTransaction
which locks the asset and serves as a transfer-proof in the
source network, entryTransaction which veriﬁes the validity
of the transfer-proof in order to re-create the asset in the
destination network.
In our protocol, the sender who wants to transfer the asset
must present a proof that the asset is locked. To achieve this,
we adopt the proof-of-burn protocol [10, 14], which presents
a mechanism where the sender transfers the asset to a non-
spendable burn-address and is able to present that transaction
as a proof for the locked asset.
an address to which one can send assets, but from where
they can never be recovered because there is no private key
The process of burning consists of sending crypto asset to an
address where they become inaccessible and useless. Typically,
do not have a corresponding private key therefore the asset
at those addresses are not spendable. The burn protocol [10]
presents proofs such that if the underlying cryptographic
scheme is secure then the probability of ﬁnding a private key
for a given burn address is nearly negligible.
1) Exit transaction: The exit-transaction must be initiated
on the source network by the sender. This execution checks the
validity of the transaction and generates a transfer-proof. The
transaction-validity process checks the authenticity of the asset
and the owner’s ability to spend. The transfer-proof generator
produces a proof that the asset exists and it is locked while
the asset is in transit. This transaction aims to create an exit
proof for that asset in the source blockchain network. Having
an exit proof created by the system as part of the protocol will
ensure the system’s security. Moreover, the network comes to
a consensus about the asset transfer, thereby the authenticity
of the information is satisﬁed.
In our protocol, exitTransaction uses a conditional time-lock
with a secret code – the former determines a time frame for
1https://github.com/b-pillai/burn-to-claim
the transaction, and the latter is used to claim the asset in the
destination network. A time-lock is deﬁned as a function that
locks the output of a transaction for a period of time such that
the asset cannot be spent until the time has elapsed2.
Our protocol requires the sender to generate a secret code γ
using a random key generator function, keyGen(). Then the
secret code γis encrypted using the public key of the recipient
KR
pbefore sharing with recipient. The encrypted secret code
is denoted by Γ. We assume the public key information is
shared among users during the preparation stage.
Algorithm 1 exit-transaction-protocol
1: function exitTransaction(T x(KS
p,KS
2: if exportVeriﬁer(KS
3: KS
4: vis timelocked(v, t) at βin N1
5: T xt(T x,H(γ),σ)
6: else
7: invalid transaction
8: end if
9: return transaction receipt
10: end function
The function exitTransaction deﬁned in Algorithm 1 takes a
tuple of (T x(KS
p,KS
adr,β,v,T x), H(γ),σ) as inputs where
T x includes the sender’s public key (KS
burn-address (β), asset (v) and the previous transaction (T x)
in which the asset vwas spent. H(γ)represents the hash value
of secret code γand σis the digital signature of the T x .
Deﬁnition 2 (exportVeriﬁer).The exportVeriﬁer function con-
sists of two sub-functions spendVeriﬁer and assetVeriﬁer, it
returns true when both sub-functions return true, and it returns
false otherwise.
spendVeriﬁer:
returns true if for the given KS
p
the function verify(T x,KS
p,σ) returns true and
p) returns KS
returns false otherwise.
assetVeriﬁer:
returns true if balance(KS
adr) is true and T xis
included in a valid state;
returns false otherwise.
If exportVeriﬁer returns true then the transaction executes
the transfer of the asset to the given burn-address βwith
conditions such that the asset is time-locked within the source
network for a deﬁned time-lock period tand the hashed secret
code H(γ)is added to the data structure of the transaction.
2) Entry transaction: The purpose of the entry-transaction
is to recreate the asset in the destination network. An entry-
transaction must be initiated in the destination network by
the recipient. Upon initiating the entryTransaction with the
transfer-proof from source chain, the network nodes verify the
validity of the transfer-proof and recreate the asset.
2https://bcoin.io/guides/cltv.html
Algorithm 2 entry-transaction-protocol
1: function entryTransaction((T x(KR
p,KR
2: if importVeriﬁer(T x,T x,σ)and
3: (T x.time-lock is under the time limit) and
4: decrypt(Γ,KR
r) = T x.H(γ)) is true then
5: βKR
6: T xe(T x,H(γ),σ)
7: else
8: invalid transaction
9: end if
10: return transaction receipt
11: end function
The function entryTransaction deﬁned in Algorithm 2 takes
a tuple (T x (KR
p,KR
adr,β v,T x), Γ,σ) as input where
the T x includes the recipient public key KR
p, the recipient
transaction T x;Γrepresents the encrypted secret code and σ
denotes the digital signature.
Deﬁnition 3 (importVeriﬁer).The importVeriﬁer consists of
two functions spendVeriﬁer and proofVeriﬁer, it returns true
when both sub-functions return true, and false otherwise.
spendVeriﬁer:
returns true if for the given burn-address βfrom
KR
pthe function verify(T x,KR
r,σ) returns true and
p) returns KR
use a source chain version of getAddress function);
returns false otherwise.
proofVeriﬁer:
returns true if βis generated from KR
=burn,T xis included in a valid state;
otherwise returns false.
A proofVeriﬁer is an extended version of assetVeriﬁer.
Here the nodes on the destination network need to verify the
proof from the source network. We assume that through the
gateway mechanism, the destination network nodes are able
to verify the proof. Through the T xany gateway node can
access the speciﬁc transaction in the source network. Once the
importVeriﬁer returns true, the mining nodes need to check the
time-lock and the secret code. We assume that both the source
and the destination network run on a global clock. If the time
is under the time-lock period and the hash of decrypted secret
code matches with the hash value embedded in the transaction,
the network awards the asset to the recipient address KR
B. Workﬂow of the protocol
This section presents a walk-through of the workﬂow of
the burn-to-claim protocol. We begin with a use case of
two blockchain systems which are self-sufﬁcient and secure.
The two networks run different applications but they want
to interoperate. These networks may have distinct consensus
participants that employ different agreement protocols. It is
assumed that the majority of consensus participants in both
networks are honest. Here the assumption is that even though
these systems are not connected, they have enough credibility
which is governed by a protocol and have some common
agreements. For example, they can be two different businesses
with a collaborative business interest, different branches of a
company or different departments in an organisation. The main
objective of this paper is to address the cross-blockchain trans-
action proof-problem. Therefore, we focus on the construction
of consensus on how the transactions are veriﬁed, and on what
conditions the transactions are valid.
1) Network assumptions: To address the state proof-
participants and their ability to mine. We assume that the
cryptographic primitives of the networks are secure. For the
underlying network, we make the same assumptions as pre-
sented in [5, 11]. One assumption is that the nodes in sender
and receiver networks are synchronized with a global clock.
In the network of our model, some nodes are elected
as gateway nodes. We envision each blockchain as an au-
tonomous system, which communicates with each other via a
cross-blockchain protocol. To facilitate communication among
blockchains, the nodes can rely on decentralised integration
mechanisms that can identify and address cross-chain inte-
gration. This decentralised integration mechanism acts as a
veriﬁcation method for the cross-blockchain protocol. The
architecture of our model can be seen as a number of net-
works (based on the topology) connected through a gateway
mechanism to create a network-of-networks (NoN) [6].
There will be multiple nodes which function as gateways on
the same network; therefore, they will be competing against
each other for the mining reward. We assume that not all
the nodes will verify the transaction, but a sufﬁcient number
of them must do to satisfy the security of the system. The
other nodes will accept a gateway node’s proposal based on
the credibility of the gateway node in the network. We leave
further discussions on a decentralised integration mechanisms
for future work.
2) Example: We set an example where Alice (the sender
Sin the blockchain network N1) wants to transfer an asset
to Bob (the recipient Rin the blockchain network N2). Alice
ﬁrst submits an exitTransaction to network N1. Network N1
executes the transaction, effectively burns Alice’s asset in
network N1. Bob notices that the asset has been burned
successfully and submits the proof of burn to network N2.
Network N2veriﬁes the proof and if successful, recreates the
asset and assigns it to Bob’s account. Figure 1 shows a brief
overview of the protocol construction.
3) Preparation stage: In the preparation stage, ﬁrst, Alice
Sand Bob Rrequire to exchange their public keys via a key
exchange mechanism. Suses the public key of Rto encrypt
the secret code (γ) and share the encrypted secret code (Γ)
with Rto initiate entryTransaction. Then, they mutually agree
on the time-lock period t. After that, Alice Sgenerates the
burn address (β). Here, we describe the steps in detail.
In order to spend value in an address Kadr, a user needs to
prove the ownership of the public key that is used to generate
Figure 1. A high level overview of the Burn-to-Claim protocol workﬂow. The boxes represent chained blocks along the time steps in the source and destination
networks. At the preparation stage, Sgenerates and shares an encrypted secret code encrypt(γ) with R. At the commit stage, Sinitiates the exitTransaction,
burning the asset to βgenerated from R’s address, then time-locks the transaction output with the hash value of H(γ). After conﬁrmation period Rgets
notiﬁed with the previous transaction T x. At the execution stage, Rinitiates exitTransaction, claiming asset v. To do that Rmust prove the relation with
βand reveal γwithin the time-lock period. If Rfailed to claim the v,Sreclaims the vafter the time-lock period.
no private key can be considered as burned. However, how
do we know that an address does not have a private key?
To address this issue and to make a more speciﬁc proof in
adr) and returns β. This will
guarantee that the address βdoes not have a private key in
the source network and βis more speciﬁc to the recipient R
because it is generated from R’s address. Therefore, we can
use such a transfer to burn address as a valid proof.
Now that we have the proof we need to add a provision
for retrieving the asset in case of an unsuccessful transfer.
For instance, the asset is burned on the source chain and
not recreated in the recipient network, or the asset is sent
to a wrong address. We name this property as reclaim-from-
burn and explain the process in Algorithm 4. To ensure
this correctness of this property, we impose a time-lock on
transaction output in the source network. This will stop the
sender from claiming the asset back before the recipient claims
the asset. The time-lock period is agreed based on factors such
as the network latency and consensus timing, which we refer
to as transit-time.
We also need to consider the double-spending problem
where a dishonest sender commits exit-transaction on the same
asset multiple times [9]. In order to prevent double-spending,
our protocol uses a secret code and a time-lock value. To claim
an asset, the recipient must reveal the secret code whereas the
sender is unable to reclaim an asset until the time-lock period
is expired.
4) Commit stage: In the commit stage, Screates and
broadcasts an exitTransaction to invoke Algorithm 2 in the
network N1.
Algorithm 3 exit-transaction-time-key-lock condition
1: while (time-lock is true) do
2: if (Rclaim v)then
3: Rreveal secret γto N2
4: N1.miner gets γfrom N2
5: N1.miner claims his γ-locked fee
6: .secret γis known to N1&N2
7: end if
8: end while (after the tlock)
9: if (Rfail to claim v)then
10: Sreveals γto N1
11: Sre-claim v
12: N1.miner claim his γ-locked fee
13: .secret γis known to N1
14: end if
Algorithm 3 shows the transfer condition logic. The con-
dition here is that anyone claiming the transaction output
(includes the asset and the miner’s fee) must reveal the secret
code. Therefore, the transaction will be mined by the miners
need to get the secret code to claim the fee. That means if
there is no valid gateway node then this transaction will not
go through in the ﬁrst place.
The time-key-lock condition mechanism allows only one
party to claim the asset at a time. For example, while the
T xtoutput is time-locked in the source network, if Rreveals
the secret code γin her network, the miner who mined this
transaction in the source network will reveal it in source
network to claim his fees; thereby the γis known to both
networks. After that, Swill not be able to claim the asset.
Likewise, if Rfails to claim the asset within the time frame,
then Sreveals γafter tlock expired in the source network to
reclaim the asset. In our design γis not known to the network;
therefore, once the γis revealed nobody will be able to claim
the asset even after tlock the expiry of tlock.
5) Execution stage: The execution stage has two possi-
bilities: either Rclaims the asset within the transit time-
lock period or Sreclaims the asset after the time-lock period
expired.
a) Rclaims the asset: Rconstructs an entry-transaction
and broadcasts to N2. If Rcan prove the ownership of KR
r
and KR
adr, the network will be able to process the transaction.
However, our protocol requires a solid evidence that Shas
burned the asset von the source network. Here Rprovides a
burn-address βand a previous transaction T x, which form
the proof of commit in the source chain.
Our protocol requires a mining process where some nodes
are able to mine in multiple blockchains. With that require-
ment, among nnumber of nodes mgateway nodes propose
this transaction and eventually one proposal will get accepted
by the network. We assume that these gateway nodes are
able to validate the transfer-proof with T x. The nodes verify
that transaction occurred on the source chain by ensuring that
the transaction is contained in a block. This can be done by
checking the chain validity [7] of the block and the transaction.
If importVeriﬁer returns true the network awards the asset v
adr. That means by now the secret
code γis known to the network, and after that, the source
network miner will take it to the source network to claim his
fee, and then γis known to both the networks.
b) Sreclaims the asset: In case the recipient has not claimed
the asset within the time-lock period, the sender gets notiﬁed
by the network or the mining node who mined the T xt, and the
sender then invoke reclaimTransaction, which is is a variant
of entryTransaction and is deﬁned in Algorithm 4, to claim
the asset back. The transaction ﬁrst checks the signature via
verify(T x,KS
adr,σ), then checks the time-lock period and
secret code hash. As we stated earlier, our protocol requires
some miners to mine in both the chains. Therefore, we assume
that miners are able to check with the network N2before
approving this transaction.
Algorithm 4 reclaim-transaction-protocol
1: function reclaimTransaction((T x(KS
p,KS
2: if reclaimVeriﬁer() is true and
3: (T x.tlock pass the time limit) and
4: decrypt(Γ,KS
p) = T x.H(γ)) is true then
5: βKS
6: else
7: invalid transaction
8: end if
9: return transaction receipt
10: end function
The function of reclaimVeriﬁer consists of two sub-
functions spendVeriﬁer and proofVeriﬁer. The function check
if verify(T x,KR
r) returns
KR
adr. Then the proofVeriﬁer checks the transfer proof of T x
referring to if the balance(β) = burn and T xBand B
Qreturn true else return false. The reclaimTransaction can be
included with the entryTransaction but for clarity, we present
it as a separate transaction.
III. ANALYSI S
In this section, we analyse the correctness and security of
the Burn-to-Claim protocol. Cross-chain data guaranty/trust
is one of the most important means to enable interoper-
ability among blockchain networks. The integration process
for exchanging information may be based on other existing
techniques. But to build trust about the shared information we
must resolve speciﬁc properties of the individual transactions
involved in the exchange process; that is, security: a cryp-
tographic assurance of transfer commitment of transactions;
correctness: each successful transaction commits only one
valid outcome and fairness: either the transfer executes the
transfer of an asset or return the asset [2, 10].
It should be noted that the burn-address in our proposed pro-
tocol is not generated from a regular keypair, rather a unique
address is generated each time by combining the recipient
address and other parameters. Therefore, it is not spendable
in the current network. This means, with the signature scheme
of the underlying cryptocurrency, the asset burned in the
proposed scheme would remain unspendable.
Lemma 1 (Unspendability).A burn-address βis unspendable
with respect to a blockchain address protocol [11].
The main functionality of entryTransaction is to recreate
asset but only after the asset is burnt on the source chain.
In our protocol the asset must be permanently burned at the
commit stage. With the burn protocol and its property of
unspendability the asset is permanently burned before claiming
on the source chain.
Lemma 2 (Burn before claim).An asset vwhich is transferred
from N1to N2must be burned in N1before a user can claim
it in N2.
The sender who initiates the exit-transaction must own the
asset he is being transferred. In exitTransaction the exportVer-
iﬁer() checks the transaction validity and owner’s ability to
spend. This process must be carried by each mining node and
must reach the consensus of the network. Therefore, as long
as the network is secure, the participants can only exchange
the asset of their own.
Lemma 3 (Ownership).The function exitTransaction can only
be successfully executed if the sender owns the asset.
Theorem 1 (Security).The recipient network can rely on the
Burn-to-Claim exit-proof guarantee provided by the source
network.
The function exitTransaction transfers the asset vto a burn-
To claim v, the recipient must prove to the network that βis
derived from an address he owns. The function spendVeriﬁer
checks the signature σto verify the Kpand checks the whether
βis derived from the given Kpusing the function getAddress.
Therefore, only the user who owns a private key associated
with KR
adr can make the claim of the asset in the destination
network.
Theorem 2 (Correctness).The exchange operation only ex-
change an asset to a correct recipient.
We assume that no adversary can obtain the private key of
a secure signature scheme, except with negligible probability.
As a result, the correctness of our protocol is dependent on a
probabilistic polynomial-time adversary can decipher the key.
Let σbe a secure signature scheme then the possibility of
a distribution entity to decipher the Krfrom a Kpor βis
unpredictable.
Theorem 3 (Fairness).The exchange operation should only
execute one outcome, either the exchange succeeds and the
asset is transferred to the recipient, or it is failed and the
asset returns to the sender.
Fairness in our context means that both parties receive the
item they expect or neither do. The fairness theorem only relies
on the fact that a standard hash function is collision resistant.
By using hash preimage as the secret code of the conditional
payment, the atomicity of the transactions can be guaranteed
without the participation of a trusted third party, so as to realise
fair cross-chain exchange.
IV. CONCLUSION
In this paper, we analyse the blockchain transaction protocol
and propose to add new features that help solve the problem
of interoperability. One of the critical features of our method
is that it presents an internal functionality for value/asset
exchange. An internal protocol provides a universal language,
and via such a protocol, blockchain users can communicate
directly and transfer various forms of data using standardised
pathways. Furthermore, we brieﬂy showed that Burn-to-Claim
protocol is resilient to double-spending by its correctness and
fairness properties.
REFERENCES
[1] Rafael Belchior, Andr´
e Vasconcelos, S´
ergio Guerreiro,
and Miguel Correia. A survey on blockchain interoper-
ability: Past, present, and future trends. arXiv preprint
arXiv:2005.14282, 2020.
[2] Marianna Belotti, Stefano Moretti, Maria Potop-
Butucaru, and Stefano Secci. Game theoretical analysis
of Atomic Cross-Chain Swaps. PhD thesis, Caisse des
d´
epˆ
ots-Institut pour la recherche et Banque des terri-
toires, 2019.
[3] Michael Borkowski, Daniel McDonald, Christoph Ritzer,
and Stefan Schulte. Towards atomic cross-chain token
transfers: State of the art and open questions within
tast. Distributed Systems Group TU Wien (Technische
Universit at Wien), Report, 2018.
[4] Michael Borkowski, Christoph Ritzer, Daniel McDonald,
and Stefan Schulte. Caught in chains: Claim-ﬁrst trans-
actions for cross-blockchain asset transfers. Technische
Universit¨
at Wien, Whitepaper, 2018.
[5] Ittay Eyal, Adem Efe Gencer, Emin G¨
un Sirer, and
Robbert Van Renesse. Bitcoin-ng: A scalable blockchain
protocol. In 13th symposium on networked systems
design and implementation, pages 45–59, 2016.
[6] Jianxi Gao, Daqing Li, and Shlomo Havlin. From a single
network to a network of networks. National Science
Review, 1(3):346–356, 2014.
[7] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. The
bitcoin backbone protocol: Analysis and applications.
In Annual International Conference on the Theory and
Applications of Cryptographic Techniques.
[8] Thomas Hardjono, Alexander Lipton, and Alex Pent-
land. Towards a design philosophy for interoperable
blockchain systems. arXiv preprint arXiv:1805.05934,
2018.
[9] Ghassan O Karame, Elli Androulaki, and Srdjan Cap-
kun. Double-spending fast payments in bitcoin. In
Proceedings of the 2012 ACM conference on Computer
and communications security, pages 906–917, 2012.
[10] Kostis Karantias, Aggelos Kiayias, and Dionysis Zindros.
Proof-of-burn. In International Conference on Financial
Cryptography and Data Security, 2019.
[11] Aggelos Kiayias, Alexander Russell, Bernardo David,
and Roman Oliynykov. Ouroboros: A provably secure
proof-of-stake blockchain protocol. In Annual Interna-
tional Cryptology Conference, pages 357–388. Springer,
2017.
blockchain interoperability. Information Processing Let-
ters, page 105976, 2020.
[13] Babu Pillai, Kamanashis Biswas, and Vallipuram
Muthukkumarasamy. Cross-chain interoperability among
blockchain-based systems using transactions. The Knowl-
edge Engineering Review, 35, 2020.
[14] Iain Stewart. Proof of burn - bitcoin wiki. Available at:
https://en.bitcoin.it/wiki/Proof of burn, Dec 2012.
... Cross-blockchain protocols are an active area of research that tries to provide certain guarantees when moving value/data between blockchains networks [15]. Several protocols have been proposed over the past few years, such as hash time locks, cryptographic proofs -rollups [16], Proof-of-Burn [17], [18], [1] and signature-based protocols [19]. Technically, these proposals built on the security aspects of the cryptography involved in the protocols. ...
... Gas is the measure of the amount of Ether that is required to run. D. The Burn-to-Claim protocol Figure 1 shows a high level overview of the Burn-to-Claim protocol [1], [18] workflow. The vertical lines represent actors and horizontal arrows represent message activity along the time line. ...
... At the very high level, we aim to construct a model that consists of a scenario where a user wishes to transfer an asset from a blockchain network to another blockchain network. The Burn-to-Claim [1], [18] protocol executes the transfer process so that the asset is being destroyed (removed) from one blockchain network and re-created on the other blockchain network. The networks involved in this process are source networks from where the asset is removed and destination networks to where the asset is moved. ...
... It gives the guarantee that the token is permanently destroyed before being transferred onto another network [43]. We refer to our previous work for details on a burn-to-claim protocol [44], [45]. ...
... Integration systems aim to address this problem by implementing different protocols to accomplish the composability of cross-blockchain transactions between integrating networks. Consequently, there exist a range of cross-blockchain protocols such as atomic swap, lock/unlock, burn/mint to be used based on the use-cases [10], [12], [13], [44]. ...
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.
Article
Full-text available
The future of multi-blockchain architecture depends on the emergence of new protocols that enable consensus between trustless cross-blockchain participants. However, interoperability between blockchains remains a research challenge. The existing interoperability approaches provide integration through solutions using a middleware system, making it difficult to gain confidence in the security and correctness of the process. A cross-blockchain protocol must provide a self-verifiable state proof that encodes trust in the transfer process to guarantee consensus. Inspired by the burn-address concept, we propose a Burn-to-Claim cross-blockchain protocol to exchange assets between two networks. The proposed protocol transfers assets from one blockchain system to another so that the asset is burned from the source blockchain and recreated on the destination blockchain. Our protocol makes use of digital signatures, hash-time-locks and integration mechanisms to perform cross-blockchain transactions in a distributed manner. We theoretically prove that the proposed cross-blockchain protocol transfers assets securely and correctly. In addition, the experimental results demonstrate the feasibility of the Burn-to-Claim protocol when used in an application environment.
Article
Full-text available
The blockchain is an emerging technology which has the potential to improve many information systems. In this regard, the applications and the platform they are built on must be able to connect and communicate with each other. However, the current blockchain platforms have several limitations, such as lack of interoperability among different systems. The existing platforms of blockchain applications operate only within their own networks. Even though the underlying technology is similar, it relies on centralized third-party mediators to exchange or retrieve information from other blockchain networks. The current third-party intermediaries establish trust and security by preserving a centralized ledger to track ‘account balances’ and vouch for a transaction’s authenticity. The inability for independent blockchains to communicate with one another is an inherent problem in the decentralized systems. Lack of appropriate inter-blockchain communication puts a strain on the mainstream adoption of blockchain. It is evident that blockchain technology has the potential to become a suitable solution for some systems if it can scale and is able to cross communicate with other systems. For the multisystem blockchain concept to become a reality, a mechanism is required that would connect and communicate with multiple entities’ blockchain systems in a distributed fashion (without any intermediary), while maintaining the property of trust and integrity built by individual blockchains. In this article, we propose a mechanism that provides cross-chain interoperability using transactions.
Article
Full-text available
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.
Research
Full-text available
Blockchains, the fundamental technology upon which cryptocurrencies are implemented, have gained considerable interest in finance, economics, and research. Nevertheless, the numerous blockchains in existence remain mostly unconnected, with no possibilities for interoperability. While approaches for atomic swaps (the atomic exchange of value on two blockchains) are emerging, there is still no documented implementation of a protocol for the transfer of assets from one blockchain to another. This white paper formalizes the cross-blockchain proof problem, showing that in practice, it is not possible to verify the existence of specific data on one blockchain from within another blockchain. Based on this, we describe the concept of a cross-blockchain asset transfer protocol using claim-first transactions. This protocol allows for decentralized transfer of assets between blockchains despite the cross-blockchain proof problem.
Research
Full-text available
Cryptocurrencies share a broad overall purpose, enabling distributed, decentralized and trustless transfers of value. Nevertheless, the various blockchains upon which each cryptocurrency is implemented remain, for the most part, unconnected. While approaches for atomic swaps (the secure exchange of tokens on one chain for another) are emerging, there is still no documented implentation of such a system that adheres to cryptocurrency's orientation toward decentralisation and trustlessness. In this paper, we propose the concept of atomic cross-chain token transfers, which will connect various blockchains, foster collaboration between various stakeholders, and to mitigate risk to end users of a specific blockchain. This paper reviews the current state of the art, both in terms of blockchains and atomic swap technologies. More specifically, we survey twenty of the most prominent blockchains, as well as fourteen currently operational or forthcoming cryptocurrency systems, discussing their features and potential usability for atomic cross-chain token transfers. We then identify several open key challenges for such token transfers, and discuss potential directions of research.
Conference Paper
Full-text available
We present “Ouroboros”, the first blockchain protocol based on proof of stake with rigorous security guarantees. We establish security properties for the protocol comparable to those achieved by the bitcoin blockchain protocol. As the protocol provides a “proof of stake” blockchain discipline, it offers qualitative efficiency advantages over blockchains based on proof of physical resources (e.g., proof of work). We also present a novel reward mechanism for incentivizing Proof of Stake protocols and we prove that, given this mechanism, honest behavior is an approximate Nash equilibrium, thus neutralizing attacks such as selfish mining.
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.
Technical Report
Full-text available
Cryptocurrencies, based on and led by Bitcoin, have shown promise as infrastructure for pseudonymous online payments, cheap remittance, trustless digital asset exchange, and smart contracts. However, Bitcoin-derived blockchain protocols have inherent scalability limits that trade-off between throughput and latency and withhold the realization of this potential. This paper presents Bitcoin-NG, a new blockchain protocol designed to scale. Based on Bitcoin's blockchain protocol, Bitcoin-NG is Byzantine fault tolerant, is robust to extreme churn, and shares the same trust model obviating qualitative changes to the ecosystem. In addition to Bitcoin-NG, we introduce several novel metrics of interest in quantifying the security and efficiency of Bitcoin-like blockchain protocols. We implement Bitcoin-NG and perform large-scale experiments at 15% the size of the operational Bitcoin system, using unchanged clients of both protocols. These experiments demonstrate that Bitcoin-NG scales optimally, with bandwidth limited only by the capacity of the individual nodes and latency limited only by the propagation time of the network.
Article
Full-text available
Network science has attracted much attention in recent years due to its interdisciplinary applications. We witnessed the revolution of network science in 1998 and 1999 started with small-world and scale-free networks having now thousands of high-profile publications, and it seems that since 2010 studies of ‘network of networks’ (NON), sometimes called multilayer networks or multiplex, have attracted more and more attention. The analytic framework for NON yields a novel percolation law for n interdependent networks that shows that percolation theory of single networks studied extensively in physics and mathematics in the last 50 years is a specific limit of the rich and very different general case of n coupled networks. Since then, properties and dynamics of interdependent and interconnected networks have been studied extensively, and scientists are finding many interesting results and discovering many surprising phenomena. Because most natural and engineered systems are composed of multiple subsystems and layers of connectivity, it is important to consider these features in order to improve our understanding of such complex systems. Now the study of NON has become one of the important directions in network science. In this paper, we review recent studies on the new emerging area—NON. Due to the fast growth of this field, there are many definitions of different types of NON, such as interdependent networks, interconnected networks, multilayered networks, multiplex networks and many others. There exist many datasets that can be represented as NON, such as network of different transportation networks including flight networks, railway networks and road networks, network of ecological networks including species interacting networks and food webs, network of biological networks including gene regulation network, metabolic network and protein-protein interacting network, network of social networks and so on. Among them, many interdependent networks including critical infrastructures are embedded in space, introducing spatial constraints. Thus, we also review the progress on study of spatially embedded networks. As a result of spatial constraints, such interdependent networks exhibit extreme vulnerabilities compared with their non-embedded counterparts. Such studies help us to understand, realize and hopefully mitigate the increasing risk in NON.
Conference Paper
Full-text available
Bitcoin is a decentralized payment system that relies on Proof-of-Work (PoW) to verify payments. Nowadays, Bitcoin is increasingly used in a number of fast payment scenarios, where the time between the exchange of currency and goods is short (in the order of few seconds). While the Bitcoin payment verification scheme is designed to prevent double-spending, our results show that the system requires tens of minutes to verify a transaction and is therefore inappropriate for fast payments. An example of this use of Bitcoin was recently reported in the media: Bitcoins were used as a form of \emph{fast} payment in a local fast-food restaurant. Until now, the security of fast Bitcoin payments has not been studied. In this paper, we analyze the security of using Bitcoin for fast payments. We show that, unless appropriate detection techniques are integrated in the current Bitcoin implementation, double-spending attacks on fast payments succeed with overwhelming probability and can be mounted at low cost. We further show that the measures recommended by Bitcoin developers for the use of Bitcoin in fast payments are not always effective in detecting double-spending; we show that if those recommendations are integrated in future Bitcoin implementations, double-spending attacks on Bitcoin will still be possible. Finally, we propose and implement a modification to the existing Bitcoin implementation that ensures the detection of double-spending attacks against fast payments.