“`html
Statechains represent a unique secondary layer protocol initially crafted by Ruben Somsen in 2018, reliant on the eltoo (or LN Symmetry) concept. In 2021, an adaptation of the foundational proposal, Mercury, was developed by CommerceBlock. In 2024, a subsequent version of the initial Mercury design emerged, termed Mercury Layer.
The Statechain protocol is somewhat more intricate to analyze compared to other frameworks such as Ark or Lightning due to the variety of adaptations that exist between the initially suggested architecture, the two that have been concretely implemented, and various alternative designs that have been loosely suggested.
Similar to Ark, Statechains rely on a centralized coordinating server for their operation. Unlike Ark, however, they possess a somewhat different trust framework compared to a vUTXO in an Ark batch. They depend on the coordinating server to erase previously generated segments of a private key to maintain a trustless system, but as long as the server adheres to the established protocol and carries out that function, they offer robust security assurances.
The fundamental concept of a Statechain is to facilitate the transfer of complete UTXO ownership among different individuals off-chain, assisted by the coordinator. There is no necessity for incoming liquidity like Lightning, nor is there a requirement for the coordinator server to supply any liquidity as seen in Ark.
To commence, we will examine the original protocol introduced by Ruben Somsen.
The Original Statechain
Statechains essentially serve as a pre-signed transaction that permits the current holder of the Statechain to independently withdraw on-chain whenever desired, alongside a history of signed messages that cryptographically validate that former owners and the recipients to whom the Statechain was sent approved those transactions.
The initial design was based on eltoo utilizing ANYPREVOUT, whereas the current strategy to enable similar functionality employs CHECKTEMPLATEVERIFY and CHECKSIGFROMSTACK (a simplified summary of this is included at the conclusion of the CHECKSIGFROMSTACK article). The core idea is a script that allows a pre-signed transaction to utilize any UTXO that contains that script and secures the appropriate amount of bitcoin, rather than being specific to a single UTXO.
Within the protocol, a user seeking to deposit their coins into a Statechain approaches a coordinating server and undergoes a deposit procedure. The depositing user, Bob, generates a key that will be uniquely allocated to him, and additionally creates a secondary “transitory” key that will eventually be shared (more details on this shortly). Subsequently, they formulate a deposit transaction that locks their coin to a multisig requiring both the coordinator’s key and the transitory key for signing.
Utilizing this multisig, Bob and the coordinator endorse a transaction that utilizes that coin and yields a UTXO that can be expended by any subsequent transaction endorsed by the transitory key and the coordinator’s key employing LN Symmetry, or by Bob’s unique key after a specified timelock. Bob can now fund the multisig with the required amount, thereby establishing the Statechain.
To transfer a Statechain to Charlie, Bob must follow a multi-step process. Initially, Bob signs a message with his unique private key certifying his intent to transfer the Statechain to Charlie. Charlie is then required to sign a message confirming that he has obtained the Statechain from Bob. Ultimately, the coordinator server must endorse a new transaction that empowers Charlie to freely claim the Statechain on-chain before Bob provides Charlie with a copy of the transitory key.
All of this is rendered atomic through the use of adapter signatures. These are signatures that are modified in such a manner using a random data piece that makes them invalid, yet they can be rendered valid again once the holder of the signature receives that data. All of the messages, as well as the new pre-signed transaction, are signed with adapter signatures, and are atomically validated simultaneously through the release of the adapter data.
Holders of a Statechain must have faith that the coordinator server will never collaborate with a previous owner to sign an immediate closure of the Statechain and misappropriate funds from the current owner. However, the series of pre-signed messages can demonstrate that a coordinator has engaged in theft if they were to take such action. Should a past owner attempt to utilize their pre-signed transaction to seize the funds, the timelock on the spend path using solely their key allows the current owner to submit their pre-signed transaction and rightfully claim the funds on-chain.
Mercury and Mercury Layer
The original Statechain framework necessitates a softfork to operate. CommerceBlock crafted their variant of Statechains to work without a softfork, but in doing so, certain tradeoffs regarding functionality were undertaken.
The fundamental concept remains akin to the original model, where all users possess a pre-signed transaction enabling them to unilaterally claim their funds, and the coordinator server still plays a role in facilitating off-chain transfers that require it to be trusted to act honestly. The two principal differences lie in how those transactions are signed and the configuration of the pre-signed transaction provided to users.
Regarding signing, there is no longer a transitory private key transferred among users. Instead, a multiparty-computation protocol (MPC) is implemented, allowing the original owner and the coordinator server to collaboratively create partial segments of a private key without either party ever possessing the complete key. This key is utilized to endorse the pre-signed transactions. The MPC protocol permits the current owner and coordinator to engage in a secondary protocol with a third party, the recipient of a transfer, to regenerate distinct segments that compile to form the same private key. In both the Mercury and Mercury Layer protocol, after concluding a transfer, an honest coordinator server eliminates the key material linked to the previous owner. As long as this process is adhered to, the coordinator can no longer authenticate a transaction with a previous owner, since the new key material they have is incompatible with what any past owner might retain. This actually provides a stronger assurance, assuming the coordinator remains honest, than the initial proposal.
The structure of the pre-signed transaction for Mercury and Mercury Layer is unable to utilize LN Symmetry, as this is unfeasible without a softfork. Instead, CommerceBlock opted for decrementing timelocks. The original owner’s pre-signed transaction is timelocked using nLocktime to a point significantly far into the future from the moment the Statechain was established. With each successive user receiving the Statechain during a transfer, the nLocktime value for their transaction is a pre-determined duration shorter than that of the prior owner. This ensures that a prior owner cannot even attempt to submit their transaction on-chain before the current owner can do so, yet it also implies that eventually, the current owner must finalize their Statechain on-chain before prior owners’ transactions become valid.
The significant distinction between Mercury and Mercury Layer involves how these transactions are endorsed. In the Mercury instance, the coordinator server simply observes the proposed transaction,
“““html
verifies it, and subsequently endorses it. Mercury Layer employs a blind-signing protocol, indicating that they do not actually perceive any specifics of the transaction they are endorsing. This requires the server to monitor Statechains using anonymized logs on the server and a distinct authorization key from the current proprietor to ensure they are solely endorsing legitimate transfers.
Collaboration With Other Layers
Statechains can collaborate with other Layer 2s that rely on pre-signed transactions. For example, a portion of the initial proposal recommended a fusion of Statechains and Lightning Channels. Since both consist of merely pre-signed transactions, it is feasible to actually nest a Lightning channel on top of a Statechain. This only necessitates the current owner’s unilateral exit key to function as a multisig, along with the establishment of the pre-signed transactions that utilize that output into a Lightning channel. This permits Lightning channels to be initiated and concluded entirely off-chain.
In a comparable manner, it is feasible to nest a Statechain atop a vUTXO in an Ark batch. This simply necessitates the pre-signed transactions essential for constructing a Statechain, utilizing the vUTXO output.
Conclusion
Statechains are not completely trustless, yet they represent a significantly trust-minimized schema that is highly liquidity efficient and facilitates the free transfer of UTXOs off-chain among any users willing to adopt the trust framework of Statechains.
While the initial proposal has yet to be realized, the two implementations crafted by CommerceBlock have been thoroughly executed. Both struggled to achieve anything beyond marginal use in practical scenarios. Whether this is due to users’ reluctance to accept the trust framework involved, or simply a shortcoming in marketing or awareness, remains uncertain.
Nonetheless, given that there are two complete implementations and designs for a more versatile variation should LN Symmetry ever become achievable on Bitcoin, this is an option that will always be available. The advantageous aspect of open-source software is that it will persist regardless of current usage, should individuals choose to utilize it in the future.
Source link
“`
