DLT Interoperability and More ⛓️#5 ⛓️ — Universal Atomic Swaps: Secure Exchange of Coins Across All Blockchains

In this series, we analyze papers on blockchain and interoperability (and both).

This edition covers a recent paper on atomic swaps

Photo by Maxim Hopman on Unsplash

➡️ Title: Universal Atomic Swaps: Secure Exchange of Coins Across All Blockchains
➡️ Authors: Sri Aravinda, Krishnan Thyagarajan , Giulio Malavolta , Pedro Moreno-Sánchez

➡️ Source: https://eprint.iacr.org/2021/1612

➡️ Background:

Interoperability is important to study because it allows blockchains (firstly built as siloes by default) to communicate together. The communication of different blockchains creates network effects, similar to the rise of the internet, leading to the creation of multi-billion dollar industry.
However, interoperability is hard to be considered a solved challenge, due to several reasons we study in a future article. This paper provides an advance to the state of the art in this discipline.

Properties that the authors consider important for an atomic swap protocol:

1. non-custodial, departing from a third party trusted holding the coins from users during the exchange;

Several protocols like ODAP allow secure exchange of assets under a custodial model. This model is probably adequate for institutions and businesses that are registered in the centralized world.

2. universal, that is, compatible with all (current and future) cryptocurrencies;

The authors search for a generalizable protocol that can accommodate a variety of cryptocurrencies. This is an interesting property, since performing decentralized asset transfers (for the meaning of asset transfer vs. asset exchange see our paper Do You Need a Distributed Ledger Technology Interoperability Solution?) typically requires handling the intricacies of each blockchain. Discovering the root technical requirements (or more formally, an ideal functionality) for a blockchain to enable arbitrary asset transfers is indeed very interesting.

3. multi-asset, supporting the exchange of multiple coins in a single atomic swap.

It should allow the composition of multiple single asset transfers in one session. This allows for improving the efficiency of 1-n or even n-n transfers, something we are also studying (see Hermes and our upcoming paper).

➡️ Contributions:

• The authors provide an asset transfer protocol satisfying the properties: of non-custodial, universal, and multi-asset. The protocol has minimal technical requirements (only that the underlying blockchains have the ability to verify signatures) and can perform n-n transfers of different cryptocurrencies.
• The authors provide an implementation (not open sourced) and an evaluation for the case of blockchains supporting Schnorr/ECDSA (which we do not cover in this article)

💪 Strong points:

• The authors do in my opinion, an excellent introduction to what is a hash time lock contract and how can atomic swaps be implemented.
• The authors can find a way not to require on-chain scripts (e.g., smart contracts) to realize atomic swaps. This is typically not straightforward, because HTLCs (and other atomic swaps mechanisms such as Hermes) require tracking time to implement timeouts. Timeout allows recovery from crash faults and avoids deadlocking (when a user purposely does not want to complete a transfer). This scheme then relies on parties wanting to perform asset exchanges collectively owning an address.
• The scheme is straightforward, although complex. First, both parties create a jointly managed account, each one having a share on that account (on the account’s private key, specifically). Then, parties sign a refund transaction, which is triggered after a timeout. Then, the secret creation phase happens. In HTLCs it is a hash of a secret; in this scheme, a “locked” version of a signature, computed via 2 party computation acts as the secret. One of the signatures to unlock an asset depends on the other (the “secret”), in a way that when one asset is redeemed, the next one can be redeemed as well.
• An assumption the protocol does is that an adversary cannot prevent a party to perform computation offline (i.e., being offline), similarly to the assumption in HTLCs. However, in that case, with the proposed protocol the price to pay is local computation versus on-chain computation (in the case of HTLCs, incurring transaction fees).

😞 Limitations:

• It is true that atomic swaps can be implemented with HTLCs, but there are some attacks that can hamper the atomicity property. In particular, when Bob receives a secret r to unlock the hash lock on the target chain, the transaction doing the unlocking may be unsuccessful. If that is the case, we have a situation where Alice obtained her assets but Bob didn’t, violating the atomicity property (which, by extension can be considered a consistency property across chains).
• The implementation and evaluation stand short because only the performance of the key functions that allow the locking of assets is tested, in a dummy end-to-end asset transfer. The overhead for the setup phase (in terms of computational effort), is not provided.

🔥 Points of interest:

• “an atomic swap must preserve fungibility, that is, an observer (other than Alice and Bob) of the ledger should not distinguish a transfer executed as part of an atomic swap from a standard asset transfer in such ledger. “. In cross-chain asset swaps, (asset transfers) this property is not conserved, because the transferred assets are representations of that asset in a source blockchain. However, asset exchanges (which is the object of study of this paper) preserve that property (typically implemented with HLTCs)
• It would be interesting if the authors said what are the trust assumptions on “Even among existing cryptocurrencies, atomic swaps (and consequently secure exchange) are limited to a handful of combinations of cryptocurrencies, or require one to accept strong trust assumptions. “
• I’m not sure what the authors mean by “As a byproduct of such generality, such atomic swap transactions are identical to standard one-to-one transactions, thereby increasing the fungibility of the swapped coins. “
• The authors consider that, for a protocol to be universal, they should be able to offer a “signature verification script for authenticating transactions “. It assumes a general-purpose 2-party computation (2PC) protocol and the existence of a verifiable timed signature. I am not sure if this is the appropriate definition for a universal protocol, given the assumptions, and would like the authors to have discussed this a bit more.
• I think I’ve found a typo: “A timeout t for a transaction tx means that the transaction is accepted by the nodes in the network, only after time t has expired “ -> “A timeout t for a transaction tx means that the transaction is accepted by the nodes in the network, only BEFORE time t “
• the protocol seems much more complex than a simple HTLC. It requires users to control a joint address, as the basis for the atomic swaps. In fact, this scheme looks similar to payment channels, where there are signed commitments on returning funds to the original owner in case a party goes offline (and also because most of the processing seems to be happening off-chain). The setup phase (namely setting joint accounts) does not provide enough detail on the resources needed (in terms of time and transactional cost).

🚀 How does it relate to our work at Técnico Lisboa, INESC-ID, and Blockdaemon? (views are my own and do not necessarily reflect the opinions of my employer)

• Enabling secure, scalable interoperability is an important part of what we do at Blockdaemon. Studying cheaper ways to perform atomic swaps is of interest to support growing blockchain ecosystems, that take interoperability as an important factor.

🚀 What are the implications for our work?

• Given the mission above, there are applications for studying universal atomic swaps. This has applications to several research areas, allowing us to reason how could an attacker take advantage of a n-n atomic swap.
• Multi-asset swaps are important to protect against front-running and back-running because for large values, manipulating the price of an asset during the exchange path a1->a2-> … -> a might translate into losses for the user conducting the trade.