Security Council: Vote #1 - Change to Security Model

[system]

For full context on the implementation of the Security Council, please read Intro to Optimism’s Security Council

Security Council: Vote #1 - Change to Security Model

The proposal that follows requests Token House approval for a change to the security model of OP Mainnet. This change does not constitute a Protocol Upgrade.

---

Summary

This is a proposal to turn proxy admin keys for OP Mainnet over to a public, decentralized set of individual actors (“participants”) accountable to Optimism Governance: i.e., the Security Council.

Specifically, for this initial Security Council proposal (Vote # 1), Governance will vote to approve the addition of the Security Council as one signer (of two) on a 2/2 multisig that controls protocol upgrades for OP Mainnet. The other signer on the multisig will be the current Foundation multisig.

If this proposal passes, it will approve a change similar to this illustrative example.

There will be an on-chain change of the ProxyAdmin’s owner from 0x9ba6e03d8b90de867373db8cf1a58d2f7f006b3a to a new 2 of 2 multisig (0xdc53b1d440b8a56dd50a6d69312dac903d3aa48b, in the example provided above).

The state diff for the above example can be found here.

Security Considerations

• The Security Council will operate a Gnosis Safe multisig wallet.
• Participants will carry out their roles in accordance with the Charter including the following key points:
  • During normal operations, the Security Council will implement the protocol upgrade and role designation decisions (such as designations for the sequencer, proposer, and challenger roles, as well as designating the composition of the participants on the Security Council multisig) made by Optimism Governance. The Security Council simply does as Governance directs. It does not directly evaluate the “merit” of the accompanying proposed code (e.g., for security purposes); that evaluation is the responsibility of Governance.
  • During defined emergency situations, the Security Council is empowered to act preemptively, without direct Governance approval, in order to keep the network safe and secure. Each participant may also take actions they or the Optimism Foundation believes to be necessary to comply with applicable law.
  • Dysfunctional participants, either individually or acting as a quorum, can be effectively checked, without undermining the security advantages motivating the formation of the Council in the first place.

Conclusion

You can read the complete Security Council Charter here. Technically, neither the existence of a Security Council nor its Charter needs to be approved via governance. However, since the implementation of this proposed Security Council represents a fundamental change to OP Mainnet’s security model, the Optimism Foundation is requesting approval to implement the change.

If this proposal passes with a 76% approval threshold (30% quorum), the Optimism Foundation will move forward with the implementation of the Security Council.

---

Note: Through subsequent Governance proposals and votes, it is intended that this Security Council will eventually extend beyond OP Mainnet, to secure all other OP Chains within the Superchain (read more). The ultimate goal is preventing any single party from being able to upgrade the system, modify rollup state, or censor transactions.

---

What Does this Mean for Delegates?

This proposal will go to a vote in Special Voting Cycle #16a.

[polynya]

Glad to see Security Counci on the horizon. This will be my last vote for these “giving Foundation full autonomy” type proposals. In future, I’d like to see the exact code payload for protocol upgrade proposals. In fact, I’d recommend an additional proposal in a future voting cycle, once the code is ready, with the exact code to show the Foundation’s commitment (which is what I assume Vote #1 implies). Of course, this should soon be an automated process like in many DAOs, where the payload is trustlessly executed after the vote, which would minimize the SC’s role only to emergency situations. That should then evolve to only pause rights (all execution by governance itself) and eventually complete dissolution of the SC.

[Sirlupinwatson]

Hi there! I was curious to know if there is any post where we can apply to be part of the Security Council?

As an Ex-Gitcoin Steward and Security Council leader, I would like to apply my experience and knowledge with Optimism!

Feel free to DM me or point at where I should apply following this conversation.

Best regards, Sirlupinwatson (Armand)

[sam.ng]

Upgradeability of the bridge contract is a really important topic that needed to be addressed - love to see it.

Agree that there should be a clear distinction between harmful upgrades and a simple “halt”. This arises from the delicate equilibrium that needs to be maintained between the timing of upgrades for safety and trustlessness. When a bug arises, the ideal response wouldn’t be to post it on a governance forum and wait for a month. Instead, prompt action is required to rectify it.

Incorporating waiting periods (which exceed the rollup’s withdrawal time) before implementing upgrades is also a good thing from a user perspective. If an upgrade isn’t to your liking, you can choose to opt out safely. This approach is more in tune with trust minimization because it operates under the assumption of synchrony for Optimism governance. You don’t have to trust the majority to be honest. You just need to ensure that you are aware of any upcoming upgrades and can opt out beforehand.

In my opinion, it is worthwhile to consider the addition of a “High Alert Mode” feature into the system. By “High Alert Mode,” I refer to a special operational state triggered when, for instance, the network fails to produce any valid blocks for a predetermined duration, say “x” hours.

This feature could be intrinsically integrated into the L1 contracts, serving as a swift upgrade pathway. The feature specifications could include:

1. During the High Alert Mode, the Security Council would possess the same authorities and rights referenced here.
2. The activation of this mode can exclusively occur in response to a bug and cannot be initiated directly at the discretion of entities through mechanisms like a multisig. This specification adds an extra layer of resilience against: a) Wrench attacks and b) Regulatory alterations.

Note that you could still allow a multisig to execute the upgrade but if and only if the network has entered High Alert Mode.

This structure aims to activate preventive measures “automatically” under critical conditions, ensuring enhanced security and adaptability in the face of unexpected challenges.

[bobby]

Hi Polynya, thank you for the feedback.

In future, I’d like to see the exact code payload for protocol upgrade proposals.

I agree.

There will not be any execution of transactions before Vote #2, as the final set of Security Council members is still being finalized and will be voted on by the Token House in Vote #2. Votes #1 and #2 will be executed together by submitting a transaction that adds Security Council members’ addresses to the upgrade multisig. The Foundation will share the proposed transaction to change signers as part of the Vote #2 milestone once the final set of Security Council members’ addresses is available.

As noted from your previous feedback on the Bedrock protocol upgrade, all future protocol upgrades submitted by OP Labs or the Foundation will include a commit hash with a specific code payload for voters to review. This requirement will also be included in the forthcoming template for protocol upgrade proposals.

this should soon be an automated process like in many DAOs […] which would minimize the SC’s role only to emergency situations. That should then evolve to only pause rights (all execution by governance itself) and eventually complete dissolution of the SC.

This is the intended future for the Security Council and protocol upgrades going forward. We recognize this initial Security Council structure is a good first step, but in further iterations, the Collective can make additional trust minimizing improvements.

Thank you for your support of this first step, and thank you for pushing for further progress.

[Sator]

The intention behind this inquiry is to ensure a well-structured and effective decision-making process within the Security Council, especially in the face of disagreements. Could you elucidate the conflict resolution procedures within the Security Council?

[chaselb]

Has there been an analysis of potential areas of attack or exploitation of this structure? What are the potential risks here?

[Joxes]

We’re happy to see Optimism governance introduce the Security Council this season. We agree that the council should be made up of ethical, committed people with expertise in the area to carry out its activities minimizing the risks that still imply having the power to update the entire chain with the acceptance of a few parties.

One point to highlight is the region considerations, both geographic and more importantly time zone, I think are critical to have.

Some questions:

1. About delayed upgrades, maybe the docs are not clear enough; does all upgrades have ALL a 14 delay period or is there a method to execute them immediately for, by example, emergency purposes?

2. Deleting an output for any reason other than OP Mainnet bugs/invalid outputs is considered a violation of the Law of Chains?

3. A little more clarity here, can the Security Council act in an emergency if the sequencer, batcher or proposer acts maliciously (let’s say, massive censorship that not even governance can operate)?

4. What is the method that will be used to check reaction times (also liveness)?
   Idea: carry out drills in a completely random way in groups and individually.

5. From the Security Council Charter v0.1: "If the number of signers is reduced below 8, then a safety mechanism is activated which hands control of the Security Council to the Foundation.
   "What is this mechanism and how does the Foundation intend to enforce it?

Thank you!

[linda]

I voted for this proposal since it sounds reasonable to me at this stage.

[chaselb]

Can we get more information on how the cohorts work? The charter mentions that there is an initial cohort, who’s term lasts for 12 months, and a second, staggered cohort. Why do we have staggered elections?

[Joxes]

Hello, just pinning my questions, and looking for answers before this voting period ends, thanks!

cc: @bobby

[lefterisjp]

Happy to finally see a proper step towards removing centralization from the hands of the foundation. A security council like others rollups already have is important.

[kaereste]

The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.

We’ll be voting in favour of the proposal as we believe establishing a Security Council is an important step towards decentralisation. We understand the reason behind and we’re onboard with the implementation of the council in phases.

[bobby]

Sorry for the delay @Joxes and thanks for your patience.

does all upgrades have ALL a 14 delay period or is there a method to execute them immediately for, by example, emergency purposes?

All upgrades have a 14 day delay period. There is a withdrawal pause functionality that may be used by the Foundation in the event of emergency situations. This means that in the case of an emergency bugfix, L2 → L1 messages would be delayed by 14 days as well. We think that this is the right tradeoff to make, because it means that the Security Council cannot unilaterally pass an upgrade which steals assets.

Deleting an output for any reason other than OP Mainnet bugs/invalid outputs is considered a violation of the Law of Chains?

Based on the Law of Chains, deleting or censoring valid outputs on an OP Chain would generally be considered a violation, unless done to address a clear security threat or bug.

Specifically: the Law of Chains states that OP Chain state transitions must follow the rules defined by the OP Stack to uphold state transition validity (Section 3).

OP Chain state transitions, and cross-chain messages sent to or from OP Chains, must only be finalized if they follow the rules defined by the most recent Optimism Governance-approved release of the OP Stack.

It also notes that Chain Servicers censoring or limiting transactions to extract profit or violate User Protections would violate security, uptime and liveness protections (Section 3).

A Chain Servicer that: illegitimately censors, reorders, or limits transactions (e.g., by running off-chain sequencing code that is not approved by Optimism Governance, or by colluding with L1 validators to artificially inflate sequencer batch submission costs) in order to extract a profit or violate User Protections.

Finally, it also states that “Chain Servicers must promptly address emergency bug fixes or other security compromises.”

can the Security Council act in an emergency if the sequencer, batcher or proposer acts maliciously (let’s say, massive censorship that not even governance can operate)?

From the Security Council Charter: “The Security Council is permitted to preemptively address actual or anticipated bugs, defects, unplanned maintenance, or stability, integrity, availability, non-repudiation or other security issues with the OP Stack or any OP Chain." (Emergency Response section)

The Charter also states: “All protocol upgrades, and the specific designation change that removes a sequencer for the sequencer allowlist, are subject to a 14 day delay period before becoming effective.” (Delayed Upgrades section)"

However, the Law of Chains makes clear that enforcement of the Law of Chains is the responsibility of Optimism Governance. In other words, the Security Council’s ability to remove a sequencer should only be used for security-related incidents; more general violations of the Law of Chains should be adjudicated and enforced by Governance, not the Security Council.

What is the method that will be used to check reaction times (also liveness)?

Liveness checks will ensure that signers have access to their keys by extending the Safe contracts added functionality. The exact mechanism is currently under development. :

From the Security Council Charter v0.1: “If the number of signers is reduced below 8, then a safety mechanism is activated which hands control of the Security Council to the Foundation.” What is this mechanism and how does the Foundation intend to enforce it?

This mechanism will be implemented in a new Safe module contract. In the event that the number of signers drops to 7, all signers will be removed and the Foundation will be added as the sole signer.

[bobby]

@chaselb

Can we get more information on how the cohorts work? The charter mentions that there is an initial cohort, who’s term lasts for 12 months, and a second, staggered cohort. Why do we have staggered elections?

Some potential benefits of the staggered cohort model:

• Provides continuity - at least 50% of council participants carry over their knowledge and experience at any given time.
• Allows periodic refreshment of perspectives - new members regularly join through elections.
• Avoids full turnover at once - retains institutional knowledge.
• Spreads out election cycles - prevents fatigue if all seats were up at the same time.
• Smooth transitions - outgoing and incoming members can share knowledge.

[Joxes]

Thank you so much @bobby for the explanation. Nothing more to add, now is more clear for us.

We vote FOR this proposal.

The eventual introduction of the Security Council is an obvious step in the right direction and we are happy that it’s happening now. The details provided in the documentation and clarifications in this thread lead us to believe that Security Council Charter cover all the necessary points to achieve its effectiveness and reduce the previous risks as well as the new ones with this change.

[Base]

We are supportive of the Security Council. Once live and approved by Governance, the Security Council will help secure and decentralize OP Mainnet, Base, and other chains that will be built on the OP Stack and participate in the Superchain.

Though we would like to show our support in this voting cycle, we do not currently have the technical ability to vote (working on making it happen!) and are still listening and refining our overall strategy around our governance involvement (give us feedback here). We will share more updates with the Community as we progress.

[Vincent_APACDAO]

Hi, would be great if the Optimism community can have more details about the proposed changes to the security model of the Security Council covering the matters below.

(1) The background of the proposed change to the security model in particular why it is necessary, the challenges or vulnerabilities it aims to address, and the impact in terms of the benefits of the proposed change on the OP Mainnet.

(2) The extent to which the Security Council Charter alligns with industry best practices and helps enhance the overall security posture of the OP Mainnet and beyond to cover other OP Chains within the Superchain.

(3) The circumstances under which the Security Council can act preemptively with examples or scenarios that qualify as “defined emergency situations.”

(4) The essence of the Security Considerations including the key security measures set out in a non-technical manner that can be read and understood by lay persons among the community.

(5) The rationale for the choice of numbers for the 76% approval threshold and 30% quorum in particular the considerations that led to selecting these specific numbers.

Looking forward to some information on the above.

Cheers.