CommerceBlock is launching Mercury Layer today, an enhanced version of its version of the Country Series. You can read a longer explanation of how their Mercury case chains work here. The upgrade to Mercury Layer represents a huge improvement over the initial implementation of the state chain, but unlike the initial Mercury Wallet release, this wallet 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 similar to payment channels in many respects, i.e. they are a cooperatively shared UTXO with a pre-signed transaction as a last resort mechanism for people to enforce their ownership. The main difference between a Lightning Channel and a state chain is the parties involved in collaboratively sharing a 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, the state chain is open with a facilitator/operator, and can be completely freely transferred between any two participants who are willing to trust the operator to be honest, completely off-chain. The person wishing to upload the state chain collaborates with the operator to create a single public key. The creator and operator each have a share of the corresponding private key, with neither having a complete copy of the key. From here they pre-sign a transaction that allows the creator to get their coins back after a unilateral period of time.
To transfer the state chain, the current owner cooperates with the receiver and operator to sign cryptographic proof using their private key share that they are transferring the coin, then the receiver and operator create a new pair of key shares that add up to the same private key and sign a temporary transaction for the new owner with a shorter time lock than the original. (To ensure they can be used sooner than previous owners). This process is repeated with each transfer until the time lock can no longer be shortened, at which point the state chain must be closed on the chain.
Owners transfer the entire historical chain of past states with each transfer so users can verify that timelocks are reduced correctly and the operator timestamps them using Mainstay, a variation of Opentimestamps where each piece of data has its own unique “slot” in the tree Merkle to ensure that only one copy of the data is timestamped. This allows everyone to review the transfer history of the country series.
In the land of the blind
The major change that Mercury Layer has brought to the original version of the country strings is amazing. The state chain service operator will no longer be able to know anything about what is being transferred: for example, the TXIDs involved, the public keys involved, and even the signatures it collaborates with users to create for the pre-signed transactions needed to claim a refund. Your money is on one side.
By offering a blind version of Schnorr MuSig2, Mercury can facilitate the process of signing regressive transactions without knowing any details of what they are signing. This requires some design changes in order to take into account the fact that the operator is no longer able to see and publish the entire transfer history of the state chain. They are not even able to verify the validity of the transaction they sign at all.
In the previous iteration, the uniqueness of the owner/set of current transactions of the state chain was proven by the operator by publishing the complete transfer history of the state chain with Mainstay. This is not possible here, because in the encrypted version, the operator does not know any details at all about these transactions. This necessitates a new way for the operator to prove current ownership of the state chain. All this data is pushed in full to the client-side verification form. The operator simply keeps track of the number of times it has signed something for one country chain, and tells the user that number when requested. The user then receives transactions for the previous state of the chain from the user to whom they are sending them, fully verifies on the client side that the number of transactions matches what the operator claimed, and then fully validates all signatures and reduces the timelocks by the appropriate amount each time. Instead of publishing the full state chain transactions and transfer order to Mainstay, because it is designed not to be aware of all that information, it publishes its share of the public key (not the full total public key) of the current user for each user's state chain. This allows any user receiving a status string to verify that the transfer history and current status are legitimate against the transaction data sent by the sender.
The trigger server keeps track of unique state chains to account for past signatures by assigning a random identifier to each state chain upon creation, which is stored with its label, private key, and shares of the public key (not the entire overall public key). The new format scheme for key splitting and repartitioning is implemented in such a way that the server passes its share of the key to the user, and the data needed for the repartition is withheld so that the server is not able to fully identify the user. Sharing the public key, allowing it to generate the complete public key and determine the currency on the chain.
The design doesn't even let the operator know when it has signed a collaborative closing with the current owner rather than a previously signed transaction for a new off-chain owner; He does not see any details 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 to provide a fake transaction that cannot be cleared. First, this on-chain user will see that UTXO support has been spent for that country chain. Second, since the operator must sign all state updates, the transaction history will only have a clear cooperative closure in the chain of previous transactions. Both commands will allow the user to reject the transaction knowing it is illegal.
The state chain also allows Lightning channels to be “put on top” of the state chain by having the state chain pay for a multi-signature address between two people, and the two negotiate a traditional set of Lightning commit transactions on top of it. You will need to close the on-chain state chain before closing the Lightning channel, so you will need to use longer time lengths for Lightning payments, but otherwise it will work quite normally.
Overall, with the massive privacy improvements of the new iteration of state chains, and composability with Lightning, this opens many doors to the economic viability and flexibility of layer 2 transaction mechanisms on Bitcoin. Especially in light of the recent drastic changes in mempool dynamics and the resulting fee pressure.
It offers the same kind of liquidity benefits as Ark, i.e. the ability to be freely transferable without having to receive liquidity, but unlike Ark it is live and active today. It's undoubtedly a different trust model than something like Lightning alone, but for the massive gains in flexibility and scalability, it's certainly a possibility to explore.
