From Blast to Layer2 Multi-Signature Backdoor: Which is More Important, Technology or Social Consensus?

Author: Faust, Geek Web3

Introduction: The underlying implication of Blast facing traditional Layer2s like Polygon zkEVM might be "Are nobles and ministers born of a different kind?" Since everyone is not sufficiently decentralized, and the essence relies on social consensus to ensure security, why criticize Blast for not having a high enough Layer2 concentration? "Why rush to harm each other?"

Indeed, Blast's reliance on a 3/5 multi-signature to control the deposit address has been widely criticized, but most Layer2s also manage contracts through multi-signatures. Previously, Optimism even used a single EOA address to control contract upgrade permissions. In a landscape where mainstream Layer2s almost all have security risks like multi-signatures, criticizing Blast for being unsafe seems more like a disdain from technical elites towards a gold mining project.

However, setting aside the question of which is better, the significance of blockchain lies more in solving the issue of information transparency in social consensus/democratic governance. While promoting technological supremacy, we must acknowledge that social consensus itself is more important than technology, as it is the foundation that guarantees the effective operation of all Web3 projects. Ultimately, technology serves social consensus; projects that cannot be recognized by the majority, no matter how superior the technology, are essentially just a beautiful appendix.

Main Text: Recently, the new project Blast launched by the founder of Blur has gone viral online. This "asset earning" protocol, which claims to be Layer2, has set up a deposit address on the ETH chain. After users deposit funds into the Blast address, these funds will be used for native ETH staking, placed into MakerDAO to earn interest, etc., with the profits returned to users.

With the founder's aura and attractive gameplay, Blast secured $20 million in funding from investors led by Paradigm, attracting countless retail participants. Within less than 5 days of launch, the TVL attracted by the Blast deposit address exceeded $400 million. It is no exaggeration to say that Blast is like a powerful medicine in the long bear market, instantly igniting people's enthusiasm.

However, while Blast has achieved phased success, it has also drawn skepticism from many experts. For instance, both L2BEAT and Polygon engineers pointed out that the current Blast is merely a Deposit contract deployed on Ethereum to receive deposits, which can be upgraded under the control of a 3/5 multi-signature. In other words, the contract's code logic could be rewritten, and it could still be rug-pulled. At the same time, Blast claims to implement a Rollup structure, but currently, it is just an empty shell, with the withdrawal function not expected to launch until February next year.

Blast also countered that the vast majority of Rollups rely on a group of multi-signatures to manage contract upgrade permissions, and other Layer2s criticizing "Blast for using multi-signatures" is merely a case of the pot calling the kettle black.

Multi-signature in Layer2 is a long-standing issue

In fact, the issue of multi-signatures in Layer2 contracts has existed for a long time. As early as July this year, L2BEAT conducted a special survey on the upgradability of Rollup contracts. The so-called "upgradable" refers to changing the logic contract address that the proxy contract points to, achieving the effect of changing the contract logic. If the new contract contains malicious logic, the Layer2 officials could steal user assets.

Image Source: wtf academy

According to L2BEAT's data, mainstream Rollups like Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet, and Polygon ZKEVM all adopt upgradable contracts authorized by multi-signatures, allowing them to bypass time lock restrictions and upgrade immediately. (You can read previous articles from Geek Web3: The Game of Trust: Rollups Controlled by Multi-signatures and Committees)

Interestingly, Optimism previously managed contract upgrades with just one EOA address, and multi-signatures were only added in October this year. As for Polygon zkEVM, which criticized Blast, it can also "emergency take over" Rollup contracts under 6/8 multi-signature authorization, turning Layer2 governance from contract governance to "naked human governance." Interestingly, the Polygon engineer who criticized Blast also mentioned this point but was vague in expression.

So what is the significance of this "emergency mode"? Why do most Rollups need to leave themselves an emergency button or backdoor? According to Vitalik's previous statements, Rollups need to frequently update the contracts deployed on ETH during iteration. Without introducing proxy contracts or other upgradable means, efficient iteration becomes difficult.

Moreover, smart contracts that hold a large amount of assets may have subtle bugs, and Layer2 development teams may inevitably overlook them. If certain vulnerabilities are exploited by hackers, it could lead to significant asset theft. Therefore, both Layer2 and DeFi protocols often set up an emergency button, allowing "committee members" to intervene when necessary to prevent certain malicious events from occurring.

Of course, the committees set up in Layer2 can often bypass time lock restrictions to immediately upgrade contract code. From a certain perspective, they seem to be more concerning than hackers or other external factors. In other words, no matter what, smart contracts that manage huge assets cannot escape a certain degree of "trust assumption," which assumes that the multi-signature controllers behind the contracts do not act maliciously. Unless the contract is designed to be non-upgradable and there are no bugs that threaten user asset security.

The reality is that current mainstream Layer2s either allow their established committees to update contracts immediately or have relatively short time lock restrictions (for example, anyone upgrading the dYdX contract has at least a 48-hour delay). If people discover that the committee intends to incorporate malicious logic into the new contract code, users theoretically have enough time to urgently withdraw their assets from Layer1.

(Regarding forced withdrawals and escape pod functions, you can read our previous article: "How Important Are Forced Withdrawals and Escape Pod Functions for Layer2?")

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

But the key issue is that many Layer2s have not even set up forced withdrawal functions that can bypass Sequencer sorting. Such Layer2 officials can act maliciously by first having the sorter reject everyone's withdrawal requests, then transferring user assets to Layer2 accounts controlled by the officials. Afterward, the officials can update the Rollup contract as needed, and once the time lock delay ends, they can transfer all user assets to the ETH chain.

Of course, the actual situation may be worse than I described, as most Rollup officials can upgrade contracts without time lock restrictions, meaning they can almost instantly execute rug pulls worth hundreds of millions of dollars.

Truly decentralized Layer2 should have contract upgrade delays greater than forced withdrawal delays

In fact, to solve the decentralization/security issues of Layer2, the following must be achieved:

Set up a censorship-resistant withdrawal outlet on Layer1, allowing users to transfer assets from Layer2 to the ETH chain without the sorter’s permission. The forced withdrawal delay should not be too long, ensuring that user assets can quickly exit from L2;

Anyone upgrading Layer2 contracts must be subject to time lock delay restrictions, and contract upgrades should take effect after forced withdrawals. For example, if dYdX's contract upgrades have at least a 48-hour delay, then the forced withdrawal/escape pod mode should also have a delay of less than 48 hours. This way, if users discover that the dYdX project team intends to incorporate malicious code into the new contract, they can withdraw their assets from Layer2 to Layer1 before the contract updates.

Currently, the vast majority of Rollups that have implemented forced withdrawal/escape pod mechanisms do not meet the above conditions. For instance, dYdX's forced withdrawal/escape pod has a maximum delay of 7 days, but the dYdX committee's contract upgrade delay is only 48 hours, meaning the committee can deploy the new contract before the user's forced withdrawal takes effect, stealing assets before users can escape.

From this perspective, apart from Fuel, ZKSpace, and DeGate, other Rollups cannot guarantee that user forced withdrawals will be processed before contract upgrades, all having a high degree of trust assumption.

Many projects using Validium solutions (DA implemented off-chain) have long contract upgrade delays (e.g., 8 days or longer), but Validium often relies on off-chain DAC nodes to publish the latest data, and DACs may launch data withholding attacks, rendering the forced withdrawal function ineffective, thus not conforming to the safety model discussed above. (You can read our past article: "Expelling Validium? Reinterpreting Layer2 from the Perspective of the Danksharding Proposer")

At this point, we can succinctly conclude that Layer2 solutions other than Fuel, ZKSpace, and DeGate are not decentralized. Users either trust the Layer2 project team or its established security committee not to act maliciously, trust off-chain DAC nodes not to collude, or trust that the sorter will not censor their transactions (reject their requests). Currently, only the three mentioned above truly meet the criteria for security, censorship resistance, and decentralization.

Security relies not only on technology but must also incorporate social consensus

In fact, the topic we are discussing today is not new; the essence of Layer2 relying on the project's credit has long been pointed out by countless people. For example, the founders of Avalanche and Solana have both fiercely criticized this, but the issue is that these trust assumptions present in Layer2 also exist in Layer1 and all blockchain projects.

For instance, we need to assume that the Validator nodes holding 2/3 of the staking weight in the Solana network do not collude, and we need to assume that the two largest mining pools holding most of Bitcoin's hash power 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."

When traditional Layer1 public chains experience malicious acts that lead to significant user asset losses, they often resolve the issue through social consensus by abandoning the problematic chain and forking a new one (refer to the 2016 DAO incident that led to the Ethereum 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 team.)

Social consensus is the root of ensuring that blockchain projects and the DeFi protocols they carry operate in an orderly manner. Even contract code audits and community members disclosing issues with certain projects are part of social consensus. Relying solely on technology to achieve decentralization often does not maximize its effectiveness and frequently remains at the theoretical level.

What truly plays a role at critical moments is often social consensus, which is unrelated to technology, public opinion supervision unrelated to academic papers, and public recognition unrelated to 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 no single entity has emerged as dominant. However, if a mining machine company suddenly invests all its hash power into this POW chain, its hash power would far exceed that of all other miners combined, instantly dismantling the decentralization of this POW chain. If this mining machine company intends to act maliciously, people can only rely on social consensus to correct the situation.

In contrast, so-called Layer2, no matter how exquisitely designed its mechanism, cannot escape the link of social consensus. Even for Layer2s like Fuel, DeGate, and ZKSpace, which are almost incapable of malicious acts by officials, the Layer1 they rely on—Ethereum itself—is also highly dependent on social consensus/community—public opinion supervision.

Moreover, our belief that contracts are non-upgradable is based on the statements of contract auditing agencies and L2BEAT, but these agencies may overlook or lie. Although this probability is very low, we must admit that we still introduce a slight trust assumption.

However, the open-source nature of blockchain data allows anyone, including hackers, to check whether contracts contain malicious logic, which has minimized the trust assumption and significantly reduced the cost of social consensus. If this cost is reduced to a sufficiently low level, we can assume that this is "decentralization."

Of course, apart from the three mentioned above, other Layer2s do not have so-called decentralization. What truly ensures security at critical moments is still social consensus; the technical component often merely facilitates social consensus supervision. If a project's technology is superior but fails to gain widespread recognition and attract a large community, then its decentralized governance and social consensus are also unlikely to be effectively realized.

Technology is indeed important, but more often, whether it can be widely recognized and whether it can develop a strong community culture are factors that are more important, valuable, and beneficial to project development than technology.

Let us take zkRollup as an example. Currently, many zkRollups have only implemented validity proof systems and DA data on-chain. They can prove externally that the user transactions they process and all transfers are valid and not fabricated by the sorter, and they have not acted maliciously in "state transitions." However, the scenarios in which Layer2 officials or sorters act maliciously are not limited to this.

We can approximate that the ZK proof system essentially only greatly reduces the cost of supervision over Layer2, but many issues cannot be resolved by technology alone; they must rely on human intervention or social consensus.

If Layer2 officials do not set up forced withdrawal or other censorship-resistant outlets, or if the officials attempt to upgrade contracts and incorporate logic that can steal user assets, community members will have to rely on social consensus and public opinion fermentation to correct the situation. At this moment, the superiority of technology seems no longer the most important factor. Rather, it is the mechanism design that facilitates social consensus that is more important; this is essentially the true essence of Layer2 and blockchain.

From the purely socially consensus-supervised Blast, we should more directly view the relationship between social consensus and technological implementation, rather than simply judging a project's merits based on "which Layer2 is closer to the Layer2 described by Vitalik." When a project has gained the recognition and attention of hundreds of millions, social consensus has already formed. Whether this is achieved through marketing or technical narratives is irrelevant, as the outcome itself is more important than the process.

Indeed, social consensus itself is an extension of democratic politics, and the real world has proven the flaws of democratic governance. However, the open-source and transparent data inherent in blockchain significantly reduces the cost of social consensus. Therefore, the "human governance" of Web3 is fundamentally different from the "human governance" of real sovereign states.

If we view blockchain itself as a technological means to improve the information transparency issues in democratic governance, rather than merely pursuing the ever-elusive "trustless achieved solely by code," everything seems much more optimistic and clear. Only by shedding the arrogance and prejudice held by technological elites and embracing a broader audience can the Ethereum Layer2 ecosystem truly become a world-class financial infrastructure for mass adoption.