Statechains is an original second layer protocol, originally developed by Ruben Somsen in 2018, depending on the proposal for Eltoo (or LN -symmetry). By 2021, a variation of the original proposal, Merkur, was built by Commerceblock. By 2024, a further iteration of the original Mercury scheme was built, Mercury Layer.
The Statechain Protocol is a little more complicated to discuss compared to other systems, such as sheet or lightning due to the variation of variations possible between the original proposed design, the two that have actually been implemented, and other possible designs that have been resolved.
Like sheet, the StateChats depends on a centralized coordinating server to work. Unlike sheets, they have a slightly different trust model than a Vutxo in a sheet of batch. They depend on the coordinating server to delete previously generated shares in a private key to remain trustless, but as long as the server follows the defined protocol and does, they provide a strong security guarantee.
The general idea of ​​a statechain is to be able to transfer ownership of an entire UTXO between different users outside the chain, relieved by the coordinator. There is no requirement for receiving liquidity such as lightning or coordinator server to provide any liquidity as a sheet.
For starters, we will look at the original protocol suggested by Ruben Somsen.
The original Statechain
Statechains is effectively a pre-separated transaction that allows the current owner of Statechain to unilaterally pull on-chain whenever they want, and a story signed messages cryptographically proving that former owners and recipients they sent StateChain to approved these transfers.
The original design was built on Eltoo using Anyprevout, but the current plans for how to enable the same functionality make use of CheckTemplateverify and Checksigfromrack (an explanation of high level of this is at the end of the controls of the Controlsigfromstack article). The basic idea is a script that enables a pre -separated transaction to use any UTXO that has the script and locks the appropriate amount of Bitcoin instead of being bound to use a single specific UTXO.
In the protocol, a user wants to deposit their coins to a statechain, a coordinator server and undergo a deposit protocol. The deposit user, Bob, generates a key that will be uniquely owned by him, but also another “passing” key that will eventually be shared (more on this soon). They then prepare a deposit transaction that locks their coin to a multi -poem that requires the coordinator’s key and the transient key to sign.
Using this multisig, Bob and the coordinator sign a transaction that uses it coin and creates an UTXO that can either be used by any other transaction signed by the transient key and the coordinator’s key using LN Symmetry, or Bob’s unique key after a time lock. Bob can now finance Multisig with the appropriate amount and Statechain has been created.
To transfer a Statechain to Charlie, Bob has to go through a multistep process. First, Bob signs a message with his unique private key that certifies the fact that he will transfer Statechain to Charlie. Charlie also has to sign a message that testifies that he has received Statechain from Bob. Finally;
All of this is made atomic using adapter signatures. These are signatures that have changed in such a way using a random piece of data that makes them invalid, but can be made valid again when the signature holder receives that piece of information. All messages and the new foreskin transaction are signed with adapter signatures and atomic are valid at the same time through the release of the adapter data.
Holders of a Statechain must trust that the coordinator server never conspires with a previous owner to sign an immediate closure of State Chain and steal funds from the current owner, but the chain of foreskin messages can prove that a coordinator has participated in theft if they were to do so. If a previous owner tries to use their pre -signed transaction to steal the funds, Timelock on the consumption path only allows their key to submit their pre -signed transaction and correctly demand the funds on chain.
Mercury and mercury layers
The original Statechain architecture requires a softfork to work. Commerceblock designed their variant of Statchains to work without a softfork, but to do so were made up in terms of functionality.
The basic idea is the same as the original design, all users have a pre -separated transaction that allows them to demand their funds one -sided, and the coordinator server still plays a role in facilitating the upper chain that requires them to trust to behave honestly. The two major differences are how these transactions are signed and the structure of the foreskin transaction users is given.
Where signing relates, there is no longer a transient private key transferred from user to user. Instead of this, a multiparty computation protocol (MPC) is used, so the original owner and coordinator server are able to collaborate with generating partial pieces of a private key without any of them ever having the full key. This key is used to sign the foreskin transactions. The MPC protocol allows the current owner and coordinator to participate in another protocol with a third party, the recipient of a transfer, to regenerate Different pieces that adds the same private key. In both the Mercury and the Mercury Layer Protocol, an honest coordinator server deletes the most important material 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, as the new piece of key material they have is not compatible with the piece that any previous owner can still have. This is actually a stronger guarantee as long as the coordinator is honest than the original proposal.
The foreskin transaction structure for mercury and mercury layers cannot use LN symmetry as this is not possible without softfork. Instead of this, Commerceblock chose to use decrement timelocks. The original owner’s foreskin transaction is time -long with the help of Nlocktid to a time far out in the future from Point of the Statechain’s creation. Since each subsequent user receives Statechain during a transfer, the NLOCTIME value of their transaction is somewhat predetermined time that is shorter than the previous owner. This guarantees that a previous owner is unable to even bowl Close their Statchain On-Chain before former owner’s transactions begin to become valid.
The biggest difference between mercury and mercury layers is how these transactions are signed. In the case of Mercury, the coordinator server simply sees the proposed transaction, verifies it and then signs it. Mercury layers use a blind-signing protocol, which means they actually don’t see any details of the transaction they sign. This necessitates server tracking of Statchains using anonymous items on the server and a special authorization key for the current owner so that they can be sure that they only sign valid transfers.
Synergy with other layers
Statechains can be synergized with other layers 2s based on pre -empted transactions. For example, part of the original proposal suggested a combination of statchains and lightning channels. Because both are simply foreskin transactions, it is possible to actually witch a lightning channel on top of a state chain. This simply requires the current owner’s one-sided exit key to be a multi-emergency, and the creation of the prescribed transactions that use that emits a lightning channel. This makes it possible to open lightning channels and close completely off-chain.
Similarly, it is possible to witch a state chain on top of a Vutxo in a sheet of batch. This simply requires the foreskin transactions needed for a statechain to be constructed and uses Vutxo output.
Wrapping
Statechains are not entirely confidence-free, but they are a very trust minimized scheme that is very liquidity effective and allows freely to transfer Utxos off-chain between any users willing to accept the trust model for Statchains.
While the original proposal has not yet been built, the two implementations designed by Commerceblock have been completely implemented. Both could not achieve anything more than marginal use in the real world. Whether this is because users are unwilling to accept the model involved, or just a failure in marketing or attention is something that cannot be fully ascertained.
Notwithstanding anything to two full implementations and designs for a more flexible variation, if LN Symmetry will ever become possible on Bitcoin, this is an option that will always be here. The great thing about open source software is that it will always be there, regardless of whether people use it now if they choose in the future.