The Game of Credit: Rollups Controlled by Multi-Signatures and Committees

Author: Link, Geek Web3

Since the gradual decline of Solana and the issuance of tokens by OP, Layer2 and Rollup seem to have become a new haven for countless Web3 practitioners. As the bear market continues to spread and FTX collapses, Multicoin suffers heavy losses, Ethereum's competitors have gradually faded from the grand stage of Web3, continuously losing the confidence to compete with ETH. More and more people are beginning to view Rollup as the core of a new narrative, with an increasing number of projects emerging like mushrooms after rain on L2.

But is all this a "false prosperity"? Is it a "bubble that could burst at any time"? Are Rollup and L2 really as good as most people claim? Are they really as safe as people perceive? Not to mention that many OP Rollups lack fraud proofs, what other security risks do Rollups have?

This article is inspired by the recent release of "Upgradeability of Ethereum L2s" by L2 BEAT, focusing on the trust risks of multi-signature and committees behind Rollup upgrades, as well as the old discussions about Rollup. It also draws connections to the recent Multichain incident, discussing why L2 may not be as "good" as many people think.

Brief Overview of Rollup Principles

Brief overview of how Rollup operates:

Ethereum Rollup = A set of contracts on Layer1 + Nodes of the Layer2 network.

The group of Layer2 network nodes can be divided into several roles, among which the most important is the Sequencer. It receives transaction requests occurring on Layer2, decides their execution order, and then packages the transaction sequence into batches, sending them to the Rollup project’s contract on Layer1 (hereinafter referred to as the Rollup contract).

Interaction logic diagram of Starknet

Layer2 full nodes can directly obtain transaction sequences from the Sequencer or read the transaction batches sent by the Sequencer to Layer1, but the latter has higher finality (immutability) than the former. Typically, once a batch of transactions is sent to Layer1 by the Sequencer, the order of that batch cannot be changed (as long as Ethereum does not experience a block rollback, the Rollup transaction sequence will not change).

Since transaction execution alters the state of the blockchain ledger, Layer2 full nodes also need to synchronize the ledger state with the Sequencer to ensure consistency.

Therefore, the Sequencer not only needs to send transaction batches to the Rollup contract on Layer1 but also needs to send the state update results after transaction execution (State root / State diff) to Layer1.

It is clear that L1 (Ethereum) actually acts as a bulletin board for L2 nodes, being much more decentralized, trustless, and secure 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 reconstruct the L2 blockchain ledger and calculate the latest Stateroot. If the Stateroot calculated by the L2 full node does not match the Stateroot published by the Sequencer on L1, it indicates that the Sequencer has committed fraud.

The most intuitive hypothetical case is: Can the L2 Sequencer steal user assets? For example, can it forge some transactions that should not have occurred (e.g., transferring certain L2 users' tokens to the address of the Sequencer operator and then transferring those tokens to L1)? This type of question can be summarized as: What happens if the Sequencer publishes incorrect transaction data or an incorrect Stateroot?

Different types of Rollups have different measures to address the fraud risk of the Sequencer. Optimistic Rollup allows L2 full nodes to provide fraud proofs to prove that the data published by the Sequencer on L1 is incorrect. For example, Arbitrum has set up a whitelist of nodes that allows whitelisted L2 nodes to publish fraud proofs.

In addition, considering that most exchanges and private cross-chain bridge project parties will run L2 full nodes, they can immediately detect errors, making the success rate of most Rollup Sequencer thefts essentially zero (because they ultimately need to cash out, which still has to be done through an exchange or transfer the stolen coins to L1 and then seek another way out).

The Aggregator in the diagram is essentially the Sequencer.

However, for Optimism, which lacks fraud proofs, the Sequencer can steal coins through Rollup's own cross-chain bridge contract. For instance, the Sequencer operator can forge transaction instructions to transfer other users' assets on L2 to their own address and then use the Rollup's built-in bridge contract to transfer the stolen coins to L1. Since there are no fraud proofs, OP's full nodes cannot challenge erroneous transactions, so theoretically, the OP Sequencer can steal user assets on L2 (as long as it really wants to do so).

As of July 24, 2023, OP after the Bedrock upgrade still has not released a fraud proof system.

The solution to this problem is "social consensus" (relying on community members and social media for public oversight) or relying on OP's official credit endorsement.

Interestingly, a recent exchange reduced the delay for Arbitrum and Optimism users to transfer coins to the exchange (from 100 L2 blocks to 1 L2 block), which actually trusts that the ARB and OP Sequencers will not act maliciously (assuming they are centralized servers with official endorsement).

Unlike Optimistic Rollup, ZK Rollup addresses the Sequencer fraud issue through Validity Proofs (often confused with ZK Proofs). In ZK Rollup networks, there are nodes called Provers that generate validity proofs for the transaction batches published by the Sequencer. At the same time, there are contracts on L1 specifically for verifying validity proofs (generally referred to as Verifiers). As long as the transaction batches and the corresponding proofs for Stateroot/State diff pass the verification of the Verifier contract, they are finalized. The official bridge of ZK Rollup will only allow withdrawal transactions that have passed validity proof verification, which is clearly much more reliable than Optimism.

Three stages of transaction data defined by Scroll.

In theory, the security of OP Rollup relies on L2 full nodes to ensure (at least one honest node capable of publishing fraud proofs). The security of ZK Rollup is guaranteed by the Verifier contract on L1 (with L1 nodes completing the final confirmation of transactions). On the surface, both can "inherit the security of L1" (using L1 to complete the final confirmation/settlement of transactions), and Ethereum maximalists even refer to it as "equivalent to L1 security" (consistent with the finality of L1 transaction results), but the reality is far from this.

Those "Old Discussions"

First, the speed of generating validity proofs for ZK Rollup is extremely slow. The Sequencer can execute thousands of transactions in one second, but generating proofs for those thousands of transactions may take several hours. However, this problem is also easy to solve. Mainstream ZKRs generally improve proof generation speed significantly by splitting proof generation tasks and having different Prover nodes process them in parallel.

Secondly, we need to consider the delay of L2 nodes in publishing data to L1. Each time the Sequencer or Prover sends data to L1, there is a fixed cost (like consuming a shipping container for each shipment). Frequently publishing data on L1 is not cost-effective and may even result in losses, so Sequencers and Provers will try to minimize the frequency of publishing data on L1, waiting until they can package a large amount of data at once.

In other words, when the number of users is insufficient and the number of transactions initiated is not high enough, the Sequencer will delay publishing data to L1. For example, during a period of fewer users last year, Optimism sent a transaction batch to L1 only once every half hour. Now, as the number of users has increased, this issue has been effectively resolved. Unlike OP, Starknet has adopted a method of reducing the frequency of State diff publication to lower data costs, which has extended Starknet's transaction finalization delay to 7~8 hours.

In addition, most ZK Rollups often "aggregate multiple proofs and send them to L1 at once" to further reduce costs. This means that Provers do not immediately send a proof to L1 after generating it, but wait until multiple proofs are generated, aggregate them, and then send them to the Verifier contract on L1. (In fact, the process of aggregating proofs is to use one proof to encompass the computational steps of verifying multiple proofs).

Illustration of Scroll's aggregated proof.

The consequence of this approach is that the frequency of proof publication is further reduced, and the delay from transaction initiation to final confirmation is further extended.

According to block explorer data, the transaction confirmation delay for Polygon ZKEVM is about 30~50 minutes, while Starknet and Zksync Era exceed 7 hours. Clearly, this is only "partially inheriting L1 security," which is far from what Ethereum supporters refer to as "equivalent to L1 security."

Of course, all the above issues can be solved through technological advancements, which can be realized in the near future. For example, many projects are developing high-performance hardware to reduce the generation time of validity proofs; Optimism has also promised to release a fraud proof system soon; Ethereum's Danksharding plan will reduce the data costs of Rollups by dozens of times or even more, which can effectively address the issues listed above.

Difficult-to-Solve "Human Governance" Issues

Like application projects such as DeFi, the operation of Rollup networks relies on relevant contracts on L1, and these contracts are "upgradable," meaning that some code can be replaced (most Rollups use proxy contracts) and can be immediately modified under the authorization of a multi-signature or security committee. To conclude: 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.

Image source: L2 BEAT research report.

First, "Why do Rollup contracts need to be upgraded?" and "How are they upgraded?". The contract code on Ethereum is immutable once deployed, but Rollups inevitably encounter various bugs during development that may lead to incorrect results; at the same time, Rollups are frequently iterating on products and need to add new features often; in extreme cases, there may also be hacker attacks on Rollup contracts, so Rollup contracts need to be upgradable, which is often achieved through proxy contracts.

Image source: wtf academy.

Proxy contracts are actually a commonly used method in Ethereum contract development, which separates the contract's data and business logic, storing them in different contracts. Data (state variables) is stored in the proxy contract, while business logic (functions) is stored in the logic contract. The proxy contract (Proxy) fully delegates the execution of functions to the logic contract (Implementation) through delegatecall, and then returns the final result to the caller (Caller).

Contract upgrades under the proxy model only require pointing the proxy contract to a new logic contract (rewriting the address of the logic contract stored in the proxy contract). Most Rollup projects adopt this simple and straightforward method for contract upgrades.

Image source: wtf academy.

It is not hard to imagine that the upgradability of Rollup contracts is actually a huge risk: if the upgraded contract contains malicious code, such as modifying the withdrawal conditions of the Rollup's built-in Bridge contract or changing the conditions under which the Verifier contract determines the correctness of validity proofs, the Sequencer can steal coins (as explained earlier).

However, the problem is that Rollup contracts cannot be disallowed from being upgradable, as previously stated. Weighing the pros and cons, the vast majority of Rollups will decide whether to upgrade the Rollup contracts through DAO governance, security committees, or multi-signature authorization, using human governance to make this decision. Additionally, they will set a delay window for contract upgrades through a timelock.

Image source: L2 BEAT research report.

Considering that most DAO proposals have automated execution processes (achieved through on-chain contracts), even if a contract upgrade is necessary, it must first obtain enough votes, and then go through the delay specified by the timelock (often lasting several days) before the contract upgrade operation is executed. If someone wants to carry out a malicious contract upgrade, they need to pass through the DAO governance process through governance attacks (like the governance attack that occurred on Tornado Cash), but this approach is costly, as they need to acquire enough tokens first, which normally would not succeed. Even if a governance attack is successful, due to the time lock, users will have enough time to withdraw their assets from L2, and the Rollup officials will also have enough time to take emergency measures.

A time lock allows certain operations only after a delay.

It seems that time locks are a magic solution to prevent malicious contract upgrades. However, the problem is that the so-called "emergency measures that Rollup officials can take" actually involve bypassing DAO governance and time locks to immediately upgrade the Rollup contract through multi-signature or security committee authorization. Considering that mainstream Rollups currently manage user assets worth billions of dollars, the ability to "immediately upgrade contracts authorized by multi-signature and security committees" is the ultimate emergency measure, but it also hangs like the sword of Damocles over all users.

Clearly, this is a trust maximization issue: you need to trust that Rollup officials do not have the intention to steal your assets. From a trustless perspective (the perspective of Nick Szabo), all Rollups controlled by multi-signatures and security committees are unsafe. Emin Gun Sirer, the founder of Avalanche, and Anatoly, the founder of Solana, along with the well-known critic Justin Bons, have all emphasized such issues.

Which Rollups Are Controlled by Multi-signatures / Committees?

According to the report "Upgradeability of Ethereum L2s" published by the well-known L2 research institution L2 BEAT and the data visualization website L2BEAT, mainstream Rollups such as Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet, and Polygon ZKEVM all have upgradable contracts authorized by multi-signatures or committees, and can bypass time lock restrictions.

Although dYdX has an EOA address that can bypass DAO governance to upgrade contracts, it is subject to time lock restrictions (with at least a 2-day delay). Immutable X has a 14-day contract upgrade delay, so according to L2BEAT, dYdX and Immutable X are more trustless than other mainstream Rollups that have already launched on the mainnet.

Image source: L2 BEAT research report.

So how can we reduce the trust risks brought by multi-signatures and security committees? The answer is actually similar to the Multichain incident: it can be summarized as the anti-witch hunt problem. It is essential to ensure that multi-signatures/committees are controlled by multiple different entities with low levels of vested interest overlap and conspiracy risk. Currently, it seems that besides increasing the maturity of DAO decentralized governance and inviting reputable individuals or institutions to participate in multi-signatures/committees, there are not many good solutions. This scenario seems to have been frequently seen in the democratic politics of the real world.

Of course, it is also possible to impose restrictions on the contract upgrade actions managed by multi-signatures/committees through time locks, but this requires weighing many factors, as the purpose of multi-signatures/committees is to quickly handle some emergencies. At the same time, if the Rollup project parties do not have a firm determination regarding the issue of trustlessness, this problem cannot be resolved.

Therefore, although different Rollup projects can ensure the safety of user assets in most cases through ingenious mechanism design, due to the existence of multi-signatures and committees, the probability of a black swan event occurring in Rollup is not zero. Even if the probability of collusion among multi-signature and committee members is only one in ten thousand, considering the value of assets managed by L2 (assuming it is 10 billion dollars), the daily risk to L2 user assets still amounts to 1 million dollars. This is indeed chilling when recalling the Multichain incident.

So I personally believe that, as Polynya previously stated, most funds within the Ethereum ecosystem will still tend to circulate and be locked in L1 rather than L2, and the Rollup ecosystem will not be able to capture most of the value within the Ethereum ecosystem in the long term. For large holders and whales, the Ethereum mainnet is clearly a more suitable and reliable place for funds than L2. Therefore, the question many people previously considered, "Will the rise of L2 lead to the coldness of L1?" has actually already been answered.

As Higashino Keigo said in his works, human hearts are far more difficult to grasp, understand, and change than mathematical formulas. Many things cannot be solved purely through technical means; whenever human factors are involved, they are always the most uncontrollable, unpredictable, and serious issues. Let us remember the classic saying on Kant's tombstone:

"There are two things that fill my mind with ever-increasing wonder and awe: the starry sky above me and the moral law within me."