Using the barrel theory to dismantle the Bitcoin/Ethereum Layer 2 security model and risk indicators

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 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 there are obvious dependencies between different components in the Bitcoin/Ethereum Layer 2 security model, or that some components are more fundamental and important for security than others, which can be considered as “shorter”. In this regard, we can initially prioritize the importance/basis of different components in the mainstream Layer 2 security model as follows:

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 published on Bitcoin and Ethereum)

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

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

Compared with the highly ordered Ethereum Layer 2 system, Bitcoin Layer 2 is like a brand new world. This new concept, which has become increasingly important after the inscription craze, is showing rising momentum, but its ecosystem is becoming increasingly chaotic. Out of the chaos, various Layer 2 projects sprouted up like mushrooms after a rain. While they bring hope to the Bitcoin ecosystem, they deliberately conceal their own security risks. Some people have 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 stages, but this does not mean that we should completely deny the industrial 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 achieved by “predecessors” with great efforts, have already shown strong persuasiveness after being widely recognized. It is definitely not a rational move to deliberately deny the value of these achievements.

While building Bitcoin Layer 2, we should fully realize the significance of “learning from the West and applying it to the East” and appropriately absorb and optimize the many conclusions of 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 “Easterners”. Regardless of whether it is Western or Eastern, the suffix “-er (人)” expresses many similar characteristics, but when corresponding to different prefixes such as “Western” and “Eastern”, the subdivision characteristics will be 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 also apply to Easterners. 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 is so controversial, even the Ethereum community has not discussed “which is Ethereum Layer 2 and which is not Layer 2” and reach an objective and consistent view. But what is certain is that while different technical solutions bring expansion effects to Bitcoin, they also have different security risks. The trust assumptions existing in their security models will be the focus of this article.

How to understand the security and evaluation criteria of Layer2

In fact, Layer 2 security is not a new discussion point. Even the word security is a composite concept that includes multiple subdivided attributes. Previously, the founder of EigenLayer once simply subdivided “security” into four elements: “transaction irreversibility (re-org resistance), censorship resistance, DA/data release reliability, and state transition validity.”

(The founder of EigenLayer once expressed his views on how the client-side verification/sovereign 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 views have been widely recognized in the Western community. It also makes it easier for us to objectively assess the risks of different Bitcoin L2s.

(Vitalik once said that since 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 auxiliary means are called “training wheels” and will introduce trust assumptions. Assumptions of trust are risks.)

So where do security risks come from? Considering the current situation, whether it is Ethereum Layer 2 or Bitcoin Layer 2, many of them rely on centralized nodes to act as sequencers, or a “committee” in the form of a side chain composed of a small number of nodes. If these centralized orderers/committees are not restricted, they can steal user assets and run away at any time. They can reject user transaction requests, causing assets to be frozen and unusable. This involves the effectiveness and censorship resistance of state transitions mentioned by the founder of EigenLayer earlier. At the same time, since Ethereum Layer 2 relies on contracts on the ETH chain for state transition verification and deposit and withdrawal behavior verification, if the contract controller (actually the official Layer 2) can quickly update the contract logic, add 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 steal the assets under custody. 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 often relies on the “notary bridge” and requires multiple nodes to release cross-chain requests through multi-signatures, Bitcoin Layer 2 also has the problem of how to reasonably distribute multi-signatures. We can even think of it as the most basic “training wheels” on Bitcoin Layer 2.

In addition, the DA issue is 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. Whether the DA data release method is reliable (Data Availability)

3. If the Layer 2 network deliberately rejects your transaction/shuts down, can you force the assets to be withdrawn from Layer 2 (Sequencer Failure, Proposer Failure)

4. Regarding Layer 2 related contracts - is the control of the official cross-chain bridge sufficiently decentralized? If power is relatively centralized, in the event of ‘insiders acting nefariously,’ do users have enough time to respond in an emergency? (Exit Window)

(“Risk factor display chart” set for different Layer 2 projects on L2BEAT)

Anyway，when we analyze Layer 2 security risks, we are actually discussing how many scenarios exist in the Layer 2 network that may cause damage to user assets, and whether the Layer 2 system can effectively restrict 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. Below we will analyze the risk factors present in the general Ethereum Layer2/Bitcoin Layer2 model. (The objects discussed in this article 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 its shortcomings?

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

Here, we might as well use the “barrel effect” to analyze Layer 2 security issues. It is easy to see that the shortest board is the “contract upgradeability” mentioned above (mainly for Ethereum Layer 2), or further, the “management rights of the official cross-chain bridge” (applicable to both Bitcoin and Ethereum Layer 2).

For Ethereum Layer 2, as long as the Layer 2 officials can rapidly upgrade contracts on the Layer 1 chain, theoretically, they can steal the tokens locked in the Layer 2 official bridge’s deposit and withdrawal address, regardless of how reliable its Data Availability (DA) layer or proof system is. It can be said that the control authority of the bridge contract concerns the safety of the entire system. It is the most fundamental and critical part of the entire Layer 2 and even the modular blockchain stack. 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, the user assets hosted by L2 must be suffer)

Different from Ethereum Layer 2, the bridge of Bitcoin Layer 2 is basically not controlled by the contract on Layer 1, because Bitcoin does not 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 diagram)

This is an unavoidable problem for Bitcoin Layer 2. It can be said that it has 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 you do not consider possible bugs in practice and only consider theoretical models, the security level of Optimistic Bridge and ZK Bridge is basically the highest level. As long as the contract code does not contain bugs or cannot be maliciously upgraded, It’s 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 “multi-signature bridges”. The security of this kind of bridge The reliability depends on how multi-signature/threshold signatures are set up, which requires the introduction of strong trust assumptions: assuming that these notaries will not collude or have their private keys stolen.

At present, most bridges based on notary/threshold signatures cannot be compared with the official “trustless bridge” of Ethereum Layer 2 in terms of security (the premise is that the contract of Ethereum Layer 2 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”. Since the “upgrade rights” of contracts related to the official Ethereum Layer 2 bridge are often concentrated in the hands of a few multi-signature controllers, if the multi-signature controllers collude, there will also be problems with the Ethereum Layer 2 bridge, unless its contract cannot Upgrade, or be 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 escape safely through the forced withdrawal/escape cabin function)

Regarding the “official bridge” part, the trust models of Ethereum Layer 2 and Bitcoin Layer 2 are basically the same: you need to trust that the multi-signature controller will not collude 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 does not maliciously upgrade/the upgrade window is long enough, its official bridge will be trustless, but Bitcoin Layer 2 cannot achieve this effect anyway.

The second shortest link – censorship-resistant forced withdrawals

If we assume that the issue of multi-signature contracts/official bridge control mentioned above can be ignored, that is, there is no problem at this layer, then the next most important layer must be the censorship resistance of withdrawals. Regarding the importance of censorship-resistant forced withdrawal/escape hatch functionality, Vitalik emphasized in his article “Different types of layer 2s” a few months ago that whether the user can successfully withdraw assets from Layer2 to Layer1 is a very important security indicator.

If Layer 2’s sequencer keeps rejecting your transaction requests, or fails/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 very popular in the Ethereum ecosystem, allows anyone to safely withdraw assets to Layer 1 when the DA fails or the fraud proof fails. 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 Layer1. Taking Starknet as an example, if the Forced Withdrawal request submitted by the user on Layer 1 does not receive a response from the Layer 2 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 sequencer 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 directly withdraw money on Layer 1 (actually, they take 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”. However, it is much more convenient to simply declare a “forced withdrawal request” than to directly activate the escape hatch. 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 communicate requests to other Layer2 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: How important are forced withdrawal and escape cabin functions to Layer2）

Currently, there are already Bitcoin Layer 2 teams that plan to imitate Arbitrum’s forced transaction implementation method and allow 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 Sequencers/Proposers who have 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 now) If it is a solution such as sovereign Rollup, where the 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, it is equivalent to realizing decentralized sequencer can solve the anti-censorship problem to a certain extent. But this is only an effective auxiliary means, certainly not the ultimate solution.d

PS: Some current Layer 2 solutions, such as Validium, etc., are not perfect in the design of the escape cabin mechanism. When the sequencer launches a data withholding attack/DA is unavailable, users cannot withdraw money. But this is due to the imperfect design of the Layer 2 escape cabin. Theoretically, the optimal escape hatch withdrawal can rely only on historical data and does not need to rely on the availability of DA/new data.

The third shortest board: the reliability of DA layer data release

Although DA is called data availability, the term actually refers to data release. It is only because Vitalik and Mustafa did not think carefully when they originally named this concept that the name DA/data availability came to be untrue.

Data release, as the name suggests, refers to whether the latest blocks/transaction data/state transition parameters can be successfully received by those in need. Data published on different chains has different reliability.

(Reference:Misunderstanding about data availability: DA = data release ≠ historical data retrieval)

It is generally believed in the Western community that established public chains such as Bitcoin and Ethereum are the most trustworthy DA layers. If the Layer2 sorter publishes new data on Ethereum, anyone who runs the Ethereum geth client can download this data and synchronize it without any hindrance.This is achieved by leveraging the sheer scale of the Ethereum network and the wide variety of public data sources. It is worth mentioning that Ethereum Rollup will force the sequencer to publish transaction data/state transition parameters on Layer1, which is guaranteed through validity proof/fraud proof.

For example, after ZK Rollup’s sequencer publishes transaction data on Layer1, it will trigger the contract logic to generate a datahash, and the validator contract must confirm that the validity certificate submitted by the Proposer has a corresponding relationship with the datahash. This is equivalent to: confirming that the zk Proof and Stateroot submitted by the Proposer are associated with the Tx data submitted by the Sequencer, that is, New Stateroot=STF(Old Stateroot，Txdata). STF is the state transition function. This ensures that the state transition data/DA is forcibly uploaded to the chain. If you only submit the stateroot and validity certificate, you will not be able to pass the verification of the validator contract. As for whether DA data release or proof verification system is more basic, the Ethereum/Celestia community has already had a full discussion. The general conclusion is that the reliability of the DA layer is more important than the completeness of the fraud proof/validity proof system. For example, solutions such as Plasma, Validium, and Optimium, where the DA layer is under the Ethereum chain and the settlement layer is on the Ethereum chain, are prone to encounter “Data Withholding Attack” problems, which means: Sequencer/Proposer can conspire with the DA layer nodes under the ETH chain to update the stateroot on Layer1, but withhold the input parameters corresponding to the state transition and do not send them out, making it impossible for outsiders to judge whether the new stateroot is correct, and become “blind” .

If this happens, the entire Layer 2 network will be scrapped. Because at this time, you have no idea what the Layer 2 ledger has become. If it is Layer 2 (Plasma and Optimium) based on fraud proof, the sorter can rewrite the data/assets under any account at will; if it is Layer 2 (Validium) based on validity proof, although the sorter cannot rewrite your account at will, this At that time, the entire Layer 2 network became a black box. No one knew what happened inside, and it was no different from being scrapped. Because of this, the orthodox Layer 2 solutions in the Ethereum ecosystem are basically Rollup, while Validium and Optimium are often not recognized by the Ethereum Foundation.

(Reference: Data Withholding and Fraud Proof: Why Plasma Doesn’t Support Smart Contracts）

so, the reliability of the DA layer/availability of state transition parameters is more important and fundamental than the completeness of the fraud proof/validity proof system. For Bitcoin Layer 2, especially Layer 2 based on the client verification model, even if there is no fraud proof/validity proof verification system on Layer 1, as long as the DA layer works as usual, everyone can still know whether there is an error in the L2 network. At present, the Bitcoin main network is difficult to verify fraud proof/validity proof (BitVM is not discussed here). Let us first assume that Bitcoin L2 does not have a proof verification system.Ideally,If the L2 sorter really does evil and publishes a stateroot that is not related to DA data on the settlement layer/BTC, it still cannot truly steal user assets because the stateroot/state transition result it unilaterally submits will not be Honest nodes recognize it, but in the end it may just be self-pleasure.（At this time, as long as the nodes run by providers of peripheral facilities in the ecosystem such as exchanges and cross-chain bridges do not collude with the sequencer, the sequencer cannot quickly realize the stolen assets by publishing erroneous data. Afterwards, as long as one honest node discovers that something is wrong and issues an alarm at a critical moment, the error can be corrected through social consensus. However, the cost of social consensus itself is very high and cannot take effect immediately)

If it is a model similar to a side chain, and most nodes conspire to perform malicious state changes, people can quickly discover the problem. As long as third-party facilities such as cross-chain bridges and exchanges do not recognize erroneous data, malicious controllers of Layer 2/side chains will not be able to successfully cash out. Unless he convinces others to directly OTC on the chain with him.

(Viatlik once pointed out in the article that client verification is the real foundation for ensuring the security of the blockchain network, Verify by yourself)

There is a very interesting point here. In fact, both Ethereum Layer 2 and Bitcoin Layer 2 can achieve “client verification”. However, on the basis of “client verification”, Ethereum Layer 2 relies on Layer 1 and the proof verification system to ensure the validity of state transitions and basically does not have to rely on social consensus (provided there is a mature fraud proof/validity proof system). The “client verification” solution of Bitcoin Layer 2 often relies heavily on “social consensus” and will bring corresponding risks.(For Bitcoin Layer 2, this security risk is basically controllable, but it may still cause some people to lose assets. For Ethereum Layer 2, because its official bridge needs to prove the cooperation of the system, if the proof system is not perfect, the order The server can steal user assets and run away on L1. Of course, the details depend on how the cross-chain bridge component is designed). So, a Layer 2 that can implement a fraud proof/validity proof verification system on Layer 1 will always be much better than a simple “client verification” model. PS: Since most Bitcoin Layer 2s that use fraud proof/validity proof systems cannot allow Layer 1 to directly participate in the proof verification process, their essence is still just treating Bitcoin as a DA layer, and the security model is equivalent to “client verification” “. Theoretically, fraud proof can be verified on the Bitcoin chain through the BitVM solution on Layer 1. However, the implementation of this solution is very difficult and will encounter great challenges. Since the Ethereum community has already discussed a lot about the Layer1-based proof and verification system, which is already well known, this article does not intend to go into details about the “Layer1-based proof and verification system”.

Conclusion

After a simple barrel model analysis, we can initially draw a conclusion：In the mainstream Layer 2 security model, according to the degree of importance/basic level, it can be sorted as follows:

1. Whether the control rights of the contract/official bridge are reasonably dispersed

2. Whether there is a censorship-resistant withdrawal function

3. Whether the DA layer/data release form is reliable

4. Whether a reliable fraud proof/validity proof system is deployed on Layer1

Of course, we did not analyze the Lightning Network/State Channel and ICP ecosystem’s ckBTC, Inscription Index Protocol and other solutions, because they are quite different from typical Rollup, Plasma, Validium or client verification solutions. Due to time constraints, it is difficult for us to conduct a prudent assessment of its safety and risk factors, but considering their significance, relevant assessment work will be carried out as scheduled in the future. At the same time, there are serious differences among many project parties as to whether the Inscription Index Protocol should be regarded as Layer 2. However, regardless of the definition of Layer 2, new things such as the Inscription Index Protocol have brought sufficient technological innovation to the Bitcoin ecosystem. And will eventually burst out with great vitality.

Disclaimer：

1. This article is reprinted from [极客web3]. All copyrights belong to the original author [Faust & 雾月，极客web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.