While building Bitcoin Layer2, we should fully recognize the meaning of “learning from the West and applying it to the East” and appropriately absorb and optimize many conclusions from the Ethereum community. However, when considering perspectives outside of the Bitcoin ecosystem, we need to be aware of the differences in their starting points and ultimately seek common ground while preserving differences.
In this article, we should moderately absorb the research achievements of the Ethereum community on Layer2 and avoid dogmatism. We should understand the security and evaluation criteria of Layer2 and identify the weaknesses in the system. We should also consider the management rights of contracts/official bridges as the shortest board, followed by censorship-resistant forced withdrawals as the second shortest board, and the reliability of data release in the DA layer as the third shortest board.
Lawrence Peter, an American management scientist, proposed the “barrel theory,” which states that the overall efficiency of a system is limited by its weakest part. In other words, the amount of water a barrel can hold is determined by its shortest plank. This principle, although simple, is often overlooked. Previous debates on the security of Layer2 mostly ignored the priority and importance of different components and focused on the reliability of state transitions and DA issues. However, they neglected the more fundamental and important factors, which may undermine the entire theoretical foundation. Therefore, when discussing complex systems with multiple modules, we need to identify the “shortest plank” first.
Inspired by the barrel theory, after conducting a system analysis, we found that there are clear dependency relationships between different components in the security model of Bitcoin/Ethereum Layer2. Some components have a more fundamental and important security than others, which can be considered as “shorter” components.
In this regard, we can preliminarily prioritize and rank the importance/foundation of different components in mainstream Layer2 security models as follows:
1. Whether the control rights of contracts/official bridges are reasonably decentralized (how centralized the multi-signature control rights are)
2. Whether there is censorship-resistant withdrawal functionality (forced withdrawal, escape hatch)
3. Whether the DA layer/data release form is reliable (whether DA data is released on Bitcoin/Ethereum)
4. Whether a reliable fraud proof/validity proof system is deployed on Layer1 (Bitcoin L2 requires BitVM for this)
Compared to the highly organized Ethereum Layer2 system, Bitcoin Layer2 is like a new world. This new concept, which has become increasingly important after the wave of inscriptions, shows a rising trend, but its ecosystem is becoming increasingly chaotic and chaotic. Various Layer2 projects have emerged one after another, like mushrooms after rain. While bringing hope to the Bitcoin ecosystem, they deliberately conceal their own security risks. Some even claim to “reject Ethereum Layer2 and follow a unique path” in a trend of extremism.
Considering the differences in functional attributes between Bitcoin and Ethereum, it is inevitable that Bitcoin Layer2 cannot align with Ethereum Layer2 in the early stage. However, this does not mean that we should completely reject Ethereum and even the industry consensus that has long been formed in the modular blockchain field (referring to the Lysenko affair by the former Soviet biologist, which persecuted supporters of Western genetics due to ideological issues).
On the contrary, these evaluation criteria that have been widely recognized after extensive efforts by “predecessors” have already demonstrated strong persuasiveness. It is not a rational move to deliberately deny the value of these achievements. While building Bitcoin Layer2, we should fully recognize the meaning of “learning from the West and applying it to the East” and appropriately absorb and optimize many conclusions from the Ethereum community. However, when considering perspectives outside of the Bitcoin ecosystem, we need to be aware of the differences in their starting points and ultimately seek common ground while preserving differences.
This is like discussing the similarities and differences between “Westerners” and “Easterners.” Whether Western or Eastern, the suffix “people” expresses many similar characteristics, but they have different characteristics when corresponding to “Western” and “Eastern” as prefixes.
But ultimately, there is an overlap between “Westerners” and “Easterners,” which means that many things applicable to Westerners are also applicable to Easterners. Many things applicable to “Ethereum Layer2” are also applicable to “Bitcoin Layer2.” Before distinguishing the differences between Bitcoin L2 and Ethereum L2, it is more important and meaningful to first clarify the commonalities between them.
Based on the principle of “seeking common ground while preserving 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 a consensus on “what is Ethereum Layer2 and what is not Layer2.” However, it can be affirmed that different technical solutions bring different scalability effects to Bitcoin, and they have different security risks and trust assumptions in their security models. These trust assumptions will be the main topic of discussion in this article.
In fact, the security of Layer2 is not a new topic. Even the term “security” is a complex concept that includes multiple attributes.
Previously, the founder of EigenLayer divided “security” into four elements: irreversibility of transactions (anti-rollbacks), censorship resistance, reliability of DA/data release, and validity of state transitions. L2BEAT and the Ethereum community OG have also proposed a risk assessment model for comparing Layer2 systems. Of course, these conclusions are applicable to smart contract-based Layer2, not typical non-smart contract-based Layer2 such as sovereign rollups and client verification.
Although this may not be 100% suitable for Bitcoin L2, it still includes many positive conclusions. Most of these viewpoints have been widely recognized in the Western community, making it easier for us to objectively assess the risks of different Bitcoin L2 solutions.
So where do security risks come from? Considering that both Ethereum Layer2 and Bitcoin Layer2 currently rely on centralized nodes to act as sorters or committees composed of a few nodes, these increasingly centralized sorters/committees can steal user assets and run away at any time. They can also reject user transaction requests, leading to frozen assets that cannot be used. This involves the previously mentioned issues of the validity of state transitions and censorship resistance.
At the same time, since Ethereum Layer2 relies on contracts on the ETH chain for state transition verification and deposit/withdrawal verification, if the contract controller (which is essentially the Layer2 official) can quickly update the contract logic and include malicious code (such as allowing a specified address to transfer all locked tokens on the L1-L2 deposit/withdrawal contract), they can directly steal the entrusted assets. This is referred to as the “multi-signature allocation problem,” which also applies to Bitcoin Layer2. Since Bitcoin Layer2 often relies on “notary bridges,” which require multiple nodes to approve cross-chain requests through multi-signatures, Bitcoin Layer2 also faces the problem of how to reasonably allocate multi-signatures, which can be seen as the most fundamental “auxiliary wheel” in Bitcoin Layer2.
In addition, the reliability of DA is also crucial. If Layer2 does not upload data to Layer1 and instead uses unreliable DA release platforms, if the off-chain DA layer (generally referred to as the DAC data availability committee) conspires and refuses to publish the latest transaction data, data withholding attacks will render the network useless and may prevent users from withdrawing smoothly. L2BEAT has summarized these issues and identified several core elements in Layer2 security models:
– Reliability of state validation/proof system
– Reliability of DA/data release
– Whether you can forcibly withdraw assets from Layer2 if the network intentionally rejects your transactions/shuts down (Sequencer Failure, Proposer Failure)
– Layer2-related contracts: decentralization of control rights of official cross-chain bridges. If power is more centralized and “self-theft” occurs, will users have enough time to respond during the exit window?
Anyway, when we analyze Layer2 security risks, we are actually discussing the scenarios in which the Layer2 network’s memory could potentially damage user assets. For these dangerous situations, can the Layer2 system effectively constrain them through mechanism design? If certain malicious behaviors are unavoidable, to what extent do we need to introduce “trust”? How many individuals in a group do we need to trust? How much do we rely on “auxiliary wheels”?
In the following text, we will analyze the risk factors in the general Ethereum Layer2/Bitcoin Layer2 models (excluding “state channels” or “payment channels” and inscription indexing protocols because they are more specific). We will try to explore which factors are more fundamental, foundational, and important in the Layer2 security model. These more fundamental weaknesses should be given more attention in terms of trust risks than other weaknesses.
Here, we can analyze the Layer2 security issues using the “barrel effect.” It is easy to see that the shortest plank mentioned earlier, “contract upgradability” (mainly for Ethereum Layer2), or more specifically, “management rights of official cross-chain bridges” (applicable to both Bitcoin and Ethereum Layer2), is the most basic and critical part of the entire Layer2 and modular blockchain stack. If the bridge component/contract can be iteratively updated under multi-signature control, we need to introduce a “trust assumption” here, assuming that the controller of the Layer2 contract/official bridge will not act maliciously.
Unlike Ethereum Layer2, Bitcoin Layer2 bridges are not controlled by contracts on Layer1 since Bitcoin does not support smart contracts. Relatively speaking, Ethereum Layer2’s entire workflow is highly dependent on contracts on Layer1, while Bitcoin Layer2 cannot do this.
For Bitcoin Layer2, this is an unavoidable problem. It can be said to have both advantages and disadvantages. Currently, it seems that Ethereum Layer2’s “trustless bridge” implemented by contracts cannot be achieved in Bitcoin Layer2. This “trustless bridge” requires dedicated contracts to be deployed on Layer1 and also relies on DA + fraud proofs/ZK proofs. It is essentially similar to optimistic bridges like Orbiter or ZK bridges like Polyhedra.
The mainstream view in the industry is that if we only consider the theoretical model without taking into account potential bugs in practice, optimistic bridges and ZK bridges have the highest level of security. As long as the contract code does not contain bugs or cannot be maliciously upgraded, they are essentially trustless.
Since Bitcoin Layer2 cannot deploy contract components on Layer1 (excluding the Lightning Network here), its official bridges are mostly “notary bridges” composed of a few nodes or “multi-signature bridges.” The security of such bridges depends on the configuration of multi-signatures/threshold signatures and requires stronger trust assumptions: assuming that these notaries will not collude or have their private keys stolen.
Currently, most bridges based on notaries/threshold signatures cannot be compared with Ethereum Layer2’s official “trustless bridge” in terms of security (assuming that Ethereum Layer2 contracts do not undergo malicious upgrades). It is apparent that the security of assets entrusted to the Bitcoin Layer2 network will be limited by the security of its official bridges or, in other words, by the decentralization of multi-signature bridges, which is the first “auxiliary wheel.”
Since the control rights of Ethereum Layer2’s official bridge-related contracts are often concentrated in the hands of a few multi-signature controllers, if these multi-signature controllers conspire, Ethereum Layer2’s bridge will also have issues unless its contracts cannot be upgraded or are subject to long delays (currently, only Degate and Fuel V1 have this feature).
Regarding the “official bridge” part, both Ethereum Layer2 and Bitcoin Layer2 rely on the security of their official bridges. Ethereum Layer2’s workflow heavily relies on contracts on Layer1, while Bitcoin Layer2 cannot do this. Therefore, the security of Bitcoin Layer2 networks will be constrained by the security of their official bridges or, in other words, by the decentralization of multi-signature bridges. This is the first “auxiliary wheel” for Bitcoin Layer2.
The trust model of Layer2 is generally consistent: the trusted multisig controllers will not conspire to commit wrongdoing. This group of multisigs can control the official bridge of L2, either by modifying its code logic or directly allowing invalid withdrawal requests, and the ultimate result is that user assets may be stolen.
The only difference between the two is that Ethereum Layer2 only needs the contract to not maliciously upgrade or have a long enough upgrade window, and its official bridge can be trusted. However, Bitcoin Layer2 cannot achieve this effect no matter what.
If we assume that the issue of contract multisig/official bridge control rights mentioned in the previous text can be ignored, that is, there is no problem at this layer, then the next most important layer is undoubtedly the censorship resistance of withdrawals.
Regarding the importance of censorship-resistant forced withdrawals/escape hatch functionality, 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 sequencer of Layer2 keeps rejecting your transaction requests or experiences long-term malfunctions or crashes, your assets will be “frozen” and you won’t be able to do anything. Even if DA and fraud-proof/ZK proof systems are available, such Layer2 is not secure enough without censorship resistance, and your assets can be seized at any time.
Moreover, the once popular Plasma solution in the Ethereum ecosystem allowed anyone to withdraw their assets to Layer1 when DA fails or fraud proofs fail. At this time, the entire Layer2 network is basically scrapped, but you can still escape with your assets. Clearly, censorship-resistant withdrawal functionality is more fundamental and foundational than DA and proof systems.
Some Ethereum Layer2 solutions, such as Loopring, StarkEx, dYdX, Degate, etc., will establish a censorship-resistant forced withdrawal/escape hatch activation function on Layer1. Taking Starknet as an example, if a user submits a Forced Withdrawal request on Layer1 and does not receive a response from the Layer2 sequencer after the 7-day window period ends, they can manually call the freeze Request function to freeze L2 and activate the escape hatch mode.
At this time, the sequencer cannot submit data to the Rollup contract on L1, and the entire Layer2 will be frozen for a year. Then, users can submit merkle proofs to prove the state of their assets on Layer2 and directly withdraw them on Layer1 (actually taking their equivalent funds from the deposit/withdrawal addresses of the official bridge).
Clearly, the escape hatch mode can only be implemented on chains that support smart contracts, such as Ethereum, and cannot be executed with such complex logic on Bitcoin. In other words, the escape hatch functionality is basically the patent of Ethereum Layer2, and Bitcoin Layer2 needs to rely on some additional auxiliary means to imitate it, which is the second “auxiliary wheel”.
However, it is much more convenient to simply declare “forced withdrawal requests” than to directly activate the escape hatch. The former only requires users to submit a transaction to a designated address on Layer1 and declare in the transaction’s additional data the data they want to submit to all Layer2 nodes (this can directly bypass the sequencer and convey the request to other Layer2 nodes). If the “forced withdrawal” request does not receive a response for a long time, users can trigger the escape hatch mode, which is a more reasonable design.
Currently, there are Bitcoin Layer2 teams planning to imitate Arbitrum’s implementation method of forced transactions, allowing users to release forced transaction declarations on the Bitcoin chain (Forced Transaction Envelopes). Under this scheme, users can bypass the sequencer and directly convey their requests to other Layer2 nodes. If the sequencer still rejects their requests after seeing the user’s forced transaction declaration, it will be noticed by other Layer2 nodes and may be punished.
But the problem is that Arbitrum’s forced transaction functionality benefits from its fraud-proof system, which can penalize the Sequencer/Proposer who ignores user transactions. However, for Bitcoin Layer2, which is difficult to verify fraud proofs/validity proofs on Layer1, it will face certain challenges in this regard. (BitVM is not discussed here for now.) If it is a security level and client verification scheme like the sovereign Rollup, it is difficult to seriously evaluate its reliability, and specific evaluations need to be conducted based on the implementation details of different projects.
Of course, given that many Bitcoin Layer2 solutions operate in a similar manner to sidechains, implementing a decentralized sequencer, they can to some extent solve the problem of censorship resistance. But this is only an effective auxiliary means and is certainly not the ultimate solution.
PS: Some Layer2 solutions on Ethereum, such as Validium, have imperfect mechanisms for escape hatches, and if the sequencer launches data withholding attacks or the DA is unavailable, users may be unable to withdraw funds. But this is due to the imperfect design of the Layer2 escape hatch. Theoretically, the optimal escape hatch withdrawal should only rely on historical data and not depend on the availability of DA/new data.
Although DA is called data availability, it actually refers to data release. It is just because Vitalik and Mustafa did not think deeply when naming this concept that we have the misleading term “DA/data availability.”
Data release, as the name suggests, refers to whether the latest block/transaction data/state transition parameters can be successfully received by those in need. The reliability of data release varies on different chains.
The Western community generally believes that established public chains like Bitcoin and Ethereum are the most trustworthy DA layers. If the Layer2 sequencer releases new data on Ethereum, anyone who runs an Ethereum geth client can download this data and synchronize it without much obstruction, thanks to the huge scale of the Ethereum network and numerous public data sources.
It is worth mentioning that Ethereum Rollup requires the sequencer to release transaction data/state transition parameters on Layer1, which is ensured by validity proofs/fraud proofs.
For example, in ZK Rollup, after the sequencer releases transaction data on Layer1, it triggers the contract logic to generate a datahash, and the validator contract needs to confirm that the validity proof and datahash submitted by the Proposer correspond. This is equivalent to confirming that the zk proof and stateroot submitted by the Proposer are associated with the Tx data, that is, New Stateroot = STF (Old Stateroot, Txdata). STF stands for state transition function.
This ensures that state transition data/DA is forcefully uploaded. If only stateroot and validity proofs are submitted, they will fail to pass the verification of the validator contract.
Regarding whether data availability or proof verification systems are more fundamental, Ethereum and Celestia communities have already had sufficient discussions, and the general conclusion is that the reliability of the DA layer is more important than the completeness of fraud proofs/validity proofs. For example, solutions like Plasma, Validium, and Optimium—DA layers below the Ethereum chain and settlement layers above the Ethereum chain—are prone to “data withholding attacks.” This refers to the collusion between the Sequencer/Proposer and the DA layer nodes on ETH, where the Sequencer can update the stateroot on Layer1 but withhold the corresponding input parameters for state transition, making it impossible for outsiders to judge whether the new stateroot is correct, resulting in a “blind spot.”
If this happens, the entire Layer2 network is essentially scrapped because in this case, you have no idea what the Layer2 ledger has become. If it is a fraud-proof-based Layer2 (Plasma and Optimium), the sequencer can arbitrarily modify the data/assets of any account. If it is a validity-proof-based Layer2 (Validium), although the sequencer cannot arbitrarily modify your account, the entire Layer2 network becomes a black box at this time, and no one knows what has happened inside. Because of this, the mainstream Layer2 solutions in the Ethereum ecosystem are basically Rollups, and Validium and Optimium are often not recognized by the Ethereum Foundation.
Therefore, the reliability of the DA layer and the obtainability of state transition parameters are more important and fundamental than fraud proofs/validity proofs. For Bitcoin Layer2, especially client verification-based Layer2, even if fraud proofs/validity proofs are not set on Layer1, as long as the DA layer works normally, everyone can still know whether the L2 network has experienced erroneous state transitions.
Bitcoin’s mainnet currently has difficulty verifying fraud proofs/validity proofs (BitVM is not discussed here), so let’s assume that Bitcoin Layer2 does not have a proof verification system on Layer1. In an ideal state, if the L2 sequencer really acts maliciously and releases a stateroot on the settlement layer/BTC that has no relationship with the DA data, it still cannot truly steal user assets in a meaningful way because the stateroot/state transition results unilaterally submitted by it will not be recognized by honest nodes and may only be self-deception.
If it is a model similar to a sidechain, where most nodes collude to execute 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 the erroneous data, the malicious controllers of Layer2/sidechain cannot successfully cash out unless they persuade others to directly engage in OTC transactions on the chain.
Here is an interesting point: both Ethereum Layer2 and Bitcoin Layer2 can achieve “client verification”. However, Ethereum Layer2, based on “client verification”, can guarantee the validity of state transitions by relying on Layer1 and proof verification systems, and it does not need to rely on social consensus (provided there is a mature fraud-proof/validity-proof system).
On the other hand, Bitcoin Layer2’s “client verification” solution often relies more on “social consensus” and brings corresponding risks (for Bitcoin Layer2, this security risk is basically controllable but may still cause certain individuals to lose assets). For Ethereum Layer2, because its official bridge requires the cooperation of proof systems, if the proof system is not perfect, the sequencer can steal user assets and run away to L1. Of course, the specific design depends on how the cross-chain bridge components are designed.
Therefore, a Layer2 that can implement fraud proofs/validity proofs verification systems on Layer1 will always be much better than a simple “client verification” model.
PS: Since most Bitcoin Layer2 solutions that adopt fraud proofs/validity proofs cannot directly involve Layer1 in the proof verification process, their essence is still just treating Bitcoin as a DA layer, and their security model is equivalent to “client verification.”
Theoretically, BitVM on Layer1 can verify fraud proofs on the Bitcoin chain, but this solution faces great engineering challenges and is difficult to implement. Given that the Ethereum community has already had extensive discussions on proof verification systems based on Layer1 and it is well-known to everyone, this article does not intend to elaborate on “proof verification systems based on Layer1”.
After a simple analysis using the “barrel model”, we can preliminarily conclude that in the security models of mainstream Layer2, according to importance/foundation, they can be ranked as follows:
1. Whether the control permissions of contracts/official bridges are reasonably distributed.
2. Whether there is censorship-resistant withdrawal functionality.
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 have not analyzed the Lightning Network/state channels and the ckBTC and Celestia’s ICP ecosystem. They have significant differences from typical Rollups, Plasma, Validium, or client verification solutions. Due to time constraints, we find it difficult to conduct a thorough evaluation of their security and risk factors, but considering their significant importance, relevant evaluations will be conducted in due course.
At the same time, there is a serious disagreement among various project parties on whether the Mnemonic Indexing Protocol should be considered as Layer2. But regardless of the definition of Layer2, the Mnemonic Indexing Protocol and other new phenomena have brought sufficient technological innovation to the Bitcoin ecosystem and will ultimately unleash tremendous vitality.
Related Reports
“The Importance of Data Availability to Layer2, Inseparable from Ethereum Mainnet?”
“What is Bitcoin Layer2? How is it different from sidechains? Analyzing technical difficulties and future potential”
The Political Reasons Behind V God’s Support for ENS: Fear of Layer2’s Data Availability Layer Being Stolen?