In-depth interpretation of why Rollups need a security committee?

Original Author: PATRICK MCCORRY

Original Compilation: Luffy, Foresight News

Any database that interacts with crypto assets will eventually choose Rollup as its technology stack. There are many compelling reasons for developers to make such a decision:

• Real-time auditing

• Default proof of solvency

• Custody of user funds is optional

• Honest party participants can protect the entire system

Most importantly, all design and implementation work of Rollup is focused on protecting users, their funds, and all their interactions from potential unknown and powerful system operators.

Even if the entire system goes offline, users can recover their funds on their own.

If Rollup can be widely deployed as a technology stack, we may have the ability to break trust barriers, allowing anyone in the global community to engage in financial interactions, thus entering a new era of global e-commerce, remote hiring, and frictionless service provision.

It indeed requires a lot of effort to make Rollup work correctly.

What about Multi-signatures?

This sounds good, but the entire system is ultimately controlled by multi-signatures. If the signers are compromised or act maliciously, they can easily steal all the funds.

So, who would care about Rollup? Somewhere on CT.

Indeed, all current Rollups have multi-signatures that have the authority to upgrade the underlying smart contracts, but as we will see, it is a conservative mechanism to protect user funds and is part of a broader system architecture.

Responsibilities of the Security Committee

Multi-signature is a technical term that refers to a system requiring multiple signers to authorize an operation. For example, K out of N signers must complete a digital signature for a transaction to be allowed.

In the context of Rollup, multi-signatures are often referred to as the security committee, and the signers are empowered to upgrade all relevant smart contracts.

Let’s take a look at the security committee in Arbitrum (as I am very familiar with it) to understand the types of responsibilities this organization may undertake:

• Veto power. If the security committee believes that a proposal passed by the Arbitrum DAO violates the Arbitrum charter and may harm the Arbitrum ecosystem, it can cancel the proposal. For example, canceling a proposal passed due to a governance attack.

• Maintenance. Upgrading the Arbitrum smart contract suite for minor changes that have little impact and do not require the involvement of the Arbitrum DAO.

• Emergency response. Responding quickly in emergencies; if they believe user funds are at imminent risk, they can urgently upgrade the smart contracts.

Of course, most importantly, the primary responsibility of the security committee is to respond to emergencies and take swift action to protect user funds.

Members of the security committee need to be very trustworthy individuals.

People must believe that the signers can respond quickly, upgrade the smart contracts in emergencies, and that they will do their utmost to protect the funds in the smart contracts.

Choosing the Right Multi-signature Threshold

When deciding to establish a security committee, two important factors need to be considered:

• How many signers are there in total?

• How many signers are needed to approve an action?

• This may seem like a trivial question, after all, it’s just two numbers, but a balancing act must be considered:

• Security violation: K members may collude to change the smart contracts and steal user funds.

• Activity violation: N-K+1 members may collude to prevent any changes to the smart contracts, which is particularly serious if a critical vulnerability is discovered.

The challenge lies in determining a threshold that can maintain fund security in peacetime while allowing for swift action in emergencies when user funds are threatened.

Let’s consider a specific example. Suppose the threshold is set to 9/10, where 9 signers must jointly sign a message. This is a stringent security threshold because it requires 9 signers to collude to steal funds. However, the downside is that any two signers can block any action in an emergency. For instance, if two signers are on a transatlantic flight, the security committee will be unable to fulfill its duties.

Of course, if the security threshold is lower, say 2/10, then any two signers can collude (or a private key is leaked), and user funds could be stolen.

Perceptions of an individual's integrity are likely to change over time.

Choosing the appropriate threshold is more of a social issue than a technical one; I believe it is more of an art than a science. Security largely depends on the integrity of individual signers. As we will soon see, there are some methods to reduce reliance on multi-signatures, but this comes with a series of trade-offs.

Security Committee Members

The multi-signature threshold required for major Rollups to upgrade all smart contracts instantly.

Most Rollups have a group of anonymous signers in their security committee. We suspect this may be due to:

• The developmental stage of Rollups,

• Protecting the personal safety of members,

• The belief that anonymity is the best choice for protecting user funds.

• On the other hand, three Rollup projects have publicly announced their security committee membership:

• Arbitrum: Signers are elected publicly, and the current list can be viewed on Tally. Only three signers are related to the Arbitrum project (two from Offchain Labs and one from the Arbitrum Foundation).

• Base: 2/2 multi-signature, one controlled by Base and the other by Optimism.

• Polygon zkEVM: Not yet implemented, but they have announced plans to upgrade their multi-signature to 10/13, which includes two members from Polygon Labs and one advisor from Polygon Labs.

• zkSync Lite: zkSync Lite should be distinguished from zkSync Era; its security committee is publicly announced and does not include direct affiliates from the Rollup project (except for investors in zkSync).

In Arbitrum and the upcoming Polygon, only a few signers are directly related to the Rollup project, and the number is small enough to ensure that affiliates cannot collude to block actions taken by the security committee. In zkSync Lite, they have also appointed signers independent of the project, aside from zkSync's investors.

In all cases, Rollups place great importance on signers who do not have direct ties to the project.

However, there seems to be a lack of consensus on how to constitute a good multi-signature, which brings us several design questions:

• Should anonymous members be allowed?

• Should members come from different regions?

• Should members be individuals or companies?

• Should members be appointed or elected?

• How many members from the same company (or country) should be allowed?

• Is there a minimum size and threshold that is considered appropriate?

The general rule of thumb should be to select highly trustworthy members so that the public has confidence in the system's security. At the very least, I believe most projects would likely do this, even if it is not always publicly verifiable.

Note: The six members of the Arbitrum security committee have currently been pre-appointed, but they will be replaced in the elections in March.

Weakening the Committee's Power

So far, we have only considered a committee empowered to immediately upgrade smart contracts, but there are some ways to limit the committee's power:

Time delay. All operations authorized by the committee will only be executed and take effect after a time T has passed.

Pause-only. All assets held by the native cross-chain bridge can be frozen by the committee. This may pause the following functions:

• Transmitting messages from L2 to L1 (i.e., withdrawals),

• Sorting pending transactions,

• Completing new checkpoints/certificates,

• Accepting new Rollup data (i.e., pending transactions).

Bypass the committee (Removed). Abandon the committee and rely on another governance mechanism (such as a DAO) to approve upgrades.

Of course, this would limit the committee's ability to act swiftly and whether they can effectively respond to emergencies threatening user funds.

If a vulnerability has been privately disclosed to the committee but has not yet been exploited by hackers, the committee can choose to upgrade the smart contracts and fix the bug. Adding a time delay to the upgrade increases the risk that attackers will study the publicly disclosed upgrade, find the vulnerability, and then exploit it.

For example, CVE-2018-17144 in Bitcoin was initially publicized as a DDoS vulnerability while attempting to hide a more serious token inflation vulnerability. The speed of upgrades is crucial to preventing exploitation.

Assessing the Defense Capability of the Pause-Only Mechanism

Let’s consider a potential scenario where an attacker actively exploits a vulnerability:

• Malicious L2 → L1 messages. An attacker can create arbitrary messages originating from smart contracts on the Rollup and forward those messages to smart contracts on Ethereum via the native cross-chain bridge.

• Invalid state transitions. An attacker can execute transactions on the Rollup that violate the rules of the state transition function, which should generally be considered invalid.

• Withdrawal vulnerabilities. An attacker can simply issue a transaction on Ethereum (Layer 1) to extract funds from the native cross-chain bridge.

In these three cases, a time delay would only give the attacker more time to continue stealing funds and reduce the committee's opportunity window to defend the system. The delay feature cannot defend against active attacks; it can only be used for routine maintenance and non-urgent tasks.

We will only evaluate the ability of the pause system and the extent to which the system can be paused.

In the case of malicious L2 → L1 messages, the pause function can mitigate the attack without interfering with transaction activity. The committee should pause the ability to transmit messages and/or finalize new checkpoints. There is a viewpoint that L2 → L1 messages should have a time delay before execution so that the committee has time to detect errors and respond to emergencies.

Defending against invalid state transitions is trickier because transaction finality has different layers in the Rollup. If we only consider Rollup transactions without any side effects, the best defense for the security committee is to stop the ability to finalize checkpoints while continuing to allow transaction sorting. This can allow time to fix bugs, reactivate checkpoint completion, and simply ignore invalid transactions.

However, if transaction activity on the Rollup is not halted, the user experience will be very chaotic, and the Rollup may end up in a severely compromised state until the client software is upgraded.

This brings us to the next scenario. If we consider how invalid transactions on the Rollup might affect other systems, how should the committee respond? The best defense is to freeze the native cross-chain bridge's ability to finalize transaction sorting or completely shut down the sorter.

This is because certain systems, such as fast cross-chain bridges that transfer funds from one Rollup to another, may authorize fund transfers once they believe that Rollup transactions (including invalid transactions) have been sorted. In this example, it may allow attackers to exploit DeFi protocols on the Rollup and then quickly transfer funds to another Rollup via the fast cross-chain bridge.

When the committee fixes the vulnerability and restores invalid transactions, damage may have already been done. Both DeFi protocols and LPs in cross-chain bridges may bear the losses caused by the attack.

Finally, if the vulnerability allows attackers to extract funds directly from the native cross-chain bridge, similar to the Nomad Hack, the security committee may be powerless to stop it.

The pause mechanism has an overarching final issue. We must assume that there is a broader governance system that can approve upgrades and reactivate the Rollup. If we assume the governance system is a DAO with an on-chain voting system running on the Rollup, then tricky implementation issues arise.

For example, if the L2→L1 message cross-chain bridge is paused, the DAO's voting results cannot be transmitted from the Rollup to the native cross-chain bridge on Ethereum, and there must be an alternative method for the DAO to send approval messages and execute upgrades.

Gradual Abolition of the Security Committee

Some in the community believe that the security committee should be gradually abolished, but in my view, this raises two issues:

False sense of security. Attackers aware of the vulnerability exploitation will wait until the security committee is gradually phased out before executing their attacks. Over time, this will undermine our confidence in the system's security.

Limited recovery options. Without a security committee, the community cannot retaliate against attackers. The only option available is to conduct parallel white-hat hacking attempts and hope to recover some funds.

I believe that a security committee is always necessary, but the powers granted to them should be gradually reduced.

With this in mind, the design question should be:

How can we allow the security committee to pause the system with minimal impact on users while enabling the broader community to participate in deciding how to fix bugs and reactivate the system?

In other words, we need a solution that truly allows the community to intervene and restore the system before limiting the pause power of the security committee.

In the realm of Layer 1 blockchains, the community can indeed directly achieve this through user-activated forks, but this approach does not apply to smart contracts on Ethereum (like Rollups), as there is no need to fork the entire Ethereum. In some cases, the Ethereum community may collectively decide to preserve the Rollup, as in the case of TheDAO in 2016, but Rollups should never rely on or expect such an outcome.

Another interesting idea along these lines is to implement an Ethereum Supreme Court to decide on smart contract upgrades and enable something akin to user-activated forks.

As mentioned earlier, if Rollup delegates its security to a DAO, there should be an implementation that allows the DAO to vote directly on Ethereum. This is very tricky, especially if the voting protocol exists within the Rollup.

Lastly, I think it is essential to conduct a comprehensive review of the types of situations that may require the security committee to respond to help facilitate discussions around its necessity.

If There Are Multi-signatures, Why Worry About Rollup?

We have spent quite a bit of time understanding the responsibilities, designs, and needs of the security committee, but it is important to return to the initial question of this article:

Is Rollup just multi-signatures?

The answer is no.

To help understand why, it is best to step back and understand what blockchain systems really want to achieve.

Blockchain protocols are tools that allow users to compute a copy of a database and be confident that they have the same database as everyone else.

With this in mind, any blockchain system has two components:

• Blockchain protocol. A combination of software, cryptography, and distributed systems that gives anyone confidence in the integrity of the database.

• Governance system. A coordination mechanism that allows all stakeholders to work together and agree on changes to the blockchain protocol.

The goal of any blockchain system (including Rollups) is to ensure that the blockchain protocol operates with an extremely reliable uptime of 99.9999%. Trusted system operators should have minimal interference in the daily operation of the system. Ultimately, the responsibility for protecting user balances, smart contract code, and state should lie with software, cryptography, and distributed systems.

Sometimes it is necessary to change the blockchain protocol to improve user interests. The community may want to fix configuration issues, add new features, or respond to critical vulnerabilities that threaten system integrity. This requires human intervention and can only be called upon 0.0001% of the time.

The governance system is responsible for implementing human intervention, and several methods have emerged over the years:

• Centralized party: A single party can unilaterally decide how to upgrade the system (many projects, including Bitcoin, started this way).

• Rough consensus: Most participants indicate they are ready to deploy an upgrade, set a marked date, and then execute the upgrade on that date (Bitcoin/Ethereum).

• Voting protocol: Parties participate in elections and explicitly vote to decide whether to approve an upgrade.

• Immutable: Smart contracts can be immutable, and the system can never change.

In addition to the above, the community can also decide to appoint a security committee as a supplementary governance option to act quickly in emergencies.

The security committee does not prevent attacks. It is a passive mechanism that works alongside governance when user funds or the reliability/performance of the blockchain protocol are under attack.

Conclusion

All discussions surrounding blockchain protocols, governance, and security committees are crucial. The existence of such discussions makes cryptocurrency so special.

This is a great example of trust engineering: a discipline focused on identifying, measuring, and reducing/eliminating elements of trust in a system.

In cryptocurrency, we focus on building systems that not only protect users from powerful system operators but also ensure that the system operates reliably (safely) under the most adverse conditions.

That is why it is healthy for community members to remain skeptical about the role of security committees, but they have a responsibility to propose better solutions during emergencies to passively protect user funds.

I hope this article clearly illustrates why security committees are useful, that they are necessary today, but also that they are just a small part of the broader architecture of smart contract systems.