SoK: Communication Across Distributed Ledgers

Alexei Zamyatin∗†, Mustafa Al-Bassam‡, Dionysis Zindros§††, Eleftherios Kokoris-Kogias¶,Pedro Moreno-Sanchez‖, Aggelos Kiayias∗∗††, and William J. Knottenbelt∗

∗Imperial College London†SBA Research

‡University College London§University of Athens

¶Ecole polytechnique federale de Lausanne‖TU Wien

∗∗University of Edinburgh††IOHK

Abstract—Communication across distributed systems, eachrunning its own consensus, is a problem previously studiedunder the assumption of trust across systems. With theappearance of distributed ledgers or blockchains, numerousprotocols have emerged, which attempt to achieve trustlesscommunication between distrusting ledgers and participants.Cross-chain communication thereby plays a fundamentalrole in cryptocurrency exchanges, sharding, bootstrappingand extension of distributed ledgers. Unfortunately, existingproposals are designed ad-hoc for specific use-cases, makingit hard to gain confidence on their correctness and to usethem as building blocks for new systems.

We provide the first systematic exposition of protocols forcross-chain communication. First, we formalize the underly-ing research problem and show cross-chain communication isimpossible without a trusted third party, contrary to commonbeliefs in the blockchain community. We then develop aframework for evaluating existing and designing new cross-chain protocols, based on use case, trust model and securityassumptions of interlinked blockchains. Finally, we identifysecurity and privacy challenges faced by protocols in thecross-chain setting.

This Systematization of Knowledge (SoK) offers a com-prehensive guide for designing protocols bridging the numer-ous distributed ledgers available today and aims to facilitateclearer communication between academia and industry inthis field.

Index Terms—blockchains, distributed ledgers, cross-chaincommunication, interoperability

1. Introduction

Why Cross-Chain Communication is Worthy of Re-search. Since the introduction of Bitcoin [135] as thefirst decentralized ledger currency in 2008, the topic ofblockchains (or distributed ledgers) has evolved into a wellstudied field in both industry and academia. Nevertheless,developments are still largely driven by community effort,resulting in a plethora of blockchain-based digital curren-cies being created. Taking into account the heterogeneous

Contact email: azamyatin@imperial.ac.uk

nature of these systems in terms of design and purpose, itis unlikely that there shall emerge a “coin to rule them all”,yielding interoperability an important research problem.Thereby, cross-chain communication is not only found incurrency transfers and exchanges [18], [19], [89]–[91],but is a critical component of scalabilty solutions (syn-chronization in sharded systems [22], [23], [26], [112],[168]), feature extensions (sidechains [36], [81], [108],[120] and cryptocurrency-backed assets [159], [169]), aswell as bootstrapping of new and migration between exist-ing systems [3], [50], [100], [153]. In addition, numerouscompeting projects aiming to create a single platform forcross-chain communication have recently emerged [20],[93], [116], [152], [160], [161], [163]. However, in spiteof the vast number of use cases and solution attempts,the underlying problem of cross-chain communicationhas neither been clearly defined, nor have the associatedchallenges been studied or related to existing research.Historical Background and Difference to Databases.The need for communication among distributed processesis fundamental to any distributed computing algorithm. Indatabases, to ensure the atomicity of a distributed trans-action, an agreement problem must be solved among theset of participating processes. Referred to as the AtomicCommit problem (AC) [44], it requires the processes toagree on a common outcome for the transaction: commitor abort. If there is a strong requirement that every correctprocess should eventually reach an outcome despite thefailure of other processes, the problem is called Non-Blocking Atomic Commit (NB-AC) [35]. Solving thisproblem enables correct processes to relinquish lockswithout waiting for crashed processes to recover. As such,we can relate the core ideas of communication across dis-tributed ledgers to NB-AC. The key difference hereby lieswithin the security model of the interconnected systems.While in classic distributed databases all processes areexpected to adhere to protocol rules and, in the worstcase, may crash, distributed ledgers, where consensus ismaintained by a committee, must also consider and handleByzantine failures.Contributions. In this work, we provide the first system-atic analysis of communication across distributed ledgers.First, we overview the process of Cross-Chain Commu-nication (CCC) and identify the main designs patters for

protocols in CCC (Section 2). Next, we formalize the un-derlying problem of Correct Cross-Chain Communicationand show it is impossible without a trusted third partyby providing a reduction to the Fair Exchange problem(Section 3). We then introduce a framework to build newand evaluate existing CCC protocols. In particular, wesystematize mechanisms used in committing, aborting andverifying in CCC, and analyze the inherent trust assump-tions thereof (Sections 4- 5). Following this framework,we introduce a classification of CCC protocols proposedin literature (Section 6). Finally, we discuss implicationsfor the blockchain, network, and threat models, and ex-amine transcendence for privacy (Section 7). We overviewrelated work in Section 8 and conclude in Section 9.

2. Overview of Cross-Chain Communication

In this section, we sketch the cross-chain communica-tion (CCC) process and the design rationales of existingprotocols. We defer the formal description of the CCCproblem to Section 3.

2.1. The Cross-Chain Communication Process

The CCC process defines the interaction between twoblockchains X and Y to synchronize transactions, each ofwhich represents the transfer of goods, assets or objects.CCC can be compartmentalized into four phases.Setup. The setup phase is required to establish the pa-rameters for the rest of the CCC process. For example,in the case of an exchange of assets of digital goods,parties agree on the CCC protocol type, asset amount, andany additional conditions. Typically, this process occursout-of-band and we hence shift our focus on the actualexecution of CCC in the rest of this paper.Commit on X . Upon a successful setup, a publiclyverifiable commitment to execute the CCC protocol ispublished on X- typically a transaction being included inthe blockchain. In case of an asset exchange, this couldbe a user locking assets, to be released upon fulfillmentof some conditions (e.g. an event on chain Y ).Verify on Y . In this phase, the correctness of the commit-ment on X is verified on Y , as per the parameters agreedin the setup phase.Commit (or Abort) on Y . If the verification succeeds, acommitment as agreed in the setup phase is published onY . Following our exchange example, this could be a usertriggering the prepared exchange of assets. Alternatively,the CCC can be aborted at this stage. In this case, thecommitment on X can also be reverted, e.g. returninglocked coins to their original owner on X , in our example.

2.2. Protocols for Cross-Chain Communication

We observe two main design patterns for protocols inCCC: (i) protocols which synchronize (atomic) exchangesof digital goods between chain X and chain Y ; and (ii)protocols that solely transfer assets/objects from a chainX to chain Y . An explanatory visualization for bothrationales is provided in Figure 1. In this section, weoverview these two protocol families and defer a system-atic classification of individual protocols to Section 6.

Chain X

1. CommitX

3b. Abort

X'

Chain Y

2. Verify?

3a. CommitY Y(x)

Chain X

1. CommitX

4b. Abort

X'

Chain Y

3. Verify?

2. CommitY4b. Abort

Y'

4a. Exchange

4a. Exchange

Figure 1: Difference between bidirectional exchange (left)and one-way transfer (right) CCC protocols. In exchangeprotocols, two assets/objects x and y are locked (andunlocked atomically if required). In transfers, a represen-tation y(x) of an asset/object x is created on y, after a“write” lock on x was obtained on X .

2.2.1. Bidirectional Exchanges. The family of bidirec-tional exchange protocols, as state in the name, encom-passes those protocols to synchronize an atomic swap oftwo (or more) digital goods (assets or objects): x of chainX and y on Y . In practice, such protocols typically imple-ment some form of a two-phase commit mechanism [18],[91], [108], where the parties can explicitly abort theexchange in case of a disagreement or failure during thecommit step.

Interestingly, bidirectional exchange protocols areblockchain agnostic in that they do not require explicitinvolvement of the consensus participants of interlinkedchains X and Y . That is, the only assumption is thatparticipants of the CCC will be able to include transactionsin the underlying ledgers. Notable examples are atomiccross-chain swaps which use HTLCs [18], [19], [90],[123] or similar symmetric cryptographic locks [46], [73],[124], [134], [140], [157] (cf. Section 4), and centralized,custodial exchange protocols [17], [41], [160].

2.2.2. One-way Transfers. The family of one-waytransfers protocols consists of protocols that move as-sets/objects from one blockchain to another. Typically, thisis achieved by obtaining a “write lock” on an asset/objectx on chain X , i.e., preventing any further updates of x onX , and creating a representation y(x) on Y . Now, the stateof x can only be modified by modifying y(x), comparableto the concept of mutual exclusion in concurrency control[67]. The state changes of y(x) can also be reflected backto X by locking or destroying y(x) and applying theupdates to x when it is unlocked. This is, for example, thecase for cryptocurrency-backed assets [17], [120], [159],[169], where changes in asset ownership executed on theissuing chain Y are propagated to the backing chain X .Although less common than in bidirectional exchanges,one-way transfer protocols may implement an explicitabort procedure, if the creation of y(x) fails.

Contrary to bidirectional exchanges, one-way transferprotocols require explicit involvement of the consensusparticipants of interlinked chains X and Y , specificallyin the verification step. In fact, we can classify one-way transfers into homogeneous and heterogeneous, twosubfamilies defined upon the required blockchain securitymodel.Homogeneous homogeneous one-way transfer protocolsexplicitly make assumptions regarding the threat and net-work models of Y when constructing a communication

protocol from X . In practice, this is the case in shard-ing [23], [25], [112], [168], where every shard is con-sidered to be secure by design [112], [168] leveraging,for example, an appropriate form of randomness [146],[155]. As a result, shards have “uniform” security, i.e.,it is equally difficult for an adversary to compromise anyshard. Following, if one shard is corrupted, the failure typ-ically occurs system wide. This further applies to (child)blockchains which have hierarchical dependency to someparent chain, i.e., the child chain’s security depends on thatof the parent (e.g., merged mining [3], [100], [120], [156]).Since, if the parent fails, so does the child, we are forced toassume the parent’s security holds when communicatingwith it from the child. Note that this relation does notnecessarily hold inversely: by definition, a child can failwithout affecting the parent (contrary to the critical impactof a failing shard) [36], [80].Heterogeneous. In the design of heterogeneous one-waytransfer protocols, interlinked chains cannot be assumedto have identical rule sets/data structures. In practice, itcan be understood that any user can create their ownchain and, in the absence of pre-defined specifications orrules ensuring e.g. sufficient honest participants exist, nogeneric security assumptions can be relied upon. Hence,a chain, even if capable of verifying the consensus rulesof another chain, cannot be sure that the received infor-mation is indeed valid (except if it is fully validated, cf.Section 5.1) [36]. As a result, CCC protocols in the het-erogeneous model typically make additional assumptionsregarding interlinked chains, restricting applicability to asubset of existing systems [108] or introducing additionaleconomic incentives [169].

3. The Cross-Chain Communication Problem

We proceed to formally define the problem of CorrectCross-Chain Communication (CCC) and provide a reduc-tion to the Fair Exchange problem [29], [137], showingthat CCC is impossible without a trusted third party.

3.1. Preliminaries

In literature, the terms blockchain and distributedledger are often used as synonyms. We adopt this nomen-clature as we proceed to introduce some notation, on thebasis of [81] with minor alterations. We refer to [53], [78],[135] for reading on the basics of distributed ledgers.

When speaking of cross-chain communication, weconsider the interaction between two distributed systemsX and Y , which can have distinct consensus participantsand may employ different agreement protocols. Thereby, itis assumed the majority of consensus participants in bothX and Y are honest1. The data structures underlying Xand Y are blockchains (or chains), i.e., append-only se-quences of blocks, where each block contains a referenceto its predecessor(s), e.g. via a hash.Ledgers and State Evolution. We denote a ledger asL (Lx and Ly respectively) and define its state as thedynamically evolving sequence of included transactions〈TX1, ..., TXn〉. We assume that the evolution of the ledger

1. Or, in the case of Proof-of-Work blockchains such as Bitcoin, themajority of computational power [135]

state progresses in discrete slots s, indexed2 by a naturalnumber i ∈ N. At each slot i, a new set of transactions(included in a newly generated block) is written to theledger L. We use L[i] to denote the state of ledger L atslot i, i.e., after applying all transactions written to theledger since slot i− 1. A transaction can be written to Lonly if it is consistent with the system’s consensus rules,given the current ledger state L[i]. This consistency is leftfor the particular system to define, and we describe it as afree predicate valid(·). In practice, the ordering at whichtransactions are included in the ledger is crucial for theirvalidity, i.e., TXj at position j can conflict with TXl atposition l (e.g. a double-spend). Depending on whetherj > l, either TXj or TXl is valid and can be included in L,but not both. For simplicity, we assume correct orderingimplicitly, and write valid(TX, Lx[i]) (instead of explicitlyspecifying the transaction index as valid(TX, Lx[i][j])).Global Clock. The state evolution of two distinct ledgersLx and Ly may progress at different time intervals: Inthe time that Lx progresses one sx slot, Ly may, forexample, progress forty sy slots (on average, as in thecase of Bitcoin [135] and Ethereum [56]). To capture theorder of transactions when synchronizing across Lx andLy, we introduce a clock function τ which maps a givenslot on any ledger to the time on a global, synchronizedclock τ : s → t. For simplicity and readability, we usethis conversion implicitly, i.e., given τ(i) = t we writeL[t] = L[i] instead of L[t] = L[τ(i)].Persistence and Liveness. Each participant P adopts andmaintains a local ledger state LP [t] at time t (LPx [t] andLPy [t] respectively), i.e., her current view of the ledger.The views of two distinct participants P and Q on thesame ledger L may differ at time t (e.g., due to networkdelay or message loss): LP [t] = L[i], LQ[t] = L[i − 1],LP [t] 6= LQ[t]. However, eventually, all honest partiesin the ledger will have the same view. This is capturedby the persistence and liveness properties of distributedledgers [78]:

Definition 1 (Liveness). Consider an honest party P of aledger L and a liveness delay parameter u. If P attemptsto write a transaction TX to its ledger at time t ∈ N, thenTX will appear in its ledger at time t′, i.e., ∃t′ ∈ N : t′ ≥t∧TX ∈ LP [t′]. Additionally, we require the interval t′−tto be upper bound by u.

Definition 2 (Persistence). Consider two honest partiesP,Q of a ledger L and a persistence delay parameter k.If a transaction TX appears in the ledger of party P attime t, then it will eventually appear in the ledger of partyQ at a time t′ > t. Concretely, for all honest parties Pand Q, we have that ∀t ∈ N : ∃t′ ≥ t : LQ[t′] = LP [t].Additionally, we require that the interval t′ − t is upperbound by k.

(Smart) Contracts and State Manipulation. A trans-action TX, when included, alters the state of a ledger Lby defining operations to be executed and agreed uponby consensus participants P1, ..., Pn. The expressivenessof operations is thereby left for the particular system todefine, and can range from mere hash functions [52] to(near) Turing complete programming languages [164].

2. In practice often referred to as the blockchain height.

Assets/Objects. We denote assets/objects on ledgers Lxand Ly as x and y, respectively. Both assets and objectscan have a state, which is encoded as part of the stateof the underlying ledger L, i.e., in the evolving set ofincluded transactions associated with the asset/object (forexample, ownership).Full nodes and Light Clients. We differentiate betweentwo types of nodes in the networks: (i) those that store theentire transaction history and validate the full ledger state(full nodes), (ii) and those that only store transactions rel-evant to them and verify their inclusion in the underlyingledger, but do not check their validity (light clients).

3.2. Model and Specification

Model. Consider two independent distributed systems Xand Y with underlying ledgers Lx and Ly, as defined inSection 3.1. We assume a closed system model as in [118]with a process P running on X and a process Q runningon Y . The only way a process can influence the stateevolution of the underlying system is by (i) writing atransaction TX to the underlying ledger L (commit), or(ii) by completely stopping to interact with the system(abort). We assume that P possesses transaction TXP ,which can be written to Lx, and Q possesses TXQ, whichcan be written to Ly. A function desc maps a transactionto some “description” which can be compared to an ex-pected description value (e.g. specifying the transactionvalue). Both processes posses descriptions dP and dQof the transactions TXP and TXQ they expect from theircounterparty. Note: dP = desc(TXP ) implies TXP is validin X (at time of synchronization), as it cannot be writtento Lx otherwise (analogous for dQ).

We assume P and Q know each other’s identity andno (trusted) third party is involved in the communicationbetween the two processes. Further, we assume no boundson message delay or deviations between local clocksand treat failure to communicate as adversarial behavior.Hence, if P or Q become malicious, we indicate this usingboolean “error variables” [79] mP and mQ.Specification. The goal of cross-chain communication canbe described as the synchronization of processes P and Qsuch that Q writes TXQ to Ly if and only if P has writtenTXP to Lx. Thereby, it must hold that desc(TXP ) = dQ∧desc(TXQ) = dP . The intuition is that TXP and TXQ aretwo transactions which must either both, or neither, beincluded in Lx and Ly, respectively. For example, they canconstitute an exchange of assets which must be completedatomically. A visual representation is provided in Figure 2.

To this end, P must convince Q that it created atransaction TXP which was included in Lx. Specifically,process Q must verify that at given time t the ledgerstate Lx[t] contains TXP . A cross-chain communicationprotocol which achieves this goal, i.e., is correct, musthence exhibit the following properties:

Definition 3 (Effectiveness). If both P and Q behave cor-rectly and TXP and TXQ match the expected descriptions(and are hence valid), then TXP will be included in Lx andTXQ will be included in Ly. If either of the transactions

are not as expected, then both parties abort.

(desc(TXP ) = dQ ∧ desc(TXQ) = dP ∧mP = mQ = ⊥=⇒ TXP ∈ Lx ∧ TXQ ∈ Ly)

∧ (desc(TXP ) 6= dQ ∨ desc(TXQ) 6= dP

=⇒ TXP /∈ Lx ∧ TXQ /∈ Ly)

Definition 4 (Atomicity). There are no outcomes in whichP writes TXP to Lx but Q does not write TXQ, or Q writesTXQ to Ly but P did not write TXP to Lx.

¬((TXP ∈ Lx ∧ TXQ /∈ Ly) ∨ (TXP /∈ Lx ∧ TXQ ∈ Ly))

Definition 5 (Timeliness). Eventually, a process that be-haves correctly will write a transaction TX to its ledgerL.

From Persistence and Liveness of L, it follows that even-tually P writes TXP to Lx and Q becomes aware of andverifies TXP .

Definition 6 (Correct Cross-Chain Communication(CCC)). Consider two systems X and Y with ledgersLx and Ly, each of which has Persistence and Liveness.Consider two processes, P on X and Q on Y , with to-be-synchronized transactions TXP and TXQ. Then a correctcross-chain communication protocol is a protocol whichachieves TXP ∈ Lx ∧ TXQ ∈ Ly and has Effectiveness,Atomicity, and Timeliness.

Summarizing, Effectiveness and Atomicity are safetyproperties. Effectiveness determines the outcome if trans-actions are not as expected or both transaction matchdescriptions and both processes are behaving correctly.Atomicity globally restricts the outcome to exclude behav-iors which place a disadvantage on either process. Timeli-ness guarantees eventual termination of the protocol, i.e.,is a liveness property.

3.3. Correct Cross-Chain Communication is asHard as Fair Exchange

We proceed to show that Correct Cross-Chain Com-munication is as hard as Fair Exchange, and hence im-possible without a trusted third party.Fair Exchange. The fair exchange of digital goods is awell-studied problem in computer science. On a high level,an exchange between two (or more) parties is consideredfair if either both parties receive the item they expect, orneither do [30]. Fair exchange can be considered a sub-problem of fair secure computation [42], and is known tobe impossible without a trusted third party [137], [165].Relating CCC to Fair Exchange. We proceed to showthat Correct Cross-Chain Communication is impossiblewithout a trusted third party (TTP) by reducing it to FairExchange [29], [30], [137].

Lemma 1. Let C be a protocol which solves CCC in thegiven system model. Then there exists a protocol S whichsolves Fair Exchange in the same system model.

Proof. Consider that the two processes P and Q areparties in a fair exchange. Specifically, P owns an itemiP and wishes to exchange it against an item iQ ownedby Q. Assume TXP assigns ownership of iP to Q andTXQ ownership of iQ to P (“descriptions” of TXP and

Figure 2: Simplified visualization of CCC between X and Y . Process Q writes TXQ only if P has written TXP . Weuse kX and kY to denote exemplary persistence delays of X and Y (kX = 3, kY = 4), and set ux = uy = 0 for theliveness delays for the sake of simplicity.

TXQ). Then, TXP must be included in Lx and TXQ in Lyto finalize the exchange. In other words, if TXQ ∈ Ly andTXP ∈ Lx, then P receives desired iQ and Q receivesdesired iP , i.e., P and Q fairly exchange iP and iQ.

A fair exchange protocol must fulfill three proper-ties: Effectiveness, (Strong) Fairness and Timeliness [29],[137]. It is easy to see the Timeliness property of CCCis equivalent to Timeliness of fair exchange as definedin [137]. Effectiveness in fair exchange states that if Pand Q behave correctly and do not want to abandon theexchange, and items iP and iQ are as expected by Q andP , then at the end of the protocol, P will have the desirediQ and Q will have the desired iP [137]. It is easy tosee Effectiveness in CCC achieves exactly this property:if P and Q behave correctly and the transaction matchthe respective descriptions (i.e., assign iP to Q and iQ toP ), then P will write TXP to Ly and Q will write TXQto Lx, resulting in P receiving iQ and Q receiving iP .From Persistence and Liveness of Lx and Ly we know bothtransactions will eventually be written to the local ledgersof P and Q, and consequently appear in the local ledgersof all other participants of X and Y . Strong Fairness in fairexchange states that there is no outcome of the protocol,where P owns iQ but Q does not own iP , or Q ownsiP but P does not own iQ [137]. In our setting, such anoutcome is only possible if TXP ∈ Lx ∧ TXQ /∈ Ly orTXP /∈ Lx ∧ TXQ ∈ Ly, which contradicts the Atomicityproperty of CCC.

We assume the same asynchronous (explicitly) and de-terministic (implicitly) system model (cf. Section 3.2)as [76], [137]. Since P and Q can simply stop partici-pating in the CCC protocol, we also have the same crashfailure model as [76], [137]. Hence, we conclude:

Theorem 1. There exists no asynchronous CCC protocoltolerant against misbehaving nodes.

Proof. Assume there exists a asynchronous protocol Cwhich solves CCC. Then, due to Lemma 1 there exists aprotocol which solves strong fair exchange. As this is acontradiction, there cannot exist such a protocol C.

Our result currently holds for the closed model, as in [76],[137]. In the open model, P and Q can be forced tomake a decision by the system, i.e., transactions can

be written on their behalf if they crash [112]. This canbe achieved by leveraging smart contracts, similar toblockchain-based fair exchange protocols, e.g. [71]. Assuch, we can construct a smart contract on Y which willinclude TXQ in Ly as soon as P includes TXP in Lx, i.e., Qis allowed to crash. A contract, however, can only performactions based on some prior input. Specifically, beforewriting TXQ the contract must receive proof that TXPwas included in Lx. A protocol achieving CCC must henceassume (i) P (or Q) will always submit a proof showingTXP ∈ Lx, i.e., introduce some form of synchrony as-sumptions, or (ii) resort to a TTP. We argue introducing aTTP is equivalent to introducing synchrony assumptions,as discussed in [137], and derive the following corollary:

Corollary 1. There exists no CCC protocol tolerantagainst misbehaving nodes without a trusted third party.

Proof. A trusted third party is equivalent to introducingsome form of synchrony. As such, if there is no trustedthird party, then the protocol is asynchronous. Theorem 1now proves Corollary 1.

The intuition behind this result is as follows.If we assume that process P does not crash and hence

submits the necessary proof the the smart contract on Y ,and that this message is delivered to the smart contractwithin a know upper bound, then we can be sure that CCCwill occur correctly. Thereby, P represents its own trustedthird party. However, if we cannot make assumptions onwhen the message will be delivered to the smart contract,a trusted third party is necessary to determine the outcomeof the CCC: the TTP observes TXP ∈ Lx and informs thesmart contract or directly enforces the inclusion of TXQin Ly. Thereby, we observe similarities to the concept offailure detectors [63], a construction used to introduce animplicit notion of time into distributed systems to solveconsensus. In the context of fair exchange, and henceCCC, a failure detector, which can also be considered a(trusted) third party to the protocol, indicates whether aparticipate has failed or misbehaved.

3.4. What is a Trusted Third Party?

Numerous recent works use a single distributed ledgersuch as Bitcoin and Ethereum to construct (optimistic)

fair exchange protocols [27], [42], [71], [107], [111],[114]. They leverage smart contracts (i.e., programs orscripts), the result of which is agreed upon and enforcedby consensus participants, to ensure the correctness of theexchange. These protocols thus use the consensus of thedistributed ledgers as an abstraction for a trusted thirdparty. As long as the majority of consensus participants arehonest, correct behavior of processes/participants of thefair exchange is enforced – typically, the correct releaseof iQ to P if Q received iP .

A CCC protocol aims to achieve synchronization be-tween two such distributed ledgers, both of which areinherently trusted to operate correctly. Here, a (possiblyadditional) TTP can be used to (i) confirm to the consensusparticipants of Y that TXP was included in Lx, who in turnenforce the inclusion of TXQ in Ly; or (ii) directly enforcecorrect behavior of Q, such that TXQ ∈ Ly.

Similar to the abstraction of TTPs used in fair ex-change protocols, in CCC it does not matter how exactlythe TTP is implemented, as long as it can enforce correctbehavior of the participants. In more detail, from theperspective of CCC there is little difference between aTTP consisting of a single individual and a committeewhere N out of M members must agree to take action(even though the latter is, without question, more resilientagainst failures).

3.5. Incentives and Economically Trustless CCC

Several workarounds have been proposed in literatureto counter the fair exchange problem. Most prominent al-ternatives include gradual release mechanisms, optimisticmodels, and partially fair secure computation [30], [42],[60], [115]. These workarounds suffer, among others, froma common drawback: they require a trusted party thatdoes not collude with the adversary. Further, when anadversary aborts, the honest parties have to spend extraefforts to restore fairness, e.g., the trusted server in theoptimistic model needs to be contacted each time fairnessis breached. The economic dimension of blockchains en-abled a shift in this paradigm: Rather than forcing an hon-est user to invest time and money to achieve fairness, themalicious user is economically punished when breachingfairness. This has paved the way to design economicallytrustless CCC protocols that follow a game theoretic modelunder the assumption that actors behave rationally [169].We remark nevertheless that such assumption only holdif incentives are aligned and players are economicallyrational. Malicious/altruistic actors can still breach CCCproperties (e.g., even if there is no economic damage, thecorrect execution of the communication itself still fails).

4. Commit and Abort in CCC

We now overview techniques for implementing thedifferent phases of CCC protocols, discussing ways ofimplementing the necessary TTP.

The commit and abort steps, as described in Section 2,go hand by hand in the CCC process. Intuitively, thecommit step is crucial to freeze an asset x in chain Xand provide a time window to be verified by participantsat Y according to the agreement reached at the setup.This time window must be, however, limited to ensure

that x can be further used by the original owner if theCCC ends in unsuccessful exchange or transfer of assets.The abort step is thus crucial to limit the aforementionedtime window.

4.1. Commit Phase

First, we discuss the different techniques to handlethe commit phase of CCC protocols. We vertebrate thisdiscussion on the assumption upon which the commitphase is designed: (i) relying on a TTP; (ii) relying onCCC participants and assuming synchronous communica-tion among them; and (iii) combinations thereof.

4.1.1. Trusted Third Party (Coordinators). A coor-dinator (also referred to as vault [169]) is a TTP thatassists other protocol participants in achieving agreementto either commit or abort the cross-chain transfer.

We can describe the coordinator types attending to twocriteria: custody of assets and involvement in blockchainconsensus. We first introduce both classification criteriaand then detail our classification of coordinators.Custody of Assets. Custody refers to where the controlover assets of (honest) participants resides and we candifferentiate between custodians and escrows.• Custodians receive unconditional control over the par-

ticipant’s funds and are thus trusted to release them asinstructed by the protocol rules. It is possible to mitigatethis trust assumption by introducing collateral (i.e., adeposit of coins from the custodian) and penalties if thecustodian misbehaves [86], [87], [158], [159], [169].

• Escrows receive control over the participant’s fundsconditional to certain prearranged constraints being ful-filled. The release of the assets depend thus on that theunderlying chain correctly verifies the fulfillment forthe condition whereas the Escrow can only fail to takeaction (e.g., crash). Moreover, from the game theoreticperspective, Escrows are expected to lose utility frommisbehaving and are hence often referred to as “un-trusted” third parties in the blockchain community.

Involvement in Blockchain Consensus. Coordinators canoptionally also take part in the blockchain consensusprotocol. We hence differentiate between consensus-leveland external coordinators.• Consensus-level coordinators refer to, as the name

states, TTPs that are additionally consensus participantsof the underlying chain. This is the case, for example, ifthe commit step is performed on chain X and enforceddirectly by the consensus participants of X , e.g. througha smart contract or directly a multi-/threshold signature.

• External coordinators, on the other hand, refer to TTPswhich are not represented by the consensus participantsof the underlying blockchain. This is the case if (i)the coordinators are external to the chain X , e.g, theconsensus participants of chain Y or other parties, or(ii) less than the majority of consensus participants ofchain X are involved.

Overview of Coordinator Types. We now proceed todetail the different coordinator types according to theaforementioned criteria and how they are implemented inpractice.

• External Custodians (Committees). In practice, in-stead of relying on the availability and honest behav-ior of a single external coordinator, trust assumptionscan also be distributed among a set of N committeemembers. Decisions require the acknowledgment (e.g.digital signature) of at least M ≤ N members, wherebyconsensus can be achieved via Byzantine Fault Tolerant(BFT) agreement protocols such as PBFT [61]. Animportant distinction to make here is between static,i.e., unchanged over time (usually permissioned), anddynamic committees, where a pre-defined mechanismis responsible for member election. The latter is awell studied problem, e.g. in Proof-of-Work [66], [109],[110], [139] and Proof-of-Stake [43], [65], [106], [131]blockchains. Practical examples for such CCC protocolsrelying on committees include [13], [68], [112].

• Consensus-level Custodian (Consensus Committee)Consensus-level custodians are identical to externalcustodians, except that they are also responsible foragreeing on the state of the underlying ledger. Often,this technique is used if the blockchain on which thecommit step is executed runs a BFT consensus protocoland there hence already exists a static committee ofconsensus participants. The later can be reused as theTTP in CCC: the trust in the honest behavior of thecommittee implicitly stems from the assumption that theunderlying ledger operates correctly. Examples includesharded blockchains, such as [23], [112], [116], [163].

• External Escrows (Multisignature Contracts). Exter-nal Escrows can be seen as a special case of commit-tees (i.e., External Custodians) where the coordinatoris transformed from Custodian to Escrow by meansof a multisignature contract. Multisignature contractsrequire the signature of the participant P (i.e., the assetowner) in addition to those of the (subset of) committeemembers, i.e., P+M,M ≤ N . The committee can thusonly execute actions pre-authorized by the participantand can at most freeze assets, but not commit theft.

• Consensus-level Escrow (Smart Contracts) are pro-grams stored in a ledger which are executed and theirresult agreed upon by consensus participants [56], [59].As such, trusting in the correct behavior of a smartcontract is essentially trusting in the secure operation ofthe underlying chain, making this a useful constructionfor Escrows. Depending on the system properties, smartcontracts can be (near) Turing complete [56], or limitedto a subset of operations [135], [148]. In addition, smartcontracts can be used to collateralize CCC participants,penalize misbehavior [86], [87], [158] or pay premiumfor correct participation [85] – even if the participantsare located on alternate chains, potentially without sup-port for smart contracts themselves [169].

4.1.2. Synchrony Assumptions (Lock Contracts).An alternative to coordinators consists in relying onsynchronous communication between participants andleveraging locking mechaniusms which stemm securityfrom cryptographic hardness assumptions. Observationsin practice show these techniques are typically used inbidirectional exchange CCC protocols implementing two-phase commit, where the same (symmetric) locks are cre-ated on both chains and released atomically. We providean overview, differentiating between the cryptographic

primitives relied upon.• Hash Locks. A protocol based on hash locks relies

on the preimage resistance property of hash functions:participants P and Q transfer assets to each other bymeans of transactions that must be complemented withthe preimage of a hash h := H(r) for a value r chosenby P – the initiator of the protocol – typically uniformlyat random [18], [19], [90], [123].

• Signature-based Locks. Protocols based on hash lockshave limited interoperability as they require that bothcryptocurrencies support the same hash function withintheir script language. Unfortunately, this assumptiondoes not hold in practice (e.g., Monero does not evensupport a script language). Instead, P and Q can transferassets to each other by means of transactions that re-quire to solve the discrete logarithm problem of a valueY := gy for a value y chosen uniformly at random byP (i.e., the initiator of the protocol). In practice, it hasbeen shown that it is possible to embed the discretelogarithm problem in the creation of a digital signature,a cryptography functionality used for authorization ismost blockchains today [46], [48], [73], [124], [134],[140], [157].

• Timelock Puzzles and Verifiable Delay Functions.An alternative approach is to construct (cryptographic)challenges, the solution of which will be made publicat a predictable time in the future. Thus, P and Qcan commit to the cross-chain transfer conditioned onsolving one of the aforementioned challenges. Concreteconstructions include timelock puzzles and verifiabledelay functions. Timelock puzzles [142] build uponinherently sequential functions where the result is onlyrevealed after a predefined number of operations areperformed. Verifiable delay functions [46] improve upontimelock puzzles on that the correctness of the result forthe challenge is publicly verifiable. This functionalitycan also be simulated by releasing parts of the preimageof a hash lock interactively bit by bit, until it can bebrute forced [41].

4.1.3. Hybrid (Watchtowers). Instead of fully relyingon coordinators being available or synchrony assumptionsamong participants holding, it is possible to it is possibleto employ so called watchtowers, i.e., trusted third parties/ service providers which act as a fallback if CCC partici-pants experience crash failures. Specifically, watchtowerstake action to enforce the commitment, if one of theparties crashes or synchrony assumptions do not hold, i.e.,after a pre-defined timeout [32], [34], [103], [125]. Thisconstruction was first introduced and applied to off-chainpayment channels [84].

4.2. Abort Phase

We now discuss different techniques to handle theabort phase of CCC protocols. We organize our discussionbased on the same assumptions upon which the commitphase is designed: (i) relying on a TTP; (ii) relying onCCC participants and assuming synchronous communica-tion among them; and (iii) combinations thereof.

4.2.1. Trusted Third Party (Coordinators). Similarly tothe commit phase, an abort can be handled by a trusted

third party. Thereby, the TTP must be the same TTPwhich executed the commit step of the CCC protocol - assuch, the possible techniques are the same as described inSection 4.1.1.

4.2.2. Synchrony Assumptions (Timelocks). Alterna-tively, it is possible to enforce synchrony by introduc-ing timelocks, after the expiry of which the protocol isaborted. Specifically, to ensure that assets are not lockedup indefinitely in case of a crash failure of a participant ormisbehavior of a TTP entrusted with the commit step, allcommit techniques can be complimented with timelocks:after expiry of the timelock, assets are returned to theiroriginal owner. Thereby, we differentiate between twotypes of timelocks:• Absolute timelocks, where a transaction becomes valid

only after a certain point in time, defined in by atimestamp or a block (ledger at index i, L[i]) locatedin the future.

• Relative timelocks, where a transaction TX2 becomesvalid only after a given time value or number of confir-mations [5] have elapsed since the inclusion of anothertransaction TX1 in the underlying ledger. For example,assuming transaction TX1 was included in L[i], thenrelatively timelocked TX2 becomes valid when the chainreaches ledger state L[j] where j = i+c, with c denotingthe number of required confirmations (i, j, c ∈ N).Typically, TX1 and TX2 are related as TX2 spends assetstransferred in TX1 [141]. While more practical thanabsolute timelocks (no need for external clock), as ofthis writing, we are not aware of schemes allowing thecreation of relative timelocks across ledgers.

4.2.3. Hybrid (Watchtowers). After expiry of a time-lock, the CCC protocol is aborted. However, participantstypically must be online to regain control over the assetslocked as part of the CCC commit phase. In most cases,one-way transfer CCC protocols do not introduce an upperbound on the delay until funds must be recovered fromthe commit (lock) is introduced. However, in bidirectionalexchange protocols, where timelocks are often used toprevent both parties’ funds from being frozen indefinitely,a timely recover may be necessary. Thereby, participantsmust come online within some pre-defined period or en-trust a trusted third party, e.g. a watchtower [32], [34],[103], [125], with the recovery of the locked assets. Thiscan be the case in HTLC atomic swaps [2], [19], [90],[141], when either party crashes after the secret used inthe hash lock has been revealed.

5. Cross-Chain State Verification

A critical component of cross-chain communication isthe verification of the state evolution of a chain X fromwithin another chain Y , i.e., that X is in a certain stateafter the commit step. We present a classification based onthe scope of the verification process, i.e., differentiatingbetween what is being verified (Section 5.1) and dis-cuss the relation between these verification classes (Sec-tion 5.2). We then overview implementation techniquesfor cross-chain state verification, differentiating, as inprevious sections, between (i) using a TTP, (ii) relying on

verification by participants, (iii) and combinations thereof(Section 5.3).

5.1. Verification Classes

If a party P on X is misbehaving, it may withholdinformation from a party Q on Y (i.e., not submit a proof),but it should not be able to trick Q into accepting anincorrect state of Lx (e.g., convince Q that TX1 ∈ Lxalthough TX1 was never written).Verification of State. The simplest form of cross-chainverification is to check whether a specific state exists, i.e.,is reachable but has not necessarily been agreed upon bythe consensus participants. A representative example is theverification of Proof-of-Work in merged mining [3], [100]:the child chain Y only parses a given X block and verifiesthat the hash of the Y candidate block was included, andchecks that the PoW hash exceeds the difficulty target ofY . Note that Y does not care whether the block is actuallypart of Lx. Another example is the use of blockchains asa public source of randomness [51], [55], [64], [70].Verification of State Agreement. In addition to the ex-istence of a state, a proof can provide sufficient data toverify that consensus has been achieved on that state. Typ-ically, the functionality of this verification is identical tothat of blockchain light clients [1], [11], [135]: instead ofverifying the entire blockchain of X , all block headers andonly transactions relevant to the CCC protocol are verified(and stored) on Y . The assumption thereby is that an in-valid block will not be included in the verified blockchainunder correct operation [122], [135]. Block headers canbe understood as the meta-data for the block, includinga commitment to all the transactions in the block, whichare typically referenced using a vector commitment [62](or some other form of cryptographic accumulator [39]),e.g. Merkle trees [129]. We discuss how proofs of stateagreement differ depending on the underlying consensusmechanism below (non-exhaustive):• Proof-of-Work. To verify agreement in PoW

blockchains, a primitive called (Non-interactive)Proofs of Proof-of-Work [104], [105], also referredto as SPV (simplified payment verification) [135] isused. Thereby, the verifier of a proof must at leastcheck for each block that (i) the PoW meets thespecified difficulty target, (ii) the specified target isin accordance with the difficulty adjustment and (iii)the block contains a reference to the previous block inthe chain [1], [169]. The first known implementationof cross-chain state agreement verification (for PoWblockchains) is BTCRelay [4]: a smart contract whichallows to verify the state of Bitcoin on Ethereum3.

• Proof-of-Stake. If the verified chain uses Proof-of-Stake in its consensus, the proofs represent a dynamiccollection of signatures, capturing the underlying stakepresent in the chain. These are referred to as Proofs ofProof-of-Stake (PoPoS) and a scheme in this directionwas put forth in [81].

• BFT. In case the blockchain is maintained by a BFTcommittee, the cross-chain proofs are simplified andtake the form of a sequence of signatures by 2f + 1

3. Similar contracts have consequently been proposed for other chains[6], [7], [10], [12], [14], [15].

members of the committee, where f is the number offaulty nodes that can be tolerated [61]. If the committeemembership is dynamically changing, the verificationprocess needs to capture the rotating configuration ofthe committee, which can incur significant cost forparties that rarely synchronize.

Sub-linear State Agreement Proofs. Verifying all blockheaders results in proof complexity linear in the sizeof the blockchain. However, there exist techniques forachieving sub-linear (logarithmic in the size of the chain)complexity, which rely on probabilistic verification. ForPoW blockchains, we are aware of two approaches: Su-perblock (Ni)PoPoWs [36], [104], [105], [132] and Fly-Client [122]. Both techniques rely on probabilistic sam-pling but differ in the selection heuristic. Superblock(Ni)PoPoWs sample blocks which exceed the requiredPoW difficulty4, i.e., randomness is sourced from theunpredictability of the mining process, whereas FlyClientsuggests to sample blocks using an optimized heuristicafter the chain has been generated (using randomnessfrom the PoW hashes [51]). Such probabilistic samplingtechniques may be potentially applicable to Proof-of-Stakeblockchains [122], however, to the best of our knowledge,no concrete schemes have been put forth at the time ofwriting. For blockchains maintained by a static BFT com-mittee, the verified signatures can be combined into ag-gregate signatures [109], [110] for optimization purposes.These signature techniques are well known and havebeen invented prior to blockchains, and we hence do notelaborate further on these schemes. In the dynamic setting,skipchains [77], [113], [136], i.e., double-linked skiplistswhich enable sub-linear crawling of identity chains, canreduce costs from linear to logarithmic (to the number ofconfigurations).Verification of State Evolution. Once verified by somechain Y that chain X has reached agreement on a ledgerstate Lx[i], it is then possible for (users on) Y to verifythat certain transactions have been included in Lx (andhence taken place on X). As mentioned, block headerstypically reference included transactions via vector com-mitments. As such, to verify that TX ∈ Lx[i] the vectorcommitment on Lx[i] needs to be opened at the index ofthat transaction, e.g. by providing a Merkle tree path tothe leaf containing TX (e.g. as in Bitcoin).Verification of State Validity. Even though a block isbelieved to have consensus, it may not be a valid blockif it contains invalid transactions or state transitions (e.g.a PoW block meeting the difficulty requirements, butcontaining conflicting transactions). Fully validating nodeswill reject these blocks as they check all included transac-tions. However, in the case of cross-chain communication,where chains typically only verify state agreement but notvalidity, detection is not directly possible. We classify twocategories of techniques to enable such chains, and non-full nodes (i.e., light clients), to reject invalid blocks:• In proactive state validation, nodes ensure that blocks

are valid before accepting them. Apart from requir-ing participants to run fully validating nodes, this canbe achieved by leveraging “validity proofs” throughsuccinct proofs of knowledge, using systems such as

4. It is a property of the PoW mining process that a certain percentageof blocks exceeds or fall short of the required difficulty.

SNARKs [45], STARKs [37] or Bulletproofs [54]. Firstschemes for blockchains offering such proofs for eachstate transition are put forth in [38], [47], [128]. Infor-mally speaking, this is a “guilty until proven innocentmodel”: nodes assume blocks that have consensus areinvalid until proven otherwise.

• In reactive state validation, nodes follow an “innocentuntil proven guilty” model. It is assumed that blocksthat have consensus only contain valid state transition,unless a state transition “fraud proof” [24] is created.Fraud proofs typically are proofs of state evolution, i.e.,opening of the transaction vector commitment in theinvalid block at the index of the invalid transaction,e.g. via Merkle tree paths. Depending on the observedfailure, more data may be necessary to determine in-consistencies (e.g. Merkle tree paths for conflictingtransactions in case of a double spend).

Verification of Data Availability. Consensus participantsmay produce a block header, but not release the includedtransactions, preventing other participants from validatingthe correctness of the state transition. To this end, verifica-tion of state validity can be complimented by verificationof data availability. A scheme for such proofs was putforth in [24] and extended in [167], which allows to verifywith high probability that all of the data in a block isavailable, by sampling chunks in an erasure-coded versionof a block.

5.2. Relation between Verification Classes

Verification of State Agreement requires to first verifya specific state exists or has been proposed (Verification ofState). To verify a transaction was included at L[i] (StateEvolution), it is first necessary to verify that the ledgerstate at L [i] is indeed agreed upon (State Agreement).Finally, to verify that a the state (transition) is indeed valid(State Validity), one must first verify that all associatedtransactions were indeed included in the ledger (StateEvolution). Verification of Data Availability serves ascomplimentary security measure, and can be added to anyof the classes to protect against data withholding attacks.We illustrate this relationship in Figure 3.

Figure 3: Venn diagram visualizing the relation of cross-chain state verification classes. The red dotted line high-lights the minimum requirement for correctly operatinglight clients, i.e., verifying SPV / NiPoPoWs in the caseof PoW blockchains.

5.3. Implementation Techniques

We discuss implementations of cross-chain verifica-tion, differentiated by whether they rely on synchronyassumptions, a TTP, or a combination thereof (hybrid).

• Synchrony Assumption (Direct Observation). Thesimplest approach to cross-chain verification is to re-quire all participants of a CCC protocol to run (fullyvalidating) nodes in all involved chains. This is oftenthe case in exchange protocols, such as atomic swapsusing symmetric locks such as HTLCs [19], [90], butalso in parent-child settings where one chain by designverifies or validates the other [36], [81], [120]. Thisrelies on a synchrony assumption that requires the CCCparticipants to observe and act upon the state evolutionof chains within a certain time, in order to complete theCCC.

• Trusted Third Party (Coordinators). Similar to thecommit and abort phases of CCC, the verification of thestate of interlinked chains can be handled by a trustedthird party (also referred to as validator [163]). Thereby,we differentiate between the following techniques:– External Validators. A simple approach is to out-

source the verification step of CCC to a (trusted) thirdparty, external to the verifying ledger (in our case Y ),as in [17], [160]. The TTP can thereby be the sameas in the commit / abort steps.

– Consensus Committee / (Smart) Contracts. Alter-natively, the verification can be handled by the con-sensus participants of the verifying chain [68], [112],[119] – leveraging the assumption that misbehavior ofconsensus participants indicates a failure of the chainitself. The verification process can be further encodedin smart contracts, as in the case of BTCRelay [4],which verifies Bitcoin block headers. Thereby, smartcontracts have recently been used to verify succinctproofs of knowledge [72], [171], which in turn can(theoretically) enable proactive verification of StateValidity in CCC protocols.

– Verification Games. Finally, rather than fully trust-ing coordinators, they can be used as a mere opti-mistic performance improvement by introducing dis-pute handling mechanisms to the verification process:users can provide (reactive) fraud proofs [24] oraccuse coordinators of misbehavior requiring themto prove correct operation [86], [101], [158].

• Hybrid (Watchtowers). Synchrony and TTP assump-tions can be combined, such that a CCC protocol worksif at least either a synchrony or TTP assumption holds.For example, in case one of the parties in the CCC goesoffline, TTPs in the form of watchtowers, that take overthe role of the offline party can be relied upon. SeeSection 4.1.3.

6. Evaluation of CCC Protocols

In this section, we evaluate existing CCC protocolsbased on the introduced classifications. We present ourresults in Table 1. We note that we performed this evalua-tion to the best of our knowledge, but are not able to coverall existing projects released in the blockchain community.As such, our focus lies on published academic papers andon community-driven projects deployed to practice.Methodology. We group protocols by their design ratio-nale, i.e., bidirectional exchanges and one-way transfers.For the latter we split protocols according to the under-lying blockchain security assumptions: homogeneous and

heterogeneous. The main focus of the evaluation lies onhow each protocol handles the impossibility result fromSection 3 during each phase of the CCC process: Commiton X , verify and commit on Y , and, if implemented, aborton X in case of failure. We further evaluate the restrictionsof becoming a trusted third party / intermediary in eachprotocol, i.e., whether the TTP selection is dynamic orstatic (pre-defined). We also consider collateralization ofTTPs in protocols where participants are reimbursed incase of failure, to minimize financial damages faced.

6.1. Bidirectional Exchange Protocols

Exchange protocols are generally agnostic to the secu-rity assumptions made for the interlinked blockchains, asthe default application is the exchange of assets betweendistinct ledgers.

We observe multiple techniques, with different under-lying trust models, the simplest and currently most usedbeing custodial (centralized) exchanges. Recent works,such as Tesseract [41], attempt to reduce the risk of theftby the custodian by leveraging trusted hardware, e.g. IntelSGX [94]. The long standing alternative to entrusting acustodian with to-be-exchanged funds are atomic swaps,first introduced in 2012 using hashed-timelock contractsfor commit and abort phases [18], [19], and recentlyformalized in [90]. Hashlocks can thereby be replacedwith signature locks [124], improving privacy and cross-platform support. As of today, the adoption of HTLCatomic swaps is scarce, which can be explained by thestrict online requirements for participants: the initiator ofthe swap can steal funds of the receiving party, if the laterdoes not claim the initiator’s committed assets before theabort timelock expires (after the secret to the hashlock wasreleased). Notarized atomic swaps [160] remove the onlinerequirement for users, by entrusting a set of coordinators(notaries) with the verification (and timely reaction) to therelease of the HTLC secret - however, introducing the riskof coordinators colluding with exchange counterparties tocommit theft.

An alternative to interactive swaps via HTLCs orsignature locks are SPV atomic swaps [18], [19], [90],[160]. Hereby, the initiator of the swap locks assets yin a smart contract on Y , which will release the later toanyone who can prove correct payment of x on X to theinitiator (Verification of State Evolution and/or Validity).However, in accordance with the impossibility result, thecounterparty can fail to provide the proof of payment onX to the smart contract on time - again enabling theftthrough a malicious abort by the initiator.

Recently, hybrid versions of HTLC and signature lockatomic swaps have been introduced, most notably Ar-wen [89] and A2L [157], where users enter assets into amultisignature escrow with an exchange coordinator. Thisrelieves the user of strict online requirements while reduc-ing the risk of theft by the TTP to a (long) lockup of assetsin the worst case. However, this requires a more complexsetup process (similar to payment channels [141]) andintroduces higher costs in the form of additional fees toprevent malicious lockup of coordinator funds (griefing).

TABLE 1: Evaluation of Cross-Chain Communication protocols. Notation for non-binary TTP values: # relies onparticipants being available and synchrony, relies on TTP, H# hybrid.

ProtocolCCC Protocol Execution

Commit on X Verify / Commit on Y Abort on X

TTP DynamicTTP? Type TTP Collateral? Type TTP Dynamic

TTP? Type

Exc

hang

e(A

gnos

tic)

Custodial Exchange [41], [160] 7External Custodian(single, pre-defined) 7 External Validator 7 TTP (same)

HTLC Atomic Swaps [18], [19], [90], [160] # - Hash Lock # 7 Direct Observation # - TimelockNotarized HTLC Atomic Swaps [160] # - Hash Lock 7 External Validator H# - Timelock + TTPSPV Atomic Swaps [8], [57], [91], [108], [169] 3 Smart Contract 7 Smart Contract - - -Collateralized SPV Atomic Swaps [108], [169] 3 Smart Contract 3 Smart Contract - - -ECDSA Atomic Swaps [124] # - Signature Lock # 7 Direct Observation # - Timelock

A2L [157] H# 7Multisig Escrow +

Signature Lock # 7 Direct Observation H# 7 Timelock + TTP

Arwen [89] H# 7Multisig Escrow + Hash

Lock # 7 Direct Observation H# 7 Timelock + TTP

Tran

sfer

Het

erog

eneo

us XCLAIM [169] 3External Custodian

(single, unrestricted) 3 Smart Contract - - -

Multisig XCLAIM [170] 3Multisig Escrow (single,

unrestricted) 3 Smart Contract - - -

Dogethereum [159] 3External Custodian

(single, unrestricted) 3 Smart Contract - - -

PoS Sidechains [81] 7External Custodian(Consensus of Y ) 7 Smart Contract - - -

tBTC [16] 7 External Custodian 3 Smart Contract - - -

wBTC [17] 7External Custodian(single, pre-defined) 7 Direct Observation - - -

Hom

ogen

eous

ATOMIX [112] 7Consensus Custodian

(shard) 7 Consensus Committee 7 TTP (same)

SBAC [23], [151] 7Consensus Custodian

(shard) 7 Consensus Committee 7 TTP (same)

Rapidchain [168] 7Consensus Custodian

(shard) 7 Consensus Committee - - -

Fabric Channels [26] 7 Consensus Custodian 7 Consensus Committee 7 TTP (same)

Federated Sidechains/Pegs [36], [68] 7External Custodian(Consensus of Y ) 7 Consensus Committee - - -

PoS Sidechains [81] 7External Custodian(Consensus of Y ) 7 Consensus Committee - - -

Rootstock [119], [120] 7External Custodian(Consensus of Y )† 7 Consensus Committee - - -

Proof-of-Burn [102], [153] 3Smart Contract / Burn

address 7Smart Contract /

Consensus Committee - - -

Merged Mining/Staking [81], [100] 7 Consensus Custodian 7 Consensus Committee - - -

Randomness Beacon [51] 3 Smart Contract 7Smart Contract /

Consensus Committee - - -† The Rootstock sidechain plans to rely on Bitcoin’s (chain X) consensus participants (only those merge-mining Rootstock) to act as (consensus) custodians. As of this writing, however, the consensuscommittee of Rootstock (chain Y ) is used as external custodian.

6.2. One-Way Transfers

Moving on to one-way asset transfers, a first obser-vation is that this protocol family generally relies on theexistence of a TTP.

6.2.1. Heterogeneous Transfers. Heterogeneous one-way transfer protocols, in most cases, focus on trans-ferring assets to other ledgers via cryptocurrency-backedassets [26], [81], [120], [169]. An asset x is commit-ted/locked on Lx, while a representation of this asset y(x)is unlocked on Ly. This asset can then be used just like anyother native asset y on Ly: transferred, exchanged, or e.g.used with smart contracts. The latter can be particularlyuseful if Lx itself only has limited scripting capabilities(such as Bitcoin). After use, y(x) can be redeemed forthe corresponding amount of x. Compared to exchangeprotocols, where each swap requires transaction broadcaston all interlinked chains5, cryptocurrency-backed assetsrequire synchronization only twice: once to issue and asecond time to redeem the transferred assets.

The trust assumptions in this protocol family rangefrom a single centralized custodian [17], to a dynamicnetwork of collateralized intermediaries as in the case ofXCLAIM [169]. In the latter approach, any participantcan lock collateral in a smart contract on the issuingchain Y and act as custodial coordinator (or vault) forlocking of x on X (commit phase). If the coordinatorattempts to defraud users (fail to prove correct behavior),the smart contract on Y will automatically slash collateral

5. Note: while payment channels allow to keep transactions off-chain,correct synchronization of e.g. time across ledgers introduces risk to raceconditions (see Section 7.2).

and reimburse victims. Should (escrow) smart contractsbe available on both interlinked chains, custodial coor-dinators serve only as fallback or performance improve-ment. A similar collateralization approach is followed bytBTC [16], yet with the restriction that the set of custodialcoordinators is pre-defined (static). The risk of theft by co-ordinators can thereby be reduced by using multisignatureescrows rather than custodial coordinators - at the cost ofintroducing complexity in terms of broadcast transactionsand data published to the underlying blockchains [170].

A drawback of cryptocurrency-backed assets betweenheterogeneous chains is the necessity to maintain a stableexchange rate between the backing assets x and the assetsy of the issuing chain, which are used as collateral. Assuch, a sudden significant fluctuation of the exchange ratecan result in (i) financial damages to users holding y(x),and in turn (ii) network congestion on both X and Y asusers race to recover assets x. A further disadvantage ofexisting heterogeneous one-way transfer protocols is thelack of a dedicated abort phase on chain X: if Y failsto issue backed assets y(x), locked assets x can remainfrozen indefinitely at the TTP’s discretion.

6.2.2. Homogeneous Transfers. Similar to heteroge-neous transfers, this protocol group focuses on moving as-sets between different chains. The main difference herebyis that interlinked chains either maintain identical securityassumptions or are dependent on one-another, e.g. exhibita parent-child relation. We differentiate between commu-nication (i) among shards in sharded blockchains and (ii)from a parent to child blockchains.

With the goal of sharding being to improve transac-tion throughput in blockchains, efficient communicationamong individual shards is a necessity. As such, we

observe cross-shard communication protocols [23], [26],[112], [151], [168] to rely on consensus participants of(individual) shards to execute both commit, verify andabort phases of CCC. Thereby, communication in shardedblockchains follows the assumption that consensus com-mittees of all shards can be trusted, as otherwise thesystem is considered to fail (“correct by construction”assumption [112]). The main difference observed in thisprotocol group is the execution of an explicit abort phasein e.g. ATOMIX [112], as opposed to the assumption thatproofs of correct commit/lock execution will be timelydelivered between / accepted by consensus committees ofdifferent shards, as e.g. in SBAC [23], [151].

Sidechains, as first introduced by Back et al. in2012 [36] aim to extend the functionality of existingblockchains (parent) by allowing to move assets to so-called child blockchains, which run their own consensusbut to some extent are dependent on the parent chain.While the design of CCC protocol for sidechains are verysimilar to those of sharded systems, a core difference isthat the homogeneous security assumptions only applywhen transferring from parent to child, but not vice-versa.As such, e.g. in the case of Federated Sidechains/Pegs[36], [68], participants of the parent chain X cannotassume correct operation of the sidechain Y and henceconsider the consensus committee of Y as external. Root-stock seeks to reduce this risk by using trusted hardwarefor the coordinators on parent chain X (in this case,Bitcoin) [119], [120].

Finally, mechanisms for bootstrapping newblockchains, such as merged mining [3], [100] andProof-of-Burn [102], [153], as opposed to CCC protocolsdiscussed so far, aim to transfer information other thandigital assets. In the case of merged mining, this is aproof that some proof-of-work was performed on theparent chain, in Proof-of-Burn it is a proof that someassets were destroyed. A further difference hereby isthe absence of a mechanism to return the transferredinformation back to the parent chain: these protocols aredeployed as velvet forks [172] and hence the parent chaingenerally remains oblivious to the existence of the childchain(s).

6.3. General Observations

We proceed to briefly overview general observationswith respect to existing CCC protocols.Tendency to TTPs. The majority of CCC protocols re-sort to TTPs, rather than relying on participants beingonline and networks communication being synchronous(although synchronous models are often assumed never-theless). Further, with the exceptions of XCLAIM [169]and Dogethereum [159], such CCC protocols utilize a pre-defined, static committee of coordinators.Static Committees. If one of the interlinked chains Yimplements a BFT agreement protocol and hence has astatic consensus committee, this committee is typicallyused as TTP in all phases of CCC protocols. Arguably,this makes sense, as participants of the other blockchainX must anyway trust in the secure operation of Y (honestmajority of the consensus committee).Collateralization Trend. In recent works [16], [108],[159], [169], there is a trend towards collateralizing co-

ordinators, with the aim of preventing financial damagesto users and incentivizing correct behavior of TTPs - thisway potentially achieving economically trustless CCC pro-tocols (cf. Section 3.5). Here, the exchange rate is crucialto ensure that collateral has sufficient value to punishmisbehavior, and stabilization measures are necessary tomitigate both short and long term fluctuations.Absence of Hybrid Verification. Surprisingly, despitenumerous recent works on constructing and optimizingwatchtowers for payment channel networks [32], [34],[103], [125], these techniques have not yet been applied toCCC protocols – despite the similarity between paymentchannels and some CCC approaches (e.g. HTLC atomicswaps).Interoperability Blockchains. Recently, there has beenan influx of so called interoperability blockchains – spe-cialized sharded distributed ledgers which aim to serve ascommunication platform between other blockchains [20],[93], [116], [152], [161], [163]. Thereby, individualshards, which are coordinated via a parent chain runninga Byzantine fault tolerant agreement protocol, connectto and import assets from existing blockchains. Thereby,these projects have in common that they rely on exist-ing techniques such as cryptocurrency-backed assets [81],[159], [169] to bridge the gap to existing systems (andare hence not included in the evaluation above). A for-mal treatment of this design, also considering distributedcomputations, is presented in [121].

7. Implications for Blockchain, Threat, Net-work, and Privacy Models

In this section, we overview implications of cross-chain communication on distributed ledgers and necessaryconsiderations when designing CCC protocols.

7.1. Threat Model and Attacks

Security and Adversary Model. Both X and Y can havea well defined security model on their own. However,these security models are not necessarily the same andeven further, it might not be trivial to compare the guar-antees they provide. For instance, X may rely on PoW andthus assume that adversarial hash computation is bound byα ≤ 33% [74], [82], [145]. On the other hand, Y may usePoS and similarly assume that the adversary’s stake in thesystem is bound by β ≤ 33%. While similar at first glance,the cost of accumulating stake [75], [80] may be lowerthan that of accumulating computational power, or vice-versa [49]. Since permissionless distributed ledgers (suchas PoW or PoS) are not Sybil resistant [69], i.e., provideweak identities at best, quantifying adversary strengthis nearly impossible, even within a single ledger [31].However, this task becomes even more difficult in thecross-chain setting: not only can consensus participants (i)“hop” between different chains [117], [130], destabilizinginvolved systems, but also (ii) be susceptible to bribingattacks, which can be executed cross-chain, making de-tection unlikely [99], [127].Consensus Finality Guarantees. Interlinked chains Xand Y may assume different finality guarantees in theirledgers. Consider the following: X accepts a transaction

as valid when confirmed by k subsequent blocks, e.g. asin PoW blockchains [78]; instead, Y deems transactionsvalid as soon as they are written to the ledger (k = 1,e.g. [21]). A CCC protocol triggers a state transition on Yconditioned on a transaction included in X , however, lateran (accidental) fork occurs on X (perhaps deeper than k).While the state of X will be reverted, this may not bepossible in Y according to consensus rules - although theAtomicity property of CCC would require such measures.Replay Attacks. Replay attacks on state verification, i.e.,where proofs are re-submitted multiple times or on multi-ple chains, can result in failures such as double spending.Protections involve the use of sequence numbers, or chainskeeping track of previously processed proofs [58], [126],[151]. Special consideration may be needed in case ofpermanent blockchain forks, as this may require updatingthe way verification is performed [126], [169].Increasing Verification Cost (Griefing). An adversarycan increase the cost of the verification of a transactionacross chains. For instance, a spam attack makes theledger grow in size, increasing both verification time andcost. This in turn may impair cross-chain state verification,especially in heterogeneous settings, where verificationof external consensus is typically an expensive opera-tion [169]. In sharded systems, an adversary can try tocreate transactions, the validation of which requires infor-mation from (almost) all shards, significantly increasingcost and defeating the purpose of sharding itself.Composability Attacks. We recall, in blockchains withstablizing [28], [162] consensus, a security parameter kis used to denote the number of blocks or confirma-tion [5] a transaction should have, before being acceptedas secure [78], [135], [138], i.e., with the probability ofa reversion being negligible. The same applies to stateagreement and state evolution proofs. In addition, thevalue linked a verified transaction must be considered:the higher the potential gain by an adversary, the higherthe risk of an attack, and the more confirmations shouldbe required [150]. However, following recent works [173],we argue at least the entire composition of a block mustbe considered, as this is the total value an adversary cangain from executing a successful attack. Recall that fora transaction to be reversed or modified, the entire blockmust be altered.

7.2. Network model

Synchrony Across Chains. The absence of a global clockacross chains requires to either agree and trust a thirdparty as external clock, or rely on chain-dependent timedefinition, such as the block generation rate [78], hinder-ing a seamless synchronization across chains [78], [169].Several factors, such as the instance of the consensusalgorithm, computation and communication capabilitiesof consensus participants or peer-to-peer network delaymust be considered for a correct operation of cross-chaincommunication protocols, especially if timelocks are used.Data Availability. Protocols leveraging verification ofstate agreement or validity across chains typically relyon timely arrival of proofs and accompanying data (blockheaders, transactions, ...). Furthermore, existing sub-linearstate verification techniques relying on probabilistic sam-pling require additional data to be included in the verified

blockchain [105], [122]. If an adversary can exclude thisdata from the chain, these protocols not only become lessefficient but may potentially exhibit vulnerabilities [122].This is a particular problem in heterogeneous settings,if data availability is not enforced by consensus, e.g.if protocols are deployed via velvet forks [172]. Onepossible solution is to include data availability proofs [23],at the cost of increasing complexity of the process.

7.3. Blockchain Model

Cryptographic Primitives. Interconnected chains X andY may leverage different cryptographic schemes, or dif-ferent instances of the same scheme. Thereby, cross-chaincommunication often requires compatible cryptographicprimitives: a CCC protocol between a system X usingECDSA [95] as its digital signature scheme and a systemY using Schnorr [147] is only possible if both schemes areinstantiated over the same elliptic curve [124]. Similarly,HTLC-based protocols require that the domain of the hashfunction has the same size in both X and Y - otherwisethe protocol is prone to oversize preimage attacks [97].Language Expressiveness. The functionality of CCC pro-tocols is typically restricted by the computational opera-tions supported by the involved chains. These can reachfrom near Turing complete environments [56], over re-stricted operation sets [135], [148], to the (near) absenceof scripting functionality altogether [9], [52]. CCC pro-tocols must hence (i) consider the operations supportedby both X and Y and leverage the intersecting function-ality [124]; or (ii) move assets from chain with limitedfunctionality to those with high(er) language expressive-ness [68], [159], [169].

7.4. Privacy and Linkability

Privacy is crucial in any financial interaction and thusin cross-chain communication as well. Ideally it shouldnot be possible for an observer to determine what twoevents have been synchronized across chains (e.g., whattwo assets have been exchanged and by whom). Amongother advantages, this improves the fungibility of pay-ments. However, there exist several privacy attack vectorsin cross-chain communication: (i) recent works [83], [123]show attacks leveraging the locking mechanism and somecountermeasures have been proposed [123], [124], [144];(ii) heuristics to explore blocks from different cryptocur-rencies [100] as well as forks [154] to cluster minerand user accounts [92]; (iii) CCC protocols leveragingcoordinators, similar to and payment hubs [84], [98],also lead to privacy leakages that enable further accountclustering [166]. Recent works [83], [88], [157] proposemeasures that allow to preserve the anonymity of partici-pants, if added to CCC protocols.

8. Related Work

We believe that our study represents the most compre-hensive systematic investigation of cross-chain communi-cation to date. Yet, we list here other works and efforts bythe blockchain community, illuminating different subsetsof this space and supporting our study.

The first work discussing cross-chain communication,excluding forum discussions, is a technical report by Backet al. [36]. The authors introduce the term “sidechain”and present how assets can be transferred between twochains using a committee of custodians or SPV proofsin a homogeneous security model. A more recent reportby Buterin discusses how cross-chain exchanges can beachieved via custodians, escrows, HTLCs and cross-chainstate verification, and provides a high level discussionof possible failures in cross-chain communication [57].Siris et al. provide an iterative overview of protocols foratomic cross-chain swaps and “sidechains” [149], focusingmostly on community driven efforts, rather than academicpublications. Similarly, Johnson et al. discuss open sourceinteroperability projects related to Ethereum [96], whileRobinson evaluates Ethereum as a coordination platformfor communication among other blockchains [143]. Ben-nik et al. [40] and similarly Miraz et al. [133] summa-rize technical details of HTLC atomic cross-chain swaps.Avarikioti et al. provide a thorough formal study of block-chain sharding protocols, although their focus does not lieon the communication between shards [33].

9. Concluding Remarks

Our systematic analysis of cross-chain communicationas a new problem in the era of distributed ledgers allows usto relate (mostly) community driven efforts to establishedacademic research in database and distributed systemsresearch. We formalize the cross-chain communicationproblem and show it cannot be solved without a trustedthird party – contrary to the assumptions often made inthe blockchain community. The classifications and com-parative evaluations introduced in this work, taking intoaccount both academic research and the vast number ofonline resources, allow to better understand the similaritiesand differences between existing cross-chain communica-tion approaches - and possibly contribute to clearer com-munication between academia and industry in this field.Finally, by discussing implications and open challenges re-lated to blockchain, network, and threat models, as well asprivacy and linkability, we offer a comprehensive guide fordesigning protocols, bridging multiple distributed ledgers.

10. Acknowledgements

We would like express our gratitude to GeorgiaAvarikioti, Daniel Perez and Dominik Harz for help-ful comments and feedback on earlier versions of thismanuscript. We also thank Nicholas Stifter, Aljosha Jud-mayer, Philipp Schindler, and Edgar Weippl for insightfuldiscussions during the course of this research.

This research was funded by Bridge 1 858561 SESC,Bridge 1 864738 PR4DLT (all FFG), the ChristianDoppler Laboratory for Security and Quality Improvementin the Production System Lifecycle (CDL-SQI), the com-petence center SBA-K1 funded by COMET, ChaincodeLabs and the Austrian Science Fund (FWF) through theMeitner program. Mustafa Al-Bassam is funded by ascholarship from the Alan Turing Institute. Alexei Zamy-atin is supported by the Binance Research Fellowship.

References

[1] Bitcoin Developer Guide: Simplified Payment Verification (SPV).https://bitcoin.org/en/developer-guide#simplified-payment-verification-spv, accessed: 2018-05-16

[2] Bitcoin Wiki: Hashed Time-Lock Contracts. https://en.bitcoin.it/wiki/Hashed Timelock Contracts, accessed: 2018-05-16

[3] Bitcoin wiki: Merged mining specification. https://en.bitcoin.it/wiki/Merged mining specification, accessed: 2018-05-03

[4] Btcrelay. https://github.com/ethereum/btcrelay, accessed 2019-08-15

[5] Confirmations. https://en.bitcoin.it/wiki/Confirmation, accessed:2018-11-28

[6] Dogerelay. https://github.com/dogethereum/dogerelay, accessed2019-08-15

[7] Eth-eos-relay. https://github.com/EveripediaNetwork/eth-eos-relay, accessed 2019-08-15

[8] Ethereum contract allowing ether to be obtained with bitcoin.https://github.com/ethers/EthereumBitcoinSwap, accessed: 2018-10-30

[9] Monero reference implementation. https://github.com/monero-project/monero, accessed: 2018-07-30

[10] Parity-Bridge. https://github.com/paritytech/parity-bridge,accessed 2019-08-15

[11] The parity light protocol - wiki. https://wiki.parity.io/The-Parity-Light-Protocol-(PIP), accessed: 2018-10-30

[12] Peace relay. https://github.com/loiluu/peacerelay, accessed 2019-08-15

[13] Poa bridge. https://github.com/poanetwork/poa-bridge, accessed:2018-05-23

[14] Project alchemy. https://github.com/ConsenSys/Project-Alchemy,accessed 2019-08-15

[15] Project waterloo. https://blog.kyber.network/waterloo-a-decentralized-practical-bridge-between-eos-and-ethereum-1c230ac65524, accessed 2019-08-15

[16] tbtc: A decentralized redeemable btc-backed erc-20 token. http://docs.keep.network/tbtc/index.pdf, accessed: 2019-11-15

[17] Wrapped bitcoin. https://www.wbtc.network/assets/wrapped-tokens-whitepaper.pdf, accessed: 2018-05-03

[18] Alt chains and atomic transfers. bitcointalk.org (2013),https://bitcointalk.org/index.php?topic=193281.msg2003765#msg2003765

[19] Atomic swap. Bitcoin Wiki (2013), https://en.bitcoin.it/wiki/Atomic swap

[20] Wanchain whitepaper. https://www.wanchain.org/files/Wanchain-Whitepaper-EN-version.pdf (2017)

[21] Abraham, I., Gueta, G., Malkhi, D.: Hot-stuff the linear, optimal-resilience, one-message bft devil. arXiv:1803.05069 (2018), https://arxiv.org/pdf/1803.05069.pdf

[22] Al-Bassam, M.: Lazyledger: A distributed data availability ledgerwith client-side smart contracts (2019), https://arxiv.org/pdf/1905.09274.pdf

[23] Al-Bassam, M., Sonnino, A., Bano, S., Hrycyszyn, D., Danezis,G.: Chainspace: A sharded smart contracts platform. In: 2018Network and Distributed System Security Symposium (NDSS)(2018)

[24] Al-Bassam, M., Sonnino, A., Buterin, V.: Fraud proofs: Max-imising light client security and scaling blockchains with dishon-est majorities. CoRR abs/1809.09044 (2018), http://arxiv.org/abs/1809.09044

[25] Alp, E.C., Kokoris-Kogias, E., Fragkouli, G., Ford, B.: Rethinkinggeneral-purpose decentralized computing. In: Proceedings of theWorkshop on Hot Topics in Operating Systems. pp. 105–112.ACM (2019)

[26] Androulaki, E., Cachin, C., De Caro, A., Kokoris-Kogias, E.:Channels: Horizontal scaling and confidentiality on permissionedblockchains. In: European Symposium on Research in ComputerSecurity. pp. 111–131. Springer (2018)

[27] Andrychowicz, M.: Multiparty computation protocols basedon cryptocurrencies (2015), https://depotuw.ceon.pl/bitstream/handle/item/1327/dis.pdf, accessed: 2017-02-15

[28] Angluin, D., Fischer, M.J., Jiang, H.: Stabilizing consensus inmobile networks. In: Distributed Computing in Sensor Systems.pp. 37–50. Springer (2006), http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.60.1040&rep=rep1&type=pdf

[29] Asokan, N.: Fairness in electronic commerce (1998)

[30] Asokan, N., Shoup, V., Waidner, M.: Optimistic fair exchange ofdigital signatures. In: International Conference on the Theory andApplications of Cryptographic Techniques. pp. 591–606. Springer(1998)

[31] Avarikioti, G., Kappeli, L., Wang, Y., Wattenhofer, R.:Bitcoin security under temporary dishonest majority. In: 23rdFinancial Cryptography and Data Security (FC) (2019), https://www.tik.ee.ethz.ch/file/ab83461dc5ca3b739c079a27f3757e94/bitcoin%20security%20under%20temporary%20dishonest%20majority.pdf

[32] Avarikioti, G., Kogias, E.K., Wattenhofer, R.: Brick: Asyn-chronous state channels. arXiv preprint arXiv:1905.11360 (2019)

[33] Avarikioti, G., Kokoris-Kogias, E., Wattenhofer, R.: Divide andscale: Formalization of distributed ledger sharding protocols.arXiv preprint arXiv:1910.10434 (2019)

[34] Avarikioti, G., Laufenberg, F., Sliwinski, J., Wang, Y., Watten-hofer, R.: Towards secure and efficient payment channels. arXivpreprint arXiv:1811.12740 (2018)

[35] Babaoglu, O., Toueg, S.: Understanding non-blocking atomiccommitment. Distributed systems pp. 147–168 (1993)

[36] Back, A., Corallo, M., Dashjr, L., Friedenbach, M., Maxwell, G.,Miller, A., Poelstra, A., Timon, J., Wuille, P.: Enabling blockchaininnovations with pegged sidechains (2014), https://blockstream.com/sidechains.pdf

[37] Ben-Sasson, E., Bentov, I., Horesh, Y., Riabzev, M.: Scalable,transparent, and post-quantum secure computational integrity.IACR Cryptology ePrint Archive 2018, 46 (2018)

[38] Ben-Sasson, E., Chiesa, A., Spooner, N.: Interactive oracle proofs.In: Theory of Cryptography Conference. pp. 31–60. Springer(2016)

[39] Benaloh, J., De Mare, M.: One-way accumulators: A decentral-ized alternative to digital signatures. In: Workshop on the Theoryand Application of of Cryptographic Techniques. pp. 274–285.Springer (1993)

[40] Bennink, P., Gijtenbeek, L.v., Deventer, O.v., Everts, M.: Ananalysis of atomic swaps on and between ethereum blockchainsusing smart contracts. Tech. report (2018), https://work.delaat.net/rp/2017-2018/p42/report.pdf

[41] Bentov, I., Ji, Y., Zhang, F., Li, Y., Zhao, X., Breidenbach,L., Daian, P., Juels, A.: Tesseract: Real-time cryptocurrencyexchange using trusted hardware. Cryptology ePrint Archive,Report 2017/1153 (2017), https://eprint.iacr.org/2017/1153.pdf,accessed:2017-12-04

[42] Bentov, I., Kumaresan, R.: How to use bitcoin to design fairprotocols. In: Advances in Cryptology–CRYPTO 2014. pp. 421–439. Springer (2014), http://eprint.iacr.org/2014/129.pdf

[43] Bentov, I., Pass, R., Shi, E.: Snow white: Provably secureproofs of stake (2016), https://eprint.iacr.org/2016/919.pdf, ac-cessed: 2016-11-08

[44] Bernstein, P.A., Hadzilacos, V., Goodman, N.: Concurrency con-trol and recovery in database systems, vol. 370. Addison-wesleyNew York (1987)

[45] Bitansky, N., Canetti, R., Chiesa, A., Tromer, E.: From ex-tractable collision resistance to succinct non-interactive argumentsof knowledge, and back again. In: Proceedings of the 3rd Innova-tions in Theoretical Computer Science Conference. pp. 326–349.ACM (2012)

[46] Boneh, D., Bonneau, J., Bunz, B., Fisch, B.: Verifiable delayfunctions. In: CRYPTO (2018)

[47] Boneh, D., Bunz, B., Fisch, B.: Batching techniques for ac-cumulators with applications to iops and stateless blockchains.Cryptology ePrint Archive, Report 2018/1188 (2018), https://eprint.iacr.org/2018/1188.pdf, https://eprint.iacr.org/2018/1188

[48] Boneh, D., Naor, M.: Timed commitments. In: Annual Interna-tional Cryptology Conference. pp. 236–254. Springer (2000)

[49] Bonneau, J.: Why buy when you can rent? bribery attacks onbitcoin consensus. In: BITCOIN ’16: Proceedings of the 3rdWorkshop on Bitcoin and Blockchain Research (February 2016),http://fc16.ifca.ai/bitcoin/papers/Bon16b.pdf

[50] Bonneau, J., Clark, J., Goldfeder, S.: On bitcoin as a publicrandomness source (2015), https://eprint.iacr.org/2015/1015.pdf,accessed: 2015-10-25

[51] Bonneau, J., Clark, J., Goldfeder, S.: On bitcoin as a publicrandomness source. IACR Cryptology ePrint Archive 2015, 1015(2015)

[52] Bonneau, J., Miller, A.: Fawkescoin: Bitcoin without public-key crypto. In: Security Protocols XXII. pp. 350–358.Springer (2014), http://www.jbonneau.com/doc/BM14-SPW-fawkescoin.pdf

[53] Bonneau, J., Miller, A., Clark, J., Narayanan, A., Kroll, J.A.,Felten, E.W.: Sok: Research perspectives and challenges for bit-coin and cryptocurrencies. In: IEEE Symposium on Security andPrivacy (2015), http://www.ieee-security.org/TC/SP2015/papers-archived/6949a104.pdf

[54] Bunz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., Maxwell,G.: Bulletproofs: Efficient range proofs for confidential trans-actions (2017), http://web.stanford.edu/∼buenz/pubs/bulletproofs.pdf, accessed:2017-11-10

[55] Bunz, B., Goldfeder, S., Bonneau, J.: Proofs-of-delay and ran-domness beacons in ethereum (2017)

[56] Buterin, V.: Ethereum: A next-generation smart contract anddecentralized application platform (2014), https://github.com/ethereum/wiki/wiki/White-Paper, accessed: 2016-08-22

[57] Buterin, V.: Chain interoperability. Tech. report (2016),https://www.r3.com/wp-content/uploads/2017/06/chaininteroperability r3.pdf, accessed: 2017-03-25

[58] Buterin, V.: Cross-shard contract yanking.https://ethresear.ch/t/cross-shard-contract-yanking/1450 (2018)

[59] Cachin, C.: Architecture of the hyperledger blockchain fabric(2016), https://www.zurich.ibm.com/dccl/papers/cachin dccl.pdf,accessed: 2016-08-10

[60] Cachin, C., Camenisch, J.: Optimistic fair secure computation.In: Annual International Cryptology Conference. pp. 93–111.Springer (2000)

[61] Castro, M., Liskov, B., et al.: Practical byzantine fault tolerance.In: OSDI. vol. 99, pp. 173–186 (1999), http://pmg.csail.mit.edu/papers/osdi99.pdf

[62] Catalano, D., Fiore, D.: Vector commitments and their applica-tions. In: International Workshop on Public Key Cryptography.pp. 55–72. Springer (2013)

[63] Chandra, T.D., Toueg, S.: Unreliable failure detectors forreliable distributed systems. vol. 43, pp. 225–267. ACM (1996),https://ecommons.cornell.edu/bitstream/handle/1813/7192/95-1535.pdf?sequence=1

[64] Chepurnoy, A., Duong, T., Fan, L., Zhou, H.S.: Twinscoin: Acryptocurrency via proof-of-work and proof-of-stake (2017), http://eprint.iacr.org/2017/232.pdf, accessed: 2017-03-22

[65] David, B., Gazi, P., Kiayias, A., Russell, A.: Ouroboros praos:An adaptively-secure, semi-synchronous proof-of-stake protocol.Cryptology ePrint Archive, Report 2017/573 (2017), http://eprint.iacr.org/2017/573.pdf, accessed: 2017-06-29

[66] Decker, C., Wattenhofer, R.: Bitcoin transaction malleabilityand mtgox. In: Computer Security-ESORICS 2014. pp.313–326. Springer (2014), http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf

[67] Dijkstra, E.W.: Solution of a problem in concurrent programmingcontrol. In: Pioneers and Their Contributions to Software Engi-neering, pp. 289–294. Springer (2001)

[68] Dilley, J., Poelstra, A., Wilkins, J., Piekarska, M., Gorlick, B.,Friedenbach, M.: Strong federations: An interoperable block-chain solution to centralized third party risks. arXiv preprintarXiv:1612.05491 (2016)

[69] Douceur, J.R.: The sybil attack. In: International Workshop onPeer-to-Peer Systems. pp. 251–260. Springer (2002), http://www.cs.cornell.edu/people/egs/cs6460-spring10/sybil.pdf

[70] Duong, T., Fan, L., Zhou, H.S.: 2-hop blockchain: Combin-ing proof-of-work and proof-of-stake securely. Cryptology ePrintArchive, Report 2016/716 (2016), https://eprint.iacr.org/2016/716.pdf, accessed: 2017-02-06

[71] Dziembowski, S., Eckey, L., Faust, S.: Fairswap: How to fairly ex-change digital goods. In: Proceedings of the 2018 ACM SIGSACConference on Computer and Communications Security. pp. 967–984. ACM (2018)

[72] Eberhardt, J., Tai, S.: Zokrates-scalable privacy-preserving off-chain computations

[73] Egger, C., Moreno-Sanchez, P., Maffei, M.: Atomic multi-channelupdates with constant collateral in bitcoin-compatible payment-channel networks. In: CCS (2019)

[74] Eyal, I., Sirer, E.G.: Majority is not enough: Bitcoin mining isvulnerable. In: Financial Cryptography and Data Security. pp.436–454. Springer (2014), http://arxiv.org/pdf/1311.0243

[75] Fanti, G., Kogan, L., Oh, S., Ruan, K., Viswanath, P., Wang, G.:Compounding of wealth in proof-of-stake cryptocurrencies. arXivpreprint arXiv:1809.07468 (2018)

[76] Fischer, M.J., Lynch, N.A., Paterson, M.S.: Impossibility ofdistributed consensus with one faulty process. vol. 32, pp.374–382. ACM (1985), http://macs.citadel.edu/rudolphg/csci604/ImpossibilityofConsensus.pdf

[77] Ford, B., Gasser, L., Kogias, E.K., Jovanovic, P.: Cryptograph-ically verifiable data structure having multi-hop forward andbackwards links and associated systems and methods (Dec 132018), uS Patent App. 15/618,653

[78] Garay, J.A., Kiayias, A., Leonardos, N.: The bitcoin backboneprotocol with chains of variable difficulty (2016), http://eprint.iacr.org/2016/1048.pdf, accessed: 2017-02-06

[79] Gartner, F.C.: Specifications for fault tolerance: A comedy offailures (1998)

[80] Gazi, P., Kiayias, A., Russell, A.: Stake-bleeding attacks on proof-of-stake blockchains. Cryptology ePrint Archive, Report 2018/248(2018), https://eprint.iacr.org/2018/248.pdf, accessed:2018-03-12

[81] Gazi, P., Kiayias, A., Zindros, D.: Proof-of-stake sidechains. IEEESecurity and Privacy. IEEE (2019)

[82] Gervais, A., Karame, G.O., Wust, K., Glykantzis, V., Ritzdo rf,H., Capkun, S.: On the security and performance of proof ofwork blockchains. In: Proceedings of the 2016 ACM SIGSAC.pp. 3–16. ACM (2016)

[83] Green, M., Miers, I.: Bolt: Anonymous payment channelsfor decentralized currencies. Cryptology ePrint Archive, Report2016/701 (2016), http://eprint.iacr.org/2016/701, accessed: 2017-08-07

[84] Gudgeon, L., Moreno-Sanchez, P., Roos, S., McCorry, P., Ger-vais, A.: Sok: Off the chain transactions. Cryptology ePrintArchive, Report 2019/360 (2019), https://eprint.iacr.org/2019/360.pdf, https://eprint.iacr.org/2019/360

[85] Han, R., Lin, H., Yu, J.: On the optionality and fairness of atomicswaps. Cryptology ePrint Archive, Report 2019/896 (2019), https://eprint.iacr.org/2019/896

[86] Harz, D., Boman, M.: The scalability of trustless trust.arXiv:1801.09535 (2018), https://arxiv.org/pdf/1801.09535.pdf,accessed:2018-01-31

[87] Harz, D., Gudgeon, L., Gervais, A., Knottenbelt, W.J.: Bal-ance: Dynamic adjustment of cryptocurrency deposits. CryptologyePrint Archive, Report 2019/675 (2019), https://eprint.iacr.org/2019/675.pdf, https://eprint.iacr.org/2019/675

[88] Heilman, E., Alshenibr, L., Baldimtsi, F., Scafuro, A., Goldberg,S.: Tumblebit: An untrusted bitcoin-compatible anonymous pay-ment hub (2016), https://eprint.iacr.org/2016/575.pdf, accessed:2017-09-29

[89] Heilman, E., Lipmann, S., Goldberg, S.: The arwen trading pro-tocols. Whitepaper, https://www.arwen.io/whitepaper.pdf

[90] Herlihy, M.: Atomic cross-chain swaps. arXiv:1801.09515 (2018),https://arxiv.org/pdf/1801.09515.pdf, accessed:2018-01-31

[91] Herlihy, M., Liskov, B., Shrira, L.: Cross-chain deals and adver-sarial commerce. arXiv preprint arXiv:1905.09743 (2019)

[92] Hinteregger, A., Haslhofer, B.: An empirical analysis of monerocross-chain traceability. arXiv preprint arXiv:1812.02808 (2018)

[93] Hosp, D., Hoenisch, T., Kittiwongsunthorn, P., et al.: Comit-cryptographically-secure off-chain multi-asset instant transactionnetwork. arXiv preprint arXiv:1810.02174 (2018)

[94] Intel Corp.: Software Guard Extensions Programming Reference,Ref. 329298-002US. https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf (2014), https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf

[95] Johnson, D., Menezes, A., Vanstone, S.: The elliptic curve digitalsignature algorithm (ecdsa). International journal of informationsecurity 1(1), 36–63 (2001)

[96] Johnson, S., Robinson, P., Brainard, J.: Sidechains and interoper-ability. arXiv preprint arXiv:1903.04077 (2019)

[97] Jones, J., abitmore: Optional htlc preimage length and hash160addition. BSIP 64, blog post, https://github.com/bitshares/bsips/issues/163

[98] Jourenko, M., Kurazumi, K., Larangeira, M., Tanaka, K.:Sok: A taxonomy for layer-2 scalability related protocols forcryptocurrencies. Cryptology ePrint Archive, Report 2019/352(2019), https://eprint.iacr.org/2019/352.pdf, https://eprint.iacr.org/2019/352

[99] Judmayer, A., Stifter, N., Zamyatin, A., Tsabary, I., Eyal, I., Gazi,P., Meiklejohn, S., Weippl, E.: Pay-to-win: Incentive attacks onproof-of-work cryptocurrencies. Cryptology ePrint Archive, Re-port 2019/775 (2019), https://eprint.iacr.org/2019/775.pdf, https://eprint.iacr.org/2019/775

[100] Judmayer, A., Zamyatin, A., Stifter, N., Voyiatzis, A.G., Weippl,E.: Merged mining: Curse or cure? In: CBT’17: Proceedings ofthe International Workshop on Cryptocurrencies and BlockchainTechnology (Sep 2017), https://eprint.iacr.org/2017/791.pdf

[101] Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S.M., Felten,E.W.: Arbitrum: Scalable, private smart contracts. In: Proceedingsof the 27th USENIX Conference on Security Symposium. pp.1353–1370. USENIX Association (2018)

[102] Karantias, K., Kiayias, A., Zindros, D.: Proof-of-burn. Interna-tional Conference on Financial Cryptography and Data Security(2019)

[103] Khabbazian, M., Nadahalli, T., Wattenhofer, R.: Outpost: A re-sponsive lightweight watchtower (2019)

[104] Kiayias, A., Lamprou, N., Stouka, A.P.: Proofs of proofs ofwork with sublinear complexity. In: International Conference onFinancial Cryptography and Data Security. pp. 61–78. Springer,Springer (2016)

[105] Kiayias, A., Miller, A., Zindros, D.: Non-interactive proofsof proof-of-work. Cryptology ePrint Archive, Report 2017/963(2017), https://eprint.iacr.org/2017/963.pdf, accessed:2017-10-03

[106] Kiayias, A., Russell, A., David, B., Oliynykov, R.:Ouroboros: A provably secure proof-of-stake blockchainprotocol (2016), https://pdfs.semanticscholar.org/a583/3270b14e251f0b16d86438d04652b1b8d7f3.pdf, accessed:2018-08-19

[107] Kiayias, A., Zhou, H.S., Zikas, V.: Fair and robust multi-partycomputation using a global transaction ledger. In: Annual Inter-national Conference on the Theory and Applications of Crypto-graphic Techniques. pp. 705–734. Springer (2016), https://eprint.iacr.org/2015/574.pdf

[108] Kiayias, A., Zindros, D.: Proof-of-work sidechains. In: Interna-tional Conference on Financial Cryptography and Data Security.Springer (2018)

[109] Kogias, E.K., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L., Ford,B.: Enhancing bitcoin security and performance with strong con-sistency via collective signing. In: 25th USENIX Security Sym-posium (USENIX Security 16). USENIX Association, Austin, TX(Aug 2016), http://arxiv.org/pdf/1602.06997.pdf

[110] Kokoris-Kogias, E.: Robust and scalable consensus for shardeddistributed ledgers. Tech. rep., Cryptology ePrint Archive, Report2019/676 (2019)

[111] Kokoris-Kogias, E., Alp, E.C., Siby, S.D., Gailly, N., Gasser,L., Jovanovic, P., Syta, E., Ford, B.: Calypso: Auditable sharingof private data over blockchains. Tech. rep., Cryptology ePrintArchive, Report 2018/209 (2018)

[112] Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Syta, E.,Ford, B.: Omniledger: A secure, scale-out, decentralized ledgervia sharding. In: 2018 IEEE Symposium on Security and Privacy(SP). pp. 583–598. IEEE (2018)

[113] Kokoris-Kogias, L., Gasser, L., Khoffi, I., Jovanovic, P., Gailly,N., Ford, B.: Managing identities using blockchains and CoSi. In:9th Workshop on Hot Topics in Privacy Enhancing Technologies(HotPETs 2016) (2016)

[114] Kumaresan, R., Bentov, I.: Amortizing secure computation withpenalties. In: Proceedings of the 2016 ACM SIGSAC Conferenceon Computer and Communications Security. pp. 418–429. ACM(2016)

[115] Kupcu, A., Lysyanskaya, A.: Usable optimistic fair exchange.Computer Networks 56(1), 50–63 (2012)

[116] Kwon, J., Buchman, E.: Cosmos: A network of dis-tributed ledgers. https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md (2015)

[117] Kwon, Y., Kim, H., Shin, J., Kim, Y.: Bitcoin vs. bitcoin cash: Co-existence or downfall of bitcoin cash? arXiv:1902.11064 (2019),https://arxiv.org/pdf/1902.11064.pdf

[118] Lamport, L.: A simple approach to specifying concurrent systems.Communications of the ACM 32(1), 32–45 (1989)

[119] Lerner, S.D.: Rootstock: Bitcoin powered smart contracts. https://docs.rsk.co/RSK White Paper-Overview.pdf (2015)

[120] Lerner, S.: Drivechains, sidechains and hybrid 2-waypeg designs. Tech. rep., Tech. Rep. [Online] (2018),https://docs.rsk.co/Drivechains Sidechains and Hybrid 2-way peg Designs R9.pdf

[121] Liu, Z., Xiang, Y., Shi, J., Gao, P., Wang, H., Xiao, X., Hu, Y.C.:Hyperservice: Interoperability and programmability across hetero-geneous blockchains. arXiv preprint arXiv:1908.09343 (2019)

[122] Luu, L., Buenz, B., Zamani, M.: Flyclient super light clientfor cryptocurrencies https://stanford2017.scalingbitcoin.org/files/Day1/flyclientscalingbitcoin.pptx.pdf, accessed 2018-04-17

[123] Malavolta, G., Moreno-Sanchez, P., Kate, A., Maffei, M., Ravi,S.: Concurrency and privacy with payment-channel networks. In:CCS. pp. 455–471 (2017)

[124] Malavolta, G., Moreno-Sanchez, P., Schneidewind, C., Kate, A.,Maffei, M.: Anonymous multi-hop locks for blockchain scalabil-ity and interoperability. In: NDSS (2019)

[125] McCorry, P., Bakshi, S., Bentov, I., Miller, A., Meiklejohn, S.:Pisa: Arbitration outsourcing for state channels. IACR CryptologyePrint Archive 2018, 582 (2018)

[126] McCorry, P., Heilman, E., Miller, A.: Atomically trading withroger: Gambling on the success of a hardfork. In: CBT’17:Proceedings of the International Workshop on Cryptocurrenciesand Blockchain Technology (Sep 2017), http://homepages.cs.ncl.ac.uk/patrick.mc-corry/atomically-trading-roger.pdf

[127] McCorry, P., Hicks, A., Meiklejohn, S.: Smart contracts forbribing miners. In: 5th Workshop on Bitcoin and Block-chain Research, Financial Cryptography and Data Security 18(FC). Springer (2018), http://fc18.ifca.ai/bitcoin/papers/bitcoin18-final14.pdf

[128] Meckler, I., Shapiro, E.: Coda: Decentralized cryptocurrencyat scale. https://cdn.codaprotocol.com/v2/static/coda-whitepaper-05-10-2018-0.pdf (2018)

[129] Merkle, R.C.: A digital signature based on a conventional encryp-tion function. In: Conference on the Theory and Application ofCryptographic Techniques. pp. 369–378. Springer (1987)

[130] Meshkov, D., Chepurnoy, A., Jansen, M.: Revisiting difficultycontrol for blockchain systems. Cryptology ePrint Archive,Report 2017/731 (2017), http://eprint.iacr.org/2017/731.pdf, ac-cessed: 2017-08-03

[131] Micali, S.: Algorand: The efficient and democratic ledger (2016),https://arxiv.org/pdf/1607.01341.pdf, accessed: 2017-02-09

[132] Miller, A.: The high-value-hash highway, bitcoin forum post(2012), https://bitcointalk.org/index.php?topic=98986.0

[133] Miraz, M., Donald, D.C.: Atomic cross-chain swaps: Devel-opment, trajectory and potential of non-monetary digital tokenswap facilities. Annals of Emerging Technologies in Computing(AETiC) Vol 3 (2019)

[134] Moreno-Sanchez, P., Randomrun, Le, D.V., Noether, S., Goodell,B., Kate, A.: Dlsag: Non-interactive refund transactions for inter-operable payment channels in monero. Cryptology ePrint Archive,Report 2019/595 (2019), https://eprint.iacr.org/2019/595

[135] Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system(Dec 2008), https://bitcoin.org/bitcoin.pdf, accessed: 2015-07-01

[136] Nikitin, K., Kokoris-Kogias, E., Jovanovic, P., Gailly, N., Gasser,L., Khoffi, I., Cappos, J., Ford, B.: CHAINIAC: Proactivesoftware-update transparency via collectively signed skipchainsand verified builds

[137] Pagnia, H., Gartner, F.C.: On the impossibility of fair exchangewithout a trusted third party. Tech. rep., Technical Report TUD-BS-1999-02, Darmstadt University of Technology . . . (1999)

[138] Pass, R., Seeman, L., shelat, a.: Analysis of the blockchainprotocol in asynchronous networks (2016), http://eprint.iacr.org/2016/454.pdf, accessed: 2016-08-01

[139] Pass, R., Shi, E.: Hybrid consensus: Scalable permissionless con-sensus (Sep 2016), https://eprint.iacr.org/2016/917.pdf, accessed:2016-10-17

[140] Poelstra, A.: Scriptless scripts. Presentation slides,https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf

[141] Poon, J., Dryja, T.: The bitcoin lightning network (2016), https://lightning.network/lightning-network-paper.pdf, accessed: 2016-07-07

[142] Rivest, R.L., Shamir, A., Wagner, D.A.: Time-lock puzzles andtimed-release crypto (1996)

[143] Robinson, P.: The merits of using ethereum mainnet as a co-ordination blockchain for ethereum private sidechains (2019),https://arxiv.org/pdf/1906.04421.pdf

[144] Rubin, J., Naik, M., Subramanian, N.: Merkelized abstract syn-tax trees. http://www.mit.edu/∼jlrubin/public/pdfs/858report.pdf(2014)

[145] Sapirshtein, A., Sompolinsky, Y., Zohar, A.: Optimal selfish min-ing strategies in bitcoin (2015), http://arxiv.org/pdf/1507.06183.pdf, accessed: 2016-08-22

[146] Schindler, P., Judmayer, A., Stifter, N., Weippl, E.: Hydrand:Practical continuous distributed randomness. Cryptology ePrintArchive, Report 2018/319 (2018), https://eprint.iacr.org/2018/319.pdf

[147] Schnorr, C.P.: Efficient signature generation by smart cards. Jour-nal of cryptology 4(3), 161–174 (1991)

[148] Sergey, I., Kumar, A., Hobor, A.: Scilla: a smart contractintermediate-level language. arXiv:1801.00687 (2018), https://arxiv.org/pdf/1801.00687.pdf, accessed:2018-01-08

[149] Siris, V.A., Dimopoulos, D., Fotiou, N., Voulgaris, S., Polyzos,G.C.: Interledger smart contracts for decentralized authorizationto constrained things (2019), https://arxiv.org/pdf/1905.01671.pdf

[150] Sompolinsky, Y., Zohar, A.: Bitcoin’s security model revisited(2016), http://arxiv.org/pdf/1605.09193.pdf, accessed: 2016-07-04

[151] Sonnino, A., Bano, S., Al-Bassam, M., Danezis, G.: Replayattacks and defenses against cross-shard consensus in shardeddistributed ledgers. arXiv preprint arXiv:1901.11218 (2019)

[152] Spoke, M., Nuco Engineering Team: Aion: The third-generation blockchain network. https://aion.network/media/2018/03/aion.network technical-introduction en.pdf, accessed 2018-04-17

[153] Stewart, I.: Proof of burn (2012), https://en.bitcoin.it/wiki/Proofof burn, accessed: 2017-05-10

[154] Stifter, N., Schindler, P., Judmayer, A., Zamyatin, A., Kern, A.,Weippl, E.: Echoes of the past: Recovering blockchain met-rics from merged mining. In: Proceedings of the 23nd Inter-national Conference on Financial Cryptography and Data Secu-rity (FC). Springer (2019), https://fc19.ifca.ai/preproceedings/41-preproceedings.pdf

[155] Syta, E., Jovanovic, P., Kogias, E.K., Gailly, N., Gasser, L.,Khoffi, I., Fischer, M.J., Ford, B.: Scalable bias-resistant dis-tributed randomness. In: 2017 IEEE Symposium on Security andPrivacy (SP). pp. 444–460. Ieee (2017)

[156] Sztorc, P.: Blind merged mining. http://www.truthcoin.info/blog/blind-merged-mining/, accessed 2018-04-17

[157] Tairi, E., Moreno-Sanchez, P., Maffei, M.: A2l: Anonymousatomic locks for scalability and interoperability in payment chan-nel hubs. Cryptology ePrint Archive, Report 2019/589 (2019),https://eprint.iacr.org/2019/589

[158] Teutsch, J., Reitwießner, C.: A scalable verification solutionfor blockchains (March 2017), https://people.cs.uchicago.edu/∼teutsch/papers/truebit.pdf, accessed:2017-10-06

[159] Teutsch, J., Straka, M., Boneh, D.: Retrofitting a two-way peg be-tween blockchains. Tech. rep. (2018), https://people.cs.uchicago.edu/∼teutsch/papers/dogethereum.pdf

[160] Thomas, S., Schwartz, E.: A protocol for interledger payments.URL https://interledger. org/interledger. pdf (2015)

[161] Verdian, G., Tasca, P., Paterson, C., Mondelli, G.: Quantoverledger whitepaper. https://www.quant.network/wp-content/uploads/2018/09/Quant Overledger Whitepaper-Sep.pdf (2018)

[162] Vukolic, M.: Eventually returning to strong con-sistency (2016), https://pdfs.semanticscholar.org/a6a1/b70305b27c556aac779fb65429db9c2e1ef2.pdf, accessed: 2016-08-10

[163] Wood, G.: Polkadot: Vision for a heterogeneous multi-chainframework. White Paper (2015)

[164] Wood, G.: Ethereum: A secure decentralised generalised trans-action ledger eip-150 revision (759dccd - 2017-08-07) (2017),https://ethereum.github.io/yellowpaper/paper.pdf, accessed: 2018-01-03

[165] Yao, A.C.C.: How to generate and exchange secrets. In: 27thAnnual Symposium on Foundations of Computer Science (sfcs1986). pp. 162–167. IEEE (1986)

[166] Yousaf, H., Kappos, G., Meiklejohn, S.: Tracing transactionsacross cryptocurrency ledgers. In: 28th {USENIX} Security Sym-posium ({USENIX} Security 19). pp. 837–850 (2019)

[167] Yu, M., Sahraei, S., Li, S., Avestimehr, S., Kannan, S., Viswanath,P.: Coded merkle tree: Solving data availability attacks inblockchains. arXiv preprint arXiv:1910.01247 (2019)

[168] Zamani, M., Movahedi, M., Raykova, M.: Rapidchain: A fastblockchain protocol via full sharding. Cryptology ePrint Archive,Report 2018/460 (2018), https://eprint.iacr.org/2018/460.pdf

[169] Zamyatin, A., Harz, D., Lind, J., Panayiotou, P., Gervais, A.,Knottenbelt, W.: Xclaim: Trustless, interoperable, cryptocurrency-backed assets. IEEE Security and Privacy. IEEE (2019)

[170] Zamyatin, A., Harz, D., Lind, J., Panayiotou, P., Gervais, A.,Knottenbelt, W.J.: Multisignatures for cryptocurrency-backed to-kens (poster). CBT’18: International Workshop on Cryptocurren-cies and Blockchain Technology (2018)

[171] Zamyatin, A., Perez-Hernandez, D., Harz, D.: Snark-relay: To-wards bitcoin transaction inclusion proofs via zksnark (2019),https://github.com/dec3ntral/snark-relay

[172] Zamyatin, A., Stifter, N., Judmayer, A., Schindler, P., Weippl,E., Knottebelt, W.J.: (Short Paper) A Wild Velvet Fork Ap-pears! Inclusive Blockchain Protocol Changes in Practice. In:5th Workshop on Bitcoin and Blockchain Research, FinancialCryptography and Data Security 18 (FC). Springer (2018), https://eprint.iacr.org/2018/087.pdf

[173] Zindros, D.: Summa proofs are not composable (2019),https://medium.com/@dionyziz/summa-proofs-are-not-composable-57b87825f428