The Ethereum Rollup Layer 2 scheme is very popular, do we still need state channels?
Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc)Editor's Note: This article comes from
Babbitt Information (ID: bitcoin8btc)
, Author: Tom Close, Compiler: Free and Easy, released with authorization.
Written in the front: Ethereum’s expansion solutions emerge in endlessly. Examples include state channels, Plasma, sharding, and the recently very popular zk-rollup and optimistic rollup, and solutions like Plasma have been sentenced to death before. It can be said that the current The Ethereum community is more inclined to choose rollup and zero-knowledge proof schemes, so what about the state channel scheme? In this article, Tom Close, head of the Magmo team of Consensys R&D Department, explained the complementary role of the state channel and the rollup scheme, and briefly mentioned some problems that the state channel scheme needs to solve.
(picture from: tuchong.com)
If you’ve been following the Ethereum ecosystem for a while, you’ve probably heard of the term state channels, you’ve probably read about their potential to improve blockchain scalability, and their ability to provide “instant finality” to transactions capabilities, but these are old news, and in an Ethereum world where rollup technology is prevalent, you might wonder where state channels are.
image description
Figure: Development activities on state channels
And today, we're going to explore state channels in the blockchain technology space and give a general summary of how they work, of course, these summaries may not be completely new to you, but it should serve you well Refresh your basic knowledge about the new state channel.
secondary title
What are the benefits of state channels?
State channels are often described as a scalability solution. Since state channels were first proposed, there has been a lot of progress on Layer 2 scaling (Layer 2 refers to solutions built on top of blockchains, so they don’t require any changes to the core protocol.)
The latest Layer 2 scaling solutions are zk-rollups and optimistic rollups, both of which involve periodically submitting batches of transaction data and resulting state roots to the blockchain, allowing for higher transaction throughput. Using the zk-rollups scheme, a zero-knowledge proof of the correctness of the overall state transition can be provided, thereby guaranteeing the validity of the on-chain state and allowing immediate withdrawal. Due to the complexity of generating proofs, the zk-rollup system is currently only used for simple asset conversions. Optimistic rollups, on the other hand, allow arbitrary EVM code execution in an off-chain setting, but require users to wait a challenge period before withdrawing their funds, and rely on parties challenging the incorrect state to maintain the integrity of the transition.
Both approaches are quite scalable, potentially achieving a transaction throughput of around 500 tx/s. (Translator's Note: This is an estimate put forward by Vitalik in the early days. After Ethereum completed the Istanbul hard fork, the theoretical tps of these two schemes increased to 2048. Assuming that Ethereum successfully shifted to the PoS scheme, these schemes The theoretical tps upper limit can be greatly improved)
State channels also help with scalability, and in some use cases state channels have the potential to achieve throughput that exceeds rollup schemes because it removes the need for the chain to process most transactions. They also have some unique properties, which make them suitable for some scenarios that are difficult to achieve with rollup schemes.
And one of the very important features is that it can realize the disintermediation of transactions: once the two parties have established a channel, they can exchange value without the participation of a third party. But in the rollup scheme, this is not the case, because all transactions must be processed by the rollup operator, and another important feature is the finality of the transfer. With state channels, the state is updated as the update is received, which means value transfers happen instantly.
For example, suppose you want to require users of the Infura API to pay a small amount of ETH for each API call. A typical user will touch your endpoint every 10 seconds or so, and you want to be able to charge them a penny and still give a sub-second response time. In this case, you don't have time to contact the rollup operator, and even if you did, the overhead cost of the rollup transaction would be too high, even if it were reduced to 100 gas (currently about 0.02 cents).
In the above cases, you may think of the state channel solution.
Well, having said all that, we haven't even mentioned the "state" part of a state channel. In most cases, the above example will require the use of payment channels (a specialized state channel), where the state is simply the balance of each participant. The state exchanged off-chain can be more general than this, allowing state channels to provide more complex interactions between users. In the state channel, including atomic swaps, arbitrarily complex conditional payments, and even chess games can be completed. This gives system designers a lot of flexibility when designing incentive schemes.
Altogether, state channels occupy a unique region of the trade-off space, whose properties are of great importance in a wide range of applications. In the remainder of this article, we will provide an overview of how state channels operate to better understand how they achieve the above properties.
secondary title
How do state channels work?
So what is a state channel? We will answer this question with a typical state channel interaction:
The scalability benefits of this setup come from the fact that during the second phase, when Alice and Bob exchange signed agreements, they can do a lot without interacting with the blockchain" transactions” limited only by how quickly they can sign and exchange messages.
You might be wondering what a "transaction" really means in this case, since the funds are not actually moving on-chain.
Although the funds held in the state channel contract have not changed, the claim rights have changed, and when Bob receives the latest message from Alice, he knows that his current share of claimable funds has changed. This is also the meaning of "immediate finality" in transactions.
secondary title
So do we need to constantly monitor the blockchain?
So far, we've only discussed co-op scenarios where everything goes well. But in a system like a state channel, one thing you should worry about is counterparty risk: if you open a state channel with Charlie and deposit funds into the state channel contract, then when Charlie becomes cooperation, or what happens to the funds in the channel when he loses his private key? Can you get your funds back? Or could Charlie use this to blackmail you and force you to pay him shares to free up the funds? The answer to these questions is another important component of the state channel system: the challenge mechanism.
In a sense, there is a simple answer to these questions: if Charlie is unresponsive, you just close the channel by sending the latest agreement on-chain, as in the cooperation case above. However, the problem with this is that the blockchain cannot tell whether the protocol result you sent is actually the last one, which means that there is a possibility that you can do evil through it. So how to solve this problem? There are two solutions:
The second approach is to have the blockchain enforce a challenge period after the supposed last state commit and give other participants a chance to commit a state before withdrawing funds. If someone submits a challenge maliciously, they will be penalized, thereby incentivizing good behavior.
What's next?
Well, does this mean that state channel participants need to constantly monitor the blockchain in order to detect instances of malicious challenges and then respond? In fact, this requirement is not as bad as it seems, participants do not have to constantly monitor, they only need to check the blockchain a few times per challenge period. The burden here can be mitigated by choosing the challenge period carefully, ensuring that any channel that is expected to run for a long time has a long challenge period. It is also possible to add functionality to the state channel system to allow participants to pre-emptively submit the latest state to the chain to ensure that they are not challenged while they are offline.
Stay tuned!
