Sidechains and status channels that are confusing concepts: What is the difference, who is better?

Editor's Note: The original title is "Side Chains and State Channels: Different Fireworks"

Foreword: There are many concepts in the technical terminology of blockchain that are often confused. One of them is the side chain and the status channel. Both are extension solutions for blockchains. But in the use of the community, they are often used interchangeably. So what is the difference between them, what are the advantages and disadvantages, who is better? This article helps answer your confusion. The author of this article is Vasa, translated by "Moqi" of "Blue Fox Notes".

The terms “state channel” and “sidechain” in the Ethereum community are often used interchangeably, leading to confusion among the average user. Today we will clarify this issue. Make a cup of coffee first, as it will take some time.

The main purpose of this article is clear:

• Implementing cross-chaining between Fabric, Quorum, and Corda, the integration framework for superbooks is like this
• Chain Weekly reported that Shanghai, Shenzhen and other places have increased the fight against cryptocurrency transactions; the ecological development of the blockchain industry is still in full swing.
• Six indicators to explore the clues of the cryptocurrency market

• What is a status channel?
• What is a side chain?

Then we compare:

• What problems do they both try to solve?
• Which is a better extension solution?

Start now.

What is a status channel?

The state channel is a very broad and simple way of thinking about problems: thinking about transactions that would happen on the blockchain and performing them under the chain without significantly increasing the risk of any participants.

The most famous example of this strategy is Bitcoin's payment channel concept, which allows immediate low-cost payments to be sent directly between the parties.

A state channel is a general form of payment channel that applies the same idea to any type of state change operation that is typically performed on a blockchain. (Blue Fox Note: That is to say, the payment channel is only a special form of the status channel, it is not just a payment)

Moving these interactions to the chain without any additional trust requires significant cost and speed improvements. The status channel will be a key part of the extended blockchain technology and it supports a higher level of user usage.

The basic composition of a state channel is very simple:

Bidirectional state channel

1. Lock a portion of the blockchain state through a multi-signature or a smart contract, so a particular set of participants must agree with each other to update their status.

2. Participants can be submitted to the blockchain transaction by building and signing to update the state between them, before the state is temporarily kept inside. Each new status update is "higher" than the previous update.

3. Finally, the participants submit the status back to the blockchain, which closes the state channel and unlocks the state again.

that's it. If the "status" updated between participants is the balance of the cryptocurrency, then we have a payment channel. Steps 1 and 3 of opening and closing the channel involve blockchain operations.

However, step 2 can quickly perform an unlimited number of updates without involving the blockchain. This is where the status channel can work. Because only steps 1 and 3 need to be posted to the network, as well as paying fees or waiting for confirmation.

In fact, through careful planning and design, the state channel can be kept open almost indefinitely and can be used as part of a larger hub system to power the entire economy or ecosystem.

Although the description here seems simple, people often think of state/payment channels to be very complex. There are many reasons for this: one of them is to hide some important subtleties in the expression of these three steps. Let's take a closer look at the implications of these simple phrases:

• Can be submitted to the blockchain

In order for the status channel to work properly, it must be ensured that the participant can post the status of its current channel to the blockchain at any time. This has led to some major limitations, such as the fact that someone must stay online to protect the interests of each party before the channel is closed.

Imagine, suppose that when we open a payment channel, I start with 100BTC and you start with 10BTC. If we first sign the update that transferred 10 BTCs to me and then sign the update that sent 50 BTCs back to you, the second update is significantly better for you than the last update. If you accidentally drop the network and I can pretend that the second update has never happened, then I can post the first update to the blockchain, effectively stealing 50 BTCs from where you are.

What you need is someone who stays online and has a copy of the latest deal so they can "before" the earlier transaction and make sure your bitcoin is protected. It is not necessarily that you keep online. You can send a copy to a number of random servers, and they agree to publish it only when needed by smart contracts (which can save money). However, no matter how you do it, you need to make sure that the latest signature status updates are higher than all other updates. This brings us to the next subtle phrase:

• Each latest update is "higher" than the previous update

In order for this part of the state channel to work properly, the locking and unlocking mechanisms must be properly designed so that the old state submitted to the blockchain has the opportunity to be corrected by replacing their new state. The easiest way is to have any unlock attempts to start the timer, during which any new updates can replace the old ones (also restart the timer). When the timer is complete, the channel is closed and the status is adjusted to reflect the last update received.

The length of the timer can be selected for each state channel to balance the inconvenience of longer channel off times and the increasing security against Internet connection or blockchain issues. (Blue Fox notes: This means weighing the pros and cons. The timer is too long, causing the channel to be closed for too long, which will cause inconvenience, and the timer is too short, which may bring security problems)

Alternatively, you can build a channel with a fine, so that anyone who issues an incorrect update to the blockchain loses more than they pretend that no subsequent transactions have occurred.

But this mechanism will not have much to do with it at the end, because (back to the previous point) the game theory of this situation makes things change. As long as this mechanism is theoretically justified, it may never have to use it.

In fact, passing the timer/penalty program may incur additional costs, delays, or other inconveniences; considering that forcing someone into the mechanism does not give you any benefit, a party to a state channel may simply pass The final channel state is mutually agreed to close the channel.

This final close operation is fundamentally different from the normal "mediation" update (since it will bypass the latest transaction mentioned above "above" the previous transaction mechanism), therefore, the participant is locked in a particular channel. Each part of the status is only signed once to close the transaction.

The details of these "subtleties" are not particularly important. Eventually it comes down to the fact that the participants open the channel by setting up a “judge” smart contract, signing each other's promises that the “judge” can enforce and decide, and then negotiate to close the channel so that the judge's decision is not needed.

As long as the “judge” mechanism is considered to be reliable, these commitments can be counted as immediate transfers, and only in exceptional circumstances will the judge appear, such as when the party disappears. Of course, these details are just some of the reasons why people think the status/payment channel is complicated. The bigger reason is that the payment channel for Bitcoin is complicated. Building a "judge" mechanism with reasonably useful attributes on Bitcoin is very complicated.

However, once you have a clear general idea of ​​the state channel, you can see that this is only due to the attempt to implement the concept in a restricted environment. Basic smart contract functions, such as timer mechanisms and allowing for two different paths based on submitted signature information, are difficult to do in Bitcoin.

Some of these features are being added or built incrementally. The payment channel is only a special sub-case of the broader "state channel" concept, and we can realize that this is a broader technology that can be applied to any smart contract that is handled frequently in a defined set of participants. Update. You can expect to see this approach in many, if not most, distributed applications.

Now, we have a clearer understanding of what is a "state channel." So let's take a look at the side chains.

What is a side chain?

A side chain is a separate blockchain that is associated with its parent chain (backbone) using a two-way anchor. In other words, you can move assets to the sidechain and then back to the parent chain. (Blue Fox notes: is to move the main chain assets back and forth between the main chain and the side chain)

Side chain

Two-way anchoring allows asset swapping between the parent chain and the child chain at a predetermined exchange rate. The original blockchain is usually the "main chain", and all other added blockchains are called "sidechains". The blockchain platform Ardor refers to its side chain as a "subchain."

Users on the parent chain must first send their tokens to an output address, and these tokens are locked so users cannot consume them elsewhere. After the transaction is completed, it will be confirmed by cross-chaining and then wait for a while to improve security.

After the waiting period, the same amount of tokens will be released on the side chain, allowing the user to get and spend here. When moving assets back from the side chain to the main chain, the process is just the opposite.

alliance

A federation is a group that acts as an intermediate point between the main chain and one of its side chains. This group determines when to lock and release the tokens used by the user. The creator of the side chain can select members of the alliance. The problem with the coalition structure is that it adds another layer between the main chain and the side chain.

The side chain is responsible for its own safety. If there is not enough computing power to protect the side chain, it may be broken. Because each side chain is independent, if it is attacked or invaded, damage will occur in the chain without affecting the main chain. Conversely, if the main chain is attacked, the sidechain will still work, but its anchored assets will lose most of its value.

Side chains require their own miners. These miners can be motivated by “combined mining”, so two separate tokens can be mined at the same time based on the same algorithm.

Now, we have a good understanding of the side chain. So let's put them together.

What problems do they want to solve?

In general, both sidechains and state channels are used to increase the scalability of the blockchain. They follow a similar model.

• Locked state/asset
• Trading outside the blockchain/main chain
• Unlock status/assets from status channel/sidechain

But despite this analogy, there are many differences between the two because we don't use separate blockchains in the state channel, and we use separate blockchains in the sidechains. Let's see what happens to this.

Which of the two is a better scalability solution?

To get the answer, let's take a look at their strengths and weaknesses.

Advantages of the status channel

The state channel has a strong privacy attribute: this is because everything happens "inside" the channel between the participants, not publicly broadcast and recorded on the chain. Only open and closed transactions must be public.

On the side chain, each transaction is posted to the side chain, and whether or not you interact with all participants on the side chain, the transaction is received by each participant on the side chain.

The status channel has instant finalism. This means that as long as the parties sign a status update, it can be considered the final state. Both parties have a high level of assurance that they can "enforce" this status on the chain if necessary. But as mentioned above, considering the security level of the transaction, the closure of the state channel may take a different amount of time.

In the side chain, there is a blockchain on the other side, so the finality depends on the mining power of the side chain.

Disadvantages of state channels

The status channel requires 100% online (availability) for all participants: as we discussed above, if any participant is not online, then this may cost him. If the participant is not online, the participant can use someone else to represent the TA. But the possibility that the representative is attacked or bribed makes it a problem with the state channel. And on the side chain you don't have to be always online.

The status channel is best for applications that have a defined set of participants: this is because the "Judge" contract (the contract used to lock the state) must know the participant/subject (ie address) for a particular channel part. We can add and remove people, but it requires a change to the contract each time. In the side chain, there is no such restriction on the change of participants.

State channels are especially useful in this situation: Participants will have to exchange many status updates over a long period of time: this is because creating a channel deployment "judge" contract will incur initial costs. However, once deployed, the cost of each status update within the status channel can be very low.

Side chain advantages

The side chain is permanent. If there are side chains, you don't have to create exclusive side chains for specific purposes. Once the sidechain is created, it is built and maintained. Instead of closing the sidechain, we lock the assets on the sidechain to move back to the main chain. This is a very useful way, and anyone who does a specific task outside the blockchain/main chain will come to the same sidechain.

Therefore, you don't have to create a separate chain for each new participant. In the status channel, you usually have to create a new status channel to add new participants. But projects such as lightning networks and lightning networks have provided excellent solutions for this. They create a network of participants so you don't have to create new channels for each new participant you interact with.

You can interact indirectly with the participants by creating a channel between you and the recipient through other participants in common between you: you and the recipient.

Sidechains allow cryptocurrencies to interact with one another: they add flexibility and allow developers to experiment on sidechains before the Beta version of the Ark or software updates the on-line backbone. Like traditional banking functions (such as issuing and tracking share ownership) can be tested on the sidechain and then moved to the main chain.

Shortcomings of side chains

The sidechain requires a lot of initial investment to start: in order to create the sidechain, we need enough miners to protect the network from attackers. In addition, we have to make sure they are up and running. However, there is no blockchain in the status channel, so there is no such requirement.

Side chains require alliances: this adds an extra layer between the main chain and the side chains. This may be another weakness that an attacker can attack: you can bribe or attack the Alliance. However, in the status channel, we only need a smart contract to complete this task for us.

The competition between the two is great. The dust settled, but the two still stood. As the research is still ongoing and the actual use has not yet spread, we are not sure who will be the winner. Perhaps they will merge to form a hybrid solution to solve the scalability problem. Until the implementation, we still have to wait and see when we can see.

——

Risk Warning: All articles in Blue Fox Notes can not be used as investment suggestions or recommendations. Investment is risky. Investment should consider individual risk tolerance. It is recommended to conduct in-depth inspections of the project and carefully make your own investment decisions.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!