Statechains are an original second low protocol that was originally developed by Ruben Somsen in 2018, depending on the proposal from Eltoo (or LN Symmetry). In 2021 a variation of the original proposal, Mercury, was built by Commercblock. In 2024 a further iteration of the original mercury schedule was built, Mercury Layer.
The Statechain protocol is a bit more complicated to discuss compared to other systems such as Ark of Lightning because of the range of variations that are possible between the original proposed design, the two that have actually been implemented and other possible designs that have been presented loosely.
Just like Ark, Statechains depend on a centralized coordinating server to function. Unlike Ark, they have a slightly different model of trust than a Vutxo in an Ark -Batch. They depend on the coordinating server to remove previously generated shares from a private key to remain confidential, but as long as the server follows the defined protocol and does this, they offer a strong security guarantee.
The general idea of a Statechain is to be able to transfer the ownership of a whole UTXO between different users outside the chain, facilitated by the coordinator. There is no requirement for receiving liquidity such as lightning or the coordinator server to offer liquidity such as Ark.
To begin with, we will look at the original protocol presented by Ruben Somsen.
The original Statechain
Statechains are effectively a pre -signed transaction with which the current owner of the Statechain can unilaterally withdraw to the chain whenever they want, and a history signed messages cryptographically proven that owners from the past and the recipients they sent the Statechain to approve those transfers.
The original design was built on Eltoo with the help of Anyprevout, but the current plans to make the same functionality possible, use Checktemplaterify and checksigfromstack (an explanation at a high level of this is at the end of the checksigromsack article). The basic idea is a script that makes a pre -signed transaction possible to publish any Utxo that has that script and locks the correct amount of Bitcoin, instead of being bound by publishing a single specific UTXO.
In the protocol, a user approaches a coordinator server approaching his coins on a Statechain and goes through a deposit protocol. The depositing user, Bob, generates a key that will be unique of him, but also a second “temporary” key that will eventually be shared (more about this). They then make a deposit transaction that locks their currency for a multisig that must sign the key to the coordinator and the transition key.
With the help of this multisig signing Bob and the coordinator a transaction that issues that coin and makes a UTXO that can be spent by another transaction signed by the temporary key and the key to the coordinator using LN Symetry, or Bob’s Unique Key after a timelock. Bob can now finance the multisig with the correct amount and the Statechain has been made.
To transfer a Statechain to Charlie, Bob has to go through a multiple process. Firstly, Bob signs a message with his unique private key that testifies to the fact that he will transfer the Statechain to Charlie. Charlie must also sign a message that testifies to the fact that he has received Bob’s Statechain. Finally, the coordinator server must sign a new transaction with which Charlie can unilaterally claim the Statechain on-chain before Bob Charlie sends a copy of the transition key.
All this is made atomair with the help of adapter signatures. These are signatures that are changed in such a way with the help of any piece of data that makes them invalid, but can be made valid again as soon as the holder of the signature receives that piece of information. All messages and the new pre -signed transaction are signed with adapter signatures and at the same time made valid by the release of the adapter data.
Holders of a Statechain should be confident that the coordinator server never consumes with an earlier owner to sign an immediate closure of the Statechain and to steal funds from the current owner, but can prove the chain of pre -signed messages that a coordinator participated in theft if they would. If a previous owner tries to use his pre -signed transaction to steal the funds, the Timelock on the issue path with only their key allows the current owner to submit his pre -signed transaction and to correct the funds on the chain correctly.
Mercury and mercury layer
The original Statechain architecture requires a softfork to function. Commercblock designed their variant of Statechains to function without a softfork, but to do this, considerations were made in terms of functionality.
The basic idea is the same as the original design, all users have a pre-signed transaction with which they can unilaterally claim their funds, and the coordinator server still plays a role in facilitating off-chain transfers who need to be trusted to be honestly. The two most important differences are how those transactions are signed and the structure of the pre -signed transaction users is given.
With regard to the signing, there is no longer a passing private key that is passed on from the user to user. Instead, a Multiparty computation protocol (MPC) is used, so that the original owner and the coordinator server are able to generate partial pieces of a private key together without ever having the entire key. This key is used to sign the pre -signed transactions. With the MPC protocol, the current owner and coordinator can deal with a second protocol with a third party, the recipient of a transfer, to regenerate different pieces That amounts to the same private key. In both the Mercury and the Mercury Layer protocol, a transfer removes a fair coordinator server that corresponds to the previous owner. As long as this is done, it is no longer possible for the coordinator to sign a transaction with a previous owner, because the new piece of important material they have is not compatible with the piece that a previous owner still has. This is actually a stronger guarantee, as long as the coordinator is fair than the original proposal.
The pre-signed transaction structure for mercury and mercury layer cannot use LN symmetry, because this is not possible without a softfork. Instead, Commercblock chose to use falling timelocks. The pre -signed transaction of the original owner is time with the help of NLockTime to a time floats in the future from the point of creating the Statechain. Since each next user receives the Statechain during a transfer, the NLockTime value of their transaction is a predetermined duration shorter than the previous owner. This guarantees that a previous owner is unable to even try to submit his transaction chains before the current owner can, but it also means that at some point the current owner will ultimately must Close their Statechain on-chain before the transactions of previous owners become valid.
The big difference between mercury and mercury layer is how these transactions are signed. In the case of Mercury, the coordinator server easily sees the proposed transaction, verifies it and then signs it. Mercury Layer uses a blind -drawing protocol, which means that they actually do not see any details of the transaction they sign. This requires that the Server -tracking Statechains requires anonymized records on the server and a special authorization key from the current owner, so that they can be sure that they only sign valid transfers.
Synergy with other layers
Storechains can synergy with other layer 2s based on pre -signed transactions. Part of the original proposal, for example, suggested a combination of Statechains and Lightning channels. Because both are simply pre -signed transactions, it is possible to actually nest a lightning channel on a Statechain. This simply requires the unilateral exit key of the current owner to be a multisig, and making the pre-signed transactions that output publish in a lightning tray. This allows lightning channels to open and closed completely off-chain.
In the same way it is possible to nest a Statechain on a vutxo in an Ark -Batch. This simply requires the pre-signed transactions that are needed to build a Statechain, thereby issuing the VUTXO output.
Shutdown
Statechains are not entirely reliable, but they are a very confidential-minimalized schedule that is very liquidity efficient and it is freely to transfer Utxos off-chain between all users willing to accept the trust model of Statechains.
Although the original proposal still has to be built, the two implementations designed by Commercblock are fully implemented. Both failed to achieve a little more than marginal use in the real world. Whether this is because users are not willing to accept the relevant trust model, or simply a failure in marketing or consciousness is something that cannot be fully determined.
Anyway, since there are two complete implementations and designs for a more flexible variation such as LN symmetry ever becomes possible on Bitcoin, this is an option that will always be here. The nice thing about Open Source software is that it will always be there, regardless of whether people use it now if they choose it in the future.
This message Bitcoin Layer 2: Statechains first appeared on Bitcoin Magazine and was written by Shinobi.