Security Council: Vote #1 - Change to Security Model

Technical Proposals 📃
,
21

(1) Background of the Proposed Change:
The proposed change to the security model involves transitioning control of the OP Mainnet’s protocol upgrades from a centralized entity (the Foundation multisig) to a Security Council multisig. This change aims to decentralize control and enhance security by preventing a single party from unilaterally upgrading the system, modifying rollup state, or censoring transactions. It introduces a phased approach (Phase 0 and Phase 1) to implement this transition, starting with the Security Council as one of the signers on a 2/2 multisig.

(2) Alignment with Industry Best Practices:
The Security Council Charter is designed to align with industry best practices for decentralized governance. It introduces a collective decision-making process and outlines the roles and responsibilities of the Security Council members. The goal is to enhance the overall security posture of OP Mainnet and other OP Chains within the Superchain by distributing decision-making authority among elected representatives rather than relying on a central authority.

(3) Circumstances for Preemptive Action:
The Security Council can act preemptively in defined emergency situations to ensure the safety and security of the network without direct Governance approval. Examples of such situations could include critical vulnerabilities or imminent threats where immediate action is required to protect the network. Participants may also take actions deemed necessary to comply with applicable laws.

(4) Security Considerations:
The Security Council operates using a Gnosis Safe multisig wallet, and participants follow the Security Council Charter during normal operations. During emergencies, the Council can act without direct Governance approval to address immediate threats. Dysfunctional participants can be checked without compromising security. The Security Council’s responsibilities include implementing protocol upgrades and role designations directed by Optimism Governance.

(5) Rationale for Approval Thresholds:
This is my assumption, maybe The Foundation has a different view.

The proposal suggests a 76% approval threshold and a 30% quorum for the Security Council’s implementation. The specific numbers may be chosen based on a balance between achieving a substantial majority for consensus while maintaining a reasonable quorum to ensure community participation. The thresholds reflect a desire for strong support (76%) and community engagement (30%) before proceeding with such a fundamental change.

2 Likes
22

After revisiting the charter, it states, “The exact number of participants depends upon candidate outreach, which is ongoing. This Charter will be updated with exact participant numbers and signing thresholds according to the change process outlined below before the Security Council is implemented.”

An aspect to take into account, especially since the exact number of participants remains unspecified (as far as I know), is the issue of liveness. An elevated threshold for the Security Council might lead to delays in taking necessary actions, such as fixing a bug. This problem becomes even more obvious when coordinating among a relatively large group spread across various time zones, where members could be engaged elsewhere/unavailable due to differing sleep schedules. The plan to implement a 75% threshold is gud as explained by the stages requirements update from L2Beat and in my opinion, a 6 out of 8 setup would make this liveness issue less constraining than having a 9 out of 12 setup for example.

That being said, it may also be a viable option to establish a lower threshold for temporarily halting the L2 operations, with the understanding that this can be bypassed by an higher threshold if needed.

2 Likes