This is Part 1 of a three-part blog series by Celer Network and L4 about state channels. In Part 1, we give a high level overview of state channels and introduce the readers to the basic concepts. In Parts 2 and 3, we will cover how developers can use state channels in their applications, and then examine state channel architecture in more detail.
What are state channels?
State channels are a technology that lets us radically improve the UX and scalability of applications built on blockchains like Ethereum.
If you’ve heard of payment channels on Bitcoin (e.g. the lightning network), state channels are similar. In fact, state channels are just a more general application of the same underlying technique. In a payment channel, we track the state of payments between parties. In a state channel, we track the state of any arbitrary program between parties — which could include payments. Payment channels are just one application of state channels. Just as Ethereum expanded on what Bitcoin made possible, state channel implementations like Celer and Counterfactual expand on the original payment channel idea.
How do state channels work, and why are they useful?
The core value of state channels is simple: for certain types of applications, channels are always cheaper, faster, and more private than a regular on-chain transaction.
Blockchain operations are expensive (we have to pay transaction fees) and they are slow (we have to wait for new blocks). Even on ETH 2.0, transactions will still require waiting for the next block, and fees will still need to be paid.
State channels let us do operations off chain, where they can be near-instantaneous and free. This means that users in a game can get instant feedback, or parties can exchange many thousands of payments or trades, with no limit to their speed except their underlying communications protocol.
In the simplest case, imagine Alice and Bob want to exchange payments through a state channel. First, Alice and Bob agree to “lock” some of their funds into a smart-contract. This smart-contract requires both Alice and Bob’s consent to do anything with the locked funds. Then, Alice and Bob simply exchange messages over the internet that represent mutual commitments to make a payment, like “Alice and Bob agree that the balance of this channel is now Alice = 8 ETH, Bob = 2 ETH”.
At any time, either of Alice or Bob could “enforce” the most recent commitments. When they are finished, they report that commitment to the smart-contract, which pays out according to the final balance.
Importantly, Alice and Bob can do this without introducing any trusted third parties. There’s no centralized operator or new person who has control over your assets while you interact through a state channel. A critical feature of state channels is that even if the off-chain mechanism fails, the user is able to restore their state on the original blockchain.
An often overlooked benefit of state channels is that they have strong privacy properties. All of the actual transactions happen privately, only visible to the parties in the channel. For instance, Alice could send Bob a conditional payment in a state channel where no-one except Alice and Bob has to know the condition. When the conditional payment resolves, it will look like a normal payment and fund transfer from the outside world even when Alice “disconnects” from the state channel network.
Let’s dig deeper
Let’s take a step back and think about why we’re doing this in the first place.
On Ethereum we pay gas to miners because we want miners to include our proposed state-transition (our transaction) into the blockchain. We have to wait because it takes time for all of Ethereum’s nodes to agree and verify that state transition. Here, we’re in a byzantine fault-tolerant trust model: individual users don’t trust the miners, miners don’t trust the user, and miners don’t even trust each other. In order to remain secure, the Ethereum protocol needs to assume an always-hostile environment even while updating state as often as possible.
Fundamentally, state channels are about allowing users to opt-in to cooperative environments where state updates can happen much faster and cheaper. Using smart contracts and simple game theory, we can create environments where users are incentive-aligned to cooperatively progress the state of an application. In the best case, the users gain cheap, instant, private interactions. If the off-chain mechanism breaks down, they simply revert back to using the Layer 1 blockchain.
A critical thing to understand is that state channels require unanimous consent to update. In a channel with Alice and Bob, each of them (or more accurately, their software) must agree to each update in the channel. Because this doesn’t require any fees, and it doesn’t require waiting for any blocks, channel updates are cheap and fast. Alice and Bob only have to wait for each other to sign updates, and each of them have an incentive to sign updates. If Bob were to not sign an update, he doesn’t gain anything: Alice can still take her valid update “on-chain” and have it enforced.
State Channels in Practice
The explanations above focused on individual state channels. But in reality, most users will experience channels through state channel networks. A state channel network is where many individual state channels are connected, such that it becomes possible to route state changes through them. For instance, Alice and Bob might not have channels open with each other, but want to play a game. As long as both have channels open with Ingrid, however, they can open what is called a “virtual channel” that routes interactions through each of their already-existing channels with Ingrid.
Once users have a channel open that connects them to a state channel network, interacting with channels becomes an easy, default experience. Users can install, use, and uninstall applications instantly with zero transaction fees.
What kind of applications are most suitable for state channels? While we’re only beginning to explore the full design space, there are a few criteria that can indicate whether an app is a good candidate:
- When a specific session involves a relatively small number of participants. While an application that uses state channels can have any number of users, an “interactive session” within that application — the period when users are interacting with each other to modify whatever “state” is held by the channel — will be most effective with a smaller number of users.
- When there will be a very large number of transactions or interactions between users. If your application only requires a handful of transactions, then setting up a channel might not save your users much trouble. But if your users will make hundreds or thousands of state updates, channels offer tremendous gains.
- When your application requires snappy, fast UX. Interactions through state channels can happen as fast as the underlying communication protocol allows. If your application could benefit from instant feedback for your users, you should 100% use state channel.
- Where you don’t have to change the set of participants too often. If a user is not already part of a state channel network, then adding them to a channel requires at least one on-chain operation, requiring fees and waiting for a block. However, users that are already part of a channel network can join or leave “virtual channels” for free.
That’s it for Part 1! Stay tuned for Part 2, where we will look more in-depth at how developers can use state channels in many different kinds of applications.
Interested in learning more? Check out our github repo for open source code: https://github.com/celer-network Wanna try it out? Here is our development doc: https://celer-network.github.io/docs/guide 🎉🎉
Curious about how the layer-2 application platform works? Download CelerX,the FIRST AND ONLY layer-2 application platform on iOS and Android. Find new fun Apps in the decentralized world. 🙌🙌
Don’t want to miss the updates? Sign up the newsletter below! 👇👇