The side chain does not have the security expected by the majority of the Ethereum community, and cannot provide censorship resistance, finality, and capital ownership guarantees.
Original title: “Understanding “Sidechain””
Author: barryWhiteHat Translation: Ajian
introduction
The importance of Layer-2 to Ethereum is increasing day by day, and it has become a consensus.
However, “Layer-2” is an inaccurate label. When some people talk about “Layer-2”, they only mean “something not on Ethereum Layer-1”. But in fact, how the solution interacts with Ethereum Layer-1 is very important. Different schemes under the same name “Layer-2” can have vastly different characteristics. It can be argued that “Layer-2” should specifically refer to something with specific attributes (for example, we probably all agree that things deployed on AWS are not Layer-2, but there are also some projects with similar security guarantees, but they are also considered It is Layer-2). However, this is not my subject here.
What I am going to discuss here is the nature of sidechains .
The basic meaning of the side chain is: a group of verifiers submit the latest state of a chain to a smart contract (on the main chain), which is a type of system that advances in this way . These (latest state) 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 the group of validators to determine who will create the side chain block at a certain moment; for example, the PoA authority proof algorithm and the PoS algorithm. (Translator’s Note: From this definition, it can be seen that the author is discussing a side chain without a validity guarantee mechanism on the main chain; according to the broad definition of “side chain” now, the author is discussing generalized side chain A subset; however, the original “side chain”, that is, the narrow concept of side chain, is generally the same as the author here. It depends on whether everyone is willing to treat “side chain” as a proper term, or is willing to take it. Its derivative meaning.)
Side chains also play an important role in the Ethereum ecosystem. They are temporary solutions for scalability and availability until researchers have developed better solutions . Products like xDai have also pointed out the demand for a better user experience and made it spread.
However, the side chain does not have the security expected by the vast Ethereum community . This is not to say that side chains should never be used. If people are fully aware of it, but are willing to use it, it is their own choice and it may be worthwhile. But if people don’t know it, it’s dangerous. This article hopes to provide some information. If everyone already fully understands these characteristics, it wouldn’t hurt for me to write another article. But if this article can help you realize your misunderstanding, then it’s a good thing.
So what security features are missing in the side chain? Almost all of the side chains are not able to provide:
Censorship resistance
Finality
Guarantee of Fund Ownership
If you want all of these features, 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 side chain.
I think open discussions are good for everyone.
Censorship resistance
Obviously, the censorship resistance of side chains is weaker than that of (well-designed) blockchains. Otherwise, there is no need for blockchain at all. But here we dig deeper.
If there are N verifiers on a side chain, and any transaction can be reviewed as long as M verifiers unanimously agree, then only (NM) verifiers can be combined to review a block. This leads to an interesting dilemma: To make it harder to review transactions, it will make it easier to review blocks. Because censoring transactions and censoring blocks are both bad things, the side chain cannot obtain strong censorship resistance at all. (Translator’s Note: The logic here is as follows, if only M validators do not agree to a block , The system cannot produce blocks, so naturally, only M validators can review a certain transaction by refusing to produce blocks; however, this also means that as long as NM validators agree, they can produce blocks at will. It is a block that contains other content but not a block, or even group play disappears).
This concern still exists when using PoS , and even calculating block weights based on equity makes it worse, because the number of independent entities reaching the threshold may be lower (even in the most ideal case, equity is sufficient Evenly distributed, it’s just the same as the situation without PoS, it won’t get better).
Data availability guarantee
Assume that only (NM) validators can create a block. Suppose that all other verifiers need to own the data of the entire state to be able to verify the new state. Then, as long as (NM) validators are malicious, they can:
Create a new block
Refusing to share block data with honest validators
Essentially, N-(NM) = M honest verifiers are removed from the consensus process, so they have complete control of the entire system
How likely is this to happen? Obviously more specific details are needed to draw conclusions, but we can start thinking like this: What is the incentive for a rational verifier to share data with others? In the traditional authority certification mechanism, failure to do so may damage the reputation. However, the reputation mechanism is also very difficult to work, because there is actually no way to prove that the data has been withheld, unless other people put all the data on the chain. Think this solution sounds like an optimistic rollup? That’s right, that’s it. This also means that a side chain with better security is essentially “degenerate” into an optimistic rollup.
In most side chain schemes, validators can get some form of payment for their work. For honest verifiers, the reward will be shared among N verifiers. For dishonest verifiers, the same amount of rewards will only be shared among N-(NM)=M verifiers, so the verifier is fully motivated not to share the updated state with others (Translator’s Note: here The calculation is suspected to be wrong).
Here, there is a fundamental problem: it is difficult to identify data availibility attacks. For honest verifiers, it is difficult to tell whether someone launched the attack or the synchronization problem they encountered.
Finality
Suppose the process of state transition is as follows:
state 1 => state2 => state3
And every conversion requires some transactions to take effect on the existing state to change the state. And finality means that once a transaction takes effect, it cannot be revoked.
The checkpoint of the side chain is sent to the Ethereum blockchain after the consensus of the verifier of the side chain, and is solidified according to the consensus mechanism of 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 totally wrong .
Because finality means that the transaction cannot be rolled back, not that the old state cannot be replaced with a new state. As long as (NM) validators agree, they can perform the following state transitions:
state 1 => state2 => state1
(Using state1 to replace state3 is tantamount to rolling back state2, which is already finalized by everyone by default, but this does not require the Ethereum main chain to roll back.)
Guarantee of ownership of side chain funds
Suppose the current state1={Alice:1000,Bob:0}. That is, Alice has 1,000 yuan, and Bob has nothing. So if Bob is malicious and controls (or can efficiently corrupt) the vast majority of POA verifiers, what can he do?
He can perform a state transition, state 1 => state2 , and state2={Alice:0,Bob:1000}. That is, steal all Alice’s money and give it to Bob.
Therefore, the defense of the side chain is reduced to that no (NM) verifiers agree to perform such an illegal state transition.
This is a well-known thing (at least I believe so), but I think it is necessary to remind everyone. Your confidence in a side chain can only be the belief that most of the validators will not do such a thing. Most security analysis of sidechains should focus on this point.
There may still be people you can trust to some degree. Just like many of us (trust for many reasons) centralized service providers. Sometimes this sacrifice is worth it. The important thing is that you know that this is a trade-off.
The problem of using governance procedures as a defense
There is a saying: “We can use governance procedures to solve all the problems mentioned above.” This method is flawed, because the entire system will degenerate into a governance process. One reason this statement particularly worries me is that it means that the other attribute of the side chain is theater (when and why do we need such an attribute?). For example, if the governance process is the ultimate means to prevent the above problems, it also means that PoS and PoA are not important. The governance process of the system is the real PoA. Moreover, it is obvious that the same attack can also be launched against the governance process of the system.
Where can the characteristics of side chains be particularly useful?
In addition to some additional attributes of the side chain, such as faster block time (and therefore a better user experience), there are indeed some occasions where the characteristics of the side chain can shine. such as:
You just want N -M validators to be able to perform arbitrary state transitions. An example is an enterprise application that hopes to have an advanced control authority.
M=0, and N verifiers can perform any state transition. For example, a game involving four parties. The problem is that one verifier can shut down the chain.
Conclusion
In the past, sidechains were the only available solution under the premise of maintaining a certain level of Ethereum’s composability and interoperability. Now, with the maturity of other Layer-2 extension solutions, it is time to consider how the side chain can better integrate with other solutions.
There are some attributes that are suitable for integrating side chains:
Achieve large-scale migration without fees to ensure that users will not be stuck due to fees and cannot withdraw.
Replace the leader election mechanism with other solutions with stronger censorship resistance (PoS may be the wrong direction. See this post)
A coordinator is needed to handle the difference between the two states on the chain.
Add false proofs to prevent illegal state transitions.
With the maturity of optimistic rollup and optimistic VM technology, the scope of project trade-offs will also change. Therefore, now is a good time to reflect on the side chain properties and related trade-offs.
original:
Source link:
