Profile of maurelian in Optimism

Posts by maurelian

• [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 22, 2024, 4:38 p.m.
  Content: Gonna.eth: 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. The verification should be carried out by the Security Council (SC). The OP Labs will provide a L 2 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: OP Labs provides a recent block number used to initialize the AnchorStateRegistry Given an op-node, the SC will run the following script to verify the AnchorStateRegistry: set BLOCK_NUMBER # Anchored L 2 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(uint 32 ) returns(bytes 32 ,uint 256 )' 0 The output of cast call must correspond to the ROOT and provided BLOCK_NUMBER. #!/bin/bash set -euo pipefail L 1 URL="${ 1 :?Must specify L 1 RPC URL}" OPNODEURL="${ 2 :?Must specify op-node RPC URL}" ASR="${ 3 :- 0 x 18 DAc 71 c 228 D 1 C 32 c 99489 B 7323 d 441 E 1175 e 443 }" RESULT=$(cast call --rpc-url "${L 1 URL}" "${ASR}" 'anchors(uint 32 ) returns(bytes 32 ,uint 256 )' 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 . 2 e 8 ]) # 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 Gonna.eth: 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 The Guardian is able to take 4 actions, which are enumerated in the DeputyGuardian module’s specification: Pause withdrawals Unpause withdrawals Blacklist a dispute game Set the respected game type Gonna.eth: 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? 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 5 th. 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.
  Likes: 2 Replies: 0
  Likers: Gonna.eth, Butterbum
  No replies yet.
• Upgrade Proposal: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 22, 2024, 12:38 p.m.
  Content: Gonna.eth: 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. The verification should be carried out by the Security Council (SC). The OP Labs will provide a L 2 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: OP Labs provides a recent block number used to initialize the AnchorStateRegistry Given an op-node, the SC will run the following script to verify the AnchorStateRegistry: set BLOCK_NUMBER # Anchored L 2 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(uint 32 ) returns(bytes 32 ,uint 256 )' 0 The output of cast call must correspond to the ROOT and provided BLOCK_NUMBER. #!/bin/bash set -euo pipefail L 1 URL="${ 1 :?Must specify L 1 RPC URL}" OPNODEURL="${ 2 :?Must specify op-node RPC URL}" ASR="${ 3 :- 0 x 18 DAc 71 c 228 D 1 C 32 c 99489 B 7323 d 441 E 1175 e 443 }" RESULT=$(cast call --rpc-url "${L 1 URL}" "${ASR}" 'anchors(uint 32 ) returns(bytes 32 ,uint 256 )' 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 . 2 e 8 ]) # 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 Gonna.eth: 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 The Guardian is able to take 4 actions, which are enumerated in the DeputyGuardian module’s specification 2 : Pause withdrawals Unpause withdrawals Blacklist a dispute game Set the respected game type Gonna.eth: 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? 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 5 th. 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.
  Likes: 2 Replies: 0
  Likers: Gonna.eth, Luckyhooman.eth
  No replies yet.
• [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 22, 2024, 12:38 p.m.
  Content: Gonna.eth: 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. The verification should be carried out by the Security Council (SC). The OP Labs will provide a L 2 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: OP Labs provides a recent block number used to initialize the AnchorStateRegistry Given an op-node, the SC will run the following script to verify the AnchorStateRegistry: set BLOCK_NUMBER # Anchored L 2 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(uint 32 ) returns(bytes 32 ,uint 256 )' 0 The output of cast call must correspond to the ROOT and provided BLOCK_NUMBER. #!/bin/bash set -euo pipefail L 1 URL="${ 1 :?Must specify L 1 RPC URL}" OPNODEURL="${ 2 :?Must specify op-node RPC URL}" ASR="${ 3 :- 0 x 18 DAc 71 c 228 D 1 C 32 c 99489 B 7323 d 441 E 1175 e 443 }" RESULT=$(cast call --rpc-url "${L 1 URL}" "${ASR}" 'anchors(uint 32 ) returns(bytes 32 ,uint 256 )' 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 . 2 e 8 ]) # 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 Gonna.eth: 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 The Guardian is able to take 4 actions, which are enumerated in the DeputyGuardian module’s specification 2 : Pause withdrawals Unpause withdrawals Blacklist a dispute game Set the respected game type Gonna.eth: 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? 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 5 th. 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.
  Likes: 2 Replies: 0
  Likers: Gonna.eth, Luckyhooman.eth
  No replies yet.
• Upgrade Proposal: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 22, 2024, 12:38 p.m.
  Content: Gonna.eth: 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. The verification should be carried out by the Security Council (SC). The OP Labs will provide a L 2 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: OP Labs provides a recent block number used to initialize the AnchorStateRegistry Given an op-node, the SC will run the following script to verify the AnchorStateRegistry: set BLOCK_NUMBER # Anchored L 2 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(uint 32 ) returns(bytes 32 ,uint 256 )' 0 The output of cast call must correspond to the ROOT and provided BLOCK_NUMBER. #!/bin/bash set -euo pipefail L 1 URL="${ 1 :?Must specify L 1 RPC URL}" OPNODEURL="${ 2 :?Must specify op-node RPC URL}" ASR="${ 3 :- 0 x 18 DAc 71 c 228 D 1 C 32 c 99489 B 7323 d 441 E 1175 e 443 }" RESULT=$(cast call --rpc-url "${L 1 URL}" "${ASR}" 'anchors(uint 32 ) returns(bytes 32 ,uint 256 )' 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 . 2 e 8 ]) # 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 Gonna.eth: 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 The Guardian is able to take 4 actions, which are enumerated in the DeputyGuardian module’s specification: Pause withdrawals Unpause withdrawals Blacklist a dispute game Set the respected game type Gonna.eth: 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? 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 5 th. 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.
  Likes: 2 Replies: 0
  Likers: Gonna.eth, Luckyhooman.eth
  No replies yet.
• [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 22, 2024, 12:38 p.m.
  Content: Gonna.eth: 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. The verification should be carried out by the Security Council (SC). The OP Labs will provide a L 2 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: OP Labs provides a recent block number used to initialize the AnchorStateRegistry Given an op-node, the SC will run the following script to verify the AnchorStateRegistry: set BLOCK_NUMBER # Anchored L 2 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(uint 32 ) returns(bytes 32 ,uint 256 )' 0 The output of cast call must correspond to the ROOT and provided BLOCK_NUMBER. #!/bin/bash set -euo pipefail L 1 URL="${ 1 :?Must specify L 1 RPC URL}" OPNODEURL="${ 2 :?Must specify op-node RPC URL}" ASR="${ 3 :- 0 x 18 DAc 71 c 228 D 1 C 32 c 99489 B 7323 d 441 E 1175 e 443 }" RESULT=$(cast call --rpc-url "${L 1 URL}" "${ASR}" 'anchors(uint 32 ) returns(bytes 32 ,uint 256 )' 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 . 2 e 8 ]) # 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 Gonna.eth: 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 The Guardian is able to take 4 actions, which are enumerated in the DeputyGuardian module’s specification: Pause withdrawals Unpause withdrawals Blacklist a dispute game Set the respected game type Gonna.eth: 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? 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 5 th. 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.
  Likes: 2 Replies: 0
  Likers: Gonna.eth, Luckyhooman.eth
  No replies yet.
• [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 16, 2024, 5 p.m.
  Content: 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: 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 L 2 Beat’s Stages framework 5 . 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 1 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 L 2 output to be finalized. Reassigning the owner of the L 2 ProxyAdmin 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 L 2 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 2 . 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: The SecurityCouncilSafe is modified to: Increase its threshold from 4 to 10 . The current owner count is 13 and will remain unchanged with this upgrade. 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 months 14 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. 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. The SuperchainConfig contract is upgraded with the GuardianSafe in the Guardian role (the code is unchanged). The L 2 ProxyAdminOwner is set to the aliased 1 address of the L 1 ProxyAdminOwner, which is the Phase 0 Security Council. The L 1 ProxyAdminOwner (i.e., the Phase 0 Security Council) can now send bridging messages from L 1 to L 2 to upgrade predeploy contracts on L 2 . This ensures the Security Council Safe has a blocking vote for L 2 predeploy upgrades. The L 2 ProxyAdminOwner is changed by calling transferOwnership() on L 2 ProxyAdmin with the aliased address of the L 1 ProxyAdmin. These contracts are tagged in the optimism repo at commit 9047 beb (tagged as release candidate op-contracts/v 1 . 5 . 0 -rc. 1 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 10 th. 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 3 . 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: 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). Error message handling was modified to be more consistent with other portions of the codebase (PR here). 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: In the LivenessModule When a signer on the Security Council Safe is no longer live and can be removed. When a signer is added or removed. When the fallback owner is activated. On the Security Council Safe: When either the LivenessModule or LivenessGuard are removed or replaced. When any other module or guard is added or removed. On the DeputyGuardianModule: When any of the Guardian actions are taken using the module, including: Calling pause/unpause on the SuperchainConfig contract. Calling blacklistDisputeGame, setRespectedGameType on an OptimismPortal contract. Proxy Admin Owner Security According to the Stages framework 1 , 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 L 2 ProxyAdminOwner can potentially steal users’ funds by upgrading L 2 predeploy contracts. The specific attack is: Upgrade the L 2 toL 1 MessagePasser contract, Insert false entries to the [sentMessages() mapping](https://github.com/ethereum-optimism/optimism/blob/maur/guardian-module/packages/contracts-bedrock/src/L 2 /L 2 ToL 1 MessagePasser.sol#L 24 ), One falsified withdrawal per asset is required to access the full balance of each ERC 20 (in the Bridge) or ETH (in the Portal) Withdraw ERC 20 s from the Bridge and ETH from the Portal To ensure “no permissioned operators” can censor users’ withdrawals or steal users’ funds (and therefore satisfy Stage 1 requirements), the L 2 ProxyAdminOwner is being transferred from the Foundation Safe to the L 2 alias 1 of the Phase 0 Security Council. The Security Council Safe will now have a blocking vote on all L 2 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 L 1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle # 23 a. The upgrade will be completed atomically such that all affected L 1 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.
  Likes: 9 Replies: 2
  Likers: polynya, cpoetter, Tane, Jepsen, brichis, Joxes, robiomarine, eugenia, Liliop.eth
  Replies:

  • alisha.eth: 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 . maurelian: Increasing the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners. 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.
  • brichis: maurelian: A draft of the report can be viewed here . Hi @maurelian! I think this link is no longer working. Can you please update it?
• Upgrade Proposal: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 16, 2024, 5 p.m.
  Content: 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: 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 L 2 Beat’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 1 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 L 2 output to be finalized. Reassigning the owner of the L 2 ProxyAdmin 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 L 2 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 1 . 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: The SecurityCouncilSafe is modified to: Increase its threshold from 4 to 10 . The current owner count is 13 and will remain unchanged with this upgrade. 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 months 14 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. 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. The SuperchainConfig contract is upgraded with the GuardianSafe in the Guardian role (the code is unchanged). The L 2 ProxyAdminOwner is set to the aliased address of the L 1 ProxyAdminOwner, which is the Phase 0 Security Council. The L 1 ProxyAdminOwner (i.e., the Phase 0 Security Council) can now send bridging messages from L 1 to L 2 to upgrade predeploy contracts on L 2 . This ensures the Security Council Safe has a blocking vote for L 2 predeploy upgrades. The L 2 ProxyAdminOwner is changed by calling transferOwnership() on L 2 ProxyAdmin with the aliased address of the L 1 ProxyAdmin. These contracts are tagged in the optimism repo at commit 9047 beb (tagged as release candidate op-contracts/v 1 . 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 10 th. 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: 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). Error message handling was modified to be more consistent with other portions of the codebase (PR here). 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: In the LivenessModule When a signer on the Security Council Safe is no longer live and can be removed. When a signer is added or removed. When the fallback owner is activated. On the Security Council Safe: When either the LivenessModule or LivenessGuard are removed or replaced. When any other module or guard is added or removed. On the DeputyGuardianModule: When any of the Guardian actions are taken using the module, including: Calling pause/unpause on the SuperchainConfig contract. Calling blacklistDisputeGame, setRespectedGameType on an OptimismPortal contract. Proxy Admin Owner Security According to the Stages framework 1 , 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 L 2 ProxyAdminOwner can potentially steal users’ funds by upgrading L 2 predeploy contracts. The specific attack is: Upgrade the L 2 toL 1 MessagePasser contract, Insert false entries to the [sentMessages() mapping](https://github.com/ethereum-optimism/optimism/blob/maur/guardian-module/packages/contracts-bedrock/src/L 2 /L 2 ToL 1 MessagePasser.sol#L 24 ), One falsified withdrawal per asset is required to access the full balance of each ERC 20 (in the Bridge) or ETH (in the Portal) Withdraw ERC 20 s from the Bridge and ETH from the Portal To ensure “no permissioned operators” can censor users’ withdrawals or steal users’ funds (and therefore satisfy Stage 1 requirements), the L 2 ProxyAdminOwner is being transferred from the Foundation Safe to the L 2 alias of the Phase 0 Security Council. The Security Council Safe will now have a blocking vote on all L 2 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 L 1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle # 23 a. The upgrade will be completed atomically such that all affected L 1 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.
  Likes: 2 Replies: 1
  Likers: polynya, cpoetter
  Replies:

  • alisha.eth: 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 . maurelian: Increasing the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners. 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.
• Upgrade Proposal: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 16, 2024, 1 p.m.
  Content: 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: 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 L 2 Beat’s Stages framework 19 . 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 5 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 L 2 output to be finalized. Reassigning the owner of the L 2 ProxyAdmin 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 L 2 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 8 . 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: The SecurityCouncilSafe is modified to: Increase its threshold from 4 to 10 . The current owner count is 13 and will remain unchanged with this upgrade. Extend its functionality by enabling new LivenessModule 9 and LivenessGuard 2 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 months 14 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. A new GuardianSafe is deployed, which has a threshold of 1 , and the Security Council Safe as its only owner. A new DeputyGuardianModule 2 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. The SuperchainConfig contract is upgraded with the GuardianSafe in the Guardian role (the code is unchanged). The L 2 ProxyAdminOwner is set to the aliased 3 address of the L 1 ProxyAdminOwner, which is the Phase 0 Security Council. The L 1 ProxyAdminOwner (i.e., the Phase 0 Security Council) can now send bridging messages 1 from L 1 to L 2 to upgrade predeploy contracts on L 2 . This ensures the Security Council Safe has a blocking vote for L 2 predeploy upgrades. The L 2 ProxyAdminOwner is changed by calling transferOwnership() on L 2 ProxyAdmin with the aliased address of the L 1 ProxyAdmin. These contracts are tagged in the optimism repo at commit 9047 beb (tagged as release candidate op-contracts/v 1 . 5 . 0 -rc. 1 1 ). Security Considerations Code Security Consistent with the OP Labs Audit Framework 4 , OP Labs had the code audited by a Cantina contest 1 which ended on May 10 th. 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 4 . 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: 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). Error message handling was modified to be more consistent with other portions of the codebase (PR here). 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 1 ). 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: In the LivenessModule When a signer on the Security Council Safe is no longer live and can be removed. When a signer is added or removed. When the fallback owner is activated. On the Security Council Safe: When either the LivenessModule or LivenessGuard are removed or replaced. When any other module or guard is added or removed. On the DeputyGuardianModule: When any of the Guardian actions are taken using the module, including: Calling pause/unpause on the SuperchainConfig contract. Calling blacklistDisputeGame, setRespectedGameType on an OptimismPortal contract. Proxy Admin Owner Security According to the Stages framework 5 , 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 L 2 ProxyAdminOwner can potentially steal users’ funds by upgrading L 2 predeploy contracts. The specific attack is: Upgrade the L 2 toL 1 MessagePasser contract, Insert false entries to the [sentMessages() mapping](https://github.com/ethereum-optimism/optimism/blob/maur/guardian-module/packages/contracts-bedrock/src/L 2 /L 2 ToL 1 MessagePasser.sol#L 24 2 ), One falsified withdrawal per asset is required to access the full balance of each ERC 20 (in the Bridge) or ETH (in the Portal) Withdraw ERC 20 s from the Bridge and ETH from the Portal To ensure “no permissioned operators” can censor users’ withdrawals or steal users’ funds (and therefore satisfy Stage 1 requirements), the L 2 ProxyAdminOwner is being transferred from the Foundation Safe to the L 2 alias 3 of the Phase 0 Security Council. The Security Council Safe will now have a blocking vote on all L 2 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 L 1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle # 23 a. The upgrade will be completed atomically such that all affected L 1 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.
  Likes: 10 Replies: 2
  Likers: polynya, cpoetter, Tane, Jepsen, brichis, Joxes, robiomarine, eugenia, Liliop.eth, revmiller
  Replies:

  • alisha.eth: 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 . maurelian: Increasing the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners. 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.
  • brichis: maurelian: A draft of the report can be viewed here . Hi @maurelian! I think this link is no longer working. Can you please update it?
• [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 16, 2024, 1 p.m.
  Content: 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: 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 L 2 Beat’s Stages framework 19 . 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 5 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 L 2 output to be finalized. Reassigning the owner of the L 2 ProxyAdmin 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 L 2 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 8 . 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: The SecurityCouncilSafe is modified to: Increase its threshold from 4 to 10 . The current owner count is 13 and will remain unchanged with this upgrade. Extend its functionality by enabling new LivenessModule 9 and LivenessGuard 2 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 months 14 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. A new GuardianSafe is deployed, which has a threshold of 1 , and the Security Council Safe as its only owner. A new DeputyGuardianModule 2 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. The SuperchainConfig contract is upgraded with the GuardianSafe in the Guardian role (the code is unchanged). The L 2 ProxyAdminOwner is set to the aliased 3 address of the L 1 ProxyAdminOwner, which is the Phase 0 Security Council. The L 1 ProxyAdminOwner (i.e., the Phase 0 Security Council) can now send bridging messages 1 from L 1 to L 2 to upgrade predeploy contracts on L 2 . This ensures the Security Council Safe has a blocking vote for L 2 predeploy upgrades. The L 2 ProxyAdminOwner is changed by calling transferOwnership() on L 2 ProxyAdmin with the aliased address of the L 1 ProxyAdmin. These contracts are tagged in the optimism repo at commit 9047 beb (tagged as release candidate op-contracts/v 1 . 5 . 0 -rc. 1 1 ). Security Considerations Code Security Consistent with the OP Labs Audit Framework 4 , OP Labs had the code audited by a Cantina contest 1 which ended on May 10 th. 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 4 . 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: 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). Error message handling was modified to be more consistent with other portions of the codebase (PR here). 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 1 ). 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: In the LivenessModule When a signer on the Security Council Safe is no longer live and can be removed. When a signer is added or removed. When the fallback owner is activated. On the Security Council Safe: When either the LivenessModule or LivenessGuard are removed or replaced. When any other module or guard is added or removed. On the DeputyGuardianModule: When any of the Guardian actions are taken using the module, including: Calling pause/unpause on the SuperchainConfig contract. Calling blacklistDisputeGame, setRespectedGameType on an OptimismPortal contract. Proxy Admin Owner Security According to the Stages framework 5 , 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 L 2 ProxyAdminOwner can potentially steal users’ funds by upgrading L 2 predeploy contracts. The specific attack is: Upgrade the L 2 toL 1 MessagePasser contract, Insert false entries to the [sentMessages() mapping](https://github.com/ethereum-optimism/optimism/blob/maur/guardian-module/packages/contracts-bedrock/src/L 2 /L 2 ToL 1 MessagePasser.sol#L 24 2 ), One falsified withdrawal per asset is required to access the full balance of each ERC 20 (in the Bridge) or ETH (in the Portal) Withdraw ERC 20 s from the Bridge and ETH from the Portal To ensure “no permissioned operators” can censor users’ withdrawals or steal users’ funds (and therefore satisfy Stage 1 requirements), the L 2 ProxyAdminOwner is being transferred from the Foundation Safe to the L 2 alias 3 of the Phase 0 Security Council. The Security Council Safe will now have a blocking vote on all L 2 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 L 1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle # 23 a. The upgrade will be completed atomically such that all affected L 1 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.
  Likes: 10 Replies: 2
  Likers: polynya, cpoetter, Tane, Jepsen, brichis, Joxes, robiomarine, eugenia, Liliop.eth, revmiller
  Replies:

  • alisha.eth: 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 . maurelian: Increasing the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners. 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.
  • brichis: maurelian: A draft of the report can be viewed here . Hi @maurelian! I think this link is no longer working. Can you please update it?
• Upgrade Proposal: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization by maurelian - No Role
  Posted on: May 16, 2024, 1 p.m.
  Content: 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: 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 L 2 Beat’s Stages framework. 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 L 2 output to be finalized. Reassigning the owner of the L 2 ProxyAdmin 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 L 2 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: The SecurityCouncilSafe is modified to: Increase its threshold from 4 to 10 . The current owner count is 13 and will remain unchanged with this upgrade. 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 months 14 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. 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. The SuperchainConfig contract is upgraded with the GuardianSafe in the Guardian role (the code is unchanged). The L 2 ProxyAdminOwner is set to the aliased address of the L 1 ProxyAdminOwner, which is the Phase 0 Security Council. The L 1 ProxyAdminOwner (i.e., the Phase 0 Security Council) can now send bridging messages from L 1 to L 2 to upgrade predeploy contracts on L 2 . This ensures the Security Council Safe has a blocking vote for L 2 predeploy upgrades. The L 2 ProxyAdminOwner is changed by calling transferOwnership() on L 2 ProxyAdmin with the aliased address of the L 1 ProxyAdmin. These contracts are tagged in the optimism repo at commit 9047 beb (tagged as release candidate op-contracts/v 1 . 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 10 th. 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: 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). Error message handling was modified to be more consistent with other portions of the codebase (PR here). 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: In the LivenessModule When a signer on the Security Council Safe is no longer live and can be removed. When a signer is added or removed. When the fallback owner is activated. On the Security Council Safe: When either the LivenessModule or LivenessGuard are removed or replaced. When any other module or guard is added or removed. On the DeputyGuardianModule: When any of the Guardian actions are taken using the module, including: Calling pause/unpause on the SuperchainConfig contract. 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 L 2 ProxyAdminOwner can potentially steal users’ funds by upgrading L 2 predeploy contracts. The specific attack is: Upgrade the L 2 toL 1 MessagePasser contract, Insert false entries to the [sentMessages() mapping](https://github.com/ethereum-optimism/optimism/blob/maur/guardian-module/packages/contracts-bedrock/src/L 2 /L 2 ToL 1 MessagePasser.sol#L 24 ), One falsified withdrawal per asset is required to access the full balance of each ERC 20 (in the Bridge) or ETH (in the Portal) Withdraw ERC 20 s from the Bridge and ETH from the Portal To ensure “no permissioned operators” can censor users’ withdrawals or steal users’ funds (and therefore satisfy Stage 1 requirements), the L 2 ProxyAdminOwner is being transferred from the Foundation Safe to the L 2 alias of the Phase 0 Security Council. The Security Council Safe will now have a blocking vote on all L 2 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 L 1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle # 23 a. The upgrade will be completed atomically such that all affected L 1 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.
  Likes: 10 Replies: 2
  Likers: polynya, cpoetter, Tane, Jepsen, brichis, Joxes, robiomarine, eugenia, Liliop.eth, revmiller
  Replies:

  • alisha.eth: 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 . maurelian: Increasing the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners. 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.
  • brichis: maurelian: A draft of the report can be viewed here . Hi @maurelian! I think this link is no longer working. Can you please update it?