Dismantling the Bitcoin/Ethereum Layer 2 security model and risk indicators

Author: Faust & Wuyue, Geek web3

Introduction: American management scientist Lawrence Peter once proposed the "barrel theory", which believes that the overall performance of a system is limited by its weakest part. In other words, how much water a barrel can hold is determined by its shortest board. Although this principle is simple, it is often overlooked. In the past, debates on Layer 2 security mostly ignored the priority and importance of different components, and basically focused on state transition reliability and DA issues, but ignored the lower-level and more important elements. In this way, the entire theoretical foundation may be lost. Untenable. Therefore, when we discuss a complex multi-module system, we must first find out which piece is the "shortest board".

Inspired by the barrel theory, we did a system analysis and found that the differences between different components in the Bitcoin/Ethereum Layer 2 security model , there are also obvious dependencies, or the security of some components is more basic and important than the security of other components, which is the so-called "shorter".

In this regard, we can initially prioritize the importance/basis of different components in the mainstream Layer2 security model as follows:< /p>

1. Whether the control rights of the contract/official bridge are reasonably dispersed (how centralized the control rights of multi-signature are)

2. Is there a censorship-resistant withdrawal function (forced withdrawal, escape hatch)

3. Is the DA layer/data release form reliable (whether DA data is released on Bitcoin, Ethereum)

4. Whether a reliable fraud proof/validity proof system has been deployed on Layer1 (Bitcoin L2 requires the help of BitVM)

We should moderately absorb the research results of Layer 2 from the Ethereum community and avoid Lysenkoism

Compared to the highly ordered Ethereum Layer 2 system, Bitcoin Layer 2 is like a brand new world, which has become more and more important after the inscription craze. While developing important new concepts, while showing a rising momentum, its ecosystem is becoming increasingly chaotic and chaotic. All of a sudden, various Layer 2 projects are springing up like mushrooms after a rain. While they bring hope to the Bitcoin ecosystem, they deliberately conceal their own security risks. Some people even threatened to "deny Ethereum Layer 2 and follow the unique path of the Bitcoin ecosystem", showing a strong tendency to take an extremist route.

Considering the differences in functional attributes between Bitcoin and Ethereum, Bitcoin Layer 2 is destined to be unable to align with Ethereum Layer 2 in the early days, but This does not mean that we should completely deny the industry common sense that has long been established in Ethereum and even the modular blockchain industry (refer to the "Lysenko incident" in which the former Soviet biologist Lysenko used ideological issues to persecute Western genetics supporters) .

On the contrary, these evaluation standards, which were obtained by "predecessors" with great efforts, have already shown their strength after being widely recognized. It is absolutely not rational to deliberately deny the value of these results.

While building Bitcoin Layer 2, we should fully Recognize the significance of "learning from the West and applying it to the East", and appropriately absorb and optimize many conclusions from the Ethereum community. But when drawing on perspectives outside the Bitcoin ecosystem, we must be aware of the differences in their starting points, and ultimately seek common ground while reserving differences.

This is like discussing the similarities and differences between "Westerners" and "Orientals". Regardless of whether it is Western or Eastern, the suffix "人" expresses many similar characteristics, but when corresponding to different prefixes such as "Western" and "Eastern", the subdivision characteristics are different.

But in the final analysis, there is bound to be overlap between "Westerners" and "Easterners", which means that many things that apply to Westerners Many things that apply to "Ethereum Layer 2" also apply to "Bitcoin Layer 2". Before distinguishing the differences between Bitcoin L2 and Ethereum L2, it may be more important and meaningful to clarify the interoperability between the two.

Adhering to the purpose of "seeking common ground while reserving differences", the author of this article does not intend to discuss "what is Bitcoin Layer 2 and what is not", because this topic The controversy is so great that even the Ethereum community has not reached an objective consensus on "which is Ethereum Layer 2 and which is not Layer 2".

But what is certain is that while different technical solutions bring expansion effects to Bitcoin, they also have different security risks. The trust assumption existing in its security model will be the topic that this article intends to focus on.

How to understand the security and evaluation criteria of Layer2

Actually, the security of Layer 2 is not a new discussion point. Even the word security is a composite concept that includes multiple subdivided attributes.

Previously, the founder of EigenLayer briefly subdivided "security" into "transaction irreversibility (rollback resistance), resistance to Four elements including auditability, DA/data release reliability, and state transition effectiveness.

(The founder of EigenLayer once expressed his views on how the client-side verification/sovereignty Rollup scheme can inherit the security of the Bitcoin mainnet)

L2BEAT and Ethereum community OG have proposed a more systematic Layer 2 risk assessment model. Of course, these conclusions are aimed at smart contract Layer 2, rather than typical non-smart contract Layer 2 such as sovereign rollup and client verification. .

Although this is not 100% suitable for Bitcoin L2, it still contains many conclusions worthy of recognition, and most of its points It has been widely recognized in the Western community, and it also facilitates us to objectively evaluate the risks of different Bitcoin L2s.

(Vitalik once said that because the Rollup solution cannot achieve theoretical perfection in its early launch, it must use some auxiliary means to improve security, and these auxiliary means are called " "Training wheels" and will introduce trust assumptions. These trust assumptions are risks)

So where do security risks come from? Considering that currently, whether it is Ethereum Layer 2 or Bitcoin Layer 2, many of them rely on centralized nodes to act as sequencers, or a small number of nodes form a "committee" in the form of a side chain. These tend to be centralized sequencers/committees. If unrestricted, users' assets can be stolen and run away at any time. Users' transaction requests can be rejected, resulting in assets being frozen and unusable. This involves the effectiveness and censorship resistance of state transitions mentioned by the founder of EigenLayer.

At the same time, because Ethereum Layer2 relies on the contract on the ETH chain for state transition verification and deposit and withdrawal behavior verification, the contract controller ( In fact, it is Layer2 official) If you can quickly update the contract logic and mix it with malicious code segments (for example, allowing a specified address to transfer all the tokens locked on the L1-L2 deposit and withdrawal contract), you can directly Stealing assets held in trust.

This is attributed to the "contract multi-signature allocation problem", and the multi-signature allocation problem also applies to Bitcoin Layer 2, because Bitcoin Layer 2 It often relies on the "notary bridge", which requires multiple nodes to release cross-chain requests through multi-signatures. Therefore, Bitcoin Layer 2 also has the problem of how to reasonably distribute multi-signatures. We can even regard it as the most basic of Bitcoin Layer 2. "training wheels".

In addition, the DA issue is also extremely important. If Layer2 does not upload data to Layer1, but chooses some unreliable DA release venues, if this off-chain DA layer (commonly known as the DAC Data Availability Committee) colludes and refuses to release the latest transaction data to the outside world, a data withholding attack will occur. This will cause the network to become obsolete and may prevent users from withdrawing funds smoothly.

L2BEAT summarized the above issues and summarized several core elements in the Layer2 security model:

1. State verification/prove whether the system is reliable (State Validation)

2. Is the DA data release method reliable (Data Availability)

3. If the Layer2 network deliberately rejects your transaction/stops, you Can assets be forcibly withdrawn from Layer2 (Sequencer Faliure, Proposer Failure)

4.  Layer2 related contracts-official cross-chain bridge Whether control is dispersed enough. If the power is relatively concentrated, will users have enough time to respond when "guarding and stealing" occurs (Exit Window)

("set on L2BEAT for different Layer2 projects" Risk factor display")

 Anyway, when we analyze Layer2 security risks, we are actually discussing Layer2 How many scenarios exist in the network that may cause damage to user assets, and whether the Layer 2 system can effectively control these dangerous situations through mechanism design. If certain malicious behaviors cannot be eliminated, how much "trust" do we need to introduce, how many individuals in a group need to be trusted, and how many "training wheels" do we need to rely on.  

In the following, we will analyze the risk factors in the general Ethereum Layer2/Bitcoin Layer2 model (this article refers to The objects discussed do not include "state channels" or "payment channels", nor do they include inscription index protocols, because they are special). And we will try to explore which factors are more basic, lower-level, and more important in the Layer 2 security model. These more basic shortcomings will be trust risks that deserve our attention more than other shortcomings.

Layer2's barrel effect - what are the shortcomings

The shortest board - management rights of the contract/official bridge

In Here, we might as well use the "barrel effect" to analyze Layer 2 security issues. It is easy to see that the shortest piece of wood is the "contract upgradeability" mentioned above (mainly for Ethereum Layer 2), or even further. Said that it is "the management right of the official cross-chain bridge" (applicable to both Bitcoin and Ethereum Layer 2).

For Ethereum Layer 2, as long as the Layer 2 official can quickly upgrade the contract on the Layer 1 chain, theoretically the Token locked on the L2 official bridge deposit and withdrawal address can be stolen, no matter how reliable its DA layer or certification system is .

It can be said that the control authority of the bridge contract is related to the safety of the entire system. It is the most basic of the entire Layer2 and even the modular blockchain stack. , the most critical part. If the bridge component/contract can be updated and iterated under multi-signature control, then we need to introduce a "trust assumption" here, assuming that the controller of the Layer 2 contract/official bridge will not do evil.

(The contract upgrade delays of different Layer 2 projects are marked on L2BEAT. Most L2 contracts can be upgraded immediately by the controller. If the contract controller wants to steal assets, or his private key is stolen by a hacker, L2 managed User assets must suffer)

Different from Ethereum Layer 2, the Bitcoin Layer 2 bridge is basically not controlled by the contract on Layer 1, because Bitcoin does not originally support smart contracts. Relatively speaking, the entire workflow of Ethereum Layer 2 is highly dependent on the contract on Layer 1, while Bitcoin Layer 2 cannot do this.

(Starknet schematic)

This is for bit For currency layer 2, it is an unavoidable problem, which can be said to have both advantages and disadvantages. At present, it seems that the "trustless bridge" implemented by Ethereum Layer 2 relying on contracts cannot be realized in Bitcoin L2. This "Trustless Bridge" requires the deployment of a dedicated contract on Layer 1 and the cooperation of the DA+ fraud proof/ZK proof system. It is essentially similar to the "optimistic bridge" like Orbiter or ZK bridges such as Polyhedra.

The current mainstream view in the industry is that if the bugs that may exist in practice are not taken into account and only the theoretical model is considered, the optimistic bridge and the ZK bridge The security level is basically the highest level. As long as the contract code does not contain bugs or cannot be maliciously upgraded, it is basically trustless.

(Optimistic Bridge only needs to ensure that 1 out of N watchers is honest to ensure safety. The trust model is 1/N) 

Since Bitcoin Layer 2 cannot deploy contract components on Layer 1 (we are not talking about the Lightning Network here), its official bridges are basically "notary bridges" composed of a small number of nodes. Or called "multi-signature bridge", the security of this kind of bridge depends on the setting method of multi-signature/threshold signature, which requires the introduction of strong trust assumptions: it is assumed that these notaries will not collude or have their private keys stolen.

Most of the current bridges based on notary/threshold signatures are not as secure as the official "trustless bridge" of Ethereum Layer 2 "Compared (the premise is that the Ethereum Layer 2 contract will not be maliciously upgraded). Obviously, the asset security of Bitcoin Layer 2 network custody will be limited by the security of its official bridge, or the decentralization of power of the multi-signature bridge, which is its first "auxiliary wheel".

Due to the "upgrade permissions" of Ethereum Layer 2 official bridge-related contracts, they are often concentrated in the hands of a few multi-signature controllers. If multi-signature controllers collude, the Ethereum Layer 2 bridge will also have problems, unless its contract cannot be upgraded or is subject to a long delay limit (currently only Degate and Fuel V1).

(Every time Degate contracts upgrade, it will reserve a 30-day safe escape period for users. During this period, as long as everyone finds that the new version of the contract code has malicious logic, they can use the forced withdrawal/escape cabin function to safely Escape)

As for the "official bridge" part, the trust models of Ethereum Layer2 and Bitcoin Layer2 are basically the same: multi-signatures need to be trusted Controllers will not conspire to do evil. This group of multi-signatures can control the L2 official bridge and either change its code logic or directly release invalid withdrawal requests. The final result is: user assets may be stolen.

The only difference between the two is that as long as the contract of Ethereum Layer 2 is not maliciously upgraded/the upgrade window is long enough, its official bridge is trustless. , but Bitcoin Layer 2 cannot achieve this effect anyway.

The second shortest board - censorship-resistant mandatory withdrawal

If we assume that the issue of multi-signature contract/official bridge control mentioned above can be ignored, that is, there is no problem with this layer, then the next most important layer must be the withdrawal behavior Censorship resistance.

Concerning the importance of censorship-resistant forced withdrawal/escape hatch functions, Vitalik’s article "Different types of layer 2s" a few months ago "It has been emphasized that whether users can successfully withdraw assets from Layer 2 to Layer 1 is a very important security indicator.

If Layer2's sorter keeps rejecting your transaction requests, or malfunctions/is down for a long time, your assets will be "frozen" and nothing can be done. Even if DA and fraud proof/ZK proof systems are available, without an anti-censorship solution, such Layer 2 is not secure enough and your assets can be detained at any time.

What's more, the Plasma solution, which was once popular in the Ethereum ecosystem, allows anyone to safely Withdraw assets to Layer1. At this time, the entire Layer 2 network is basically scrapped, but there is still a way for your assets to escape unscathed. Obviously, the censorship-resistant withdrawal function is more basic and lower-level than the DA and proof systems.

(Dankrad of the Ethereum Foundation said that Plasma can still allow user assets to be safely evacuated when DA fails/users are unable to synchronize the latest data)

Some Ethereum Layer 2, such as Loopring and StarkEx, dYdX, Degate, etc., will set up a censorship-resistant forced withdrawal/escape cabin activation function on Layer 1. Taking Starknet as an example, if the user submits Forced on Layer 1 If the Withdrawal request does not receive a response from the Layer2 sequencer at the end of the 7-day window period, the freeze Request function can be manually called to put L2 into a frozen state and activate the escape cabin mode.

At this time, the sorter cannot submit data to the Rollup contract on L1, and the entire Layer2 will be frozen for one year. Then, users can submit a merkle proof to prove their asset status on Layer 2, and withdraw money directly on Layer 1 (actually, they take away their own equal amount of funds from the official bridge’s deposit and withdrawal address).

Obviously, the escape hatch mode can only be implemented on a chain like Ethereum that supports smart contracts. Bitcoin cannot run such complex logic. In other words, the escape hatch function is basically a patent of Ethereum Layer 2. Bitcoin Layer 2 must use some additional auxiliary means to imitate the cat and the tiger. This is the second "auxiliary wheel".  

But simply stating a "forced withdrawal request" is much more convenient than activating the escape hatch directly. The former only requires the user to submit a transaction to the specified address on Layer 1, and in the additional data of the transaction, declare the data that they want to submit to all Layer 2 nodes (this can directly bypass the sequencer and convey requests to other Layer 2 nodes) . If the "forced withdrawal" does not receive a response for a long time, it is a more reasonable design for the user to trigger the escape cabin mode.

(Reference: For Layer2, how important are the forced withdrawal and escape cabin functions?

https://mp.weixin.qq.com/s/EheKZWDcJHYZ7vBZZPOMDA)

Currently, there are already Bitcoin Layer 2 teams planning to imitate Arbitrum’s forced transaction implementation, allowing users to issue forced transaction statements (Forced Transaction Envelopes) on the Bitcoin chain. Under this solution, users can bypass the sequencer and "convey their voices" directly to other Layer 2 nodes. If the sequencer still rejects the user's request after seeing the user's forced transaction statement, it will be noticed by other Layer 2 nodes and may be punished.

But the problem is that Arbitrum’s forced transaction function, benefiting from its fraud proof system, can punish Sequencer/Proposer that has been ignoring user transactions. However, Bitcoin Layer 2, which is difficult to verify fraud proof on Layer 1, will encounter certain challenges in this regard. (Let’s not discuss BitVM for the time being.) If it is a solution such as sovereign Rollup whose security level is not much different from client verification, it is difficult for us to seriously evaluate its reliability, and we may need to evaluate the implementation details of different projects.

Of course, given that many Bitcoin Layer 2 currently operate in a form similar to side chains, which is equivalent to realizing a decentralized sorter, it can Solve the anti-censorship problem to a certain extent. But this is only an effective auxiliary means, certainly not the ultimate solution.

ps: Some current Layer 2 solutions, such as Validium, etc., are not perfect in the mechanism design of the escape cabin, and the sequencer initiates data withholding. When attack/DA is unavailable, users can be prevented from withdrawing funds. But this is due to the imperfect design of the Layer 2 escape cabin. In theory, the optimal escape cabin withdrawal can only rely on historical data and does not need to rely on the availability of DA/new data)