Original author: PATRICK MCCORRY
Original compilation: Luffy, Foresight News
Any database that interacts with crypto assets will one day choose Rollup as its technology stack. There are many good reasons why developers make this decision:
real-time audit
Default proof of solvency
Escrow of user funds is optional
An honest party protects the entire system
Most importantly, all of Rollups 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 funds on their own.
If Rollup can be widely deployed as a technology stack, we may have the ability to break down barriers of trust and enable financial interaction with anyone in the global community, ushering in a new era of global e-commerce, remote recruiting, and frictionless service delivery.
It does take a lot of effort to get Rollup to work correctly.
What about multi-signature?
This sounds great, but the entire system is ultimately controlled by multi-signatures. If the signer is compromised or has malicious intent, they can easily steal all the funds.
So, who cares about Rollup? Somewhere on CT.
It is true that all current Rollups have multi-signatures with the power to upgrade the underlying smart contract, but as we will see, it is a conservative mechanism to protect user funds and is part of the wider system architecture.
Safety Committee Responsibilities
Multi-signature is a technical term that refers to a system that requires multiple signers to authorize an action. For example, the transaction will be allowed only if K out of N signers complete the digital signature.
In the context of Rollup, multisig is often referred to as a security committee, and signers are given the power to upgrade all related smart contracts.
Lets take a look at the Safety Committee in Arbitrum (since Im very familiar with it) to get an idea of the types of responsibilities this organization might have:
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 that passed due to a governance attack.
maintain. Upgrade the Arbitrum smart contract suite to make minor changes that are low-impact and do not require the involvement of the Arbitrum DAO.
Emergency. Respond quickly in emergency situations and can urgently upgrade smart contracts if they believe user funds are at imminent risk.
Of course, most importantly, the Security Committee’s primary responsibility is to respond to emergencies and act quickly to protect user funds.
Safety committee members need to be highly trustworthy.
Signers are trusted to respond quickly, to upgrade smart contracts when emergencies occur, and to do their best to protect the funds in smart contracts.
Choosing the right multi-signature threshold
When deciding to establish a safety committee, there are two important factors to consider:
How many signers are there in total?
What is the minimum number of signatories required to approve an action?
This may seem like a trivial question, after all it is just two numbers, but there is a balancing act that must be considered:
Security violation: K members may collude to change the smart contract and steal user funds.
Liveness Violation: N-K+ 1 members collude to prevent any changes to the smart contract, which is especially problematic if a serious vulnerability is discovered.
The difficulty lies in determining a threshold that maintains the security of funds in peacetime but allows for rapid action in an emergency when user funds are threatened.
Lets consider a concrete example. Suppose the threshold is set to 9/10, where 9 signers must co-sign a message. This is a severe security threshold, as 9 signers must collude to steal the funds. However, the disadvantage is that any two signers can block any action in an emergency. For example, if two signatories traveled far away on a transatlantic flight, the Safety Committee would not be able to fulfill its responsibilities.
Of course, if the security threshold is lower, say 2/10, then it only takes any two signers to collude (or the private key is leaked) and user funds will be stolen.
Perceptions of a persons integrity are likely to change over time
Choosing an appropriate threshold is more of a social question than a technical one, and I think its more of an art than a science. Security largely depends on the integrity of the individual signer. As we will see shortly, there are ways to reduce trust in multisigs, but this comes with its own set of trade-offs.
safety committee member
Major Rollup instantly upgrades the multi-signature threshold required for all smart contracts
Most Rollups have a group of anonymous signers on their security committee. We suspect this may be due to:
The development stage of Rollup,
Protect the personal safety of members,
Consider anonymity to be the best option for protecting user funds.
On the other hand, there are three Rollup projects that have publicly announced their safety committee membership:
Arbitrum: Signers are publicly elected, the current list can be found atTallyCheck it out. Only three signatories are related to the Arbitrum project (two from Offchain Labs and one from the Arbitrum Foundation).
Base: 2/2 multi-signatures, one controlled by Base and the other controlled by Optimism.
Polygon zkEVM: Not implemented yet, but they have announced that they will be upgrading their multisig to 10/13, including two members from Polygon Labs and an advisor from Polygon Labs.
zkSync Lite: zkSync Lite should be distinguished from the ZkSync Era in that its security committee is publicly announced and does not include direct affiliates from the Rollup project (other than zkSync investors).
In Arbitrum, and in the upcoming Polygon, only a handful of 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 Council. In zkSync Lite, in addition to zkSyncs investors, they also appoint signers 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 leaves us with several design issues:
Should anonymous members be allowed?
Should members come from different geographical locations?
Should members be individuals or companies?
Should members be appointed or elected?
How many members from the same company (or country) should be allowed?
Are there minimum sizes and thresholds that are considered appropriate?
A general rule of thumb should be to select members with high integrity so that the public has confidence in the security of the system. At least, I believe most projects probably do this, even if this isnt always publicly verifiable.
P.S. Six members of Arbitrum’s safety committee are currently pre-appointed, but they will be replaced at the March election.
reduce the power of the committee
So far we have only considered a committee with the power to immediately upgrade smart contracts, but there are ways to limit the committees power:
Time delay. All operations authorized by the committee will be executed and take effect only after 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 functionality:
Pass the message from L2 to L1 (i.e. withdrawal),
Complete sorting of pending transactions,
Complete new checkpoint/certificate,
Accept new Rollup data (that is, pending transactions).
Bypass committee (Removed). Abandon the committee and rely on another governance mechanism (like a DAO) to approve upgrades.
Of course, this limits the committees ability to act quickly and their ability to effectively respond to emergencies that threaten user funds.
If a vulnerability has been privately disclosed to the committee but has not yet been exploited by hackers, the security committee may choose to upgrade the smart contract and fix the bug. Adding time delays to upgrades increases the risk of an attacker studying a publicly disclosed upgrade, finding a vulnerability, and then exploiting it.
For example, CVE-2018-17144 in Bitcoin was initially promoted as a DDoS vulnerability in an attempt to hide a more serious token inflation vulnerability. The speed of upgrades is critical to preventing their exploitation.
Evaluate the defense capabilities of pause-only mechanisms
Let’s consider a potential scenario where an attacker could actively exploit the vulnerability:
Malicious L2 → L1 message. An attacker can craft arbitrary messages originating from smart contracts on Rollup and forward the messages to smart contracts on Ethereum through the native cross-chain bridge.
Invalid state transition. An attacker can execute transactions on Rollup that violate the rules of the state transition function and should generally be considered invalid.
Withdrawal loophole. An attacker can withdraw funds from the native cross-chain bridge simply by issuing a transaction on Ethereum (layer 1).
In all three cases, the time delay simply gives attackers more time to continue stealing funds and reduces the committee’s window of opportunity to defend the system. The delay function cannot protect against active attacks and can only be used for routine maintenance and non-urgent tasks.
We will only evaluate the ability to suspend the system and the extent to which the system can be suspended.
In the case of malicious L2 → L1 messages, the pause function can mitigate the attack without interfering with trading activity. The committee should suspend messaging and/or finalize the functionality of new checkpoints. There is an argument that L2 → L1 messages should have a time delay before being executed to give the committee time to detect errors and react to emergencies.
Defending against invalid state transitions is trickier because transaction finality has different layers in Rollup. If we only consider rollup transactions without considering any side effects, then the safety committees best defense is to stop the ability of checkpoints to be finalized, but continue to allow transaction ordering. This allows time to fix errors, reactivate checkpoint completion, and simply ignore invalid transactions.
However, if trading activity on Rollup is not turned off, the user experience will be chaotic and Rollup may appear in a severely broken state until the client software is upgraded.
This brings us to the next scene. If we consider how invalid transactions on Rollup might impact other systems, how should the committee react? The best line of defense is to freeze the native cross-chain bridges ability to finalize transaction ordering, or to turn off the orderer entirely.
This is because some systems, such as fast cross-chain bridges that move funds from one rollup to another, may authorize the transfer of funds once they believe the rollups transactions (including invalid transactions) are sequenced. In this example, it could allow an attacker to exploit the DeFi protocol on Rollup and then move funds quickly by transferring it to another Rollup via a fast cross-chain bridge.
By the time the committee fixes the vulnerability and restores invalid transactions, the damage may have already been done. Both the DeFi protocol and the LP in the cross-chain bridge may bear losses caused by attacks.
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 one final overall problem with the pause mechanism. We must assume there is a wider governance system that can approve upgrades and reactivate Rollup. 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 suspended, the DAOs voting results cannot be passed from Rollup to the native cross-chain bridge on Ethereum, and there must be an alternative method for the DAO to send approval information and perform upgrades.
Phase out safety committees
There are some in the community who believe that safety committees should be phased out, but in my opinion this creates two problems:
A false sense of security. An attacker who knows about the exploit will wait until the security committee has phased it 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, communities cannot fight back against attackers. The only option available is to conduct a parallel white hat hack and hope to get some of the funds back.
I believe that 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 allow the security board to suspend the system with minimal impact to users, while allowing the wider community to participate in deciding how to fix bugs and reactivate the system?
In other words, we need a scheme that actually allows the community to step in and restore the system, before limiting the safety committees suspension powers.
In the world of Layer 1 blockchains, the community can indeed be reached directly by using user-activated forks, but this method does not work for smart contracts on Ethereum (such as Rollup) because there is no need to fork the entire Ethereum. In some cases, the Ethereum community may collectively decide to save Rollup, like TheDAO in 2016, but Rollup should never rely on or expect such an outcome.
Another interesting idea along these lines is to implement an Ethereum Supreme Court to decide smart contract upgrades and enable something like user-activated forks.
As mentioned before, 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 in Rollup.
As a final note, I believe that a comprehensive review of the types of situations that may require a response from the Security Council is needed to aid the discussion around its necessity.
If you have multi-signature, why worry about rollup?
We spent considerable time understanding the responsibilities, design, and requirements of a safety committee, but it’s important to return to the original question of this article:
Is Rollup just multi-signature?
The answer is no.
To help understand why, it’s best to take a step back and understand what a blockchain system is really trying to do.
A blockchain protocol is a tool that allows users to compute copies 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. The combination of software, cryptography and distributed systems 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 Rollup, is to ensure that the blockchain protocol always operates with an extremely reliable 99.9999% uptime. There should be little disruption to the day-to-day running of the system by a trusted system operator. It is software, cryptography, and distributed systems that are ultimately responsible for protecting user balances, smart contract code, and state.
Sometimes blockchain protocols need to be changed to improve the benefit of users. The community may want to fix configuration issues, add new features, or react to critical vulnerabilities that threaten system integrity. This requires human intervention and can only be called 0.0001% of the time.
Governance systems are responsible for enabling human intervention, and several approaches have emerged over the years:
Centralized Party: A single party can single-handedly decide how to upgrade the system (many projects, including Bitcoin, started this way).
Rough consensus: Most participants indicate they are ready to deploy the upgrade, determine the marking day, and then execute the upgrade on the marking day (Bitcoin/Ethereum).
Voting protocol: All parties participate in the election and explicitly vote on whether to approve the upgrade.
Inability to interfere: Smart contracts can be immutable and the system can never be changed.
In addition to the above, a community may decide to appoint a safety committee as a complementary option to governance to take prompt action in emergencies.
Security committees do not prevent attacks. This is a passive mechanism that comes into play alongside governance when user funds or system reliability/performance of the blockchain protocol are under attack.
at last
All discussions around blockchain protocols, governance, and security committees are critical. The existence of this discussion is what makes cryptocurrencies so special.
This is a good example of trust engineering: an engineering discipline focused on identifying, measuring, and reducing/eliminating elements of trust in systems.
In cryptocurrencies, we focus on building systems that not only protect users from powerful system operators, but also enable systems to operate reliably (securely) under the most adverse conditions.
This is why it is healthy for community members to remain skeptical of the role of the Security Committee, but it is their responsibility to come up with better solutions to protect user funds in a passive manner during emergencies.
I hope this article has made it clear why safety committees are useful, they are necessary today, but are only a small part of the broader architecture of a smart contract system.
