Partnered With:

Community dispute: does side chain count as L2?

Read this article in 28 Minutes

L2's security depends on Ethereum; The security of the side chain is unrelated to that of Ethereum

原文标题：《社区争议：侧链算不算 L2？》

Original source: ETH Chinese website

This article summarizes the controversy surrounding Polygon side chains and L2 in the community, and translates Dankrad Feist's article, "What's Wrong About 51% Attacks?" so readers can read the answers to these controversies.

After Ethereum expansion solution Polygon broke into the top 20 cryptocurrencies by market capitalization on May 16, StarkWare co-founder Uri Kolodny tweeted his congratulations, but he also stressed: "Polygon is a side chain, not a layer-2. L2's security depends on Ethereum; side chain security is irrelevant (or even less) to Ethereum's." As a result, the community began to debate whether Polygon was L2 or not.

In response to Uri Kolodny's comments, Mihailo Bjelic has the following response. [1] :

First of all, Polygon isn't a side chain, it's a scale-out solution. Second (and most importantly), the default L2 is more secure than the POS side chain (in our case, the commit chain) is definitely wrong. To explain why, I'll simply compare Polygon's POS chain to StarkWare's Zkrollup or Validium.

Our POS chain does have its own set of verifiers, but it is completely permission-free and has pledged $2.8 billion. In addition, the implementation has been field tested (14 million blocks and zero accidents).

However, StarkWare Rollup has only one POA operator. This operator may go down, jump the gun, review user transactions, etc. And it is secured by Starks, a new, unproven cryptography. As for Validium, the situation is even more worrying. The Validium scheme used by Deversifi also relies on a small set of POA data availability nodes. These nodes can conspire to prevent any or all users from withdrawing funds by denying access to the data.

Given the above, I think it would be wrong to assume that L2S is more secure by default than side/commit chains.

In response to Mihailo Bjelic's reply, the community discussed from three perspectives: 1) the difference in security between layer-2 and side chain; 2) Whether layer-2 can achieve the same security as layer-1; 3) Differences between ETH2 and side chain in security. In response to the community's confusion, Ethereum Foundation developer Dankrad Feist has published an article titled "What Everyone Is Missing About the 51% Attack" (see below), which basically contains the questions and answers discussed above.

1. First, on the first question, Dankrad Feist disagrees, saying that L2 is indeed more secure because being L2 must provide the same security as the base layer. The POS side chain has the security of a weaker chain (usually a side chain). [3]

James Prestwich also weighed in. [4] : "L2 requires fewer new security assumptions than a side chain, but its security is not exactly the same as that of the main network." He pointed out that L2 has the following different characteristics compared with the side chain:

• 依赖于非审查 (欺诈证明)

• 依赖于新的密码学和可信的设置 (有效性证明) 补充一点，Starks 不需要依赖可信的设置

• 更高的硬件和带宽需求

In the following article, Dankrad Feist points out that "side chains do not verify validity, only the vast majority of the consensus conditions, and they do not have data availability checks." For the safety of side chain, please refer to the article "How does side chain work?" That part.

2. As for whether L2 can achieve the same security as L1. According to Patrick McCorry [5], the goal of L2 is to be as close to L1 security as possible, but it is impossible to be exactly the same:

• 欺诈证明不是尚方宝剑，尤其是当发布欺诈证明的费用太高时，其安全性就更小了

• 同样的，零知识证明也不是万能的，会出现排序者掉线以及 L1 无法应对大规模退出的情况

He also mentioned that the L2 solution can be boiled down to the following four points:

• 数据可用性 (委员会/rollup/等)

• 状态转换完整性 (零知识证明/欺诈证明)

• 提款完整性 (退出保证)

• 协议活性 (排序者的选择)

This hybrid approach is difficult to achieve full L1 security.

Back to the following article, Dankrad Feist explains the "Security Model for Blockchain" to highlight why L1 security is so difficult to achieve.

3. How does Polygon's POS chain compare to Eth2's? In the discussion, Dankrad Feist pointed out [5] that in the long-term development, the POS side chain will be a big hidden trouble. In ETH2 we tried to remove most of the honest assumptions, but the POS bridge didn't do that.

Here is the article:

What did everyone get wrong about the 51% attack

Please forgive the provocative tone of the title. Obviously, not everyone misunderstands the 51% attack, but there are a significant number of people who don't, so writing about it is no bad thing.

There is probably a myth in the blockchain community that as long as someone controls more than 50% of the computing power of Bitcoin, Ethereum, or any other blockchain, then that person can do anything to the network. In PoS (interest) mechanism, two-thirds of the total amount of anyone who gathered the pledge, ta can also do anything for the Internet. He can transfer other people's assets, issue tokens at will, and so on.

This is a mistake.Here's what a 51% attack can do:

• 攻击者可以阻止用户使用区块链，即，拦截任何他们不喜欢的交易。这叫做审查。

• 他们可以回滚区块链的交易，即撤销一定数量的区块并更改其中的交易顺序。

What they can't do: change the rules of the system.This means:

• 他们不能简单地在区块链系统规定之外发行新代币；例如，比特币目前为每个新的区块生产者 6.25 BTC；他们不能将这个数字变成 100 万比特币

• 如果他们没有某个地址的私钥，他们就不能使用该地址的代币

• 他们生产的区块不能比共识规则规定的大

This is not to say that the consequences of a 51% attack are not serious, it is still a very bad attack. Reordering transactions can cause a double flower, which is a very serious problem. But there are still limits to what they can do.

So with most blockchains, including Bitcoin and Ethereum, how do they ensure that now? What happens if a miner strikes a block that violates the consensus rules? Or what happens if a majority of pledgers sign a block that violates the rules of consensus?

Blockchain security model

Sometimes people claim that the longest chain is a valid Bitcoin or Ethereum chain. That's not quite the whole story. The correct definition of the current header is

• 总难度最高的有效链。

Therefore, before clients accept the condition that the blockchain should be used to record current historical data, they need to verify two properties:

1. The blockchain must be valid. This means that all state transitions are valid. For example, on Bitcoin, all transactions only cost transaction outputs that were not previously spent, Coinbase only receives transaction fees and block rewards, and so on.

2. It must be the most difficult chain. In colloquial terms, this is the longest chain, but "longest" is not measured in terms of the number of blocks, it is measured in terms of the total amount of mining effort spent on the chain.

This may sound abstract. It is reasonable to ask who verifies the first condition mentioned above, that is, who verifies that all blocks on the blockchain should be valid? Because if the miners prove that the chain works, then it's just rework, and we're not really getting anything out of it.

But blockchain is different. Let's look at why, starting with a common client/server database architecture:

Note that with a typical database, users trust the database server. They don't check if the response is correct; The client ensures that it is formatted effectively according to the protocol, and that is all. The client (represented here by a blank box) is "unintelligent" : it cannot verify anything.

But in the framework of a blockchain, it looks like this:

Let me begin by summarizing the components included in the figure above. First miners (or pledgers) produce blockchains. P2P (peer-to-peer) networks ensure that everyone has access to a valid chain, although there are some dishonest nodes (you need to be connected to at least one honest and well-connected P2P node to ensure that you are always in sync with the valid chain). Finally, the client sends the transaction to the P2P network and receives the latest chain updates (or the complete chain, if they are synchronizing) from other nodes in the network. Clients are actually part of the network, and they will also contribute by forwarding blocks and transactions, but this is less important.

The important part is that the user is running a full node, represented by the column in the client in the figure above. As soon as a client gets a new block, just like any other node, whether it's a miner or a node in a P2P network, these clients will verify that the block is a valid state transition.

If this is not a valid state transition, the block is ignored. This is why it makes no sense for a miner in a network to try to mine an invalid state transition. Everyone just ignores it.

Many users run their own nodes that interact with blockchains such as Ethereum or Bitcoin. Many communities have made this pattern part of their culture, and there is a strong emphasis on everyone running their own nodes, so that they become part of the validation process. Indeed, it is important to have most users (especially those who have pledged large amounts of assets) running full nodes; If the majority of users become lazy, then miners may suddenly be tempted to produce invalid blocks, and the model will no longer apply.

An analogy: separation of powers

It's a bit like the separation of powers in a democracy -- there are different branches of government, and just because you have a majority in one of them (like the legislature) doesn't mean you can do what you like and flout all the laws. Similarly, miners or pledgers have the right to order transactions on the blockchain; And they don't have the luxury of simply imposing new rules on the community.

But do all blockchains work like this? But is this how all blockchains work?

That's a good question. One important thing to note is that the model described above only works if the whole node is easy to run. As a normal user, if you have to buy another computer for $5000 to run a full node, and you always need a 1 Gbit /s network connection, then he or she will not choose to run a full node at all. Although TA can meet the network requirements in some places, it is likely to be inconvenient to keep it permanently to run your own blockchain nodes. In this case, the average user will most likely not choose to run their own node (unless the TA's transaction is very valuable), which means that the TA will trust someone else to perform the operation for them.

Suppose you have a chain that is so expensive to run that only the pledger and the exchange will run the full node. You've just changed the trust model, and then most of the pledgers and exchanges can get together and change the consensus rules. There is no dispute with the user about this -- if the user has no control over the chain at all, then they cannot initiate a fork. They can stick with the old rules, however, until they start running full nodes, they simply don't know if their request is being answered on the chain they want (the chain that meets their consensus requirements).

This is why whenever there is talk of increasing the block size of Ethereum or Bitcoin, there is always a lot of debate -- each increase in the block size increases the burden on everyone's own running nodes. This isn't much of a problem for the miners -- it costs much less to run a node than the actual mining operation -- so it shifts the balance of power from the user to the miners (or the pledgers).

How does the light client work?

But what if users just want to use cryptocurrency to buy coffee? Does TA need to run full nodes on the phone?

Of course, no one wants to have to do this, and neither do users. This is where the light client comes in. Light clients are simpler clients, and they don't need to validate the entire chain -- they just validate the consensus, which is the total difficulty or the amount of pledged money that has been voted.

In other words, light clients are tempted to follow a chain that contains invalid blocks. There are remedies such as data availability checks and proof of fraud. As far as I know, there is no chain that does this yet, but at least Ethereum will do it in the future.

Thus, with a light client with data availability checks and proof of fraud, users can use the blockchain's security model without having to run a full node. This is our ultimate goal, which is that any smartphone can easily run the Ethereum Light Client.

How does the side chain work?

Side chains are a hot topic at the moment. They seem to offer a simple expansion solution, not as complex as the Rollups. In short:

• 创建一条新的 PoS 链

• 在自身和以太坊之间创建一个双向桥接

• …

• 重点！请注意，侧链的安全性几乎完全依赖于桥接——这是一种允许某条链读取另一条链的状态的构造。毕竟，如果攻击者能够欺骗主链上的桥，让桥接链上的所有资产都为其所有，那么即便 PoS 链上的全节点提出异议也没办法了。所以一切都取决于桥。

Unfortunately, the state of the bridge is the same as the light client. They do not verify validity, but only the vast majority of the consensus conditions. However, side chains are worse than light clients in two ways:

1. Bridging is used for very high value transactions, where most users will choose a full node if they can

2. Unfortunately, we have no way to strengthen the bridge, as we can with light clients -- the reason is that they cannot validate data availability checks

The second point is so subtle that you can devote an article or two to it. But in a nutshell, the bridge can't do data availability checking, and without data availability checking, proof of fraud is almost useless. By using zero-knowledge proofs, you can improve this problem by requiring the bridge to pack proofs of all valid blocks -- unfortunately, this is still open to data availability attacks, but it's an improvement.

To conclude, the security model for side chains is different from, and much weaker than, blockchains like Ethereum and Bitcoin. They do not prevent invalid state transitions.

Do these problems need to be solved by sharding?

In fact, all of this has a lot to do with sharding. We need sharding to scale up because sharding is the only way to scale up without raising the barriers to running full nodes, while maintaining the full security of the blockchain as much as possible.

But what if someone revoked all historical data? Then TA can still steal all the Bitcoins /ETH/ etc

In theory, Bitcoin could be stolen by rolling back all transactions on a non-checkpoint PoW chain. Yes, you can't issue a trillion Bitcoins, but you can still steal all the Bitcoins in existence, which is also great, right?

I think this is very theoretical. The chances that a community will accept a fork that modifies its data for several years (or even just a few hours) are almost zero. In all the possible forks, there will be a massive scramble, and soon the conclusion will be reached and the fork will be rejected, and only the valid chain will be the existing chain.

With POS and finalizing, this mechanism becomes formalized -- a client can never roll back a finalized block.