Do we still need state channels?

If you’ve been following the Ethereum ecosystem for a while, you’ve probably already heard of state channels. You probably have already heard about their potential to improve the scalability of the blockchain, as well as their ability to provide “instant finality” for transactions. This is all old news, and you might be wondering where state channels are at, and whether they’re even still relevant in a world of rollups.

In this series of blog posts, we’ll be bringing you up to date with state channels in 2020. Starting from scratch, we’ll be explaining the important concepts, and the latest designs. We’ll also be sharing the work we’ve been doing since announcing the state channels collaboration last year: building a set of tools that will allow projects to add state channels to their blockchain tech stack. As part of this we’ll release a couple of projects that demonstrate the capabilities of state channels, and give an insight into the state channel user experience.

Today, we’ll be looking into the space state channels occupy in the landscape of blockchain techniques, and give a high-level summary of how they work. There’s a good chance the summary won’t be completely new to you, but it should serve as a good refresher of the baseline knowledge required for the rest of the series.

What are state channels good for?

State channels are often described as a scaling solution. Since state channels were first proposed, there’s been a lot of progress on Layer 2 scaling. (Where “Layer 2” means solutions that are built on top of the blockchain, and therefore don’t require any changes to the core protocol.)

Two of the latest Layer 2 scaling solutions are zk-rollups and optimistic rollups. Both of these approaches involve periodically submitting batched transaction data and a resulting state root to the chain, allowing a much higher transaction throughput. With zk-rollups, a zk-proof of correctness of the overall state transition is provided, which guarantees that the on-chain state is valid, allowing for immediate withdrawals. Due to the complexity of generating the proofs, zk-rollup systems are currently limited to simple transfers. Optimistic rollups allow for the execution of arbitrary EVM code, within the off-chain setting, but require users to wait a challenge period before withdrawing their funds, and rely on parties challenging incorrect states to maintain the integrity of the transitions.

The scaling properties of both these approaches are appreciable, potentially allowing the main chain to achieve a transaction throughput of around 500tx/s.

State channels also help with scalability, with the potential to match and even exceed the throughput that rollups are capable of, for certain use-cases - primarily by removing the need for the majority of transactions to be processed by the chain at all. They also have some unique properties, which make them suitable in cases where a rollup-based solution would struggle.

One of these properties is the ability to disintermediate transactions: once two parties have established a channel, they can exchange value without needing to involve a third party. This isn’t true in rollup schemes, as all transactions have to be processed by a rollup operator. Another important characteristic is the finality of the transfer. With a state channel, the state is updated the moment an update is received, meaning that value transfer happens instantly.

Imagine, for example, that you want to require a user of the Infura API to pay a small amount of ETH per API call. A typical user is going to hit your endpoint every 10 seconds or so, and you want to be able to charge them a fraction of a cent, and still give a sub-second response time. In this scenario, you don’t have time to reach out to a rollup operator, and even if you did, the rollup transaction overhead cost is going to be too high, even if it’s as low as 100 gas (which is currently around 0.02 cents).

Alternatively, imagine that you wanted to build a decentralized ISP, by allowing users to buy bandwidth from their neighbours, paying for each MB as they consume it. Or if you wanted to give content creators an alternative to ad revenues, by enabling decentralized pay-as-you-stream or pay-as-you-read models. Or if you wanted to build a network of IoT devices that could accept payments as they collect and provide data. Or if you wanted to enable payments to state providers, to incentivize them to provide the data required to support a stateless ETH1.x chain… In all of these cases, you would probably want to reach for a state channel.

Something we haven’t mentioned so far is the ‘state’ part of state channels. For the most part, the examples above require payment channels - a specialized state channel, where the state is just the balance of each participant. The state exchanged off-chain can be more general than this, allowing state channels to offer more complex interactions between their users. Atomic swaps, payments with arbitrarily complex conditions, and even games of chess are all possible within state channels. This gives system designers a lot of flexibility to play with when desigining incentivization schemes.

In summary, state channels occupy a unique area of the tradeoff space, whose characteristics are important in a wide range of applications. In the rest of this article, we’ll give an overview of how state channels operate, to better understand how they achieve the characteristics claimed above.

How do state channels work?

So, what is a state channel? We’ll start to answer this question by looking at a typical state channel interaction:

The interaction starts with two participants, Alice and Bob, depositing some funds into a state channel contract on the blockchain. They then exchange agreements about how the funds should be split between them. These agreements could be simple balance updates, or could be more complicated objects, for example containing the state of a game of chess, whose outcome will be used to split the funds. The participants add their signature to the state before sending to their counterparty. Finally, the last agreement is sent to the state channel contract, which pays the funds out accordingly.

The scalability benefits from this setup come from the fact that in the second stage, when Alice and Bob are exchanging signed agreements, they can do many ‘transactions’ without interacting with the blockchain, limited only by the speed at which they can sign and exchange messages.

You might be wondering what ‘transaction’ really mean in this case, given that the funds on-chain haven’t moved. Although there’s been no change to the funds held in the state channel contract, there has been a change to right to claim them; the moment that Bob receives an update from Alice, he knows that his share of the funds he can currently claim has changed: he might not have those funds in his account now, but he has the ability to move them there at a time of his choosing. This is also the sense in which transactions have “instant finality” - its the rights over the funds that are transferred instantly.

But don’t you have to constantly monitor the chain?

So far we’ve only covered the cooperative case, where everything goes right. One thing you should be concerned about in a system like this is counterparty risk: if you open a state channel with Charlie, and deposit your funds into the state channel contract, what happens to those funds if Charlie becomes uncooperative, or loses his private key? Can you get those funds back? Can Charlie hold your funds for ransom, forcing you to pay him a share in order to release them? The answers to these questions are another important part of state channel systems: the challenge mechanism.

In some sense, there’s an easy answer to these questions: if Charlie becomes unresponsive, you just close the channel, by sending the latest agreement to the chain, just as in the cooperative case described above. The problem with this though is that the chain has no way of telling whether the agreement you sent was actually the last one or not - you could be trying to cheat the system by sending in an earlier state that was more favourable to you. There are two ways around this problem.

The first way, which works in the cooperative case, is for all participants to explicitly sign a statement saying that the agreement in question is final, and that the channel is now closed. This is neat in that it allows for instant withdrawals, but won’t help us in the case where one or more participants are unresponsive.

The second way is for the chain to enforce a challenge period after the supposed last state is submitted and to give other participants the chance to submit a later state before the funds are withdrawn. It’s possible to incentivize good behaviour by penalizing participants who can be shown to have submitted a state that wasn’t the latest they had.

A good channel framework will combine both these approaches, allowing instant withdrawals in the cooperative case, while still providing a path for withdrawing funds in the non-cooperative case.

It might seem like this means that state channel participants need to constantly monitor the chain, in order to detect malicious challenges, so that they can respond within the challenge period. In fact this requirement isn’t as bad as it seems; participants don’t have to be monitoring constantly - they just need to check the chain a couple of times each challenge period. The burden here can be lessened through careful choice of the challenge period, ensuring that any channels that are expected to be long-running have long challenge periods. It’s 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 they can’t be challenged during a period when they’re offline.

What’s next?

In the rest of this series of articles, we’ll dig deep into a range of state channel topics, aiming to give you a complete understanding of how they work, and what they can be used for. We’ll also demonstrate and release some tools for working with state channels, which you can start to experiment with yourselves.

Stay tuned!

Written by Tom Close, Magmo team lead @ Consensys R&D