Cross-Chain Atomic Swaps

Exploring the problems associated with Cross-Chain Atomic Swaps

Introduction

Exchanging value on the blockchain is extremely easy — find the address of where you want to send your token and go! Turing complete chains even allow more complex exchanges to be created through the use of smart contracts. However, if somebody wishes to swap their ETH for ADA they will need to go through a centralised exchange.

Whilst these services do allow people to easily swap tokens they go against the grain of decentralisation. The question then arises of how can we exchange value without a third party, whilst still maintaining the atomicity of the exchange where Alice pays Bob if and only if Bob pays Alice.

When designing distributed systems actors are free to behave as they choose, therefore mechanisms should assume that every scenario is adversarial and that the two parties are always looking to act within their own self-interest (i.e., if there are any weaknesses that can be exploited in the mechanism — they will be).

Ion stage 1 explored how value could be exchanged atomically across separate turing-complete blockchains by two parties Alice and Bob without a third party of any kind. However there were a number of ways in which Alice could cheat Bob. The project was based on a one-way exchange and intended to explore its weaknesses.

In this article we explore the problems associated with these atomic transactions. starting with a very basic one-way exchange which only works if both parties behave, followed by a description of potential solutions.

One-Way Exchange

In the one-way exchange it is not possible for neither Alice or Bob to withdraw the funds of the other without depositing their own funds.

The happy path flow is:

• A. Alice deposits funds on chain A, with a hashed preimage as reference
• B. Bob sees the hashed preimage and uses it as the reference for his deposit on chain B, he however does not know the preimage used to create the hash
• C. Alice withdraws Bob’s deposit using the secret, which is now published for Bob to see
• D. Bob can now withdraw on chain A

This unfortunately only works if both parties are benevolent, and breaks if:

• Bob never deposits, then Alice cannot withdraw
• Both deposit but Alice never withdraws, which prevents Bob from withdrawing

The solution to this seems obvious, a refund function. However, as discussed in the following sections adding the ability to refund presents its own problem set.

Solutions

In order to solve the issues of the one-way exchange many concepts were developed. Extremely simple and complex mechanisms were conceived to allow a party to refund if the other did not behave as required to complete the exchange.

Below are a number of interesting ideas which each highlight a different problem associated with cross- chain atomic swaps.

Ion Forged Proof

Ion stage 1 allows a transaction to be performed across two chains, but only if the happy path is followed:

• A. Alice deposits
• B. Bob Deposits
• C. Bob sends signed proof of deposit to Escrow Contract on Chain A, blocking Alice from refunding
• D. Alice sends signed proof of deposit to Escrow Contract on Chain B, blocking Bob from refunding
• E. Bob withdraws
• F. Alice withdraws

It does not function however as both Alice and Bob can create a fraudulent proof without depositing.

The immediate reaction to this is to make it that the proof of the deposit is submitted by the other party of the trade. This solution also fails, because there isn’t any incentive for a party to allow the other to withdraw, once they have withdrawn the funds. Meaning once Alice submits Bob’s proof of deposit, allowing Bob to withdraw, there isn’t any reason forcing Bob to allow Alice to withdraw.

Another clear issue is that they can refund themselves, even if the other chain has been locked. Meaning that a party can withdraw after the other chain is locked for refunding.

Bonded Lock Chain Exchange

A bonded chain exchange is shown in the image above. This solution uses a bond and two timers, operating on chain A only, to try to get Alice and Bob to behave. Starting at the empty position the happy path flow follows:

• A. Alice proposes a trade agreement i.e. exchange value, timeout length and bond value
• B. Bob confirms the trade agreement with his signature
• C. Alice republishes the trade agreement on chain B
• D. Bob confirms the trade agreement with his signature
• E. Alice deposits the agreed value on chain A
• F. Bob posts his bond on chain A, locking the deposit of Alice activating the timer T1
• G. Bob deposits the agreed value on chain B
• H. Bob submits the proof of this transaction on chain A, canceling timer T1 activating timer T2 I. Alice agrees she has seen the deposit on chain B
• J. Bob withdraws from chain A
• K. Alice withdraws from chain B

This mechanism fixes a number of issues as Alice is always able to refund until Bob posts his bond, then once Bob’s bond is a timer is started which gives an agreed number of blocks in which Bob can submit a proof of his deposit on chain B.

If Bob does not submit a proof within the timeout his bond is made available for Alice to withdraw.

This should give Bob incentive to deposit and provide the proof in an amount of time to which he has agreed. Nonetheless Bob may not deposit and just provide a false proof, however to deter Bob from doing so Alice must also verify the proof. Once this proof has been verified, the reference that allows Bob to withdraw is made public, if not the contract reverts to the previous state.

Allowing Alice to verify Bob’s proof gives her power to deny even technically valid submissions. Thus Alice is left with the ability to eternally lock funds by perpetually denying Bob’s verification.

So we see that even in this design whereby neither party can defraud the other completely, it is sufficient for Alice to want to cause Bob harm for the mechanism to break down.

Refundable Hash-Lock

Refundable hash-lock superficially fulfills the requirements of an atomic swap. We protect each participant by delegating the responsibility of a secret pre-image to each of them. One party chooses the reference for the refund, the other that of the withdrawal. The holder of the refund reference always initiates the trade. This allows them to refund if their counterparty does not engage. Since the counterparty only deposits if they wish to engage in the trade, their lack of ability to refund is not a concern.

Splitting the responsibility means that neither party has ability to attempt to perform both a withdrawal and a refund simultaneously protecting both parties from cheating each other.

Off chain:

• Bob selects RefundRef
• Alice select WithdrawRef
• Alice and-Bob agree on a trade agreement and exchange H(RefundRef) and H(WithdrawRef)

On chain:

• A. Bob deposits his funds with the trade agreement on chain B
• B. Alice deposits her funds with the trade agreement on chain A
• C. Alice withdraws from chain B with WithdrawRef
• D. Bob witnesses WithdrawRef and withdraws from chain A with it

If Bob does not deposit his funds under the same trade agreement i.e. the wrong hashes were supplied, Alice simply does not deposit.

If Alice deposits and Bob then attempts to refund, he supplies the RefundRef in his refund which Alice witnesses and uses it to refund her own funds. Note that Bob cannot simultaneously attempt to refund because Alice holds the knowledge of the WithdrawRef required.

If Alice attempts to withdraw by supplying WithdrawRef required, she cannot simultaneously attempt to refund because Bob holds the knowledge of the RefundRef required.

This set up means that neither party can exploit the other in the traditional manner. However a transaction withholding attack by either party compromises the otherwise secret information:

• If both parties deposit and Alice attempts a withdrawal with WithdrawRef, this transaction is included in the TxPool. Bob can then scour the transaction pool, extract WithdrawRef, issue a withdrawal from chain A and a refund from chain B by attempting to hold back Alice’s withdrawal. He can do this if he happens to be the miner of the next block and choose which transactions to include or if he floods the network with higher gas-paid transactions to attempt to encourage other miners to exclude Alice’s transaction.
• If both parties deposit and Bob attempts a refund with RefundRef, this transaction is included in the TxPool and a similar attack as above is carried out.

Conclusion

Cross-chain atomic swaps present a holy grail in terms of the decentralisation of payments, an extremely simple way for two parties to exchange value with as little information swapping as possible.

However finding a solution that is truly atomic presents a number of key problems. Clearmatics intends to investigate further the possibility of cross-chain atomic swaps and also the development of incentive structures to validate parties actions across separate chains.

Read about Ion here & stay tuned for more!

Friedrich Grabner, Blockchain Engineer, Clearmatics
Chris Chung, Blockchain Engineer, Clearmatics
Duarte Aragão, Senior Blockchain Engineer, Clearmatics

Tweet us @Clearmatics