Mercury Layer: A Massive Improvement On Statechains

CommerceBlock is releasing Mercury Layer today, an improved version of their variation of a statechain. You can read a longer form explanation of how their Mercury statechains work here. The upgrade to Mercury Layer represents a massive improvement against the initial statechain implementation, however unlike the initial Mercury Wallet release, this is not packaged as a fully consumer ready wallet. It is being released as a library and CLI tool other wallets can integrate. Here’s a quick summary of how they work:

Statechains are essentially analogous to payment channels in many ways, i.e. they are a collaboratively shared UTXO with a pre-signed transaction as a mechanism of last resort for people to enforce their ownership. The major difference between a Lightning channel and a statechain is the parties involved in collaboratively 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 is opened with a facilitator/operator, and can be freely transferred in its entirety between any two participants who are willing to trust the operator to be honest, completely off-chain. Someone wishing to load a statechain collaborates with the operator to create a single public key that the creator and operator both hold a share of the corresponding private key, with neither having a complete copy of the key. From here they pre-sign a transaction allowing the creator to claim their coins back after a timelock unilaterally.

To transfer a statechain the current owner collaborates with the receiver and operator to sign a cryptographic proof with their keyshare that they are transferring the coin, and then the receiver and operator generate a new pair of keyshares that add up to the same private key and sign a timelocked transaction for the new owner with a shorter timelock than the original (to ensure they can use theirs sooner than past owners). This process is repeated for every transfer until the timelock cannot be shortened anymore, at which point the statechain must be closed out on-chain.

Owners transfer the entire historical chain of past states with each transfer so that users can verify timelocks have been properly decremented and the operator timestamps them using Mainstay, a variant of Opentimestamps where each piece of data has its own unique “slot” in the merkle tree to guarantee that only a single version of the data is timestamped. This let’s everyone audit the transfer history of a statechain.

In The Land Of The Blind

The big change Mercury Layer is bringing 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 that it collaborates with users to create for the pre-signed transactions necessary to claim back your funds unilaterally.

Introducing a blinded variant of Schnorr MuSig2, Mercury can facilitate the process of backout transaction signing without learning any of the details of what they are signing. This necessitates some design changes in order to account for the fact the operator can no longer see and publish the entirety of a statechain’s transfer history. They are not even capable of validating the transaction they are signing at all.

In the prior iteration, uniqueness of a current statechain owner/transaction set was attested to by the operator through the publishing of the entire transfer history of the statechain with Mainstay. That is not possible here, as in the blinded version the operator learns no details at all about these transactions. This necessitates a new way of the operator attesting to current ownership of the statechain. All of this data is pushed entirely to a client side validation model. The operator simply keeps track of the number of times it has signed something for a single statechain, and tells a user that number when it is requested. The user then receives the transactions of past statechain state’s from the user sending to them, and verifies entirely client side that the number of transactions match what the operator claimed, and then fully verifies the signatures are all valid and the timelocks decremented by the appropriate amount each time. In lieu of publishing the full statechain transactions and transfer order to Mainstay, because it is designed to be unaware of all of that information, it publishes its share of the public key (not the full aggregate public key) for the current user for each statechain user. This allows any user receiving a statechain to verify the transfer history and current state is legitimate against the transaction data sent by the sender.

The operator server keeps track of unique statechains to count past signatures by assigning each statechain a random identifier at creation, stored with its denomination and its private key and public key shares (not the entire aggregate public key). The new coordination scheme for sharding and re-sharding the key is done in a way where the server passes its share of the key to the user, and the data necessary for a resharding is blinded so the server is incapable of ever learning the user’s full public key share, allowing it to create the full aggregate public key and identify the coin on-chain.

The design doesn’t even allow for the operator to know when it has signed a cooperative closure with the current owner rather than a pre-signed transaction for a new off-chain owner; it doesn’t see any details to distinguish the two cases from each other. This is safe however for users who could be attacked by someone trying to “double spend” a statechain off-chain providing a fake transaction that couldn’t be settled. Firstly, that user would see on-chain that the UTXO backing that statechain was spent. Secondly the transaction history, because the operator must sign all state updates, would only have a clear cooperative closure in the chain of past transactions. Both of these things would allow the user to refuse the transaction knowing it was not legitimate.

Statechains also allow Lightning channels to be “put on top” of the statechain by having the statechain pay out to a multisig address between two people, and the two of them negotiating a conventional set of Lightning commitment transactions on top of it. It would need to close the statechain on-chain before closing the Lightning channel so would need to use longer timelock lengths for Lightning payments, but otherwise would function perfectly normally.

Overall with the massive privacy improvements of the new iteration of statechains, and the composability with Lightning, this opens many doors for the economic viability and flexibility of second layer transactional mechanisms on Bitcoin. Especially in light of the recent radical changes in mempool dynamics and the resulting fee pressure.

It offers the same type of liquidity benefits of Ark, i.e. being able to be freely transferable without needing receiving liquidity, but unlike Ark is live and functional today. It is undeniably a different trust model than something like Lightning alone, but for the massive gains in flexibility and scalability, it is definitely a possibility to explore. 

Credit: Source link