Bitcoin Layer 2 Statechain

Author: Shinobi

Source: https://bitcoinmagazine.com/technical/bitcoin-layer-2-statechains

"Statechain" is an original Layer 2 protocol, initially proposed by Ruben Somsen in 2018; the initial proposal relied on the "eltoo (or LN Symmetry)" proposal. In 2021, the CommerceBlock team developed a variant of the initial proposal: "Mercury". In 2024, the original Mercury was iterated into a version called "Mercury Layer". The Statechain proposal is more complex to explain compared to other systems (such as Ark or Lightning Channels) because from the initial proposal design to two implemented variants, and to sparsely proposed designs, it allows a wide range of variations. Similar to the Ark instance, the Statechain instance also relies on a centralized coordination service. However, unlike the Ark protocol, the trust model of the statechain is slightly different from a vUTXO in the Ark batch. Statechain relies on the coordinator deleting a key fragment previously generated to maintain trustlessness; but as long as the service provider follows the defined protocol, they provide a strong security guarantee. The overall idea of Statechain is to transfer the ownership of an entire UTXO between different users off-chain with the help of a coordinator. It does not require the recipient to have a receiving quota like Lightning Channels, and the coordination service provider does not need to provide liquidity as in the Ark protocol. Let's first look at the initial protocol proposed by Ruben Somsen. For the latest owner of a Statechain, the funds consist of two parts: (1) A pre-signed transaction that allows them to withdraw funds on-chain unilaterally at any time; (2) A cryptographically signed historical message proving previous ownership and the recipients authorized by the statechain transfers. The initial design was built on the eltoo protocol using ANYPREVOUT, but the current idea for enabling similar functionality is to use CHECKTEMPLATEVERIFY (CTV) and CHECKSIGFROMSTACK (CSFS) (a summary explanation can be found at the end of the article about CSFS). The basic idea is to create a script that allows a pre-signed transaction to spend any UTXO with this script and of a certain value, rather than letting the pre-signed transaction only spend a specific UTXO. In the statechain protocol, a user wanting to deposit funds into a Statechain first contacts a coordination service provider and goes through the deposit process. We'll call this depositing user Bob, who generates a key known only to himself ("unique key") and a "temporary key" that will eventually be shared (details later). Then, he can construct a deposit transaction, locking Bob's funds into a multisig address that requires signatures from both the coordinator's key and the temporary key. Based on this multisig address, Bob and the coordinator sign a transaction spending these funds, creating a UTXO that can be spent by any transaction signed using the LN Symmetry protocol with the temporary key and coordinator key, or by Bob's unique key after a time lock expires. Now, Bob can sign and broadcast the deposit transaction, and the Statechain is created. To transfer a Statechain to Charlie, Bob must complete a multi-step process. First, Bob signs a message with his unique key, indicating he is preparing to transfer the Statechain to Charlie. Charlie must also sign a message acknowledging receipt of the Statechain from Bob. Finally, the coordination service provider must sign a new transaction allowing Charlie to unilaterally withdraw funds from the Statechain on-chain, after which Bob sends Charlie a copy of the temporary key. All steps are made atomic using "adapter signatures". These signatures are modified in a special way: a random data segment makes them invalid signatures, however, if the signature holder obtains a message corresponding to that random data segment, they can regenerate a valid signature. All the above messages, as well as the new pre-signed transaction, use adapter signatures, and become valid messages atomically through the release of adapter data. Statechain holders must trust that the coordination service provider will never collude with previous owners to sign an immediate Statechain closure transaction (thus stealing funds from the current owner), but if the coordinator does so, the chain of pre-signed messages can prove their involvement in the theft. If a previous owner attempts to steal funds using their pre-signed transaction, (with the destination still containing the two spending paths mentioned), only the path with the key requires a time lock, so the current owner has time to submit their pre-signed transaction (spending the first path using LN-Symmetry), correctly withdrawing funds on-chain. The initial statechain architecture requires a soft fork (adding ANYPREVOUT or similar functionality) to work. CommerceBlock designed a statechain variant that doesn't require a soft fork, but with some functional sacrifices. Its basic idea remains consistent with the original design, with all users holding a pre-signed transaction allowing unilateral fund withdrawal, and the coordinator service provider still playing a crucial role in coordinating off-chain transfers, with users needing to trust their honest actions. Two significant differences are the signing method of the transactions users receive and the structure of these pre-signed transactions. First, signatures. Users no longer pass temporary private keys. Instead, Mercury uses a Multiparty Computation (MPC) protocol that allows users and the coordinator to collaboratively generate a private key, with each party only having a part of the key, with no party knowing the complete private key. This key is used to sign pre-signed transactions. This MPC protocol also allows the current owner and coordinator to participate in a second protocol with a third party (transfer recipient), enabling the coordinator and third party to generate another fragment but obtain the same private key. In the Mercury and Mercury Layer protocols, after completing a transfer, an honest coordinator must delete the key material corresponding to the previous owner. As long as this is done, the coordinator can no longer collaborate with previous owners to sign, because the remaining fragments in the coordinator's possession will not match any previous owner's fragments and cannot generate the correct private key. This provides a stronger security guarantee than the original proposal, as long as the coordinator remains honest. The pre-signed transactions in Mercury and Mercury Layer cannot use LN Symmetry (this functionality hasn't been added via soft fork yet). Therefore, CommerceBlock chose to use decreasing time locks. The earliest owner's pre-signed transaction uses the nLocktime field, an absolute time lock that can only be used in the distant future. With each transfer, subsequent users obtaining the Statechain have pre-signed transactions with absolute time locks shorter than the previous owner by a predefined length (can be used faster). This ensures that previous owners cannot prematurely submit pre-signed transactions on-chain (the latest owner's pre-signed transaction is always the fastest to broadcast), but it also means that at some point, the latest owner must close their Statechain on-chain, or the previous owner will have an opportunity. The main difference between Mercury and Mercury Layer is the transaction signing method. In Mercury, the coordinator service provider can see the current user's proposed transfer and can verify and sign it. In Mercury Layer, due to the blind signature protocol, the coordinator cannot see any details of the transactions they sign. Therefore, the service provider must use anonymous records and a special authorization key from the current owner to track each Statechain, ensuring only valid transfers are signed.

Collaboration with Other Solutions

Statechain can work collaboratively with other Layer 2 solutions based on pre-signed transactions. For example, part of the initial proposal suggested combining statechains and Lightning channels. Since both use pre-signed transactions, a Lightning channel can be encapsulated within a Statechain. This only requires the current owner's unilateral exit key to be a multi-signature and creates a pre-signed transaction to spend the Statechain into a Lightning channel. This allows the Lightning channel to be opened and closed entirely off-chain.

Similarly, a Statechain can be encapsulated in a vUTXO of an Ark round. This only requires constructing the pre-signed transaction necessary for the statechain to spend that vUTXO output.

Summary

Statechain is not completely trustless, but it is very close to minimizing trust; its liquidity efficiency is very high, and it allows users who are willing to accept the trust model to transfer UTXOs off-chain.

Although the initial proposal has not been implemented, two variants designed by CommerceBlock have been fully implemented. Both have only gained marginal users in the real world. This is either because users are unwilling to accept the trust model, or simply due to poor marketing and low attention, which is hard to conclude.

But in any case, given that there are two complete implementations, and more flexible variants can be designed as long as LN Symmetry is implemented on Bitcoin, this remains an always-available option. The beauty of open-source software is that it is always there, whether people use it now or wait for the future.