One article to understand "side chain"

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: ethfans)

, Author: barryWhiteHat, translation: A Jian, reprinted by Odaily with authorization.

introduction

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

Thanks to Albert Ni for reading and commenting.

introduction

The importance of Layer-2 to Ethereum is increasing day by day, and there is 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. The characteristics of different solutions under the same "Layer-2" name can be very different. It could be argued that "Layer-2" should refer to something with specific properties (e.g., we can probably all agree that something deployed on AWS is not Layer-2, but there are some projects, with similar security guarantees, that 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 verifiers submits the latest state of a chain to a smart contract (on the main chain), and thus promotes a type of system. 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. (Translator's Note: From this definition, it can be seen that what the author is discussing is a side chain that does not have a validity guarantee mechanism designed on the main chain; according to the current broad definition of "side chain", the author is discussing the generalized side chain. However, the original "side chain", that is, the narrow concept of side chain, is exactly the same as what the author puts forward here. It depends on whether you are willing to use "side chain" as a proper noun, or you are willing to use its derived meaning.)

• Sidechains also play 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, sidechains do not have the security that the wider Ethereum community has come to expect. 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 are missing in sidechains? Almost all sidechains cannot provide:

Censorship resistance

Guarantee of ownership of funds

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 an open discussion is good for everyone.

Censorship resistance

Clearly, sidechains are less censorship-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 any transaction can be reviewed as long as M verifiers agree unanimously, then only (NM) verifiers need to unite 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 are fundamentally incapable of achieving robust censorship resistance. , the system cannot generate blocks, so naturally, only M verifiers are required to review a transaction by refusing to generate blocks; however, this also means that as long as NM verifiers agree, they can generate blocks arbitrarily. It is a block containing other content but not a certain block, or even group play disappears).

• This concern persists when using PoS as well, and even calculating block weights by stake makes it worse because the number of independent entities reaching the threshold may be lower (even in the best case with full stake Evenly distributed, it's just the same as without PoS, it won't get better).

• Data Availability Guarantee

• Assume that only (NM) 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 (NM) validators are malicious, they can:

create a new block

Refuse to share block data with honest validators

Essentially removes N-(NM) = M honest validators from the consensus process, thus taking 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-(NM)=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).

state1 => state2 => state3

Here, there is a fundamental difficulty: 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

Suppose the flow of state transition is as follows:

state1 => state2 => state1

And each 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 side chain verifiers, and is solidified according to the consensus mechanism of the Ethereum. 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 (NM) validators agree, they can perform the following state transitions:

(Using state1 to replace state3 is tantamount to rolling back state2, which has been finalized by default, but this does not require the Ethereum main chain to roll back.)

Sidechain Fund Ownership Guarantee

Suppose the current state1={Alice:1000, Bob:0}. That is, Alice has 1000 yuan, but 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.

Therefore, the defense of the sidechain is reduced to the fact that no (NM) validators will agree to perform such an illegal state transition.

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 degree. 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.

Issues with using governance processes as a means of defense

• There is a saying that goes: “We can use governance procedures to solve all the problems mentioned above”. This approach is flawed because the entire system degenerates into one governance process. One reason this statement particularly worries me is that it implies that other properties of sidechains are theater (when and why do we need such properties?). For example, if the governance process is the ultimate means to prevent the above problems, it means that neither PoS nor PoA is 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.

• Aside from some additional properties of sidechains, such as faster block times (and thus a better user experience), there are indeed occasions where sidechain features can shine. for example:

epilogue

You just want NM validators to be able to perform arbitrary state transitions. An example would be an enterprise application that wants to have a high level of control.

The case where M=0 and N verifiers can perform any state transition. For example, a game in which four parties participate. But the problem is that 1 validator can shut down the chain.

• epilogue

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

• There are some properties that are well suited for sidechains to integrate:

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

Replace leader election with something else that is more censorship resistant (PoS might be the wrong direction. See this post)