As a professional translator, I fully understand the importance of “learning from the West and applying it to the East” while building Bitcoin Layer2. We should absorb and optimize the conclusions of the Ethereum community to an appropriate extent. However, when considering perspectives beyond the Bitcoin ecosystem, we need to be aware of the differences in starting points and ultimately seek common ground while preserving differences.
Inspired by the “barrel theory” proposed by American management scientist Laurence Peter, which states that the performance of a system is limited by its weakest part, we can analyze the interdependencies of different components in the Bitcoin/Ethereum Layer2 security models and identify which components are more fundamental and important, or in other words, “shorter”.
Based on this analysis, we can prioritize the different components in mainstream Layer2 security models as follows:
1. Whether the control authority of the contract/official bridge is reasonably decentralized (multi-signature control is less concentrated).
2. Whether there is anti-censorship withdrawal function (forced withdrawal, escape hatch).
3. The reliability of the DA layer/data release format (whether DA data is released on Bitcoin/Ethereum).
4. Whether a reliable fraud-proof/validity-proof system is deployed on Layer1 (Bitcoin L2 needs the assistance of BitVM).
Compared to the highly organized Ethereum Layer2 system, Bitcoin Layer2 is like a new world. This concept, which has become increasingly important after the NFT craze, has shown promising growth. However, its ecosystem has become increasingly chaotic and chaotic, with various Layer2 projects emerging one after another. While bringing hope to the Bitcoin ecosystem, they deliberately conceal their security risks. Some have even claimed to “reject Ethereum Layer2 and follow a unique path in the Bitcoin ecosystem,” showing a trend towards extremism.
Considering the differences in functional attributes between Bitcoin and Ethereum, it is predetermined that Bitcoin Layer2 cannot align with Ethereum Layer2 in the early stage. However, this does not mean that we should completely reject the industry consensus of Ethereum and modular blockchain, which has long been established (referring to the “Lysenkoism” event of the former Soviet biologist Lysenko, forcing persecution of supporters of Western genetics due to ideological issues).
On the contrary, these judgment criteria achieved by the “predecessors” after great efforts have already demonstrated strong persuasiveness and denying the value of these achievements is not a rational move.
While building Bitcoin Layer2, we should fully understand the meaning of “learning from the West and applying it to the East” and absorb and optimize the conclusions of the Ethereum community to an appropriate extent. However, when considering perspectives beyond the Bitcoin ecosystem, we need to be aware of the differences in starting points and ultimately seek common ground while preserving differences.
This is similar to discussing the similarities and differences between “Westerners” and “Easterners”. Whether it is Western or Eastern, the suffix “person” expresses many similar characteristics, but when corresponding to different prefixes such as “Western” and “Eastern”, there may be differences in specific characteristics.
But in the final analysis, there is always overlap between “Westerners” and “Easterners”. This 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 is more important and meaningful to first understand the similarities between the two.
Adhering to 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” because 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”.
But what can be certain is that different technical solutions bring different scalability effects to Bitcoin, and their security risks are different. The trust assumptions in their security models will be the main topic of this article.
In fact, the security of Layer2 is not a new topic. Even the term “security” is a compound concept that includes multiple specific attributes.
Previously, the founder of EigenLayer simplified “security” into four elements: “transaction irreversibility (anti-rollback), anti-censorship, DA/data release reliability, and state transition validity.”
L2BEAT and the Ethereum community OG have proposed a risk assessment model for comparing Layer2 systems, but these conclusions are mainly for 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 commendable conclusions, and most of these viewpoints have been widely recognized in Western communities, making it easier for us to objectively assess the risks of different Bitcoin L2.
So where do the security risks come from? Considering that both Ethereum Layer2 and Bitcoin Layer2 currently rely on centralized nodes to act as sequencers or committees formed by a few nodes, the security of these increasingly centralized sequencers/committees depends on their restrictions. If these sequencers/committees are unrestricted, they can steal users’ assets and run away at any time, or refuse users’ transaction requests, leading to frozen assets. This involves the state transition validity and anti-censorship mentioned by the founder of EigenLayer.
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 actually the Layer2 official) can quickly update the contract logic and include malicious code (e.g., allowing a specified address to transfer all locked tokens on the L1-L2 deposit/withdrawal contract), they can directly steal the assets held in custody.
This is referred to as the “contract multi-signature allocation problem,” which also applies to Bitcoin Layer2 because Bitcoin Layer2 often relies on “notary bridges” that require multiple nodes to approve cross-chain requests. Therefore, Bitcoin Layer2 also faces the problem of how to reasonably allocate multi-signatures, and we can even consider it as the most fundamental “auxiliary wheel” of Bitcoin Layer2.
In addition, the reliability of DA is also crucial. If Layer2 does not upload data to Layer1 and chooses unreliable DA release venues, if this off-chain DA layer (generally referred to as DAC data availability committee) conspires and refuses to publish the latest transaction data, data withholding attacks will cause the network to fail and prevent users from withdrawing smoothly.
L2BEAT summarized the above problems and identified several core elements in the Layer2 security model:
– Whether state verification/proof system is reliable (State Validation)
– Whether DA data release method is reliable (Data Availability)
– If Layer2 network intentionally refuses your transactions or shuts down, can you forcibly withdraw your assets from Layer2 (Sequencer Failure, Proposer Failure)
– Layer2-related contracts – whether the control authority of the official cross-chain bridge is sufficiently decentralized. If power is more concentrated, can users have enough time to respond in emergencies (Exit Window)
Anyway, when we analyze the security vulnerabilities of Layer2, we are actually discussing in what scenarios the memory of the Layer2 network may cause damage to users’ assets, and whether the Layer2 system can effectively constrain these dangerous situations through mechanism design. If certain malicious behaviors are unavoidable, how much “trust” do we need, how many individuals in a group do we need to trust, and how much do we rely on “auxiliary wheels”?
In the following paragraphs, we will analyze the risk elements in the general Ethereum Layer2/Bitcoin Layer2 models (excluding “state channels” or “payment channels” and citation indexing protocols because they are more specific). We will attempt to explore which factors are more fundamental, underlying, and important in the Layer2 security model, and these more fundamental shortcomings are the trust risks that deserve more attention than other shortcomings.
Here, we can use the “barrel effect” to analyze the security issues of Layer2. It is easy to see that the shortest plank mentioned earlier is the “contract upgradability” (mainly for Ethereum Layer2) or, to further elaborate, the “management authority of the official cross-chain bridge” (applicable to both Bitcoin and Ethereum Layer2).
It can be said that the control authority of the bridging contract is critical to the safety of the entire system. It is the most fundamental and crucial part of the entire Layer2 and modular blockchain stack. If the bridging 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, the bridges of Bitcoin Layer2 are not controlled by contracts on Layer1 because Bitcoin does not support smart contracts. In contrast, the entire workflow of Ethereum Layer2 highly relies on contracts on Layer1, which cannot be achieved in Bitcoin Layer2.
This is an unavoidable issue for Bitcoin Layer2. It can be said to have both advantages and disadvantages. Currently, it appears that the “trustless bridge” realized by Ethereum Layer2 relying on contracts is not achievable in Bitcoin L2. This “Trustless Bridge” requires dedicated contracts to be deployed on Layer1 and the cooperation of DA + fraud-proof/ZK proof systems. It is essentially similar to optimistic bridges like Orbiter or ZK bridges like Polyhedra.
Currently, the mainstream view in the industry is that, if we only consider the theoretical model and ignore possible 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.
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 these bridges depends on the configuration of multi-signatures/threshold signatures and requires a stronger trust assumption: assuming that these notaries will not conspire or have their private keys stolen.
Currently, most bridges based on notaries/threshold signatures cannot be compared with the “trustless bridge” of Ethereum Layer2 in terms of security (under the premise that Ethereum Layer2 contracts do not undergo malicious upgrades). It is evident that the security of assets entrusted to the Bitcoin Layer2 network will be limited by the security of its official bridge or, in other words, the decentralization of the multi-signature bridge. This is where the first “auxiliary wheel” is located.
As for the “official bridge,” the control authority of Ethereum Layer2-related contracts often concentrates in the hands of a few multi-signature controllers. If these multi-signature controllers conspire, Ethereum Layer2 bridges will also face problems unless the contracts cannot be upgraded or are subject to long delay restrictions (currently only Degate and Fuel V1 have such restrictions).
Regarding the “official bridge,” Ethereum Layer2 and Bitcoin Layer2 have different characteristics. Ethereum Layer2 heavily relies on contracts on Layer1, while Bitcoin Layer2 cannot do so. This means that the security of Ethereum Layer2 bridges is closely related to the security of Layer1 contracts, while the security of Bitcoin Layer2 bridges relies on multi-signature bridges, which introduces a higher degree of trust assumption: assuming that these notaries will not collude or have their private keys stolen.
In summary, the control authority of the bridge contract is crucial to the security of the entire system, and it is the most fundamental and critical part of the entire Layer2 and modular blockchain stack. If the bridging 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.The trust model of Layer2 is basically the same: the controllers who need to be trusted will not conspire to do evil. This group of controllers can control the official bridge of L2, either by changing its code logic or by directly allowing invalid withdrawal requests. The end result is that user assets may be stolen.
The only difference between the two is that Ethereum Layer2 is trustless as long as the contract is not maliciously upgraded or the upgrade window is long enough. However, Bitcoin Layer2 cannot achieve this effect in any way.
If we assume that the contract’s multisignature/official bridge control issues mentioned earlier can be ignored, that is, there is no problem in this layer, then the next most important layer will undoubtedly be the censorship-resistant withdrawal behavior.
Regarding the importance of censorship-resistant forced withdrawals/emergency exit functionality, Vitalik emphasized in an article “Different types of layer 2s” a few months ago that whether users can successfully withdraw their assets from Layer2 to Layer1 is a very important security indicator.
If the sequencer of Layer2 keeps rejecting your transaction requests or is down for a long time, your assets will be “frozen” and you won’t be able to do anything. Even if DA and fraud proofs/ZK proofs are available, such Layer2 is not secure enough without censorship-resistant solutions and can freeze your assets at any time.
Moreover, the Plasma solution, which was once popular in the Ethereum ecosystem, allows anyone to withdraw their assets to Layer1 when DA fails or fraud proof fails. At this time, the entire Layer2 network is basically scrapped, but you can still escape with your assets. Obviously, the censorship-resistant withdrawal function 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/emergency exit 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 at the end of a 7-day window period, they can manually trigger the freeze request function to put L2 in a frozen state and activate the emergency exit 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 a merkle proof to prove the status of their assets on Layer2 and directly withdraw them on Layer1 (which is actually taking away funds of the same amount from the official bridge’s deposit/withdrawal address).
Clearly, the emergency exit mode can only be implemented on chains that support smart contracts, such as Ethereum, and Bitcoin cannot execute such complex logic. In other words, the emergency exit function is basically a patent of Ethereum Layer2, and Bitcoin Layer2 must rely on some additional auxiliary means to imitate it, which is the second “auxiliary wheel”.
However, simply declaring a “forced withdrawal request” is much more convenient than directly activating the emergency exit mode. The former only requires users to submit a transaction to a designated address on Layer1 and declare in the transaction’s additional data what data they want to submit to all Layer2 nodes (this can bypass the sequencer and convey the request to other Layer2 nodes directly). If the “forced withdrawal” does not receive a response for a long time, users can then trigger the emergency exit mode, which is a more reasonable design.
Currently, some Bitcoin Layer2 teams plan to imitate Arbitrum’s implementation of forced transaction by allowing users to release forced transaction declarations (Forced Transaction Envelopes) on the Bitcoin chain. Under this scheme, users can bypass the sequencer and directly convey their intentions to other Layer2 nodes. If the sequencer still refuses their request after seeing the user’s forced transaction declaration, it will be noticed by other Layer2 nodes and may be penalized.
But the problem is that Arbitrum’s forced transaction function 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 Rollup solution that is not much different from client verification, it is difficult to seriously evaluate its reliability and may require evaluation of the implementation details of different projects.
Of course, since many Bitcoin Layer2 solutions operate in a manner similar to sidechains, which essentially implement decentralized sequencers, they can to some extent address the issue of censorship resistance. However, this is only an effective auxiliary means and is certainly not the ultimate solution.
PS: Some Layer2 solutions, such as Validium, have imperfect designs in their emergency exit mechanisms, where if the sequencer initiates data withholding attacks or DA is unavailable, it can prevent users from withdrawing their assets. But this is attributed to the imperfect design of the Layer2 emergency exit mechanism. The theoretically optimal emergency exit withdrawal should only rely on historical data and should not depend on the availability of DA/new data.
Although DA is called data availability, the term actually refers to data release. It is just that Vitalik and Mustafa did not think deeply when they initially named this concept, resulting in 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 received by those who need them. The reliability of data release varies on different chains.
The Western community generally believes that Bitcoin, Ethereum, and other mainstream public chains are the most trustable 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. This is achieved based on the vast scale of the Ethereum network and the numerous public data sources.
It is worth mentioning that Ethereum Rollup forcibly requires the sequencer to release transaction data/state transition parameters on Layer1, which is guaranteed by validity proofs/fraud proofs.
For example, in the case of ZK Rollup, when the sequencer releases transaction data on Layer1, it triggers the contract logic to generate a data hash, and the validator contract needs to confirm that the zk proof and data hash provided by the Proposer correspond to each other.
This is equivalent to confirming that the zk proof and state root submitted by the Proposer correspond to the Tx data, 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. If only the state root and validity proof are submitted, they will not pass the verification of the validator contract.
Regarding whether data availability or proof verification systems are more foundational, the Ethereum/Celestia community has already had ample discussions, and the general consensus is that the reliability of the DA layer is more important than the completeness of the fraud proofs/validity proofs system. For example, schemes like Plasma, Validium, and Optimium—DA layers under Ethereum with settlement layer on Ethereum—are prone to “data withholding attacks.” This refers to the collusion between the Sequencer/Proposer and the DA layer node on the ETH chain, where they update the state root on Layer1 but withhold the corresponding input parameters for the state transition, making it impossible for outsiders to determine whether the new stateroot is correct, resulting in a “blind spot”.
In such a scenario, the entire Layer2 network becomes essentially useless because you have no idea what the Layer2 ledger has become. For fraud-proof-based Layer2 (Plasma and Optimium), the sequencer can arbitrarily modify the data/assets of any account; for validity-proof-based Layer2 (Validium), although the sequencer cannot easily modify your account, the entire Layer2 network becomes a black box, and no one knows what happened inside, making it indistinguishable from being scrapped. It is for this reason that 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/data availability of state transition parameters is more important and foundational than the completeness of fraud proofs/validity proofs system. For Bitcoin Layer2, especially those based on client verification models, even without fraud proofs/validity proofs verification system set on Layer1, as long as the DA layer works normally, everyone can still know if there are errors in the L2 network state transition.
Bitcoin’s mainnet currently has difficulty verifying fraud proofs/validity proofs (not discussing BitVM here), so let’s assume that Bitcoin Layer2 does not have a proof verification system on Layer1. In an ideal scenario, if the L2 sequencer really acts maliciously and releases a state root on the settlement layer/BTC that is unrelated to the DA data, it still cannot effectively steal user assets because the state root/state transition results unilaterally submitted by it will not be recognized by honest nodes, and it may just 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/sidechains cannot successfully cash out unless they persuade others to transact with them directly 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,” guarantees the validity of state transitions by relying on Layer1 and proof verification systems, and does not need to rely heavily on social consensus (assuming there is a mature fraud proofs/validity proofs system).
On the other hand, the “client verification” solution of Bitcoin Layer2 often relies more on “social consensus,” which brings corresponding risks (for Bitcoin Layer2, this security risk is basically controllable but may still cause some people to lose their assets). For Ethereum Layer2, because its official bridge requires the cooperation of the proof verification system, if the proof system is not perfect, the sequencer can steal user assets and escape 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 system on Layer1 will always be much better than a simple “client verification” model.
PS: Since most Bitcoin Layer2 solutions that have adopted fraud proofs/validity proofs cannot directly involve Layer1 in the proof verification process, they essentially treat Bitcoin as a DA layer, and their security models are equivalent to “client verification.”
Theoretically, it is possible to verify fraud proofs on the Bitcoin chain through the BitVM scheme on Layer1, but this scheme faces great engineering challenges and difficulties. Given that the Ethereum community has already had extensive discussions on proof verification systems based on Layer1, and it is well-known, this article does not intend to elaborate on “proof verification systems based on Layer1”.
Based on a simple analysis using the barrel model, we can preliminarily conclude that in the security models of mainstream Layer2 solutions, in terms of importance/foundation, the following order can be applied:
1. Whether the control authority of contracts/official bridges is reasonably decentralized.
2. Whether there is censorship-resistant withdrawal functionality.
3. Whether the DA layer/data release form is reliable.
4. Whether a reliable fraud proofs/validity proofs system is deployed on Layer1.
Of course, we have not analyzed the Lightning Network/state channels and the ICP ecosystem’s ckBTC, inscription index protocol, etc., because they have significant differences from typical Rollups, Plasma, Validium, or client verification schemes. Due to time constraints, it is difficult to conduct a thorough evaluation of their security and risk factors, but considering their significant significance, relevant evaluation work will be carried out as scheduled.
At the same time, there is a serious divergence among various projects regarding whether the inscription index protocol should be considered as Layer2. But regardless of the definition of Layer2, the inscription index protocol and other new things have brought sufficient technological innovation to the Bitcoin ecosystem and will eventually burst with tremendous vitality.