Entrepreneur | Co-founder @tbc_inc, an MIT CIC incubated startup | Speaker |https://vaibhavsaini.com
State Channels and Sidechains are the two terms in Ethereum community that are often used interchangeably, thus causing mass confusion.
But today we will get it clear.
Go make a cup of coffee first, it’s going to be a long one.
The purpose of this article is to clearly define:
Then we will compare the two:
Without wasting much time, let’s get started.
State channels are a very broad and simple way to think about blockchain interactions which could occur on the blockchain, but instead get conducted off of the blockchain, without significantly increasing the risk of any participant. The most well known example of this strategy is the idea of payment channels in Bitcoin, which allow for instant fee-less payments to be sent directly between two parties. Here is a list of some of the State Channel Projects.
State channels are the general form of payment channels, applying the same idea to any kind of state-altering operation normally performed on a blockchain.
Moving these interactions off of the chain without requiring any additional trust can lead to significant improvements in cost and speed. State channels will be a critical part of scaling blockchain technologies to support higher levels of use.
The basic components of a state channel are very simple:
That’s it! If the “state” being updated between participants was a digital currency balance, then we would have a payment channel. Steps 1 and 3, which open and close the channel, involve blockchain operations. But in step 2 an unlimited number of updates can be rapidly made without the need to involve the blockchain at all — and this is where the power of state channels comes into play, because only steps 1 and 3 need to be published to the network, pay fees, or wait for confirmations. In fact, with careful planning and design, state channels can remain open almost indefinitely, and be used as part of larger hub and spoke systems to power an entire economy or ecosystem.
Despite my simple description here, state/payment channels have generally been perceived as quite complicated. There are several reasons for this, and one of them is that there are some important subtleties hidden in my phrasing of the three steps. Let’s take a closer look at what these simple phrases imply, starting with:
could be submitted to the blockchain
In order for state channels to work, participants have to be assured that they could publish the current state of the channel to the blockchain at any time. This results in some important limitations, such as the fact that someone has to stay online to protect each individual party’s interests until the channel is closed.
Imagine that when we initiated a payment channel I started with 100 bitcoins and you started with 10. If we first sign an update that transfers 10 of those bitcoins to me, and then later sign an update that transfers 50 back to you, the later update is obviously more beneficial to you than the earlier one is. If you were to unexpectedly lose internet access, and I were to pretend the second update never happened, I might be able to publish the first update to the blockchain and effectively steal 50 bitcoins from you! What you need is somebody to stay online with a copy of that later transaction so that they can “trump” the earlier one and make sure your bitcoins are protected. It doesn’t have to be you — you could send a copy to many random servers who agree via smart contract to publish it only if needed (for a small fee of course). But however you do it, you need to be assured that the latest signed update to the state is available to trump all others. Which leads us to our next subtle phrase:
Each new update “trumps” previous updates
To make this part of the state channel work, the locking and unlocking mechanisms have to be properly designed so that old state updates submitted to the blockchain have a chance to be corrected by the newer state updates which replaced them. The simplest way is to have any unlocking attempt start a timer, during which any newer update can replace the old update (restarting the timer as well). When the timer completes, the channel is closed and the state adjusted to reflect the last update received. The length of the timer would be chosen for each state channel, balancing the inconvenience of a long channel closing time with the increased safety it would provide against internet connection or blockchain problems. Alternatively, you could structure the channel with a financial penalty so that anyone publishing an inaccurate update to the blockchain will lose more than they could gain by pretending later transactions didn’t happen.
But the mechanism ends up not mattering very much, because (going back to the previous point) the game theory of this situation puts a twist on things. As long as this mechanism is theoretically sound, it will probably never have to be used. Actually going through the timer/penalty process may introduce extra fees, delays, or other inconveniences; given that forcing someone into the mechanism can’t give you any advantage anyways, parties to a state channel will probably just close the channel out by mutually agreeing on a final channel state. This final close-out operation needs to be fundamentally different from the normal “intermediate” updates (since it will bypass the “trumping” mechanism above), so participants will only sign a final close-out transaction once for each portion of the state locked within a particular channel.
The details of these “subtleties” aren’t especially important. What it all ultimately breaks down to is that participants open the channel by setting up a “judge” smart contract, sign promises to each other which the judge can enforce and adjudicate if necessary, and then close the channel by agreeing amongst themselves so that the judge’s adjudication isn’t needed. As long as the “judge” mechanism can be assumed to be reliable, these promises can be counted as instant transfers, with the judge only appealed to in exceptional circumstances, such as when one party disappears.
Of course, these details are only part of the reason people think that state/payment channels are complicated. A much bigger one is that Bitcoin payment channels are complicated. Building a “judge” mechanism in Bitcoin with even reasonably useful properties is surprisingly intricate. But once you have a clear concept of state channels in general, you can see that this only comes from trying to implement the idea in a constrained context. Basic smart contract features like a timer mechanism and allowing two different paths to be taken depending on the signed message submitted are just plain harder to do in Bitcoin. Some of these features are being gradually added or built. By seeing that payment channels are only a special subcase of the broader “state channel” idea, we realise that this is a much broader technique, and that state channels can apply to any smart contract which deals with frequent updates between a defined set of participants. You can anticipate seeing this approach in many (if not most) distributed applications going forward.
Now we have a bit clear idea that what is a “state channel”. So, let’s move to side chain.
A sidechain is a separate blockchain that is attached to its parent blockchain(mainchain) using a two-way peg.
In other words, you can move assets to the sidechain and then back to the parent chain.
The two-way peg enables interchangeability of assets at a predetermined rate between the parent blockchain and the sidechain. The original blockchain is usually referred to as the ‘main chain’ and all additional blockchains are referred to as ‘sidechains’. The blockchain platform Ardor refers to its sidechains as ‘childchains’.
A user on the parent chain first has to send their coins to an output address, where the coins become locked so the user is unable to spend them elsewhere. Once the transaction has been completed, a confirmation is communicated across the chains followed by a waiting period for extra security. After the waiting period, the equivalent number of coins is released on the sidechain, allowing the user to access and spend them there. The reverse happens when moving back from a sidechain to the main chain.
A federation is a group that serves as an intermediate point between a main chain and one of its sidechains. This group determines when the coins a user has used are locked up and released. The creators of the sidechain can choose the members of the federation. A problem with the federation structure is that it adds another layer between the main chain and the sidechain.
Sidechains are responsible for their own security. If there isn’t enough mining power to secure a sidechain, it could be hacked. Since each sidechain is independent, if it is hacked or compromised, the damage will be contained within that chain and won’t affect the main chain. Conversely, should the main chain become compromised, the sidechain can still operate, but the peg will lose most of its value.
Sidechains need their own miners. These miners can be incentivized through ‘merged mining’, whereby two separate cryptocurrencies, based on the same algorithm, are mined simultaneously.
Here is a list of some of the Sidechain Projects.
Now, we have a good understanding of sidechains too. So, let’s put them to the ring.
Both Sidechain and State Channel are tricks to improve the poor scalability of blockchains in general.
They both follow a bit same model.
But despite this analogy, there are many differences between the two which arises from the point that in State Channels we do not use a separate blockchain whereas in Sidechains we use a separate blockchain. Let’s see what are its consequences.
To decide this, let’s see their pros and cons.
The fight between the two was great. The dust has settled, but both are still standing. As the research is still going on and the practical use is not widespread we can’t decide who will be the winner. Maybe they will have to merge to form a hybrid solution to serve the purpose of scaling. Till then we have to wait, to see what time has to show us.
Thanks to Jeff Coleman for the wonderful explanation of state channels.
Thanks for reading;)
About the Author
He works as Senior blockchain developer and has worked on several blockchain platforms including Ethereum, Quorum, EOS, Nano, Hashgraph, IOTA.
He is currently a sophomore at IIT Delhi.
Hold down the clap button if you liked the content! It helps me gain exposure .
Want to learn more? Checkout my previous articles.