header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Scan to Download the APP

Blast triggers new thinking: Which is more important, technology or social consensus?

Read this article in 29 Minutes
The design of a mechanism that facilitates people to reach social consensus is more important, and this is actually the essence of Layer 2 and even blockchain.
Original title: "From Blast to Layer2 multi-signature backdoor: Which is more important, technology or social consensus?"
Original author: Faust, geek web3

Introduction: Blast's subtext in the face of Polygon zkEVM and other orthodox Layer2s may be "Are kings, princes, generals, and ministers of different species?"Since everyone is not trustless enough, and the essence is to rely on social consensus to ensure security, why criticize Blast's Layer2 concentration is not high enough, "Why are you so anxious to fight each other"?


Admittedly, Blast's reliance on 3/5 multi-signatures to control the recharge address has been widely criticized, but most Layer2s also rely on multi-signatures to manage contracts. Previously, Optimism even used only one EOA address to control contract upgrade permissions. At a time when almost all mainstream Layer2s have security risks such as multi-signature, criticizing Blast for being unsafe is more like the technical elites "looking down" on a gold farming project.


But putting aside the question of which of the above two is better, the significance of blockchain is more to solve the problem of information opacity in social consensus/democratic governance, and when advocating the supremacy of technology, we must admit that social consensus itself is more important than technology, because it is the basis for ensuring the effective operation of all Web3 projects. In the final analysis, technology serves social consensus, and projects that cannot be recognized by the majority, no matter how superior the technology is, are essentially just a gorgeous appendix.



Text: Recently, Blast, a new project launched by the founder of Blur, has become popular on the entire network. This "asset interest-bearing" protocol under the banner of Layer2 has set up a recharge address on the ETH chain. After users deposit funds into the Blast address, these funds will be used for ETH The profits from network native staking, placing in MakerDAO to earn interest, etc. will be returned to users.


Relying on the founder's own aura and attractive gameplay, Blast obtained $20 million in financing from investors led by Paradigm, and also attracted the participation of countless retail investors. Within less than 5 days of going online, the TVL attracted by Blast's recharge address exceeded $400 million. It is no exaggeration to say that BLast is like a powerful medicine in the long bear market, which instantly aroused people's enthusiasm.



However, while Blast has achieved phased success, it has also attracted doubts from many experts. For example, engineers from L2BEAT and Polygon both said: At present, Blast has only deployed a Deposit contract on Ethereum to receive deposits. This contract can be upgraded under the control of 3/5 multi-signatures. In other words, the code logic of the contract may be rewritten, and you can still use Rug if you want to. At the same time, Blast only claims to implement the Rollup structure, but now it is just an empty shell, and even the withdrawal function will have to wait until February next year.



And Blast also pointed out that most of the Rollups rely on a group of multi-signatures to manage contract upgrade permissions. Other Layer2s accusing "Blast of using multi-signatures" is just a case of the pot calling the kettle black.



Layer2 multi-signature is a long-standing problem


In fact, Layer2 contract multi-signature is a long-standing problem. As early as July this year, L2BEAT conducted a special investigation on the upgradeability of Rollup contracts. The so-called "upgradeability" is to change the logical contract address pointed to by the proxy contract to achieve the effect of changing the contract logic. If the new contract after the change contains malicious logic, the Layer2 official can steal the user's assets.


(Image source: wtf academy)


According to L2BEAT data, currently mainstream Rollups such as Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM, etc. all use multi-signature authorized upgradeable contracts, which can bypass time lock restrictions and upgrade immediately. (You can read previous articles of Geek Web3: Credit Game: Rollups controlled by multi-signatures and committees)



What is surprising is that Optimism used to only use an EOA address to manage contract upgrades, and even multi-signature was not added until October this year. As for the Polygon zkEVM, which once criticized Blast, it can also "emergency takeover" of the Rollup contract under the 6/8 multi-signature authorization, turning Layer2 from contract governance to "naked human governance". Interestingly, the Polygon engineer who criticized Blast above also mentioned this point, but was vague.




So what is the significance of this "emergency mode"? Why do most Rollups leave themselves an emergency button or backdoor? According to Vitalik's previous statement, Rollup needs to frequently update the contracts deployed on ETH during the iteration process. If upgradeable means such as proxy contracts are not introduced, it will be difficult to iterate efficiently.


In addition, smart contracts that host a large amount of assets may have subtle bugs, and the Layer2 development team is inevitably careless. If some loopholes are exploited by hackers, a large amount of assets may be stolen. Therefore, whether it is Layer2 or DeFi protocol, an emergency button is often set up, and "committee members" intervene when necessary to prevent certain malicious incidents from happening.



Of course, the committee set up by Layer2 can often bypass the time lock limit and upgrade the contract code immediately. From a certain perspective, they seem to be more taboo than external factors such as hackers. In other words, no matter what, smart contracts that hold huge amounts of assets are unlikely to be exempt from a certain degree of "trust assumption," that is, assuming that the multi-signature controllers behind the contract do no evil. Unless the contract is designed to be non-upgradeable and there are no bugs that could threaten the security of user assets.


The reality is that the current mainstream Layer2 either allows its own committee to update the contract immediately, or introduces a relatively short time lock limit (for example, anyone who wants to upgrade the dYdX contract will have a delay of at least 48 hours). If people discover that the committee intends to mix malicious logic for stealing assets into the new version of the contract code, users theoretically have enough time to react and urgently withdraw their assets from Layer1.


(For more information about forced withdrawal and escape hatch functions, please read our previous article "On Layer2 How important are the forced withdrawal and escape hatch functions?



(Time lock means that you are allowed to perform certain operations only after a delay)


But the key to the problem is that many Layer2s don’t even have a forced withdrawal function that can bypass the Sequencer. If such Layer2 officials want to do evil, they can first let the sequencer reject everyone’s withdrawal request, and then transfer the user’s assets to the L2 account controlled by the Layer2 official. After that, the official will update the Rollup contract according to their own needs, and after the time lock delay is over, all user assets can be transferred to the ETH chain.


Of course, the actual situation may be worse than what I said, because most Rollup officials can upgrade contracts without being restricted by time locks, that is to say, hundreds of millions of dollars can be completed almost instantly. rug.



A truly trustless Layer2 should make the contract upgrade delay longer than the forced withdrawal delay


In fact, to solve the Layer2 trust/security problem, the following things need to be done:


Set up a censorship-resistant withdrawal exit on Layer1, so that users can directly withdraw assets from Layer2 to the ETH chain without the permission of the sorter. The delay of forced withdrawal should not be too long, so as to ensure that user assets can be quickly withdrawn from L2;


Anyone who wants to upgrade the Layer2 contract must be subject to a time lock delay, and the contract upgrade should take effect later than the forced withdrawal. For example, the current dYdX contract upgrade has a delay of at least 48 hours, so the delay for the forced withdrawal/escape hatch mode to take effect should be reduced to within 48 hours. In this way, after users discover that the dYdX project party wants to mix malicious code into the new version of the contract, they can withdraw their assets from Layer2 to Layer1 before the contract is updated.


Currently, most of the Rollups that have launched the forced withdrawal/escape hatch mechanism do not meet the above conditions. For example, the forced withdrawal/escape hatch of dYdX has a maximum delay of 7 days, but the contract upgrade delay of the dYdX committee is only 48 hours, which means that the committee can complete the deployment of the new contract before the user's forced withdrawal takes effect, and steal the assets before the user escapes.



From this perspective, except Fuel, ZKSpace and Degate, other Rollups cannot guarantee that the forced withdrawal of users will be processed before the contract is upgraded, and all have a high degree of trust assumption.



Many projects that adopt the Validium solution (DA is implemented outside the Ethereum chain) have a long contract upgrade delay (such as 8 days or longer), but Validium often relies on the DAC node under the chain to publish the latest data, and DAC may launch a data withholding attack to invalidate the forced withdrawal function, so it does not meet the security model discussed above. (You can read our previous article "Expelling Validium? Re-understanding Layer2 from the perspective of the proposer of Danksharding")


At this point, we seem to be able to draw a concise and clear conclusion: Layer2 solutions other than Fuel, ZKSpace and DeGate are not trustless. Users either trust the Layer2 project party or the security committee they set up not to do evil, or trust the DAC nodes under the chain not to collude, or trust the sorter not to review your transactions (reject your requests). Currently, there are only three Layer2s that truly meet the requirements of security, anti-censorship and trustlessness.


Security is not only achieved by technology, but also requires the introduction of social consensus


In fact, the topic we are talking about today is not new. The fact that Layer2 essentially depends on the credit of the project party pointed out in this article has long been pointed out by countless people. For example, the founders of Avalanche and Solana have launched fierce attacks on this, but the problem is that these trust assumptions that exist in Layer2 also exist on Layer1 and even in all blockchain projects.


For example, we need to assume that the Validator nodes that account for 2/3 of the staking weight in the Solana network do not collude, and we need to assume that the top two mining pools that account for most of the Bitcoin computing power share do not unite to launch a 51% attack to roll back the longest chain. Although these assumptions are difficult to break, "difficult" does not mean "impossible".


Once a traditional Layer1 public chain has malicious behavior that causes a large number of user assets to be damaged, it will often end up abandoning the problematic chain and forking a new chain through social consensus (refer to the 2016 The DAO incident that caused Ethereum to fork into ETH and ETC). If someone attempts a malicious fork, everyone must also choose which "more reliable" fork to follow through social consensus. (For example, most people did not follow the ETHW project)



Social consensus is the root of ensuring the orderly operation of blockchain projects and even the DeFi protocols they carry. Even error correction mechanisms such as contract code audits and community members disclosing problems with a project are part of social consensus. Decentralization achieved solely by technology often does not play the greatest role, and often remains at the theoretical level.


What really works at critical moments is often social consensus that has nothing to do with technology, public opinion supervision that has nothing to do with academic papers, and mass recognition that has nothing to do with technical narratives.


We can imagine the following scenario: a POW public chain that only a few hundred people have heard of is temporarily in a highly decentralized state, because there is no monopoly yet. But if a mining machine company suddenly puts all its computing power into the POW chain, it will have many times more computing power than all other miners. At this time, the decentralization of this POW chain will be instantly disintegrated. If the mining machine company intends to do evil, people can only correct it through social consensus.



On the other hand, the so-called Layer2, no matter how sophisticated its mechanism design is, cannot avoid the link of social consensus. Even for L2s such as Fuel, DeGate and ZKSpace, which are almost impossible for the official to do evil, the Layer1-Ethereum they rely on is also highly dependent on social consensus/community-public opinion supervision.


Moreover, we believe that the contract cannot be upgraded because we listened to the statements of the contract auditing agency and L2BEAT, but these agencies may be negligent or lie. Although the probability is extremely low, we have to admit that it still introduces a small trust assumption.


But the open source nature of the blockchain itself allows anyone, including hackers, to check whether the contract contains malicious logic, which actually minimizes the trust assumption, which greatly reduces the cost of social consensus. If this cost is reduced to a low enough level, we can assume that this is "trustless".



Of course, except for the three mentioned above, other Layer2s do not have the so-called trustlessness at all. What really guarantees security at critical moments is still social consensus. The technical component is often just to facilitate people to carry out social consensus supervision. If a project has superior technology but cannot be widely recognized and cannot attract a large community group, then its decentralized governance and social consensus itself will be difficult to carry out effectively.


Technology is indeed important, but more often than not, whether it can be widely recognized and whether a strong community culture can be developed are more important, more valuable, and more conducive to project development than technology.


Let's take zkRollup as an example. Currently, many zkRollups only implement the validity proof system and DA data on the chain. It can prove to the outside world that all user transactions and transfers it processes are valid, not forged by the sorter, and there is no evil in the "state transition", but this is not the only scenario where Layer2 officials or sorters do evil.


We can roughly think that the ZK proof system essentially only greatly reduces the cost of people's supervision of Layer2, but many things cannot be solved by technology itself, and must rely on the intervention of human rule or social consensus.



If the L2 official does not set up anti-censorship exits such as forced withdrawals, or the official tries to upgrade the contract and mixes logic that can steal user assets, community members will have to rely on social consensus and public opinion fermentation to correct errors. At this moment, whether the technology is superior or not seems to no longer be the most important. Rather than saying whether technology is important for security, it is better to say that the mechanism design itself that facilitates people to develop social consensus is more important. This is actually the true meaning of Layer2 and even blockchain.


From Blast, which relies solely on social consensus for supervision, we should look at the relationship between social consensus and technical implementation more directly,rather than simply judging the pros and cons of a project based on "which L2 is closer to the Layer2 in vitalik's mouth than another L2". When a project has gained the recognition and attention of hundreds of millions of people, social consensus has been formed. It doesn't matter whether it relies on marketing or technical narrative, because the result itself is more important than the process.


It is true that social consensus itself is an extension of democratic politics, and the real world has confirmed the defects of democratic governance, but the open source and data transparency of the blockchain itself have greatly reduced the cost of social consensus. Therefore, Web3's "rule by man" is essentially different from the "rule by man" of real sovereign states.


If we regard blockchain itself as a technical means to improve the problem of information transparency in democratic governance, rather than simply pursuing the unattainable "Trustless achieved purely by code", everything seems to become more optimistic and clear. Only by getting rid of the arrogance and prejudice inherent in the technical elite and embracing a wider audience, can the Ethereum Layer2 system truly become a world-class financial infrastructure with mass adoption.


Original link



Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia

Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit