Mercury Layer’s Lightning Latch Swap Protocol

Commerceblock has launched a brand new atomic swap protocol to be used with statechains on their Mercury Layer protocol. The HSM server has launched performance to assist atomically swapping two statechains, in addition to implementing an atomic trade of a statechain for a Lightning cost. That is the primary instance of concretely outlined and constructed interactions between statechains and the Lightning Community. Synergy between each protocols has been postulated because the idea of a statechain was initially proposed by Ruben Somsen, particularly as a method to clear up the limitation of getting to switch a complete statechain UTXO without delay.

Fundamental Statechain Swaps

As a way to assist the brand new swap protocols, the HSM server wants so as to add some new fields to its database entries monitoring every statechain it’s facilitating. To facilitate the statechain to statechain swap, the server wants to trace:

• Batch_id: a worth to affiliate statechains being swapped in a bunch.
• Batch-time: a time that begins a counter after which the statechains will be “reclaimed” if the swap fails.
• Locked: a worth indicating whether or not or not the statechain is locked and restricted from common transfers.

This enables the HSM server to trace and implement all of the variables essential to make sure a protected atomic swap. When initiating a swap, customers have to speak with one another instantly in an effort to set up a shared batch_id between them. From this level they commerce all the mandatory info required to facilitate a standard statechain switch, and ship that info plus the batch_id and batch-time to the server. They basically begin the common switch course of, but in addition connect the variables to attach the person statechains as collaborating in a swap collectively and the way lengthy the timeout interval is for that.

The server at this level will apply a lock to each statechain utilizing the identical batch_id within the switch course of. Till the timeout expires, or the entire statechains in its database utilizing the identical batch_id have been unlocked by the present homeowners, the server is not going to approve any transfers. A neat factor about the way in which the HSM enforces the swap logic is that it doesn’t matter who contacts the server first. When the server will get a message utilizing a batch_id, it checks each statechain in its database and if there’s a pre-existing batch-time for that batch_id it units it as the identical. This ensures that irrespective of who registers the swap first all of them use the identical time worth for the timeout perform.

Every consumer concerned within the swap at this level checks for and downloads the messages that initiated the switch protocol, and upon verifying they’re appropriate sends a message to the server to unlock their statechain, eradicating the switch restrictions. Every time anybody makes an attempt to finalize a switch on the receiver aspect of any of the statechains concerned within the swap, the server checks to ensure the entire statechains with the identical batch_id are unlocked. If even a single one with the associated batch_id remains to be locked the server will finalize a switch for none of them. If a swap doesn’t succeed earlier than the timeout, the server will proceed limiting the finalization of the swap switch, however will let the present homeowners initialize a brand new switch to themselves to successfully cancel the swap.

Lightning Latch

The Lightning Latch performance, swapping a statechain for a Lightning cost, works very equally to the statechain to statechain swap. Listed below are the brand new fields the server should monitor for the Lightning swap:

• Batch_id: a worth to affiliate statechains being swapped in a bunch.
• Batch-time: a time that begins a counter after which the statechains will be “reclaimed” if the swap fails.
• Pre-image: the preimage of the Lightning cost, which is generated by the HSM server.
• Locked_1 and locked_2: there are two lock fields for the Lightning swap, one licensed by every consumer concerned.

Similar to with the statechain to statechain swap, the customers set up and share a random batch_id. The present statechain proprietor then messages the server with the batch_id and statechain concerned and requests it generates a hashlock preimage for a Lightning cost. This consumer then generates a Lightning bill utilizing this preimage, and the second consumer contacts the server to substantiate it generated the preimage. The present statechain proprietor then begins the statechain switch course of and uploads the switch message to the server.

After affirmation of that, the second consumer attempting to swap for the statechain initiates the Lightning cost. At the moment the server is the one one with the preimage, so the statechain proprietor can’t finalize the cost but. The present proprietor after verifying the pending Lighting cost sends the server an unlock message to take away the primary lock on the statechain. The receiver lastly verifies the switch message, and if legitimate messages the server to take away their lock as effectively.

Now with each locks eliminated, the HSM server will launch the preimage to the present statechain proprietor to finalize the Lightning cost, and can finalize the statechain switch to the receiver.

This scheme does require trusting the statechain operator to perform actually, however that’s basically not a change to the pre-existing belief mannequin of utilizing a statechain typically. At no time does the operator have management over customers’ funds, nor do they study something concerning the Lightning cost particulars.

What Is This Good For?

This scheme is a far cry from the initially posited interplay between statechains and Lightning channels, stacking one on high of the opposite, however whilst a easy place to begin this presents purposeful utility for present Lightning customers. Rebalancing channels is a essential factor for a lot of nodes, if the capability is solely pushed to at least one aspect or the opposite the utility of that channel is restricted for routing funds. Many companies and customers have began experimenting with utilizing Liquid as a mechanism for this as a consequence of on-chain charges rising and making swaps into and out of the Lightning Community dearer.

Statechains supply an alternate mechanism to a federated sidechain to alleviate a number of the payment bills related to channel steadiness administration. As a substitute of getting to swap out to the mainchain instantly, or use a sidechain, funds will be swapped to a statechain and held there till they’re wanted for swapping funds again right into a channel. Comparable financial savings in charges will be had whereas nonetheless sustaining the flexibility to unilaterally declare your funds on the mainchain.

One other potential use case (TRIGGER WARNING) could be the potential for extra environment friendly marketplaces for buying and selling ordinals. Since ordinals are merely an index scheme monitoring paths backwards within the transaction historical past to particular satoshis, they’ll simply be lifted off-chain onto a statechain. That dynamic together with Lightning Latch may enable cheaper and quicker off-chain purchases of ordinals. Somebody may construct a market the place they are often offered immediately off-chain over the Lightning Community.

It’s even doable at some point if Lightning shoppers may grow to be conscious in some way of which statechain operators particular Lightning nodes belief that Latch may very well be used to assist route funds by passing statechains round between completely different nodes as a substitute of utilizing standard Lightning channels.

On the entrance of pure statechain to statechain transfers, this presents the potential for a message passing layer to recreate coinjoin like system mixing cash off-chain, much like the unique mixing performance in Commerceblock’s first statechain implementation.

Whereas it’s a quite simple place to begin, Lightning Latch and the statechain swap performance crack open the primary door of statechains integrating into the present Lightning Community – and different related layers to come back sooner or later – in a manner that lets all of them combine seamlessly and performance as a singular community when it comes to cost routing and liquidity administration. Even whereas we debate the necessity for and usefulness of covenants, there may be nonetheless various room to proceed constructing with what we have already got.

You possibly can hearken to the Commerceblock crew clarify the logic past the protocol right here:

Chatting with the Dr @TTrevethan about why to construct lightning latch on @mercurylayer #bitcoin #layer2 pic.twitter.com/CKVG9aHTQ6

— Nicholas Gregory (@gregory_nico) March 15, 2024

And for a extra technical clarification, right here:

Going by way of the technicals of how lightning latch will work with @TTrevethan on @mercurylayer #bitcoin #layer2 pic.twitter.com/aQIcjh2ukq

— Nicholas Gregory (@gregory_nico) March 16, 2024