[FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization

Technical Proposals 📃 Protocol Upgrade
1

Hi Maurelian here, I’m a protocol security engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not represent or speak on behalf of, the Optimism Foundation.

Executive Summary

The protocol upgrade is intended to increase the security and decentralization of the Superchain by meeting the following requirements:

  1. Increasing the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners. This meets the 75% threshold requirement for a Stage 1 rollup outlined in L2Beat’s Stages framework.

  2. Reassigning the role of Guardian from the Foundation to a new Guardian Safe with the Security Council Safe as its sole owner. This moves the Superchain closer to satisfying the 1 week exit window requirement for Stage 1.

    Additionally the Foundation is appointed to the new DeputyGuardian role which is able to act as Guardian through the Guardian Safe. This appointment can be revoked by the Security Council Safe at any time.

    Even though the appointment of the DeputyGuardian is closer to a change in configuration than version, it is a fundamental component of the Superchain’s security model and thus we are requesting governance approval (as would, we believe, any decision to use the Security Council Safe to modify the DeputyGuardian).

    Note that the Guardian role is generally authorized to enforce ‘Safety over Liveness’ in the system, meaning that it can currently pause and unpause withdrawals, and following the Fault Proofs upgrade will be able to intervene in the event that a bug would allow an invalid L2 output to be finalized.

  3. Reassigning the owner of the L2ProxyAdmin contract from the Foundation to the Security Council (currently in Phase 0, which is a joint 2/2 multisig between the Security Councils Safe and the Foundation Safe). This ensures the Security Council Safe has a blocking vote for L2 predeploy upgrades and is a requirement for Stage 1.

If this vote passes, we recommend the upgrade be deployed shortly after the end of the veto period.

Specifications

The full specifications for the Liveness Extension and Deputy Guardian system are available from the specs repo.

Technical Details

This upgrade does not affect the node or execution client software.

The following outlines the full set of changes to the existing system:

  1. The SecurityCouncilSafe is modified to:

    1. Increase its threshold from 4 to 10. The current owner count is 13 and will remain unchanged with this upgrade.

    2. Extend its functionality by enabling new LivenessModule and LivenessGuard contracts.

      This module and guard comprise a liveness checking mechanism intended to ensure that any loss of access to a signer’s keys is identified and addressed within a predictable period of time.

      The maximum time during which an owner will be considered live without having signed a transaction or else explicitly calling the guard to demonstrate liveness, will be 3 months14 weeks. Should an owner not be live during that time, the Module will enable that owner to be removed without requiring a threshold of owners to sign. The duration of 14 weeks is chosen to be slightly longer than 3 months, so that liveness can be demonstrated on a regular quarterly cadence.
      In the unlikely event that enough owners are removed to reduce the total number of owners below 8, then the module will enable all owners to be removed and be replaced with the Foundation as the sole owner.

  2. A new GuardianSafe is deployed, which has a threshold of 1, and the Security Council Safe as its only owner.

    A new DeputyGuardianModule is enabled on this GuardianSafe. This module enables the FoundationSafe to call any of the Guardian authorized actions in the SuperchainConfig and OptimismPortal contracts.

    This architecture will allow the Foundation to maintain the fast incident response system it has established, while providing the Security Council Safe with the ultimate authority to:

    • override and reverse any Guardian actions taken by the Foundation.
    • revoke the capacity to act as the Guardian by disabling the DeputyGuardianModule.

  3. The SuperchainConfig contract is upgraded with the GuardianSafe in the Guardian role (the code is unchanged).

  4. The L2ProxyAdminOwner is set to the aliased address of the L1ProxyAdminOwner, which is the Phase 0 Security Council.

    The L1ProxyAdminOwner (i.e., the Phase 0 Security Council) can now send bridging messages from L1 to L2 to upgrade predeploy contracts on L2. This ensures the Security Council Safe has a blocking vote for L2 predeploy upgrades.

    The L2ProxyAdminOwner is changed by calling transferOwnership() on L2ProxyAdmin with the aliased address of the L1ProxyAdmin.

These contracts are tagged in the optimism repo at commit 9047beb (tagged as release candidate op-contracts/v1.5.0-rc.1).

Security Considerations

Code Security

Consistent with the OP Labs Audit Framework, OP Labs had the code audited by a Cantina contest which ended on May 10th. A Lead Security Researcher from Spearbit was also engaged to audit the system in parallel.

This audit uncovered no High severity issues, however a number of improvements were identified which we elected to make in order to reduce the potential for issues resulting from human error. A draft of the report can be viewed here. It will be finalized after the completion of judging and escalation, however OP Labs has reviewed the findings with assistance from the Cantina/Spearbit team and are confident that no High severity issues were identified.

Those changes (all in the LivenessModule) are:

  1. A constructor check was removed, which enforced that the Safe’s threshold was greater than 75% of the owner count at the time of the module’s deployment. This check reduces the likelihood of the module being enabled on a misconfigured Safe, but also made the deployment and upgrade process more difficult. The check will instead be done at upgrade time, thus ensuring no loss of safety (PR here).
  2. Error message handling was modified to be more consistent with other portions of the codebase (PR here).
  3. The module will be deactivated in the event that ownership of the Security Council Safe is transferred to the FALLBACK_OWNER (the Foundation Safe). This mitigates the risk of unexpected behavior when the Safe is operating below the expected minimum number of owners (PR here).

Operational Security

We will also establish monitoring systems for detecting events associated with the code. These systems will detect and alert on the following events:

  1. In the LivenessModule

    1. When a signer on the Security Council Safe is no longer live and can be removed.
    2. When a signer is added or removed.
    3. When the fallback owner is activated.

  2. On the Security Council Safe:

    1. When either the LivenessModule or LivenessGuard are removed or replaced.
    2. When any other module or guard is added or removed.

  3. On the DeputyGuardianModule:

    When any of the Guardian actions are taken using the module, including:

    1. Calling pause/unpause on the SuperchainConfig contract.
    2. Calling blacklistDisputeGame, setRespectedGameType on an OptimismPortal contract.

Proxy Admin Owner Security

According to the Stages framework, one of the requirements for Stage 1 is that “Users’ withdrawals cannot be censored by the permissioned operators”. This means that any vector to halt or censor users’ withdrawals OR steal users’ funds must be controlled by the Security Council.

An attack vector exists whereby the L2ProxyAdminOwner can potentially steal users’ funds by upgrading L2 predeploy contracts. The specific attack is:

To ensure “no permissioned operators” can censor users’ withdrawals or steal users’ funds (and therefore satisfy Stage 1 requirements), the L2ProxyAdminOwner is being transferred from the Foundation Safe to the L2 alias of the Phase 0 Security Council. The Security Council Safe will now have a blocking vote on all L2 predeploy upgrades.

Impact Summary

OP Labs does not anticipate any downtime due to this upgrade. Node operators are not affected. Existing contracts retain their current interfaces in order to remain backward compatible with any existing integrations.

These changes primarily affect the system of ownership and authorization, and serve to increase the decentralization of the Superchain.

Action Plan

If this proposal passes a Token House vote, the L1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle #23a. The upgrade will be completed atomically such that all affected L1 contracts will be upgraded within a single transaction.

No action is required by node operators, as this is change affects contracts only.

If a critical security issue is discovered before upgrading, OP Labs will collaborate with the community to extensively communicate that the upgrade will no longer occur.

Conclusion

This upgrade moves the Superchain forward in terms of decentralization, while preserving existing incident response capabilities and providing safety against potential liveness failures.

10 Likes
2

As Security Council Lead, I am excited and proud to see this proposal to progress the Security Council from Phase 0 to Phase 1. This is a huge step in further decentralizing the Superchain :clap: .

This is a significant change from the current signing threshold, which is 4/13. Signing data from the last two proposal upgrades signed by the Security Council is as follows:

  • 13/13 SC members submitted signatures for Proposal Upgrade 4; and
  • 12/13 SC members submitted signatures for Proposal Upgrade 6.

Based on these numbers, I do not anticipate any issues with the Security Council meeting the increased signing threshold (75%). During Phase 0, the Security Council was operating on the basis that it should be meeting a 75% signing threshold, in anticipation of moving to Phase 1.

I am confident in the ability of the individuals and entities who make up the OP Security Council to meet the new requirements and additional scope set out in this proposal.

If anyone is interested in keeping up to date on the Security Council, monthly updates are posted on opsc.vercel.app.

6 Likes
3

Hey @maurelian thanks for the detailed post. Nice especially to see the SC bump to 10/14 .

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

1 Like
4

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

1 Like
5

Thanks @maurelian for putting together the detailed proposal for the Superchain to aim to achieve the Stage 1 requirements. It’s great to see the continuous efforts to improve on the security, integrity and decentralization of the rollup.

We are an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote.

1 Like
6

I had to combine this document with the Fault Proofs post to understand the whole process and I feel there are a few gray areas.

  1. Manual Verification Process: None of them specifically address the manual verification process for the AnchorStateRegistry mentioned in the Fault Proofs post. Clarifying who will conduct this verification and how it will be carried out would provide a more complete picture.

  2. Specific Actions of the Guardian: While both documents discuss the role of the Guardian and its authority within the system, I can’t find examples of specific actions that the Guardian might take in various scenarios like dispute resolution, protocol upgrades or invalid output roots

  3. Timeline and Coordination: Both documents outline the proposed actions and upgrades, but are they going to be implemented as soon as the Token House approves?

Sorry if this question has already been addressed. With all the S6 governance documents, I haven’t had the chance to give these documents the proper time. Thank you for your patience.

3 Likes
7

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote

8

I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

9

We are an Optimism delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

10

On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal:

The Optimism team has proposed three important changes to enhance the security and decentralization of the network. This is a summary of these changes aimed to be digestible by non-technical members of the Optimism Collective.

All of these changes are aimed at achieving a technical description of Stage 1 Decentralization, which is a critical step towards decentralizing the OP stack. These changes have the goal of increasing the security of the OP stack, improving decentralization, and enabling strong incident response.

These changes have been audited by third party auditors in a Cantina contest which ended on May 10th. A Lead Security Researcher from Spearbit was also engaged to audit the system in parallel. The audits uncovered no High severity issues.

1. Increase in Security Council Threshold:

  • Current State: Decisions require 4 out of 13 members to approve.
  • Proposed Change: Increase this to 10 out of 13 members.
  • Reason: This higher threshold ensures that more members must agree before any decision is made, significantly improving the network’s security by reducing the risk of a small group making unilateral decisions.

Thresholds: Threshold signatures are ways to ensure that some group of authorized organizations or individuals have to agree before authorizing an action. For example Imagine you and your friends have a magical treasure chest. To open it, you need a special key. But, instead of one person having the key, the key is split into pieces. Each friend holds a piece of the key.

To open the chest, you need a certain number of friends (say 3 out of 5) to put their pieces together. This way, no single person can open the chest alone; it requires teamwork. This makes sure the treasure is safe and only opened when enough friends agree. In general when the threshold is higher, this requires more parties to agree on unlocking the chest.

The Security council makes decisions in a similar way to ensure one entity doesn’t have the ability to make unilateral decisions. The chest in this scenario is a smart contract that authorizes actions. Right now the threshold is low (only 4 out of 13 members need to put their key piece together) this upgrade increases the security by requiring that 10 out of 13 key pieces are needed to authorize upgrade changes. The increase in the security council threshold requires that members of the security council need to agree before decisions are made, which improves the network security by reducing the risk that a small group makes unilateral decisions. Notably this meets the 75% threshold requirement for a Stage 1 rollup outlined in L2Beat’s Stages framework which is a respected framework for evaluating the stages of decentralization of rollups.

2. Guardian Role Transfer:

  • Current State: The Foundation currently holds the Guardian role.
  • Proposed Change: Transfer this role to a new entity called the Guardian Safe, which will be controlled by the Security Council.
  • The foundation will be appointed the Deputy Guardian Role, which has the ability to act as a guardian through the Guardian Safe.

The Guardian Role is able to pause withdrawals from the OP stack in an unprecedented event in which there is a critical vulnerability in the fault proof system. Withdrawals are the act of withdrawing assets from an OP chain to Ethereum mainnet. The fault proofs are meant to make this process permissionless. But in the scenario where an attacker could withdraw more than they have (withdrawing other users’ funds from the OP Chain), the Guardian Role can stop the attacker. This is considered a short term safeguard, but critical to ensure the safety of the Optimism ecosystem in the case of a catastrophic event. In practice the Guardian Role is a smart contract that can only be called by an authorized wallet. This proposal sets the Security Councils threshold (as described above) as the authorized Guardian. This change also delegates the Guardian capabilities to the foundation by assigning them the Deputy Guardian Role, allowing the foundation the same abilities as the Guardian Role (to pause withdrawals). In practice this upgrade only changes the configuration of the Guardian such that the Optimism network can move closer to the stage 1 decentralization described by L2 Beat.

  • Current State: The ownership of the L2ProxyAdmin contract is the Optimism Foundation multisig.
  • Proposed Change: Reassign this ownership to a 2/2 threshold between the Security Council and the Optimism Foundation.
  • Reason: By transferring the ownership to the Security Council, the control over key administrative functions becomes more decentralized, preventing any single entity from having too much control over the system’s critical upgrades and changes.

This change ensures that the Security Council Safe has a blocking vote for L2 pre-deploy upgrades and is a requirement for Stage 1. This means that when a networking upgrade is being voted on, the security council can vote against a network upgrade and prevent the vote from passing. This is important because not all upgrades are safe and if there is a network upgrade that is proposed that has security vulnerabilities, the security council should be able to stop the proposal from passing.

14 Likes
11

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

1 Like
12

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

13

I am concerned about the increase to 10/13 for SC multisig. Its better in terms of security to make upgrades but introduces new risks in terms of loss of keys or liveliness within a certain time frame to 4/13. It would also now require 4 SC members to collude and stop upgrades/hold us ransom. I would prefer it to be closer to 8/13 60% or 9/13 70%. It feels safer to me.

As for the other four upgrades, I feel are all understandable to implement.

2 Likes
14

If you received answers to these questions somewhere else, you mind linking it here for reference? I’m also curious about these questions you asked.

Separate clarifying question: when all of these changes implemented, what powers will the foundation continue to have in the network? Just as the deputy guardian? Does the Foundation need to approve/execute any other upgrades (say, contracts on L1?).

15

Check the recording link posted here, next to the end of the call they address these questions:

4 Likes
16

As far as liveness/losing keys goes, I think there is a module built in if one of the addresses doesn’t prove liveness within 14 weeks.

17

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

1 Like
18

Thank you for the good explanation on the call.

I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move towards a vote.

1 Like
19

The verification should be carried out by the Security Council (SC). The OP Labs will provide a L2 block number anchor that the SC will verify that its output is configured in the AnchorStateRegistry. The SC will need access to an op-node to verify this.

The procedure can be summarized as:

  1. OP Labs provides a recent block number used to initialize the AnchorStateRegistry
  2. Given an op-node, the SC will run the following script to verify the AnchorStateRegistry:
set BLOCK_NUMBER # Anchored L2 block provied by OP Labs
set ASR # AnchorStateRegistry address
set OPNODE_URL
ROOT=$(cast rpc optimism_outputAtBlock $(cast --to-hex $BLOCK_NUMBER) --rpc-url $OPNODE_URL | jq .outputRoot)
cast call $ASR 'anchors(uint32) returns(bytes32,uint256)' 0

The output of cast call must correspond to the ROOT and provided BLOCK_NUMBER.

#!/bin/bash
set -euo pipefail
L1URL="${1:?Must specify L1 RPC URL}"
OPNODEURL="${2:?Must specify op-node RPC URL}"
ASR="${3:-0x18DAc71c228D1C32c99489B7323d441E1175e443}"

RESULT=$(cast call  --rpc-url "${L1URL}" "${ASR}" 'anchors(uint32) returns(bytes32,uint256)' 0)
# First result is the output root
ACTUAL_ROOT=$(echo "$RESULT" | head -n 1)
# Second result is the block number but cast outputs it in decimal and scientific notation (e.g. 120059865 [1.2e8])
# So trim to just the decimal number
BLOCK_NUM=$(echo "$RESULT" | tail -n 1 | cut -d ' ' -f 1)

echo "Block Number: ${BLOCK_NUM}"
echo "Actual:       ${ACTUAL_ROOT}"

BLOCK_HEX=$(cast --to-hex "${BLOCK_NUM}")
EXPECTED_ROOT=$(cast rpc optimism_outputAtBlock "${BLOCK_HEX}" --rpc-url "${OPNODEURL}" | jq -r .outputRoot)
echo "Expected:     ${EXPECTED_ROOT}"

if [[ "${EXPECTED_ROOT}" == "${ACTUAL_ROOT}" ]]
then
    echo "Anchor state is valid"
else
    echo "Anchor state is invalid"
fi

The Guardian is able to take 4 actions, which are enumerated in the DeputyGuardian module’s specification:

  1. Pause withdrawals
  2. Unpause withdrawals
  3. Blacklist a dispute game
  4. Set the respected game type

The intention is to finalize both upgrades as soon as possible after the Token House approves, and the Citizen’s House veto period has passed on Wednesday June 5th.

However its worth noting that the two changes are independent of each other, and if for whatever reason either proposal does not go forward, they are not mutually dependent and can be activated independently.

2 Likes
20

As part of the Path to Open Metagovernance, we’re experimenting with polls to collect more community input.

Was this non-technical summary useful?

Please provide any additional feedback in the comments below

This summary was effective at explaining the contents of the proposal
  • 1
  • 2
  • 3
  • 4
  • 5
0 voters
This summary influenced my confidence in voting on the proposal
  • 1
  • 2
  • 3
  • 4
  • 5
0 voters
  • I still do not understand this proposal
0 voters