State Channels Still Beat All Other Layer-2 Scalability Solutions
Tags: web3, blockchain, crypto, blockchaintechnology
Published: 2022-06-13 06:08:22

We can’t help writing about what we work on in [Yellow Network](https://www.yellow.org). Previously, we talked a lot about the issues of [blockchain interoperability and crypto market fragmentation](https://medium.com/yellow-blog/what-is-web3-liquidity-aggregation-f27bf8e52a7). In this article, we will cover another not less significant problem of the industry — the **blockchain scalability** and will focus on state channels as its most prominent solutions. Here we would like to explain these things simply but in-depth and showcase how we use state channels to make cross-chain transactions instant and low-cost. Let’s dive in!

## Why is scalability so important for blockchain?

The more crypto adoption is gaining momentum, the more it becomes challenging for blockchain networks like Bitcoin and Ethereum to provide participants with the due user experience. The original designs of the networks get less and less suitable to process the growing transaction numbers without losing on speed and increasing transaction fees. It's good to remind here that the Ethereum network can handle ~15 TPS (transactions per second), and the Bitcoin network can handle ~5 TPS. That was great at the beginning but no longer feasible at the present moment.

> Clumsy and semi-functional network design becomes a major turnoff for potential users considering joining a network, as well as for existing users to keep continuously exploring a network. From the marketing perspective, it's literally killing the user retention rate.

Herewith, the growing number of decentralized applications (dApps) creates an extra load on networks. As dApps are getting more complicated, they require more computational power to function, but at the same time, they seek faster transaction speed and lower fees. So as we see here, blockchain scalability and its mass adoption are pretty interdependent things. This is why solving the scalability problem is so vitally important for the whole crypto industry to keep progressing and widespread.

## How do we solve scalability issues in blockchain?

Roughly saying, there are two main approaches to handling the scalability problem. These are "**off-chain**" and "**on-chain**" approaches - a few words on each.

### On-chain

"On-chain" means that we make some improvements on the blockchain level (Layer 1). Here we can, at least, try to innovate the existing consensus algorithm, replace it with a better one (f.eg. [Proof-of-Work](https://en.wikipedia.org/wiki/Proof_of_work) with [Proof-of-Stake](https://en.wikipedia.org/wiki/Proof_of_stake)), or create a groundbreaking new one from scratch. The end goal here would be to achieve better bandwidth and throughput and decrease the computational power required for transaction processing. As an example, Ethereum is currently undergoing on-chain scaling through [sharding](https://ethereum.org/en/upgrades/shard-chains/). 
Briefly, sharding is the process of splitting a database horizontally to spread the load. In the Ethereum context, sharding will reduce network congestion and increase the number of transactions per second by creating new 60+ chains, known as "_shards_." This will also reduce the load for each validator, as they will no longer be required to process the entirety of all transactions across the network. The consensus mechanism will move from highly computational and clumsy Proof-of-Work (PoW) to Proof-of-Stake (PoS) with lower hardware requirements.

### Off-chain

While on-chain scaling is a great way to go in the long term, however, this is an extremely complicated task. It requires massive efforts and enormous time (it can take years) to get accomplished. A way more flexible alternative to on-chains is "off-chain" solutions that do not modify the base blockchain. Off-chain or interchangeably, Layer 2 solutions, are built upon blockchains and exist in the form of their superstructures. The main job of off-chain solutions is to improve users' transaction experience by getting rid of existing blockchain networks bottlenecks, like slow speed and high fees. The core principle of the off-chain solutions' work is moving transaction sessions out of the blockchain and publicly recording only their final balance. The most applied off-chain solutions are:

- state channels
- sidechains, and
- rollups.
Below we will cover how they differ while focusing on state channels. Other examples to add here could be [validiums](https://ethereum.org/en/developers/docs/scaling/validium/) and [Plazma](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/plasma/). However, they are less common and won't be addressed in this article.

## What is a state channel?

A state channel is a mechanism enabling transacting parties to _interact off-chain_ and further record with a blockchain only the final state between them. It's like two traders would make x-number of transactions between each other during a day, and by the evening, would officially post the final net balance between them. This trick allows to overcome all the challenges arising out of blockchains' clumsy nature, making transactions fast and cheap while still being the same secure as if they were conducted directly on-chain. Here is how to use them:

### 1. Opening

To initiate a state channel, counterparties shall deposit a required amount of collateral (i.e., funds) with a [multisig](https://en.wikipedia.org/wiki/Multisignature) contract. Then the collateral of both will be deducted and sent to a smart contract running the state channel. A deposit transaction will deduct money from the party's accounts and transfer it to a particular smart contract that cooperates with this state channel. This depositing mechanism is aimed to ensure that no [double-spending](https://www.investopedia.com/terms/d/doublespending.asp) will occur neither on the on-chain nor on the off-chain sides of interactions. And this is where the first fee payment happens.

### 2. Transacting

Since a state channel is open, parties are free to conduct the transactions as much as they prefer through cryptographically signed messages. Their "P&L" inside the channel will alter with each transaction that happens.

### 3. Settlement and channel closing

Finally, any party can initiate an on-chain transaction when all the transactions are done. For that, both parties should agree on the final state of the channel and submit it to the blockchain for the record. And now it's time for the second fee payment.

### What if there is a dispute?

If a participant rejects confirming the final state or simply doesn't respond, the other party can register a dispute on-chain. Then this party will have to submit to a smart contract **the latest state** of their digitally signed transactions recorded off-chain to prove their claims are legitimate. Another party can disagree that the provided state is the latest and submit the more updated state in response. In the end, the parties would turn to the settlement or the force-execution phase (depending on the specifics of a channel design).

## Killer features of state channels

Summing up, the key benefits of state channels are:

- **High throughput**: moving transactions off of a chain allows to dramatically reduce the computational load of a Layer 1 network without losing on security
- **Strong privacy properties**: transactions within a state channel are not publicly broadcasted. Only the opening and closing of a state channel goes into a blockchain.
- **Instant settlement**: once both parties sign a state update, all the transactions between them are deemed to be completed. No miners' confirmations are required for that.
- **Low fees**: transactions happening inside a channel do not require any computational power, and therefore they are cheap.

## Limitations of state channels

Like with any technology, the application of state channels has its limitations. Basically, these limitations look as follows:

- **Pre-defined counterparties requirement**: A channel cannot be used to send funds off-chain to users who are not the channel's participants.
- **Availability requirement**: They have to be available in case their counterparty wishes to rigger settlement.
- **Insufficiency for some types of real-time interactive applications**, when the parties get into a dispute and have to resolve it on a blockchain (i.e., adjust to slow blockchain speed).

## State channels implementation (2015–2021)

Here is a quick historical data on how state channels have been implemented:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eh5kasol8uk4x45sca88.jpeg)

## Examples of state channels implementation in 2022

Here I would just share some great examples of ongoing projects relying on state channels, including ours (why not?😊):

- [Yellow Network](https://www.yellow.org) - a non-custodial multi-chain trading environment and automated clearinghouse, providing a user with aggregated crypto liquidity, price feed, and seamless high-speed cross-chain transactions at minimal fees.
- [Perun Network](https://perun.network) - a state channel application that supports payments, microservices, IoT, gaming, and other business use cases.
- [Raiden Network](https://raiden.network) - an instant payment solution with low fees compatible with all ERC-20 tokens.
- [Graph Protocol](https://thegraph.com/en/) - a blockchain indexing and querying service utilizing state channels for settling rewards for node operators (indexers).

## State channels vs. Payment channels

Payment channels are a specific use case of state channels. They are only designed to support payments between two or more parties. The most well-known example of payment channels is [Lightning Network](https://lightning.network). Comparing payment channels with state ones, the latter have much broader applications and are not limited only to payments. For example, state channels can also be used for scaling a dApp or a blockchain (like [Celer Network](https://www.celer.network)), in real-time gaming, etc.

> Essentially, state channels are an answer for any decentralized application which needs a high throughput, privacy at a transaction level, and the same level of security as a Layer 1 blockchain.

## State channels vs. Sidechains vs. Rollups

### Sidechains

Unlike a state channel, a side chain is a _separate blockchain_ that is connected with its parent blockchain (the main chain) through a two-way peg. Sidechains run in parallel with their main chains and have their own consensus algorithms. Though side chains are similar to the main chain in terms of smart contract language and code deployment, they have different validator nodes and, unlike state channels, side chains do not inherit the main chain's security properties. A two-way peg enables the transfer of assets between the main net and side chain. The side chain's consensus mechanism (ex: PoS) allows it to process transactions at a higher throughput. The transactions are batched and brought on the main chain, which reduces the computational load on the main chain and thereby reduces the gas fees. Examples of sidechain projects:

- [Polygon](https://polygon.technology) - a proof-of-stake sidechain for scaling Ethereum.
- [Gnosis Chain](https://gnosis.io) - a stable coin payment network built on Ethereum.xDAI is a USD pegged stable coin on the Gnosis chain.
- [Liquid Network](https://liquid.net) - a bitcoin sidechain for quick payments and settlements with applications for exchanges.
- [RootStock](https://www.rsk.co) - a side chain with smart contract functionality on Bitcoin.

## Rollups

Rollups are a group of solutions that use different techniques to 'bundle' transactions and submit them to the main net, thereby increasing the speed and reducing the fee per transaction. Like state channels, rollups perform transaction execution outside Layer 1, and then the data is posted to Layer 1, where consensus is reached. The main difference between state channels and rollups is that the latter involve an intermediary to process transactions - a rollup operator. Also, state channels are suitable for a wider variety of use cases than rollups at the present moment. Examples of rollups:

- [Optimistic rollups](https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/) (as defined on Ethereum.org): assume transactions are valid by default and only run the computation, via a fraud proof, in the event of a challenge.

- [Zero-knowledge rollups](https://ethereum.org/en/developers/docs/scaling/zk-rollups/): run computation off-chain and submits validity proof to the chain.

## State channel implementation in Web3 multi-chain trading: Yellow Network

As we mentioned above, Yellow Network enables [multi-chain high-speed trading](https://hackernoon.com/an-intro-to-web3-multi-chain-trading) and liquidity aggregation from multiple exchanges and DeFi protocols. At the core of Yellow's architecture is an **overlay mesh peer-to-peer (P2P) network **that uses state channels for two primary purposes:

- to unify all blockchains and allow their interoperability, and
- to enable reaching any token circulating on whatever isolated network and transfer it to other networks (no matter whether the networks are compatible) without bridging.
Below is how it works.

### (i) Channel opening

To open a trading state channel, the counterparties need to agree on the amount of YELLOW tokens to be provided as collateral and then deposit them with a smart contract called Adjudicator. Once this is done, the state channel is active, and the counterparties can start trading.

### (ii) Remote order matching

The trades are facilitated by the matching engine 'Finex'. The engine allows the exchanges to place bulk orders and cancellations with a validation process that ensures trades are being executed within funding limits. The transactions are then maintained with a metadata index without processing them in the blockchain.

### (iii) Settlement

The settlement process may be initiated by any party at any time and should be validated by all the parties involved. After that, the trading channel closes. 
Essentially, Yellow Network is a **Layer 3** that operates independently of blockchains but facilitates their interconnection and cross-functionality, massively relying on state channel technology. As a result, Yellow's architecture enables a matching throughput of around billions of messages per day, which is significantly faster than any paired Layer 1 and Layer 2 solutions available today. At the end, it would even enable h[igh-frequency crypto trading](https://medium.com/yellow-blog/a-complete-introduction-to-high-frequency-crypto-trading-cf36bd0c8720) in the same manner as it's done in traditional finance.

## Yellow Network's Features

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s7cr4m7qkg0sulp2beev.jpeg)

## Key takeaway

Compared with other scalability solutions, state channels still maintain their winner position. They are easier for implementation, cheap and fast in terms of their functionality, absolutely disintermediated, and secure ̶a̶s̶ ̶h̶e̶l̶l̶ the same as a blockchain they operate with. Moreover, state channels are feasible for more use cases than their alternatives. When it comes to Web3 multi-chain trading, state channels are the best bet, as they help overcome blockchains' interoperability challenges and provide speed, enabling even crypto HFT. Yellow Network is the perfect example to prove that.

## Want to learn more about Yellow Network and cross-chain trading technology?

- Check out OpenDAX v4 stack GitHub: [github.com/openware/opendax ](https://www.openware.com/product/opendax)
- Visit the OpenDAX product page: [https://www.openware.com/product/opendax](https://www.openware.com/product/opendax)
- Follow Yellow Twitter: [twitter.com/Yellow](twitter.com/Yellow) 
- Join the public Yellow Network Telegram: [t.me/yellow_org](t.me/yellow_org)
-  Read Yellow Network Medium blog: [medium.com/yellow-blog ](medium.com/yellow-blog )

Stay tuned as Yellow Network unveils the developer tools, brokerage nodes stack, and community liquidity mining software!