A Layer 2 that can implement a fraud proof/validity proof verification system on Layer 1 will always be much better than a simple “client verification” model.
Written by: Faust & Wuyue, geek web3
Advisor: Kevin He (@0xKevinHe), VP of Xinhuo Technology
Introduction: American management scientist Lawrence Peter once proposed the “barrel theory”, which believes that the overall performance of a system is limited by its weakest part. In other words, how much water a barrel can hold is determined by its shortest board. Although this principle is simple, it is often overlooked. **Previous debates on Layer 2 security mostly ignored the priority and importance of different components. They basically focused on state transition reliability and DA issues, but ignored the lower-level and more important elements. In this way, the entire theoretical foundation Probably not even tenable. Therefore, when we discuss a complex multi-module system, we must first find out which piece is the “shortest board.”
Inspired by the barrel theory, we did a system analysis and found that there are obvious dependencies between different components in the Bitcoin/Ethereum Layer 2 security model, or that some components are more secure than others. Sex is more basic and important, the so-called “shorter”.
In this regard, we can initially prioritize the importance/basis of different components in the mainstream Layer2 security model as follows:**
Whether the control authority of the contract/official bridge is reasonably dispersed (how concentrated is the multi-signature control authority)?
Is there a censorship-resistant withdrawal function (forced withdrawal, escape hatch)
Whether the DA layer/data release form is reliable (whether DA data is released on Bitcoin or Ethereum)
Whether a reliable fraud proof/validity proof system has been deployed on Layer1 (Bitcoin L2 requires BitVM)
We should moderately absorb the research results of Layer 2 from the Ethereum community and avoid Lysenkoism
Compared with the highly ordered Ethereum Layer 2 system, Bitcoin Layer 2 is like a brand new world. This new concept, which has become increasingly important after the inscription craze, is showing rising momentum, but its ecological system is becoming increasingly chaotic and chaotic. Out of the chaos, various Layer 2 projects sprouted up like mushrooms after a rain. While they bring hope to the Bitcoin ecosystem, they deliberately conceal their own security risks. Some people even threatened to “deny Ethereum Layer 2 and follow the unique path of the Bitcoin ecosystem.” They have a strong tendency to take an extremist route.
Considering the differences in functional attributes between Bitcoin and Ethereum, Bitcoin Layer 2 is destined to be unable to align with Ethereum Layer 2 in the early days, but this does not mean that we should completely deny that Ethereum and even the modular blockchain industry have long had Industry common sense of final conclusion (refer to the “Lysenko incident” in which the former Soviet biologist Lysenko used ideological issues to persecute Western genetics supporters).
On the contrary, these evaluation standards, which were obtained by “predecessors” with great efforts, have already shown strong persuasiveness after being widely recognized. It is definitely not a rational move to deliberately deny the value of these achievements. **
**While building Bitcoin Layer 2, we should fully realize the significance of “learning from the West and applying it to the East” and appropriately absorb and optimize the many conclusions of the Ethereum community. But when drawing on perspectives outside the Bitcoin ecosystem, we must be aware of the differences in their starting points, and ultimately seek common ground while reserving differences. **
This is like discussing the similarities and differences between “Westerners” and “Easterners”. Regardless of whether it is Western or Eastern, the suffix “人” expresses many similar characteristics, but when corresponding to different prefixes such as “Western” and “Eastern”, the subdivision characteristics will be different.
But in the final analysis, there is bound to be an overlap between “Westerners” and “Easterners”, which means that many things that apply to Westerners are also applicable to Easterners, and many things that apply to “Ethereum Layer 2” , also applies to “Bitcoin Layer2”. **Before distinguishing the differences between Bitcoin L2 and Ethereum L2, it may be more important and meaningful to clarify the interoperability between the two.
Adhering to the purpose of “seeking common ground while reserving differences”, the author of this article does not intend to discuss “what is Bitcoin Layer 2 and what is not”, ** because this topic is too controversial, even the Ethereum community has not discussed “what is Ethereum Layer 2” , which ones are not Layer 2" and reach an objective and consistent view.
**But what is certain is that while different technical solutions bring expansion effects to Bitcoin, they also have different security risks. The trust assumptions existing in their security models will be the topic that this article intends to focus on. **
How to understand the security and evaluation criteria of Layer2
In fact, Layer 2 security is not a new discussion point. Even the word security is a composite concept that includes multiple subdivided attributes.
Previously, the founder of **EigenLayer had simply subdivided “security” into four elements including “transaction irreversibility (anti-rollback), censorship resistance, DA/data release reliability, and state transition validity.” **
(The founder of EigenLayer once expressed his views on how the client-side verification/sovereign rollup scheme can inherit the security of the Bitcoin mainnet)
L2BEAT and Ethereum Community OG have proposed a relatively systematic Layer 2 risk assessment model. Of course, these conclusions are aimed at smart contract Layer 2, rather than typical non-smart contract Layer 2 such as sovereign rollup and client verification.
**Although this is not 100% suitable for Bitcoin L2, it still contains many conclusions worthy of recognition. Most of its views have been widely recognized in the Western community, ** and it also facilitates our objective assessment of the risks of different Bitcoin L2.
(Vitalik once said that because the Rollup solution cannot achieve theoretical perfection in its early launch, it must use some auxiliary means to improve security, and these auxiliary means are called “training wheels” and will introduce trust assumptions. These trust assumptions are risks)
So where do security risks come from? Considering the current situation, whether it is Ethereum Layer 2 or Bitcoin Layer 2, many of them rely on centralized nodes to act as sequencers, or a small number of nodes forming a “committee” in the form of a side chain. These tend to be centralized. If the sequencer/committee is not restricted, it can steal user assets and run away at any time. It can refuse users’ transaction requests, causing assets to be frozen and unusable. **This involves the state transition effectiveness and censorship resistance mentioned by the founder of EigenLayer earlier. **
At the same time, since Ethereum Layer2 relies on contracts on the ETH chain for state transition verification and deposit and withdrawal behavior verification, if the contract controller (actually the official Layer2) can quickly update the contract logic, add malicious code segments (for example, Allowing a specified address to transfer all the tokens locked on the L1-L2 deposit and withdrawal contract), you can directly steal the assets under custody.
**This is attributed to the “contract multi-signature distribution problem”, and the multi-signature distribution problem also applies to Bitcoin Layer 2, ** because Bitcoin Layer 2 often relies on the “Notary Bridge” and requires multiple nodes to release through multi-signature Cross-chain requests, so Bitcoin Layer 2 also has the problem of how to reasonably distribute multi-signatures. We can even regard it as the most basic “auxiliary wheel” of Bitcoin Layer 2. **
**Also, the DA issue is extremely important. **If Layer2 does not upload data to Layer1, but chooses some unreliable DA release venues, if this off-chain DA layer (commonly known as the DAC Data Availability Committee) colludes and refuses to release the latest transaction data to the outside world, the data Withholding attacks will cause the network to become obsolete and may prevent users from withdrawing funds smoothly.
L2BEAT summarized the above issues and summarized several core elements in the Layer2 security model:
State Validation/Prove whether the system is reliable (State Validation)
Is the DA data publishing method reliable? (Data Availability)
If the Layer2 network deliberately rejects your transaction/shuts down, can you force the assets to withdraw from Layer2 (Sequencer Faliure, Proposer Failure)
Layer2 related contracts - whether the control of the official cross-chain bridge is sufficiently decentralized. If power is relatively concentrated, will users have enough time to respond when “surveillance theft” occurs (Exit Window)
(“Risk factor display” set for different Layer2 projects on L2BEAT)
Anyway, when we analyze Layer 2 security risks, we are actually discussing how many scenarios exist in the Layer 2 network that may cause damage to user assets, and whether the Layer 2 system can effectively restrict these dangerous situations through mechanism design. **If certain malicious behaviors cannot be eliminated, how much “trust” do we need to introduce, how many individuals in a group need to be trusted, and how many “auxiliary wheels” do we need to rely on.
Below we will analyze the risk factors in the general Ethereum Layer2/Bitcoin Layer2 model** (The objects mentioned in this article do not include “state channel” or “payment channel”, nor does it include the inscription index protocol , because they are special). **And we will try to explore which factors are more basic, lower-level, and more important in the Layer 2 security model. These more basic shortcomings will be trust risks that deserve our attention more than other shortcomings.
The barrel effect of Layer2 - what are the shortcomings?
The shortest board - contract/official bridge management rights
Here, we might as well use the “barrel effect” to analyze Layer 2 security issues. It is easy to see that the shortest board is the “contract upgradeability” mentioned above (mainly for Ethereum Layer 2), or Furthermore, it is the “management right of the official cross-chain bridge” (applicable to both Bitcoin and Ethereum Layer 2). **
For Ethereum Layer 2, as long as the Layer 2 official can quickly upgrade the contract on the Layer 1 chain, the Token locked on the L2 official bridge deposit and withdrawal address can theoretically be stolen, no matter how reliable its DA layer or certification system is.
It can be said that the control authority of the bridge contract is related to the security of the entire system. It is the most basic and critical part of the entire Layer 2 and even the modular blockchain stack. **If the bridge component/contract can be updated and iterated under multi-signature control, then we need to introduce a “trust assumption” here, assuming that the controller of the Layer2 contract/official bridge will not do evil. **
(The contract upgrade delays of 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 a hacker, the user assets hosted by L2 Will definitely suffer)
Different from Ethereum Layer 2, the bridge of Bitcoin Layer 2 is basically not controlled by the contract on Layer 1, because Bitcoin does not originally support smart contracts. Relatively speaking, the entire workflow of Ethereum Layer2 is highly dependent on the contract on Layer1, while Bitcoin Layer2 cannot do this.
(Starknet schematic)
**This is an unavoidable problem for Bitcoin Layer 2. It can be said that it has both advantages and disadvantages. At present, it seems that the “trustless bridge” implemented by Ethereum Layer 2 relying on contracts cannot be realized in Bitcoin L2. **This “Trustless Bridge” requires the deployment of a dedicated contract on Layer1 and the cooperation of the DA+ fraud proof/ZK proof system. It is essentially similar to the “optimistic bridge” like Orbiter or ZK bridges such as Polyhedra.
The current mainstream view in the industry is that if you do not consider possible bugs in practice and only consider theoretical models, the security level of Optimistic Bridge and ZK Bridge is basically the highest level. As long as the contract code does not contain bugs or cannot be maliciously upgraded, It’s basically trustless.
(The Optimistic Bridge only needs to ensure that 1 out of N watchers is honest to ensure safety. The trust model is 1/N)
Since Bitcoin Layer 2 cannot deploy contract components on Layer 1 (we are not talking about the Lightning Network here), its official bridges are basically “** Notary Bridges” composed of a small number of nodes, or “Multi-Signature Bridges”. This kind of bridge The security depends on how multi-signature/threshold signatures are set up, which requires the introduction of strong trust assumptions: it is assumed that these notaries will not collude or have their private keys stolen. **
At present, most bridges based on notary/threshold signatures cannot be compared with the official “trustless bridge” of Ethereum Layer 2 in terms of security (the premise is that the contract of Ethereum Layer 2 will not be maliciously upgraded). Obviously, the asset security of **Bitcoin Layer 2 network custody will be limited by the security of its official bridge, or by the decentralization of power of the multi-signature bridge. This is its first “auxiliary wheel” . **
Since the “upgrade rights” of Ethereum Layer 2 official bridge-related contracts are often concentrated in the hands of a few multi-signature controllers, ** if the multi-signature controllers collude, the Ethereum Layer 2 bridge will also have problems, unless it The contract cannot be upgraded or is subject to a long delay** (currently only Degate and Fuel V1).
(Every time Degate contracts upgrade, it will reserve a 30-day safe escape period for users. During this period, as long as everyone finds that the new version of the contract code has malicious logic, they can escape safely through the forced withdrawal/escape cabin function)
Regarding the “official bridge” part, **The trust models of Ethereum Layer 2 and Bitcoin Layer 2 are basically the same: the controllers who need to trust the multi-signature will not collude to do evil. **This group of multi-signatures can control the L2 official bridge, or change it The code logic is to directly release invalid withdrawal requests, and the final result is: user assets may be stolen.
The only difference between the two is that Ethereum Layer 2’s official bridge is trustless as long as the contract is not maliciously upgraded/the upgrade window is long enough, but Bitcoin Layer 2 cannot achieve this effect anyway.
The second shortest board - censorship-resistant forced withdrawal
If we assume that the issue of multi-signature contracts/official bridge control mentioned above can be ignored, that is, there is no problem with this layer, then the next most important layer must be the censorship resistance of withdrawals.
Regarding the importance of the censorship-resistant forced withdrawal/escape cabin function, Vitalik emphasized in his article “Different types of layer 2s” a few months ago that whether users can successfully withdraw assets from Layer2 to Layer1 is a key factor. Very important safety indicator. **
If Layer 2’s sequencer keeps rejecting your transaction requests, or fails/is down for a long time, your assets will be “frozen” and nothing can be done. **Even if DA and fraud proof/ZK proof systems are available, without an anti-censorship solution, such Layer 2 is not secure enough and your assets can be detained at any time. **
What’s more, the Plasma solution, which was once very popular in the Ethereum ecosystem, allows anyone to safely withdraw assets to Layer 1 when the DA fails or the fraud proof fails. At this time, the entire Layer 2 network is basically scrapped, but there is still a way for your assets to escape unscathed. **Obviously, the censorship-resistant withdrawal function is more basic and lower-level than the DA and proof systems. **
(Dankrad of the Ethereum Foundation said that Plasma can still allow user assets to be safely evacuated when DA fails/users are unable to synchronize the latest data)
Some Ethereum Layer 2, such as Loopring, StarkEx, dYdX, Degate, etc., will set up a censorship-resistant forced withdrawal/escape cabin activation function on Layer 1. Taking Starknet as an example, if the user submits Forced on Layer 1 If the Withdrawal request does not receive a response from the Layer2 sequencer at the end of the 7-day window period, the freeze Request function can be manually called to put L2 into the frozen state and activate the escape cabin mode.
At this time, 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 a merkle proof to prove their asset status on Layer 2, and directly withdraw money on Layer 1 (actually, they take away their own equal amount of funds from the official bridge’s deposit and withdrawal address). **
Obviously, the escape hatch mode can only be implemented on a chain like Ethereum that supports smart contracts, and Bitcoin cannot run such complex logic. **In other words, the escape hatch function is basically a patent of Ethereum Layer 2. Bitcoin Layer 2 must use some additional auxiliary means to imitate the cat and the tiger. This is the second “auxiliary wheel”. **
**But simply stating 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 in the additional data of the transaction, declare the data that they want to submit to all Layer2 nodes (**This can directly bypass the sorter and send data to other Layer2 nodes node communicates the request). **If the “forced withdrawal” does not receive a response for a long time, it is a more reasonable design for the user to trigger the escape cabin mode.
(Reference: How important are the forced withdrawal and escape cabin functions for Layer2?)
**Currently, there are already Bitcoin Layer 2 teams that plan to imitate Arbitrum’s forced transaction implementation and allow users to issue forced transaction statements (Forced Transaction Envelopes) on the Bitcoin chain. **Under this solution, users can bypass the sequencer and “convey their voices” directly to other Layer2 nodes. If the sequencer still rejects the user’s request after seeing the user’s forced transaction statement, it will be noticed by other Layer 2 nodes and may be punished.
**But the problem is that Arbitrum’s forced transaction function, benefiting from its fraud proof system, can punish Sequencer/Proposer that has been ignoring user transactions. However, Bitcoin Layer 2, which is difficult to verify fraud proof on Layer 1, will encounter certain challenges in this regard. (Let’s not discuss BitVM for now) **If it is a solution such as sovereign Rollup, where the security level is not much different from client verification, it is difficult for us to seriously evaluate its reliability, and we may need to evaluate the implementation details of different projects.
Of course, given that many Bitcoin Layer 2 currently operate in a form similar to side chains, it is equivalent to realizing a ** decentralized sequencer, which can solve the anti-censorship problem to a certain extent. But this is only an effective auxiliary means, certainly not the ultimate solution. **
ps: Some current Layer 2 solutions, such as Validium, etc., are not perfect in the design of the escape cabin mechanism. When the sequencer launches a data withholding attack/DA is unavailable, users cannot withdraw money. But this is due to the imperfect design of the Layer 2 escape cabin. Theoretically, the optimal escape cabin withdrawal can only rely on historical data and does not need to rely on the availability of DA/new data)
The third shortest board: the reliability of DA layer data release
**Although DA is called data availability, this term actually refers to data release. **It is only because Vitalik and Mustafa did not think carefully when they originally named this concept that the name DA/data availability does not match. Real name.
**Data release, as the name suggests, refers to whether the latest blocks/transaction data/state transition parameters can be successfully received by those in need. **Publishing data on different chains has different reliability.
(Reference: Misunderstanding of data availability: DA=data release ≠ historical data retrieval)
Western communities generally believe that established public chains such as Bitcoin and Ethereum are the most trustworthy DA layers. If the Layer2 sorter publishes new data on Ethereum, anyone who runs the Ethereum geth client can download the data and synchronize it without any hindrance. **This is because This is achieved by the huge scale of the Ethereum network and the wide variety of public data sources.
**It is worth mentioning that Ethereum Rollup will force the sequencer to publish transaction data/state transition parameters on Layer1, which is guaranteed through validity proof/fraud proof. **
For example, after ZK Rollup’s sequencer publishes transaction data on Layer1, it will trigger the contract logic to generate a datahash, and the validator contract must confirm that the validity certificate submitted by the Proposer has a corresponding relationship with the datahash.
This is equivalent to: confirming that the zk Proof and Stateroot submitted by the Proposer are associated with the Tx data submitted by the Sequencer, that is, New Stateroot=STF(Old Stateroot, Txdata). STF is the state transition function.
**This ensures that the state transition data/DA is forcibly uploaded to the chain. If you only submit the stateroot and validity certificate, it will not be able to pass the verify of the validator contract. **
As for whether DA data release or proof verification system is more basic, the Ethereum/Celestia community has already had a full discussion. The general conclusion is: **The reliability of the DA layer is more important than the completeness of the fraud proof/validity proof system. **For example, solutions such as Plasma, Validium, and Optimium, where the DA layer is under the Ethereum chain and the settlement layer is on the Ethereum chain, are prone to "data withholding attacks", which means:
**Sequencer/Proposer can conspire with the DA layer nodes under the ETH chain to update the stateroot on Layer1, but the input parameters corresponding to the state transition are held back and not sent out, making it impossible for outsiders to judge whether the new stateroot is correct, which becomes “open eyes” blind". **
**If this happens, the entire Layer 2 network is equivalent to being scrapped, **because at this time, you have no idea what the Layer 2 ledger has become. If it is Layer 2 (Plasma and Optimium) based on fraud proof, the sorter can rewrite the data/assets under any account at will; if it is Layer 2 (Validium) based on validity proof, although the sorter cannot rewrite your account at will, this At that time, the entire Layer 2 network became a black box. No one knew what happened inside, and it was no different from being scrapped. Because of this, the orthodox Layer 2 solutions in the Ethereum ecosystem are basically Rollup, while Validium and Optimium are often not recognized by the Ethereum Foundation.
(Reference: Data Withholding and Fraud Proof: Why Plasma Doesn’t Support Smart Contracts)
Therefore, the reliability of the DA layer/availability of state transition parameters is more important and fundamental than the completeness of the fraud proof/validity proof system. **For Bitcoin Layer 2, especially Layer 2 based on the client verification model, even if there is no fraud proof/validity proof verification system on Layer 1, as long as the DA layer works as usual, everyone can still know whether there is an error in the L2 network state transition.
At present, it is difficult for the Bitcoin main network to verify fraud proof/validity proof (BitVM will not be discussed here). Let us first assume that Bitcoin L2 does not have a proof verification system. Ideally, if the L2 sorter really does evil and publishes a stateroot that is not related to DA data on the settlement layer/BTC, it still cannot truly steal user assets because it unilaterally submitted the stateroot / The result of the state transition will not be recognized by honest nodes, and in the end it may be just for self-pleasure.
*(****At this time, as long as the nodes run by ecosystem peripheral facilities providers such as exchanges and cross-chain bridges do not collude with the sequencer, the sequencer cannot quickly realize the stolen assets by publishing incorrect data .***After that, as long as one honest node discovers that something is wrong and issues an alarm at a critical moment, the error can be corrected through social consensus. However, the cost of social consensus itself is very high and cannot take effect immediately)
If it is a model similar to a side chain, where most nodes conspire to perform malicious state changes, people can quickly discover the problem. As long as third-party facilities such as cross-chain bridges and exchanges do not recognize erroneous data, the malicious controller of the Layer 2/side chain will not be able to successfully cash out, unless he convinces others to directly OTC with him on the chain.
(Viatlik once pointed out in the article that client verification is the real foundation to ensure the security of the blockchain network, Verify by yourself)
There is a very interesting point here. In fact, both Ethereum Layer 2 and Bitcoin Layer 2 can achieve “client verification”. However, on the basis of “client verification”, Ethereum Layer 2 relies on Layer 1 and the proof verification system to ensure the validity of state transitions and basically does not need to rely on social consensus (provided there is a mature fraud proof/validity proof system).
The “client verification” scheme of Bitcoin Layer 2 often has a strong reliance on “social consensus” and will bring corresponding risks (For Bitcoin Layer 2, this security risk is basically controllable, but it is still It may cause some people to lose assets. For Ethereum Layer 2, because its official bridge needs to prove the cooperation of the system, if the system is proved to be imperfect, the sequencer can steal user assets and run away on L1. Of course, the specific requirements See how to design the cross-chain bridge component).
Therefore, a Layer 2 that can implement a fraud proof/validity proof verification system on Layer 1 will always be much better than a simple “client verification” model. **
**PS: Since most Bitcoin Layer 2 that adopts the fraud proof/validity proof system cannot allow Layer 1 to directly participate in the proof verification process, its essence is still just treating Bitcoin as the DA layer, and the security model is equivalent to “customer end verification”. **
Theoretically, fraud proof can be verified on the Bitcoin chain through the BitVM solution on Layer 1. However, the implementation of this solution is very difficult and will encounter great challenges. Since the Ethereum community has already discussed a lot about the Layer1-based proof and verification system, which is already well known, this article does not intend to go into details about the “Layer1-based proof and verification system”.
Summarize
After a simple barrel model analysis, we can initially draw a conclusion**: In the mainstream Layer2 security model, according to the degree of importance/basic degree, it can be sorted as follows:**
Whether the control authority of the contract/official bridge is reasonably dispersed
Is there a censorship-resistant withdrawal function?
Is the DA layer/data release form reliable?
Whether a reliable fraud proof/validity proof system is deployed on Layer1
Of course, we did not analyze the Lightning Network/State Channel and ICP ecosystem’s ckBTC, Inscription Index Protocol and other solutions, because they are quite different from typical Rollup, Plasma, Validium or client verification solutions. Due to time constraints, it is difficult for us to conduct a prudent assessment of its safety and risk factors, but considering their significance, relevant assessment work will be carried out as scheduled in the future.
At the same time, there are serious differences among many project parties as to whether the Inscription Index Protocol should be regarded as Layer 2. However, regardless of the definition of Layer 2, new things such as the Inscription Index Protocol have brought sufficient technological innovation to the Bitcoin ecosystem. And will eventually burst out with great vitality.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Using the barrel theory to dismantle Bitcoin and Ethereum Layer 2 security models and risk indicators
Written by: Faust & Wuyue, geek web3
Advisor: Kevin He (@0xKevinHe), VP of Xinhuo Technology
Introduction: American management scientist Lawrence Peter once proposed the “barrel theory”, which believes that the overall performance of a system is limited by its weakest part. In other words, how much water a barrel can hold is determined by its shortest board. Although this principle is simple, it is often overlooked. **Previous debates on Layer 2 security mostly ignored the priority and importance of different components. They basically focused on state transition reliability and DA issues, but ignored the lower-level and more important elements. In this way, the entire theoretical foundation Probably not even tenable. Therefore, when we discuss a complex multi-module system, we must first find out which piece is the “shortest board.”
Inspired by the barrel theory, we did a system analysis and found that there are obvious dependencies between different components in the Bitcoin/Ethereum Layer 2 security model, or that some components are more secure than others. Sex is more basic and important, the so-called “shorter”.
In this regard, we can initially prioritize the importance/basis of different components in the mainstream Layer2 security model as follows:**
We should moderately absorb the research results of Layer 2 from the Ethereum community and avoid Lysenkoism
Compared with the highly ordered Ethereum Layer 2 system, Bitcoin Layer 2 is like a brand new world. This new concept, which has become increasingly important after the inscription craze, is showing rising momentum, but its ecological system is becoming increasingly chaotic and chaotic. Out of the chaos, various Layer 2 projects sprouted up like mushrooms after a rain. While they bring hope to the Bitcoin ecosystem, they deliberately conceal their own security risks. Some people even threatened to “deny Ethereum Layer 2 and follow the unique path of the Bitcoin ecosystem.” They have a strong tendency to take an extremist route.
Considering the differences in functional attributes between Bitcoin and Ethereum, Bitcoin Layer 2 is destined to be unable to align with Ethereum Layer 2 in the early days, but this does not mean that we should completely deny that Ethereum and even the modular blockchain industry have long had Industry common sense of final conclusion (refer to the “Lysenko incident” in which the former Soviet biologist Lysenko used ideological issues to persecute Western genetics supporters).
On the contrary, these evaluation standards, which were obtained by “predecessors” with great efforts, have already shown strong persuasiveness after being widely recognized. It is definitely not a rational move to deliberately deny the value of these achievements. **
**While building Bitcoin Layer 2, we should fully realize the significance of “learning from the West and applying it to the East” and appropriately absorb and optimize the many conclusions of the Ethereum community. But when drawing on perspectives outside the Bitcoin ecosystem, we must be aware of the differences in their starting points, and ultimately seek common ground while reserving differences. **
This is like discussing the similarities and differences between “Westerners” and “Easterners”. Regardless of whether it is Western or Eastern, the suffix “人” expresses many similar characteristics, but when corresponding to different prefixes such as “Western” and “Eastern”, the subdivision characteristics will be different.
But in the final analysis, there is bound to be an overlap between “Westerners” and “Easterners”, which means that many things that apply to Westerners are also applicable to Easterners, and many things that apply to “Ethereum Layer 2” , also applies to “Bitcoin Layer2”. **Before distinguishing the differences between Bitcoin L2 and Ethereum L2, it may be more important and meaningful to clarify the interoperability between the two.
Adhering to the purpose of “seeking common ground while reserving differences”, the author of this article does not intend to discuss “what is Bitcoin Layer 2 and what is not”, ** because this topic is too controversial, even the Ethereum community has not discussed “what is Ethereum Layer 2” , which ones are not Layer 2" and reach an objective and consistent view.
**But what is certain is that while different technical solutions bring expansion effects to Bitcoin, they also have different security risks. The trust assumptions existing in their security models will be the topic that this article intends to focus on. **
How to understand the security and evaluation criteria of Layer2
In fact, Layer 2 security is not a new discussion point. Even the word security is a composite concept that includes multiple subdivided attributes.
Previously, the founder of **EigenLayer had simply subdivided “security” into four elements including “transaction irreversibility (anti-rollback), censorship resistance, DA/data release reliability, and state transition validity.” **
(The founder of EigenLayer once expressed his views on how the client-side verification/sovereign rollup scheme can inherit the security of the Bitcoin mainnet)
L2BEAT and Ethereum Community OG have proposed a relatively systematic Layer 2 risk assessment model. Of course, these conclusions are aimed at smart contract Layer 2, rather than typical non-smart contract Layer 2 such as sovereign rollup and client verification.
**Although this is not 100% suitable for Bitcoin L2, it still contains many conclusions worthy of recognition. Most of its views have been widely recognized in the Western community, ** and it also facilitates our objective assessment of the risks of different Bitcoin L2.
(Vitalik once said that because the Rollup solution cannot achieve theoretical perfection in its early launch, it must use some auxiliary means to improve security, and these auxiliary means are called “training wheels” and will introduce trust assumptions. These trust assumptions are risks)
So where do security risks come from? Considering the current situation, whether it is Ethereum Layer 2 or Bitcoin Layer 2, many of them rely on centralized nodes to act as sequencers, or a small number of nodes forming a “committee” in the form of a side chain. These tend to be centralized. If the sequencer/committee is not restricted, it can steal user assets and run away at any time. It can refuse users’ transaction requests, causing assets to be frozen and unusable. **This involves the state transition effectiveness and censorship resistance mentioned by the founder of EigenLayer earlier. **
At the same time, since Ethereum Layer2 relies on contracts on the ETH chain for state transition verification and deposit and withdrawal behavior verification, if the contract controller (actually the official Layer2) can quickly update the contract logic, add malicious code segments (for example, Allowing a specified address to transfer all the tokens locked on the L1-L2 deposit and withdrawal contract), you can directly steal the assets under custody.
**This is attributed to the “contract multi-signature distribution problem”, and the multi-signature distribution problem also applies to Bitcoin Layer 2, ** because Bitcoin Layer 2 often relies on the “Notary Bridge” and requires multiple nodes to release through multi-signature Cross-chain requests, so Bitcoin Layer 2 also has the problem of how to reasonably distribute multi-signatures. We can even regard it as the most basic “auxiliary wheel” of Bitcoin Layer 2. **
**Also, the DA issue is extremely important. **If Layer2 does not upload data to Layer1, but chooses some unreliable DA release venues, if this off-chain DA layer (commonly known as the DAC Data Availability Committee) colludes and refuses to release the latest transaction data to the outside world, the data Withholding attacks will cause the network to become obsolete and may prevent users from withdrawing funds smoothly.
L2BEAT summarized the above issues and summarized several core elements in the Layer2 security model:
(“Risk factor display” set for different Layer2 projects on L2BEAT)
Anyway, when we analyze Layer 2 security risks, we are actually discussing how many scenarios exist in the Layer 2 network that may cause damage to user assets, and whether the Layer 2 system can effectively restrict these dangerous situations through mechanism design. **If certain malicious behaviors cannot be eliminated, how much “trust” do we need to introduce, how many individuals in a group need to be trusted, and how many “auxiliary wheels” do we need to rely on.
Below we will analyze the risk factors in the general Ethereum Layer2/Bitcoin Layer2 model** (The objects mentioned in this article do not include “state channel” or “payment channel”, nor does it include the inscription index protocol , because they are special). **And we will try to explore which factors are more basic, lower-level, and more important in the Layer 2 security model. These more basic shortcomings will be trust risks that deserve our attention more than other shortcomings.
The barrel effect of Layer2 - what are the shortcomings?
The shortest board - contract/official bridge management rights
Here, we might as well use the “barrel effect” to analyze Layer 2 security issues. It is easy to see that the shortest board is the “contract upgradeability” mentioned above (mainly for Ethereum Layer 2), or Furthermore, it is the “management right of the official cross-chain bridge” (applicable to both Bitcoin and Ethereum Layer 2). **
For Ethereum Layer 2, as long as the Layer 2 official can quickly upgrade the contract on the Layer 1 chain, the Token locked on the L2 official bridge deposit and withdrawal address can theoretically be stolen, no matter how reliable its DA layer or certification system is.
It can be said that the control authority of the bridge contract is related to the security of the entire system. It is the most basic and critical part of the entire Layer 2 and even the modular blockchain stack. **If the bridge component/contract can be updated and iterated under multi-signature control, then we need to introduce a “trust assumption” here, assuming that the controller of the Layer2 contract/official bridge will not do evil. **
(The contract upgrade delays of 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 a hacker, the user assets hosted by L2 Will definitely suffer)
Different from Ethereum Layer 2, the bridge of Bitcoin Layer 2 is basically not controlled by the contract on Layer 1, because Bitcoin does not originally support smart contracts. Relatively speaking, the entire workflow of Ethereum Layer2 is highly dependent on the contract on Layer1, while Bitcoin Layer2 cannot do this.
(Starknet schematic)
**This is an unavoidable problem for Bitcoin Layer 2. It can be said that it has both advantages and disadvantages. At present, it seems that the “trustless bridge” implemented by Ethereum Layer 2 relying on contracts cannot be realized in Bitcoin L2. **This “Trustless Bridge” requires the deployment of a dedicated contract on Layer1 and the cooperation of the DA+ fraud proof/ZK proof system. It is essentially similar to the “optimistic bridge” like Orbiter or ZK bridges such as Polyhedra.
The current mainstream view in the industry is that if you do not consider possible bugs in practice and only consider theoretical models, the security level of Optimistic Bridge and ZK Bridge is basically the highest level. As long as the contract code does not contain bugs or cannot be maliciously upgraded, It’s basically trustless.
(The Optimistic Bridge only needs to ensure that 1 out of N watchers is honest to ensure safety. The trust model is 1/N)
Since Bitcoin Layer 2 cannot deploy contract components on Layer 1 (we are not talking about the Lightning Network here), its official bridges are basically “** Notary Bridges” composed of a small number of nodes, or “Multi-Signature Bridges”. This kind of bridge The security depends on how multi-signature/threshold signatures are set up, which requires the introduction of strong trust assumptions: it is assumed that these notaries will not collude or have their private keys stolen. **
At present, most bridges based on notary/threshold signatures cannot be compared with the official “trustless bridge” of Ethereum Layer 2 in terms of security (the premise is that the contract of Ethereum Layer 2 will not be maliciously upgraded). Obviously, the asset security of **Bitcoin Layer 2 network custody will be limited by the security of its official bridge, or by the decentralization of power of the multi-signature bridge. This is its first “auxiliary wheel” . **
Since the “upgrade rights” of Ethereum Layer 2 official bridge-related contracts are often concentrated in the hands of a few multi-signature controllers, ** if the multi-signature controllers collude, the Ethereum Layer 2 bridge will also have problems, unless it The contract cannot be upgraded or is subject to a long delay** (currently only Degate and Fuel V1).
(Every time Degate contracts upgrade, it will reserve a 30-day safe escape period for users. During this period, as long as everyone finds that the new version of the contract code has malicious logic, they can escape safely through the forced withdrawal/escape cabin function)
Regarding the “official bridge” part, **The trust models of Ethereum Layer 2 and Bitcoin Layer 2 are basically the same: the controllers who need to trust the multi-signature will not collude to do evil. **This group of multi-signatures can control the L2 official bridge, or change it The code logic is to directly release invalid withdrawal requests, and the final result is: user assets may be stolen.
The only difference between the two is that Ethereum Layer 2’s official bridge is trustless as long as the contract is not maliciously upgraded/the upgrade window is long enough, but Bitcoin Layer 2 cannot achieve this effect anyway.
The second shortest board - censorship-resistant forced withdrawal
If we assume that the issue of multi-signature contracts/official bridge control mentioned above can be ignored, that is, there is no problem with this layer, then the next most important layer must be the censorship resistance of withdrawals.
Regarding the importance of the censorship-resistant forced withdrawal/escape cabin function, Vitalik emphasized in his article “Different types of layer 2s” a few months ago that whether users can successfully withdraw assets from Layer2 to Layer1 is a key factor. Very important safety indicator. **
If Layer 2’s sequencer keeps rejecting your transaction requests, or fails/is down for a long time, your assets will be “frozen” and nothing can be done. **Even if DA and fraud proof/ZK proof systems are available, without an anti-censorship solution, such Layer 2 is not secure enough and your assets can be detained at any time. **
What’s more, the Plasma solution, which was once very popular in the Ethereum ecosystem, allows anyone to safely withdraw assets to Layer 1 when the DA fails or the fraud proof fails. At this time, the entire Layer 2 network is basically scrapped, but there is still a way for your assets to escape unscathed. **Obviously, the censorship-resistant withdrawal function is more basic and lower-level than the DA and proof systems. **
(Dankrad of the Ethereum Foundation said that Plasma can still allow user assets to be safely evacuated when DA fails/users are unable to synchronize the latest data)
Some Ethereum Layer 2, such as Loopring, StarkEx, dYdX, Degate, etc., will set up a censorship-resistant forced withdrawal/escape cabin activation function on Layer 1. Taking Starknet as an example, if the user submits Forced on Layer 1 If the Withdrawal request does not receive a response from the Layer2 sequencer at the end of the 7-day window period, the freeze Request function can be manually called to put L2 into the frozen state and activate the escape cabin mode.
At this time, 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 a merkle proof to prove their asset status on Layer 2, and directly withdraw money on Layer 1 (actually, they take away their own equal amount of funds from the official bridge’s deposit and withdrawal address). **
Obviously, the escape hatch mode can only be implemented on a chain like Ethereum that supports smart contracts, and Bitcoin cannot run such complex logic. **In other words, the escape hatch function is basically a patent of Ethereum Layer 2. Bitcoin Layer 2 must use some additional auxiliary means to imitate the cat and the tiger. This is the second “auxiliary wheel”. **
**But simply stating 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 in the additional data of the transaction, declare the data that they want to submit to all Layer2 nodes (**This can directly bypass the sorter and send data to other Layer2 nodes node communicates the request). **If the “forced withdrawal” does not receive a response for a long time, it is a more reasonable design for the user to trigger the escape cabin mode.
(Reference: How important are the forced withdrawal and escape cabin functions for Layer2?)
**Currently, there are already Bitcoin Layer 2 teams that plan to imitate Arbitrum’s forced transaction implementation and allow users to issue forced transaction statements (Forced Transaction Envelopes) on the Bitcoin chain. **Under this solution, users can bypass the sequencer and “convey their voices” directly to other Layer2 nodes. If the sequencer still rejects the user’s request after seeing the user’s forced transaction statement, it will be noticed by other Layer 2 nodes and may be punished.
**But the problem is that Arbitrum’s forced transaction function, benefiting from its fraud proof system, can punish Sequencer/Proposer that has been ignoring user transactions. However, Bitcoin Layer 2, which is difficult to verify fraud proof on Layer 1, will encounter certain challenges in this regard. (Let’s not discuss BitVM for now) **If it is a solution such as sovereign Rollup, where the security level is not much different from client verification, it is difficult for us to seriously evaluate its reliability, and we may need to evaluate the implementation details of different projects.
Of course, given that many Bitcoin Layer 2 currently operate in a form similar to side chains, it is equivalent to realizing a ** decentralized sequencer, which can solve the anti-censorship problem to a certain extent. But this is only an effective auxiliary means, certainly not the ultimate solution. **
ps: Some current Layer 2 solutions, such as Validium, etc., are not perfect in the design of the escape cabin mechanism. When the sequencer launches a data withholding attack/DA is unavailable, users cannot withdraw money. But this is due to the imperfect design of the Layer 2 escape cabin. Theoretically, the optimal escape cabin withdrawal can only rely on historical data and does not need to rely on the availability of DA/new data)
The third shortest board: the reliability of DA layer data release
**Although DA is called data availability, this term actually refers to data release. **It is only because Vitalik and Mustafa did not think carefully when they originally named this concept that the name DA/data availability does not match. Real name.
**Data release, as the name suggests, refers to whether the latest blocks/transaction data/state transition parameters can be successfully received by those in need. **Publishing data on different chains has different reliability.
(Reference: Misunderstanding of data availability: DA=data release ≠ historical data retrieval)
Western communities generally believe that established public chains such as Bitcoin and Ethereum are the most trustworthy DA layers. If the Layer2 sorter publishes new data on Ethereum, anyone who runs the Ethereum geth client can download the data and synchronize it without any hindrance. **This is because This is achieved by the huge scale of the Ethereum network and the wide variety of public data sources.
**It is worth mentioning that Ethereum Rollup will force the sequencer to publish transaction data/state transition parameters on Layer1, which is guaranteed through validity proof/fraud proof. **
For example, after ZK Rollup’s sequencer publishes transaction data on Layer1, it will trigger the contract logic to generate a datahash, and the validator contract must confirm that the validity certificate submitted by the Proposer has a corresponding relationship with the datahash.
This is equivalent to: confirming that the zk Proof and Stateroot submitted by the Proposer are associated with the Tx data submitted by the Sequencer, that is, New Stateroot=STF(Old Stateroot, Txdata). STF is the state transition function.
**This ensures that the state transition data/DA is forcibly uploaded to the chain. If you only submit the stateroot and validity certificate, it will not be able to pass the verify of the validator contract. **
As for whether DA data release or proof verification system is more basic, the Ethereum/Celestia community has already had a full discussion. The general conclusion is: **The reliability of the DA layer is more important than the completeness of the fraud proof/validity proof system. **For example, solutions such as Plasma, Validium, and Optimium, where the DA layer is under the Ethereum chain and the settlement layer is on the Ethereum chain, are prone to "data withholding attacks", which means:
**Sequencer/Proposer can conspire with the DA layer nodes under the ETH chain to update the stateroot on Layer1, but the input parameters corresponding to the state transition are held back and not sent out, making it impossible for outsiders to judge whether the new stateroot is correct, which becomes “open eyes” blind". **
**If this happens, the entire Layer 2 network is equivalent to being scrapped, **because at this time, you have no idea what the Layer 2 ledger has become. If it is Layer 2 (Plasma and Optimium) based on fraud proof, the sorter can rewrite the data/assets under any account at will; if it is Layer 2 (Validium) based on validity proof, although the sorter cannot rewrite your account at will, this At that time, the entire Layer 2 network became a black box. No one knew what happened inside, and it was no different from being scrapped. Because of this, the orthodox Layer 2 solutions in the Ethereum ecosystem are basically Rollup, while Validium and Optimium are often not recognized by the Ethereum Foundation.
(Reference: Data Withholding and Fraud Proof: Why Plasma Doesn’t Support Smart Contracts)
Therefore, the reliability of the DA layer/availability of state transition parameters is more important and fundamental than the completeness of the fraud proof/validity proof system. **For Bitcoin Layer 2, especially Layer 2 based on the client verification model, even if there is no fraud proof/validity proof verification system on Layer 1, as long as the DA layer works as usual, everyone can still know whether there is an error in the L2 network state transition.
At present, it is difficult for the Bitcoin main network to verify fraud proof/validity proof (BitVM will not be discussed here). Let us first assume that Bitcoin L2 does not have a proof verification system. Ideally, if the L2 sorter really does evil and publishes a stateroot that is not related to DA data on the settlement layer/BTC, it still cannot truly steal user assets because it unilaterally submitted the stateroot / The result of the state transition will not be recognized by honest nodes, and in the end it may be just for self-pleasure.
*(****At this time, as long as the nodes run by ecosystem peripheral facilities providers such as exchanges and cross-chain bridges do not collude with the sequencer, the sequencer cannot quickly realize the stolen assets by publishing incorrect data .***After that, as long as one honest node discovers that something is wrong and issues an alarm at a critical moment, the error can be corrected through social consensus. However, the cost of social consensus itself is very high and cannot take effect immediately)
If it is a model similar to a side chain, where most nodes conspire to perform malicious state changes, people can quickly discover the problem. As long as third-party facilities such as cross-chain bridges and exchanges do not recognize erroneous data, the malicious controller of the Layer 2/side chain will not be able to successfully cash out, unless he convinces others to directly OTC with him on the chain.
(Viatlik once pointed out in the article that client verification is the real foundation to ensure the security of the blockchain network, Verify by yourself)
There is a very interesting point here. In fact, both Ethereum Layer 2 and Bitcoin Layer 2 can achieve “client verification”. However, on the basis of “client verification”, Ethereum Layer 2 relies on Layer 1 and the proof verification system to ensure the validity of state transitions and basically does not need to rely on social consensus (provided there is a mature fraud proof/validity proof system).
The “client verification” scheme of Bitcoin Layer 2 often has a strong reliance on “social consensus” and will bring corresponding risks (For Bitcoin Layer 2, this security risk is basically controllable, but it is still It may cause some people to lose assets. For Ethereum Layer 2, because its official bridge needs to prove the cooperation of the system, if the system is proved to be imperfect, the sequencer can steal user assets and run away on L1. Of course, the specific requirements See how to design the cross-chain bridge component).
Therefore, a Layer 2 that can implement a fraud proof/validity proof verification system on Layer 1 will always be much better than a simple “client verification” model. **
**PS: Since most Bitcoin Layer 2 that adopts the fraud proof/validity proof system cannot allow Layer 1 to directly participate in the proof verification process, its essence is still just treating Bitcoin as the DA layer, and the security model is equivalent to “customer end verification”. **
Theoretically, fraud proof can be verified on the Bitcoin chain through the BitVM solution on Layer 1. However, the implementation of this solution is very difficult and will encounter great challenges. Since the Ethereum community has already discussed a lot about the Layer1-based proof and verification system, which is already well known, this article does not intend to go into details about the “Layer1-based proof and verification system”.
Summarize
After a simple barrel model analysis, we can initially draw a conclusion**: In the mainstream Layer2 security model, according to the degree of importance/basic degree, it can be sorted as follows:**
Of course, we did not analyze the Lightning Network/State Channel and ICP ecosystem’s ckBTC, Inscription Index Protocol and other solutions, because they are quite different from typical Rollup, Plasma, Validium or client verification solutions. Due to time constraints, it is difficult for us to conduct a prudent assessment of its safety and risk factors, but considering their significance, relevant assessment work will be carried out as scheduled in the future.
At the same time, there are serious differences among many project parties as to whether the Inscription Index Protocol should be regarded as Layer 2. However, regardless of the definition of Layer 2, new things such as the Inscription Index Protocol have brought sufficient technological innovation to the Bitcoin ecosystem. And will eventually burst out with great vitality.