CommerceBlock today releases Mercury Layer, an enhanced version of its state chain variant. A detailed explanation of how the Mercury state chain works can be read here. The upgrade to Mercury Layer represents a huge improvement over the initial state chain implementation, but unlike the initial Mercury Wallet release, it is not packaged into a fully consumer-ready wallet. It is being released as a library and CLI tool for integration with other wallets. Here’s a brief summary of how it works:
Statechains are inherently similar to payment channels in many ways. That is, UTXOs that are shared collectively through pre-signed transactions as a last resort mechanism for people to exercise their ownership rights. The key difference between Lightning Channel and Statechain is which parties jointly share UTXOs and how ownership of enforceable claims on UTXOs is transferred to other parties.
Unlike Lightning channels, which are created and shared between two static participants, statechains are opened through a moderator/operator and can be transferred entirely freely between any two participants willing to trust the operator. -chain. Someone who wants to load a state chain works with an operator to generate a single public key where both the creator and operator hold a share of that private key and do not hold a complete copy of the key. Here they pre-sign the transaction so that the creator can unilaterally get the coins back after a time lock.
To transfer the state chain, the current owner works with the recipient and operator to sign a cryptographic proof with a key share that they are transferring coins, and then the recipient and operator generate a new key share pair that sums the same private key and signature. A time lock transaction for the new owner with a shorter time lock than the original owner (to ensure it is available sooner than the past owner). This process is repeated for every transfer until the time lock cannot be shortened any further, at which point the state chain must be terminated on-chain.
The owner sends the entire historical chain of past states with each transfer, so the user can verify that the timelock has been appropriately decremented, and the operator uses Mainstay, a variant of Opentimestamp where each piece of data has a unique “slot” in the Merkle tree. Timestamp it. Ensures that only a single version of data is timestamped. This allows everyone to audit the transmission history of the state chain.
in the land of the blind
The big changes that Mercury Layer brings to the original version of the state chain are remarkable. The operator of the Statechain service no longer knows anything about what is being transmitted. This means that we don’t know the TXID involved, the public key involved, or even the signature that the user collaborates with to create for the pre-signed transaction needed to claim the return. Your funds unilaterally.
Introducing a blind variant of Schnorr MuSig2, Mercury can facilitate the backout transaction signing process without learning details about the content of the signature. This requires some design changes to account for the fact that operators can no longer view and publish the entire transmission history of the state chain. They don’t even have the ability to verify any transactions they sign.
In previous iterations, the uniqueness of the current Statechain owner/transaction set was proven by the operator through publishing the entire transfer history of the Statechain via Mainstay. This is not possible here because in the blind version the operator does not know any details about these transactions. This requires a new way for operators to prove current ownership of Statechain. All of this data is pushed entirely to the client-side validation model. The operator simply keeps track of the number of signatures for a single state chain and reports that number to the user when requested. It then receives the transactions in the past state chain state from the user 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 lock is reduced by the appropriate amount. every time. Instead of publishing the entire Statechain transaction and transfer orders to the mainstay, we publish a shared public key (not the full aggregate public key) for each Statechain’s current user, as it is designed to be blind to all information. user. This allows anyone receiving the state chain to verify that the transmission history and current state are legitimate for the transaction data sent by the sender.
The operator server tracks unique statechains, assigning a random identifier to each statechain upon creation and storing it along with its denomination and private and public key shares (not the full aggregate public key) to calculate past signatures. The new coordination scheme for key sharding and resharding is done in such a way that the server passes key sharing to the user, and the data required for resharding is blocked so that the server cannot learn the user’s complete information. Public key sharing allows you to generate full public keys and identify coins on-chain.
By design, the operator cannot know when a cooperative closure has been signed with the current owner rather than a pre-signed transaction for the new off-chain owner. No details are shown to distinguish the two cases from each other. However, this is safe for users who could be attacked by someone trying to “double spend” the off-chain state chain providing fake transactions that cannot be settled. First, the user can confirm on-chain that the UTXOs backing that state chain have been spent. Second, the transaction history has a clear cooperative end only in the past transaction chain because the operator must sign all state updates. Both of these allow users to refuse transactions knowing they are not legitimate.
Statechain also allows you to “put Lightning channels on top” of Statechain by having Statechain pay to a multi-signature address between two people, and have those two negotiate a set of traditional Lightning promise transactions on top of it. Since we need to close the on-chain state chain before closing the Lightning channel, we need to use a longer lock length for Lightning payments, but otherwise it works perfectly fine.
Overall, the potential combination of Lightning with large-scale privacy improvements in new state chain iterations opens many doors for the economic viability and flexibility of Bitcoin’s second-layer transaction mechanisms. This is especially true considering the recent rapid changes in mempool dynamics and the resulting fee pressures.
This provides the same type of liquidity advantage as Ark. This means that it is freely transferable without the need to receive liquidity, but unlike Ark, it is alive and functional today. It’s definitely a different trust model than something like Lightning, but it certainly has potential to explore for massive improvements in flexibility and scalability.