Commerceblock has released a new atomic swap protocol for use with state chains on its Mercury Layer protocol. The HSM server provided functionality to support atomic swapping of two statechains, as well as enforcing atomic swapping of a statechain for a Lightning payment. This is the first example of concretely defined and structured interactions between state chains and the accelerator network. The synergy between both protocols has been assumed since the statechain concept was originally proposed by Robin Sumsen, specifically as a way to solve the problem of having to move the entire UTXO statechain simultaneously.
Basic state chain swaps
In order to support the new swap protocols, the HSM server needs to add some new fields to its database entries to track each state chain it facilitates. To facilitate swapping the state string with the state string, the server needs to keep track of:
- Batch_id: A value to bind to the status strings being swapped in a batch.
- Batch Time: The time at which the timer starts and after which the state strings can be “recovered” in the event of a swap failure.
- Locked: A value indicating whether the state chain is locked and restricted from regular transfers or not.
This allows the HSM server to track and implement all variables necessary to ensure a secure atomic swap. When a swap is initiated, users must communicate with each other directly in order to create a shared Batch_ID between them. From there, they process all the necessary information required to facilitate the normal transfer of the status chain, and send that information along with the batch ID and batch time to the server. They basically initiate the regular transfer process, but they also attach variables to link individual state threads as swap shares together and a timeout period for that.
At this point the server will apply a lock on each state chain using the same batch ID in the transfer process. Until the timeout expires, or all state threads in its database using the same batch ID are unlocked by the current owners, the server will not approve any transfers. The great thing about the way HSM enforces 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 every status chain in its database and if there is a pre-existing batch time for that batch ID, it sets it accordingly. This ensures that no matter who registers the swap first, they all use the same time value for the timeout function.
Each client participating in the swap at this point checks and downloads the messages that initiated the transfer protocol, and when verified, sends a message to the server to open its state chain, removing the transfer restrictions. When anyone tries to finish a transfer on the recipient side for any of the state threads participating in the swap, the server checks to make sure that all state chains with the same batch ID are unlocked. If even one with the relevant batch ID is still locked, the server will complete the transfer for any of them. If the swap is not successful before the timeout expires, the server will still restrict the completion of the swap transfer, but will allow the current owners to configure a new transfer for themselves to effectively cancel the swap.
Lightning latch
The Lightning Latch function, which swaps the state chain with a Lightning batch, works very similarly to swapping the state chain for the state chain. Here are the new fields that the server must track for a Lightning swap:
- Batch_id: A value to bind to the status strings being swapped in a batch.
- Batch Time: The time at which the timer starts and after which the state strings can be “recovered” in the event of a swap failure.
- Preimage: The preimage of a Lightning batch, which is generated by the HSM server.
- Locked_1 and locked_2: There are two lock fields for Lightning swap, one of which is authorized by each user involved.
Just as with swapping the country string for the country string, users generate and share a random Batch_id. The current state chain owner then sends a message to the server with the batch ID and state chain in question and asks it to create a pre-hash image of the Lightning batch. This user then creates a Lightning invoice using this initial image, and the second user contacts the server to confirm that they created the initial image. The current state chain owner then initiates the state chain transfer process and uploads the transfer message to the server.
After this is confirmed, the second user who tries to switch to the state chain initiates a Lightning payment. At this time, only the server has the advance image, so the owner of the state chain cannot finish the payment yet. The current owner, after verifying the pending lighting batch, sends an unlock message to the server to remove the first lock on the state chain. The receiver finally verifies the transfer message, and if the messages are valid, the server also removes the lock.
Now that both locks are removed, the HSM server will issue the pre-image to the current statechain owner to finalize the Lightning push, and will finalize the transfer of the statechain to the recipient.
This scheme requires trust in the statechain operator to operate honestly, but this is not a fundamental change to the pre-existing trust model of statechain use in general. At no time does the operator control users' funds, nor does he know anything about Lightning's payment details.
What is this good for?
This scheme is a far cry from the originally assumed interplay between state chains and Lightning channels, where one is stacked on top of the other, but even as a simple starting point, this offers a functional benefit to existing Lightning users. Channel rebalancing is necessary for many nodes, if capacity is pushed entirely to one side or the other, that channel will have limited utility for routing payments. Many companies and users are starting to experiment with using Liquid as a mechanism for this due to rising on-chain fees and making swaps on and off the Lightning Network more expensive.
Statechains offer an alternative mechanism to the federated sidechain to mitigate some of the fee expenses associated with channel balance management. Instead of having to switch to the main chain directly, or use a sidechain, funds can be swapped to the state chain and kept there until they are needed to exchange funds back in the channel. Similar savings on fees can be achieved while maintaining the ability to claim your funds unilaterally on the mainnet.
Another potential use case (trigger warning) is the potential for more efficient markets for ordinal trading. Since ordinals are just an index scheme that traces paths backwards in the transaction history to a particular satoshi, they can easily be lifted off-chain to the state chain. This dynamic with Lightning Latch could allow for cheaper and faster off-chain purchases of arrangements. Anyone can create a marketplace where they can be instantly sold off-chain via the Lightning Network.
It is even possible that one day Lightning customers will somehow become aware of the Lightning nodes of state chain operators who trust that Latch can be used to help route payments by passing state chains between different nodes instead of using traditional Lightning channels.
On top of statechain-to-statechain transfers, this provides the potential for the message passing layer to recreate the coin peg system as an off-chain coin mixing system, similar to the original mixing functionality in Commerceblock's first statechain implementation.
Although it's a very simple starting point, the Lightning Latch and its statechain swap functionality opens the first door to integrating the statechain with the existing Lightning Network — and other similar layers to come in the future — in a way that allows them all to integrate seamlessly and operate as a unique network. Payment routing and liquidity management. Even while debating the need and usefulness of covenants, there is still plenty of room to continue building on what we already have.
You can listen to the Commerceblock team explain the logic behind the protocol here:
Chat with Dr @TTrevethan About why lightning bolts are built @mercurylayer #Bitcoin #layer2 pic.twitter.com/CKVG9aHTQ6
– Nicholas Gregory (@Gregory_nico) March 15, 2024
For more technical explanation here:
See the technical aspects of how a lightning latch works @TTrevethan on @mercurylayer #Bitcoin #layer2 pic.twitter.com/aQIcjh2ukq
– Nicholas Gregory (@Gregory_nico) March 16, 2024
