A complete comparison of the two scaling methods

June 2018

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:

What are State channels ?
What are Sidechains ?

Then we will compare the two:

What problems are they trying to solve ?
Which is a better scaling solution among the two ?

Without wasting much time, let’s get started.

What are State Channels ?

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:

Part of the blockchain state is locked via multisignature or some sort of smart contract, so that a specific set of participants must completely agree with each other to update it.
Participants update the state amongst themselves by constructing and signing transactions that could be submitted to the blockchain, but instead are merely held onto for now. Each new update “trumps” previous updates.
Finally, participants submit the state back to the blockchain, which closes the state channel and unlocks the state again (usually in a different configuration than it started with).

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.

What are SideChains ?

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.

Federations

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.

What problems are they trying to solve ?

Both Sidechain and State Channel are tricks to improve the poor scalability of blockchains in general.

They both follow a bit same model.

Locking up state/assets.
Doing transactions off the blockhain/mainchain.
Unlocking the state/assets from the state channel/sidechain.

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.

Which is a better scaling solution among the two ?

To decide this, let’s see their pros and cons.

State Channel pros

State channels have strong privacy properties: This is because everything is happening “inside” a channel between participants, rather than broadcast publicly and recorded on-chain. Only the opening and closing transactions must be public. Whereas in sidechains every transaction is published on the sidechain which is received by every participant on the sidechain irrespective of the fact that you are not interacting with all of the participants on the sidechain.
State channels have instant finality, meaning that as soon as both parties sign a state update, it can be considered final. Both parties have a very high guarantee that, if necessary, they can “enforce” that state on-chain. But as discussed above that the state channel closing could take variable time considering the security level of the transaction. Whereas in sidechains you have a blockchain on the other side. So the finality depends on the mining power of the sidechain.

State Channel cons

State Channels need 100% availability of all the participants involved: As we have discussed above that if anyone the participants goes unavailable, then this could prove costly to him. The participants can use someone to represent him if he goes unavailable, but the possibility of the representative getting attacked or bribed makes it a problem for state channel. Whereas in sidechains you don’t have to be available all the time you are on the sidechain.
State channels are best used for applications with a defined set of participants: This is because the Judge contract(the contract used to lock the state) must always know the participants/entities (i.e. addresses) that are part of a given channel. We can add and remove people, but it requires a change to the contract each time. Whereas in sidechains there is no such limitation on the movement of the participants.
State Channels are particularly useful where participants are going to be exchanging many state updates over a long period of time: This is because there is an initial cost to creating a channel in deploying the Judge contract. But once it is deployed, the cost per state update inside that channel is extremely low.

Sidechain pros

Sidechains are permanent. You don’t have create your own sidechain for specific purpose if there is one present: Sidechains are created and maintained once made. We don’t close sidechains, rather we lock the assets on sidechain to move back to the mainchain. This can be helpful in the way that anyone who is doing a specific task off blockchain/mainchain (for eg. transacting in dogecoin) will come to the same sidechain. So, you don’t have to create separate chains for every new participant. Whereas in state channels you usually have to create a new channel to add a new participant. But projects such as Lightning , Raiden network have come up with brilliant solution for this. They create a mesh of participants so you don’t have to create a new channel for every new participant you interact with. You can interact with participants indirectly creating a channel between you and recipient through some other participant who is common to both: you and the recipient.
Sidechains allow cryptocurrencies to interact with one another: They add flexibility and allow developers to experiment with Beta releases of Altcoins or software updates before pushing them on to the main chain. Traditional banking functions like issuing and tracking ownership of shares can be tested on sidechains before moving them onto main chains.

Sidechain cons

Sidechains need a lot of initial investment to start off: To create a sidechain we need to have enough miners so that the network is safe from attackers. Also, we have to make it sure that they are up and running. Whereas there is no blockchain involved in state channels. So, no such requirement is needed.
A Federation is needed for sidechains: This adds another layer between the mainchain and the sidechain. This could prove as another weak point for the attackers to attack by bribing or attacking the federation. Whereas in state channel we just need a smart contract to do this for us.

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.

from: https://hackernoon.com/difference-between-sidechains-and-state-channels-2f5dfbd10707

***

Counterfactual: Generalized State Channels on Ethereum

*a typical state-channel, composed of counterfactually instantiated objects.*

June 2018

At L4 we have been working on state channels and other blockchain scalability research. Today we’re excited to share one of the foundational pieces of our work: Counterfactual: Generalized State Channels (pdf).

State channels are the foundational technology for useable distributed applications. They can be used in any interaction with a defined set of participants, such as payments or games like chess or poker. “Channelizing” these applications makes them radically cheaper, and reduces the unacceptably high latency in today’s blockchain applications, enabling the web-like response times expected by users.

Despite this, state channels are underutilized in today’s ethereum applications. Each project that wants to use state channels must effectively build their own custom implementation, leading to redundancies and unnecessary risks. Second, existing state channel implementations still put too many operations on-chain, and compromise privacy in unnecessary ways.

We envision a better future. Earlier, we described two broad goals:

Design a generalized state channels implementation that preserves privacy, is built using modular components, has support for multiple parallel operations inside a single channel, and allows users to upgrade channel designs without any on-chain operations.
Make it easy for developers to utilize state channels by providing a framework and standard modular components for building secure, performant applications.

Our paper (pdf, local copy) describes a state channels design that places as little on-chain as possible while still remaining secure. We believe it will become a standard reference for building secure and optimized state channels, something long-needed by the ethereum community.

We will be attending Off the Chain in Berlin where we will discuss our technique in more depth. Needless to say, we’re not doing an ICO or any other fundraising event involving a token.

In this blog post, we summarize the approach described in our paper. If you’re interested in a conceptual description of how state channels work, take a look at the state channels section of Josh Stark’s Layer 2 scaling article. The rest of this blog post assumes the reader has some familiarity with the basic technique.

State channels terminology

The basic technique behind state channels has been known for several years. Since then, we have found new vocabulary that lets us abstract over particular implementations and discuss components and techniques that appear in all state channels.

State channels work by “locking up” some portion of blockchain state into a multisig contract, controlled by a defined set of participants. The state that is “locked up” is called a state deposit. For instance, this might be an amount of ether or an ERC20 token, but could also be a cryptokitty or an ENS domain name.

After the state deposit is locked, channel participants use off-chain messaging to exchange and sign valid ethereum transactions without deploying them to chain. These are transactions that could be put on chain anytime, but are not.

Updating the state of the channel always proceeds by unanimous consent. All parties sign (and keep their own copies of) each off-chain transaction. Because these “state updates” are taking place entirely off chain, they have zero transaction fees, and their speed is limited only by their underlying communications protocol.

For this reason, state channels offer “instant” transactions — i.e., parties do not have to wait for any blockchain confirmations. An application can immediately consider an operation finalized and display that to users, without having to wait for a set number of confirmations. This is how state channels are able to offer web-like response times.

We call this property instant finality. In consensus research, “finality” means the extent to which a state transition is guaranteed not to be reverted. In the context of state channels, an operation is final if Alice cannot be prevented from realizing that operation on the blockchain if they choose to.

If the latest “update” in a state channel says “Alice = 5ETH, Bob = 1 ETH”, then that state is “final”. Remember, the update is a valid transaction signed by both Alice and Bob, which could be deployed on-chain by either party at any time. As long as we assume Alice can broadcast that transaction to the internet at some point, she can consider that transaction final.

The core property of state channels is the ability to refer back to the blockchain only when necessary. If a channel is properly constructed, then all parties can engage in fast operations that offer instant finality. If anything ever goes wrong, all parties always have the option to deploy the latest version of the state to the blockchain.

Keep in mind that state channels — and all blockchain technologies — should be considered within appropriate threat models. We examine in detail threat models appropriate for state channels in section 3 of our paper and limitations of state channels in section 7.

Minimizing on-chain operations

Existing application-specific state channel implementations require users to open up a new channel for each application they would like to use, paying expensive transaction fees. For instance, two users would make one on-chain transaction to open a payment channel between them, and they would need to make another on-chain transaction to play a game of chess with each other.

Our state channels minimize on-chain requirements to an extreme, moving as much logic as possible to the off-chain layer. This leads to one of the most significant insights of our paper: a sufficiently powerful multisignature wallet is the only necessary on-chain component of any individual state channel.

Moving logic off-chain allows us to gain significant advantages over existing channels. We can install new applications into a state channel without ever going on-chain. We can even upgrade or re-design a state channel without requiring on-chain transactions or fees.

This approach also has significant privacy benefits. Properly constructed, the multisignature wallet used to secure the state deposit should be indistinguishable from any other multisignature wallet. There would be no way to tell the difference, on chain, between a common multisig and one used to create a state channel.

Counterfactual Terminology

We are able to achieve these results using what we call “counterfactual instantiation”. Explaining this technique requires first defining terminology.

“Counterfactual” means something that could be true, but is not. This is an extremely helpful concept when discussing state channels, where we spend a lot of time reasoning about things that could be happening on chain, but are not.

In state channels, we say “counterfactual X” to describe a case where:

X could happen on chain, but doesn’t
Any participant can unilaterally make X happen on-chain
Participants can therefore act as though X has happened on-chain

For instance, imagine a payment channel between Alice and Bob. Alice sends 4 ETH to Bob through the channel, which in practice means that both parties sign a transaction. This transaction could be deployed on chain at any time by either party, but it is not. So we can say “counterfactual Alice gives Bob 4 ETH”. This allows them to act as though the transaction has already happened — it is final, within appropriate threat models.

Counterfactual instantiation

In the sections above, we said that our approach lets you install new applications into a state channel with zero on chain operations or fees. How it this possible?

The key to this capability is what we call counterfactual instantiation. In the section above, we described counterfactual transactions between Alice and Bob. But we can also create counterfactual contracts. Counterfactual instantiation means to instantiate a contract without actually deploying it on-chain. When a contract is counterfactually instantiated, all parties in the channel act as though it has been deployed, even though it has not. This technique lets us move almost all channel logic off-chain.

Counterfactual instantiation is achieved by making users sign and share commitments to the multisig wallet. These commitments say that if the counterfactually instantiated contract were to be instantiated on-chain, the multisig wallet (which holds the state deposit) will look at the instantiated contract and transfer the appropriate state deposits based on the state of that contract.

For this to work, we need to refer to the counterfactually instantiated contract inside the commitment, before the contract is deployed. To do this, we introduce a global registry: an on-chain contract that maps unique deterministic addresses for any counterfactual contract to actual on-chain deployed addresses.² The hashing function used to produce the deterministic address can be any function that takes into account the bytecode, its owner (i.e. the multisignature wallet address), and a unique identifier.

For example, we might have a contract `C` with bytecode and constructor arguments `initcode`. The result of running a function call to the registry with the argument `initcode` would be that an entry would be added to the registry; its key being the counterfactual address and its value being the actual on-chain deployed address.

This gives us a way of referencing off-chain contracts without needing to deploy them on-chain first. We simply do a lookup in the registry to see what address corresponds to the counterfactual address. In Solidity this is as simple as:

Registry(registryAddress).resolve(counterfactualAddress)

Object-oriented channel design

Our channel design lets developers take an object-oriented approach to state channels. Any individual state channel will be composed of several counterfactual objects — e.g. a payment channel object, or a chess-game channel object. Because these are counterfactually instantiated, they require no fees to be added into the channel — only signed commitments between the parties.

For instance, Alice and Bob can at any point choose to counterfactually instantiate a contract within their channel — say, a contract that defines a game of chess. They can then exchange state-updates between each other that reference that counterfactually-instantiated game, in order to actually play the game of chess, all with no on-chain fees.

We believe this object-oriented approach offers many significant benefits:

Application developers can program against a well-defined API, plugging into the core components necessary for every channel.
We can ensure that, as long as the core components are heavily audited and remain secure, bugs in the application developer’s code can be isolated to just the state it controls.
Application developers can reuse existing components via counterfactual addressing just as they would reuse ethereum contracts — for instance, a provably fair randomness source.
Users can preserve privacy in a dispute, only putting on-chain the objects that are in dispute.
We can access more points on the trade-off curve between messages passed during normal operation, and transactions that need to be posted in the case of a dispute, and in certain cases this lets us amortize responses to stale state across channels.

Conclusion

If you’re interested in learning more about generalized state channels and the counterfactual technique, we encourage you to read the paper. The paper includes significant content that we have not summarized in this post, including:

Comparisons to other techniques like sidechains and Plasma
Review of existing state channel designs
In-depth examination of relevant threat models
Meta-channels
An example construction for generalized state channels

For updates, follow us at @statechannels and keep an eye on our website.

Lastly, we’d like to thank the Ethereum Foundation for their continuing support of this important work. We are thrilled to be part of a talented community driven to scale the ethereum network, laying the groundwork for Web 3. We’d also like to thank Vitalik Buterin, Erik Bryn, Tom Close, Josh Stark, Nima Vaziri, Armani Ferrante, Lisa Eckey, Kristina Hostakova, Yoichi Hirai, and Sylvain Laurent for their discussion and feedback on earlier drafts of the paper.

NOTES

² In the future, once account abstraction is live, we’ll be able to do this trivially, since a contract address will be computable based on its bytecode and constructor arguments.

from: https://medium.com/statechannels/counterfactual-generalized-state-channels-on-ethereum-d38a36d25fc6

see also: state channels design PDF (local copy)