Commerceblock has released a new atomic swap protocol for use with statechains on their Mercury Layer protocol. The HSM server has introduced functionality to support atomic swapping of two statechains, as well as forcing an atomic swap of a statechain for a Lightning payment. This is the first example of concretely defined and built interactions between statechains and the Lightning Network. Synergy between both protocols has been postulated since the concept of a state chain was originally proposed by Ruben Somsen, specifically as a way to overcome the limitation of transferring an entire state chain of UTXO at once.
Basic state chain swaps
To support the new swap protocols, the HSM server must add some new fields to the database entries that track each statechain it facilitates. To facilitate statechain-to-statechain exchanges, the server must maintain:
- Batch_id: A value to associate statechains that are swapped in a group.
- Batch time: A time that starts a counter after which the statechains can be “reclaimed” if the swap fails.
- Locked: A value indicating whether or not the state chain is locked and limited to regular transfers.
This allows the HSM server to track and enforce all the variables necessary to ensure a secure atomic swap. When initiating a swap, users must communicate directly with each other to establish a shared batch_id between them. From this point on, they trade all the necessary information needed to enable a normal statechain transfer, and send that information plus the batch_id and batch-time to the server. They essentially start the regular transfer process, but also link the variables to connect the individual state chains as participants in an exchange and how long the timeout period is for that.
The server will apply a lock to each statechain with the same batch_id in the transfer process at this point. Until the timeout expires, or until all statechains in the database using the same batch_id are unlocked by their current owners, the server will not approve any transfers. The nice thing about the way the HSM enforces the swap logic is that it doesn’t matter who contacts the server first. When the server receives a message using a batch_id, it checks each statechain in its database and if there is a pre-existing batch time for that batch_id, it sets it as the same. This ensures that no matter who registers the swap first, they all use the same time value for the timeout function.
Each client involved in the swap at this point checks and downloads the messages that initiated the transfer protocol, and after verifying that they are correct, sends a message to the server to unlock their statechain, thus removing the transfer restrictions cancelled. Whenever someone tries to complete a transfer on the receiver side of one of the statechains involved in the swap, the server checks to see if all statechains with the same batch_id have been unlocked. If even one with the associated batch_id is still locked, the server will not complete a transfer for any of them. If a swap fails before the timeout, the server continues to limit the completion of the swap transfer, but allows the current owners to initialize a new transfer to itself to effectively cancel the swap.
Lightning bolt
The Lightning Latch functionality, which involves swapping a statechain for a Lightning payment, works much the same as the statechain-to-statechain swap. Here are the new fields the server must maintain for the Lightning swap:
- Batch_id: A value to associate statechains that are swapped in a group.
- Batch time: A time that starts a counter after which the statechains can be “reclaimed” if the swap fails.
- Pre-image: The pre-image of the Lightning payment, which is generated by the HSM server.
- Locked_1 and lock_2: There are two lock fields for the Lightning swap, one authorized by each involved user.
Similar to statechain-to-statechain exchanges, users set and share a random batch_id. The current statechain owner then sends a message to the server with the affected batch_id and statechain and asks it to generate a hashlock preimage for a Lightning payment. This user then generates a Lightning invoice using this preimage, and the second user contacts the server to confirm that it generated the preimage. The current statechain owner then begins the statechain transfer process and uploads the transfer message to the server.
After confirming this, the second user who attempts to trade for the statechain will initiate the Lightning payment. At this point, the server is the only one with the preimage, so the statechain owner cannot complete the payment yet. The current owner, after verifying the pending Lighting payment, sends an unlock message to the server to remove the first lock from the statechain. The receiver finally verifies the transfer message and if it is valid, it also sends a message to the server to remove the lock.
Now that both locks have been removed, the HSM server will release the preimage to the current statechain owner to complete the Lightning payment, and the statechain transfer to the recipient will be completed.
This plan does require that you can trust the statechain operator to function honestly, but that is not fundamentally a change to the pre-existing trust model of statechain use in general. The operator has no control over users’ funds at any point, nor does it learn anything about the Lightning payment details.
What is this good for?
This scheme is a far cry from the originally posited interaction between statechains and Lightning channels, where one is stacked on top of the other, but even as a simple starting point it offers functional usability for existing Lightning users. Channel rebalancing is a necessity for many nodes; if capacity is pushed completely to one side or the other, the usefulness of that channel for routing payments is limited. Many companies and users have begun to experiment with using Liquid as a mechanism for this, as on-chain costs increase and swaps into and out of the Lightning Network become more expensive.
Statechains provide an alternative mechanism to a federated sidechain to alleviate some of the fees associated with managing channel balances. Instead of having to swap directly to the main chain or use a side chain, funds can be swapped to a state chain and held there until they are needed to swap funds back to a channel. Similar cost savings can be achieved while still retaining the ability to unilaterally claim your funds on the main chain.
Another potential use case (TRIGGER WARNING) would be the possibility of more efficient ordinal trading marketplaces. Because ordinal numbers are simply an index scheme that follows paths back in the transaction history to specific satoshis, they can easily be taken off-chain into a state chain. That dynamic combined with Lightning Latch could enable cheaper and faster off-chain purchases of ordinal numbers. Someone could build a marketplace where they could be sold directly off-chain via the Lightning Network.
It’s even possible one day that Lightning customers could somehow become aware of which statechain operators trust specific Lightning nodes that Latch can be used to route payments by passing statechains between different nodes instead of conventional Lightning channels.
On the front of pure statechain-to-statechain transfers, this offers the potential for a message passing layer to create a Coinjoin-like system that mixes coins off-chain, similar to the original mixing functionality in Commerceblock’s first statechain implementation.
While it’s a very simple premise, Lightning Latch and its statechain swap functionality opens the first door of statechains that integrate into the existing Lightning Network – and other similar layers to come in the future – in a way that lets them all integrate seamlessly. function as a single network in terms of payment routing and liquidity management. Even as we debate the need and usefulness of covenants, there is still a lot of room to build on what we already have.
You can listen to the Commerceblock team explain the logic beyond the protocol here:
Chat with Dr. @TTrevethan on why you should build a lightning bolt on @mercurylayer #bitcoin #layer2 pic.twitter.com/CKVG9aHTQ6
— Nicholas Gregory (@gregory_nico) March 15, 2024
And for a more technical explanation, here:
Going over the technical details of how lightning bolt will work with @TTrevethan on @mercurylayer #bitcoin #layer2 pic.twitter.com/aQIcjh2ukq
— Nicholas Gregory (@gregory_nico) March 16, 2024
