Introduction: American management scientist Lawrence Peter once proposed the "barrel theory", which holds 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. 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 more important factors at the bottom level. In this way, the foundation of the entire theory may not stand. Therefore, when we discuss complex systems with multiple modules, we must first find out which is the "shortest plank".
Inspired by the barrel theory, we conducted a systematic analysis and found that there is an obvious dependency between different components in the Bitcoin/Ethereum Layer 2 security model, or the security of some components is more fundamental and important than the security of other components, which is the so-called "shorter".
In this regard, we can preliminarily prioritize the importance/basicity of different components in the mainstream Layer 2 security model as follows:
1. Is the control of the contract/official bridge reasonably decentralized (how centralized is the multi-signature control)?
2. Is there a censorship-resistant withdrawal function (forced withdrawal, escape hatch)?
3. Is the DA layer/data publishing format reliable (is the DA data published on Bitcoin or Ethereum)
4. Is a reliable fraud proof/validity proof system deployed on Layer 1 (Bitcoin L2 requires the help of BitVM)
We should moderately absorb the research results of the Ethereum community on Layer2 and avoid Lysenkoism
Compared with the highly ordered Ethereum Layer2 system, Bitcoin Layer2 is like a brand new world. This new concept, which has become increasingly important after the inscription craze, is showing a rising momentum, but its ecosystem is becoming increasingly chaotic. All of a sudden, various Layer2 projects emerge in an endless stream, like mushrooms after rain. While they bring hope to the Bitcoin ecosystem, they deliberately conceal their own security risks. Some people even threatened to "deny Ethereum Layer2 and take the unique path of Bitcoin ecology", showing a tendency to take an extremist route.
Considering the differences in functional attributes between Bitcoin and Ethereum, Bitcoin Layer2 is destined to be unable to align with Ethereum Layer2 in the early stage, but this does not mean that we should completely deny the industry common sense that has long been concluded in Ethereum and even the modular blockchain community (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 criteria, which were achieved by "predecessors" with great efforts, have long demonstrated strong persuasiveness after being widely recognized. It is by no means rational to deliberately deny the value of these achievements.
While building Bitcoin Layer2, 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. However, when drawing on views outside the Bitcoin ecosystem, we need to 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". Whether it is Western or Eastern, the suffix "人" expresses many similar characteristics, but when corresponding to different prefixes such as "Western" and "Eastern", the detailed 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, and 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 first clarify the interconnections 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 Layer 2 and what is not", because this topic is too controversial. Even the Ethereum community has not reached an objective and consistent view on "what is Ethereum Layer 2 and what is not Layer 2".
But what is certain is that while different technical solutions bring expansion effects to Bitcoin, their security risks are different. The trust assumptions in their security models will be the focus of this article.
How to understand the security and evaluation criteria of Layer 2
In fact, the security of Layer 2 is not a new topic of discussion. Even the word security is a complex concept that includes multiple subdivided attributes.
Previously, the founder of EigenLayer simply subdivided "security" into four elements: "transaction irreversibility (anti-rollback), anti-censorship, DA/data release reliability, and state transition validity."
(EigenLayer founder expressed his views on how client-side verification/sovereign Rollup solutions can inherit the security of Bitcoin mainnet)
L2BEAT and Ethereum community OG have proposed a more systematic Layer2 risk assessment model. Of course, these conclusions are aimed at smart contract-based Layer2, rather than typical non-smart contract-based Layer2 such as sovereign Rollup and client verification.
Although this is not 100% suitable for Bitcoin L2, it still contains many conclusions that are worthy of recognition. Most of its views have been widely recognized in the Western community, and it also makes it easier for us to objectively evaluate the risks of different Bitcoin L2s.
(Vitalik once said that since the Rollup solution could not achieve theoretical perfection in the early stage of launch, it was necessary to use some auxiliary means to improve security. These auxiliary means are called "training wheels" and will introduce trust assumptions. These trust assumptions are risks)
So where do the 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 a "committee" in the form of a side chain composed of a few nodes, these centralized sorters/committees can steal user assets and run away at any time if they are not restricted, and can reject user transaction requests, causing assets to be frozen and unusable. This involves the state transition validity and anti-censorship mentioned by the founder of EigenLayer in the previous article.
At the same time, since Ethereum Layer2 relies on contracts on the ETH chain to verify state transitions and deposit and withdrawal behaviors, if the contract controller (actually the Layer2 official) can quickly update the contract logic and mix malicious code segments into it (for example, allowing a specified address to transfer all tokens locked on the L1-L2 deposit and withdrawal contract), the managed assets can be directly stolen.
This is attributed to the "contract multi-signature allocation problem", which also applies to Bitcoin Layer2. Because Bitcoin Layer2 often relies on the "notary bridge" and requires multiple nodes to release cross-chain requests through multi-signatures, Bitcoin Layer2 also has the problem of how to reasonably allocate multi-signatures. We can even regard it as the most basic "training wheel" of Bitcoin Layer2.
In addition, the DA problem is also extremely important. If Layer2 does not upload data to Layer1, but chooses some unreliable DA publishing venues on its own, if this off-chain DA layer (generally called the DAC Data Availability Committee) conspires and refuses to release the latest transaction data to the outside world, the data withholding attack will cause the network to be scrapped and may prevent users from withdrawing funds smoothly.
L2BEAT summarizes the above issues and summarizes several core elements in the Layer 2 security model:
1. State Validation/Proof of System Reliability
2. Is the DA data release method reliable? (Data Avalibility)
3. If the Layer2 network deliberately rejects your transaction/shuts down, can you force your assets out of Layer2 (Sequencer Failure, Proposer Failure)?
4. Is the control of the official cross-chain bridge of Layer2 related contracts decentralized enough? If the power is relatively centralized, when "embezzlement" occurs, will users have enough time to respond (Exit Window)?
(“Risk Factor Display Chart” set up for different Layer2 projects on L2BEAT)
Anyway, when we analyze the security risks of Layer2, we are actually discussing how many scenarios exist in the Layer2 network that may cause damage to user assets, and whether the Layer2 system can effectively control these dangerous situations through mechanism design. If certain malicious behaviors cannot be eliminated, how much "trust" do we need to introduce, how many individuals in a group do we need to trust, and how many "training wheels" do we need to rely on.
In the following, we will analyze the risk factors in the general Ethereum Layer2/Bitcoin Layer2 model (the objects discussed in this article do not include "state channels" or "payment channels", nor do they include inscription index protocols because they are relatively special). And we will try to explore which factors are more basic, more basic, and more important in the Layer2 security model. These more basic shortcomings will be the trust risks that deserve our attention more than other shortcomings.
Layer 2’s barrel effect — what are the shortcomings?
The shortest board - management of the contract/official bridge
Here, we might as well use the "barrel effect" to analyze the Layer2 security issue. It is easy to see that the shortest piece of wood is the "contract upgradeability" mentioned above (mainly for Ethereum Layer2), or to put it more specifically, the "management rights of the official cross-chain bridge" (applicable to both Bitcoin and Ethereum Layer2).
For Ethereum Layer2, as long as the Layer2 official can quickly upgrade the contract on the Layer1 chain, in theory, the tokens locked on the L2 official bridge deposit and withdrawal address can be stolen, no matter how reliable its DA layer or proof system is.
It can be said that the control authority of the bridge contract is related to the safety of the entire system. It is the most basic and critical part of the entire Layer2 and even the modular blockchain stack. If the bridge component/contract can be updated and iterated under multi-signature control, then we have to introduce the "trust assumption" here, assuming that the controller of the Layer2 contract/official bridge will not do evil.
(The contract upgrade delays for different Layer2 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 hackers, the user assets managed by L2 will definitely suffer.)
Unlike Ethereum Layer2, Bitcoin Layer2's bridge is basically not controlled by the contracts on Layer1, because Bitcoin does not support smart contracts. Relatively speaking, the entire workflow of Ethereum Layer2 is highly dependent on the contracts on Layer1, while Bitcoin Layer2 cannot do this.
(Starknet schematic)
This is an unavoidable problem for Bitcoin Layer2, which can be said to have both advantages and disadvantages. At present, the "trustless bridge" that Ethereum Layer2 relies on contracts to implement cannot be realized in Bitcoin L2. This "Trustless Bridge" requires the deployment of a dedicated contract on Layer1, and requires the cooperation of DA+ fraud proof/ZK proof system, which is essentially similar to the "optimistic bridge" of Orbiter or ZK bridge such as Polyhedra.
The current mainstream view in the industry is that if we ignore possible bugs in practice and only consider theoretical models, the security level of the Optimistic Bridge and the ZK Bridge is basically the highest level. As long as the contract code does not contain bugs or cannot be maliciously upgraded, it is basically trustless.
(The optimistic bridge only needs to ensure that 1 out of N watchers is honest to ensure security, and 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 this bridge depends on the setting of multi-signature/threshold signatures, which requires the introduction of strong trust assumptions: assuming that these notaries will not collude or have their private keys stolen.
At present, most of the bridges based on notaries/threshold signatures cannot be compared with the official “trustless bridge” of Ethereum Layer2 in terms of security (the premise is that the Ethereum Layer2 contract will not be maliciously upgraded). Obviously, the security of assets hosted by the Bitcoin Layer2 network will be subject to the security of its official bridge, or the power decentralization of the multi-signature bridge, which is its first “training wheel”.
Since the "upgrade permissions" of Ethereum Layer2 official bridge-related contracts are often concentrated in the hands of a few multi-signature controllers, if the multi-signature controllers collude, Ethereum Layer2 bridges will also have problems, unless their contracts cannot be upgraded or are subject to very long delay restrictions (currently only Degate and Fuel V1 are like this).
(Every time Degate upgrades the contract, it will give users a 30-day safe escape period. 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 hatch function)
Regarding the “official bridge”, the trust models of Ethereum Layer2 and Bitcoin Layer2 are basically the same: it is necessary to trust that the controller of the multi-signature will not collude to do evil. This group of multi-signatures can control the L2 official bridge, either by changing its code logic or directly releasing 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 Layer2 is not upgraded maliciously/the upgrade window period is long enough, its official bridge is trustless, but Bitcoin Layer2 cannot achieve this effect anyway.
The second shortest board — censorship-resistant forced withdrawals
If we assume that the multi-signature/official bridge control issue mentioned above can be ignored, that is, there is no problem at this level, then the next most important level must be the censorship resistance of withdrawal behavior.
Regarding the importance of censorship-resistant forced withdrawal/escape hatch functions, 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 keeps rejecting your transaction requests, or fails/downtimes for a long time, your assets will be "frozen" and you will be unable to do anything. Even if DA and fraud proof/ZK proof systems are available, if there is no anti-censorship solution, such a Layer2 is not safe enough and your assets can be withheld 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 Layer1 when DA fails or fraud proof fails. At this time, the entire Layer2 network is basically scrapped, but your assets can still be withdrawn intact. Obviously, the anti-censorship withdrawal function is more basic and underlying than the DA and proof system.
(Dankrad of the Ethereum Foundation said that Plasma can still allow users to safely evacuate their assets when DA fails/users cannot synchronize the latest data)
Some Ethereum Layer2s, such as Loopring, StarkEx, dYdX, Degate, etc., will set up a censorship-resistant forced withdrawal/escape hatch activation function on Layer1. Taking Starknet as an example, if the Forced Withdrawal request submitted by the user on Layer1 does not receive a response from the Layer2 sorter 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 hatch mode.
At this point, the sorter cannot submit data to the Rollup contract on L1, and the entire Layer2 will be frozen for one year. Then, users can submit merkle proofs to prove their asset status on Layer2 and withdraw funds directly on Layer1 (in fact, they take their own funds from the deposit and withdrawal addresses of the official bridge).
Obviously, the escape hatch mode can only be implemented on chains like Ethereum that support smart contracts, and Bitcoin cannot run such complex logic. In other words, the escape hatch function is basically the patent of Ethereum Layer2, and Bitcoin Layer2 must use some additional auxiliary means to imitate it, which is the second "training wheel".
However, simply declaring a "forced withdrawal request" is much more convenient than directly activating the escape hatch. The former only requires the user to submit a transaction to the specified address on Layer1, and declare the data that he wants to submit to all Layer2 nodes in the additional data of the transaction (this can directly bypass the sorter and convey the request 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 hatch mode.
(Reference: How important are forced withdrawal and escape hatch functions to Layer2?
https://mp.weixin.qq.com/s/EheKZWDcJHYZ7vBZZPOMDA）
Currently, there is a Bitcoin Layer2 team that intends to imitate Arbitrum's forced transaction implementation method, allowing users to publish forced transaction envelopes on the Bitcoin chain. Under this scheme, users can bypass the sorter and directly "convey their voices" to other Layer2 nodes. If the sorter still rejects the user's request after seeing the user's forced transaction statement, it will be noticed by other Layer2 nodes and may be punished.
But the problem is that Arbitrum's forced transaction function, thanks to its fraud proof system, can punish Sequencer/Proposer who has been ignoring user transactions. However, Bitcoin Layer2, which is difficult to verify fraud proofs on Layer1, will encounter certain challenges in this regard. (Let's not discuss BitVM for now) If it is a sovereign Rollup, whose security level is not much different from client verification, it is difficult for us to seriously evaluate its reliability, and we may need to evaluate it based on the implementation details of different projects.
Of course, given that many Bitcoin Layer2s currently operate in a form similar to sidechains, which is equivalent to implementing a decentralized sorter, the anti-censorship problem can be solved to a certain extent. But this is only an effective auxiliary means, and it is definitely not the ultimate solution.
ps: Some current Layer2 solutions, such as Validium, are not perfect in the design of the escape hatch mechanism. When the sorter launches a data withholding attack/DA is unavailable, users can be unable to withdraw funds. But this is due to the imperfection of the Layer2 escape hatch design. In theory, the optimal escape hatch withdrawal can only rely on historical data, without relying on the availability of DA/new data)
The third shortest board: Reliability of DA layer data release
Although DA is called data availability, this term actually refers to data release. It is only because Vitalik and Mustafa did not think carefully when they first named this concept that the name DA/data availability came into being.
Data release, as the name implies, refers to whether the latest block/transaction data/state transition parameters can be successfully received by those who need them. The reliability of data released on different chains is different.
(Reference: Misunderstanding of data availability: DA = data release ≠ historical data retrieval
https://mp.weixin.qq.com/s/OAM_l4Pe9Gphn8H55OZUtw）
The Western community generally believes that Bitcoin, Ethereum and other established public chains are the most trustless DA layers. If the Layer2 sorter publishes new data on Ethereum, anyone running the Ethereum geth client can download and synchronize the data with almost no hindrance. This is achieved by relying on the huge scale of the Ethereum network and the numerous public data sources.
It is worth mentioning that Ethereum Rollup will force the sorter to publish transaction data/state transition parameters on Layer1, which is guaranteed by validity proof/fraud proof.
For example, after the ZK Rollup sorter publishes transaction data on Layer 1, it triggers the contract logic to generate a datahash, and the validator contract must confirm that there is a corresponding relationship between the validity proof submitted by the Proposer and 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 only the stateroot and validity proof are submitted, it will not pass the verification of the validator contract.
The Ethereum/Celestia community has already had a full discussion on which is more fundamental, DA data release or proof verification system. 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 off-chain and the settlement layer is on-chain, are prone to "data withholding attacks", which means:
The Sequencer/Proposer can collude 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 determine whether the new stateroot is correct, thus becoming "blind".
If this happens, the entire Layer2 network is equivalent to being scrapped, because at this time, you have no idea what the Layer2 ledger has become. If it is a Layer2 based on fraud proof (Plasma and Optimium), the sorter can arbitrarily rewrite the data/assets under any account; if it is a Layer2 based on validity proof (Validium), although the sorter cannot arbitrarily rewrite your account, the entire Layer2 network becomes a black box at this time, and no one knows what happened inside, which is no different from being scrapped. Because of this, the orthodox Layer2 solutions in the Ethereum ecosystem are basically Rollup, and Validium and Optimium are often not recognized by the Ethereum Foundation.
(Reference: Data Withholding and Fraud Proofs: Why Plasma Doesn’t Support Smart Contracts
https://mp.weixin.qq.com/s/oOPZqIoi2p6sCxBdfUP4eA）
Therefore, the reliability of the DA layer/the availability of state transition parameters is more important and fundamental than the completeness of the fraud proof/validity proof system. For Bitcoin Layer2, especially Layer2 based on the client verification model, even if there is no fraud proof/validity proof verification system on Layer1, as long as the DA layer works normally, everyone can still know whether there is an erroneous state transition in the L2 network.
At present, it is difficult to verify fraud proof/validity proof on the Bitcoin mainnet (BitVM is not discussed here). Let us assume that Bitcoin L2 does not have a proof verification system. Ideally, if the L2 sorter does evil and publishes a stateroot that is not associated with DA data on the settlement layer/BTC, it still cannot really steal user assets, because the stateroot/state transition result it unilaterally submits will not be recognized by honest nodes, and in the end it may just be self-satisfaction.
(At this point, as long as the nodes run by the providers of peripheral facilities within the ecosystem, such as exchanges and cross-chain bridges, do not collude with the sorter, the sorter will not be able to quickly liquidate the stolen assets by publishing wrong data. After that, as long as one honest node finds 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 the sidechain, and the majority of 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 incorrect data, the malicious controller of Layer2/sidechain will not be able to successfully cash out unless he convinces others to do OTC directly with him on the chain.
(Viatlik once pointed out in the article that client verification is the real foundation for ensuring the security of blockchain network, Verify by yourself)
There is an interesting point here. In fact, both Ethereum Layer2 and Bitcoin Layer2 can achieve "client verification". However, Ethereum Layer2, based on "client verification", uses Layer1 and the proof verification system to ensure the validity of state transitions, and basically does not need to rely on social consensus (provided that there is a mature fraud proof/validity proof system).
The "client verification" scheme of Bitcoin Layer2 often has a strong reliance on "social consensus", which will bring corresponding risks (for Bitcoin Layer2, this security risk is basically controllable, but it may still cause some people to lose assets. For Ethereum Layer2, because its official bridge requires the cooperation of the proof system, if the proof system is not perfect, the sorter can steal user assets and move them to L1 and run away. Of course, it depends on how the cross-chain bridge component is designed).
Therefore, a Layer2 that can implement a fraud proof/validity proof verification system on Layer1 will always be much better than a simple "client verification" model.
PS: Since most Bitcoin Layer2s that use the fraud proof/validity proof system cannot allow Layer1 to directly participate in the proof verification process, their essence is still to just treat Bitcoin as a DA layer, and the security model is equivalent to "client verification."
Theoretically, through the BitVM solution on Layer 1, fraud proofs can be verified on the Bitcoin chain, but this solution is difficult to implement and will encounter great challenges. Since the Ethereum community has already discussed a lot about the proof verification system based on Layer 1, and it is already well known, this article does not intend to elaborate on the "proof verification system based on Layer 1".
Summarize
After a simple analysis of the wooden barrel model, we can preliminarily draw the conclusion that the mainstream Layer 2 security models can be ranked as follows according to their importance/basicity:
1. Is the control of the contract/official bridge reasonably decentralized?
2. Is there a censorship-resistant withdrawal function?
3. Is the DA layer/data publishing format reliable?
4. Is a reliable fraud proof/validity proof system deployed on Layer 1?
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 their security and risk factors, but considering their great significance, the relevant assessment work will be carried out as scheduled in the future.
At the same time, there are serious differences among many project parties on 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 tremendous vitality.
