Original Author: Vitalik Buterin

Original Author: Vitalik Buterin

Translator's Note: With the increasing transaction activities of other L1 public chains and L2, the demand for cross-chain and cross-rollup has also greatly increased. And this makes bridging produce an "anti-network effect": when there are not many transaction activities, the network will be very secure; when there are more transactions, the risk will be greater (because the attack motivation greatly exceeds the attack cost). So what is the difference between cross-chain and cross-rollup security? In this article, Vitalik proposed the concept of "shared security", and based on this, he classified various cross-chain and cross-rollup activities into security levels.

When evaluating a small chain that is "connected" to a large chain in some way, one of the biggest concerns you need is:

If an attacker is able to launch a 51% attack on a small chain, how much damage can this do?

• This is a very real and important issue, as small chains tend to be much smaller (in terms of market cap) than large chains. And it is often quite feasible for an attacker to buy 51% of the tokens (or at least 51% of the staked tokens) of a small chain, especially if there is a large amount of bridging assets on that chain (the attacker able to steal those assets).If the minichain is a "",attackerCanCansteal all assets

• If the minichain is a "side chainside chain",attackerAll assets can be stolen

• , for the same reason as above. However, sidechains are slightly more secure than a fully independent L1. Because the block header of the side chain will be published on Ethereum, so if Ethereum rolls back, the side chain will also roll back. This prevents theft involving 51% attacks on Ethereum, however it does not prevent 51% attacks on sidechains.rollupIf the minichain is a "”, the attacker can delay the transaction, which may force users to have to pay L1 fees, but theyNo assets can be stolen

. This is because there is an on-chain mechanism (proof-of-fraud or proof-of-data-availability) that verifies that events involving the attacker's withdrawals on the mini-chain are all valid.

• Some more specific examples:"plasma"If the minichain is a, the attacker can delay transactions and force users to pay L1 fees, but they also。

• No assets can be stolen"validium"If the minichain is a, the attacker canPermanently lock all user assets,but stillNo assets can be stolen

. Validium (like Starkware's ImmutableX) is thus an interesting compromise. Validium is not as "L2" as rollup, because those who control validium can still deny users access to their assets and blackmail them, but validium is still much more secure than side chains anyway. More importantly, validium can also achieve the scalability of side chains.This is what we call "shared security". If you hold assets and conduct some transactions on a small chain, are your assets as safe or less secure than if you do the same thing on a large chain?

The conclusion is: if it is on rollup or plasma, the assets share the security of the main chain; if it is on an independent L1 or side chain, the security of the assets is much lower than that of the main chain; if it is on validium, its security Sex is somewhere in between.Note also that the reference I made inEF Seventh AMAFor some of the reasons mentioned in , many things are actually symmetric: if you hold ETC, you are better off holding it on a ZK rollup built on top of ETC than you are holding wrapped ETC on Ethereum (although this The bridge is a perfect ZK-SNARK validator for the Ethereum consensus). Not that you need to have transactional activity on the largest chain possible. Rather, it means that the region in which you conduct trading activities belongs to the same region as the region in which the asset you used was originally issued.”shared security zone

. Among them, "shared security zone" can be understood as "a certain chain", and the security of all other chains (such as rollup) is ultimately guaranteed by this chain.

Vitalik's relevant answer in EF's seventh AMA is as follows:

The reason why I maintain a positive attitude towards the multi-chain blockchain ecosystem (there are indeed some independent communities with different values, for them, independent development is better than all competing for the influence of the same thing), and for A key reason why cross-chain applications remain passive is that bridging has fundamental security constraints.

To understand why bridges have these limitations, we need to look at how various combinations of blockchains and bridges are resistant to 51% attacks. A lot of people have this mentality: "If the blockchain gets 51% attacked, the whole system will crash, so we need to spend all our efforts to prevent 51% attacks, not even once." I strongly disagree with this Thoughts; in fact, blockchains maintain many guarantees even after a 51% attack, and maintaining these guarantees is very important.

As an example, suppose you hold 100 ETH on Ethereum, and when Ethereum is 51% attacked, some transactions will be censored and/or reversed. So no matter what happens, you still have those 100 ETH. Even a hacker who initiates a 51% attack cannot propose a block that steals your ETH, because such a block would violate the protocol rules, so it will be rejected by the network. Even if 99% of the computing power or stake share wants to launch an attack to steal your ETH, everyone running a node will only follow the remaining 1%, because only their blocks follow the protocol rules. More generally, if you have an application on Ethereum, it is possible to censor or rollback the application's transactions for a period of time by launching a 51% attack, but what you end up with is a consistent state. If you hold 100 ETH and exchange it for 320,000 DAI on Uniswap, then even if the blockchain is attacked in some crazy way, you will still get a reasonable result in the end: either you still hold 100 ETH, or get those 320,000 DAI. That is, a result that gets neither (or both) actually violates the protocol rules and will not be accepted by the network.

Now, imagine if you transfer 100 ETH to a bridge on Solana and get 100 Solana-WETH, then Ethereum is 51% attacked. The attacker deposits a sum of his own ETH in the Solana-WETH encapsulation contract, and then immediately rolls back the deposit transaction on the Ethereum network after the transaction is confirmed on the Solana network. The Solana-WETH contract is now no longer fully recoverable, maybe your 100 Solana-WETH are now only worth 60 ETH. Even with a perfect bridge based on ZK-SNARKs that could fully verify consensus, it would still be vulnerable to such a 51% attack.

Therefore, it is always safer to hold Ethereum-native assets on Ethereum or Solana-native assets on Solana than to hold Ethereum-native assets on Solana or Solana-native assets on Ethereum. "Ethereum" in this context not only refers to the Ethereum L1 base chain, but also includes any L2 built on it. That is, if Ethereum is 51% attacked and transactions are rolled back, transactions on Arbitrum and Optimism will also be rolled back. Thus, "across-rollup" applications holding state on Optimism and Arbtirum are guaranteed to remain consistent even if Ethereum is 51% attacked. And if Ethereum is not 51% attacked, there is no way to 51% attack Arbitrum and Optimism respectively. Therefore, holding assets issued on Optimism and then encapsulated on Arbitrum is still very safe.

However, when there are more than two chains, the problem becomes more serious. If there are 100 chains, there will be many interdependent dapps between these chains. At this time, even launching a 51% attack on a chain will cause systemic risks and threaten the economy of the entire ecosystem. This is why I think it is possible for interdependent regions to be closely connected to sovereign independent regions (thus, many applications of the Ethereum network are closely connected to each other, many applications of the Avax network are closely connected to each other, etc.; rather than Ethereum The applications of Fang Network and Avax Network are closely related to each other).

This is why rollup cannot directly "use another data layer". If a rollup stores its data in Celestia or BCH or whatever, but handles assets on Ethereum, then if that layer gets 51% attacked, the user is screwed. Even if Celestia's Data Availability Sampling (DAS) can resist 51% attacks, it can't actually help you, because the Ethereum network does not read this DAS; instead, the Ethereum network reads the information on the bridge, and Bridging happens to be vulnerable to 51% attacks. As a rollup wanting to provide security for applications using ethereum-native assets, the ethereum data layer must be used (and the same is true for any other ecosystem).

Of course, I wouldn't say that these problems will arise anytime. It is difficult and expensive to 51% attack just one chain. However, the more users use the cross-chain bridge and the applications on it, the more serious the problem will be. No one will attack Ethereum in order to steal 100 Solana-WETH (or attack Solana in order to steal 100 Ethereum-WSOL). But if there are 10 million ETH or SOL on the bridge, then the incentive to launch attacks will be stronger, and some large asset pools will make these attacks easier to happen. Therefore, cross-chain transaction activities have an anti-network effect: when there are not many transaction activities, the network will be very secure; when there are more transactions, the risk will be greater.

But that doesn't change the classification above; it just makes it broader, because even if Ethereum itself is 51% attacked, these differences in security will still exist.

Some more specific examples:

And it's not safe to use BSV on BSV (although both are in the same shared security zone, which is itself), because BSV is a weak PoW chain and can be easily attacked by boring BTC/BCH miners. And BSV's blocks are too large for users to verify (and there are no plans to add sharding/ZK-SNARK/DAS technology to solve this problem). So when someone conducts a 51% attack on BSV, the attacker can directly issue invalid blocks, and users may have no choice but to accept these blocks.

Original link