State Channels: An Introduction to Off-chain Transactions
Software Engineer - 19 June 2020 -
Software Engineer - 19 June 2020 -
In recent years, Blockchain technology has become a running theme, although the worldwide acceptance of this technology is still inconclusive due to its scalability, anonymity, and transaction costs. In this article, I will make you understand how the issues mentioned above are restricting Blockchain adoption across everyday applications. Let us assume that Alice and Bob are playing a game of chess that is designed at the top of Blockchain technology. For making a move, a player obliges to pay the transaction fee and wait for the move confirmation on the Blockchain as the chess move requires state changes and state changes need to be committed on the Blockchain. Such confirmation time and validation fee inclusion make Blockchain technology inaccessible to tiny hands. Even if we omit the transaction fee issue, the `current Blockchain solutions are not scalable for decentralized applications (DApps). State channel addresses these concerns without significantly increasing the risk of any participant.
State channel is a technique designed to allow users to make multiple Blockchain transactions such as state changes or money transfers, without committing all of the transactions to the Blockchain. In the traditional state channel, only two transactions are added to the Blockchain, but an infinite or almost infinite number of transactions can be made between the participants. Example: In a Chess game built on top of state channels, the chess game beginning move and closing move should be committed on the Blockchain. All other moves can be made off-chain without the involvement of the Blockchain. These off-chain transactions do not require a fee with instant finality.
A Payment channel is one implementation of the state channels, which deals with money transfers. A state channel is a smart-contract that enforces predefined rules for off-chain transactions. Each transaction creates a new state based on the previous state, signed by each party, which is cryptographically provable on the blockchain. Every new state makes the last state invalid since the smart-contract acknowledges only the highest state as a valid state.
State channels don’t have a “direction” because they are a generalization and a more powerful version of payment channels. Consider a unidirectional channel as one whose state is simply one state value: “Alice’s payment to Bob”. Consider a bidirectional channel as one that has two state values: “Alice’s balance” and “Bob’s balance”.
In a state channel application, each party must sign an initial (opening) channel transaction, and deposit money according to application business logic. Users need to pay predefined transaction cost each time they either open a new channel or deposit money into the active channel. A deposit transaction deducts money from the depositor’s account and transfers it to the smart-contract address. This depositing mechanism will ensure that there will be no double-spent occur in on-chain or off-chain network. The smart-contract is not authorized to mint or destroy money, therefore in each valid state, all participants combined money equals total deposited money no more and no less. Figure (1) demonstrates a generic idea of the State Channels.
FIGURE(1):- STATE CHANNEL GENERIC SOLUTION
Let us re-consider the example cited above. Alice and Bob want to open one payment channel since they are playing a tic-tac-toe game, and after each game, they want to transfer money. Initially, they both signed the opening transaction and deposited 100 and 100 cash on the board. Alice and Bob are expected to pay transaction fees only at the time of channel opening, and now they can play the infinite number of game rounds without paying transaction fees with instant transaction finality. Assuming they decide to leave the game after the nth round, and the latest state was Alice 75 and Bob 125. Either Alice or Bob can send a channel closing transaction with the latest valid cryptographic state. It will take some time and transaction cost to validate this closing transaction, and the transaction, in turn, will send cash back to the respective wallet.
Participants pay validator fees at the time of opening and closing channels. All other transactions are free even though the number of transactions is hundreds or thousands.
On average, Bitcoin will take about 10 minutes to complete the transaction, and Ethereum will take 15 seconds to 5 minutes if you pay the regular gas price. That means if Alice made a move, the game would stop until the move is confirmed on the chain. On the contrary, payment channel transaction finality depends on the bandwidth of the network, more the bandwidth faster the finality.
All on-transactions are registered in the Blockchain ledger and are available in the public domain. Anyone can analyze these Blockchain data and get insights into the individual. On the contrary, state channel off-chain transactions are not committed in the Blockchain except for opening and closing transactions that give participants a considerable degree of privacy.
Off-chain transactions do not change the on-chain state, therefore the payment channel Apps are scalable. And if we can build a network of payment channels like the Raiden Network or the Lightning Network, then we don’t have to open a direct channel between the two parties if there is some indirect channel that leads to scalability.
Security of payment channel states depends on how the smart- contract validates the states, what information is included in the states such as (1) state nonce, (2) smart-contract address, (3) channel Id, (4) state and stakeholder status, etc. Each participant shall make a digital signature to validate the current state. The aim of including this information in the state is to make each state universally unique like UUIDS. The smart contracts address and channel id, together used to prevent cross-contract and in-contract replay attacks.
The Payment Channel will lock down the deposited money in the smart-contract and release it after the channel has closed. No one wants to lock up a massive amount of capital in a smart-contract that makes payment channels useful for micro-payments. Each state compels all participants to sign, which is why one offline participant can stop the processing of the payment channel.
I hope you found this article to be insightful and useful. To deep dive into some of our work around state channels, you can check out the GitHub repository.