Lightning Latch Swap Protocol at Mercury Layer

Commerceblock has released a new atomic swap protocol for use with the state chains of the Mercury Layer protocol. The HSM server introduces the ability to atomically swap two state chains and enforce atomic swaps of state chains for Lightning payments. This is the first example of specifically defined and built interaction between Statechain and Lightning Network. Synergy between the two protocols has been assumed especially since the state chain concept first proposed by Ruben Somsen as a way to work around the limitation of having to transmit the entire state chain UTXO at once.

Basic Statechain Swap

To support the new swap protocol, the HSM server must add several new fields to the database entry that tracks each state chain it supports. To facilitate exchanges from statechain to statechain, the server must track:

• Batch_id: A value that links the chain of states exchanged in the group.
• Deployment Time: The time to start a counter that can “reclaim” the state chain if a swap fails.
• Locked: A value indicating whether the state chain is locked and regular transfers are restricted.

This allows the HSM server to track and apply all variables necessary to ensure secure atomic exchange. When initiating a swap, users must communicate directly with each other to establish a shared batch ID. From this point on, they transact all the necessary information needed to facilitate a normal state chain transfer and send that information, as well as the batch ID and batch time, to the server. They essentially initiate a regular transfer process, but they participate together in a swap, linking the individual state chains and also attaching a variable linking how long the timeout will be.

At this point, the server applies a lock to all state chains using the same batch ID in the transfer process. The server will not acknowledge the transfer until the timeout expires or all state chains in the database using the same batch ID are unlocked by the current owner. The nice thing about the way HSM applies swap logic is that it doesn’t matter who connects to the server first. When the server receives a message with a batch ID, it checks all state chains in the database and, if there is an existing batch time for that batch ID, sets it equal. This way, no matter who registers the swap first, everyone will use the same time value for the timeout function.

At this point, each client involved in the swap verifies and downloads the message that initiated the transfer protocol, and after verifying that it is correct, sends the message to the server to unlock the state chain and remove the transfer limit. Whenever anyone attempts to complete a transfer on the receiver side of the state chain associated with the swap, the server checks to see if all state chains with the same batch ID are unlocked. If even a single item with an associated batch_ID is still locked, the server will not complete the transfer for any item. If the swap does not succeed before the timeout, the server continues to restrict the swap transfer from completing, but allows the current owner to initiate a new transfer for itself, effectively canceling the swap.

lightning latch

The Lightning Latch function, which swaps a statechain for a Lightning payment, works very similarly to swapping from a statechain to a statechain. The new fields the server must track for Lightning swaps are:

• Batch_id: A value that links the chain of states exchanged in the group.
• Deployment Time: The time to start a counter that can “reclaim” the state chain if a swap fails.
• Pre-image: A pre-image of a Lightning payment generated by the HSM server.
• Locked_1 and Locked_2: There are two locked fields for Lightning swaps, one approved by each user involved.

Similar to exchanging from statechain to statechain, users set and share a random batch ID. The current state chain owner then sends a message to the server with the relevant batch_id and state chain and requests it to generate a hashlock pre-image for Lightning payments. This user then uses this pre-image to create a Lightning invoice, and a second user connects to the server to verify that the pre-image was created. The current Statechain owner then initiates the Statechain transfer process and uploads the transfer message to the server.

After confirming this, the second user who wants to exchange Statechain initiates a Lightning payment. As the current server is the only one with pre-images, Statechain owners cannot complete payments yet. After confirming the pending lighting payment, the current owner sends a unlock message to the server to remove the first lock in the state chain. The receiver finally checks the sent message, and if it is a valid message, the server also removes the lock.

Now, once both locks are removed, the HSM server releases the pre-image to the current state chain owner to complete the lightning payment and finalizes the state chain transfer to the recipient.

The plan requires trusting the Statechain operator to operate honestly, but this is not fundamentally a change to the existing trust model that normally uses Statechain. The operator has no control over user funds in any way and cannot know anything about Lightning payment details.

What is this good for?

This scheme is a far cry from the originally established interaction between state chains and Lightning channels, but even as a simple starting point, it provides functional utility to existing Lightning users. Channel rebalancing is a necessary operation for many nodes. If capacity is completely pushed to one side or the other, the utility of that channel is limited to payment routing. Many businesses and users have begun experimenting with using Liquid as a mechanism to do this, as on-chain fees rise and swaps into and out of the Lightning Network become more expensive.

Statechain provides an alternative mechanism to federated sidechains to alleviate some of the fee costs associated with channel balance management. Instead of swapping directly to the mainchain or using a sidechain, you can swap funds to the state chain and store them until needed to swap funds back to the channel. Similar fee savings can be achieved while retaining the ability to unilaterally claim funds from the mainchain.

Another potential use case (TRIGGER WARNING) is the possibility of a more efficient market for ordinal trading. Ordinal numbers can be easily lifted into an off-chain state chain because they are simply an indexing system that traces the path from transaction history to a specific satoshi. This dynamic, combined with Lightning Latch, makes ordinal off-chain purchases cheaper and faster. The Lightning Network allows someone to build a marketplace where they can instantly sell off-chain.

One day, once Lightning clients know which StateChain operators trust specific Lightning nodes, they may find that they can use Latch to route payments by passing StateChains between different nodes instead of using existing Lightning channels.

On the pure state chain to state chain transfer front, this provides the possibility for the message passing layer to recreate coin joins, such as a system for mixing coins off-chain, similar to the original mixing function of Commerceblock’s first state chain implementation. do.

Although it’s a very simple starting point, Lightning Latch and state chain swap functionality opens the first door for state chains to be integrated into existing Lightning networks and other similar layers coming in the future, allowing them to all integrate seamlessly. It functions as a single network in terms of payment routing and liquidity management. Even as we debate the need and usefulness of covenants, there is quite a bit of room to continue building on what we already have.

Here you can hear the Commerceblock team explain the logic behind the protocol.

Conversation with Dr. @TTrevethan About Why Lightning Clasps Are Made @mercurylayer #Bitcoin #Layer 2 pic.twitter.com/CKVG9aHTQ6

— Nicholas Gregory (@gregory_nico) March 15, 2024

For a more technical explanation, see here.

Let’s take a look at the technology behind how Lightning Latch works. @TTrevethan In ~ @mercurylayer #Bitcoin #Layer 2 pic.twitter.com/aQIcjh2ukq

— Nicholas Gregory (@gregory_nico) March 16, 2024