Community Controversy: Does sidechain count as L2?

On May 16, the market value of the Ethereum expansion solution Polygon ranked among the top 20 in the cryptocurrency market value, and then StarkWare co-founder Uri Kolodny retweeted congratulations, but at the same time he emphasized: "Polygon is a side chain, not Layer-2. L2 The security of the side chain depends on Ethereum; and the security of the side chain is irrelevant (or even lower) than that of Ethereum.” Therefore, the community started a heated discussion around whether Polygon is L2 or not.

In response to Uri Kolodny's comment, Mihailo Bjelic responded with the following [1]:

First of all, Polygon is not a side chain, it is a set of expansion solutions. Second (and most importantly), it is absolutely wrong to assume that L2 is more secure than a PoS sidechain (ours is the commit chain) by default. To explain why, I'll briefly compare Polygon's PoS chain with StarkWare's zkRollup or Validium.

Our PoS chain does have its own set of validators, but it's completely permissionless and has $2.8 billion staked. Additionally, the implementation has been battle tested (14 million blocks with zero incidents).

However, StarkWare Rollup has only one PoA operator. This operator may crash, run away, review user transactions, etc. And, it's secured by STARKs, a brand new, unproven cryptography. As for Validium, the situation is even more worrisome. 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 data.

Considering the above, I think the idea that default L2s are more secure than sidechains/commitchains is wrong.

In response to Mihailo Bjelic's reply, the community discussed from three perspectives: 1) the difference between Layer-2 and side chains in terms of security; 2) whether Layer-2 can achieve the same security as Layer-1; 3) The difference between Eth2 and side chains in terms of security. As for the confusion in the community, Dankrad Feist, a developer of the Ethereum Foundation, published the article "What everyone got wrong about 51% attacks" [2] (see below), which basically covers the issues discussed above and answer.

1. First of all, regarding the first question, Dankrad Feist disagreed. He said that L2 is indeed more secure, because as an L2, it must provide the same security as the base layer. Whereas PoS sidechains have the security of a weaker chain (usually a sidechain). [3]

James Prestwich also participated in the discussion [4]: ​​"Compared with side chains, L2 requires fewer new security assumptions, but its security is not exactly the same as the main network." He pointed out that L2 has the following differences compared with side chains specialty:

• Rely on non-censorship (fraud proof)

• Reliance on new cryptography and trusted settings (validity proofs) In addition, Starks do not need to rely on trusted settings

• Higher hardware and bandwidth requirements

In the following, Dankrad Feist points out that "the sidechain does not verify validity, only verifies the vast majority of consensus conditions, and it does not have data availability checks." Regarding the security issues of sidechains, see the article "How do sidechains 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 the safety of L1 as possible, but it is impossible to want to be exactly the same:

• Fraud proofs are not silver bullets, especially when the fees to issue them are too high, making them even less secure

• Similarly, zero-knowledge proofs are not a panacea, and there will be situations where the sorter goes offline and L1 cannot handle large-scale exits

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

• Data availability (committee/rollup/etc)

• State Transition Integrity (Zero-Knowledge Proof/Fraud Proof)

• Withdrawal Integrity (Exit Guarantee)

• Protocol liveness (choice of orderer)

This hybrid scheme is difficult to fully achieve L1 security.

Back in the article below, Dankrad Feist explains "Blockchain's Security Model" to highlight why L1 security is so hard to achieve.

3. So how does Polygon's PoS chain compare with Eth2's PoS mechanism? In the discussion, Dankrad Feist pointed out [5] that in the long run, the PoS side chain will be a big hidden danger. In Eth2 we try to remove most of the honesty assumptions, however PoS bridging cannot do that.

secondary title

What everyone is getting wrong about 51% attacks

Please excuse the provocation in the title. Obviously, not everyone misunderstood 51% attacks, but a significant number still didn't, so it wouldn't hurt to write an article about them.

There is probably a myth in the blockchain circle: as long as someone controls more than 50% of the computing power of Bitcoin, Ethereum or other blockchains, then ta can do anything to the network. In the PoS (Proof of Stake) mechanism, as long as someone gathers 2/3 of the total pledge, ta can also do anything to the network. ta can transfer other people's assets, issue tokens at will, and so on.

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

• An attacker can prevent users from using the blockchain, i.e., intercept any transactions they do not like. This is called censorship.

• They can roll back the transactions of the blockchain, that is, undo a certain number of blocks and change the order of transactions in them.

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

• They can't simply issue new tokens outside the rules of the blockchain system; for example, Bitcoin is currently 6.25 BTC per new block producer; they can't turn that number into 1 million Bitcoins

• If they don't have a private key for an address, they can't spend that address' tokens
  

• The blocks they produce cannot be larger than the consensus rules dictate

That's not to say that a 51% attack isn't bad, it's still a pretty nasty attack. Reordering transactions can cause double spending, which is a very serious problem. But there are still limits to what they can do.

Blockchain Security Model

Blockchain Security Model

The valid chain with the highest total difficulty.

The valid chain with the highest total difficulty.

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

This might sound a bit abstract. We have reason to ask a question, who will verify the first condition above, that is, who will verify that all blocks on the blockchain should be valid? Because if the miners still verify that the chain is valid, then it's just duplication of work, and we don't really gain anything from it.

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

Note that with a typical database, the user trusts the database server. They don't check that the response is correct; the client makes sure it's validly formatted according to the protocol, that's all. The client (represented here by an empty square) is "dumb": it cannot verify anything.

But in the architecture of the blockchain, it is like this:

Let me first summarize the components included in the above diagram. First miners (or stakers) produce the blockchain. A P2P (peer-to-peer) network ensures that everyone can use a valid chain despite the presence of 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 update (or the full chain, if they are syncing) from other nodes in the network. Clients are actually part of the network, they will also contribute by forwarding blocks and transactions, but not so important here.

The important part is that the user is running a full node, represented by the bars in the client in the image above. Whenever 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 miners in the network to try to mine invalid state transitions. Everyone just ignores it.

secondary title

For example: 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 branch (like the legislature) doesn't mean you can do whatever you like and defy all law. Likewise, miners or stakers have the power to order transactions in the blockchain; they do not have the power to easily impose new rules on the community.

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

That's a good question. An important thing to note is that the model described above will only work if full nodes are easy to run. As an ordinary user, if you have to spend $5000 to buy another computer to run a full node, and you always need a 1 GBit/s network connection, then you will not choose to run a full node at all. Although ta can meet this network requirement in some places, it is probably not so convenient to permanently maintain it to run its own blockchain node. In this case, it is very likely that the average user will not choose to run the node themselves (unless his transaction is very valuable), which means that he will trust others to perform this operation for him.

Suppose there is a chain that is so expensive to run that only stakers and exchanges run full nodes. You just changed the trust model, and then the majority of stakers and exchanges were able to get together and change the consensus rules. Users have no dispute over this - if users have no control over the chain at all, they cannot initiate a fork. They can stick with the old rules, however, unless they start running full nodes, they have no idea if their requests are being answered on the chain they want (the chain that satisfies their consensus requirements).

secondary title

How do light clients work?

But what if the user just wants to pay for coffee with cryptocurrency? Does Ta need to run a full node on the phone?

Of course, no one wants to need to do this, and neither do users. Then this is when the light client comes into play. Light clients are simpler clients that don't need to verify the entire chain - they only verify the consensus, either the total difficulty or the amount staked that has been voted on.

In other words, light clients are tricked into following a chain that contains invalid blocks. There are remedies for this, such as data availability checks and fraud proofs. As far as I know, no chain has implemented this yet, but at least Ethereum will do so in the future.

secondary title

How do sidechains work?

Sidechains are a hot topic right now. They seem to provide a simple scaling solution, not as complicated as rollups. in short:

• Create a new PoS chain

• Create a two-way bridge between itself and Ethereum

• …

• focus! Note that the security of sidechains relies almost entirely on bridging — a construct that allows one chain to read the state of another. After all, if an attacker can trick the bridge on the main chain into owning all assets on the bridge chain, even if the full node on the PoS chain raises an objection, there is no way. So everything depends on the bridge.

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

• Bridges are used for very high value transactions where most users would opt for a full node if they could
  

• Unfortunately, we have no way to harden the bridge, while we can do this to light clients - the reason is that they cannot validate data availability checks

The second point is very subtle and can be explained in one or two articles. But in simple terms, bridges cannot do data availability checks, and without data availability checks, fraud proofs are pretty much useless. And if you use zero-knowledge proof, you can ask the bridge to pack the proof of all valid blocks, so as to improve this problem-unfortunately, this may still be attacked by data availability, but it is also an improvement.

secondary title

Do all these problems need to be solved by sharding?

secondary title

But what if someone revokes all historical data? Then ta can still steal all bitcoin/ETH/etc

Theoretically, on a non-checkpointed PoW chain, bitcoins could be stolen by rolling back all transactions. Yes, you can't issue a trillion bitcoins, but you can still steal all the bitcoins in existence, which is fine too, right?

I think this is very theoretical. The chances that the community will accept a fork that modifies its data for several years (or even just a few hours) are close to zero. In all possible forks, there will be massive scrambles that will quickly come to a conclusion and reject the fork, agreeing only that the valid chain is the one that exists.

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

[1] https://twitter.com/MihailoBjelic/status/1393686451255226368

[2] https://dankradfeist.de/ethereum/2021/05/20/what-everyone-gets-wrong-about-51percent-attacks.html

[3] https://twitter.com/dankrad/status/1393721324300865537?s=20

[4] https://twitter.com/_prestwich/status/1393730794238005253

[5] https://twitter.com/stonecoldpat0/status/1393869662572748801