Using the barrel theory to analyze the security model and risk indicators of Bitcoin and Ethereum's Layer 2

Original Title: "Using the Barrel Theory to Analyze the Security Models and Risk Indicators of Bitcoin/Ethereum Layer2"
Original Author: Faust & Misty Moon, Geek Web3 / Advisor: Kevin He(@0xKevinHe), VP of Technology at New Fire Technology

Introduction: American management scholar Lawrence J. Peter proposed the "Barrel Theory," which posits 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 plank. This principle, while simple, is often overlooked. Previous debates on Layer2 security have largely ignored the priorities and importance of different components, focusing mainly on state transition reliability and DA issues, while neglecting more fundamental and important factors. This oversight could undermine the entire theoretical foundation. Therefore, when we discuss complex systems with multiple modules, we must first identify the "shortest plank." Inspired by the Barrel Theory, our systematic analysis revealed that there are clear dependencies among different components in the Bitcoin/Ethereum Layer2 security models, meaning that the security of certain components is more fundamental and important than others, referred to as "shorter." Accordingly, we can preliminarily rank the importance/fundamentality of different components in mainstream Layer2 security models as follows:

1. Whether the control rights of contracts/official bridges are reasonably decentralized (how concentrated is the multi-signature control)

2. Whether there is an anti-censorship withdrawal function (forced withdrawal, escape hatch)

3. Whether the DA layer/data publication method is reliable (is DA data published on Bitcoin or Ethereum)

4. Whether a reliable fraud proof/validity proof system is deployed on Layer1 (Bitcoin L2 needs to rely on BitVM)

I Moderately Absorb the Ethereum Community's Research on Layer2 to Avoid Lysenkoism

Compared to the highly organized Ethereum Layer2 system, Bitcoin Layer2 is like a brand new world. This new concept, which has become increasingly important after the inscription craze, shows signs of rising, yet its ecosystem is becoming increasingly chaotic and approaching disorder. Various Layer2 projects are emerging like bamboo shoots after a rain. While they bring hope to the Bitcoin ecosystem, they deliberately conceal their own security risks, and some have even claimed to "deny Ethereum Layer2 and take a unique path in the Bitcoin ecosystem," showing a tendency towards extremism.

Considering the functional differences between Bitcoin and Ethereum, Bitcoin Layer2 is destined to not align with Ethereum Layer2 in its early stages, but this does not mean we should completely deny the industry knowledge that has long been established in Ethereum and the modular blockchain space (referencing the "Lysenko Affair," where Soviet biologist Trofim Lysenko persecuted Western geneticists over ideological issues).

On the contrary, the evaluation standards achieved through the immense efforts of "predecessors," once widely recognized, have demonstrated strong persuasive power. Deliberately denying the value of these achievements is not a rational act.

While building Bitcoin Layer2, we should fully recognize the significance of "learning from the West" and moderately absorb and optimize many conclusions from the Ethereum community. However, when referencing viewpoints outside the Bitcoin ecosystem, we must be aware of the differences in their starting points and ultimately strive for common ground while reserving differences.

This is akin to discussing the similarities and differences between "Westerners" and "Easterners." Regardless of whether they are Western or Eastern, the suffix "people" expresses many similar characteristics; it is just that when corresponding to the different prefixes "Western" and "Eastern," there will be differences in specific characteristics. But fundamentally, there is bound to be overlap between "Westerners" and "Easterners," which means that many things applicable to Westerners are also applicable to Easterners, and many things applicable to "Ethereum Layer2" are also applicable to "Bitcoin Layer2."

Before distinguishing the differences between Bitcoin L2 and Ethereum L2, it may be more important and meaningful to clarify the commonalities between the two.

Adhering to the principle of "seeking common ground while reserving differences," the author of this article does not intend to discuss "what is Bitcoin Layer2 and what is not," as this topic is highly controversial, and even the Ethereum community has not reached an objective consensus on "which are Ethereum Layer2 and which are not Layer2."

However, it is certain that different technical solutions bring varying scaling effects to Bitcoin, and their security risks differ. The trust assumptions present in their security models will be the focus of this article.

How to Understand the Security and Evaluation Criteria of Layer2

In fact, the security of Layer2 is not a new discussion point. Even the term "security" is a compound concept that encompasses multiple sub-properties.

Previously, EigenLayer's founder simply subdivided "security" into four elements: "transaction irreversibility (rollback resistance), anti-censorship, DA/data publication reliability, and state transition validity."

(The founder of EigenLayer expressed views on how client validation/sovereign Rollup solutions inherit the security of the Bitcoin mainnet)

L2BEAT and Ethereum community OGs have proposed a relatively systematic Layer2 risk assessment model, of course, these conclusions pertain to smart contract-based Layer2, rather than sovereign Rollups, client validation, and other typical non-smart contract-based Layer2.

Although this may not be 100% applicable to Bitcoin L2, it still contains many commendable conclusions, most of which have been widely recognized in the Western community, making it easier for us to objectively assess the risks of different Bitcoin L2 solutions.

(Vitalik once stated that since Rollup solutions cannot achieve theoretical perfection at the early stages, they must rely on auxiliary means to enhance security, which are referred to as "auxiliary wheels," and will introduce trust assumptions. These trust assumptions are the risks.)

So where do security risks come from? Considering that currently, whether it is Ethereum Layer2 or Bitcoin Layer2, many rely on centralized nodes to act as sorters, or consist of a "committee" formed by a few nodes, these increasingly centralized sorters/committees, if left unchecked, can steal user assets and run away at any time, or refuse user transaction requests, leading to assets being frozen and unusable. This involves the state transition validity and anti-censorship mentioned earlier by the founder of EigenLayer.

At the same time, since Ethereum Layer2 relies on contracts on the ETH chain for state transition validation and deposit/withdrawal behavior verification, if the contract controllers (essentially the Layer2 officials) can quickly update the contract logic and insert malicious code segments (for example, allowing a specified address to transfer all tokens locked in the L1-L2 deposit/withdrawal contract), they can directly steal the custodial assets. This is categorized as the "contract multi-signature allocation problem," and the multi-signature allocation problem is equally applicable to Bitcoin Layer2, as Bitcoin Layer2 often relies on "notary bridges," requiring multiple nodes to release cross-chain requests through multi-signature, so Bitcoin Layer2 also faces the issue of how to reasonably allocate multi-signatures, which we can even consider as the most fundamental "auxiliary wheel" of Bitcoin Layer2.

In addition, the DA issue is also extremely important. If Layer2 does not upload data to Layer1 and instead chooses some unreliable DA publication venues, if this off-chain DA layer (commonly referred to as DAC data availability committee) colludes and refuses to publish the latest transaction data, data withholding attacks will lead to network failure and may prevent users from successfully withdrawing.

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

1. Is the state validation/proof system reliable? (State Validation)

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

3. If the Layer2 network deliberately refuses your transaction/stops, can you forcibly withdraw assets from Layer2? (Sequencer Failure, Proposer Failure)

4. Is the control of Layer2-related contracts - official cross-chain bridges sufficiently decentralized? If power is concentrated, can users have enough time to respond in the event of "insider theft"? (Exit Window)

(L2BEAT's "Risk Factor Display" for different Layer2 projects)

Anyway, when we analyze Layer2 security risks, we are essentially discussing how many scenarios exist within the Layer2 network that could lead to user asset damage, and whether the Layer2 system can effectively constrain these dangerous situations through mechanism design. If certain malicious behaviors cannot be eliminated, to what extent do we need to introduce "trust," how many individuals in a group do we need to trust, and how many "auxiliary wheels" do we need to rely on.

In the following text, we will analyze the risk factors present in the general Ethereum Layer2/Bitcoin Layer2 models (the subjects discussed in this article do not include "state channels" or "payment channels," nor do they include inscription indexing protocols, as they are relatively special). We will also attempt to explore which factors are more fundamental, lower-level, and important in the Layer2 security model; these more fundamental shortcomings will be trust risks that deserve more attention than other shortcomings.

The Barrel Effect of Layer2 ------ What are the Shortcomings

The Shortest Plank ------ Control Rights of Contracts/Official Bridges

Here, we can analyze the Layer2 security issue using the "Barrel Effect," and it is easy to see that the shortest plank is the "upgradability of contracts" (mainly concerning Ethereum Layer2), or more specifically, the "management rights of official cross-chain bridges" (applicable to both Bitcoin and Ethereum Layer2).

For Ethereum Layer2, as long as the Layer2 officials can quickly upgrade contracts on Layer1, theoretically, they can steal the tokens locked in the L2 official bridge's deposit/withdrawal address, regardless of how reliable its DA layer or proof system is.

It can be said that the control rights of bridging contracts are crucial to the safety of the entire system; they are the most fundamental and critical part of the entire Layer2 and modular blockchain stack. If the bridging components/contracts can be updated and iterated under multi-signature control, we must introduce a "trust assumption" here, assuming that the controllers of the Layer2 contracts/official bridges will not act maliciously.

(L2BEAT marks the upgrade delays of different Layer2 project contracts; most L2 contracts can be immediately upgraded by the controllers. If the contract controllers want to steal assets, or if their private keys are hacked, the user assets held in L2 will inevitably suffer.)

Unlike Ethereum Layer2, the bridges of Bitcoin Layer2 are generally not controlled by contracts on Layer1, as Bitcoin does not support smart contracts. In contrast, the entire workflow of Ethereum Layer2 heavily relies on contracts on Layer1, which Bitcoin Layer2 cannot do.

(Starknet Principle Diagram)

This is an unavoidable issue for Bitcoin Layer2, which can be seen as both beneficial and detrimental. Currently, it seems that the "trustless bridge" implemented by Ethereum Layer2 through contracts cannot be realized on Bitcoin L2. This "Trustless Bridge" requires deploying dedicated contracts on Layer1, along with the cooperation of DA + fraud proof/ZK proof systems, essentially similar to Orbiter's "optimistic bridge" or Polyhedra's ZK bridge.

The mainstream view in the industry is that, if we do not consider potential bugs in practice and only consider theoretical models, the security levels of optimistic bridges and ZK bridges are generally the highest, as long as the contract code does not contain bugs or cannot be maliciously upgraded, they are essentially trustless.

(An optimistic bridge only needs to ensure that among N watchers, if 1 is honest, security is guaranteed; the trust model is 1/N.)

Since Bitcoin Layer2 cannot deploy contract components on Layer1 (not discussing the Lightning Network here), its official bridges are basically "notary bridges" composed of a few nodes, or "multi-signature bridges." The security of such bridges depends on the setup of multi-signature/threshold signatures, requiring strong trust assumptions: assuming that these notaries will not collude or have their private keys stolen.

Currently, most bridges based on notaries/threshold signatures cannot compare in security with Ethereum Layer2's official "trustless bridges" (provided that the contracts of Ethereum Layer2 do not undergo malicious upgrades). Clearly, the security of assets hosted on the Bitcoin Layer2 network will be constrained by the security of its official bridges, or the degree of power decentralization of the multi-signature bridge, which is the first "auxiliary wheel."

Since the "upgrade permissions" of contracts related to Ethereum Layer2's official bridges are often concentrated in the hands of a few multi-signature controllers, if the multi-signature controllers collude, the bridge of Ethereum Layer2 will also encounter problems, unless its contracts are non-upgradable or subject to a long delay (currently only Degate and Fuel V1 are like this).

(Degate reserves a 30-day safety escape period for users during each contract upgrade; if users discover malicious logic in the new contract code during this period, they can safely escape through the forced withdrawal/escape hatch function.)

Regarding the "official bridge," the trust model of Ethereum Layer2 and Bitcoin Layer2 is essentially the same: it requires trusting that the multi-signature controllers will not collude maliciously. This group of multi-signatures can control the L2 official bridge, either changing its code logic or directly allowing invalid withdrawal requests, resulting in user assets potentially being stolen.

The only difference between the two is that as long as the contracts of Ethereum Layer2 do not undergo malicious upgrades or the upgrade window is long enough, its official bridge is trustless, but Bitcoin Layer2 can never achieve this effect.

The Second Shortest Plank ------ Anti-Censorship Forced Withdrawal

If we assume that the issues regarding contract multi-signature/official bridge control rights can be ignored, meaning that there are no problems at this level, then the next most important layer must be the anti-censorship of withdrawal actions.

Regarding the importance of the anti-censorship forced withdrawal/escape hatch function, Vitalik emphasized in his article "Different Types of Layer 2s" a few months ago that whether users can smoothly withdraw assets from Layer2 to Layer1 is a very important security indicator.

If the Layer2 sorter continuously refuses your transaction requests or experiences long-term failures/downtime, your assets will be "frozen," and you will be unable to do anything. Even if the DA and fraud proof/ZK proof systems are available, without an anti-censorship solution, such a Layer2 is not secure enough and can hold your assets at any time.

Moreover, the Plasma solution, which was once very popular in the Ethereum ecosystem, allowed anyone to safely withdraw assets to Layer1 in the event of DA failure or fraud proof failure. At that point, the entire Layer2 network would essentially be rendered useless, but your assets would still have a way to escape. Clearly, the anti-censorship withdrawal function is more fundamental and lower-level than the DA and proof systems.

(Dankrad from the Ethereum Foundation stated that Plasma allows users to safely withdraw assets even when DA fails or users cannot sync the latest data.)

Some Ethereum Layer2 solutions, such as Loopring, StarkEx, dYdX, and Degate, establish an anti-censorship forced withdrawal/escape hatch activation function on Layer1. For example, in Starknet, if a user submits a Forced Withdrawal request on Layer1 and does not receive a response from the Layer2 sorter by the end of the 7-day window, they can manually call the freeze Request function to freeze L2 and activate escape hatch mode.

At this point, the sorter cannot submit data to the Rollup contract on L1, and the entire Layer2 will freeze for a year. Then, users can submit a Merkle proof to prove their asset status on Layer2 and withdraw directly on Layer1 (essentially taking their equivalent funds from the official bridge's deposit/withdrawal address).

Clearly, the escape hatch mode can only be implemented on chains like Ethereum that support smart contracts; Bitcoin cannot run such complex logic. In other words, the escape hatch function is essentially a patent of Ethereum Layer2, while Bitcoin Layer2 must rely on some additional auxiliary means to mimic it, which is the second "auxiliary wheel."

However, simply declaring a "forced withdrawal request" is much easier than directly activating the escape hatch. The former only requires users to submit a transaction to a specified address on Layer1 and declare the data they want to submit to all Layer2 nodes in the transaction's additional data (thus bypassing the sorter and conveying the request to other Layer2 nodes). If the "forced withdrawal" does not receive a response for an extended period, users can then trigger the escape hatch mode, which is a reasonable design.

Currently, some Bitcoin Layer2 teams plan to mimic Arbitrum's forced transaction implementation method, allowing users to publish forced transaction declarations (Forced Transaction Envelopes) on the Bitcoin chain. Under this scheme, users can bypass the sorter and directly convey their requests to other Layer2 nodes. If the sorter continues to refuse the user's request after seeing the forced transaction declaration, it will be noticed by other Layer2 nodes and may face penalties.

However, the problem is that Arbitrum's forced transaction function benefits from its fraud proof system, which can penalize the Sequencer/Proposer that continuously ignores user transactions. But for Bitcoin Layer2, which finds it challenging to verify fraud proofs on Layer1 (not discussing BitVM here), it will encounter certain challenges in this regard. (Not discussing sovereign Rollups, which have a security level not much different from client validation, we find it difficult to seriously assess their reliability and may need to evaluate the implementation details of different projects.)

Of course, given that many Bitcoin Layer2 solutions currently operate in a manner similar to sidechains, effectively achieving decentralized sorting, they can somewhat address the anti-censorship issue. However, this is merely an effective auxiliary means and certainly not a final solution.

PS: Some current Layer2 solutions, such as Validium, do not have a well-designed escape hatch mechanism; when the sorter launches a data withholding attack or DA is unavailable, users may be unable to withdraw. However, this is attributed to the inadequacies in the design of Layer2 escape hatches. Theoretically, the optimal escape hatch withdrawal can rely solely on historical data without needing to depend on the availability of DA/new data.)

The Third Shortest Plank: Reliability of DA Layer Data Publication

Although DA is referred to as data availability, this term actually refers to data publication. It is simply because Vitalik and Mustafa did not think deeply when they initially named this concept, leading to the misleading term DA/data availability.

Data publication, as the name implies, refers to whether the latest block/transaction data/state transition parameters can be smoothly received by those in need. The reliability of data published on different chains varies.

The Western community generally believes that established public chains like Bitcoin and Ethereum are the most trustless DA layers. If the Layer2 sorter publishes new data on Ethereum, anyone running the Ethereum geth client can download this data and synchronize it with almost no obstruction, thanks to the vast scale of the Ethereum network and numerous public data sources.

It is worth mentioning that Ethereum Rollups require sorters to publish transaction data/state transition parameters on Layer1, which is ensured through validity proofs/fraud proofs.

For example, after the ZK Rollup sorter publishes transaction data on Layer1, it triggers contract logic to generate a data hash, and the validator contract must confirm that the validity proof submitted by the Proposer corresponds to the data hash.

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, i.e., New Stateroot = STF(Old Stateroot, Txdata). STF is the state transition function.

This ensures that state transition data/DA is forcibly on-chain. If only the stateroot and validity proof are submitted, they cannot pass verification by the validator contract.

Regarding whether the reliability of DA data publication or the completeness of the proof verification system is more fundamental, the Ethereum/Celestia community has long discussed this, and 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, Plasma, Validium, Optimium, and similar solutions—where the DA layer is off-chain on Ethereum and the settlement layer is on Ethereum—are prone to "data withholding attacks," which refer to:

Sequencers/Proposers can collude with DA layer nodes off the ETH chain to update the stateroot on Layer1 while withholding the input parameters corresponding to the state transition, preventing outsiders from determining whether the new stateroot is correct, rendering them "blind."

If this situation occurs, the entire Layer2 network is essentially rendered useless because at that point, you have no idea what the Layer2 ledger has become. If it is a Layer2 based on fraud proofs (Plasma and Optimium), the sorter can arbitrarily rewrite data/assets under any account; if it is a Layer2 based on validity proofs (Validium), although the sorter cannot freely rewrite your account, the entire Layer2 network becomes a black box, and no one knows what is happening inside, which is no different from being rendered useless. For this reason, the orthodox Layer2 solutions within the Ethereum ecosystem are basically Rollups, while Validium and Optimium are often not recognized by the Ethereum Foundation.

Thus, the reliability of the DA layer/state transition parameter availability is more important and fundamental than the completeness of the fraud proof/validity proof system. For Bitcoin Layer2, especially those based on client validation models, even without a fraud proof/validity proof verification system set up on Layer1, as long as the DA layer is functioning normally, everyone can still know whether the L2 network has experienced erroneous state transitions.

Currently, it is difficult to verify fraud proofs/validity proofs on the Bitcoin mainnet (not discussing BitVM here), so let us assume that Bitcoin L2 does not have a proof verification system. In an ideal state, if the L2 sorter truly acts maliciously and publishes a stateroot on the settlement layer/BTC that is unrelated to DA data, it still cannot genuinely steal user assets because the stateroot/state transition results it submits unilaterally will not be recognized by honest nodes, and in the end, it may just be self-indulgent.

(At this point, as long as the nodes operated by surrounding facilities within the ecosystem, such as exchanges and cross-chain bridges, do not collude with the sorter, the sorter cannot quickly liquidate stolen assets by publishing erroneous data. Subsequently, as long as there is 1 honest node that discovers something is wrong and issues an alarm at a critical moment, social consensus can correct the error. However, the cost of social consensus itself is high and cannot take effect immediately.)

If it is a model similar to a sidechain, where most nodes collude to execute malicious state changes, people can also quickly discover the problem. As long as third-party facilities like cross-chain bridges and exchanges do not recognize erroneous data, malicious controllers of Layer2/sidechains cannot successfully cash out unless they persuade others to conduct direct OTC with them on-chain.

(Vitalik once pointed out in an article that client validation is the true foundation for ensuring the security of blockchain networks; Verify by yourself.)

Here is an interesting point: in fact, both Ethereum Layer2 and Bitcoin Layer2 can achieve "client validation." However, Ethereum Layer2, based on "client validation," uses Layer1 and proof verification systems to ensure the validity of state transitions, essentially not relying on social consensus (provided that there is a mature fraud proof/validity proof system).

On the other hand, Bitcoin Layer2's "client validation" solutions often have a strong reliance on "social consensus," which brings corresponding risks (for Bitcoin Layer2, this security risk is generally controllable but may still lead to some individuals losing assets. For Ethereum Layer2, since its official bridge requires the cooperation of proof systems, if the proof system is not perfect, the sorter can steal user assets and run away to L1. Of course, it depends on how the cross-chain bridge component is designed.)

Therefore, a Layer2 that can implement fraud proof/validity proof verification systems on Layer1 will always be much better than a purely "client validation" model.

PS: Since most Bitcoin Layer2 solutions that adopt fraud proof/validity proof systems cannot allow Layer1 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 validation."

Theoretically, through the BitVM solution on Layer1, fraud proofs can be verified on the Bitcoin chain, but this solution faces significant challenges in terms of engineering implementation. Given that the Ethereum community has already conducted extensive discussions on proof verification systems based on Layer1, which are well-known, this article will not elaborate on "Layer1-based proof verification systems." Summary

Summary

Through a simple analysis using the barrel model, we can preliminarily conclude that in mainstream Layer2 security models, based on importance/fundamentality, the following ranking can be made:

1. Whether the control rights of contracts/official bridges are reasonably decentralized

2. Whether there is an anti-censorship withdrawal function

3. Whether the DA layer/data publication method is reliable

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

Of course, we have not analyzed the Lightning Network/state channels and ICP ecosystem's ckBTC, inscription indexing protocols, and other solutions, as they differ significantly from typical Rollup, Plasma, Validium, or client validation solutions. Due to time constraints, we are also unable to conduct a prudent assessment of their security and risk factors, but considering their significant implications, related evaluation work will certainly be carried out in due course.

At the same time, there are serious disagreements among many project parties regarding whether the inscription indexing protocol should be considered Layer2. Regardless of the definition of Layer2, new things like the inscription indexing protocol have brought significant technological innovation to the Bitcoin ecosystem and will ultimately unleash tremendous vitality.