Atomic Cross-Network Swaps
The below is a deep dive into the technology powering instant settlement at sparkswap, a new way to trade cryptocurrencies without depositing assets on an exchange. It is a technical article, and it is recommended that readers be familiar with the Lightning Network and Atomic Cross-chain Swaps.
Trustless atomic cross-chain swaps have been hailed as a potential solution to the problem of custodial cryptocurrency exchanges, but have largely failed to deliver in terms of significant user adoption. I would argue that a significant reason for that failure is the unacceptably slow speed of finality for trading of ordinary amounts.
Atomic swaps using Layer 2 solutions like the Lightning Network (and Payment Channel Networks more generally) have the potential to increase the speed of these swaps significantly, but to date have been largely implementation-specific demonstrations.
Cross-Network Preimage Retrieval is a new mechanism for trustless atomic swaps over Payment Channel Networks that increases potential currency support and simplifies implementation while maintaining the atomic and trustless properties of an on-chain swap.
Custodial Exchanges re-introduce risk
Cryptocurrency trading today is largely done on custodial exchanges, wherein users deposit their currencies with the exchange directly, perform trading within the exchange’s system, and then withdraw their new currency balance at a later time. This structure, while simplest to set up from the exchange’s perspective, re-introduces custodial risk to a system (Bitcoin/cryptocurrency) that is designed to remove custodial risk and provide financial sovereignty to its users. “Not your keys, not your Bitcoin”, as Andreas Antonopoulous so succinctly put it.
Custodial exchanges, as a result, exhibit all of the problems of the traditional financial system, although in some cases exacerbated by the new and mostly unregulated nature of the industry. Billions have been stolen from exchanges over the past few years, assets are frequently frozen by local governments or users simply can’t move currency out due to operational backlogs.
Atomic swaps are too slow for trading
Trustless atomic swaps are a potential solution to this problem. Using properties native to cryptocurrencies (e.g. Script), users can construct a swap between currencies on two different blockchains in which the transaction is trustless between the parties, requires no trusted intermediary, and is atomic (i.e. it either completes or it does not, it cannot be partially completed).
Decred has published an atomic swap contract in Script that is simple and easy to follow, and produced a sample implementation for swapping several currencies (that research was extended to include Ethereum).
However, using atomic swaps via on-chain transactions takes considerable time to remain trustless — in the case of trades using Bitcoin, by far the most liquid cryptocurrency, these swaps take over an hour to finalize. For trading currencies in which prices move in seconds and minutes, such slow finalization would result in one party or the other backing out of the trade for all but the largest of transactions. As a result, they do not lead to a slow settling exchange as might be expected, but rather to no exchange at all.
Some projects are using a combination of 0-confirmation transactions and dedicated arbiter nodes or similar systems to try to increase speed of the swaps, which diminishes the trustless nature of the swap. Others are taking advantage of the latency aspect of on-chain swaps to build them into transactions resembling option contracts — a promising area of research, but one that does not solve the problem of spot trading.
Lightning Network swaps are currently limited
Layer 2 solutions like the Lightning Network solve the transaction finality speed problem in Bitcoin and other cryptocurrencies in a general fashion, and can be used in atomic swaps as well. Indeed atomic swaps are listed as a potential application of the Lightning Network in its whitepaper. Lightning Labs demonstrated a BTC/LTC swap using the Lightning Network Daemon in late 2017.
But these Layer 2 swaps have remained largely demonstrations, and have only been demonstrated with two currencies that can support the same Layer 2 network specification, in the case of the Lightning Network, BOLT. While the BOLT specification is by far the most mature of the Payment Channel Networks, it was built for Bitcoin (rightfully so), and may not be able to support as many currencies as users would like to swap. The development of Raiden as a non-BOLT-compatible network is a clear step in that direction.
As a hybrid solution between on-chain and off-chain swaps, Alex Bosworth created Submarine Swaps, which allows users to use on-chain transactions to pay Lightning Network invoices. That software has broadened interoperability with other currencies and provided a unique perspective on Lightning Network invoices. However, it is still limited in settlement speed due to on-chain transactions.
Cross-Network Preimage Retrieval
Building on the work of the Lightning Labs team and Alex Bosworth in particular, we’ve developed a new mechanism to execute trustless atomic swaps between currencies using Payment Channel Networks like the Lightning Network that:
- Increases the potential reach of swaps to additional blockchains and currencies
- Simplifies the implementation of swaps
- Maintains the trustless and atomic properties of swaps
We call this mechanism Cross-Network Preimage Retrieval.
Before I explain the specific construction for this mechanism, I’ll provide a brief background on Payment Channel Network Payments and Swaps, two critical components to understand Cross-Network Preimage Retrieval.
Payment Channel Network Payments
In Payment Channel Networks like the Lightning Network, payments are mediated by a preimage that is known only to the recipient of the eventual payment. Payment is irrevocably promised along the route from the origin (payer) to the destination (payee) with each node irrevocably promising to pay the next node a given amount if they present the preimage that corresponds to a hash.
To redeem her payment, the destination node presents the preimage to the penultimate node, transferring the promised currency and finalizing the payment. The penultimate node then uses that preimage to redeem the payment he is due, and so on, triggering an entire settlement chain backward along the route to the origin, leaving the origin node with less currency, the destination node with more, and each intermediate node with no change in balance (except for fees extracted).
The contract used to irrevocably promise payment upon receipt of the preimage in the Lightning Network is a Hashed Timelock Contract.
Payment Channel Network Swaps
An atomic swap using a Payment Channel Network is best thought of as a circular payment. If the simplest multi-hop payment is along a route from User A to User X to User B all on the same blockchain, then the simplest swap is along a route from User A to User B on blockchain 1, and from User B to User A on blockchain 2. This payment is a loop with its origin at User A on blockchain 1 and its destination at User A on blockchain 2. Since this is all part of one route and tied to one preimage and hash, its outcome is atomic. If the swap succeeds, User A winds up with less of the currency on blockchain 1, and more of the currency on blockchain 2 (User B has the inverse outcome).
As they have been demonstrated to date, Payment Channel Network swaps rely on User B operating his node on both Blockchain 1 and Blockchain 2 so that he can receive a promise for payment (HTLC) on Blockchain 1, and extend a promise for payment on Blockchain 2, and settle backwards across the route in the case of a successful swap.
This setup introduces significant difficulties for User B, namely:
- The software he runs must support every blockchain he wishes to trade between (or: that he must have software that supports every pair he wishes to trade)
- The payment forwarding mechanism must support swaps natively and have access to (or logic for) the user’s trading preferences
#1 significantly limits compatibility both in theory and in practice, and #2 significantly increases implementation complexity.
Cross-Network Preimage Retrieval Swap
A Payment Channel Network Swap using Cross-Network Preimage Retrieval requires every participant to operate three components:
- A payment channel network node for each different network (two nodes total)
- A node connecting the payment channel network nodes, which we call the Interchain Router
These components are all controlled and operated by the same user, so the interaction mode between them is semi-trusted.
Prepare Swap
To setup the swap, User A, the initiating party, creates an invoice with a preimage known only to her on her Payment Channel Network node operating on blockchain 2. She sends the hash of this preimage to User B out-of-band.
User B, the translating party, creates a invoice on his Payment Channel Network node operating on blockchain 1 for the hash sent by User A. Since User B does not know the preimage for this invoice, he marks it as an External Preimage invoice, or an invoice for which the preimage is stored externally.
Initiate Swap
User A then initiates the swap by extending an irrevocable promise of payment upon receipt of the preimage (HTLC) from her PCN node on blockchain 1 to User B’s PCN node on blockchain 1.
User B’s PCN node on blockchain 1, upon receiving this promise of payment, would normally reject it since it does not have the preimage to redeem it. In our case, User B has created a special External Preimage invoice indicating that the preimage for the payment is available on an external service. User B’s PCN node on blockchain 1 makes a request for the preimage from an external service, which in our case is the Interchain Router.
Translate Swap across blockchains
The Interchain Router makes a determination about whether to proceed with the swap based on the price, the counterparty, and size. If the Interchain Router does decided to proceed with the swap, it translates the payment by using User B’s PCN node on blockchain 2 to extend an irrevocable promise of payment upon receipt of the preimage (HTLC) to User A’s PCN node on blockchain 2.
Settle final leg of swap
User A’s PCN node on blockchain 2, upon being extended this payment for a preimage which it knows (see step 1), settles the payment, thus revealing the preimage to User B’s PCN node on blockchain 2.
Translate preimage across blockchains
User B’s PCN node on blockchain 2 returns the preimage to the Interchain Router (which initiated the payment). Once the Interchain Router has the preimage, it can return the preimage to User B’s PCN node on blockchain 1.
Settle initial leg of swap
Now in possession of the preimage for the payment extended to it, User B’s PCN node on blockchain 1 settles the initial payment, triggering settlement back to User B’s PCN node on blockchain 1.
Swap Result
The result is User A reducing currency on blockchain 1 in exchange for currency on blockchain 2, and User B the inverse.
In normal operation, this swap would settle in about as much time as it takes to make two payments on the respective Payment Channel Networks, which in the case of the Lightning Network is typically in the hundreds of milliseconds.
Increased Interoperability
The only property that two Payment Channel Networks and their underlying blockchains need to have in common in order to complete an atomic swap using Cross-Network Preimage Retrieval is a payment process based on irrevocable promises of payment upon receipt of a preimage, and support for the same hash function for those preimages (e.g. SHA256). There is active research into removing even the hash function commonality restriction through Scriptless Scripts, but even without such a development, keeping interoperability requirements to a single hash function opens up a huge number of potential currencies, including networks currently in development (e.g. Raiden and the Lightning Network).
In addition to the increased interoperability on paper, Cross-Network Preimage Retrieval increases practical interoperability by removing the requirement for a single client to support two blockchains. For different enough currencies (e.g. Bitcoin and Zcash), even a client that follows the same specification (e.g. BOLT) may be different enough to require (or at least make advisable) a separate client.
Simplified Implementation
Removing the need for two currencies on two blockchains to co-exist within the same client at the same time significantly decreases the complexity of a swap implementation (as is evidenced by concurrent multi-chain support being de-prioritized by the Lightning Labs team for LND).
In addition, Cross-Network Preimage Retrieval uses, by and large, primitives that should be common to every Payment Channel Network. Specifically it uses:
- Send payment
- Settle payment
- Invoice / preimage creation
In only one area does the Payment Channel Network node have to perform a non-standard action, which is to retrieve a preimage stored on an external service. Given the potential sensitivity of preimages and a desire to separate concerns, even that functionality may end up having utility outside of Cross-Network Swaps.
Trade-offs
There are of course trade-offs with this approach. The two that come to mind most readily are reduced privacy and limited cross-network messaging.
The swap demonstrated by Lightning Labs only required User A, the Initiating Party to know the identity of User B, the Translating Party. Cross-Network Preimage Retrieval requires that each party knows the other’s identity (on at least one of the Payment Channel Networks) since each party is responsible for constructing one leg of the route. This is, in my view, an acceptable tradeoff given that the identity of your counterparty may be a relevant detail when it comes to making a swap.
Additionally, because this is intended as a cross-network and cross-specification swap, the ability to pass network-specific messages back is limited. This is also likely an acceptable trade-off given that the need to pass such messages back across networks is also limited.
Fast, simple, & interoperable cross-chain swaps
Cross-Network Preimage Retrieval allows for swaps that take advantage of the speed that comes with Payment Channel Networks to allow for trading that is comparable with the speed allowed by custodial cryptocurrency exchanges today while preserving the atomicity, trustlessness, and finality of on-chain atomic swaps.
This new mechanism allows swaps between multiple different types of networks built on different underlying blockchains, implemented in different network clients. It is a simpler approach that takes better advantage of the built-in functionality of these networks making it a more robust swap mechanism.
Cross-Network Preimage Retrieval in Practice
We developed Cross-Network Preimage Retrieval while building sparkswap, a new system for trading cryptocurrencies without depositing assets onto a third party like an exchange. These swaps are powering the software that is live on testnet performing Bitcoin/Litecoin trades that settle in seconds.
Take look at the developer documentation, GitHub repository, or join us on Discord for more details of how we implemented these types of swaps, and to help us make them more reliable.
