DLT Interoperability and More ⛓️#20 —Atomic cross-chain exchanges of shared assets ⛓️

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

This edition covers a paper on a paper on atomic cross-chain swaps from late 2022.

Photo by Gabrielle Henderson on Unsplash

➡️ Title: Atomic cross-chain exchanges of shared assets
➡️ Publication: AFT 2022

➡️ Authors: Krishnasuri Narayanam, Venkatraman Ramakrishna, Dhinakaran Vinayagamurthy, Sandeep Nishad

➡️ Paper source: https://arxiv.org/pdf/2202.12855.pdf

➡️ Background:

The paper explains formally generalized atomic cross-chain swaps (in Section 2). We explain atomic swaps, informally, in our paper “Do You Need a Distributed Ledger Technology Interoperability Solution?” (page 20, Solution Type 2, “Cross-Authentication”).

From our paper:

“Cross-authentication interoperability solutions allow parties to exchange assets across DLTs, where each party sends a transaction on each DLT. To this end, parties need to authenticate on both chains to perform the transfers. This process typically happens without a trusted third party, as what is needed is some of-chain synchronization to set up the transactions to happen in both chains. rustless Asset Exchanges correspond to one asset exchange with non-mediated communication. The de-facto method for implementing this scheme are Hash Lock Time Contracts (HTLCs), where both parties deploy a smart contract in each chain that transfers the right amount of coins to the other party. HTLCs consist in facilitating an asset exchange between two parties (typical case, although multi-party HLTCs exist [12, 64]) on a different blockchain (both parties can access it).

Party from DLT 1 (P1) creates a secret s such that the hash of the secret, h(s) is put in a smart contract on DLT 1, transferring an asset to P2. The contract is hash locked with s, and a timelock t. Thus, P2 can redeem the assets from DLT 1 with secret s until time t. Upon confirming that the contract is correctly instantiated, P2 can create a smart contract on DLT 2 with the same hashlock h(s) but a timelock t’ < t. The smart contract sends assets to P2 from DLT 2. This ensures that P1 can redeem assets before P2, with a slack t-t’. When P1 asserts that the contract from P2 is published, that party can send secret s, redeeming its assets. P2 now holds secret s, and can use it to redeem its assets on DLT 1.

HTLCs imply handling the technical layer (the hashing functions that are used to construct the secret needs to be supported by the involved DLTs) and the semantic layer (the information exchanged has mean.”

Onto the paper!

➡️ Contributions:

• The authors propose a model of asset exchanges across DLT networks
• The authors propose MPHTLC, an augmented HTLC protocol for atomic multi-owner-and-asset exchanges

💪 Strong points:

• The paper is one of the first (if not the first) to propose handling cross-chain atomic swaps in a multi-ownership scenario by a group of mutually distrusting parties.
• The authors capture a subtle attack when co-ownership is involved (Section 2.1). Although these attacks are not verified now (AFAIK), in a future where blockchain gateways perform asset transfers across chains, and for complex assets owned by multiple-gateways, this attack could occur. Furthermore, the topic of multi-asset exchanges will become more relevant, as this will be an optimization for single asset exchanges (a multiple asset exchange can be decomposed in multiple single asset exchanges, I suppose by definition :-) )
• The provided implementation, Hyperledger Labs Weaver, is a well-tested, real-world implementation interoperability project. It was recently merged with Hyperledger Cactus, yielding Hyperledger Cacti. For more on Weaver/Hyperledger Cacti, please visit this workshop video.

🤞 Suggestions for improvement:

• Although the implementation seems to have a huge engineering effort, the evaluation could have been a bit more comprehensive: the authors only evaluate the total latency for the different operations on two chains. Experiments about the scalability as a function of the number of participants and different distributions over asset ownership would have been interesting.

🔥 Points of interest:

• The authors describe the “happy” path of an HTLC (where we are exchanging an asset 𝑀, owned by party 𝑋 in ledger L1, for asset 𝑁, owned by party 𝑌 in ledger L2):”

1. 𝑋 hashes secret 𝑠 to produce 𝐻 = 𝐻𝑎𝑠ℎ(𝑠);

2. 𝑋 locks 𝑀 on L1, specifying 𝑌 as the recipient, with 𝐻 as guard for duration 𝑇 using a blockchain or smart contract transaction •

3. 𝑌 similarly locks 𝑁 on L2 with 𝐻 (now publicly known), specifying 𝑋 as the recipient, for duration 𝑇 /2

4. 𝑋 claims 𝑁 on L2 by revealing 𝑠 (which, when hashed, must match 𝐻) via a transaction within 𝑇 /2

5. 𝑌 similarly claims 𝑀 on L1 by supplying 𝑠 (now publicly known) after 𝑋’s claim but within 𝑇”

• The basic foundation of the proposed protocol “are built on these fundamental operations:

1. Unconnected Local Transfers (ULTs): A pair of asset transfers in two ledgers where neither the initial nor the final owner of one asset matches the initial or final owner of the other asset (as illustrated in Figure 5a). In effect, these transfers are not interdependent and can be executed simply as smart contract invocations localized to the respective ledgers. None of the involved parties have an atomicity requirement.

2. Cross-Ledger Replacements (CLRs): A pair of transfers where the initial owner of one asset is the same as the final owner of the other (as illustrated in Figure 5b).

3. Cross-Ledger Swaps (CLSs): A pair of transfers where the initial owner of one asset is the same as the final owner of the other and vice versa (as illustrated in Figure 5c and also earlier in Figure 1).”

• Section 2.3 then shows how to combine the fundamental operations to build cross-ledger transactions.
• The proposed protocol works by avoiding attacks on the following two scenarios.

1. The first, “• multiple co-owners must lock an asset first before making a joint claim for an asset in another ledger, as described in case (1) in Section 2.5 (also see Figure 3)”:

Solution:

2. The other scenario is “co-owners of different assets must lock their respective assets first before making a joint claim for an asset in another ledger, as described in case (2) in Section 2.5 (also see Figure 4)”:

Solution:

For the details and proofs, please refer to the paper.

🚀 What are the implications for our work?

• In a future where blockchain gateways will transact assets, asset exchanges can be made more efficient by leveraging MPHTLC, to accommodate where mutually distrusting groups own assets.