State channels aim to reduce transaction costs by avoiding the necessity of recording each transaction individually on the blockchain. Channel participants can conduct any number of transactions off-chain while storing only the necessary events on the blockchain (or on-chain). This helps to increase the number of transactions while lowering the expense. Consider a blockchain-based Chess game where every move is stored on-chain, though it will have a finite number of moves before the game ends storing all those moves on the blockchain is pointless! We just need the initial state and final state of the game to decide the result of the match. Also, storing every move by the user on the blockchain will be time-consuming (as transacting on the blockchain takes time) as well as expensive (because storing anything on-chain requires you to pay gas fees). That's where state channels come into the picture.
Why do we need State Channels?
Public Blockchains like Ethereum and Bitcoin are slow, as every transaction must be executed by all participating nodes. Since the computational powers are limited and every node has to handle several transactions to mine a single block, there is a limit to transaction throughput. Channels solve this problem by allowing users to transact off-chain while still maintaining the security of on-chain. State Channel is the first Layer 2 (solutions which are built on top of the blockchain, and therefore don’t require changes to the core protocol) Scaling Solution. Although there are other layer-2 Scaling Solutions like zk-rollups and optimistic rollups which can provide better transaction throughput (around 500 transactions/second) why do we need state channels? Well, state channels have the potential to match or even increase the throughput that rollups are capable of, for certain use cases.
Consider yourself as an API service provider like Alchemy or Infura. Now, if a user purchases your service and makes a request every few seconds and you want to charge them as low as possible while maintaining a minimal response time, you won't go to rollups as not only their response time would be relatively more but also the transaction cost will be higher! Imagine another scenario where you built a Decentralized ISP (Internet Service Provider), that allows users to buy bandwidth from their neighbours, paying for each MB as they consume it. All these scenarios require state channels as rollups won't be efficient here! They are very useful in situations where participants wish to transact in high frequency.
What are Channels and their types?
Channels are basically, peer-to-peer protocols that allow the participants to make any number of transactions and post the final results on the blockchain. A multi-sig smart contract ensures the transactions are signed by both the intermediate parties. To open a channel, peers deploy a multi-sig contract on-chain and add funds into it, both peers sign and exchange the agreements about how the funds should be distributed between them, after which they can transact off-chain. An update to the channel's state requires the signature of both participants. To close the channel, participants submit the last agreed state and the contract pays out the funds accordingly.
Blockchain Channels are of 2 types: Payment Channels and State Channels
Payment Channels
It is basically a two-way ledger maintained by the participants. This idea was one of the earliest scaling solutions and was introduced in the Bitcoin Lightning Network. It works the same way as specified above and participants can conduct an arbitrary number of instant transactions as long as the sum of their transfers doesn't exceed the deposited amount. It has applications in Atomic swaps and micropayments.
State Channels
Apart from supporting off-chain payments, Payment Channels aren't of much use and to eliminate this flaw, state channels were introduced. They provide all the benefits of Payment Channels along with the ability to store the contract's (state) variables. State Channels also work similarly as described earlier. Every update in a state channel consists of:
- nonce: acts as a unique ID for transactions and prevents replay attacks, also helps to identify the order of transactions
- channel's old state
- channel's new state
- change of state variable
state updates are not broadcasted on-chain unless the participants agree on the final state. Details referenced in the state update include the number of each participant's moves and a list of approved transactions.
Now, in a non-disputed scenario both the users will agree to state changes and finalize the channel but that's not true with all of the cases the chances of dispute are there and in that case, these are the possible situations:
- Participants go offline and fail to propose state transitions
- Participants refuse to co-sign valid state updates
- Participants try to finalize the channel by proposing an old state update to the on-chain contract
- Participants propose invalid state transitions for others to sign
Settling Disputes:
one participant can submit an on-chain request to end the channel without waiting for another one's approval. If any of the earlier described disputes occur, either party can trigger an on-chain request to close and distribute the channel's funds. To process the exit, the participant must submit the application's last valid state update to the on-chain contract. If this bears the signature of all parties, then funds are redistributed in their favour. There is a delay in executing single-user exit requests due to the possibility of fraudulent action which gives the other user time to challenge the exit transaction. But if the exit request is unanimously signed, it is executed immediately. So this is pretty good, right? But there are further advancements in this scaling solution which has led to the introduction of virtual channels.
Problems With State Channel:
- Generally, the number of participants remains fixed in a state channel because updating users will create more complex operations like redistribution of user's funds if a new user onboards or complexity in settling disputes and many other issues might arise.
- Users update the state channels in turns, i.e. before submitting another transaction you wait for other users for their state update and this process is a bit slow, which might hurt the User Experience.
- Griefing Attacks: These type of attacks do not benefit the attacker directly, but causes harm to the victim. So, an attacker might try to repeatedly post irrelevant transactions on-chain, forcing the victim to respond with a valid state.
- Establishing a channel requires locking funds in a contract over some time, thereby making your funds illiquid during that span.
Okay, I get it there are a lot of problems with state channels so, why do we use them? So to answer this let's move on to:
Use cases of State Channel:
- They help to achieve better transaction throughput (transactions/second) and incur less expense than interacting with the mainnet.
- Since the transaction happens off-chain, there is no trace of your funds, thereby increasing the privacy of your transactions.
- They are the most suitable solutions for micropayments (better efficiency than roll-ups in this particular case).
Virtual Channels
Now deploying a smart contract and creating a channel, requires some ETH to start with and it can get more expensive if the network is congested (as more transaction fees), so to solve that problem virtual channels were introduced. No on-chain interactions are needed to establish this channel. This technique relies on the "ledger channels" that were already created and a virtual channel can be built on top of it and participants can connect to an intermediary (owner/s of the virtual channel). The intermediary is not aware of what application is run in the private channel. A virtual channel can be opened, executed, and finalized off-chain. Users in each virtual channel can interact via a new contract instance, as the ledger channel can support multiple contract instances.
Projects implementing state channels:
To learn more about state channels:
Read more from Etherworld:
_________________________________________________________
Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.
For Press Releases, project updates, and guest posts publishing with us, email to contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Share if you like the content. Donate at avarch.eth or Gitcoin
If you've something to share with the blockchain community, join us on Discord!