An article to understand the status quo of the state channel

Editor's Note: This article comes fromBlock Record (ID: BlockchainInsights), published with permission.

Editor's Note: This article comes from

Block Record (ID: BlockchainInsights)

Block Record (ID: BlockchainInsights)

, published with permission.

In this post, we'll learn the basics of how state channels work, and why their implementation is complex. We’ll discuss how they can be used for payments on Bitcoin’s Lightning Network, and how they can be leveraged for more complex applications, powered by Ethereum smart contracts. Finally, we'll explore why state channels have not seen widespread adoption so far, and why this might change.

How state channels work

The core premise of state channels is surprisingly simple to understand. Instead of using on-chain transactions, parties wishing to transact on a regular basis can first lock funds in a smart contract and then exchange signed messages off-chain that update the status of who owns which funds. Any number of transactions can happen off-chain, the speed of which is limited only by the ability of the parties to exchange signed messages. Whenever any party wants to exit the channel, they can submit the latest signature status to the smart contract on the chain, and the smart contract will verify the signature and distribute the funds according to the agreed distribution method.

Let's look at the simplest example of a state channel: a simple payment between two parties. We invite our old friends, Alice and Bob. We assume that these two people have a reason to exchange exchange funds on a regular basis. They all deposit funds into smart contracts on the base chain - in this example, let's say 5 ETH each. Alice signs a message to pay Bob 1 ETH, which means she updates her balance to 4 ETH and Bob's balance to 6 ETH. Alice sends the signed message to Bob, who signs the updated state and returns it. Afterwards, Bob pays Alice 0.5 ETH, reducing his balance to 5.5 ETH and increasing her balance to 4.5 ETH. He signs this payment message and sends it to Alice, who then signs the message and sends it back.

This process repeats for as long as Alice and Bob want. It is worth noting that micropayments are possible in this system. Since there are no fees until the channel is settled, sending 1000 payments of 0.001 ETH costs the same as sending one payment of 1 ETH.

Eventually, Alice and Bob's transaction came to an end. The final balance signed by both parties is that Alice has 7 ETH and Bob has 3 ETH. She submits this last co-signed state to the base chain, and the base chain first verifies that both parties are indeed signed with the private key, and then distributes to both parties according to the indicated balance. Simple and concise, right? Yes, but we left out some key details."the devil in the details"Like many things in the blockchain world, state channels work smoothly when all parties are behaving in the way they expect. But if parties always behaved the way they expect, we wouldn't need decentralized cryptocurrency networks in the first place! The whole reason blockchain exists is to allow parties to transact in a trust-minimized manner, and this Malicious behavior under dispute must be prevented.

For state channels, even in our simple two-party payment channel example, the consideration of these contentious factors adds a substantial amount of incidental complexity. Consider this scenario. If Bob pays Alice 2 ETH in return for a good or service, but when he receives the good, he uses an outdated state — one that was signed before his last payment — to close the on-chain channel. Both Alice and Bob signed this previous state, and the smart contract does not know that this state is previous. This will allow Bob to claim funds that Alice believes belong to her."To prevent this bad behavior, our system can require both users to have a special"finally

A state is signed which explicitly marks the channel as closed and funds are released only when such a state is committed. So what happens if a party refuses to sign on to such a final state, or simply disappears or goes offline for an extended period of time? Funds from both parties will be stuck in the smart contract.

to avoid this

sad reminder

As a result, parties need to be able to exit the channel and use the intermediate state to withdraw funds. When both parties do not explicitly close the channel, most final operations add a waiting period for funds to be paid. This gives each party the opportunity to dispute the withdrawal by presenting a newer state signed by both parties, thereby proving that the other party attempted to cheat. Such proofs are often accompanied by penalties for malicious actors.

It's a workable solution, but we can see how much complexity it has added. For a simple two-party payment channel, both parties must now constantly monitor the chain to ensure that the other party is not trying to cheat. They must maintain a cached copy of their latest state and be prepared to conduct on-chain transactions to prove that cheating has occurred. Additionally, users must be prepared to wait for the objection period to elapse before getting their funds back if the other party stops responding.

Multi-party payment

Now, here's the thing - state channels with only two-party payments are fairly limited in usability. How many financial transactions involve just repeated payments back and forth between two parties, and both parties are comfortable dedicating a large sum of their own money to the purpose of paying with the other party? Probably quite a few."To make state channels useful, we need to expand what they can do. We have two ways to do this. One is to increase the number of parties that can use the channel. The second is the ability to expand state channels, not just payment, but more general state types can be realized, thereby realizing more complex use cases."Let's look at the increase in parties first. The easiest way to do this is to have one big channel where all participants deposit into the same contract and sign all states. For obvious reasons, this approach doesn't work outside of a small number of users. What we need is not a single channel, but a network of channels.

Lightning Network: Payment Channel Network

To make payment channels really useful, Bitcoin's Lightning Network makes them routeable. Any user may open a channel with one or more nodes (anyone can operate). Then, payments are made between nodes

jump

, each node will transfer funds to the next node until it reaches the intended recipient. For such jumps, each node charges a small fee.https://medium.com/）。

As you can imagine, such a system comes with an explosion of complexity, and the Lightning Network took a long time to solve such difficulties. It still has a way to go, Lightning Network adoption hasn’t picked up over the past 12-18 months. To be honest, I'm not sure if the Lightning Network will gain mass adoption, but the technology that's been built is impressive nonetheless.

While the Lightning Network has made state channels more useful by enabling payments across participants, others have taken a different tack: restricting channels to a small set of parties but expanding their capabilities.

Add state to state channel

By including specific rules about what state transitions are allowed—rules that can be verified and enforced in on-chain smart contracts in the event of disputes—state channels can be used to build multi-party decentralized applications that achieve the same performance (link:

Imagine the kinds of applications that could be implemented with this kind of state channel, the most common example tends to be games. Imagine if Alice and Bob wanted to play a game of chess and put some money into it. Through a smart contract that encodes the rules of chess, and some basic data structures used to represent the state of the chessboard, Alice and Bob can place bets and play a game of chess off-chain by exchanging signed messages. When the game is over, the channel can be closed and the winning party gets his reward.

If either party tries to cheat, the other party can "mediate" through the smart contract. By presenting the most recent state, they can prove a valid game state and eventually close the channel. Under normal circumstances, though, the game will play out in the manner expected from any web-based board game. The only difference is that there are on-chain transactions to open and close channels at the start and end of the game.https://docs.ethhub.io/）。

The relative simplicity of state channels as a concept means that they are one of the first proposed and researched scaling solutions in the blockchain world. After years of research though, they still haven't been widely adopted in any meaningful way. What is the reason?"state channel"As I'm trying to impress you, the concept of a state channel is relatively simple, but the actual implementation involves a fair amount of complexity, especially when you're trying to build something that's actually useful. It turns out that it is quite difficult to deal with the many situations associated with malicious behavior, while also achieving what people really want. The fact that we haven't seen much adoption is possible because it's taken a long time to work out robust, usable solutions.https://blog.statechannels.org/）

I'm not giving up on state channels yet. First, the Lightning Network continues to mature, and more adoption may follow. In addition, in the Ethereum ecosystem, there are many teams developing generalized state channels, which will make it easier to build applications based on state channels (link: