Partnered With:

One article to understand "side chain"

Read this article in 16 Minutes

Sidechains do not have the security that the wider Ethereum community expects.

Original title: "Viewpoint|Understanding "side chain""

Original source: Ethereum enthusiasts

< /p>

Disclaimer: The opinions expressed here are my own and do not necessarily represent those of my employer or anyone else.

Thanks Albert Ni for reading and commenting.

Introduction

Layer-2 is important to Ethereum Sex is on the rise, and it's a consensus.

However, "Layer-2" is an imprecise label. When some people talk about "Layer-2", they just mean "things that are not on Ethereum Layer-1". But in fact, how the solution interacts with Ethereum Layer-1 is very important. Different solutions under the same name of "Layer-2" can have vastly different characteristics. It can be argued that "Layer-2" should refer to something with specific properties (for example, we can probably agree that things deployed on AWS are not Layer-2, but there are some projects that have similar security guarantees, but are also considered is Layer-2). However, this is not the subject of my discussion here.

What I am going to discuss here are the properties of sidechains.

The basic meaning of the side chain is: a group of validators submit the latest state of a chain to one (on the main chain) ) smart contracts, a type of system that advances in this way. These (up-to-date) checkpoints can be used by a bridge contract to support user deposits and withdrawals. Generally speaking, there will also be a leader election process among this group of verifiers to determine who will create the side chain block at a certain moment; such as PoA authority proof algorithm and PoS algorithm.

For the broad definition of "side chain", the author discusses a subset of the generalized side chain; however, the original "side chain", that is, the narrow concept of side chain, is generally the same as what the author proposes here. Just look at Everyone is willing to regard "side chain" as a proper noun, and is still willing to take its derivative meaning.)

The side chain is in It also plays an important role in the Ethereum ecosystem. They are a temporary fix for scalability and usability until researchers develop something better. Products like xDai also point out the need for a better user experience and spread it.

However, the side chain does not have the vast Ethereum community Expected security. This is not to say that sidechains should never be used. If people are fully informed, but willing to use it, that's their choice, and it might be worth it. But if people are uninformed, it is dangerous. This article is intended to provide some information. If everyone is already fully aware of these features, it doesn't hurt me to write another article. But if this article can help people realize their misconceptions, then it will be a good thing.

So what security features do sidechains lack? Almost all sidechains are cannot provide:

< p>1. Censorship Resistance

2. Finality

3. Funds Ownership Assurance

If you want all these features, then you may have to find another solution to replace the side chain. Of course, it is also possible to improve the performance of specific solutions in these dimensions while maintaining the core architecture of the sidechain.

I think open discussions are good for everyone.

Censorship Resistance

Apparently, sidechains are censored Less resistant than (well-designed) blockchains. Otherwise, there is no need for a blockchain at all. But here we dig a little deeper.

If there are N verifiers in a certain side chain, and as long as there are M verifiers agreeing, any transaction can be reviewed transaction, then only (N-M) verifiers need to join forces to review a block. This leads to an interesting dilemma: making it harder to censor transactions makes it easier to censor blocks. Because censoring transactions and censoring blocks are bad things, sidechains simply cannot achieve robust censorship resistance

(Translator's Note: here The logic is as follows, if the system cannot produce a block as long as M verifiers do not agree to produce a block, then naturally, only M verifiers are required to review a certain transaction by refusing to produce a block; however, this is also It means that as long as N-M verifiers agree, they can produce blocks arbitrarily, always produce blocks containing other content but not a certain block, or even disappear collectively).

This concern still exists when using PoS, even calculating block weight by stake makes it worse , because the number of independent entities reaching the threshold is likely to be lower (even in the best case, where the stake is sufficiently evenly distributed, it is just as good as without PoS, not better).

Data Availability Guarantee

Assume as long as (N-M ) validators can create a block. Assume further that all other validators need to have the entire state data in order to be able to validate the new state. Then, as long as (N-M) validators are malicious, they can:

1. Create a new block

2. Refuse to share block data with honest validators

3. Essentially, N-(N-M) = M honest verifiers The validators moved out of the consensus process and thus took full control of the system

How likely is this to happen? Obviously more specific details are needed to draw conclusions, but we can start thinking like this: Where is the incentive for a rational validator to share data with others? In traditional proof-of-authority mechanisms, not doing so could be reputationally damaging. However, the reputation mechanism is also difficult to work, because there is actually no way to prove that the data is withheld unless someone else puts all the data on the chain. Think this solution sounds like optimistic rollup? That's right, that's it. This also means that sidechains with better security essentially "degenerate" into optimistic rollups.

In most sidechain schemes, validators receive some form of payment for their work. For honest validators, the reward is shared among N validators. For dishonest validators, the same amount of rewards will only be shared among N-(N-M)=M validators, so validators have every incentive not to share their updated state with others (Translator's Note: Here calculation is suspected to be wrong).

There is a fundamental difficulty here: it is difficult to discern data availability attacks. It is difficult for an honest validator to tell if someone has launched an attack or if they have a synchronization problem.

Finality

Assume that the state transition process is as follows:

state1 => state2 => state3

And every conversion requires some transactions to take effect on the existing state to change the state. The finality means that once the transaction takes effect, it cannot be revoked.

The checkpoint of the side chain is sent to the Ethereum blockchain after the consensus of the verifiers of the side chain, and according to the The consensus mechanism of Fangfang has been solidified. Some people may therefore think that the finality of the side chain is equivalent to the finality of Ethereum; to roll back the block of the side chain, you also need to roll back the block of Ethereum. But this is all wrong.

Because the finality means that the transaction cannot be rolled back, it does not mean that the old state cannot be replaced by the new state. As long as (N-M) validators agree, they can perform the following state transitions:

state1 => state2 => state1

(Using state1 to replace state3 is tantamount to rolling back state2, which has been finalized by default, but this does not require ether at all Fang main chain is also rolled back.)

Sidechain Fund Ownership Guarantee

Assume the current state1={Alice:1000, Bob:0}. That is, Alice has 1000, and Bob has nothing. So what can Bob do if he is malicious and controls (or can efficiently corrupt) the vast majority of POA validators?

He can perform a state transition, state1 => state2, and state2={Alice:0,Bob:1000}. That is, steal all of Alice's money and give it to Bob.

The defense of the sidechain is thus weakened to the point that no (N-M) validators will agree to enforce such an illegal state convert.

This is already known (at least I believe so), but I think it is necessary to remind everyone. You can only have confidence in a sidechain if you believe that a majority of validators won't do such a thing. Most security analysis of sidechains should focus on this.

There may still be certain people you can trust to some extent. Just like many of us trust (for many reasons) centralized service providers. Sometimes the sacrifice is worth it. It is important that you understand that this is a tradeoff.

The problem with using governance procedures as a means of defense

One One way to say this is: "We can use a governance process to solve all the problems mentioned above". This approach is flawed because the entire system degenerates into one governance process. One reason I'm particularly concerned about this statement is that, It means that other properties of sidechains are theater (when, why do we need such properties?). For example, if the governance process is the last resort to prevent the above problems, then it means, what PoS , PoA, all are not important. The governance process of the system is the real PoA. Moreover, it is obvious that the same attack can be launched on the governance process of the system.

Where might the features of sidechains be particularly useful?

Besides some additional properties of sidechains, such as faster block time (thus having a better user experience), there are indeed some occasions where the characteristics of the side chain can shine.

For example:

1. You just want N-M validators to be able to perform arbitrary state transitions. Enterprise applications that want a high-level control authority are an example .

2. M=0, and N verifiers can perform arbitrary state transitions. For example, a four-party game. But the problem is, 1 verifier You can close this chain.

Conclusion

At one time, sidechains were the only solution available while maintaining a certain level of composability and interoperability in Ethereum. Now, as some other Layer-2 scaling solutions mature, it is time to consider how sidechains interact with Other schemes are better integrated.

There are some properties that make sidechains well suited for integration:

1. Realize large-scale migration without fees, to ensure that users will not be stuck because of fees and unable to exit.

< /p>

2. Replace the leader election mechanism with other more censorship-resistant schemes (PoS may be the wrong direction. See this post)

3 . A coordinator is required to handle the difference between two states on the chain.

4. Add error proofs to prevent illegal state transitions.

/p>

As optimistic rollup and optimistic VM technologies mature, the scope of trade-offs for projects will change, so now is a good time to reflect on sidechain properties and their associated trade-offs.