Cross-chain Deals and Adversarial Commerce

Modern distributed data management systems face a new challenge: how can autonomous, mutually-distrusting parties cooperate safely and effectively? Addressing this challenge brings up questions familiar from classical distributed systems: how to combine multiple steps into a single atomic action, how to recover from failures, and how to synchronize concurrent access to data. Nevertheless, each of these issues requires rethinking when participants are autonomous and potentially adversarial. We propose the notion of a \emph{cross-chain deal}, a new way to structure complex distributed computations in an adversarial setting. Deals are inspired by classical atomic transactions, but are necessarily different, in important ways, to accommodate the decentralized and untrusting nature of the exchange. We describe novel safety and liveness properties, along with two alternative protocols for implementing cross-chain deals in a system of independent blockchain ledgers. One protocol, based on synchronous communication, is fully decentralized, while the other, based on eventually-synchronous communication, necessarily requires stronger trust assumptions.


Introduction
Today's distributed data management systems face a new and daunting challenge: enabling commerce among autonomous parties who do not know or trust one another, a model we call adversarial commerce.
In classical distributed systems, participating parties are trusted to behave properly; parties may be implemented as replica groups if necessary to mask crashes and Byzantine failures, and thus ensure trust is warranted.e computations are o en organized as atomic transactions that ensure, for example, that transactions appear to run in one-at-a-time order, taking e ect either everywhere or nowhere.Computation is directed by a trusted coordinator, and executed by parties that can be trusted to follow directions.
By contrast, in adversarial commerce each party decides for itself whether to participate in a particular interaction.Because parties are autonomous, they cannot be forced to run common hardware or so ware.Instead, they agree only to follow a common protocol, an agreement that can be monitored, but not enforced.Correctness is local and sel sh: the common protocol should guarantee that all parties that follow the protocol end up "no worse o " than when they started, even in the presence of faulty or malicious behavior by other parties.Examples of adversarial commerce include securities trading, digital asset management, the Internet of ings, supply chain management, and, of course, cryptocurrencies.
Speci cally, we consider a system consisting of a collection of autonomous parties, where each party controls some set of assets.Parties may exchange assets among themselves in complex ways for mutual bene t (see the example below).Each asset is tracked on a replicated, distributed, tamperproof ledger called a blockchain.Our model is agnostic about the particular algorithms and data structures underlying the blockchains, requiring only that they operate correctly, and are capable of running simple programs known as contracts (sometimes "smart contacts").
is paper makes the following contributions.
• We propose the notion of a cross-chain deal, a new computational abstraction for structuring complex distributed exchanges in an adversarial se ing.Deals are inspired by classical atomic transactions, but differ, in essential ways, to accommodate the autonomous and potentially adversarial nature of the parties.• e well-known ACID correctness properties of atomic transactions must be rethought and reformulated for adversarial commerce.We de ne new safety and liveness properties appropriate for interactions among mutually-untrusting autonomous parties.
• We describe two new protocols for implementing cross-chain deals.A fully-decentralized timelock protocol assumes a synchronous communication model.We then argue that no fully decentralized protocol can tolerate periods of communication asynchrony.
Our certi ed blockchain (CBC) protocol does not rely on synchrony.It is based on two-phase commit but di ers in interesting ways.
• We provide an analysis of the resource costs of the two protocols.Given the immature state of today's blockchain technology, we focus on inherent, abiding, platform-independent trade-o s and costs rather than explicit performance measurements.
Speci c blockchains and blockchain-like mechanisms may rise or fall, but the need for adversarial commerce is here to stay.Future distributed data management systems will be expected to operate in such a world, and the time has come to examine how such computations can be de ned, speci ed, and implemented.In several key ways, deals in adversarial commerce are di erent from atomic transactions.Nevertheless, the two concepts serve the same high-level purpose of allowing clients to compose complex computations from simpler ones in a safe and well-structured way.

Example
Alice is a ticket broker.She buys tickets at wholesale prices from event organizers and resells them at retail prices to consumers, collecting a modest commission.Alice lives in the future, where tickets are managed on a ticket blockchain, a tamper-proof replicated ledger that tracks ticket ownership.Similarly, the coins paid for those tickets live on a distinct coin blockchain.Both blockchains support contracts, simple programs that control when and how ownership of tickets and coins is transferred.
One day, Bob, a theater owner, decides to sell two coveted tickets to a hit play for 100 coins.Alice knows that Carol would be willing to pay 101 coins for those tickets, so Alice moves to broker a deal between Bob and Carol.
Alice's task is to devise a distributed protocol, executed by Alice, Bob, and Carol, communicating through contracts running on various blockchains, to execute a cross-chain deal that transfers the tickets from Bob to Carol, and the coins from Carol to Bob, minus Alice's commission.If all goes as planned, all transfers take place, and if anything goes wrong (someone crashes or tries to cheat), no honest party should end up worse o .E.g., Alice does not want to end up holding tickets she can't sell or coins that she must refund.
As discussed in Section 8, Alice, Bob, and Carol's deal cannot be executed as an atomic cross-chain swap, the focus of much prior work [10,11,17,26,32,33,42].In a cross-chain swap, each party transfers an asset directly to another, and halts.In this example, however, Alice enters the deal with no assets to swap: her value is to act as a broker between Bob and Carol, which requires more complex indirect transfers.While cross-chain swaps can be considered a special case of cross-chain deals, cross-chain deals can be substantially more exible and powerful.

Cross-Chain Deals
Here we de ne cross-chain deals and how to execute them.), where each row and column is labeled with a party, and the entry at row i and column j shows the assets to be transferred from party i to party j.A party's column states what it expects to acquire from the deal (its incoming assets), and its row states what it expects to relinquish (its outgoing assets).A party enters a deal if the proposed transfers leave it be er o , and it agrees to commit (complete) the deal if it deems the actual outcome to be at least as good as the agreed-upon deal.
In our example, the deal is given by the 3 × 3 matrix in Figure 1.Carol expects to transfer 101 coins to Alice in return for tickets transferred from Alice.Similarly, Bob expects to transfer tickets to Alice in return for 100 coins from Alice.Although the gure refers only to "tickets", the speci c (nonfungible) tickets to be provided would be part of the deal speci cation, while the speci c (fungible) coins would likely be omi ed.

Deal Protocols
Parties to a deal carry out a protocol to complete the deal's transfers.In an environment where parties can fail or cheat, no protocol can guarantee that all transfers take place as promised by the deal speci cation.Which kind of partial transfers should be deemed acceptable?
Instead of distinguishing between faulty and non-faulty parties, as in classical models, we distinguish only between compliant parties who follow the protocol, and deviating parties who do not.Many kinds of fault-tolerant distributed protocols require that some fraction of the parties be compliant.For example, proof-of-work consensus [30] requires a compliant majority, while most Byzantine fault-tolerant (BFT) consensus protocols require more than two-thirds of the participants to be compliant.For cross-chain deals, however, it seems prudent to make no assumptions about the number of deviating parties.
Our classi cation of parties into compliant and deviating is partly inspired by the classi cation in the BAR model [2], which identi es parties as rational, altruistic, or Byzantine.In adversarial commerce, compliant parties are rational parties that decide to follow the protocol; all others are deviating, whether rational or not.ere are no altruistic parties.Critically, our classi cation di ers from that of BAR (and other standard models of Byzantine behavior) by not limiting the number of Byzantine parties.e most fundamental safety property is (informally) that compliant parties should end up "no worse o ", even when other parties deviate arbitrarily from the protocol.A crosschain deal protocol satis es safety if: Property 1.For every compliant party X , • If any of X 's outgoing assets is transferred, then all of X 's incoming assets are transferred.• If any of X 's incoming assets is not transferred, then none of X 's outgoing assets is transferred.
e rst condition states that if a compliant party ends up paying anything, it gets everything.e second condition states that if a compliant party ends up not receiving something, it pays nothing.
is notion of safety weakens the classical all-or-nothing property of atomic transactions.Safety permits the "all" outcome where every compliant party's incoming and outgoing assets are transferred, as well as the "nothing" outcome where no compliant party's assets are transferred.However, safety also permits outcomes where a compliant party pays nothing but receives assets from deviating parties, or pays less than expected for its incoming assets.Such outcomes, while unlikely in practice, cannot be ruled out because we cannot constrain the behavior of potentially-irrational deviating parties.
Cross-chain task protocols typically rely on some form of escrow to ensure the good faith of participating parties.e following weak liveness property ensures that conforming parties' assets cannot be locked up forever.Property 2. No asset belonging to a compliant party is locked up forever.
Finally, we would like protocols to satisfy the following strong liveness property: Property 3. If all parties are compliant, all transfers happen.
In general, strong liveness is possible only in periods when the communication network is synchronous, ensuring a xed upper bound on message delivery time.

System Model
For our purposes, a blockchain is a publicly-readable, tamperproof distributed ledger (or database) that tracks ownership of assets among various parties.An asset may be fungible, like a sum of money, or non-fungible, like a theater ticket.A party can be a person, an organization, or even a contract (see below).We assume multiple independent blockchains, each managing a di erent kind of asset.We restrict our a ention to blockchains that track asset ownership, and to deals that transfer asset ownership from one party to another.We assume all value transfers are explicitly represented on the blockchain.For example, Alice does not send paper tickets to Carol o -chain.
A party can publish an entry on a blockchain, and it can monitor one or more blockchains, receiving noti cations when other parties publish entries.In our model, publishing an entry usually executes a blockchain-resident program called a contract.We will use contracts for escrow: an asset owner temporarily transfers ownership of an asset to a contract.If certain conditions are met, the contract transfers that asset to a counterparty, and otherwise it refunds that asset to the original owner.
A party can publish a new contract on a blockchain, or call a function exported by an existing contract.Contract code and contract state are public, so a party calling a contract knows what code will be executed.Contracts are typically re-executed multiple times by mutually-suspicious parties checking up on one another, so contract code must be deterministic.A contract can access any data on the blockchain where it resides, or call other contracts on that blockchain, but it cannot directly access data from the outside world, and cannot call contracts on other blockchains.e only way a contract on blockchain A can learn of a change to a remote blockchain B is if some party explicitly informs the contract at A of B's change.Naturally, the contract on A will typically require some kind of "proof" that any information o ered about B's state is correct.
In summary, adversarial commerce encompasses two distinct kinds of agents: contracts and parties.Contract code resides publicly on a blockchain.It is deterministic and trusted.It is also passive, executed only when called by active parties.
e parties are active, autonomous, and mutually untrusting.ey are given a protocol, which each party may or may follow.Parties may be rational, following their own interests, or they may be irrational, departing from the protocol even when it is not in their interests to do so [2].
We assume each party has a public key and a private key, and that any party's public key is known to all.

Executing Cross-Chain Deals
Escrow plays the role of classical concurrency control, ensuring that a single asset cannot be transferred to di erent parties at the same time.Here we specify what happens when assets are put into escrow, and how ownership of escrowed assets transferred.
ere is a domain of parties P, and a domain of assets A. (A party may be a person or a contract, and assets are digital tokens representing items of value.)An asset can have only one owner at a time: we say that Owns(P, a) is true if P owns a and no other party owns a.
A deal is executed as a cross-chain protocol.As the protocol runs, assets are tentatively transferred from one party to another.If the deal execution commits at an asset's blockchain, that asset becomes the property of the transfer target, while if the deal execution aborts at that blockchain, that asset is refunded to its original owner.Commi ing or aborting is local to each asset's blockchain.
We represent the state of an active deal by two maps C : A → P and A : A → P, both initially empty.C(a) indicates the eventual owner of asset a if the deal commits at a, and A(a) if it aborts at a. We say Owns C (P, a) to indicate that P will own a if the deal commits, and Owns A (P, a) to indicate that P would own a if the deal aborts.Now we de ne what happens when an asset is placed in escrow by P during deal D.
Pre: Owns(P, a) Post: Owns(D, a) and Owns C (P, a) and Owns A (P, a) e precondition states that P can escrow A only if P owns a.If the precondition is satis ed, the postcondition states that ownership of a is transferred from P to D (via the escrow contract), but P remains the owner of a in both C and A, since no tentative transfer has happened yet, so P would regain ownership of a if D were to terminate either way.For example, when Bob escrows his tickets, they become the property of the contract, but should the deal terminate right then, the tickets would revert to Bob.
Next we de ne what happens when party P tentatively transfers an asset a to party Q as part of deal D.
Pre: Owns(D, a) and Owns C (P, a) e precondition requires a to be held in escrow by D, with P the indicated owner should D commit.If the precondition is satis ed, the postcondition states that Q will become the owner should D commit (at this point).For example, when Bob transfers his tickets to Alice, Alice becomes the owner of those tickets in C.
Assets remain in escrow until the deal terminates.If it terminates by commi ing, the owners of assets in C become the actual owners (displacing D).If it terminates by aborting, the owners of assets in A become the actual owners (again displacing D).

Phases
A deal is executed in the following phases.
Clearing: A market-clearing service discovers and broadcasts the participants, the proposed transfers, and possibly other deal-speci c information.e market clearing service may be centralized, but need not be trusted, because each party decides for itself whether to participate.e precise structure of the service is beyond the scope of this paper.
Escrow: Parties escrow their outgoing assets.For example, Bob escrows his tickets and Carol her coins.
Transfer: e parties perform the sequence of ownership transfers according to the deal.For example, Bob transfers the tickets to Alice, who subsequently transfers them to Carol.
Validation: Once the tentative transfers are complete, each party checks that its incoming assets are properly escrowed (so they cannot be double-spent), and that the trade-o between the incoming and outgoing assets is satisfactory.For example, Carol checks that the tickets to be transferred are escrowed, that the seats are (at least as good as) the ones agreed upon, and that she did not somehow overpay.
Commit: e parties vote on whether to make the tentative transfers permanent.If all parties vote to commit, the escrowed assets are transferred to their new owners; otherwise those assets are refunded to their original owners.
In the classical two-phase commit protocol [8], validation usually requires no semantic checks; instead a party agrees to prepare if appropriate locks are held and persistence is guaranteed.Under adversarial commerce, however, an application-speci c validation phase is needed for each party to decide whether the tentative nal state is satisfactory.For example, only Carol can decide whether the tickets she is about to purchase are ones she wants.
Cross-chain deals rely on two critical, intertwined mechanisms.First, the escrow mechanism prevents double-spending by making the escrow contract itself the asset owner.Care must be taken that assets belonging to compliant parties do not remain escrowed forever in the presence of malicious behavior by counterparties.Second, the commit protocol must be resilient in the presence of malicious misbehavior.A deviating party may be able to steal assets if it can convince some parties that the deal completed successfully, and others that it did not.If a deviating party can prevent (or delay) a decision by the commit protocol, then it can keep assets locked up forever (or a long time).
e principal challenge in implementing cross-chain deal protocols is the design of the integrated escrow management and commit protocol.Just as with classical transaction mechanisms, there are many possible choices and trade-o s.In the remainder of this paper, we describe two cross-chain deal protocols, implemented via contracts, one for the synchronous timing model, and one for the eventually-synchronous model, each making di erent trust assumptions.

Timelock Commit Protocol
We now describe a timelock commit protocol where escrowed assets are released if all parties vote to commit.Parties do not explicitly vote to abort.Instead, timeouts are used to ensure that escrowed assets are not locked up forever if some party crashes or walks away from the deal. is protocol assumes a synchronous network model where there is a known upper bound ∆ on the time needed to change any blockchain's state in a way observable by all parties.
In our example, Bob places his tickets into escrow, then transfers them to Alice, who transfers them to Carol.All parties examine their incoming assets, and if those assets are satisfactory, the parties vote to commit at the escrow contract on each asset's blockchain.For example, if Alice, Bob, and Carol all register commit votes on the ticket blockchain, the escrow contract releases the tickets to Carol.All votes are subject to timeouts: if any commit vote fails to appear before the contract's timeout expires, the tickets revert to Bob. (Symmetric conditions apply to Carol's coins.) Because of the adversarial nature of a deal, each party is motivated to publish its vote on the blockchains controlling its incoming assets (it is eager to be paid), but not on the blockchains controlling its outgoing assets (it is not so eager to pay).To align the protocol with incentives, one party's commit vote may be forwarded from one escrow contract to another by a motivated party.
For example, Bob is motivated to publish his commit vote only on the coin blockchain.However, once published, Bob's vote becomes visible to Carol, who is motivated to forward that vote to the ticket blockchain.Carol's position is symmetric: she is motivated to publish her vote only on the ticket blockchain, but Bob is motivated to forward it to the coin blockchain.Alice is motivated to send her vote to both blockchains.(Nevertheless, no harm occurs if a party sends its commit vote directly to any contract.) A tricky part of this protocol is how to choose timeouts.Simply assigning each party a timeout for each asset is incorrect, as shown by the following example.
Suppose that the ticket and coin escrows assign Alice timeouts A t and A c respectively, and that Bob and Carol's commit votes have already been published on both blockchains.In one scenario, Alice waits until just before A c to register her vote on the coin blockchain, unlocking Carol's payment to Bob.It may take time ∆ for Carol to observe Alice's vote and forward it to the ticket blockchain, implying that A t ≥ A c +∆.In another scenario, Alice waits until just before A t to register her vote on the ticket blockchain, unlocking Bob's tickets for Carol.It may take time ∆ for Bob to observe Alice's vote and forward it to the coin blockchain, implying that A c ≥ A t + ∆, a contradiction.
To resolve this dilemma, each escrow contract's timeout for a party's commit vote depends on the length of the path along which that vote was forwarded.For example, if Alice votes directly, her vote will be accepted only if it is received within ∆ of the commit protocol's starting time. is vote must be signed by Alice.If Alice forwards a vote from Bob, that vote will be accepted only if it is received within 2 • ∆ of the starting time, where the extra ∆ re ects the worst-case extra time needed to forward the vote. is vote must be signed rst by Bob, then Alice.Finally, if Alice forwards a vote that Bob forwarded from Carol, that vote will be accepted only if it is received within 3 • ∆, and so on.is vote must be signed rst by Carol, then Bob, then Alice.We refer to this chain of signatures as the vote's path signature.
In general, a vote from party X received with path signature p must arrive within time |p| • ∆ of the pre-established commit protocol starting time, where |p| is the number of distinct signatures for that vote.
Clearing Phase: e market-clearing service broadcasts the following to all parties in the deal: the deal identi er D, the list of parties plist, a commit phase starting time t 0 used to compute timeouts, and the timeout delay ∆.Most blockchains measure time imprecisely, usually by multiplying the current block height by the average block rate.e choice of t 0 should be far enough in the future to take into account the time needed to perform the deal's tentative transfers, and ∆ should be large enough to render irrelevant any imprecision in blockchain timekeeping.Because t 0 and ∆ are used only to compute timeouts, their values do not a ect normal execution times, where all votes are received in a timely way.If deals take minutes, then ∆ could be measured in hours.
Escrow Phase: Each party places its outgoing assets in escrow through an escrow contract escrow(D, Dinfo, a).
on that asset's blockchain.Here D is the deal identi er and Dinfo is the rest of the information about the deal (plist, t 0 , and ∆); the escrow requests takes e ect only if the party is the owner of a and a member of the plist.
Transfer Phase: Party P transfers a subset a of asset a tentatively owned by P to party Q by sending transfer(D, a, a , Q).
to the escrow contract on the asset's blockchain.e party must be the owner of a and Q must be in the plist.
Validation Phase: Each party examines its escrowed incoming assets to see if they are satisfactory and the deal information is correct.If so, the party votes to commit.
Commit Phase: Each compliant party sends a commit vote to the escrow contract for each incoming asset.(A complaint party is free to altruistically send commit votes to other escrow contracts as well.)A party uses commit(D, , p) to vote directly and to forward votes to the deal's escrow contracts, where is the voter and p is the path signature for 's vote.(Since D is e ectively a nonce, nothing extra is needed to guard against replay a acks.) A contract accepts a commit vote only if it arrives in time and is well-formed: all parties in the path signature are unique and in the plist, and their signatures are valid and a est to a vote from oter .If the commit is accepted, that contract has now accepted a vote from the party.
A contract releases the escrowed asset to the new owner(s) when it accepts a commit vote from every party.If the contract has not accepted a vote from every party by time where N is the number of parties, it will never accept the missing votes, so the contract times out and refunds its escrowed assets to the original owners.

Well-formed Deals and Decentralization
For ease of exposition, we can think of a deal as a directed graph (digraph), where each vertex represents a party, and each arc represents a transfer; the digraph for our deal is shown in Figure 2.
If the deal digraph is not strongly connected, it can be shown that the deal is not well-formed, in the sense that it must include one or more "free riders" that collectively take assets but do not return any [26].e remaining parties have no incentive to conform to any protocol executing such a deal, because they could improve their payo s by excluding the free riders 1 .
A compliant party rst sends votes to the escrow contracts on its incoming assets' blockchains.
en it monitors its outgoing assets' blockchains and forwards other parties' votes to its incoming assets' blockchains.No party needs to interact with any other blockchains.For example, if Carol owns only altcoins, then as part of the deal, she can go to David to exchange her altcoins for coins, and the deal can commit without parties such as Bob needing to interact with the altcoin blockchain (or even know about it). is protocol is decentralized in the sense that there is no single blockchain that must be accessed by all compliant parties. is voting protocol re ects the (incentive-compatible) minimum a compliant party must do.Nothing prevents compliant parties from sending their commit votes directly to arbitrary blockchains.For example, Bob might send his vote directly to the ticket blockchain, perhaps hoping to speed up the commit process.If he does so, he passes up a (very unlikely) opportunity to cheat Carol if she (non-compliantly) fails to claim her tickets in time.
In the remainder of this section, we assume that deals are well-formed, and the corresponding digraphs are strongly connected, although our timelock protocol can handle illformed deals if needed. 1 Perhaps the free riders are sending some kind of hidden o -chain payments to the other parties, but support for hidden payments is beyond this paper's scope.Proof.Suppose by way of contradiction that compliant party X 's outgoing asset a is released from escrow and transferred (with commit votes from every party), but the escrow for X 's incoming asset b times out and is refunded because of a missing vote from party Z .Suppose Z 's commit vote at a's contract arrived with path signature p. e signatures in p cannot include X 's, because X is compliant and would have already forwarded Z 's vote to b. Z 's vote must have arrived at a before time t 0 + |p| •∆.Since X is compliant, it forwards that vote to b's contract along path Xp, before time t 0 +(|p| +1)•∆, where that vote is accepted, a contradiction.eorem 5.2.e timelock protocol satis es weak liveness: no compliant party's outgoing assets are locked up forever.
Proof.Every escrow created by a compliant party has a nite timeout.eorem 5.3.e timelock protocol satis es strong liveness.
Proof.If all parties are compliant, they all send commit votes to the escrow contracts for their incoming assets.Each time a new commit vote appears on an outgoing asset's contract, the party forwards it to its incoming assets' contracts.Since the deal is well-formed, the deal digraph is strongly connected, and all commit votes are forwarded to all contracts in time.

Remarks
Like any synchronous-model protocol, ∆ must be chosen large enough to make denial-of-service a acks prohibitively expensive.Suppose that Bob acquires Alice and Carol's votes on time, and forwards them to claim the coins, but Alice and Carol are driven o ine before they can forward Bob's vote to the ticket blockchain, so Bob ends up with both the coins and the tickets.Technically, this outcome is correct because Alice and Carol have deviated from the protocol by not claiming their assets in time.Indeed, any timelock-based commit protocol has a window during which parties may lose their assets by going o ine at the wrong time.To address a similar risk, the Lightning payment network [35] employs watchtowers [13], parties that monitor escrow contracts and step in to act on the behalf of o -line parties in danger of losing assets.

Certi ed Blockchain Commit Protocol
Now we describe a commit protocol that does not rely on network synchrony.More precisely, we adopt the semisynchronous communication model [18], where the network starts out asynchronous, with no bound on message delivery times, but eventually reaches a global stabilization time (GST) where message delivery delays become bounded 2 .With this model we can no longer handle aborts by depending on bounded timeouts for escrow, so instead we allow parties to vote to abort as well as to commit: they vote to commit if validation succeeds, and they vote to abort if validation fails, or if too much time has passed.
e protocol is motivated by the classical two-phase commit protocol [8], but di ers in some interesting ways.In particular, there is no coordinator; instead we use a special blockchain, the certi ed blockchain, or CBC, as a kind of shared log.e CBC might be an additional blockchain or one of those already being used in the deal.
Instead of voting to commit transfers of individual assets, as in the timelock protocol, each party votes on the CBC whether to commit or abort the entire deal.e CBC serves to record and order these votes.A party can extract a proof from the CBC that particular votes were recorded in a particular order.A party claiming an asset (or a refund) presents a proof of commit (or abort) to each contract managing that asset.e contract checks the proof's validity and carries out the requested commit or abort if the proof is valid.A proof of commit proves that every party voted to commit the deal before any party voted to abort.A proof of abort proves that some party voted to abort the deal before every party voted to commit.A party can rescind an earlier commit vote by voting to abort (for example, if the deal is taking too long to complete).To ensure strong liveness, once a compliant party has voted to commit, it must wait time at least ∆ before rescinding that vote.
Recall that a commit protocol is decentralized if there is no single blockchain accessed by all parties in any execution.e CBC protocol is not decentralized in this sense, because the CBC itself is a centralized "whiteboard" shared by all parties.is loss of decentralization is inevitable: no protocol that tolerates periods of asynchrony can be decentralized.A formal proof is out of scope, but we sketch an informal argument adapted from Fischer, Lynch, and Paterson [21].If all parties are compliant, then if the deal commits (resp.aborts) at any asset's blockchain, it must commit (resp.abort) at all of them.Initially, the deal's state is bivalent: both commit and abort are possible outcomes.But the deal's state cannot remain bivalent forever, so it must be possible to reach a (bivalent) critical state where each party is about to take a decisive step that will force the protocol to enter a univalent state where either a commit outcome or an abort outcome becomes inevitable.A potentially decisive step forcing an eventual commit cannot take place at a di erent blockchain than a potentially decisive step forcing an eventual abort, because then it would be impossible to determine which happened rst, hence which one was truly decisive.It follows that in any such critical state, all parties must be about to call the same contract, violating decentralization. 2 In practice, we require only that the synchronous periods last "long enough" to complete the deal.
Here are the phases of the CBC protocol.A discussion of what proofs are like appears in Section 6.2.
Clearing Phase: e market-clearing service broadcasts a unique identi er D and a list of participating parties plist (this protocol does not require the t 0 starting time nor ∆).One party records the start of the deal on the CBC by publishing an entry: startDeal(D, plist).
e calling party must appear in the plist.If more than one startDeal for D is recorded on the CBC, the earliest is considered de nitive.
Escrow Phase: Each party places its outgoing assets in escrow: escrow(D, plist, h, a, . ..) Here, h is the hash of the startDeal that started the deal; the hash is needed in case there is more than one such entry on the CBC.e ellipsis indicates arguments that vary depending on the algorithm used to implement the CBC, as discussed in Section 6.2.As in the timelock protocol, the sender must be the owner of asset a and a member of the plist.
Transfer Phase: Party P transfers a subset a of asset a tentatively owned by P to party Q by sending transfer(D, a, a , Q).
to the escrow contract on the asset's blockchain.P must be the owner of a and Q must be in the plist.
Validation Phase: As before, each party checks that its incoming assets are satisfactory and properly escrowed with the correct plist and h.
Commit Phase: Each party X publishes either a commit or abort vote for D on the CBC: where D is the deal identi er, and h is the startDeal.As usual, each voter must be in the start-of-deal plist.

Correctness
e correctness of the CBC protocol is mostly self-evident: safety is satis ed because a deal either commits everywhere or aborts everywhere, weak liveness is satis ed because any compliant party whose assets are locked up for too long will eventually vote to abort, and strong liveness is satis ed in periods when the network is synchronous because every compliant party votes to commit before any compliant party votes to abort.

Cross-Chain Proofs
e CBC acts as a shared log visible to all parties, allowing parties to determine which commit or abort votes were registered, and, importantly, the order in which they were registered.e decisive vote is the one that determines whether the deal commits or aborts.However, it is not enough to convince active parties that a deal commi ed or aborted; it is also necessary to convince passive contracts on various blockchains so they will correctly transfer or refund escrowed assets.
A straightforward approach is to present each contract with a subsequence of the CBC's blocks, starting with the initial block containing the deal's rst startDeal record, and ending with block containing the decisive vote.But how can we be sure that the blocks presented are really on the CBC? e answer depends partly on the kind of algorithm underlying the CBC blockchain.
Byzantine Fault-Tolerant Consensus: Let us assume the CBC relies on Byzantine fault-tolerant (BFT) consensus [1,4,12,38].Blocks are approved by a known set of 3f + 1 validators, of which at most f can deviate from the protocol.( e details of how validators reach consensus on new blocks are not important here.)To support long-term fault tolerance, the blockchain can be recon gured periodically by having at least 2f + 1 current validators elect a new set of validators.BFT protocols guarantee safety even when communication is asynchronous.ey ensure liveness when communication becomes synchronous a er the GST.
Each block in a BFT blockchain is vouched for by a certicate containing at least 2f + 1 validator signatures of that block's hash.If the block contains an entry that identi es 3f + 1 new validators along with their public keys, the new validators will be in charge of the next block.e sequence of blocks and their certi cates can be used as a proof.e contract on the asset blockchain will be able to check this proof as long as it knows the rst block's set of validators.
is is accomplished by passing the 3f + 1 validators of the initial block as an extra argument to each of the deal's escrow contracts (in place of the ellipses).Parties must provide the correct validators when pu ing assets in escrow, and they must check their correctness before voting to commit.
Checking the proof as just described is a lot of work; the proof is likely to be spread over many blocks, each containing a large number of entries.Furthermore, we cannot shorten the proof by having the party tell the contract which entries to look at, since that would allow a malicious party to fool a contract into making a wrong decision.But there are many ways to make BFT proofs more e cient.
A straightforward optimization is to take advantage of the fact that the CBC has validators.
is allows the parties to request certi cates from the CBC.Such a certi cate would vouch for the current state of the deal (active, commi ed, aborted).is certi cate alone would be enough of a proof provided the validators haven't changed since the deal started; otherwise the party must also provide the chain of validators.
Proof-of-work (Nakamoto) Consensus: Proofs of commit or abort generated by a CBC implemented using proof-ofwork consensus (like Bitcoin [30] or Ethereum [19]) are possible, but such blockchains lack nality: any proof might be contradicted by a later proof, although producing a later, contradictory proof becomes more expensive to the adversary the longer it waits.
Here is a scenario where Alice can construct a fake "proof of abort" for a proof-of-work CBC.As soon as the deal execution starts, Alice (perhaps aided by partners in crime) privately mines a block that contains an abort vote from Alice.When her part of the deal is complete, however, Alice publicly sends a commit vote to the CBC.If, by the time all parties have voted commit, Alice was able to mine a private abort block, then Alice can use that fake proof of abort to halt outgoing transfers of her assets, while using the legitimate proof of commit to trigger incoming transfers.
In the spirit of proof-of-work, this a ack can be made more expensive by requiring a proof of commit or abort to include some number of con rmation blocks beyond the one containing the decisive vote, forcing Alice to outperform the rest of the CBC's miners for an extended duration.To deter rational cheaters, the number of con rmations required should vary depending on the value of the deal, implying that high-value deals would take longer to resolve than lowervalue deals.
To summarize, while it is technically possible to produce commit or abort proofs from a proof-of-work CBC, the result is likely to be slow and complex.In the same way a proofof-work blockchain can fork, a proof-of-work proof can be contradicted by by a later proof.Similarly, to make the production of contradictory proofs expensive, the proof's di culty must be adjusted to match the value of the assets transferred by the deal.By contrast, a BFT certi cate of commit or abort is nal, and independent of value of the deal's assets.

Cost Analysis
is section analyzes the costs associated with each of the protocols.We use a cost structure inspired by that of the Ethereum [41] blockchain, since that is currently the bestdeveloped platform, but the costs on other blockchains are not likely to be radically di erent.
Consider a deal with n participating parties, m assets, and t ≥ m transfers.

Gas Costs
To make denial-of-service a acks prohibitively expensive, virtual machines that execute contracts typically charge for each instruction executed.In Ethereum [41], this charge  is expressed in terms of Gas units, whose value (in Ether, the Ethereum blockchain's native currency) varies according to demand.For example, the gas cost of simple arithmetic operations or accesses to short-lived memory is in single digits, and control ow or read operations from long-lived storage is in double or triple digits.In general, gas costs are dominated by two kinds of operations: writing to long-lived storage is (usually) 5000 gas, and each signature veri cation is 3000 gas.To illustrate our gas cost analysis, Figure 3 shows a fragment of a pseudocode implementation of a generic EscrowManager contract for a fungible asset, modeled as an ERC20-standard token [22].e heart of the EscrowManager contract is a pair of mappings: escrow records how many tokens each party has escrowed (Line 3), and onCommit records how many tokens each party would receive if the deal commits at this asset (Line 4).For clarity, some error checking has been omi ed.
Escrow phase: Each party calls the escrow function to escrow some number of tokens. is function incurs 2 storage writes (in a function call) to transfer the token from the sender to the escrow contract (Line 8), and 1 storage write each to update the escrow (Line 9) and the onCommit (Line 10) maps, for a total of 4 storage writes.Globally, the escrow phase incurs O(m) gas costs.
Transfer phase: Each party calls the transfer function to transfer some number of escrowed tokens to another party.
is function incurs 1 storage write to decrement the sender's tentative onCommit balance (Line 15), and another to increment the recipient's balance (Line 16).Globally, the transfer phase incurs O(t) gas costs.
Validation phase: Each party monitors its incoming and outgoing escrow contracts to ensure it is satis ed with the assets it is due to acquire and relinquish. is computation takes place entirely at the parties, and incurs no gas cost.Timelock protocol commit phase: Timelock escrow contracts verify commit path signatures.Note that signatures are generated by parties, not by contracts, so while signature generation incurs computation costs at parties, it incurs no gas costs at contracts.
Figure 5 shows a pseudocode fragment for a timelock escrow contract.e contract records the set of parties participating in the deal (Line 2) and which ones have voted (Line 2).e commit function takes as arguments the voter, the set of signers, and their signatures.It checks that the deal has not timed out (Line 6), that the voter is legitimate ).e expensive steps are verifying each of the signatures (Line 11), and recording the voter (Line 13) in long-lived storage.Each escrow contract veri es a vote from each of n parties, and each party's vote could have been signed by up to n others, yielding a worst-case per-contract bound of O(n 2 ) signature veri cations, plus a constant number of storage writes for other bookkeeping.Since there are m contracts, the timelock commit protocol incurs an O(mn 2 ) global gas cost.In the best case, a deal can abort with no signature veri cations, but in the worst case, aborting can cost almost as much as commi ing.
CBC protocol commit phase: Escrow contracts check proofs from the CBC by verifying that they are correctly signed by enough validators.Figure 6 shows a pseudocode fragment for an escrow contract for a CBC using an underlying BFT consensus protocol that tolerates f Byzantine validators.We assume the optimization where parties request status certi cates from the CBC; for brevity, we assume there have been no recon gurations.
e contract keeps track of the CBC's current set of validators (Line 2); it also knows their public keys.e commit function takes as arguments the set of signers and their signatures.It checks that there are no duplicate validators (Line 6), that all voters are validators (Line 7), and that there are enough votes (Line 8).e expensive step is verifying each of the validator signatures (Line 10); there will also be a constant number of storage writes to record the outcome and to update the escrow and ownership mappings.
Each contract veri es 2f + 1 signatures, or (k + 1)(2f + 1) if the set of validators has changed k times.e global gas cost is O(m(2f + 1)) signature veri cations plus a constant number of storage writes to update the escrow mappings.

Time Costs
We analyze each commit protocol's timing delays when the network is synchronous, with bound ∆ on the time needed both to change a blockchain state, and to have that change observed by any interested party.
For both protocols, if all parties are conforming, the escrow phase takes time at most ∆, since every party updates its outgoing assets' escrow contracts in parallel.Similarly, the transfer phase takes time at most t • ∆.It may be possible to execute transfers concurrently, in which case this phase takes time at most ∆. e validation phase takes time at most ∆, since each party must observe each escrow contract's most recent state.
Timelock protocol commit phase: If each party sends its commit vote only to the blockchains managing its incoming assets, then the worst-case duration of the commit phase is proportional to the longest sequence of transfers, which is bounded by n∆.If parties (altruistically) send their votes directly to all blockchains, then the bound is just ∆.
CBC protocol commit phase: All conforming parties send their votes to the CBC in parallel, and these votes are available very quickly when the CBC is executed using a BFT protocol such as PBFT [12]..It requires at most another ∆ for the escrow contracts to transfer or refund their assets.

Related Work
In a cross-chain swap [10,11,17,26,32,33,42], each party transfers an asset to another party and halts.Cross-chain swaps are a ractive because they reduce or eliminate the use of exchanges, some of which have proved to be untrustworthy [39,40].However, as noted, the three-way deal described in our example cannot be formulated as a swap because Alice starts with nothing to swap.She uses Carol's coins to buy Hashed timelocked contracts are o en used for cross-chain swaps [10,11,17,32,33].Herlihy [26] proposed a multi-party cross-chain swap protocol, based on hashed timelocked contracts.At the start, a subset of parties, called "leaders" generate secrets.First, the leaders publish their escrow contracts, and then followers do the same, as contract publication propagates through the swap digraph in a carefully-chosen order.In the next phase, a er all contracts are in place, the leaders release their secrets, also propagated through the digraph in a particular order.e timelock commit protocol presented here is has a simpler structure.By replacing secrets with votes, and by treating all parties uniformly, the timelock protocol eliminates the need for the careful contract deployment phase, and clari es when parties review the transactions nal outcome.Both commit protocols use timeout mechanisms based on path signatures.
O -chain payment networks [16,23,25,31,35] and state channels [15] use hashed timelock contracts to circumvent the scalability limits of existing blockchains.ey conduct repeated o -chain transactions, nalizing their net transactions in a single on-chain transaction.e use of hashed timelock contracts ensures that parties cannot be cheated if one party tries to se le an incorrect nal state.Like swaps and deals, payment channels require a synchronous communication model.Luu et al. [29] propose using (hardware) trusted execution environments to ease synchrony requirements.It remains to be seen whether trusted execution environments can be applied to adversarial deals.e authors are not aware of o -chain networks that support cross-chain swaps or deals.Arwen [25] supports multiple o -chain atomic swaps between parties and exchanges, but their protocol is specialized to currency trading and does not seem to support non-fungible assets.Komodo [33] supports o -chain cross-platform payments using a trusted intermediary.
Sharded blockchains [3,28] address scalability limits of blockchains by partitioning the state into multiple shards so that transactions on di erent shards can proceed in parallel, and support multi-step atomic transactions spanning multiple shards.An atomic transaction that spans multiple shards is executed at the client in Chainspace [3] , or at the server in Omniledger [28].In these systems a transaction represents a single trusted party and there is no support for transactions involving untrusted parties.
Chainspace [3] allows transactions to specify immutable proof contracts to be executed at the server.
e proofs are used to validate client execution traces resembling optimistic concurrency control.Channels [5], an extension of Omniledger Atomix protocols, uses proofs in a two-phase protocol similar to our CBC, for atomic untrusted cross-shard single-step multi-party UTXO [27] transfers, but does not support multi-step deals or non-fungible assets.
e BAR (byzantine, altruistic and rational) computation model [6,14] supports cooperative services spanning autonomous administrative domains that are resilient to byzantine and rational manipulations.Like Byzantine faulttolerant systems, BAR-tolerant systems assume a bounded number of Byzantine faults, and as such do not t the adversarial deal model, where any number of parties may be Byzantine.
A (blockchain) oracle [34] is a trusted data feed that reports physical-world occurrences to contracts.(For example, an early frost report might trigger an insurance payment to a farmer.)e CBC somewhat resembles an oracle, but instead of reporting on the outside world, it acts as an internal "whiteboard" shared by the parties.
An early precursor of adversarial commerce was the study of federated databases [36], which addressed the problem of coordinating and commi ing transactions that span multiple autonomous, mutually untrusting, heterogeneous data stores.An important challenge was to achieve cross-database serializable transactions where participants did not trust one another to release locks in a timely way.(Federated databases did not a empt to tolerate arbitrary Byzantine behavior.)

Discussion
Deals are not restricted to the unconditional transfers in our earlier ticket-brokering example.For example, Alice might auction a ticket as follows.Bob and Carol transfer their bids as coins to Alice, and Alice's contract compares the bids, and transfers back the losing bidder's coins and the ticket to the winning bidder. 3is deal, too, cannot be expressed as an atomic swap because Alice transfers assets she did not own at the start.
Deals can also be structured to provide incentives for good behavior.For example, to discourage maliciously joining then aborting deals, a party might escrow a small deposit that is lost if that party is the rst to cause the deal to fail.Designing and implementing such incentives is an area of ongoing research [20].
In the timelock commit protocol, if ∆ is chosen too small, parties may be vulnerable to an extended denial-of-service attack.In our example, if ∆ is chosen poorly, Bob, a er casting his vote to commit, might fall victim to a denial-of-service attack for longer than ∆, and may fail to claim his coins before they are refunded to Alice.ere is a similar threat to the CBC commit protocol, where the CBC itself might be the target of a denial of service a ack, causing a deal's assets to be locked up for the duration of the a ack.However, the CBC protocol ensures that the deal either commits everywhere or aborts everywhere; the timelock protocol does not.
A more subtle issue concerning the CBC commit protocol is that the parties must trust the CBC not to engage in censorship, where CBC validators selectively choose to ignore certain deals, causing them to abort when they could otherwise have commi ed. e threat of hard-to-prove censorship might present a challenge for mutually-untrusting parties to agree on a trustworthy CBC provider.
Some form of signature combining may reduce space costs in either commit protocol, although prior techniques [37] do not seem immediately applicable.
If we assume (reasonably) that 2f + 1, the number of compliant CBC validators usually exceeds n, the number of compliant parties, then it will usually be more expensive to commit a CBC deal (O(m(2f + 1))) than a timelock deal (O(mn 2 )).But one gets what one pays for: the CBC protocol works in a more demanding model.
10 Conclusions e emerging domain of adversarial commerce is a kind of fun-house mirror of classical distributed transactions: familiar features are recognizable, but distorted.We have proposed the notion of cross-chain deals to ll the ecological niche occupied by distributed atomic transactions, and we have proposed using escrow contracts and distributed blockchain-based commit protocols to play the role of classical concurrency control and the two-phase commit protocol.
Classical transactions are o en described in terms of the well-known ACID properties [24]: atomicity, consistency, isolation, and durability.Cross-chain deals are not classical transactions, and these classical notions of correctness must be rethought.
Classical atomicity means that all transfers take place, or none do.In adversarial commerce, where parties are autonomous and cooperation is voluntary, this global atomicity property becomes a local property: each conforming party ends up no worse o , no ma er how deviating parties behave.
Classical isolation guarantees that concurrent transactions cannot interfere, typically enforced via serializability or snapshot consistency.But serializability is a poor t for Alice, Bob, and Carol, independent, concurrently-executing parties who must interact with one another during the deal execution.In adversarial commerce, interference takes the form of double-spending: what if Bob somehow concurrently sells the same tickets to Carol and to someone else, collecting coins from both?Escrow contracts replace classical locks or snapshots, ensuring that ownership cannot unexpectedly change while a deal is being executed.
We believe that adversarial commerce, de ned as economic exchange among mutually untrusted autonomous parties, is here to stay.Moreover, a system architecture composed of autonomous untrusted parties that communicate via shared tamper-proof data stores is the most natural way to organize such a system.Although we sketched implementations of cross-chain deals using today's blockchains and smart contracts, none of our principal results depends on blockchains as such.We believe that the notion of a deal as a computational abstraction will be central to any systematic approach to adversarial commerce, no ma er what technology underlies the shared data stores.( ere are many technologies hoping to displace blockchains, e.g.[7,9]).e "sel sh" correctness conditions proposed here re ect the inherent challenges of cooperation among untrusting parties.Similarly, the centralization trade-o s explored here for deal implementations re ect the inherent challenges of dealing with the synchrony (or lack thereof) of the communication network.
It is easy to confuse cross-chain deals with atomic transactions, since they address similar needs.We hope this paper has clari ed the critical distinctions between them, and explained why deals are needed to address the demands of adversarial commerce.

Figure 2 .
Figure 2. Alice, Bob, and Carol's deal expressed as a digraph