Read more about why Rollups need a safety committee?

ORIGINAL AUTHOR: PATRICK MCCORRY

Original compilation: Luffy, Foresight News

Any database that interacts with crypto assets will one day choose Rollup as the technology stack. There are a number of good reasons for developers to make such a decision:

• Real-time auditing
• Default solvency certificate
• Escrow of user funds is optional
• An honest party participant protects the entire system

Most importantly, all of Rollup’s design and implementation efforts are focused on protecting users, their funds, and all of their interactions from potentially unknown and powerful system operators.

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

If Rollups can be widely deployed as a tech stack, then we may have the ability to break down barriers of trust and enable financial interactions for anyone in the global community, leading to a new era of global e-commerce, remote hiring, and frictionless service delivery.

It does take a lot of effort to get a rollup to perform correctly.

What about multisigs?

That sounds good, but the entire system is ultimately controlled by multisig. If the signer is compromised or malicious, then they can easily steal all the funds.

So, who cares about Rollups? somewhere on CT.

It’s true that all current rollups have multisig and have the right to upgrade the underlying smart contract, but as we’ll see, it’s a conservative mechanism that protects user funds and is part of a broader system architecture.

Responsibilities of the Safety Committee

Multisig is a technical term that refers to a system that requires multiple signers to authorize an action. For example, K of the N signers complete the digital signature for the transaction to be allowed.

In the context of rollups, multisig is often referred to as a security committee, where signers are given the power to upgrade all related smart contracts.

Let’s take a look at the Security Council in Arbitrum (as I’m very familiar with it) to get an idea of the types of responsibilities this organization might have:

*Veto. If the Security Committee believes that a proposal passed by the Arbitrum DAO violates the Arbitrum charter and may harm the Arbitrum ecosystem, it may cancel the proposal. For example, cancel a proposal that passed due to a governance attack. *Maintenance. Upgrade the Arbitrum smart contract suite to make minor changes that are less impactful and don’t require Arbitrum DAO involvement.

• Emergencies. Respond quickly in case of an emergency, and if they believe that user funds are at imminent risk, they can urgently upgrade the smart contract.

Of course, the most important thing is that the first duty of the security committee is to respond to emergencies and act quickly to protect user funds.

The members of the safety committee need to be very trustworthy people.

There is a trust in the signers to be able to react quickly, to be able to upgrade the smart contract in the event of an emergency, and to do their best to keep the funds in the smart contract safe.

Select the correct multisig threshold

There are two important factors to consider when deciding to establish a safety committee:

• How many signatories are there?
• What is the minimum number of signatories required to approve an action?
• This may seem like a trivial question, after all, it’s just two numbers, but there is a balancing act that must be considered:
• Security breach: K members may collude to change smart contracts and steal user funds.
• Active violation: N-K+ 1 members collude to prevent any changes to the smart contract, especially if a critical vulnerability is found.

The challenge is to establish a threshold that will both keep funds safe in peacetime and act quickly in case of an emergency when user funds are threatened.

Let’s consider a specific example. Let’s say the threshold is set to 9/10 where 9 signers must co-sign a message. This is a strict security threshold as 9 signers must collude to steal the funds. The downside, however, is that any two signatories can block any action in an emergency. For example, if two signatories travel far away on a transatlantic flight, the Safety Committee will not be able to fulfill its duties.

Of course, if the security threshold is low, let’s say 2/10, then it only takes any two signers to collude (or the private key is compromised) for user funds to be stolen.

The perception of a person’s integrity is likely to change over time

Choosing the appropriate threshold is more of a social issue than a technical one, and I think it’s more of an art than a science. Security is highly dependent on the integrity of the individual signer. As we’ll see shortly, there are ways to reduce trust in multisig, but this comes with a series of trade-offs.

Member of the Safety Committee

The main rollup instantly upgrades the multisig threshold required for all smart contracts

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

• The development stage of the rollup,
• To protect the personal safety of members,
• Believe that anonymity is the best option to protect user funds.
• On the other hand, there are three Rollup projects that have publicly announced their security committee membership:
• Arbitrum: Signers are publicly elected, and the current list can be viewed on Tally. Only three signatories are associated with the Arbitrum project (two from Offchain Labs and one from the Arbitrum Foundation).
• Base: 2/2 multisig, one controlled by Base and the other controlled by Optimism.
• Polygon zkEVM: Not yet implemented, but they have announced that they will be upgrading their multisig to 10/13, which includes two members from Polygon Labs and one consultant from Polygon Labs.
• zkSync Lite: zkSync Lite should be distinguished from ZkSync Era, whose safety committee is publicly announced and does not include direct affiliates from the Rollup project (except for investors in zkSync).

In Arbitrum, and in the upcoming Polygon, only a handful of signatories are directly associated with the Rollup project, and the number is small enough to ensure that affiliates cannot collude to block action taken by the Security Committee. In zkSync Lite, in addition to zkSync’s investors, they appoint signers who are independent of the project.

In all cases, Rollup places a high value on signers who are not directly related to the project.

However, there seems to be a lack of consensus on what constitutes a good multisig, which brings us to several design issues:

• Should anonymous members be allowed?
• Should members be from different geographies?
• Should members be individuals or corporations?
• 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 pick members with a high degree of integrity so that the public has confidence in the security of the system. At least, I believe most projects probably do, even if this isn’t always publicly verifiable.

P.S. Six members of the Arbitrum Security Committee are currently pre-appointed, but they will be replaced in the March elections.

Weaken the powers of the Commission

So far, we’ve only considered one committee that has the power to upgrade the smart contract immediately, but there are ways to limit the committee’s powers:

Time delay. All actions authorized by the Commission will not be performed and take effect until time T has elapsed.

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

• Deliver the message from L2 to L1 (i.e. withdraw money),
• Complete the sorting of pending transactions,
• Complete new checkpoints/certificates,
• Accept new rollup data (i.e., pending transactions).

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

This, of course, limits the Commission’s ability to act quickly and their ability to effectively respond to emergencies that threaten user funds.

If the vulnerability has been disclosed to the committee privately, but has not yet been exploited by hackers, the security committee has the option to upgrade the smart contract and fix the bug. Adding a time delay to an upgrade increases the risk that an attacker will research a publicly disclosed upgrade, find a vulnerability, and then exploit it.

For example, CVE-2018-17144 in the BTC was initially advertised as a DDoS vulnerability in an attempt to hide a more serious token inflation vulnerability. The speed of the upgrade is critical to prevent it from being exploited.

Evaluate the defenses of the pause-only mechanism

Let’s consider a potential scenario for an attacker to actively exploit a vulnerability:

• Malicious L2 → L1 messages. An attacker can craft arbitrary messages originating from a smart contract on a rollup and forward the message to the smart contract on the ETH via a native cross-chain bridge.
• Invalid state transitions. An attacker can execute a transaction on a rollup that violates the rules of the state transition function and should generally be considered invalid.
• Withdrawal loopholes. An attacker can withdraw funds from the native cross-chain bridge by simply issuing a transaction on the ETH Fang (Layer 1).

In all three cases, the time delay only gives the attacker more time to continue stealing the funds and reduces the window of opportunity for the committee to defend the system. The time-lapse feature does not protect against active attacks and can only be used for routine maintenance and non-urgent tasks.

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

In the case of malicious L2 → L1 messages, the pause feature can mitigate the attack without interfering with trading activities. The committee should suspend messaging and/or finalize the functionality of new checkpoints. There is an argument that there should be a time delay before the L2 → L1 message is executed so that the committee has time to detect errors and react to emergencies.

Defending against invalid state transitions is trickier because transaction finality has different layers in rollups. If we only consider rollup transactions without considering any side effects, then the best defense for the security committee would be to stop the ability to checkpoint finalization, but continue to allow transactions to be sorted. This allows time to fix bugs, reactivate checkpoint completion, and simply ignore invalid transactions.

However, if trading activity on the Rollup is not turned off, the user experience will be chaotic and the Rollup may appear to be severely broken until the client software is upgraded.

This brings us to the next scenario. How should the committee react if we consider how invalid transactions on rollups might affect other systems. The best line of defense is to freeze the native cross-chain bridge’s ability to finalize the ordering of transactions, or to turn off the sequencer entirely.

This is because certain systems, such as fast cross-chain bridges that transfer funds from one rollup to another, may authorize the transfer of funds once they believe that the rollup’s transactions (including invalid transactions) are sorted. In this example, it may allow an attacker to exploit a DeFi protocol on a Rollup and then transfer funds quickly by transferring it to another Rollup via a fast cross-chain bridge.

By the time the commission fixes the breach and reinstates the invalid transaction, the damage may have already been done. LPs in both DeFi protocols and cross-chain bridges can bear the cost of an attack.

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

There is an ultimately overarching problem with the suspension mechanism. We have to assume that there is a broader governance system that can approve upgrades and reactivate rollups. If we assume that the governance system is a DAO with an on-chain voting system running on 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 passed from the rollup to the native cross-chain bridge on the ETH, and there must be an alternative way for the DAO to send the approval and perform the upgrade.

Phasing out the Security Council

There are those in the community who believe that the safety committee should be phased out, but in my opinion, this poses two problems:

False sense of security. Attackers who are aware of the exploit wait until the security committee is phased out before executing the attack. Over time, this can erode our confidence in the security of our systems.

Recovery options are limited. Without a safety committee, the community can’t fight back against the attackers. The only option available is to run a parallel white hat hack and hopefully reclaim some of the funds.

In my opinion, safety committees will always be necessary, but the powers given to them should be gradually reduced.

With this in mind, the design question should be:

How can we get the safety committee to suspend the system with minimal impact to users, while allowing the broader community to participate in deciding how to fix bugs and reactivate the system?

In other words, we need a program that really allows the community to step in and restore the system, and then limit the suspension power of the Security Council.

In the Layer 1 blockchain space, the community can indeed be reached directly by using user-activated forks, but this method does not work for smart contracts on ETH squares (such as Rollups) because there is no need to fork the entire ETH. In some cases, the ETH community may collectively decide to save the Rollup, like TheDAO in 2016, but the Rollup should never rely on or expect such an outcome.

Another interesting idea along these lines is to implement a ETH for the Supreme Court to decide on smart contract upgrades and enable forks similar to user activation.

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

Finally, I think there is a need for a comprehensive review of the types of situations that may require a response from the Council in order to facilitate the discussion around its necessity.

Why worry about rollups if you have multisigs?

We’ve spent quite a bit of time understanding the responsibilities, design, and needs of the safety committee, but it’s important to go back to the original question in this article:

Is Rollup just a multisig?

The answer is no.

To help understand why, it’s best to take a step back and understand what the blockchain system really wants to do.

A blockchain protocol is a tool that allows users to compute a copy of a database and be confident that they have the same database as everyone else.

With this in mind, there are two components to any blockchain system:

• Blockchain protocol. The combination of software, cryptography, and distributed systems gives anyone confidence in the integrity of a 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 Rollup, is to ensure that the blockchain protocol always runs with an extremely reliable uptime of 99.9999%. A trusted system operator should have little to no interference with the day-to-day operation of the system. Ultimately, it is the software, cryptography, and distributed systems that are ultimately responsible for protecting user balances, smart contract code, and state.

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

Governance systems are responsible for implementing human intervention, and several approaches have emerged over the years:

• Totalitarian political parties: Unilateral parties can decide individually how to upgrade the system (many projects, including BTC, started this way).
• Rough consensus: The majority of participants said they were ready to deploy the upgrade, determine the mark day, and then perform the upgrade on the mark day (BTC/ETH).
• Voting agreement: All parties participate in the election and explicitly vote on whether to approve the escalation.
• No interference: Smart contracts can be immutable, and the system can never be changed.

In addition to the above, the community can also decide to appoint a safety committee as a complementary option to governance to act quickly in an emergency.

The Security Council does not stop the attack. This is a passive mechanism that works alongside governance when a blockchain protocol’s user funds or system reliability/performance are attacked.

Finally

All discussions around blockchain protocols, governance, and security committees are crucial. The existence of this discussion is what makes cryptocurrencies so special.

This is a good example of trust engineering: an engineering discipline that focuses on identifying, measuring, and reducing/eliminating trust elements in a system.

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

That’s why it’s healthy for community members to be skeptical about the role of the safety committee, but they have a responsibility to come up with better solutions during emergencies to protect user funds in a reactive way.

I hope this article will make it clear why security committees are useful, they are necessary today, but they are only a small part of the broader architecture of smart contract systems.