Rollup's biggest trust risk: the problem of "rule of man" that cannot be ignored

Author: Link, Geek Web3

Introduction: Since the gradual decline of Solana and the release of Token by OP, Layer2 and Rollup seem to have become the new havens for countless Web3 practitioners. As the bear market continues to spread, FTX is out of the game, and Multicoin suffers heavy losses, Ethereum's competitors have gradually faded out of the Web3 stage, and they have continuously lost the confidence to compete with ETH. More and more people began to regard Rollup as the core of a new round of narrative, and more and more projects sprung up on L2 like mushrooms after rain.

But is all this "false prosperity" or a "bubble that may be burst at any time"? Are Rollup and L2 really as good as most people claim? Is it really as safe as people think it is? Not to mention that many OP Rollups do not have fraud proofs, what are the security risks of **Rollups? **

Inspired by the "Upgradeability of Ethereum L2s" recently released by L2BEAT, this article focuses on the multi-signature and committee trust risks behind the Rollup upgrade (immediately upgrade the Rollup contract, taking away user assets) and the previous clichés about Rollup. Reminiscent of the recent Multichain, we will talk about why L2 is not as "beautiful" as many people think.

Brief description of Rollup principle

A brief description of the operating principle of Rollup:

**Ethereum Rollup = a set of contracts on Layer1 + Layer2 network's own nodes. **

The group of Layer 2 network nodes can be divided into several types of roles, the most important of which is the sequencer (Sequencer). It receives transaction requests that occur on Layer2, determines their execution order, and then packages the transaction sequence into a batch (Batch), which is sent to the contract of the Rollup project on Layer1 (hereinafter collectively referred to as the Rollup contract).

The full node of Layer2 can directly obtain the transaction sequence from the sequencer, or read the transaction batch (Batch) sent by the sequencer to Layer1, but the latter has higher final certainty (unchangeability) than the former. Usually, when a batch of transactions is sent to Layer1 by the sequencer, the order of the batch of transactions cannot be changed (as long as there is no block rollback in Ethereum, the transaction sequence of Rollup will not change).

Since transaction execution will change the state of the blockchain ledger, in addition to the order of transactions, the Layer 2 full node also needs to synchronize the state of the ledger with the sequencer, so as to ensure consistency.

Therefore, the sequencer not only needs to transmit transaction batches to Layer1’s Rollup contract, but also transmits the state update results (Stateroot/State diff) after transaction execution to Layer1.

It is not difficult to see that L1 (Ethereum) actually acts as a bulletin board for L2 nodes, which is far more decentralized, trustless, and safer than L2's own network. For L2 full nodes, as long as they obtain the Rollup transaction sequence on L1 + the initial Stateroot, they can restore the L2 blockchain ledger and calculate the latest Stateroot. If the Stateroot calculated by the L2 full node itself is inconsistent with the Stateroot published by the sequencer to L1, it means that the sequencer has fraud.

The most intuitive hypothetical case is: L2's sequencer can steal user assets. For example, can it forge some transactions that should not have occurred (ps: transfer some L2 user's Tokens to the address of the sequencer operator, and then transfer these Tokens to L1). This kind of question can be boiled down to: What to do after the sequencer publishes wrong transaction data or wrong Stateroot? **

For the fraud risk of the sequencer, different types of Rollup have different countermeasures. Optimistic Rollup (Optimistic Rollup) allows L2 full nodes to provide fraud proofs (Fraud Proof), proving that the data released by the sequencer in L1 has errors. For example, Arbitrum has set up a node whitelist, allowing the L2 nodes on the whitelist to issue fraud proofs.

In addition, considering that most exchanges and private cross-chain bridge project parties will run L2 full nodes, errors can be found immediately, and the success rate of most Rollup sequencers stealing coins is basically 0 (because it needs to be cashed out in the end, it still needs to be completed on the exchange, or the stolen coins can be transferred to L1 and then find another way out).


(The Aggregator in the figure is actually a sequencer)

But for Optimism without fraud proof, the sequencer can steal coins through Rollup's own cross-chain bridge contract. For example, the sequencer operator can forge transaction instructions, transfer other people's assets in L2 to their own address, and then transfer the stolen coins to L1 through Rollup's built-in bridge contract. Because there is no fraud proof, the OP's full node cannot challenge the wrong transaction, so in theory, OP's sequencer can steal the user's assets in L2 (as long as it really wants to do so).

The solution to this kind of problem is "social consensus" (supervised by public opinion such as community members and social media), or **relying on OP's official credit endorsement. **

Interestingly, an exchange has recently reduced the delay for Arbitrum and Optimism users to transfer coins to the exchange (from 100 L2 blocks to 1 L2 block), which is actually to trust that the sequencers of ARB and OP will not do evil** (by default they are centralized servers with official endorsement)**.

Unlike optimistic Rollup, in addition to relying on L2 full nodes, ZK Rollup solves the problem of sequencer fraud through Validity Proof (often confused with ZK Proof). There is a node called Prover in the ZK Rollup network, which is designed to generate validity proofs for the transaction batches issued by the sequencer. At the same time, there is a contract (generally called Verifier) on L1 that specifically verifies the validity certificate. As long as the transaction batch and the certificate corresponding to Stateroot/State diff pass the verification of the Verifier contract, it will be finalized (Finalized). The official bridge of ZK Rollup will only release the withdrawal transactions verified by the validity certificate, which is obviously much more reliable than Optimism.

In theory, the security of OP Rollup is guaranteed by L2 full nodes (at least one honest node that can issue fraud proofs). The security of ZK Rollup is guaranteed by the Verifier contract on L1 (the transaction is finally confirmed by the L1 node). On the surface, they can all "inherit the security of L1" (with the help of L1 to complete the final confirmation/settlement of the transaction), and Ethereum maximalists even call it "equivalent to the security of L1" (consistent with the finality of L1's transaction results), but the actual situation is not the case, or even far from it.

Those "cliche" points

First of all, ZK Rollup's validity proof generation speed is extremely slow, the sequencer can execute thousands of transactions in 1 second, but it may take several hours at most to generate Proof for these thousands of transactions. But this problem is also easy to solve. The mainstream ZKR basically divides the Proof generation task and sends it to different Prover nodes for parallel processing to greatly increase the speed of Proof generation.

Second, it is necessary to consider the delay of L2 nodes publishing data in L1. Because each time the sequencer or Prover sends data to L1, there will be a fixed cost (like a container is consumed for each shipment). Frequently publishing data on L1 is not cost-effective or even at a loss, so the sequencer and Prover will minimize the frequency of publishing data on L1, and then package and release a large amount of data at one time.

In other words, when the number of users is insufficient and the number of transactions initiated is insufficient, the sequencer will delay releasing data to L1. For example, when there were few users last year, Optimism only sent a transaction batch to L1 every half an hour. Now, because the number of users has increased, this problem has been effectively solved. Different from the OP, Starknet has adopted a method of reducing the frequency of State diff releases to reduce data costs, which makes Starknet's transaction final confirmation delay extended to 7-8 hours.

In addition, most ZK Rollups often "aggregate many proofs and send them to L1 at one time" in order to further reduce costs. That is to say, Prover will not send to L1 immediately after generating a Proof, but wait for multiple Proofs to be generated, aggregate them together, and then send to the Verifier contract of L1. (In fact, the process of aggregating Proofs is to use one Proof to include the calculation steps generated by verifying multiple Proofs)

The consequence of this is that the frequency of Proof releases is further reduced, and the delay from transaction initiation to final confirmation is further lengthened.

According to the block explorer, **Polygon ZKEVM’s transaction confirmation delay is about 30-50 minutes, and Starknet and Zksync Era are more than 7 hours. **Obviously this is only "partially inheriting the security of L1", which is far from the "security equivalent to L1" that Ethereum supporters say.

Of course, the above problems can all be solved by technological progress, and will be realized in the near future. For example, many project parties are developing high-performance hardware to reduce the generation time of validity proofs; Optimism also promises to release a fraud proof system soon; Ethereum’s Danksharding solution will reduce the data cost of Rollup by dozens of times or even higher, which can effectively solve the problems listed above.

Difficult to solve "rule of man" problem

Like application projects such as Defi, the operation of the Rollup network depends on the relevant contracts on L1, and these contracts are "upgradable", which means that some codes can be replaced (most Rollups use proxy contracts), and can be carried out immediately under the authorization of multi-signature or security committee. Let me talk about the conclusion first: **Rollup can quickly change the contract code on L1 through a multi-signature or security committee controlled by a few people, and then steal user assets. **

First of all, "why the Rollup contract needs to be upgraded" and "how is it upgraded". The contract code on Ethereum cannot be changed after deployment, but Rollup inevitably has various bugs during the development process, which may lead to wrong results; at the same time, Rollup is also undergoing frequent product iterations, and new functions need to be added frequently; in more extreme cases, there may be hackers attacking the Rollup contract, so the Rollup contract needs to be upgradable, which is often achieved through proxy contracts.

The proxy contract is actually a method commonly used in Ethereum contract development, which is to separate the data of the contract from the business logic and store them in different contracts. Data (state variables) are stored in proxy contracts, and business logic (functions) are stored in logic contracts. The proxy contract (Proxy) entrusts the execution process of the function to the logic contract (Implementation) through delegatecall, and then returns the final result to the caller (Caller).

To upgrade the contract in the proxy mode, you only need to point the proxy contract to the new logic contract (rewrite the address of the logic contract stored in the proxy contract). **Most Rollup projects have adopted this method of contract upgrade, which can be described as simple and rude. **

It is not difficult to imagine that Rollup’s contract can be upgraded is actually a huge thunder: if the upgraded contract contains malicious code, such as modifying the withdrawal release conditions of Rollup’s built-in Bridge contract, or modifying the conditions of the Verifier contract to determine validity and prove correctness, the sequencer can steal coins (the principle is mentioned earlier).

But the problem is that the Rollup contract cannot be allowed to be upgraded. The reason is very clear. On balance, the vast majority of Rollup will decide whether to upgrade the Rollup contract through DAO governance, security committee or multi-signature authorization. In addition, the time lock Timelock will be used to set a delay window period for contract upgrades.

Considering that most DAO proposals have an automated execution process (implemented through on-chain contracts), even if the contract is to be upgraded, enough votes must be obtained first, and then the operation of upgrading the contract will only be executed after the delay specified by the Timelock (often many days). If someone wants to engage in malicious contract upgrades, they need to overcome the DAO governance through governance attacks (such as the governance attacks that occurred on Tornado Cash), but the cost of doing so is very high, and they must first obtain enough Tokens, which will not succeed under normal circumstances. Even if the governance attack is successful, due to the time lock, users will have enough time to withdraw assets from L2, and **Rollup officials will have enough time to take emergency measures. **

It looks like timelocks are the magic weapon against malicious contract upgrades. But the problem is that the so-called "emergency measures that Rollup officials can take" are actually bypassing DAO governance and time locks, and immediately upgrading the Rollup contract through multi-signature or security committee authorization. Considering that the current mainstream Rollup hosts billions of dollars in user assets, the "immediate upgrade of the contract" authorized by the multi-signature and security committee is the ultimate emergency measure, but it is also the sword of Damocles hanging over the heads of all users.

Obviously this is a matter of maximizing trust: you need to trust that Rollup officials will not have the idea of stealing your assets. If you consider it from the perspective of Trustless (Nick Szabo’s perspective), **all Rollups controlled by multi-signature and security committees are insecure. **Emin Gun Sirer, the founder of Avalanche, Anatoly, the founder of Solana, and Justin Bons, the famous sunspot, have all emphasized this kind of problem.

Which Rolllups are manipulated by multisigs/committees?

According to the report "Upgradeability of Ethereum L2s" released by the well-known L2 research institution L2 BEAT, and the L2BEAT data visualization website, **Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM and other mainstream Rollups all have multi-signature or committee-authorized upgradeable contracts, and can bypass time lock restrictions. **

Although dYdX has an EOA address that can bypass the DAO governance upgrade contract, it is limited by a time lock (at least 2 days of delay). Immutable X has a 14-day contract upgrade delay. Therefore, according to L2BEAT, **dYdX and Immutable X are more trustless than other mainstream Rollups that have launched the mainnet. **

**So how to reduce the trust risk brought by multi-signature and safety committee? **The answer is actually similar to the Multichain incident: it can be attributed to the anti-witch problem. It must be ensured that multisigs/committees are controlled by multiple different entities with no high degree of overlapping interests and low risk of collusion. At present, it seems that there is no good way except to increase the maturity of DAO's decentralized governance and invite famous and reputable celebrities or institutions to participate in multi-signature/committee. The above scenario seems to have been common in real-world democracies.

Of course, it is also possible to limit the contract upgrade behavior managed by multi-signature/committee through time lock, but this needs to be weighed against many factors, because the purpose of multi-signature/committee is to quickly deal with some emergency situations; at the same time, if the Rollup project party does not have a firm determination on the issue of trustlessness, this problem cannot be solved.

Therefore, although different Rollup projects can guarantee the security of user assets most of the time through sophisticated mechanism design, the probability of a black swan event in Rollup is not zero due to the existence of multi-signatures and committees. Even if the probability of multi-sig and committee member collusion is only 1 in 10,000, considering the value of assets under L2 custody (assumed to be 10 billion US dollars), the risk of L2 user assets is still as high as 1 million US dollars per day. Reminiscent of the Multichain incident, it is really creepy.

So I personally think that, as Polynya said before, most of the funds in the Ethereum ecosystem will still tend to circulate and lock in L1 rather than L2, and the Rollup ecosystem will not be able to capture most of the value in the Ethereum ecosystem in the long run. For large investors and whales, the Ethereum mainnet is obviously a more suitable and reliable place to go for funds than L2. Therefore, many people have considered "whether the rise of L2 will lead to the desertion of L1", in fact, they already have the answer.

As Keigo Higashino said in his book, the human heart is far more elusive, harder to understand, more complicated, and harder to change than mathematical formulas. Many things cannot be solved by purely technical means, but any factor involving "human nature" will always be the most uncontrollable, unpredictable, and most serious problem in this world. Here, please let us keep in mind the classic sentence on Kant's tombstone:

"Two things have always surrounded my mind, and the more I think about them the more amazement and awe they evoke in me: the moral law within and the starry sky above.