Stages update: Security Council requirements

Thanks to Vitalik Buterin, Justin Drake, Alex Gluchowski, Yoav Weiss, Patrick McCorry and Maurelian for the feedback on the initial and on the new version of the Stages Framework.

Background

The initial version of the Stages Framework can be summarized as follows:

• Stage 0 — Full Training Wheels: At this stage, the rollup is effectively run by the operators. Still, there is an open-source software that allows for the reconstruction of the state from the data posted on L1, used to compare state roots with the proposed ones.
• Stage 1 — Limited Training Wheels: In this stage, the rollup transitions to being governed by smart contracts. However, a Security Council might remain in place to address potential bugs. This stage is characterized by the implementation of a fully functional proof system, decentralization of fraud proof submission, and provision for user exits without operator coordination. The Security Council, comprised of a diverse set of participants, provides a safety net, but its power also poses a potential risk.
• Stage 2 — No Training Wheels: This is the final stage where the rollup becomes fully managed by smart contracts. At this point, the fraud proof system is permissionless, and users are given ample time to exit in the event of unwanted upgrades. The Security Council’s role is strictly confined to addressing soundness errors that can be adjudicated on-chain, and users are protected from governance attacks.

It’s clear to see how Stage 0 represents full control by the operators, how Stage 2 represents full control by smart contracts, and how Stage 1 is intended as something in between. In Stage 1, the ability to instantly upgrade is no longer in the hands of the core team but is entrusted to a sufficiently decentralized group of members that compose the Security Council.

Defining the requirements of such council is crucial to distinguish it from a simple multisig, and therefore from a Stage 0 rollup. The current requirements are:

• At least of 8 participants.
• At least 50% of the members outside of the core organization.
• At least 50% threshold.
• At least 2 outsiders are needed to reach consensus.
• The members are publicly announced.

The problem

Let’s consider the minimum Security Council given those requirements: 8 members, 50% threshold, 6 outsiders, and 2 from the organization.

The Security Council can perform two actions:

• Accept the proof system’s decisions by not overriding it.
• Override the proof system’s decisions by pushing an instant upgrade.

With the given Security Council setup, it takes 50% of the members to both follow the proof system (by rejecting an override) and to override it, which is at minimum composed of 2 outsiders and 2 insiders.

The key insight is that Security Council threshold can be modulated to make it easier to follow the proof system and harder to override it.

Imagine a multisig with 87.5% threshold (7/8): it takes at least 7 members to override the proof system, but just 2 members to prevent such override from being confirmed.

Let’s try to turn this 7/8 multisig into one with 51% (i.e. ⌊|multisig|*50%⌋+1) by adding “dummy” addresses, like many zero addresses. Those addresses are “dummy” since they never vote for an upgrade, as if they always want to agree with the smart contract proof system, it being either correct or buggy. The number of dummy addresses that we need to add to reach 51% is higher if the original threshold is higher. For example, for a multisig that has a 8/12 (66.6%) threshold, we just need to add 3 addresses to reach 8/15, while for a 11/12 we need to add 8 addresses to reach 11/20.

Since these dummy addresses always “follow” the smart contracts, we can consider them to be the “voting power” that the proof system has in the multisig, and in general in the whole system.

Once again, within our original 7/8 multisig setup, the multisig can be seen as a 7/13 (51%) multisig where the proof system has 5 votes always directed towards not overriding itself. To better see how it aligns with the original council, let’s go once again through the possible actions:

• Accept the proof system decision by preventing an override: 7 votes needed, 5 given by default by the proof system, 2 other members needed.
• Reject the proof system decision by pushing an override: 7 members needed.

Since the number of active members needed to push an upgrade or reject it is the same, this 51% “virtual” multisig can be thought as equivalent to the original one.

By using this virtual multisig, we can calculate the percentage of power given to the proof system over the original 7/8 multisig: the proof system consists of 5 votes over the 7/13 virtual threshold, so it consists of around 38.5% of the decision-making power in the multisig.

If you’re interested more in the math, take a look at the appendix at the end of this article.

Going back to the original 50% threshold multisig, it is easy to see that the proof system holds exactly zero voting power: its presence doesn’t make it easier to reject an override than to push one, and therefore it has zero votes.

The new requirement

With Stage 1, as previously said, the goal is to communicate a middle ground between full operator and full smart contract control. It is therefore natural to express this by requiring the proof system to have at least half of the power over the decision making over the L2, which corresponds to at least 25% of voting power in the simple majority threshold virtual multisig.

Here’s some examples to familiarize with this concept:

• 6/8 multisig (75%) → 27.27% proof system power ✅
• 5/8 multisig (62.5%) → 11.11% proof system power ❌
• 9/12 multisig (75%) → 29.41% proof system power ✅
• 8/12 multisig (66.67%) → 20.00% proof system power ❌
• 12/16 multisig (75%) → 30.43% proof system power ✅
• 11/16 multisig (68.75%) → 23.81% proof system power ❌

A 75% threshold aligns pretty well with the minimum 25% of proof system power requirement, except when the multisig size becomes large:

• 14/20 multisig (70%) → 25.93% proof system power ✅
• 135/200 multisig (67.5%) → 25.56% proof system power ✅

For the curious, the minimum threshold such that the ≥25% proof system power holds is 2/3:

Refer to the appendix for the formula.

We don’t expect Security Councils to be this large, so for simplicity we agreed on using the 75% threshold requirement, while keeping in mind the rationale behind it.

Counting members

Until now, we required at least 50% of the Security Council members to be outside of the organization and at least 2 outsiders to reach consensus. This requirement implies that it is sufficient to corrupt those 2 people to push a malicious upgrade, regardless of the size of the multisig.

As proven by the recent events between the Multichain team and the Chinese law enforcement authorities, or the Oasis Court order, people inside the same organization or the same jurisdiction share the same legal risks which makes it harder to treat them as being different entities.

The aim is to create a Security Council whose membership is sufficiently diverse to resist coordinated malicious activities, legal coercion, or other forms of external influence. Achieving this through objective criteria has been proven challenging due to various edge cases.

Considering these complexities, member diversity will be subjectively assessed. It is advisable to have members representing various organizations, which helps to dilute the risk associated with the potential for internal collusion within a single entity. Including members from different legal jurisdictions enhances the Council’s resilience against localized legal actions or regulations.

Risk Analysis: when to move from Stage 0 to Stage 1?

When designing a Security Council, one should consider two scenarios:

1. The rollup contains a bug: in this case, the Security Council should quickly upgrade the system. A lower threshold increases the probability of a positive outcome.
2. The rollup is working as intended: the Security Council should not override the system in this case. A higher threshold helps make this scenario less likely.

The size and the threshold of the multisig should reflect the risks associated with both the system and the Security Council itself. Let’s walk through an example to make the concept easier to understand. A Security Council of a fictional rollup is composed of 15 members. We assign theoretical probabilities to specific scenarios given their perceived risk:

• 10% chance of at least 4 of the members having a fault.
• 1% chance of at least 8 of the members having a fault.
• 0.1% chance of at least 12 members having a fault.

Moreover, we assign a probability of 20% to the proof system having a fault. Given those probabilities, how can we determine what threshold is the best?

Assuming a threshold of 12, the probability of a negative outcome can be calculated as such: 0.1% (12 members having a fault) + 20% (the proof system has a bug) * 10% (4 members have a fault and prevent the upgrade) ≈ 2.1%¹. If instead we assume instead a threshold of 8 to push an upgrade, the chance of a negative outcome is 1% + 20% * 1% ≈ 1.2%, which is lower and, therefore, better than the threshold of 12 proposed above.

As the confidence in the proving system increases, the threshold should be increased accordingly to eventually reach Stage 1.

Liveness concerns

A high Security Council threshold can spark concerns related to the timeliness of actions required to push an upgrade to fix a bug. This is particularly challenging when there is a need to gather a large number of people from potentially different time zones, who could be either busy or asleep.

For this reason, it may be beneficial to implement a lower threshold to pause the L2, which can then be overridden by the higher threshold if necessary. In addition to this, we suggest conducting periodic but unexpected emergency drills to practice signing messages in a timely manner.

Affected rollups: the Arbitrum case

This change in requirements for Stage 1 affects only Arbitrum. Arbitrum has, in addition to the 9/12 threshold for the Security Council, a lower threshold of 7/12 within the same multisig. This threshold allows for upgrades with a 13-day delay, providing an approximate 6-day exit window. Since this lower threshold does not meet the requirements to be recognized as a Security Council (the threshold being ≤75%), the criteria for simple multisigs apply, necessitating at least a 7-day exit window for users. To retain its Stage 1 status, Arbitrum must either remove the lower threshold entirely or extend the timelock delay on L1, L2, or both. Additionally, the Arbitrum Security Council currently includes 2 members from Offchain Labs.

Compared to other rollups, upgrades and elections in Arbitrum are highly decentralized and, therefore, take time to be proposed, voted on, and executed. For the time being, although Arbitrum technically does not meet the new Stage 1 requirements, we will maintain its current designation. We are currently working closely with Offchain Labs and the Arbitrum DAO to address these concerns promptly; however, if the necessary changes are not implemented in a timely manner, we will reclassify the rollup to Stage 0.

Appendix: the math

The percentage of power that the proof system has over the virtual multisig can be calculated as follows:

1. proof system virtual votes = threshold — number of people needed to block a proposal
2. number of people to block a proposal = size — threshold + 1
3. equivalent 51% multisig size = size + proof system virtual votes
4. proof system power = proof system virtual votes / equivalent 51% multisig size

If you’d like to play with the formula, here’s a quick python script that calculates the proof system voting power for different multisigs and that contains some other considerations → link.

[1] The intersection between non-independent event should be subtracted, but the conclusion remains the same.