Partnered With:

Mercury Layer: brings significant improvements to Statechain.

Read this article in 11 Minutes

This article provides a detailed explanation of how Mercury Statechain works.

Original Title: "MERCURY LAYER: A MASSIVE IMPROVEMENT ON STATECHAINS"

Original Source: SHINOBI, Bitcoin Magazine

Translated by: BTCStudy

CommerceBlock has launched "Mercury Layer" today, an upgraded version of their statechain variant. You can learn how Mercury Statechain works through this long article. However, unlike the original Mercury Wallet, this Mercury Layer upgrade represents a huge improvement on the initial statechain implementation, but it has not yet been packaged as a wallet that is fully consumer-facing. It was released as a library and command-line tool that can be integrated into other wallets. This article briefly summarizes how it works:

Statechain is similar to payment channels in many ways, that is, it is a collectively shared UTXO that uses pre-signed transactions as a means of enforcing ownership. The main difference between Statechain and Lightning Network is the number of participants who can share a UTXO and the way in which a enforceable claim can be transferred to another participant.

In the Lightning Network, a UTXO is created and shared by two static parties, while a Statechain is opened by an operator and can be freely transferred between any two individuals who are willing to trust the operator's honesty, completely off-chain. The person who wants to create a Statechain creates a public key with the operator, and both the creator and the operator only have a fragment of the private key behind that public key, with neither party having the complete private key. Then, they pre-sign a transaction that allows the creator to unilaterally retrieve their funds after a time lock expires.

When transferring a Statechain, the current owner collaborates with the recipient and operator to sign a cryptographic proof using their fragment private key to prove that they want to transfer the money. Then, the recipient and operator generate a new pair of fragment private keys, which, when combined, are still the original private key. Then, a transaction with a time lock can be signed, and the new owner's time lock is shorter than the original owner's (to ensure that the new owner can always withdraw funds faster than the old owner). This process can be repeated until the time lock can no longer be shortened, at which point the Statechain will be closed on the chain.

The owner of the asset also needs to transfer the entire historical chain of transfers, so that users can verify that the time lock has been properly shortened and that the operator has used the Mainstay protocol (a variant of the Opentimestamp protocol) to add timestamps to these records. Each piece of data has its own unique "space" on a Merkle tree, ensuring that only one version of the data has a timestamp. This allows everyone to audit the entire transfer history of a Statechain.

On the Dark Earth

The biggest change that Mercury Layer brings to the original statechain is blinding. The operator of the Statechain service will no longer be able to know anything that is transferred: that is, the relevant TXID, the relevant public key, and even the signature generated in cooperation with the user for the pre-signed transaction.

Introduced a blinded variant of Schnorr MuSig2, Mercury can assist in the signature process of backup transactions without knowing any details of what is being signed. This necessitates some design changes to accommodate the fact that the operator can no longer see and publish the integrity of a Statechain transfer history. They can't even verify the transactions they have signed themselves.

In the previous version, the uniqueness of the current owner/transaction set of a Statechain was witnessed by the operator through the complete transfer history of the Statechain published via mainstay. Now, this is no longer possible because in this blinded version, the operator has no knowledge of these transactions. This makes it necessary for us to find a new way to allow the operator to witness the latest ownership of a Statechain. All of this data will be passed entirely through a "client verification mode". The operator only needs to track the number of times they sign something for a Statechain and then tell a user who needs this number.

The user receives the transaction history of this Statechain from the payment provider, and then verifies on their own that the number of transactions matches the operator's statement, and that all signatures are valid and the time lock decreases by an appropriate amount each time. The complete Statechain transactions and transfer order are no longer published to Mainstay, because the operator is designed to not know all of this information. Instead, they only publish their own public key fragments from working with each previous user (rather than the complete aggregated public key) to the newest user. This allows any user who receives a Statechain to verify the transaction history and current state is valid (through the transaction data provided by the sender).

The operator's server needs to track the number of past signature times for each Statechain. The method is to assign a random identifier to each Statechain when it is created, and store the relevant denomination, fragment private key, and fragment public key (instead of the complete aggregated public key). In the new private key splitting and re-splitting scheme, the server passes its fragment public key to the user, and the data required for re-splitting is blinded, so the server cannot know the user's complete fragment public key, and therefore cannot generate the complete aggregated public key and identify the location of the funds on the chain.

This design even prevents the operator from knowing whether they have signed a cooperation closure with the latest owner or a new pre-signed transaction with a new owner; they cannot distinguish between the two based on any details. However, if someone tries to "double-spend" a Statechain by providing a false and un-settled transaction, the recipient can detect it. First, the recipient will see the UTXO that provides value for this Statechain being spent on the chain. Secondly, because the operator must sign all state changes, there will only be a clear cooperative closure solution in the history of past transactions. Both can alert the recipient that this is invalid and should be rejected.

Statechain construction also allows for lightning channels to be "deployed on" a Statechain by transferring the Statechain to a multi-signature address owned by two parties, who can then negotiate a set of traditional lightning channel commitment transactions on top of it. If these two parties need to close the lightning channel, they must first close the Statechain on-chain, and as a result, they cannot use time locks longer than the Statechain's lifespan in lightning transactions. However, in all other respects, it is identical to a conventional lightning network.

Overall, with the significant privacy improvements of the new version of Statechain and its composability with the Lightning Network, many prospects for the economic feasibility and flexibility of layer-two transaction mechanisms on Bitcoin have been unlocked. This is especially true considering the recent significant changes in transaction pool dynamics and the resulting pressure on transaction fees.

This mechanism provides the same liquidity advantages as Ark, that is, the ability to transfer freely without considering the receiving limit. However, unlike Ark, it has already been launched and can be used now. It is undeniable that it has a different trust model from things like the Lightning Network, but considering its huge gains in flexibility and scalability, it is undoubtedly an area that should be explored.