CommerceBlock today released Mercury Layer, an improved version of their version of a statechain. You can read a longer explanation of how their Mercury state chains work here. The upgrade to Mercury Layer represents a huge improvement over the original statechain implementation, but unlike the original Mercury Wallet release, this is not packaged as a fully consumer-ready wallet. It is released as a library and CLI tool that other wallets can integrate. Here’s a quick summary of how they work:
State chains are essentially analogous to payment channels in many ways, i.e. they are a jointly shared UTXO with a pre-signed transaction as a last resort for people to enforce their ownership. The main difference between a Lightning channel and a state chain is the parties involved in jointly sharing the UTXO, and how ownership of an enforceable claim against it is transferred to other parties.
Unlike a Lightning Channel, which is created and shared between two static participants, a statechain opens with a facilitator/operator and can be freely transferred in its entirety between two participants who are willing to trust the operator to be honest , completely disabled. -chain. Someone who wants to load a statechain works with the operator to create a single public key for which the creator and the operator both own part of the corresponding private key, without having a complete copy of the key. From here, they pre-sign a transaction that allows the creator to unilaterally reclaim their coins after a time slot.
To transfer a state chain, the current owner works with the recipient and operator to sign a cryptographic proof with their key share that they are transferring the coin, and then the recipient and operator generate a new pair of key shares that together transfer the same private key forms and signs a time-bound transaction for the new owner with a shorter time slot than the original (to ensure they can use theirs sooner than previous owners). This process is repeated for each transfer until the time slot can no longer be shortened, at which point the state chain must be closed on-chain.
Owners transfer the entire historical chain of past states with each transfer, allowing users to verify that time slots have been downgraded appropriately and the operator timestamps them using Mainstay, a variant of Opentimestamps where each piece of data has its own unique “lock” in the merkle tree to ensure that only one version of the data is timestamped. This allows anyone to check the transfer history of a state chain.
In the land of the blind
The sea change that Mercury Layer brings to the original version of statechains is blinding. The operator of the statechain service will no longer be able to learn anything about what is being transferred: i.e. the TXIDs involved, the public keys involved, even the signatures it creates together with users for the pre-signed transactions needed to get back to claim your money unilaterally.
By introducing a blinded variant of Schnorr MuSig2, Mercury can simplify the process of signing transactions without learning the details of what they are signing. This will require some design changes to account for the fact that the operator can no longer see and publish the full transfer history of a state chain. They are not even able to validate the transaction they are signing.
In the previous iteration, the operator confirmed the uniqueness of a current state chain owner/transaction set by publishing the state chain’s full transfer history with Mainstay. That is not possible here, because in the blinded version the operator does not learn any details about these transactions at all. This requires a new way for the operator to attest to the current ownership of the state chain. All this data is fully pushed to a client-side validation model. The operator simply keeps track of how many times he has signed something for a single statechain, and tells a user that number when prompted. The user then receives the transactions of previous statechain states from the user who sends it to them, and fully verifies on the client side that the number of transactions matches what the operator claimed, and then fully verifies that the signatures are all valid and that the time slots will be reduced by the correct amount. every time. Instead of publishing the full statechain transactions and transfer order to Mainstay, because it is designed not to be aware of all that information, it publishes its part of the public key (not the full aggregated public key) for the current user for each statechain user. This allows any user who receives a statechain to verify the transfer history and the current status is legitimate based on the transaction data sent by the sender.
The operator server maintains unique statechains to count past signatures by assigning each statechain a random identifier upon creation, stored with its denomination and its private key and public key shares (not the entire aggregated public key). The new coordination scheme for key sharing and resharing is done in a way where the server passes its share of the key to the user, and the data required for key resharing is blinded so that the server does not enter is capable of ever learning the user’s entire key. public key share, allowing it to create the entire aggregated public key and identify the coin on the chain.
The design does not even allow the operator to know when it has signed a cooperative closing with the current owner instead of a pre-signed transaction for a new off-chain owner; it sees no details to distinguish the two cases. However, this is safe for users who could be attacked by someone trying to ‘double’ an off-chain state chain, creating a fake transaction that cannot be settled. First, that user in the chain would see that the UTXO supporting that state chain has been issued. Second, because the operator must sign all status updates, the transaction history would only have a clear cooperative closure in the chain of previous transactions. Both of these things would allow the user to decline the transaction, knowing it wasn’t legitimate.
Statechains also allow Lightning channels to be placed “on top” of the statechain by having the statechain pay out to a multisig address between two people, and the two on top of that negotiating a conventional series of Lightning commit transactions. It would have to close the statechain on-chain before closing the Lightning channel, so would have to use longer timelock lengths for Lightning payments, but would otherwise function completely normally.
Overall, with the massive privacy improvements of the new version of state chains, and the ability to compose with Lightning, this opens a lot of doors for the economic viability and flexibility of second-layer transaction mechanisms on Bitcoin. Especially in light of the recent radical changes in mempool dynamics and the resulting pressure on fees.
It offers the same kind of liquidity benefits as Ark, i.e. it can be freely transferable without the need for liquidity, but unlike Ark it is live and functional today. It’s undeniably a different trust model than something like Lightning alone, but the huge gains in flexibility and scalability make it certainly an option worth exploring.
