Atomic Swaps with Asset Resolution on Corda

[Note that this is a research paper. As such it is shared for interest and education; it is not part of the product roadmap yet]

I’m Sotiria Fytraki, a software engineer in the research team of Richard G. Brown, the CTO of R3. This article is about a protocol that enables the atomic exchange of two different assets on Corda. Such a protocol is necessary for scenarios where we cannot have the two assets being swapped in the same transaction because they belong to different networks, otherwise we could just do a traditional DvP Corda transaction — right?

The protocol shows how to swap Asset1 (red) for Asset2 (blue) in a scenario where initially Asset1 belongs to PartyA in Corda Network1 (CN1) and Asset2 belongs to PartyB in Corda Network (CN2). The design assumes flow session interoperability between CN1 and CN2 (cross-trust-root interoperability). This form of interoperability is referred to as INTRACHAIN in Richard G. Brown’s article The Five Ingredients of Blockchain Interoperability. This protocol can also be used for Corda networks whose nodes do not communicate over flow sessions at all and thus have to rely on a web portal (or similar) for their communication — for instance by using FlowAsyncOperation API. Note that Corda does not currently support atomic swaps and flow session interoperability.

Both Parties have nodes on both networks: Party A’ is the node of PartyA in CN2, and Party B’ is the node of Party B in CN1. An important aspect of the proposed protocol is that the issuers of the assets are not involved in the assets exchange.

The protocol relies on time locks. The time aspect of the locks ensures that the assets are not locked forever and that they expire after an amount of time that is reasonable for the specific asset. The proposed atomic swaps design does not require any off-ledger intervention.

The information exchanged between the two networks does not require the nodes to have the same CorDapps installed because the networks exchange (simple) signed data structures — as opposed to transactions and backchains.

Corda Features

This section outlines the Corda features and components that are at the very core of the atomic swaps design.

Encumbrance States

The atomic swaps design requires a way to lock the assets that are about to be swapped (i.e., Asset1 and Asset2). Encumbrances come to rescue because they provide a mechanism to link states together and require that two (or more) linked states must be consumed together. Thus, one can use an encumbrance to lock a state (e.g., Asset1) and dictate additional rules (contract constraints) for the state’s consumption in the contract code of the lock. The original state (e.g., Asset1) and its contract remains unchanged.

The interested reader can find examples that show how to use encumbrances in the Corda OS codebase. As a starting point I would recommend the TransactionEncumbranceTests. If you would like to gain a deeper understanding of encumbrances, you can look into the implementation of the Chain Snipping CorDapp (also referred to as Transaction Breaks or Reissuance CorDapp). You can view a sample that shows how to use the Chain Snipping CorDapp and the associated documentation in the provided links.

Timestamp Authority

The proposed protocol requires an authority that can attest on the timestamp of the spent status of a state. The notary is the straight forward choice for this purpose. So, the protocol requires that given a StateRef the notary attests on the timestamp of the spent state — or the notary confirms that the state was not spent. The proposed design relies on a non-validating notary.

The fact that Corda networks already have a timestamp authority (i.e., Notary) allows for an atomic swaps design that does not require off-ledger intervention.

Regarding the balance of powers, swaps are controlled by the parties themselves, not by a centralised authority. Even if the parties need to consult the Notary, ultimately it is their decision whether they proceed with a swap or not.

The Protocol

First Step: PartyB Locks Asset2

PartyA proposes the exchange of Asset1 for Asset2 to PartyB (as shown in the figure below). PartyB inspects the proposal and decides to proceed with it. In doing so PartyB builds the transaction Tx0 which consumes Asset2 and generates an encumbered version of Asset2. The encumbered Asset2 has PartyB as its participant.

The rules of the encumbrance (which acts as a Time Lock) dictate that the encumbered Asset2 can be moved only to PartyA’ within the window {T2, T2+delta}. After T2+delta the encumbered Asset2 can only be moved back to PartyB.

Thus, the lock ensures that if Asset2 is spent in the time window {T2, T2+delta}, then it can only be transferred to PartyA’. The next steps of the protocol show that, if this happens, it can be made inevitable that Asset1 is transferred to PartB’ as well.

In the figure above and the ones that follow, states (i.e., Asset1, Asset2, Lock) are denoted by circles. Under each circle there is a rectangle which includes the state participants.

Second Step: PartyB builds Tx1 that will move Asset2 to PartyA’ if signed, but does not sign it yet

When Tx0 is finalised, PartyB builds Tx1; a transaction that will move Asset2 from PartyB to PartyA’ once signed but does not sign it yet. As explained in the previous step, the rules of the Lock are such that if Tx1 is signed in the time window {T2, T2 + delta}, Asset2 must have been transferred to Party A’.

After Tx1 has been built (but not signed), PartyB sends Tx1 to Party A’ which in turn inspects Tx1 on behalf of PartyA. Once PartyA’ has inspected Tx1, PartyA’ sends the TxId of Tx1 (0xbcde) to PartyA to CN1. The TxId is the root of the Merkle Tree of a transaction and is stored as a SecureHash in Corda. Note that PartyA and PartyA’ are nodes operated by/for the same entity.

In addition to the TxId, PartyA’ sends the key of Notary2 and PartyB along with the StateRef of the encumbered Asset2 (0xabcd[0]) to PartyA. The StateRef is necessary for the “Secondary Resolution Strategy” that will be detailed in Step 5.

Third Step: PartyA Locks Asset1

What does PartyA know at this point? PartyA in CN1 has just received four pieces of information from PartyA’ (which they trust): the TxId of Tx1 (0xbcde), the key of Notary2 and PartyB and the StateRef 0xabcd[0]. So this means PartyA knows several things. They know that the asset that they want to obtain is locked for the next time period and that if they see a signature from certain keys (PartyB and Notary2) over 0xbcde then it means that Asset2 is definitely theirs.

To proceed with the atomic swap, PartyA builds the transaction Tx2. The transaction Tx2 consumes the original Asset1 and creates an encumbered version of Asset1 which has two participants PartyB’ and PartyA. The encumbrance acts as a Lock. Specifically, the encumbrance dictates the following rules:

1. PartyB’ can unlock Asset1 if PartyB’ receives the signature of the Notary2 and PartyB from CN2 over 0xbcde in a time window of length two times delta {T1, T1+ 2 x delta}. In other words, if PartyB signs and notarises Tx1 then PartyB’ knows it can use this evidence to unlock Asset1.
2. Otherwise, after the expiration of the time window PartyA can reclaim Asset1 (explained in Step 5).

PartyA signs Tx2, notarises it and sends the encumbered Asset1 to PartyB’ (by providing a session with PartyB’ in the finality flow). So at this point PartyA and PartyB’ have a copy of the encumbered Asset1 in their respective Vaults. If PartyA wants to reclaim the asset after the expiration of the time window (because Tx1 has not been signed in CN2), the encumbered Asset1 is already in their Vault.

Finally, PartyB’ inspects and verifies Tx2 and the signatures on Tx2 in CN1 on behalf of PartyB. If the verification is successful, Party B’ instructs PartyB to sign Tx1 in CN2.

Fourth Step: PartyB signs Tx1 that moves Asset2

Once PartyB receives the instruction from PartyB’, PartyB signs Tx1 and sends it for notarisation. The transaction gets notarised if the time window has not expired yet. Then, PartyB sends the notarised transaction to PartyA’ by providing a session with PartyA’ in the finality flow. As a last action, PartyB sends the signature of Notary2 along with his own signature over the TxId of Tx1 (0xbcde) to PartyB’.

A potential attack lurks as PartyB may refuse to send Asset2 to PartyA’. This can demonstrate in Corda transactions in general, and is not related to the atomic swaps in specific.

In the case of atomic swaps the potential issue is that after signing and notarising Tx1, Party B’ (in collaboration with PartyB) can unlock Asset1 in CN1 while refusing to send Asset2 to Party A’. This is a situation where atomicity is violated because PartyB’ obtains Asset1 while PartyA’ does not obtain Asset2.

However, in the case of atomic swaps PartyA’ can detect this issue (i.e., if PartyB refuses to send Asset2 to PartyA’). This is possible because PartyA’ must have inspected Tx1 at the second step of this protocol and thus PartyA’ knows the StateRef of the encumbered Asset2 (i.e., 0xabcd[0]). As a result PartyA’ can query Notary2 and figure out if the encumbered Asset2 has been spent in the given time window. Thus, PartyA’ has a way to detect this attack.

Fifth Step: Resolution Strategy for Asset1

As described in the fourth step, in the time window {T2, T2 +delta}, PartyB decides if they will move Asset2 to PartyA’, and if so PartyB signs and notarises Tx1. So, there is also a possibility that PartyB decides not to move Asset2 — by not signing Tx1. There is also a possibility that Tx1 has been signed but the associated network messages have been delayed because of network delays or malicious intent. All these scenarios are possible in a distributed multi-party environment. In the remainder of this section we describe the potential scenarios one by one and we explain how the proposed protocol details with each of them.

Let’s start with the scenario where PartyB signs Tx1 in Step 4 and PartyB’ receives the signed TxId from CN2 within the time window two times delta and uses it to unlock Asset1 (figure below). In other words, the evidence that Tx1 has been signed is received before the expiration of the Lock of Asset1, and the atomic swap completes successfully (i.e., Asset1 is moved to PartyB’ and Asset2 is moved to PartyA’).

But what happens if PartyB’ has not received the signed TxId at the end of the time window? In this case we will employ the secondary resolution strategy.

The secondary resolution strategy is based on three tactical moves: (1) to lock the Asset2, in step 1, (2) to assign two participants to the encumbered Asset1, in step 3, and (3) to share the StateRef 0xabcd[0] with PartyA in CN1 and include it in Tx2. So, now we are ready to execute the resolution strategy for the Asset1 past the end of the time window (i.e., T1+two times delta). PartyA and/or PartyB’ can drive the resolution and use the StateRef 0xabcd[0] to query Notary2 in CN2. There are three potential scenarios:

1. The locked Asset2 has not been spent. In this case PartyA can reclaim their asset because Asset2 can only be transferred back to PartyB at this point.
2. The locked Asset2 has been spent after T2+delta, and now must have been transferred back to PartyB. In this case PartyA can reclaim their asset.
3. The locked Asset2 has been spent within the time window {T2, T2+delta} and now belongs to PartyA’. Asset2 has been transferred to Party A’ via Tx1 or Tx1’. Tx1' is identical to Tx1 with one difference: Tx1' has a different TxId — because it is a different transaction. PartyB’ transfers Asset1 to themselves and includes the TxId (either Tx1 or Tx1') in the transaction. Please note that the secondary strategy is not based on the TxId but it is rather based on the StateRef 0xabcd[0].

The Notary must offer a flow which queries the spent status of a StateRef. If the state has been spent, the flow also obtains the associated timestamp.

For the common case scenario, the protocol employs the primary resolution strategy (which does not rely on information obtained by the Notary as it only relies on information exchanged between the two parties) and then uses the secondary resolution strategy otherwise. Thus, this approach reduces the traffic to the Notary.

A provisional patent with this protocol has been filed in the US patent office.

Acknowledgements

Kostas Chalkias, Stefano Franz, Will Hester, Stefan Iliev and Matthew Bradbury have done work in the area of atomic swaps. Thanks to Richard G. Brown for his input to this work.