Statechains are a form of sidechain technology developed over the Bitcoin protocol.
The goal of sidechains, payment channels, or any other scalability-focused solution is to improve transaction times within the Bitcoin network. At the time of writing, each Bitcoin block is produced (on average) every 10 minutes, and each block contains a maximum of roughly 2MB worth of transactions.
On average Bitcoin can process between 7-10 transactions per second, which is deemed too slow for most commercial-focused needs.
In comparison, Visa, Mastercard, and other payment processors can go up to millions of transactions per second. Of course, like any service that achieves high throughput, they are heavily centralised.
To achieve better efficiency and a higher transaction processing rate, Bitcoin aims to implement alternative features which will keep most of its current decentralisation while at the same time allow for faster transfers between Bitcoin users.
How Statechains work
1/4 #Statechains are a novel layer two protocol, designed for off-chain Bitcoin transfer. It is facilitated by a multisig federation which never has complete control, making it non-custodial. Check out my new article, or keep reading below for a summary!👇https://t.co/kDRA2QhVkk
— Ruben Somsen 🚵♀️🚵♂️🚵🚳 (@SomsenRuben) June 4, 2019
The Statechains protocol provides a simple alternative method of transferring Bitcoins between agents. This protocol only uses the layer-one blockchain when entering or exiting the system or when there are disputes – much like Lightning.
A Statechain is a ledger that contains the history of every UTXO (unspent transaction output) that is under its management. This ledger is also maintained by the Statechain entity and servers, making them accountable for misbehaviour.
To improve security, more than one entity can be added as a Statechain validator, meaning it’s possible to make a federated group of signatories like a multisig group.
Moreover, the entity operating the Statechain is expected to keep a public ledger in which every transaction is recorded. This acts as evidence against unauthorised withdrawals. With this working model, fraud can be proven (and prevented in the future) provided that the users store the evidence that their transaction was, at some point, included in the Statechain.
Unlike other blockchains, in Statechains, every UTXO has a history that is independent of the history of other UTXOs, since coins cannot be merged or split into multiple outputs. Cleverly, this new blockchain model allows for users to selectively verify and track the history of only the UTXOs they care about.
While Statechains are not as secure as on-chain transactions, the technology is thought to be a step up from multisig security or federated sidechains. This implementation uses Schnorr signatures – a type of signature aggregation – Eltoo, adaptor signatures, and Graftroot as well if required.
Of course, Statechains also have a downside. The absolute need to transfer UTXOs in full as they cannot easily be split into smaller amounts means it’s difficult to micro-transact using Statechains.
Advantages of Statechains
When compared to the Lightning Network (LN), Statechains offer more security as coins can be transferred directly without having to find a path on a network of sufficiently funded channels, which can be a problem for routing and security.
Also, given users only verify and store the UTXOs that they care about, the Statechains protocol will be a better model in regards to data and memory requirements. A user that transacts more often or needs to verify and store more UTXOs will most likely need additional storage space in the form of additional nodes/channels than a user that deals with fewer UTXOs.
Additionally, even though there is a problem with micro-transactions on Statechains, it is possible to integrate LN payment channels with Statechains, meaning a user could use a Statechain with Lightning features for micro-transactions.
The original proposal, by Ruben Somsen, can be seen here.
Disclaimer: The views and opinions expressed by the author should not be considered as financial advice. We do not give advice on financial products.