Atomic Commitment Across Blockchains

TL;DR

This paper introduces AC3WN, a decentralized protocol ensuring all-or-nothing atomic cross-chain transactions in asynchronous environments, preventing partial asset exchanges due to network delays or crashes.

Contribution

It presents the first decentralized all-or-nothing atomic cross-chain commitment protocol suitable for asynchronous networks.

Findings

Guarantees atomicity in cross-chain swaps

Uses witnesses to prevent conflicting events

Ensures all or nothing asset exchange

Abstract

The recent adoption of blockchain technologies and open permissionless networks suggest the importance of peer-to-peer atomic cross-chain transaction protocols. Users should be able to atomically exchange tokens and assets without depending on centralized intermediaries such as exchanges. Recent peer-to-peer atomic cross-chain swap protocols use hashlocks and timelocks to ensure that participants comply to the protocol. However, an expired timelock could lead to a violation of the all-or-nothing atomicity property. An honest participant who fails to execute a smart contract on time due to a crash failure or network delays at her site might end up losing her assets. Although a crashed participant is the only participant who ends up worse off, current proposals are unsuitable for atomic cross-chain transactions in asynchronous environments where crash failures and network delays are the norm. In this paper, we present AC3WN, the first decentralized all-or-nothing atomic cross-chain commitment protocol. The redeem and refund events of the smart contracts that exchange assets are modeled as conflicting events. An open permissionless network of witnesses is used to guarantee that conflicting events could never simultaneously occur and either all smart contracts in an atomic cross-chain transaction are redeemed or all of them are refunded.

Tables

Table 1. Table 1: The throughput in tps of the top-4 permissionless cryptocurrencies sorted by their market cap  [ 24 ] .

Blockchain	tps	Blockchain	tps
1) Bitcoin	7	3) Litecoin	56
2) Ethereum	25	4) Bitcoin Cash	61

Equations

$$\text{centering}ms(\mathcal{D})=sig(...,sig((\mathcal{D},t),p_1),...,p_{|\mathcal{V}|})\text{@add@centering}$$

Full text

K****eywords Atomic Commitment, Blockchains

1 Introduction

The wide adoption of permissionless open blockchain networks by both industry (e.g., Bitcoin [22], Ethereum [28], etc) and academia (e.g., Bzycoin [18], Elastico [19], BitcoinNG [11], Algorand [21], etc) suggest the importance of developing protocols and infrastructures that support peer-to-peer atomic cross-chain transactions. Users, who usually do not trust each other, should be able to directly exchange their tokens and assets that are stored on different blockchains (e.g., Bitcoin and Ethereum) without depending on trusted third party intermidiaries. Decentralized permissionless [20] blockchain ecosystems require infrastructure enablers and protocols that allow users to atomically exchange tokens without giving up trust-free decentralization, the main reasons behind using permissionless blockchain. We motivate the problem of atomic cross-chain transactions and discuss the current available solutions and their limitations through the following example.

Suppose Alice owns X bitcoins and she wants to exchange them for Y ethers. Luckily, Bob owns ether and he is willing to exchange his Y ethers for X bitcoins. In this example, Alice and Bob want to atomically exchange assets that reside in different blockchains. In addition, both Alice and Bob do not trust each other and in many scenarios, they might not be co-located to do this atomic exchange in person. Current infrastructures do not support these direct peer-to-peer transactions. Instead, both Alice and Bob need to independently exchange their tokens through a trusted centralized exchange, Trent (e.g., Coinbase [3] and Robinhood [4]) either through fiat currency or directly. Using Fiat, both Alice and Bob first exchange their tokens with Trent for a fiat currency (e.g., USD) and then use the earned fiat currency to buy the other token also from Trent or from another trusted exchange. Alternatively, some exchanges (e.g., Coinbase) allow their customers to directly exchange tokens (ether for bitcoin or bitcoin for ether) without going through fiat currencies.

These solutions have many drawbacks that make them unacceptable solutions for atomic peer-to-peer cross-chain transactions. First, both solutions require both Alice and Bob to trust Trent. This centralized trust requirement risks to derail the whole idea of blockchain’s trust-free decentralization [22]. Second, both solutions require Trent to trade in all involved resources (e.g., bitcoin and ether). This requirement is unrealistic especially if Alice and Bob want to exchange commodity resources (e.g., transfer a car ownership for bitcoin assuming car titles are stored in a blockchain [16, 29]). Third, both solutions do not achieve atomicity of the transaction among the involved participants. Alice might trade her bitcoin directly for ether or through a fiat currency while Bob has no obligation to execute his part of the swap. Finally, both solutions significantly increase the number of required transactions to achieve the intended cross-chain transaction, and hence drastically increases the imposed fees. One cross-chain transaction between Alice and Bob results in either four transactions (two between Alice and Trent and two between Bob and Trent) if fiat is used or at best two transactions (one between Alice and Trent and one between Bob and Trent) if assets are directly swapped.

An Atomic Cross-Chain Transaction111Atomic Cross-Chain Transaction, AC2T, and Atomic Swap, AS, are interchangeably used., AC2T, is a distributed transaction that spans multiple blockchains. This distributed transaction consists of sub-transactions and each sub-transaction is executed on some blockchain. An Atomic Cross-Chain Commitment, AC3, protocol is required to execute AC2Ts. This protocol is a variation of traditional distributed atomic commitment protocols (e.g., 2PC [14, 8]). This protocol should guarantee both atomicity and commitment of AC2Ts. Atomicity ensures the all-or-nothing property where either all sub-transactions take place or none of them is executed. Commitment guarantees that any changes caused by a cross-chain transaction must eventually take place if the transaction is decided to commit. Unlike in 2PC and other traditional distributed atomic commitment protocols, atomic cross-chain commitment protocols are also trust-free and therefore must tolerate maliciousness [16].

A two-party atomic cross-chain swap protocol was originally proposed by Nolan [23, 1] and generalized by Herlihy [16] to process multi-party atomic cross-chain swaps. Both Nolan’s protocol and its generalization by Herlihy use smart contracts, hashlocks, and timelocks to execute atomic cross-chain swaps. A smart contract is a self executing contract (or a program) that gets executed in a blockchain once all the terms of the contract are satisfied. A hashlock is a cryptographic one-way hash function $h=H(s)$ that locks assets in a smart contract until a hash secret $s$ is provided. A timelock is a time bounded lock that triggers the execution of a smart contract function after a pre-specified time period.

The atomic swap between Alice and Bob, explained in the earlier example, is executed using Nolan’s protocol as follows. Let a participant be the leader of the swap, say Alice. Alice creates a secret $s$, only known to Alice, and a hashlock $h=H(s)$. Alice uses $h$ to lock X bitcoins in a smart contract $SC_{1}$ and publishes $SC_{1}$ in the Bitcoin network. $SC_{1}$ states to transfer X bitcoins to Bob if Bob provides the secret $s$ such that $h=H(s)$ to $SC_{1}$. In addition, $SC_{1}$ is locked with a timelock $t_{1}$ that refunds the X bitcoins to Alice if Bob fails to provide $s$ to $SC_{1}$ before $t_{1}$ expires. As $SC_{1}$ is published in the Bitcoin network and made public to everyone, Bob can verify that $SC_{1}$ indeed transfers X bitcoins to the public address of Bob if Bob provides $s$ to $SC_{1}$. In addition, Bob learns $h$ from $SC_{1}$. Using $h$, Bob publishes a smart contract $SC_{2}$ in the Ethereum network that locks Y ethers in $SC_{2}$ using $h$. $SC_{2}$ states to transfer Y ethers to Alice if Alice provides the secret $s$ to $SC_{2}$. In addition, $SC_{2}$ is locked with a timelock $t_{2}<t_{1}$ that refunds the Y ethers to Bob if Alice fails to provide $s$ to $SC_{2}$ before $t_{2}$ expires.

Now, if Alice wants to redeem her Y ethers from $SC_{2}$, Alice must reveal $s$ to $SC_{2}$ before $t_{2}$ expires. Once $s$ is provided to $SC_{2}$, Alice redeems the Y ethers and $s$ gets revealed to Bob. Now, Bob can use $s$ to redeem his X bitcoins from $SC_{1}$ before $t_{1}$ expires. Notice that $t_{1}>t_{2}$ is a necessary condition to ensure that Bob has enough time to redeem his X bitcoins from $SC_{1}$ after Alice provides $s$ to $SC_{2}$ and before $t_{1}$ expires. If Bob provides $s$ to $SC_{1}$ before $t_{1}$ expires, Bob successfully redeems his X bitcoins and the atomic swap is marked completed.

The case against the current proposals: if Bob fails to provide $s$ to $SC_{1}$ before $t_{1}$ expires due to a crash failure or a network partitioning at Bob’s site, Bob loses his X bitcoins and $SC_{1}$ refunds the X bitcoins to Alice. This violation of the atomicity property of the protocol penalizes Bob for a failure that happens out of his control. Although a crashed participant is the only participant who ends up being worse off (Bob in this example), this protocol does not guarantee the atomicity of AC2Ts in asynchronous environments where crash failures, network partitioning, and message delays are the norm.

Another important drawback in Nolan’s and Herlihy’s protocols is the requirement of sequentially publishing the smart contracts in an atomic swap before the leader (Alice in our example) reveals the secret $s$. This requirement is necessary to ensure that the publishing events of all the smart contracts in the atomic swap happen before the redemption of any of the smart contracts. This causality requirement ensures that any malicious participant who declines to publish a smart contract does not take advantage of the protocol. However, the sequential publishing of smart contracts, especially in atomic swaps that include many participants, proportionally increases the latency of the swap to the number of sequentially published contracts.

In this paper, we propose AC3WN, the first decentralized all-or-nothing Atomic Cross-Chain Commitment protocol that uses an open Witness Network. The redemption and the refund events of smart contracts in AC2T are modeled as conflicting events. A decentralized open network of witnesses is used to guarantee that conflicting events must never simultaneously take place and either all smart contracts in an AC2T are redeemed or all of them are refunded. Unlike in Nolan’s and Herlihy’s protocols, AC3WN allows all participants to concurrently publish their contracts in a swap resulting in a drastic decrease in an atomic swap’s latency. Our contribution is summarized as follows:

• •

We present AC3WN, the first all-or-nothing atomic cross-chain commitment protocol. AC3WN is decentralized and does not require to trust any centralized intermediary.

• •

We prove the correctness of AC3WN showing that AC3WN achieves both atomicity and commitment of AC2Ts.

• •

Finally, we analytically evaluate AC3WN in comparison to Herlihy’s [16] protocol. Unlike in Herlihy’s protocol where the latency of an atomic swap proportionally increases as the number of the sequentially published smart contracts in the atomic swap increases, our analysis shows that the latency of an atomic swap in AC3WN is constant irrespective of the number of smart contracts involved.

The rest of the paper is organized as follows. In Section 2, we discuss the open blockchain data and transactional models. Section 3 explains the cross-chain distributed transaction model and Section 4 presents our atomic cross-chain commitment protocol. An analysis of the atomic cross-chain commitment protocol is presented in Section 5. The protocol is evaluated in Section 6 and the paper is concluded in Section 7.

2 Open Blockchain Models

2.1 Architecture Overview

An open permissionless blockchain system [20] (e.g., Bitcoin, Ethereum) typically consists of two layers: a storage layer and an application layer as illustrated in Figure 1. The storage layer comprises a decentralized distributed ledger managed by an open network of computing nodes. A blockchain system is permissionless if computing nodes can join or leave the network of its storage layer at any moment without obtaining a permission from a centralized authority. Each computing node, also called a miner, maintains a copy of the ledger. The ledger is a tamper-proof chain of blocks, hence named blockchain. Each block contains a set of valid transactions that transfer assets among end-users. The application layer comprises end-users who communicate with the storage layer via message passing through a client library. End-users have identities, defined by their public keys, and signatures, generated using their private keys. Digital signatures are the end-users’ way to generate transactions as explained later in Section 2.3. End-users submit their transactions to the storage layer through a client library. Transactions are used to transfer assets from one identity to another. End-users multicast their transaction messages to mining nodes in the storage layer.

A mining node validates the transactions it receives and valid transactions are added to the current block of a mining node. Miners run a consensus protocol through mining to agree on the next block to be added to the chain. A miner who mines a block gets the right to add its block to the chain and multicasts it to other miners. To make progress, miners accept the first received mined block after verifying it and start mining the next block222Forks and fork resolutions are discussed in later Sections.. Sections 2.2 and 2.3 explain the data model and the transactional model of open blockchain systems respectively.

2.2 Data Model

The storage layer stores the ownership information of assets in the system in the blockchain. The ownership is determined through identities and identities are typically implemented using public keys. For example, the Bitcoin blockchain stores the information of the most recent owner of every bitcoin in the Bitcoin blockchain. A bitcoin that is linked to Alice’s public key is owned by Alice. In addition, the blockchain stores transactions that transfer the ownership of an asset from one identity to another. Therefore, an asset can be tracked from its registration in the blockchain, the first owner, to its last owner in the blockchain. In the Bitcoin network, new bitcoins are generated and registered in the Bitcoin blockchain through mining. Asset ownership is transferred from one identity to another through a transaction. In addition, transactions are used to merge or split assets as explained in Section 2.3.

2.3 Transaction Model

A transaction is a digital signature that transfers the ownership of assets from one identity to another. End-users, in the application layer, use their private keys [26] to digitally sign assets linked to their identity to transfer these assets to other identities, identified by their public keys. These digital signatures are submitted to the storage layer via message passing through a client library. It is the responsibility of the miners to validate that end-users can transact only on their own assets. If an end-user digitally signs an asset that is not owned by this end-user, the resulting transaction is not valid and is rejected by the miners. In addition, miners validate that an asset cannot be spent twice and hence prevent double spending of assets.

A transaction takes one or more input assets owned by one identity and results in one or more output assets where each output asset is owned by one identity. Therefore, transactions are used to merge or split assets. Figure 2 shows two transactions $TX_{1}$, a transaction that merges assets, and $TX_{2}$, a transaction that splits assets. $TX_{1}$ takes 3 input assets owned by Alice, merges them into one output asset, and transfers the ownership of this merged asset to Bob. On the other hand, $TX_{2}$ takes one input asset owned by Bob and splits it into 2 output assets of two different values; one is transferred to Alice and the other is transferred to Bob. Note that the summation of a transaction’s input assets matches the summation of its output assets assuming that no transaction fees are imposed.

Figure 3 shows an example of how $TX_{1}$ and $TX_{2}$ take place in the Bitcoin blockchain. As shown, Alice can only transact on assets that she owns in previous blocks in the blockchain issuing $TX_{1}$. Similarly, once the ownership of 1.8 bitcoin is transferred to Bob, only then can Bob issue the transaction $TX_{2}$ to split the 1.8 bitcoin asset to 0.3 to Alice and 1.5 to Bob in a following block. In traditional databases, end-user transactions execute arbitrary updates in the storage layer as long as the semantic and the access control rights of a transaction are validated in the application layer. On the other hand, in blockchain systems, this validation is explicitly enforced in the storage layer and hence end-users, in the application layer, are allowed to transact only on assets they own in the storage layer.

Another way to perform transactions in blockchain systems is through smart contracts. A smart contract is a program written in some scripting language (e.g., Solidity for Ethereum smart contracts [5]) that allows general program executions on a blockchain’s mining nodes. End-users deploy a smart contract in a blockchain through a deployment333Deployment and publishing are used interchangeably. message, $msg$, that is sent to the mining nodes in the storage layer. The deployment message includes the smart contract code in addition to some implicit parameters that are accessible to the smart contract code once the smart contract is deployed. These parameters include the sender end-user public key, accessed through $msg.sender$, and an optional asset value, accessed through $msg.val$. This optional asset value allows end-users to lock some of their assets in the deployed smart contract. Like transactions, a smart contract is deployed in a blockchain if it is included in a mined block in this blockchain. We adopt Herlihy’s notion of a smart contract as an object in programming languages [17, 10]. A smart contract has a state, a constructor that is called when a smart contract is first deployed in the blockchain, and a set of functions that could alter the state of the smart contract. The constructor initializes the smart contract’s state and uses the implicit parameters to initialize the owner of the smart contract and the assets to be locked in this smart contract. Miners verify that the end-user who deploys a smart contract indeed owns these assets. Once assets are locked in a smart contract, their owners cannot transact on these assets outside the smart contract logic until these assets are unlocked from the smart contract as a result of a smart contract function call. To execute a smart contract function, end-users submit their function call accompanied by the function parameters through messages to miners. These messages could include implicit parameters as well (e.g., $msg.sender$). Miners execute444End-users pay to miners a smart contract deployment fee plus a function invocation fee for every function call. the function on the current contract state and record any contract state changes in their current block in the blockchain. Therefore, a smart contract state might span many blocks after the block where the smart contract is first deployed.

3 Atomic Cross-Chain Transaction Model

An Atomic Cross-Chain Transaction, AC2T, is a distributed transaction to transfer the ownership of assets stored in multiple blockchains among two or more participants. This distributed transaction consists of sub-transactions and each sub-transaction transfers an asset on some blockchain. An AC2T is modeled using a directed graph $\mathcal{D}=(\mathcal{V},\mathcal{E})$ [16] where $\mathcal{V}$ is the set of vertexes and $\mathcal{E}$ is the set of edges in $\mathcal{D}$. $\mathcal{V}$ represents the participants in AC2T and $\mathcal{E}$ represents the sub-transactions in AC2T. A directed edge $e=(u,v)\in\mathcal{E}$ represents a sub-transaction that transfers an asset $e.a$ from a source participant $u\in\mathcal{V}$ to a recipient participant $v\in\mathcal{V}$ in some blockchain $e.BC$. Figure 4 shows an example of an AC2T graph between Alice (A) and Bob (B). As shown, the edge (A, B) represents the sub-transaction $AC^{2}T_{1}$ that transfers X bitcoins from A to B while the edge (B, A) represents the sub-transaction $AC^{2}T_{2}$ that transfers Y ethers from B to A.

An atomic cross-chain commitment protocol is required in order to correctly execute an AC2T. This protocol must ensure the atomicity and the commitment of all sub-transactions in AC2T as follows.

• •

Atomicity: either all asset transfers of all sub-transactions in the AC2T take place or none of them does.

• •

Commitment: once the atomic cross-chain commitment protocol decides the commitment of an AC2T, all asset transfers of all sub-transactions in this AC2T must eventually take place.

An atomic cross-chain commitment protocol is a variation of the two phase commit protocol (2PC) [14, 8]. Therefore, we use the analogy of 2PC to explain an abstraction of an atomic cross-chain commitment protocols. In 2PC, a distributed transaction spans multiple data partitions and each partition is responsible for executing a sub-transaction. A coordinator sends a vote request to all involved data partitions. Upon receiving a vote request, a data partition votes back yes only if it succeeds in executing all the operations of its sub-transaction on the involved data objects. Otherwise, a data partition votes no to the coordinator. A coordinator decides to commit a distributed transaction if all involved data partitions vote yes, otherwise it decides to abort the distributed transaction. If a commit decision is reached, all data partitions commit their sub-transactions. However, if an abort decision is reached, data partitions abort their sub-transactions. 2PC assumes that the coordinator and the data partitions are trusted. The main challenge in blockchain systems is how to design a trust-free variation of 2PC where end-user participants do not trust each other and a protocol cannot depend on a centralized trusted coordinator.

An atomic cross-chain commitment protocol requires that for every edge $e=(u,v)\in\mathcal{E}$, the source participant $u$ to lock an asset $e.a$ in Blockchain $e.BC$. This asset locking is necessary to temporarily prevent the participant $u$ from spending $e.a$ through other transactions in $e.BC$. If every source participant $u$ locks $e.a$ in $e.BC$, the atomic cross-chain commitment protocol can decide to commit the AC2T. Once the protocol decides to commit the AC2T, every recipient participant $v$ should be able to redeem the asset $e.a$. However, if the protocol decides to abort the AC2T because some participants do not comply to the protocol or a participant requests the transaction to abort, every source participant $u$ should be able to refund their locked assets $e.a$.

In blockchain systems, smart contracts are used to implement this logic. Participant $u$ deploys a smart contract $SC_{e}$ in Blockchain $e.BC$ to lock an asset $e.a$ owned by $u$ in $SC_{e}$. $SC_{e}$ ascertains to conditionally transfer $e.a$ to $v$ if a commitment decision is reached, otherwise $e.a$ is refunded to $u$. A smart contract $SC_{e}$ exists in one of three states: published ($P$), redeemed ($RD$), or refunded ($RF$). A smart contract $SC_{e}$ is published if it gets deployed to $e.BC$ by $u$. Publishing the smart contract $SC_{e}$ serves two important goals towards the atomic execution of an AC2T. First, it represents a yes vote on the sub-transaction corresponding to the edge $e$. Second, it locks the asset $e.a$ in blockchain $e.BC$. A smart contract $SC_{e}$ is redeemed if participant $v$ successfully redeems the asset $e.a$ from $SC_{e}$. Finally, a smart contract $SC_{e}$ is refunded if the asset $e.a$ is refunded to participant $u$.

Now, if for every edge $e=(u,v)\in\mathcal{E}$, participant $u$ publishes smart contract $SC_{e}$ in $e.BC$, it means that all participants vote yes on AC2T, lock their involved assets in AC2T, and hence the AC2T can be committed. However, if some participants decline to publish their smart contracts, the AC2T has to be aborted. The commitment of AC2T requires the redemption of every smart contract $SC_{e}$ in AC2T. On the other hand, if the AC2T aborts, this requires the refund of every smart contract $SC_{e}$ in AC2T.

To implement conditional smart contract redemption and refund, a cryptographic commitment scheme primitive based on [12] is used. A commitment scheme allows a user to commit to some chosen value without revealing this value. Once this hidden value is revealed, other users can verify that the revealed value is indeed the one that is used in the commitment. A hashlock is an example of a commitment scheme. A hashlock is a cryptographic one-way hash function $h=H(s)$ that is used to conditionally lock assets in a smart contract using $h$, the lock, until a hash secret $s$, the key, is revealed. Once $s$ is revealed, everyone can verify that the lock $h$ equals to $H(s)$ and hence unlocks the assets locked in the smart contract.

An atomic cross-chain commitment protocol should ensure that smart contracts in AC2T are either all redeemed or all refunded. For this, a protocol uses two mutually exclusive commitment scheme instances: a redemption commitment scheme and a refund commitment scheme. All smart contracts in AC2T commit their redemption action to the redemption commitment scheme instance and their refund action to the refund commitment scheme instance. If the protocol decides to commit the AC2T, the protocol must publish the redemption commitment scheme secret. This allows all participants in AC2T to redeem their assets. However, if the protocol reaches an abort decision, the protocol must publish the refund commitment scheme secret. This allows participants in AC2T to refund the locked assets in every published smart contract. A protocol must ensure that once the secret of one commitment scheme instance is revealed, the secret of the other instance cannot be revealed. This guarantees the atomic execution of an AC2T. In Section 4, we instantiate different protocols that implement mutually exclusive redemption and refund commitment schemes in different ways.

Algorithm 1 illustrates a smart contract template that can be used in implementing an atomic cross-chain commitment protocol. Each smart contract has a sender $s$ and recipient $r$ (Line 2), an asset $a$ (Line 3) to be transferred from $s$ to $r$ through the contract, a state (Line 4), and a redemption and refund commitment scheme instances $rd$ and $rf$ (Lines 5 and 6). A smart contract is published in a blockchain through a deployment message. When published, its constructor (Line 7) is executed to initialize the contract. The deployment message of a smart contract typically includes some implicit parameters like the sender’s address (msg.sender, Line 8) and the asset value (msg.value, Line 9) to be locked in the contract. The constructor initializes the addresses, the asset value, the refund and redemption commitment schemes, and sets the contract state to P (Lines 8–11).

In addition, each smart contract has a redeem function (Line 13) and a refund function (Line 18). A redeem function requires the smart contract to be in state P and that the provided commitment scheme secret is valid (Line 14). If all these requirements hold, the asset $a$ is transferred from the contract to the recipient and the contract state is changed to RD (Lines 15–16). However, if any requirement is violated, the redeem function fails and the smart contract state is not changed.

Similarly, the refund function requires the smart contract to be in P state and that the provided commitment scheme secret is valid (Line 19). If all these requirements hold, the asset $a$ is refunded from the contract to the sender and the contract state is changed to RF (Lines 20–21).

The redeem and the refund functions use two helper functions: IsRedeemable (Line 23) and IsRefundable (Line 26). IsRedeemable verifies that the provided redemption commitment scheme secret is valid and hence the smart contract can be redeemed. Similarly, IsRefundable verifies that the provided refund commitment scheme secret is valid and hence the smart contract can be refunded. In Section 4, we instantiate different versions of these two functions for every atomic cross-chain commitment protocol.

4 AC3: Atomic Cross-Chain Commitment

This section presents two Atomic Cross-Chain Commitment, AC3, protocols that achieve both atomicity and commitment of an AC2T. There are two main challenges in designing a correct AC3 protocol. The first challenge is how to implement the redemption and refund commitment scheme instances used by every smart contract in AC2T. The second challenge is how to ensure that the two instances are mutually exclusive. If the secret of one instance is revealed, the secret of the other instance must never be revealed. First, we present AC3TW, an AC3 protocol that uses a centralized Trusted Witness in Section 4.1. Then, we present AC3WN, an AC3 protocol that replaces the centralized trusted witness with a permissionless Witness Network in Section 4.2. Using a permissionless network of witnesses does not require more trust in the witness network than the required trust in the blockchains used to exchange the assets in an AC2T. Furthermore, the AC3WN protocol overcomes the vulnerability of the centralized trusted witness, which may fail or be subject to denial of service attacks.

4.1 AC3TW: Centralized Trusted Witness

A centralized trusted witness, Trent, is leveraged to implement an AC3 protocol as follows. For every AC2T, a directed graph $\mathcal{D}=(\mathcal{V},\mathcal{E})$ is constructed at some timestamp $t$ and multisigned by all the participants in the set $\mathcal{V}$ generating a graph multisignature $ms(\mathcal{D})$ as shown in Equation 1. The timestamp $t$ is important to distinguish between identical $AC^{2}T$s among the same participants. The order of participant signatures in $ms(\mathcal{D})$ is not important. Any signature order indicates that all participants in the AC2T agree on the graph $\mathcal{D}$ at some timestamp $t$.

[TABLE]

Afterwards, any participant in the set $\mathcal{V}$ registers $ms(\mathcal{D})$ at Trent through a registration message. This indicates that participants in the AC2T trust Trent to witness their AC2T. Trent’s identity is leveraged to implement the redemption and refund commitment scheme instances and Trent’s digital signatures [26] are leveraged to implement their corresponding commitment scheme secrets. After $ms(\mathcal{D})$ is registered at Trent, participants in the AC2T publish smart contracts in the AC2T in their corresponding blockchains. Participants set both the redemption and refund commitment scheme instances of their smart contracts to the pair $(ms(\mathcal{D}),PK_{T})$ where $PK_{T}$ is Trent’s public key. Trent’s signatures $T(ms(\mathcal{D}),RD)$ and $T(ms(\mathcal{D}),RF)$ are used to implement the redemption and refund commitment scheme secrets respectively.

The witness role: Trent maintains a key/value store of $ms(\mathcal{D})$’s as the key, and his digital signature to either $(ms(\mathcal{D}),RD)$ or $(ms(\mathcal{D}),RF)$ as the value. When Trent receives a multisigned graph’s registration message $ms(\mathcal{D})$, Trent checks that $ms(\mathcal{D})$ has not been registered before. If true, Trent inserts $ms(\mathcal{D})$ to the key/value store. Trent sets the key to $ms(\mathcal{D})$ and sets its corresponding value to $\bot$. Now, if all participants deploy their smart contracts in their corresponding blockchains, any participant can request a redemption signature from Trent for $ms(\mathcal{D})$ through a redemption request message. On receiving a redemption request, Trent verifies that $ms(\mathcal{D})$ is registered in the key/value store. If the value corresponding to $ms(\mathcal{D})$ is $\bot$, Trent verifies that all smart contracts in the AC2T are deployed and that the redemption and refund commitment scheme instances of every smart contract are set to $(ms(\mathcal{D}),PK_{T})$. If true, Trent witnesses the redemption of the AC2T by signing $(ms,RD)$ and setting the value of the key $ms(\mathcal{D})$ to $T(ms(\mathcal{D}),RD)$. However, if the verification fails, Trent keeps the value of the key $ms(\mathcal{D})$ unchanged. Similarly, a participant can request a refund signature from Trent for $ms(\mathcal{D})$ through a refund request message. On receiving a refund request, Trent verifies that $ms(\mathcal{D})$ is registered in the key/value store and its corresponding value is $\bot$. If true, Trent witnesses the refund of the AC2T by signing $(ms,RF)$ and setting the value of the key $ms(\mathcal{D})$ to $T(ms(\mathcal{D}),RF)$. However, if the verification fails, Trent keeps the value of the key $ms(\mathcal{D})$ unchanged. Trent responds to redemption and refund requests of $ms(\mathcal{D})$ with the value corresponding to $ms(\mathcal{D})$ in the key/value store. Trent uses the key/value store to ensure that either $T(ms(\mathcal{D}),RD)$ or $T(ms(\mathcal{D}),RF)$ can be issued for an AC2T. Once a signature of one commitment scheme secret is revealed (e.g., the redemption signature), the signature of the other commitment scheme secret cannot be issued (e.g., the refund signature). This guarantees that the redemption and refund commitment scheme secrets are mutually exclusive. Trent’s signature $T(ms(\mathcal{D}),RD)$ implies that Trent witnessed the deployment of all smart contracts in the AC2T and hence the AC2T can be committed without violating atomicity. The AC2T is committed once Trent issues $T(ms(\mathcal{D}),RD)$. Afterwards, participants use $T(ms(\mathcal{D}),RD)$ to eventually redeem all the locked assets in the published smart contracts. Trent’s signature $T(ms(\mathcal{D}),RF)$ implies that the AC2T was not previously committed and hence can be aborted. The AC2T is aborted once Trent issues $T(ms(\mathcal{D}),RF)$. Afterwards, participants use $T(ms(\mathcal{D}),RF)$ to eventually refund all the locked assets in the published smart contracts.

Algorithm 2 presents a smart contract class inherited from the smart contract template in Algorithm 1 that uses Trent’s digital signatures as redemption and refund commitment scheme secrets. Both the redemption and the refund commitment scheme instances comprise the ordered pair ($ms(\mathcal{D})$, $PK_{T}$) (Line 2). The IsRedeemable function (Line 5) takes a digital signature as input and verifies that this signature is Trent’s signature to $(ms(\mathcal{D}),RD)$ using a SigVerify function (Line 6). Similarly, The IsRefundable function (Line 8) takes a digital signature as input and verifies that this signature is Trent’s signature to $(ms(\mathcal{D}),RF)$ (Line 9).

The following steps summarizes the AC3TW protocol steps to execute the AC2T shown in Figure 4:

Alice and Bob construct the graph $\mathcal{D}$ and multisign $(\mathcal{D},t)$ to generate $ms(\mathcal{D})$. 2. 2.

Either Alice or Bob registers $ms(\mathcal{D})$ at Trent and Trent inserts $ms(\mathcal{D})$ to his key/value store only if $ms(\mathcal{D})$ is not registered before. 3. 3.

Afterwards, Alice publishes a smart contract $SC_{1}$ using Algorithm 2 to the Bitcoin network stating the following:

• •

Move X bitcoins from Alice to Bob if Bob provides $T(ms(\mathcal{D}),RD)$.

• •

Refund X bitcoins from $SC_{1}$ to Alice if Alice provides $T(ms(\mathcal{D}),RF)$. 4. 4.

Concurrently, Bob published a smart contract $SC_{2}$ to the Ethereum network using Algorithm 2 stating the following:

• •

Move Y ethers from Bob to Alice if Alice provides $T(ms(\mathcal{D}),RD)$.

• •

Refund Y ethers from $SC_{2}$ to Bob if Bob provides $T(ms(\mathcal{D}),RF)$. 5. 5.

After both $SC_{1}$ and $SC_{2}$ are published, either Alice or Bob requests a redemption commitment scheme secret from Trent. Trent issues $T(ms(\mathcal{D}),RD)$ only if both $SC_{1}$ and $SC_{2}$ are published in their corresponding blockchains and the value corresponding to $ms(\mathcal{D})$ is $\bot$ in Trent’s key/value store. 6. 6.

If a participant declines to publish their smart contract or a participant changes their mind before AC2T is committed, any participant can requests a refund commitment scheme secret from Trent. Trent issues $T(ms(\mathcal{D}),RD)$ only if the value corresponding to $ms(\mathcal{D})$ is $\bot$ in Trent’s key/value store.

This protocol achieves atomicity by ensuring that either $T(ms(\mathcal{D}),RD)$ or $T(ms(\mathcal{D}),RF)$ can be issued. However, this solution requires the participants to trust a centralized intermediary, Trent, and hence risks to derail the whole idea of blockchain’s trust-free decentralization [22]. In Section 4.2, we explain how to replace Trent with a permissionless network of witnesses.

4.2 AC3WN: Permissionless Witness Network

This section presents AC3WN, an AC3 protocol that uses a permissionless blockchain network of witnesses to decide whether an $AC^{2}T$ should be committed or aborted. Miners of this blockchain are collectively the witnesses on $AC^{2}T$s. The AC3WN protocol is designed to address the shortcoming of the AC3TW protocol that depends on a centralized trusted witness. The AC3TW protocol uses the trusted witness identity and signatures to implement the redemption and the refund commitment scheme instances of all smart contracts in the AC2T. In contrast, in AC3WN, it is infeasible to use a specific witness identity to implement the redemption and the refund commitment scheme instances. The witness network is permissionless. Therefore, the identities of all the miners, the witnesses, in this network are not necessarily known and hence cannot be used to implement these commitment scheme instances. Instead, when a set of participants want to execute an AC2T, they deploy a smart contract $SC_{w}$ in the witness network where $SC_{w}$ is used to coordinate the AC2T. $SC_{w}$ has a state that determines the state of the AC2T. $SC_{w}$ exists in one of three states: Published ($P$), Redeem_Authorized ($RD_{auth}$), or Refund_Authorized ($RF_{auth}$). Once $SC_{w}$ is deployed, $SC_{w}$ is initialized to the state $P$. If the witness network decides to commit the AC2T, the witnesses set $SC_{w}$’s state to $RD_{auth}$. However, if the witness network decides to abort the AC2T, the witnesses set $SC_{w}$’s state to $RF_{auth}$.

Figure 5 shows an AC2T that exchanges assets among blockchains, $blockchain_{1},...,blockchain_{n}$ and uses a witness blockchain for coordination. Also, it illustrates the AC3WN protocol steps. For every AC2T, all the participants construct the directed graph $\mathcal{D}$ at some timestamp $t$ and multisign it resulting in the multisignature $ms(\mathcal{D})$. A participant registers $ms(\mathcal{D})$ in a smart contract $SC_{w}$ in the witness network where $SC_{w}$’s state is initialized to $P$. The state $P$ indicates that the participants of the AC2T agreed on $\mathcal{D}$. In addition, the participants agree to conditionally link the redeem and the refund actions of their smart contracts in the AC2T to $SC_{w}$’s states $RD_{auth}$ and $RF_{auth}$ respectively. Afterwards, the participants parallelly deploy their smart contracts in the blockchains, $blockchain_{1},...,blockchain_{n}$, as shown in Figure 5. After all the participants deploy their smart contracts in the AC2T, a participant may submit a state change request to the witness network miners to alter $SC_{w}$’s state from $P$ to $RD_{auth}$. This request is accompanied by evidence that all smart contracts in the AC2T are deployed and correct. Upon receiving this request, the miners of the witness network verify that $SC_{w}$’s state is $P$ and that the participants of the AC2T have indeed deployed their smart contracts in the AC2T in their corresponding blockchains. In addition, the miners verify that all these smart contracts are in state $P$ and that the redemption and the refund of these smart contracts are conditioned on $SC_{w}$’s states $RD_{auth}$ and $RF_{auth}$ respectively. If this verification succeeds, the miners of the witness network record $SC_{w}$’s state change to $RD_{auth}$ in their current block. Once a block that reflects the state change of $SC_{w}$ to $RD_{auth}$ is mined in the witness network, the commitment of the AC2T is decided and participants can use this block as a commitment evidence to redeem their assets in the smart contracts of the AC2T. The commit decision is illustrated in Figure 5 using the vertical dotted line.

Similarly, if some participants decline to deploy their smart contracts in the AC2T or a participant changes her mind before the commitment of the AC2T, a participant can submit a state change request to the witness network miners to alter $SC_{w}$’s state from $P$ to $RF_{auth}$. The miners of the witness network only verify that $SC_{w}$’s state is $P$. If this verification succeeds, the miners of the witness network record $SC_{w}$’s state change to $RF_{auth}$ in their current block. Once a block that reflects the state change of $SC_{w}$ to $RF_{auth}$ is mined in the witness network, the AC2T is decided to abort and the participants can use this block as evidence of the abort to refund their assets in the deployed smart contracts of the AC2T. Note that $SC_{w}$ is programmed to ensure that $SC_{w}$’s state can only be changed either from $P$ to $RD_{auth}$ or from $P$ to $RF_{auth}$ but no other state transition is allowed. This ensures that $SC_{w}$’s states $RD_{auth}$ and $RF_{auth}$ are mutually exclusive. The details of evidence and how miners of one blockchain validate evidence in another blockchain without maintaining a copy of this other blockchain are explained in Section 4.3. Section 4.3 presents different implementations for evidence submission and validation.

Algorithm 3 presents the details of $SC_{w}$. $SC_{w}$ consists of four functions: Constructor (Line 5), AuthorizeRedeem (Line 10), AuthorizeRefund (Line 14), and VerifyContracts (Line 18). The Constructor initializes $SC_{w}$ with the participants public keys and the multisigned graph of the AC2T. This information is necessary to the witness network miners to later verify the publishing of all smart contracts in the AC2T. AuthorizeRedeem alters $SC_{w}$’s state from $P$ to $RD_{auth}$. To call AuthorizeRedeem, a participant provides evidence that shows where the smart contracts of the AC2T are published (Line 10). AuthorizeRedeem first verifies that $SC_{w}$’s state is currently $P$. In addition, AuthorizeRedeem verifies that all smart contract in the AC2T are published and correct through a VerifyContracts function call (Line 11). If this verification succeeds, $SC_{w}$’s state is altered to $RD_{auth}$ (Line 12). On the other hand, AuthorizeRefund (Line 14) verifies only that the state of $SC_{w}$ is $P$ (Line 15). If true, $SC_{w}$’s state is altered to $RF_{auth}$ (Line 16).

VerifyContracts (Line 18) validates that all smart contracts in the AC2T are published and correct. For every edge $e=(u,v)\in\mathcal{D}.\mathcal{E}$, VerifyContracts finds a matching smart contract $SC_{e}$ in the participant evidence. VerifyContracts ensures that $SC_{e}$ matches its description in the edge $e$. If any parameter in $SC_{e}$ does not match its description in $e$, VerifyContracts fails and returns false (Line 22). However, if all smart contracts in the provided list are correct, VerifyContracts returns true (Line 20). VerifyContracts ensures that AuthorizeRedeem cannot be executed unless all smart contract in the AC2T are published and correct and hence a commit decision can be reached.

Algorithm 4 presents a smart contract class inherited from the smart contract template in Algorithm 1 in order to use $SC_{w}$’s state as redemption and refund commitment scheme secrets. IsRedeemable returns true if $SC_{w}$’s state is $RD_{auth}$ (Line 7), while IsRefundable returns true if $SC_{w}$’s state is $RF_{auth}$ (Line 13). As the witness network is permissionless, forks could possibly happen resulting in two concurrent blocks where $SC_{w}$’s state is $RD_{auth}$ in the first block and $SC_{w}$’s state is $RF_{auth}$ in the second block. To avoid atomicity violations, participants cannot use a witness network block where $SC_{w}$’s state is $RD_{auth}$ or $RF_{auth}$ in their smart contract redemption and refund respectively unless this block is buried under at least $d$ blocks in the witness network. As the probability of a fork of depth $d$ (e.g., 6 blocks in the Bitcoin network [2]) is negligible, $SC_{w}$’s state eventually converges to either $RD_{auth}$ or $RF_{auth}$.

The following steps summarizes the AC3WN protocol steps to execute the AC2T shown in Figure 4:

Alice and Bob construct the $AC^{2}T$’s graph $\mathcal{D}$ and multisign $(\mathcal{D},t)$ to generate $ms(\mathcal{D})$. 2. 2.

Either Alice or Bob registers $ms(\mathcal{D})$ in a smart contract $SC_{w}$ and publishes $SC_{w}$ in the witness network setting $SC_{w}$’s state is $P$. $SC_{w}$ follows Algorithm 3. 3. 3.

Afterwards, Alice publishes a smart contract $SC_{1}$ using Algorithm 4 to the Bitcoin network that states the following:

• •

Move X bitcoins from Alice to Bob if Bob provides evidence that $SC_{w}$’s state is $RD_{auth}$.

• •

Refund X bitcoins from $SC_{1}$ to Alice if Alice provides evidence that $SC_{w}$’s state is $RF_{auth}$. 4. 4.

Concurrently, Bob publishes a smart contract $SC_{2}$ to the Ethereum network using Algorithm 4 stating the following:

• •

Move Y ethers from Bob to Alice if Alice provides evidence that $SC_{w}$’s state is $RD_{auth}$.

• •

Refund Y ethers from $SC_{2}$ to Bob if Bob provides evidence that $SC_{w}$’s state is $RF_{auth}$. 5. 5.

After both $SC_{1}$ and $SC_{2}$ are published, any participant can submit a state change request of $SC_{w}$ from $P$ to $RD_{auth}$ to the witness network miners. This request is accompanied by evidence that $SC_{1}$ and $SC_{2}$ are published in the Bitcoin and the Ethereum blockchains respectively. The witness network miners first verify that $SC_{w}$’s state is currently $P$. Then, they verify that both $SC_{1}$ and $SC_{2}$ are published and correct in their corresponding blockchains. If these verifications succeed, the miners of the witness network record $SC_{w}$’s state change to $RD_{auth}$ in their current block. Once a block that reflects the state change of $SC_{w}$ to $RD_{auth}$ is mined and gets buried under $d$ blocks in the witness network, Alice and Bob can use this block as evidence to redeem their assets from $SC_{2}$ and $SC_{1}$ respectively. 6. 6.

If a participant declines to publish a smart contract, the other participant can submit a state change request of $SC_{w}$ from $P$ to $RF_{auth}$ to the witness network miners. The witness network miners verify that $SC_{w}$’s state is currently $P$. If true, miners record $SC_{w}$’s state change to $RF_{auth}$ in their current block. Once a block that reflects the state change of $SC_{w}$ to $RF_{auth}$ is mined and gets buried under $d$ blocks in the witness network, Alice and Bob can use this block as evidence to refund their assets from $SC_{1}$ and $SC_{2}$ respectively.

This protocol uses two blockchain techniques to ensure that $SC_{w}$’s states $RD_{auth}$ and $RF_{auth}$ are mutually exclusive. First, it uses the smart contract programmable logic to ensure that $SC_{w}$’s state can only be altered from $P$ to $RD_{auth}$ or from $P$ to $RF_{auth}$. Second, it uses the longest chain fork resolving technique to resolve forks in the witness network blockchain. This ensures that in the rare case of forking where one fork chain has $SC_{w}$’s state of $RD_{auth}$ and another fork chain has $SC_{w}$’s state of $RF_{auth}$, the fork is eventually resolved resulting in either $SC_{w}$’s state is $RD_{auth}$ or $SC_{w}$’s state is $RF_{auth}$ but not both.

4.3 Cross-Chain Evidence Validation

This section explains different techniques for the miners of one blockchain, the validators, to validate the publishing and verify the state of a smart contract deployed in another blockchain, the validated. The AC3WN protocol leverages these techniques in two protocol functions: 1) VerifyContracts in Algorithm 3 and 2) IsRedeemable/IsRefundable in Algorithm 4. In VerifyContracts, the miners of the witness network need to validate the publishing of all smart contracts in the AC2T in the blockchains where asset transfers occur. In addition, the miners need to verify that the state of all the published contracts is $P$ and that the redemption and the refund of these smart contracts are conditioned on $SC_{w}$’s states. Finally, the miners need to verify that for every smart contract in the AC2T, the sender, the recipient, and the asset match the specification of its corresponding edge $e\in\mathcal{D}$. Similarly, in IsRedeemable/IsRefundable, miners of the blockchains where asset transfers occur need to verify that $SC_{w}$’s state is either $RD_{auth}$, in order to execute the redemption of a smart contract or $RF_{auth}$, in order to execute the refund of a smart contract. In the former case, the miners of the witness network are the validators and the asset blockchains are the validated blockchains. In the latter case, the miners of the asset blockchains are the validators and the witness blockchain is the validated blockchain.

A simple but impractical solution is to require all the miners of every blockchain to serve as validators to all other blockchains. A blockchain validator maintains a copy of the validated blockchain and for every new mined block, a validator validates the mined block and adds it to its local copy of the validated blockchain. If all mining nodes mine one blockchain and validate all other blockchains, mining nodes can consult their local copies of these blockchains to validate the publishing and hence verify the state of any smart contract in any blockchain. If a participant needs the miners of the validator blockchain to validate the publishing of a smart contract in the validated blockchain, this participant submits evidence that comprises a block id and a transaction id of the smart contract in the validated blockchain to the miners of the validator blockchain. This evidence is easily verified by the mining node of the validator blockchain by consulting their copy of the validated blockchain. However, this full replication of all the blockchains in all the mining nodes is impractical. Not only does it require massive processing power to validate all blockchains, but also it requires significant storage and network capabilities at each mining node.

Alternatively, miners of one blockchain can run light nodes [9] of other blockchains. A light node, as defined in [9], is a node that downloads only the block headers of a blockchain, verifies the proof of work of these block headers, and downloads only the blockchain branches that are associated with the transactions of interest to this node. For example, the mining nodes of the witness network can run light nodes for the Bitcoin network to verify the $AC^{2}T$’s smart contracts in the Bitcoin network. A participant who wants the witness network mining nodes to validate a smart contract in the Bitcoin network submits evidence that consist of a block id and a transaction id of the smart contract in the Bitcoin network to the miners of the witness network. The miners of the witness network use their Bitcoin light nodes to validate the smart contract publishing and verify the smart contract state. This solution requires miners to mine for one blockchain and maintain light nodes for all other blockchains. Although the cost of maintaining a light node is much cheaper than maintaining a blockchain full copy, running a light node for all blockchains does not scale as the number of blockchains increases.

It is important to mention that the previous two techniques put the evidence validation responsibility of one blockchain on the miners of another blockchain. In addition, they require changes in the current infrastructure by requiring the miners of one blockchain to either maintain a full copy or a light node of other blockchains.

Our proposal: Another way to allow one blockchain, the validator, to validate the publishing and verify the state of a smart contract in another blockchain, the validated, is to push the validation logic into the code of a smart contract in the validator blockchain. A smart contract in the validator blockchain is deployed and stores the header of a stable block in the validated blockchain. A stable block is a block at depth $d$ from the current head of the validated blockchain such that the probability of forking the blockchain at this block is negligible (i.e., a block at depth $\geq$ 6 in the Bitcoin blockchain [2]). A participant who deploys the smart contract in the validator blockchain stores the block header of a stable block of the validated blockchain as an attribute in the smart contract object in the validator blockchain. When the transaction or the smart contract of interest takes place in a block in the validated blockchain and after this block becomes a stable block, at depth $d$, a participant can submit evidence of the transaction occurrence in the validated blockchain to the miners of the validator blockchain. This evidence comprises the headers of all the blocks that follow the stored stable block in the smart contract of the validator blockchain in addition to the block where the transaction of interest took place. The evidence is submitted to the validator smart contract via a function call. This smart contract function validates that the passed headers follow the header of the stable block previously stored in the smart contract object and that the proof of work of each header is valid. In addition, the function verifies that the transaction of interest indeed took place and that the block of this transaction is stable and buried under $d$ blocks in the validated blockchain.

Figure 6 shows an example of a validator blockchain, blockchain2, that validates the occurrence of transaction $TX_{1}$ in the validated blockchain, blockchain1. In this example, there exists a smart contract $SC$ that gets deployed in the current head block of blockchain2 (labeled by number 2 in Figure 6). $SC$ has an initial state $S_{1}$ and stores the header of a stable block, at depth $d$, in blockchain1 (labeled by number 1). This header is represented by a red rectangle inside $SC$. $SC$’s state is altered from $S_{1}$ to $S_{2}$ if evidence is submitted to miners of blockchain2 that proves that $TX_{1}$ took place in blockchain1 in some block after the stored stable block in $SC$. When $TX_{1}$ takes place in blockchain1 (labeled by number 3) and its block becomes a stable block at depth $\geq d$ (labeled by number 4), a participant submits the evidence (labeled by number 5) to the miners of blockchain2 through $SC$’s function call (labeled by number 6). This function takes the evidence as a parameter and verifies that blocks in the evidence took place after the stored stable block in $SC$. This verification ensures that the header of each evidence block includes the hash of the header of the previous block starting from the stored stable block in $SC$. In addition, this function verifies the proof of work of each evidence’s block header. Finally, the function validates that $TX_{1}$ took place in some block in the evidence blocks and that this block has already become a stable block. If this verification succeeds, the state of $SC$ is altered from $S_{1}$ to $S_{2}$. This technique allows miners of one blockchain to verify transactions and smart contracts in another blockchain without maintaining a copy of this blockchain. In addition, this technique puts the evidence validation responsibility on the developer of the validator smart contract.

5 AC3WN Analysis

This section analyzes the AC3WN protocol introduced in Section 4.2. First, we establish that the proposed protocol ensures atomicity. Then we analyze the scalability of the witness network and how it affects the scalability of the commitment protocol. Finally, we explain how this protocol extends the functionality of previous proposals in [23, 16].

5.1 AC3WN: Atomicity Correctness Proof

Lemma 5.1

Assume no forks in the witness network, then the AC3WN protocol is atomic.

proof 5.2

Assume an AC2T executed by the AC3WN protocol and the atomicity of this transaction is violated. This atomicity violation implies that there exists two smart contract $SC_{i}$ and $SC_{j}$ in AC2T where $SC_{i}$ is redeemed and $SC_{j}$ is refunded. The redemption of $SC_{i}$ implies that there exists a block in the witness network where $SC_{w}$’s state is $RD_{auth}$ while the refund of $SC_{j}$ implies that there exists a block in the witness network where $SC_{w}$’s state is $RF_{auth}$. Since $SC_{w}$ is programmed to allow only the state transitions either from $P$ to $RD_{auth}$ or from $P$ to $RF_{auth}$, the two function calls to alter $SC_{w}$’s state from $P$ to $RD_{auth}$ and from $P$ to $RF_{auth}$ cannot take effect in one block. Miners of the witness network shall accept one and reject the other. Therefore, these two state changes must be recorded in two separate blocks. As there exists no forks in the witness network, one of these two blocks must happen before the other. This implies that either $SC_{w}$’s state is altered from $RD_{auth}$ in one block to $RF_{auth}$ in a following block or altered from $RF_{auth}$ in one block to $RD_{auth}$ in a following block. However, only the state transitions from $P$ to $RD_{auth}$ or from $P$ to $RF_{auth}$ are allowed and no other state transition is permitted leading to a contradiction. $\Box$

Lemma 5.3

Let $\epsilon$ be a negligible probability of forks in the permissionless witness network, then AC3WN protocol is atomic with a probability $1-\epsilon$.

proof 5.4

Assume an AC2T executed by the AC3WN protocol and the atomicity of this transaction is violated with a probability $p>>>\epsilon$. This atomicity violation implies that there exists two smart contract $SC_{i}$ and $SC_{j}$ in AC2T where $SC_{i}$ is redeemed and $SC_{j}$ is refunded. The redemption of $SC_{i}$ implies that there exists a block in the witness network where $SC_{w}$’s state is $RD_{auth}$ while the refund of $SC_{j}$ implies that there exists a block in the witness network where $SC_{w}$’s state is $RF_{auth}$. As $SC_{w}$’s states $RD_{auth}$ and $RF_{auth}$ are conflicting states, this implies that the block where $SC_{w}$’s state update to $RD_{auth}$ occurs must exist in a fork from the block where $SC_{w}$’s state update to $RF_{auth}$ occurs. The atomicity violation of the AC2T with a probability $p$ implies that the fork probability in the witness network must be $p$ leading to a contradiction. $\Box$

5.2 The Scalability of AC3WN

One important aspect of AC3 protocols is scalability. Does using a permissionless network of witnesses to coordinate AC2Ts limit the scalability of the AC3WN protocol? In this section, we argue that the answer is no. To explain this argument, we first develop an understanding of the properties of executing AC2Ts and the role of the witness network in executing AC2Ts.

An AC2T is a distributed transaction that consists of sub-transactions. Each sub-transaction is executed in a blockchain. An AC3 protocol coordinates the atomic execution of these sub-transactions across several blockchains. An AC3 protocol must ensure an atomic execution of the distributed transaction. This atomic execution of a distributed transaction requires the ACID [13, 15] execution of every sub-transaction in this distributed transaction in addition to the atomic execution of the distributed transaction itself. The ACID execution of a sub-transaction executed within a single blockchain is guaranteed by the miners of this blockchain. Miners use many techniques including mining, verification, and the miner’s rationale to join the longest chain in order to implement ACID executions of transactions within a single blockchain. The atomicity of the distributed transaction is the responsibility of the distributed transaction coordinator. Therefore, the main role of the witness network in the AC3WN protocol is to ensure the atomicity of the AC2T. Since the atomicity coordination of AC2Ts is embarrassingly parallel, different witness network can be used to coordinate different AC2Ts.

Assume two concurrent AC2Ts, $t_{1}$ and $t_{2}$. The atomic execution of $t_{1}$ does not require any coordination with the atomic execution of $t_{2}$. Each AC2T requires its witness network to ensure that either all sub-transactions in the AC2T are executed or none of them is executed. Therefore, $t_{1}$ and $t_{2}$ do not have to be coordinated by the same witness network. $t_{1}$ can be coordinated by one witness network while $t_{2}$ can be coordinated by another witness network. If $t_{1}$ and $t_{2}$ conflict at the sub-transaction level, this conflict is resolved by the miners of the blockchain where these sub-transactions are executed. Therefore, using a permissionless witness network to coordinate AC2Ts does not limit the scalability of the AC3WN protocol. Different permissionless networks are used to coordinate different AC2Ts. For example, the Bitcoin network can be used to coordinate $t_{1}$ while the Ethereum network can be used to coordinate $t_{2}$. Once a performance bottleneck is detected in a permissionless witness network, other permissionless networks can be potentially used to coordinate other AC2Ts. This ensures that the transaction throughput of an AC3 protocol is only bounded by the transaction throughput of the blockchains used to exchange the assets in an AC2T but not the witness network.

5.3 Handling Complex AC2T Graphs

One main improvement of the AC3WN protocol over the state-of-the-art AC3 protocols in [16, 23] is its ability to coordinate the atomic execution of AC2Ts with complex graphs. This improvement is achieved because the AC3WN protocol does not depend on the rational behavior of the participants in the AC2T to ensure atomicity. Instead, the protocol depends on a permissionless network of witnesses to coordinate the atomic execution of AC2Ts. Once the participants agree on the AC2T graph and register it in the smart contract $SC_{w}$ in the witness network, participants cannot violate atomicity as the commit and the abort decisions are decided by the state of $SC_{w}$. The state transitions of $SC_{w}$ are witnessed and verified by the miners of the witness network. Therefore, the publishing order of the smart contracts in the AC2T cannot result in an advantage to any coalition among the participants. Participants can concurrently publish their smart contracts in the AC2T, both in Figures 4 and 7, without worrying about the maliciousness of any participant.

Figure 7 illustrates two complex graph examples that either cannot be atomically executed by the protocols in [23, 16] or require additional mechanisms and protocol modifications to be atomically executed. These graphs appear in supply-chain applications. Both Nolan’s and Herlihy’s single leader protocol require the AC2T graph to be acyclic once the leader node is removed. Therefore, both protocols fail to execute the transaction graph shown in Figure 7a. Removing any node from the graph in Figure 7a still results in a cyclic graph. Herlihy presents a multi-leader protocol in [16] to handle cyclic graphs. However, both Nolan’s and Herlihy’s protocols fail to handle disconnected graphs similar to the graph shown in Figure 7b. On the other hand, the AC3WN protocol ensures the atomic execution of AC2Ts irrespective of the AC2T’s graph structure.

6 Evaluation

This section analytically compares the performance and the overhead of the AC3WN protocol presented in Section 4.2 to the state-of-the-art atomic swap protocol presented by Herilhy in [16]. First, we compare the latency of AC2Ts as the diameter of the transaction graph $\mathcal{D}$ increases in Section 6.1. Then, the monetary cost overhead of using a permissionless network of witnesses to coordinate the AC2T is analyzed in Section 6.2. Afterwards, an analysis on how to choose the witness network is developed in Section 6.3. Finally, an analysis of the AC2T throughput as the witness network is chosen from the top-4 permissionless cryptocurrencies, sorted by market cap, is presented in Section 6.4.

6.1 Latency

The AC2T latency is defined as the difference between the timestamp $t_{s}$ when an AC2T is started and the timestamp $t_{c}$ when the AC2T is completed. $t_{s}$ marks the moment when participants in the AC2T start to agree on the AC2T graph $\mathcal{D}$. $t_{c}$ marks the completion of all the asset transfers in the AC2T by redeeming all the smart contracts in AC2T.

Let $\Delta$ be enough time for any participant to publish a smart contract in any permissionless blockchain, or to change a smart contract state through a function call of this smart contract, and for this change to be publicly recognized [16]. Also, let $Diam(\mathcal{D})$ be the AC2T graph diameter. The $Diam(\mathcal{D})$ is the length of the longest path from any vertex in $\mathcal{D}$ to any other vertex in $\mathcal{D}$ including itself.

The single leader atomic swap protocol presented in [16] has two phases: the AC2T smart contract sequential deployment phase and the AC2T smart contract sequential redemption phase. The deployment phase requires the deployment of all smart contracts in the AC2T, $N$, where exactly $Diam(\mathcal{D})\leq N$ smart contracts are sequentially deployed resulting in a latency of $\Delta\cdot Diam(\mathcal{D})$. Similarly, the redemption phase requires the redemption of all smart contracts in the AC2T, $N$, where exactly $Diam(\mathcal{D})\leq N$ smart contracts are sequentially redeemed resulting in a latency of $\Delta\cdot Diam(\mathcal{D})$. The overall latency of an AC2T that uses this protocol equals to the latency summation of these two phases $2\cdot\Delta\cdot Diam(\mathcal{D})$. Figure 8 visualizes the two phases of the protocol where time advances from left to right. As shown, some smart contracts (e.g., $SC_{2}$, $SC_{3}$, and $SC_{4}$) could be deployed and redeemed in parallel but there are exactly $Diam(\mathcal{D})$ sequentially deployed and $Diam(\mathcal{D})$ sequentially redeemed smart contracts resulting in an overall latency of $2\cdot\Delta\cdot Diam(\mathcal{D})$. Note that the protocol allows the parallel deployment and redemption of some smart contracts as long as they do not lead to an advantage to either a participant or a coalition in the AC2T.

On the other hand, the AC3WN protocol has four phases: the witness network smart contract deployment phase, the AC2T smart contract parallel deployment phase, the witness network smart contract state change phase, and the AC2T smart contract parallel redemption phase. The witness network smart contract deployment requires the deployment of the smart contract $SC_{w}$ in the witness network resulting in a latency of $\Delta$. The AC2T smart contract parallel deployment requires the parallel deployment of all smart contracts, N, in the AC2T resulting in a latency of $\Delta$. The witness network smart contract state change requires a state change in $SC_{w}$ either from $P$ to $RD_{auth}$ or from $P$ to $RF_{auth}$ through $SC_{w}$’s Redeem or Refund function calls resulting in a latency of $\Delta$. Finally, the AC2T smart contract parallel redemption requires the parallel redemption of all smart contracts, N, in the AC2T resulting in a latency of $\Delta$. The overall latency of an AC2T that uses this protocol equals to the latency summation of these four phases $4\cdot\Delta$.

Figure 9 visualizes the four phases of the AC3WN protocol where time advances from left to right. As shown, all smart contracts in the AC2T are parallelly deployed and parallelly redeemed resulting in an overall latency of $4\cdot\Delta$.

Figure 10 compares the overall AC2T latency in $\Delta$s resulting from Herlihy’s protocol in [16] and the AC3WN protocol as the transaction graph diameter, $Diam(\mathcal{D})$ increases. As shown, the AC3WN protocol achieves a constant latency of $4\cdot\Delta$ irrespective of the transaction graph diameter value while Herlihy’s protocol achieves a linear latency with respect to the transaction graph diameter value. Note that the smallest transaction graph consists of two nodes and two edges and hence the graph diameter in Figure 10 starts at 2.

6.2 Cost Overhead

This section analyzes the monetary cost overhead of the AC3WN protocol in comparison to Herlihy’s atomic swap protocol in [16]. As explained in Section 2, miners charge end-users a fee for every smart contract deployment and every smart contract function call that results in a smart contract state change. This fee is necessary to incentivize miners to add smart contracts and append smart contract state changes to their mined blocks. As shown in Figures 8 and 9, both protocols deploy a smart contract for every edge $e\in\mathcal{E}$ where $\mathcal{E}$ is the edge set of the AC2T graph $\mathcal{D}$. This results in the deployment of $N=|\mathcal{E}|$ smart contracts in the smart contract deployment phase of both protocols. In addition, both protocols invoke a redemption or a refund function call for every deployed smart contract in the AC2T resulting in $N$ function calls. However, the AC3WN protocol requires to deploy an additional smart contract $SC_{w}$ in the witness network in addition to an additional function call to change $SC_{w}$’s state either from $P$ to $RD_{auth}$ or from $P$ to $RF_{auth}$. The cost of $SC_{w}$ deployment and $SC_{w}$ state transition function call comprises the monetary cost overhead of the AC3WN protocol. Let $f_{d}$ be the deployment fee of any smart contract $SC_{i}\in AC^{2}T$ and $f_{fc}$ be the function call fee of any smart contract function call. Then, the overall AC2T fee of Herlihy’s protocol is $N\cdot(f_{d}+f_{fc})$ while the overall AC2T fee of the AC3WN protocol is $(N+1)\cdot(f_{d}+f_{fc})$. This analysis shows that AC3WN imposes a monetary cost overhead of $\frac{1}{N}$ the transaction fee of Herilhy’s protocol assuming equal deployment and functional call fees for all the smart contracts in the AC2T.

But, How much does it cost in dollars to deploy a smart contract and make a smart contract function call? The answer is, it depends. Many factors affect a smart contract fee such as the length of the smart contract and the average transaction fee in the smart contract’s blockchain [27, 6]. Ryan [27] shows that the cost of deploying a smart contract with a similar logic to $SC_{w}$’s logic in the Ethereum network costs approximately $4 when the ether to USD rate is$300. Currently, this costs approximately $2 assuming the current ether to USD rate of$140.

6.3 Choosing the Witness Network

This section develops some insights on how to choose the witness network for an AC2T. This choice has to consider the risk of choosing different permissionless blockchain networks as the witness of an AC2T and the relationship between this risk and the value of the assets exchanged in this AC2T. As the state of the witness smart contract $SC_{w}$ determines the state of an AC2T, forks in the witness network present a risk to the atomicity of the AC2T. A fork in the witness network where one block has $SC_{w}$’s state of $RD_{auth}$ and another block has $SC_{w}$’s state of $RF_{auth}$ might result in an atomicity violation leading to an asset loss of some participants in the AC2T. To overcome possible violation, our AC3WN protocol does not consider a block where $SC_{w}$’s state is either $RD_{auth}$ or $RF_{auth}$ as a commit or an abort evidence until this block is buried under $d$ blocks in the witness network. This technique of resolving forks by waiting is presented in [22] and used by Pass and Shi in [25] to eliminate uncertainty of recently mined blocks. This fork resolution technique is efficient as the probability of eliminating a fork within $d$ blocks is sufficiently high.

However, a malicious participant in an AC2T could fork the witness blockchain for $d$ blocks in order to steal the assets of other participants in the AC2T. To execute this attack, a malicious participant rents computing resources to execute a 51% attack on the witness network. The cost of an hour of 51% attack for different cryptocurrency blockchains is presented in  [7]. If the cost of running this attack for $d$ blocks is less than the expected gains from running the attack, a malicious participant is incentivized to act maliciously.

To prevent possible maliciousness, the cost of running a 51% attack on the witness network for $d$ blocks must be set to exceed the potential gains of running the attack. Let $V_{a}$ be the value of the potentially stolen assets if the attack succeeds. Also, let $C_{h}$ be the hourly cost of a 51% attack on the witness network. Finally, let $d_{h}$ be the expected number of mined blocks per hour for the witness blockchain (e.g., $d_{h}$ = 6 blocks / hour for the Bitcoin blockchain). The value $d$ must be set to ensure that $V_{a}$ is less than the cost of running the attack for $d$ blocks $\frac{d\cdot C_{h}}{d_{h}}$. Therefore $d$ must be set to achieve the inequality $d>\frac{V_{a}\cdot d_{h}}{C_{h}}$ in order to disincentivize maliciousness. For example, let $V_{a}$ be $1M and assume that the Bitcoin network is used to coordinate this transaction. The cost per hour of a 51approximately$C_{h}=$300K$. Therefore,$d$must be set to be$>\frac{$1M\cdot 6}{$300K}=20$.

6.4 Throughput

The throughput of the AC2Ts is the number of transactions per second (tps) that could be processed assuming that every AC2T spans a fixed set of blockchains and is witnessed by a fixed witness blockchain. For an AC2T that spans multiple blockchains, the throughput is bounded by the slowest involved blockchain in the AC2T including the witness network. Let $tps_{i}$ be the throughput of blockchain $i$. The throughput of the AC2Ts that span blockchains i, j, .., n and are witnessed by the blockchain w equals to $min(tps_{i},tps_{j}..,tps_{n},tps_{w}$).

Table 1 shows the transaction throughput of the top-4 permissionless cryptocurrencies sorted by their market cap. An example AC2T that exchange assets among Ethereum and Litecoin blockchains and is witnessed by the Bitcoin network achieves a throughput of 7. The witness network should be chosen from the set of involved blockchains (Litecoin and Ethereum in this example) to avoid limiting the transaction throughput.

7 Conclusion

This paper presents AC3WN, the first decentralized Atomic Cross-Chain Commitment protocol that ensures the all-or-nothing atomicity semantics even in the presence of participant crash failures and network delays. Unlike in [23, 16] where the protocol correctness mainly relies on participants rational behaviour, AC3WN separates the coordination of an Atomic Cross-Chain Transaction, AC2T, from its execution. A permissionless open network of witnesses coordinates the AC2T while participants in the AC2T execute sub-transactions in the AC2T. This separation allows AC3WN to ensure atomicity of all the sub-transactions in an AC2T even in the presence of failures. In addition, this separation enables AC3WN to parallelly execute sub-transactions in the AC2T reducing the latency of an AC2T from O($Diam(\mathcal{D})$) in [16], where $Diam(\mathcal{D})$ is the diameter of the AC2T graph $\mathcal{D}$, to $O(1)$ irrespective of the size of the AC2T graph $\mathcal{D}$. Also, this separation allows AC3WN to scale by using different permissionless witness networks to coordinate different AC2Ts. This ensures that using a permissionless network of witnesses for coordination does not introduce any performance bottlenecks. Finally, the AC3WN protocol extends the functionality of the protocol in [16] by supporting AC2Ts with complex graphs (e.g., cyclic and disconnected graphs). AC3WN introduces a slight monetary cost overhead to the participants in the AC2T. This cost equals to the cost of deploying a coordination smart contract in the witness network plus the cost of a function call to the coordination smart contract to decide whether to commit or to abort the AC2T. The smart contract deployment and function call approximately cost $2555Assuming current ether to USD rate of$140. combined per AC2T when the Ethereum network is used to coordinate this AC2T.