Executive Summary
Hi I’m Adrian, a protocol 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.
This protocol upgrade reduces the trust assumptions for users of OP Mainnet by enabling permissionless output proposals and a permissionless fault proof system. As part of a responsible and safe rollout of Fault Proofs, it preserves the ability for the guardian to override if necessary to maintain security. As a result, withdrawals no longer depend on the privileged proposer role posting an output root, allowing the entire withdrawal process to be completed without any privileged actions. The trust assumption is reduced to requiring only that the guardian role does not act to intervene. Combined with the Guardian, Security Council Threshold and L 2 ProxyAdmin Ownership changes 36 proposal, we believe this satisfies the criteria to have OP Chains reach Stage 1 status.
If this vote passes and becomes the new governance-approved version of the OP Stack, the upgrade will be deployed to OP Mainnet by the Security Council (currently in Phase 0 , which is a joint 2 / 2 multisig between the Security Council Safe and the Foundation’s Safe) shortly after the end of the veto period.
Motivation
Securing withdrawals with a Fault Proof system is a key requirement for meeting the stage 1 19 decentralization milestone with the ultimate goal of enhancing the security of user assets.
This upgrade enables a permissionless Fault Proof system which allows anyone to propose output roots and participate in the dispute system. As a result, users will be able to withdraw assets from L 2 to L 1 without relying on the sequencer or any other centralized infrastructure.
As part of a responsible and safe rollout of Fault Proofs, it is required that at this stage, the existing Guardian role 7 capabilities are carried over to this new version, meaning that the Guardian can disable the Fault Proof system in the event of emergency. While this means the system is still not fully trustless - as is the nature of Stage 1 designation - it reduces the trust assumption to requiring only that the Guardian role does not act maliciously, rather than requiring a single permissioned proposer to actively propose. This proposed upgrade extends the Guardian role’s pause ability to be able to disable the fault proof system, an extension of its existing capabilities in the fault proofs context. For more info on how the Guardian role is expected to be permissioned, see this post 36 .
This upgrade also includes a smart contract framework that provides a solid basis for a future multi-proof system, allowing additional proof systems to easily be added. This will further reduce trust assumptions in later upgrades as the OP Stack moves towards achieving Stage 2 decentralization.
Specifications
The full specifications for the fault dispute system are available from the specs repo 27 . If this proposal is approved, the fault dispute system specs will be promoted from the experimental section of specs, to be part of the canonical spec.
Technical Details
This upgrade does not affect the node or execution client software.
Prior to the upgrade, the fault dispute system contracts have been deployed:
DisputeGameFactory (implementation: 0 xc 641 A 33 cab 81 C 559 F 2 bd 4 b 21 EA 34 C 290 E 2440 C 2 B 24 proxy: 0 xe 5965 Ab 5962 eDc 7477 C 8520243 A 95517 CD 252 fA 9 25 ) - a factory for creating dispute games that can be used by the upgraded OptimismPortal as the source of proposed output roots.
FaultDisputeGame ( 0 x 4146 DF 64 D 83 acB 0 DcB 0 c 1 a 4884 a 16 f 090165 e 122 19 ) - an implementation of a dispute game that uses permissionless, interactive bi-section of the chain state
This is initialized with an ABSOLUTE_PRESTATE of 0 x 037 ef 3 c 1 a 487960 b 0 e 633 d 3 e 513 df 020 c 43432769 f 41 a 634 d 18 a 9595 cbf 53 c 55 . This is the initial state for the Cannon MIPS VM to run op-program tagged in the optimism repo at commit a 6 d 4 eeda 11477 adfcd 106 e 03131625 a 40334 e 3 a 6 (tagged as release op-program/v 1 . 0 . 0 ). This prestate can be rebuilt using the make reproducible-prestate command (docs 8 )
PermissionedFaultDisputeGame ( 0 xE 9 daD 167 EF 4 DE 8812 C 1 abD 013 Ac 9570 C 616599 A 0 12 ) - extends FaultDisputeGame to restrict participation to privileged roles. This can be used as a fallback in the event of failure of the fault dispute game.
AnchorStateRegistry (implementation: 0 x 6 B 7 da 1647 Aa 9684 F 54 B 2 BEeB 699 F 91 F 31 cd 35 Fb 9 6 proxy: 0 x 18 DAc 71 c 228 D 1 C 32 c 99489 B 7323 d 441 E 1175 e 443 9 ) - stores the latest “anchor” state for each available FaultDisputeGame type. By using stored anchor states, new FaultDisputeGame instances can be initialized with a more recent starting state which reduces the amount of required offchain computation.
This is initialized with the starting anchor for CANNON and PERMISSIONED_CANNON games set to block number 120059863 and output root 0 x 2694 ac 14 dcf 54 b 7 a 77363 e 3 f 60 e 6462 dc 78 da 0 d 43 d 1 e 2 f 058 dbb 6 a 1488814977 .
As the fault dispute system contracts are deployed ahead of time and are permissionless, it is possible for dispute games to be created prior to OptimismPortal being upgraded. If these games resolve that the output root is valid, the AnchorStateRegistry will be updated with the new value. The validity of the current value of the AnchorStateRegistry will be manually verified as part of the upgrade process.
DelayedWETH (implementation: 0 x 97988 d 5624 F 1 ba 266 E 1 da 305117 BCf 20713 bee 08 5 proxy: 0 xE 497 B 094 d 6 DbB 3 D 5 E 4 CaAc 9 a 14696 D 7572588 d 14 6 ) - an extension to WETH 9 that allows for delayed withdrawals. This introduces a time delay before bonds posted as part of a FaultDisputeGame can be withdrawn, allowing the Guardian role to change the allocation of bonds if there is a bug in the FaultDisputeGame to preserve incentive compatibility.
PreimageOracle ( 0 xD 326 E 10 B 8186 e 90 F 4 E 2 adc 5 c 13 a 2 d 0 C 137 ee 8 b 34 5 ) - stores validated pre-images that can be retrieved by hash. This is used by op-program and other fault proof programs to retrieve data required to perform the derivation process and validate the output root.
MIPS ( 0 x 0 f 8 EdFbDdD 3 c 0256 A 80 AD 8 C 0 F 2560 B 1807873 C 9 c 5 ) - the Cannon MIPS VM implementation. Executes a single MIPS CPU instruction on-chain as part of the step call to determine the validity of claims at the bottom level of the dispute game.
There are also two off-chain programs provided to support users interacting with the fault proof system:
op-challenger - implements the honest actor algorithm for the FaultDisputeGame to automatically challenge invalid output root proposals and defend valid ones.
op-dispute-mon - monitors the fault proof system, exposing a variety of metrics that enable monitoring and alerting of the fault proof system, such as when games are forecast or have resolved with a status that is inconsistent with the local op-node used by op-dispute-mon.
The following changes are being introduced with the upgrade:
Upgrade the OptimismPortal contract ( 0 xe 2 F 826324 b 2 faf 99 E 513 D 16 D 266 c 3 F 80 aE 87832 B 20 ) that uses the DisputeGameFactory as the source of output proposals. (spec 9 )
The proveWithdrawalTransaction method is modified, retaining the same signature function but with the second argument now providing an index within the DisputeGameFactory’s list of created games.
Enforces an air-gap requiring a period of time (DISPUTE_GAME_FINALITY_DELAY_SECONDS) to have elapsed since the game resolved before the game can be used in a call to finalizeWithdrawalTransaction.
The Guardian role can blacklist dispute games or change the RESPECTED_GAME_TYPE to invalidate dispute games in the event of failures in the fault proof system.
Users are now able to reprove their withdrawals at any time. Previously, a user could only reprove their withdrawal if the output root was removed from the L 2 OutputOracle by the guardian, but with this upgrade users will be able to reprove their withdrawal at any time. This allows users to change the dispute game their withdrawal is proven against if needed without waiting for the game to actually resolve as invalid. The 7 day withdrawal finalization delay resets when a user reproves their withdrawal to ensure there is still a full 7 day air-gap between proving and finalizing the withdrawal.
The L 2 OutputOracle contract is no longer used
The SystemConfig contract ( 0 xF 56 D 96 B 2535 B 932656 d 3 c 04 Ebf 51 baBff 241 D 886 10 ) is updated to:
reference the DisputeGameFactory address instead of the L 2 OutputOracle address.
enforce a maximum block gas limit of 200 , 000 , 000 to prevent the gas limit being raised to the point where block execution is too resource intensive to be processed in cannon as part of the fault dispute system.
remove the setResourceConfig setter to prevent the System Config Owner 1 , from misconfiguring the resource config and preventing force inclusions from L 1 (e.g. by setting the maximum deposit gas too low). The resource config can now only be changed by upgrading the SystemConfig contract which is controlled by the L 1 Proxy Admin (a 2 -of- 2 multisig with the Optimism Foundation and Security Council).
These contracts are tagged in the optimism repo at commit 547 ea 72 d 9849 e 13 ce 169 fd 31 df 0 f 9197651 b 3 f 86 19 (tagged as release candidate op-contracts/v 1 . 4 . 0 -rc. 4 13 ).
Security Considerations
Our design philosophy has been to focus on fundamental safety mechanisms first. We acknowledge that gaining certainty in the correctness of the complex logic found within the FaultDisputeGame contract, its dependencies, and the offchain op-challenger software will take time. Therefore, we have included a number of fallback mechanisms designed to maintain the safety of the system even in the event of a complete failure of those complex components - in particular the ability for the Guardian role to pause withdrawals and disable the Fault Proof System.
The Sherlock community completed a successful bug hunt 9 , focused on issues which would allow these fundamental safety mechanisms to be subverted. See the final report 15 for further details. The reported issues have been addressed. As none of the reported issues circumvented the fundamental safety mechanisms we decided not to pursue a fix review.
Impact Summary
As part of the upgrade, all pending withdrawals will be invalidated. Users with pending withdrawals will need to re-prove their withdrawals against an output proposal submitted in the form of a FaultDisputeGame which will restart the withdrawal delay period. This means that withdrawals initiated less than one week before the upgrade is executed will only be finalized one week after the upgrade is complete. For example, a withdrawal initiated 6 days before the upgrade would take a total of 13 days to finalize.
Users reading output roots from the L 2 OutputOracle contract will need to update to read from the DisputeGameFactory.
OP Labs does not anticipate any down time due to this upgrade, and node operators are not affected.
While the normal case for dispute games allows them to resolve within the 7 day withdrawal delay period, the maximum possible time for a dispute game to resolve is 16 days which may lengthen the withdrawal delay for withdrawals proven against that dispute game. Extending a game to this point incurs a significant cost and users may reprove their withdrawal against a different output root at any time. The Game Clock section of the specs 6 provides further details.
Tooling that performs withdrawals will need to be updated to use the new DisputeGameFactory as the source of output roots when proving withdrawals. New versions of the Optimism SDK and viem have already been released with this support.
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. Prior to upgrading, the anchor state in the AnchorStateRegistry will be validated manually. If the value is invalid due to a game having resolved incorrectly prior to full deployment, a replacement version of the AnchorStateRegistry will be deployed using the starting anchor in this proposal, before upgrading contracts. The upgrade will be completed atomically such that all affected L 1 contracts will be upgraded within a single transaction.
This upgrade has already been activated on internal devnets and the op-sepolia testnet.
As this is a L 1 contracts-only upgrade, no action is required by node operators.
To prepare infra and the community for withdrawal flow changes, we will be rolling out mainnet messaging starting this week. This will expand on the preparation for breaking changes 5 implemented with contributors for OP Sepolia, which we coordinated with ~ 30 infra teams and several rounds of public posts. Mainnet communication will include:
Comms: At least two rounds of public messaging on OP social channels notifying users of the changes to withdrawal flow, and of the impact on withdrawals during the upgrade window.
Contributors: Coordinate with bridge infra contributors, including maintainers of popular frontends to the standard bridge, to post banners notifying users of the changes.
Support: Prep developer support team for inbound support tickets about transactions that need to be reproven due to not finishing the first proof in time before the changes.
Bridges: Notify bridges and other infra contributors whose operations might be impacted due to the withdrawal flow changes.
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
The deployment of a permissionless Fault Dispute System to OP Mainnet is a major step forward on the path to decentralization. This proposal is a responsible approach to the roll out, preserving the safety checks and functionality of the Guardian role while still benefiting from permissionless output proposals and laying a foundation for reaching stage 2 decentralization.
OP Labs is proposing an upgrade for their software in the Optimism ecosystem which will reduce trust assumptions for users by introducing permissionless output proposals and a fault-proof system. The upgrade aims to enhance the security of user assets by allowing withdrawals without relying on centralized infrastructure. The upgrade maintains existing security protocols and introduces mechanisms to allow for withdrawals to be re-proven, ensuring system safety. The proposal includes technical specifications for the fault dispute system, details on contract updates, and security considerations. If approved, pending withdrawals will need to be re-proven, impacting withdrawal timings for users. The deployment plan involves upgrading L1 contracts and notifying users and infra teams about the changes. It is part of OP Labs' efforts towards decentralization and system security improvements.
Gonna.eth: ajsutton:
This upgrade has already been activated on internal devnets and the op-sepolia testnet.
How long has been active? Is there any performance report?
ajsutton:
The validity of the current value of the AnchorStateRegistry will be manually verified as part of the upgrade process.
How does the manual verification happen?
Leo.Zhang: ajsutton:
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
@ajsutton So when will be the proposal implemented on mainnet? Is there a specific timeline? Thank you!
brichis: ajsutton:
See the final report for further details.
Hey @ajsutton! I think this link is no longer working. Can you please update it?
system: ajsutton:
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.
To clarify, there has been no change to the original deployment timeline.
Executive Summary
Hi I’m Adrian, a protocol engineer at OP Labs. OP Labs is a software development …
Executive Summary
Hi I’m Adrian, a protocol 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.
This protocol upgrade reduces the trust assumptions for users of OP Mainnet by enabling permissionless output proposals and a permissionless fault proof system. As part of a responsible and safe rollout of Fault Proofs, it preserves the ability for the guardian to override if necessary to maintain security. As a result, withdrawals no longer depend on the privileged proposer role posting an output root, allowing the entire withdrawal process to be completed without any privileged actions. The trust assumption is reduced to requiring only that the guardian role does not act to intervene. Combined with the Guardian, Security Council Threshold and L 2 ProxyAdmin Ownership changes proposal, we believe this satisfies the criteria to have OP Chains reach Stage 1 status.
If this vote passes and becomes the new governance-approved version of the OP Stack, the upgrade will be deployed to OP Mainnet by the Security Council (currently in Phase 0 , which is a joint 2 / 2 multisig between the Security Council Safe and the Foundation’s Safe) shortly after the end of the veto period.
Motivation
Securing withdrawals with a Fault Proof system is a key requirement for meeting the stage 1 decentralization milestone with the ultimate goal of enhancing the security of user assets.
This upgrade enables a permissionless Fault Proof system which allows anyone to propose output roots and participate in the dispute system. As a result, users will be able to withdraw assets from L 2 to L 1 without relying on the sequencer or any other centralized infrastructure.
As part of a responsible and safe rollout of Fault Proofs, it is required that at this stage, the existing Guardian role capabilities are carried over to this new version, meaning that the Guardian can disable the Fault Proof system in the event of emergency. While this means the system is still not fully trustless - as is the nature of Stage 1 designation - it reduces the trust assumption to requiring only that the Guardian role does not act maliciously, rather than requiring a single permissioned proposer to actively propose. This proposed upgrade extends the Guardian role’s pause ability to be able to disable the fault proof system, an extension of its existing capabilities in the fault proofs context. For more info on how the Guardian role is expected to be permissioned, see this post.
This upgrade also includes a smart contract framework that provides a solid basis for a future multi-proof system, allowing additional proof systems to easily be added. This will further reduce trust assumptions in later upgrades as the OP Stack moves towards achieving Stage 2 decentralization.
Specifications
The full specifications for the fault dispute system are available from the specs repo. If this proposal is approved, the fault dispute system specs will be promoted from the experimental section of specs, to be part of the canonical spec.
Technical Details
This upgrade does not affect the node or execution client software.
Prior to the upgrade, the fault dispute system contracts have been deployed:
DisputeGameFactory (implementation: 0 xc 641 A 33 cab 81 C 559 F 2 bd 4 b 21 EA 34 C 290 E 2440 C 2 B proxy: 0 xe 5965 Ab 5962 eDc 7477 C 8520243 A 95517 CD 252 fA 9 ) - a factory for creating dispute games that can be used by the upgraded OptimismPortal as the source of proposed output roots.
FaultDisputeGame ( 0 x 4146 DF 64 D 83 acB 0 DcB 0 c 1 a 4884 a 16 f 090165 e 122 ) - an implementation of a dispute game that uses permissionless, interactive bi-section of the chain state
This is initialized with an ABSOLUTE_PRESTATE of 0 x 037 ef 3 c 1 a 487960 b 0 e 633 d 3 e 513 df 020 c 43432769 f 41 a 634 d 18 a 9595 cbf 53 c 55 . This is the initial state for the Cannon MIPS VM to run op-program tagged in the optimism repo at commit a 6 d 4 eeda 11477 adfcd 106 e 03131625 a 40334 e 3 a 6 (tagged as release op-program/v 1 . 0 . 0 ). This prestate can be rebuilt using the make reproducible-prestate command (docs)
PermissionedFaultDisputeGame ( 0 xE 9 daD 167 EF 4 DE 8812 C 1 abD 013 Ac 9570 C 616599 A 0 ) - extends FaultDisputeGame to restrict participation to privileged roles. This can be used as a fallback in the event of failure of the fault dispute game.
AnchorStateRegistry (implementation: 0 x 6 B 7 da 1647 Aa 9684 F 54 B 2 BEeB 699 F 91 F 31 cd 35 Fb 9 proxy: 0 x 18 DAc 71 c 228 D 1 C 32 c 99489 B 7323 d 441 E 1175 e 443 ) - stores the latest “anchor” state for each available FaultDisputeGame type. By using stored anchor states, new FaultDisputeGame instances can be initialized with a more recent starting state which reduces the amount of required offchain computation.
This is initialized with the starting anchor for CANNON and PERMISSIONED_CANNON games set to block number 120059863 and output root 0 x 2694 ac 14 dcf 54 b 7 a 77363 e 3 f 60 e 6462 dc 78 da 0 d 43 d 1 e 2 f 058 dbb 6 a 1488814977 .
As the fault dispute system contracts are deployed ahead of time and are permissionless, it is possible for dispute games to be created prior to OptimismPortal being upgraded. If these games resolve that the output root is valid, the AnchorStateRegistry will be updated with the new value. The validity of the current value of the AnchorStateRegistry will be manually verified as part of the upgrade process.
DelayedWETH (implementation: 0 x 97988 d 5624 F 1 ba 266 E 1 da 305117 BCf 20713 bee 08 proxy: 0 xE 497 B 094 d 6 DbB 3 D 5 E 4 CaAc 9 a 14696 D 7572588 d 14 ) - an extension to WETH 9 that allows for delayed withdrawals. This introduces a time delay before bonds posted as part of a FaultDisputeGame can be withdrawn, allowing the Guardian role to change the allocation of bonds if there is a bug in the FaultDisputeGame to preserve incentive compatibility.
PreimageOracle ( 0 xD 326 E 10 B 8186 e 90 F 4 E 2 adc 5 c 13 a 2 d 0 C 137 ee 8 b 34 ) - stores validated pre-images that can be retrieved by hash. This is used by op-program and other fault proof programs to retrieve data required to perform the derivation process and validate the output root.
MIPS ( 0 x 0 f 8 EdFbDdD 3 c 0256 A 80 AD 8 C 0 F 2560 B 1807873 C 9 c) - the Cannon MIPS VM implementation. Executes a single MIPS CPU instruction on-chain as part of the step call to determine the validity of claims at the bottom level of the dispute game.
There are also two off-chain programs provided to support users interacting with the fault proof system:
op-challenger - implements the honest actor algorithm for the FaultDisputeGame to automatically challenge invalid output root proposals and defend valid ones.
op-dispute-mon - monitors the fault proof system, exposing a variety of metrics that enable monitoring and alerting of the fault proof system, such as when games are forecast or have resolved with a status that is inconsistent with the local op-node used by op-dispute-mon.
The following changes are being introduced with the upgrade:
Upgrade the OptimismPortal contract ( 0 xe 2 F 826324 b 2 faf 99 E 513 D 16 D 266 c 3 F 80 aE 87832 B) that uses the DisputeGameFactory as the source of output proposals. (spec)
The proveWithdrawalTransaction method is modified, retaining the same signature function but with the second argument now providing an index within the DisputeGameFactory’s list of created games.
Enforces an air-gap requiring a period of time (DISPUTE_GAME_FINALITY_DELAY_SECONDS) to have elapsed since the game resolved before the game can be used in a call to finalizeWithdrawalTransaction.
The Guardian role can blacklist dispute games or change the RESPECTED_GAME_TYPE to invalidate dispute games in the event of failures in the fault proof system.
Users are now able to reprove their withdrawals at any time. Previously, a user could only reprove their withdrawal if the output root was removed from the L 2 OutputOracle by the guardian, but with this upgrade users will be able to reprove their withdrawal at any time. This allows users to change the dispute game their withdrawal is proven against if needed without waiting for the game to actually resolve as invalid. The 7 day withdrawal finalization delay resets when a user reproves their withdrawal to ensure there is still a full 7 day air-gap between proving and finalizing the withdrawal.
The L 2 OutputOracle contract is no longer used
The SystemConfig contract ( 0 xF 56 D 96 B 2535 B 932656 d 3 c 04 Ebf 51 baBff 241 D 886 ) is updated to:
reference the DisputeGameFactory address instead of the L 2 OutputOracle address.
enforce a maximum block gas limit of 200 , 000 , 000 to prevent the gas limit being raised to the point where block execution is too resource intensive to be processed in cannon as part of the fault dispute system.
remove the setResourceConfig setter to prevent the System Config Owner, from misconfiguring the resource config and preventing force inclusions from L 1 (e.g. by setting the maximum deposit gas too low). The resource config can now only be changed by upgrading the SystemConfig contract which is controlled by the L 1 Proxy Admin (a 2 -of- 2 multisig with the Optimism Foundation and Security Council).
These contracts are tagged in the optimism repo at commit 547 ea 72 d 9849 e 13 ce 169 fd 31 df 0 f 9197651 b 3 f 86 (tagged as release candidate op-contracts/v 1 . 4 . 0 -rc. 4 ).
Security Considerations
Our design philosophy has been to focus on fundamental safety mechanisms first. We acknowledge that gaining certainty in the correctness of the complex logic found within the FaultDisputeGame contract, its dependencies, and the offchain op-challenger software will take time. Therefore, we have included a number of fallback mechanisms designed to maintain the safety of the system even in the event of a complete failure of those complex components - in particular the ability for the Guardian role to pause withdrawals and disable the Fault Proof System.
The Sherlock community completed a successful bug hunt, focused on issues which would allow these fundamental safety mechanisms to be subverted. See the final report for further details. The reported issues have been addressed. As none of the reported issues circumvented the fundamental safety mechanisms we decided not to pursue a fix review.
Impact Summary
As part of the upgrade, all pending withdrawals will be invalidated. Users with pending withdrawals will need to re-prove their withdrawals against an output proposal submitted in the form of a FaultDisputeGame which will restart the withdrawal delay period. This means that withdrawals initiated less than one week before the upgrade is executed will only be finalized one week after the upgrade is complete. For example, a withdrawal initiated 6 days before the upgrade would take a total of 13 days to finalize.
Users reading output roots from the L 2 OutputOracle contract will need to update to read from the DisputeGameFactory.
OP Labs does not anticipate any down time due to this upgrade, and node operators are not affected.
While the normal case for dispute games allows them to resolve within the 7 day withdrawal delay period, the maximum possible time for a dispute game to resolve is 16 days which may lengthen the withdrawal delay for withdrawals proven against that dispute game. Extending a game to this point incurs a significant cost and users may reprove their withdrawal against a different output root at any time. The Game Clock section of the specs provides further details.
Tooling that performs withdrawals will need to be updated to use the new DisputeGameFactory as the source of output roots when proving withdrawals. New versions of the Optimism SDK and viem have already been released with this support.
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. Prior to upgrading, the anchor state in the AnchorStateRegistry will be validated manually. If the value is invalid due to a game having resolved incorrectly prior to full deployment, a replacement version of the AnchorStateRegistry will be deployed using the starting anchor in this proposal, before upgrading contracts. The upgrade will be completed atomically such that all affected L 1 contracts will be upgraded within a single transaction.
This upgrade has already been activated on internal devnets and the op-sepolia testnet.
As this is a L 1 contracts-only upgrade, no action is required by node operators.
To prepare infra and the community for withdrawal flow changes, we will be rolling out mainnet messaging starting this week. This will expand on the preparation for breaking changes implemented with contributors for OP Sepolia, which we coordinated with ~ 30 infra teams and several rounds of public posts. Mainnet communication will include:
Comms: At least two rounds of public messaging on OP social channels notifying users of the changes to withdrawal flow, and of the impact on withdrawals during the upgrade window.
Contributors: Coordinate with bridge infra contributors, including maintainers of popular frontends to the standard bridge, to post banners notifying users of the changes.
Support: Prep developer support team for inbound support tickets about transactions that need to be reproven due to not finishing the first proof in time before the changes.
Bridges: Notify bridges and other infra contributors whose operations might be impacted due to the withdrawal flow changes.
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
The deployment of a permissionless Fault Dispute System to OP Mainnet is a major step forward on the path to decentralization. This proposal is a responsible approach to the roll out, preserving the safety checks and functionality of the Guardian role while still benefiting from permissionless output proposals and laying a foundation for reaching stage 2 decentralization.
Gonna.eth: ajsutton:
This upgrade has already been activated on internal devnets and the op-sepolia testnet.
How long has been active? Is there any performance report?
ajsutton:
The validity of the current value of the AnchorStateRegistry will be manually verified as part of the upgrade process.
How does the manual verification happen?
Leo.Zhang: ajsutton:
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
@ajsutton So when will be the proposal implemented on mainnet? Is there a specific timeline? Thank you!
brichis: ajsutton:
See the final report for further details.
Hey @ajsutton! I think this link is no longer working. Can you please update it?
system: ajsutton:
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.
To clarify, there has been no change to the original deployment timeline.
Executive Summary Hi I’m Adrian, a protocol engineer at OP Labs. OP Labs is a software development …
Executive Summary Hi I’m Adrian, a protocol 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. This protocol upgrade reduces the trust assumptions for users of OP Mainnet by enabling permissionless output proposals and a permissionless fault proof system. As part of a responsible and safe rollout of Fault Proofs, it preserves the ability for the guardian to override if necessary to maintain security. As a result, withdrawals no longer depend on the privileged proposer role posting an output root, allowing the entire withdrawal process to be completed without any privileged actions. The trust assumption is reduced to requiring only that the guardian role does not act to intervene. Combined with the Guardian, Security Council Threshold and L 2 ProxyAdmin Ownership changes proposal, we believe this satisfies the criteria to have OP Chains reach Stage 1 status. If this vote passes and becomes the new governance-approved version of the OP Stack, the upgrade will be deployed to OP Mainnet by the Security Council (currently in Phase 0 , which is a joint 2 / 2 multisig between the Security Council Safe and the Foundation’s Safe) shortly after the end of the veto period. Motivation Securing withdrawals with a Fault Proof system is a key requirement for meeting the stage 1 2 decentralization milestone with the ultimate goal of enhancing the security of user assets. This upgrade enables a permissionless Fault Proof system which allows anyone to propose output roots and participate in the dispute system. As a result, users will be able to withdraw assets from L 2 to L 1 without relying on the sequencer or any other centralized infrastructure. As part of a responsible and safe rollout of Fault Proofs, it is required that at this stage, the existing Guardian role 3 capabilities are carried over to this new version, meaning that the Guardian can disable the Fault Proof system in the event of emergency. While this means the system is still not fully trustless - as is the nature of Stage 1 designation - it reduces the trust assumption to requiring only that the Guardian role does not act maliciously, rather than requiring a single permissioned proposer to actively propose. This proposed upgrade extends the Guardian role’s pause ability to be able to disable the fault proof system, an extension of its existing capabilities in the fault proofs context. For more info on how the Guardian role is expected to be permissioned, see this post. This upgrade also includes a smart contract framework that provides a solid basis for a future multi-proof system, allowing additional proof systems to easily be added. This will further reduce trust assumptions in later upgrades as the OP Stack moves towards achieving Stage 2 decentralization. Specifications The full specifications for the fault dispute system are available from the specs repo 3 . If this proposal is approved, the fault dispute system specs will be promoted from the experimental section of specs, to be part of the canonical spec. Technical Details This upgrade does not affect the node or execution client software. Prior to the upgrade, the fault dispute system contracts have been deployed: DisputeGameFactory (implementation: 0 xc 641 A 33 cab 81 C 559 F 2 bd 4 b 21 EA 34 C 290 E 2440 C 2 B 3 proxy: 0 xe 5965 Ab 5962 eDc 7477 C 8520243 A 95517 CD 252 fA 9 1 ) - a factory for creating dispute games that can be used by the upgraded OptimismPortal as the source of proposed output roots. FaultDisputeGame ( 0 x 4146 DF 64 D 83 acB 0 DcB 0 c 1 a 4884 a 16 f 090165 e 122 1 ) - an implementation of a dispute game that uses permissionless, interactive bi-section of the chain state This is initialized with an ABSOLUTE_PRESTATE of 0 x 037 ef 3 c 1 a 487960 b 0 e 633 d 3 e 513 df 020 c 43432769 f 41 a 634 d 18 a 9595 cbf 53 c 55 . This is the initial state for the Cannon MIPS VM to run op-program tagged in the optimism repo at commit a 6 d 4 eeda 11477 adfcd 106 e 03131625 a 40334 e 3 a 6 (tagged as release op-program/v 1 . 0 . 0 ). This prestate can be rebuilt using the make reproducible-prestate command (docs 1 ) PermissionedFaultDisputeGame ( 0 xE 9 daD 167 EF 4 DE 8812 C 1 abD 013 Ac 9570 C 616599 A 0 ) - extends FaultDisputeGame to restrict participation to privileged roles. This can be used as a fallback in the event of failure of the fault dispute game. AnchorStateRegistry (implementation: 0 x 6 B 7 da 1647 Aa 9684 F 54 B 2 BEeB 699 F 91 F 31 cd 35 Fb 9 proxy: 0 x 18 DAc 71 c 228 D 1 C 32 c 99489 B 7323 d 441 E 1175 e 443 1 ) - stores the latest “anchor” state for each available FaultDisputeGame type. By using stored anchor states, new FaultDisputeGame instances can be initialized with a more recent starting state which reduces the amount of required offchain computation. This is initialized with the starting anchor for CANNON and PERMISSIONED_CANNON games set to block number 120059863 and output root 0 x 2694 ac 14 dcf 54 b 7 a 77363 e 3 f 60 e 6462 dc 78 da 0 d 43 d 1 e 2 f 058 dbb 6 a 1488814977 . As the fault dispute system contracts are deployed ahead of time and are permissionless, it is possible for dispute games to be created prior to OptimismPortal being upgraded. If these games resolve that the output root is valid, the AnchorStateRegistry will be updated with the new value. The validity of the current value of the AnchorStateRegistry will be manually verified as part of the upgrade process. DelayedWETH (implementation: 0 x 97988 d 5624 F 1 ba 266 E 1 da 305117 BCf 20713 bee 08 proxy: 0 xE 497 B 094 d 6 DbB 3 D 5 E 4 CaAc 9 a 14696 D 7572588 d 14 ) - an extension to WETH 9 that allows for delayed withdrawals. This introduces a time delay before bonds posted as part of a FaultDisputeGame can be withdrawn, allowing the Guardian role to change the allocation of bonds if there is a bug in the FaultDisputeGame to preserve incentive compatibility. PreimageOracle ( 0 xD 326 E 10 B 8186 e 90 F 4 E 2 adc 5 c 13 a 2 d 0 C 137 ee 8 b 34 2 ) - stores validated pre-images that can be retrieved by hash. This is used by op-program and other fault proof programs to retrieve data required to perform the derivation process and validate the output root. MIPS ( 0 x 0 f 8 EdFbDdD 3 c 0256 A 80 AD 8 C 0 F 2560 B 1807873 C 9 c) - the Cannon MIPS VM implementation. Executes a single MIPS CPU instruction on-chain as part of the step call to determine the validity of claims at the bottom level of the dispute game. There are also two off-chain programs provided to support users interacting with the fault proof system: op-challenger - implements the honest actor algorithm for the FaultDisputeGame to automatically challenge invalid output root proposals and defend valid ones. op-dispute-mon - monitors the fault proof system, exposing a variety of metrics that enable monitoring and alerting of the fault proof system, such as when games are forecast or have resolved with a status that is inconsistent with the local op-node used by op-dispute-mon. The following changes are being introduced with the upgrade: Upgrade the OptimismPortal contract ( 0 xe 2 F 826324 b 2 faf 99 E 513 D 16 D 266 c 3 F 80 aE 87832 B 2 ) that uses the DisputeGameFactory as the source of output proposals. (spec) The proveWithdrawalTransaction method is modified, retaining the same signature function but with the second argument now providing an index within the DisputeGameFactory’s list of created games. Enforces an air-gap requiring a period of time (DISPUTE_GAME_FINALITY_DELAY_SECONDS) to have elapsed since the game resolved before the game can be used in a call to finalizeWithdrawalTransaction. The Guardian role can blacklist dispute games or change the RESPECTED_GAME_TYPE to invalidate dispute games in the event of failures in the fault proof system. Users are now able to reprove their withdrawals at any time. Previously, a user could only reprove their withdrawal if the output root was removed from the L 2 OutputOracle by the guardian, but with this upgrade users will be able to reprove their withdrawal at any time. This allows users to change the dispute game their withdrawal is proven against if needed without waiting for the game to actually resolve as invalid. The 7 day withdrawal finalization delay resets when a user reproves their withdrawal to ensure there is still a full 7 day air-gap between proving and finalizing the withdrawal. The L 2 OutputOracle contract is no longer used The SystemConfig contract ( 0 xF 56 D 96 B 2535 B 932656 d 3 c 04 Ebf 51 baBff 241 D 886 1 ) is updated to reference the DisputeGameFactory address instead of the L 2 OutputOracle address. These contracts are tagged in the optimism repo at commit 547 ea 72 d 9849 e 13 ce 169 fd 31 df 0 f 9197651 b 3 f 86 3 (tagged as release candidate op-contracts/v 1 . 4 . 0 -rc. 4 ). Security Considerations Our design philosophy has been to focus on fundamental safety mechanisms first. We acknowledge that gaining certainty in the correctness of the complex logic found within the FaultDisputeGame contract, its dependencies, and the offchain op-challenger software will take time. Therefore, we have included a number of fallback mechanisms designed to maintain the safety of the system even in the event of a complete failure of those complex components - in particular the ability for the Guardian role to pause withdrawals and disable the Fault Proof System. The Sherlock community completed a successful bug hunt 2 , focused on issues which would allow these fundamental safety mechanisms to be subverted. See the final report 6 for further details. The reported issues have been addressed. As none of the reported issues circumvented the fundamental safety mechanisms we decided not to pursue a fix review. Impact Summary As part of the upgrade, all pending withdrawals will be invalidated. Users with pending withdrawals will need to re-prove their withdrawals against an output proposal submitted in the form of a FaultDisputeGame which will restart the withdrawal delay period. This means that withdrawals initiated less than one week before the upgrade is executed will only be finalized one week after the upgrade is complete. For example, a withdrawal initiated 6 days before the upgrade would take a total of 13 days to finalize. Users reading output roots from the L 2 OutputOracle contract will need to update to read from the DisputeGameFactory. OP Labs does not anticipate any down time due to this upgrade, and node operators are not affected. While the normal case for dispute games allows them to resolve within the 7 day withdrawal delay period, the maximum possible time for a dispute game to resolve is 16 days which may lengthen the withdrawal delay for withdrawals proven against that dispute game. Extending a game to this point incurs a significant cost and users may reprove their withdrawal against a different output root at any time. The Game Clock section of the specs 1 provides further details. Tooling that performs withdrawals will need to be updated to use the new DisputeGameFactory as the source of output roots when proving withdrawals. New versions of the Optimism SDK and viem have already been released with this support. 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. Prior to upgrading, the anchor state in the AnchorStateRegistry will be validated manually. If the value is invalid due to a game having resolved incorrectly prior to full deployment, a replacement version of the AnchorStateRegistry will be deployed using the starting anchor in this proposal, before upgrading contracts. The upgrade will be completed atomically such that all affected L 1 contracts will be upgraded within a single transaction. This upgrade has already been activated on internal devnets and the op-sepolia testnet. As this is a L 1 contracts-only upgrade, no action is required by node operators. To prepare infra and the community for withdrawal flow changes, we will be rolling out mainnet messaging starting this week. This will expand on the preparation for breaking changes implemented with contributors for OP Sepolia, which we coordinated with ~ 30 infra teams and several rounds of public posts. Mainnet communication will include: Comms: At least two rounds of public messaging on OP social channels notifying users of the changes to withdrawal flow, and of the impact on withdrawals during the upgrade window. Contributors: Coordinate with bridge infra contributors, including maintainers of popular frontends to the standard bridge, to post banners notifying users of the changes. Support: Prep developer support team for inbound support tickets about transactions that need to be reproven due to not finishing the first proof in time before the changes. Bridges: Notify bridges and other infra contributors whose operations might be impacted due to the withdrawal flow changes. 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 The deployment of a permissionless Fault Dispute System to OP Mainnet is a major step forward on the path to decentralization. This proposal is a responsible approach to the roll out, preserving the safety checks and functionality of the Guardian role while still benefiting from permissionless output proposals and laying a foundation for reaching stage 2 decentralization.
On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal…
On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal:
For Optimism withdrawals to function, the L 2 state root must be posted to L 1 .
You can think of the L 2 state root as a single “summary” value that can be used to prove any fact about L 2 ’s state. This value is used when withdrawing funds to prove those funds were actually withdrawn on L 2 .
(Optimism actually uses a few different values to make proving simpler, but we can skip that for this discussion.)
Before this upgrade, this L 2 root value was posted to the L 2 OutputOracle contract. It could only be posted by a trusted, permissioned account. As long as this permissioned account acted honestly, the chain would function as intended.
This upgrade aims to move towards technical decentralization by allowing anyone to post the L 2 root.
How does this work?
L 2 roots are proven through “games”. In the current game, anyone can propose a root (and put up a financial bond along with it). Any other user can challenge them (also putting up a bond), and the two users then go back and forth proving facts about how the root was calculated and increasing their bonds until either (a) one of them gives up or (b) they disagree about a fact so basic that it can be proven on chain.
If the user who proposed the root wins this game, the root is considered valid. Otherwise, it is considered invalid. The loser also forfeits their bonds to the winner.
Only a valid game that has had enough time to work itself out can have withdrawals proven against it, which stops dishonest users from being able to post an incorrect root.
Safeguards
The game itself may still have security issues. As the proposal says: “We acknowledge that gaining certainty in the correctness of the complex logic found within the FaultDisputeGame contract, its dependencies, and the offchain op-challenger software will take time.”
For this period where the security of the game may still be at risk, Optimism has poured significant resources into building safeguards around the game, as follows:
An off chain monitoring system has been set up to monitor all proposed roots and ensure they align with the correct state.
After a root is finalized through a game, an additional delay has been added before withdrawals can occur. During this period, the GUARDIAN role can reject the root. This will allow the monitoring to stop invalid withdrawals.
A contract called DelayedWETH has been set up to hold the bonds and only allow payouts after a delay, so that bonds can be redirected towards the rightful recipient in the event that a game is abused.
Other Implications
As a part of the OptimismPortal (the contract that handles withdrawals) being upgraded, all previously proved withdrawals will no longer work. This means that any previously proven withdrawal that has not yet been finalized will need to be reproved, including an additional wait before being able to finalize.
If you have any questions about the technical details of this upgrade, feel free to post here and I (or someone else in the DAB) will get back to you.
Harper: Thanks @zachobront and DAB for the summary. Very helpful!
mastermojo: I am one of the Synthetix Ambassadors, and I am an Optimism delegate [Delegate Commitments - #65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote.
Jrocki: As a delegate who is not a developer these plain English non-technical explanations actually allow me to be an informed voter on protocol upgrades. Otherwise my options would be limited to abstaining or trying to find another delegates assessment that I trust.
As part of the Path to Open Metagovernance, we’re experimenting with polls to collect more communit…
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
Average rating: 4 . 3 .
20
voters
This summary influenced my confidence in voting on the proposal
Average rating: 4 . 12 .
17
voters
I still do not understand this proposal
0
voters
Votes are public.
As part of the Path to Open Metagovernance 3 , we’re experimenting with polls to collect more comm…
As part of the Path to Open Metagovernance 3 , 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
Average rating: 4 . 3 .
20
voters
This summary influenced my confidence in voting on the proposal
Average rating: 4 . 12 .
17
voters
I still do not understand this proposal
0
voters
Votes are public.
On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal…
On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal: For Optimism withdrawals to function, the L 2 state root must be posted to L 1 . You can think of the L 2 state root as a single “summary” value that can be used to prove any fact about L 2 ’s state. This value is used when withdrawing funds to prove those funds were actually withdrawn on L 2 . (Optimism actually uses a few different values to make proving simpler, but we can skip that for this discussion.) Before this upgrade, this L 2 root value was posted to the L 2 OutputOracle contract. It could only be posted by a trusted, permissioned account. As long as this permissioned account acted honestly, the chain would function as intended. This upgrade aims to move towards technical decentralization by allowing anyone to post the L 2 root. How does this work? L 2 roots are proven through “games”. In the current game, anyone can propose a root (and put up a financial bond along with it). Any other user can challenge them (also putting up a bond), and the two users then go back and forth proving facts about how the root was calculated and increasing their bonds until either (a) one of them gives up or (b) they disagree about a fact so basic that it can be proven on chain. If the user who proposed the root wins this game, the root is considered valid. Otherwise, it is considered invalid. The loser also forfeits their bonds to the winner. Only a valid game that has had enough time to work itself out can have withdrawals proven against it, which stops dishonest users from being able to post an incorrect root. Safeguards The game itself may still have security issues. As the proposal says: “We acknowledge that gaining certainty in the correctness of the complex logic found within the FaultDisputeGame contract, its dependencies, and the offchain op-challenger software will take time.” For this period where the security of the game may still be at risk, Optimism has poured significant resources into building safeguards around the game, as follows: An off chain monitoring system has been set up to monitor all proposed roots and ensure they align with the correct state. After a root is finalized through a game, an additional delay has been added before withdrawals can occur. During this period, the GUARDIAN role can reject the root. This will allow the monitoring to stop invalid withdrawals. A contract called DelayedWETH has been set up to hold the bonds and only allow payouts after a delay, so that bonds can be redirected towards the rightful recipient in the event that a game is abused. Other Implications As a part of the OptimismPortal (the contract that handles withdrawals) being upgraded, all previously proved withdrawals will no longer work. This means that any previously proven withdrawal that has not yet been finalized will need to be reproved, including an additional wait before being able to finalize. If you have any questions about the technical details of this upgrade, feel free to post here and I (or someone else in the DAB) will get back to you.
As part of the Path to Open Metagovernance, we’re experimenting with polls to collect more communit…
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 55 voters Closes in 9 days. Votes are public. Results This summary influenced my confidence in voting on the proposal 1 2 3 4 55 voters Closes in 9 days. Votes are public. Results I still do not understand this proposal 0 voters Votes are public.
Please note that I’ve edited the original post to add information on two additional changes to the …
Please note that I’ve edited the original post to add information on two additional changes to the SystemConfig contract about enforcing a maximum block gas limit and removing the setResourceConfig. These were unintentionally missed in my original summary of the changes but seemed worth noting for transparency.
Thank you for the non-technical summary.
I am an Optimism delegate with sufficient voting power and…
Thank you for the non-technical summary.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
Thank you for the non-technical summary.
I am an Optimism delegate 3 with sufficient voting power…
Thank you for the non-technical summary.
I am an Optimism delegate 3 with sufficient voting power and I believe this proposal is ready to move to a vote.
I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move…
I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
I’m an Optimism delegate 3 with sufficient voting power and I believe this proposal is ready to …
I’m an Optimism delegate 3 with sufficient voting power and I believe this proposal is ready to move to a vote.
Thanks for the detailed post on fault proofs. Was waiting and looking forward for this hitting on O…
Thanks for the detailed post on fault proofs. Was waiting and looking forward for this hitting on Optimism as an upgrade so this is an easy thing to approve.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
Thanks for the detailed post on fault proofs. Was waiting and looking forward for this hitting on O…
Thanks for the detailed post on fault proofs. Was waiting and looking forward for this hitting on Optimism as an upgrade so this is an easy thing to approve.
I am an Optimism delegate 3 with sufficient voting power and I believe this proposal is ready to move to a vote.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move…
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
ajsutton:
This upgrade has already been activated on internal devnets and the op-sepolia testn…
ajsutton:
This upgrade has already been activated on internal devnets and the op-sepolia testnet.
How long has been active? Is there any performance report?
ajsutton:
The validity of the current value of the AnchorStateRegistry will be manually verified as part of the upgrade process.
How does the manual verification happen?
ajsutton: Gonna.eth:
How long has been active? Is there any performance report?
We’ve had the fault dispute game running on op-sepolia since March 19 and all dispute games have resolved correctly. op-sepolia was updated to use fault proofs prior to the Sherlock audit contest so we have updated it to deploy the fixes as a result of that contest.
You can see the interactions with the system starting from the DisputeGameFactory contract on Etherscan. For a simpler view, you can use the subcommands on op-challenger to list games and list claims.
Gonna.eth:
How does the manual verification happen?
See this answer from @maurelian: https://gov.optimism.io/t/upgrade-proposal-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/19
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move…
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
changed old delegate commitment to new agora page to show OP delegate info
I am an Optimism delegate 4 with sufficient voting power and I believe this proposal is ready to …
I am an Optimism delegate 4 with sufficient voting power and I believe this proposal is ready to move to a vote.
changed old delegate commitment to new agora page to show OP delegate info
GM! First, thanks to the DAB for the non-technical summary. After getting all my questions about th…
GM! First, thanks to the DAB for the non-technical summary. After getting all my questions about this upgrade answered, I approve this proposal:
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
GM! First, thanks to the DAB for the non-technical summary. After getting all my questions about th…
GM! First, thanks to the DAB for the non-technical summary. After getting all my questions about this upgrade answered, I approve this proposal:
I am an Optimism delegate 3 with sufficient voting power and I believe this proposal is ready to move to a vote.
The community call answered the questions I had.
I am an Optimism delegate with sufficient voting p…
The community call answered the questions I had.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move…
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
I am an Optimism delegate 2 with sufficient voting power and I believe this proposal is ready to …
I am an Optimism delegate 2 with sufficient voting power and I believe this proposal is ready to move to a vote.
On behalf of Blockchain@USC:
We are an Optimism delegate with sufficient voting power and we believ…
On behalf of Blockchain@USC:
We are an Optimism delegate with sufficient voting power and we believe this proposal is ready to move to a vote.
On behalf of Blockchain@USC:
We are an Optimism delegate 2 with sufficient voting power and we be…
On behalf of Blockchain@USC:
We are an Optimism delegate 2 with sufficient voting power and we believe this proposal is ready to move to a vote.
Hey @ajsutton! At SEED Latam, we are thrilled to see this proposal make its way to the forum. Movin…
Hey @ajsutton! At SEED Latam, we are thrilled to see this proposal make its way to the forum. Moving OP Mainnet into Stage 1 is a significant step forward, and we are excited that we are likely ready for it.
Some aspects were addressed in the last Governance Call, but we believe there are still several points that need to be clarified for the community’s understanding of this new upgrade:
How large are the bonds expected to be needed to sustain and win a dispute? A summary of the factors involved would be nice.
How many steps/transactions are required to settle a dispute (worst-case scenario)?
With Fault Proofs, are escape hatches practically possible? In the event of sequencer and proposer failure, we would expect to initiate an forced withdrawal from L 1 and then propose a new state root. Are there any dependencies to consider?
Since the roles of proposer and challenger will be open to everyone, is there a guide available outlining the best practices for running them?
On a side note, we appreciate the publication of non-technical summaries (cc: @zachobront) below each technical proposal. We hope to help providing context to all interested parties by making these questions outlined above. Thank you.
ajsutton: Joxes:
How large are the bonds expected to be needed to sustain and win a dispute? A summary of the factors involved would be nice.
The bonds are sized based on the anticipated cost to post a counter claim as well as to deter spamming invalid claims. There’s more details in the specs. As an example on op-sepolia the game 0xcf8f181497DAD07277781517A76cb131C54A1BEE shows the escalating bond sizes. The list-claims subcommand of op-challenger can provide a good view of the claims in the game: ./op-challenger/bin/op-challenger list-claims --l1-eth-rpc <SEPOLIA_L1> --game-address 0xcf8f181497DAD07277781517A76cb131C54A1BEE
Joxes:
How many steps/transactions are required to settle a dispute (worst-case scenario)?
The maximum depth of a game is 73, but there can be any number of claims and counter-claims within a dispute game. Due to the permissionless structure where many different actors can participate in the same game, a single claim may be countered by any number of different counter-claims, effectively combining multiple disputes into a single game.
Joxes:
With Fault Proofs, are escape hatches practically possible? In the event of sequencer and proposer failure, we would expect to initiate an forced withdrawal from L1 and then propose a new state root. Are there any dependencies to consider?
Users are able to complete the full withdrawal cycle without depending on any privileged action. The caveat is that the Guardian role has the ability to override the system by either blacklisting games or reverting to a permissioned system. So the trust assumption is reduced to requiring only that the guardian role does not act to intervene but there is still a trust assumption, inline with the stage 1 requirements.
Joxes:
Since the roles of proposer and challenger will be open to everyone, is there a guide available outlining the best practices for running them?
It’s not expected that normal users run op-proposer to regularly propose output roots, they’d generally just propose a single output root if they need to withdraw and the chain operator isn’t proposing outputs for them. They can do that through direct calls to the DisputeGameFactory even via Etherscan or could use the create-game subcommand of op-challenger.
For running op-challenger, there aren’t detailed docs currently. Definitely an area to build up between the official docs and community content.
ajsutton:
If this proposal passes a Token House vote, the L 1 contracts will be upgraded foll…
ajsutton:
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
@ajsutton So when will be the proposal implemented on mainnet? Is there a specific timeline? Thank you!
ajsutton: Leo.Zhang:
@ajsutton So when will be the proposal implemented on mainnet? Is there a specific timeline? Thank you!
There isn’t a specific timeline. The upgrade will require coordination with the security council to obtain the appropriate signatures. As mentioned in the proposal, the recommendation is to perform the upgrade shortly after the end of the veto period and I’m definitely excited to see it go live as soon as possible.
Huge step, and I appreciate the focus on the safety failsafes that come with the upgrade.
I am an O…
Huge step, and I appreciate the focus on the safety failsafes that come with the upgrade.
I am an Optimism delegate 2 with sufficient voting power and believe this proposal is ready to move towards a vote.
Huge step, and I appreciate the focus on the safety failsafes that come with the upgrade.
I am an O…
Huge step, and I appreciate the focus on the safety failsafes that come with the upgrade.
I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move towards a vote.
I am one of the Synthetix Ambassadors, and I am an Optimism delegate [Delegate Commitments - # 65 …
I am one of the Synthetix Ambassadors, and I am an Optimism delegate [Delegate Commitments - # 65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote.
Gonna.eth:
How long has been active? Is there any performance report?
We’ve had the fault di…
Gonna.eth:
How long has been active? Is there any performance report?
We’ve had the fault dispute game running on op-sepolia since March 19 and all dispute games have resolved correctly. op-sepolia was updated to use fault proofs prior to the Sherlock audit contest so we have updated it to deploy the fixes as a result of that contest.
You can see the interactions with the system starting from the DisputeGameFactory contract on Etherscan. For a simpler view, you can use the subcommands on op-challenger to list games and list claims.
Gonna.eth:
How does the manual verification happen?
See this answer from @maurelian: https://gov.optimism.io/t/upgrade-proposal-guardian-security-council-threshold-and-l 2 -proxyadmin-ownership-changes-for-stage- 1 -decentralization/ 8157 / 19
Gonna.eth:
How long has been active? Is there any performance report?
We’ve had the fault di…
Gonna.eth:
How long has been active? Is there any performance report?
We’ve had the fault dispute game running on op-sepolia since March 19 and all dispute games have resolved correctly. op-sepolia was updated to use fault proofs prior to the Sherlock audit contest so we have updated it to deploy the fixes 1 as a result of that contest.
You can see the interactions with the system starting from the DisputeGameFactory 3 contract on Etherscan. For a simpler view, you can use the subcommands 2 on op-challenger to list games and list claims.
Gonna.eth:
How does the manual verification happen?
See this answer from @maurelian: https://gov.optimism.io/t/upgrade-proposal-guardian-security-council-threshold-and-l 2 -proxyadmin-ownership-changes-for-stage- 1 -decentralization/ 8157 / 19
Joxes:
How large are the bonds expected to be needed to sustain and win a dispute? A summary …
Joxes:
How large are the bonds expected to be needed to sustain and win a dispute? A summary of the factors involved would be nice.
The bonds are sized based on the anticipated cost to post a counter claim as well as to deter spamming invalid claims. There’s more details in the specs 3 . As an example on op-sepolia the game 0 xcf 8 f 181497 DAD 07277781517 A 76 cb 131 C 54 A 1 BEE 5 shows the escalating bond sizes. The list-claims subcommand of op-challenger can provide a good view of the claims in the game: ./op-challenger/bin/op-challenger list-claims --l 1 -eth-rpc --game-address 0 xcf 8 f 181497 DAD 07277781517 A 76 cb 131 C 54 A 1 BEE
Joxes:
How many steps/transactions are required to settle a dispute (worst-case scenario)?
The maximum depth of a game is 73 , but there can be any number of claims and counter-claims within a dispute game. Due to the permissionless structure where many different actors can participate in the same game, a single claim may be countered by any number of different counter-claims, effectively combining multiple disputes into a single game.
Joxes:
With Fault Proofs, are escape hatches practically possible? In the event of sequencer and proposer failure, we would expect to initiate an forced withdrawal from L 1 and then propose a new state root. Are there any dependencies to consider?
Users are able to complete the full withdrawal cycle without depending on any privileged action. The caveat is that the Guardian role has the ability to override the system by either blacklisting games or reverting to a permissioned system. So the trust assumption is reduced to requiring only that the guardian role does not act to intervene but there is still a trust assumption, inline with the stage 1 requirements.
Joxes:
Since the roles of proposer and challenger will be open to everyone, is there a guide available outlining the best practices for running them?
It’s not expected that normal users run op-proposer to regularly propose output roots, they’d generally just propose a single output root if they need to withdraw and the chain operator isn’t proposing outputs for them. They can do that through direct calls to the DisputeGameFactory even via Etherscan or could use the create-game 1 subcommand of op-challenger. 1
For running op-challenger, there aren’t detailed docs currently. Definitely an area to build up between the official docs and community content.
qizhou: ajsutton:
It’s not expected that normal users run op-proposer to regularly propose output roots, they’d generally just propose a single output root if they need to withdraw and the chain operator isn’t proposing outputs for them. They can do that through direct calls to the DisputeGameFactory even via Etherscan or could use the create-game subcommand of op-challenger.
One question is that when proposing an output root, could we only store the minimum necessary data on-chain and delay creating the game contract until it is challenged?
The rational is that the current create() method of DisputeGameFactory takes about 429k gas, which is more than 4x higher than 93k of L2OutputOracle.proposeL2Output().
Leo.Zhang:
@ajsutton So when will be the proposal implemented on mainnet? Is there a specific …
Leo.Zhang:
@ajsutton So when will be the proposal implemented on mainnet? Is there a specific timeline? Thank you!
There isn’t a specific timeline. The upgrade will require coordination with the security council to obtain the appropriate signatures. As mentioned in the proposal, the recommendation is to perform the upgrade shortly after the end of the veto period and I’m definitely excited to see it go live as soon as possible.
Leo.Zhang: Thanks for you reply. I’m also very excited to see it implemented. When is the end of the veto period?
Tane: Thanks for raising great points. We have a question about the timing of the deployment.
ajsutton:
There isn’t a specific timeline. The upgrade will require coordination with the security council to obtain the appropriate signatures. As mentioned in the proposal, the recommendation is to perform the upgrade shortly after the end of the veto period and I’m definitely excited to see it go live as soon as possible.
According to Adrian’s clarification, the deployment will be coordinated with the security council and if the fact that the Fault Dispute Game isn’t fully audited is deemed a blocker, we can delay the deployment in July? We believe we can vote for the proposal and time the deployment appropriately, relying on the judgement and coordination by the council and OP Labs.
Thanks for you reply. I’m also very excited to see it implemented. When is the end of the veto peri…
Thanks for you reply. I’m also very excited to see it implemented. When is the end of the veto period?
Leo.Zhang:
When is the end of the veto period?
The veto period ends on June 5 th I believe.
Leo.Zhang:
When is the end of the veto period?
The veto period ends on June 5 th I believe.
The SEED Latam delegation, as we have communicated here 1 , with @Joxes being an Optimism delegate…
The SEED Latam delegation, as we have communicated here 1 , with @Joxes being an Optimism delegate with sufficient voting power we believe this proposal is ready to move towards a vote.
Hi all,
I shared an objective overview of the facts of this upgrade above on behalf of the Develope…
Hi all,
I shared an objective overview of the facts of this upgrade above on behalf of the Developer Advisory Board, but wanted to follow up with a personal message explaining why I plan to vote no on this proposal.
Here are a few facts for context:
If this proposal passes, deployment will occur on June 10 th.
The Fault Dispute Game itself has not been audited.
There is an audit contest 18 for the Fault Dispute Game that is scheduled for July.
The safeguards themselves have received a thorough audit and no High Severity issues were found.
This audit was focused only on the on chain components and assumed that off chain monitoring and execution worked perfectly.
In the event that there is a bug in the Fault Dispute Game and the safeguards need to be used, the Optimism Bridge will go down temporarily and all pending withdrawals will need to be reproven.
These facts lead to me the conclusion that there is quite a serious downside risk of things going wrong after this upgrade, with very limited upside.
In terms of risks, I would suggest two major categories:
1 ) Reputation
I think it is highly likely ( 80 %+) that there are critical bugs still in the Fault Dispute Game. This is no fault of the OP Labs dev team. It’s incredible complex code and hasn’t been audited. It would honestly be astonishing if there were no serious bugs.
In the event that a single critical bug is found and requires shutting down the bridge, it would cause major reputational damage for Optimism. Even though there are safeguards, mainnet bridge code having a critical bug would be very bad for public perception.
If this happens more than once (which doesn’t seem out of the question), the reputational damage would be quite a bit worse.
2 ) Security Risk
I participated in the contest focused on the safeguards, and feel very confident in the on chain components functioning safely.
However, the whole system relies on two facts:
Off chain monitoring will catch any fraudulent games
The guardian role will be able to move quickly enough to override a fraudulent game before the withdrawal is executed
In general, I feel uncomfortable about the idea that proactive action is needed to secure a multibillion dollar protocol. Although it is unlikely, it feels like there is just too much that could go wrong with this much at stake.
For example, after Protocol Upgrade # 8 5 , the guardian role is performed by the 10 / 13 security multisig. For a normal protocol, this might be sufficient, but with billions of dollars on the line, it doesn’t seem out of the question that an attacker could take 4 signers temporarily offline for a few days until their withdrawal is processed.
(Note that I believe the Foundation has an override here, so this example may not be exactly right, but my point is that anything that requires proactive action does not feel like adequate security to me.)
I want to make clear that I have the utmost respect for the OP Labs team and think the Fault Dispute Game is incredible well built. I am excited for it to be deployed.
But I think it is rushed to try to perform this deployment before the Fault Dispute Game audit is complete. No code this complex is perfect, and the downside of there being issues feels too large to justify taking the risk.
For these reasons, I plan to vote no on this proposal, and look forward to voting yes later in the summer when the risks have been addressed.
Tane: Thanks for raising great points. We have a question about the timing of the deployment.
ajsutton:
There isn’t a specific timeline. The upgrade will require coordination with the security council to obtain the appropriate signatures. As mentioned in the proposal, the recommendation is to perform the upgrade shortly after the end of the veto period and I’m definitely excited to see it go live as soon as possible.
According to Adrian’s clarification, the deployment will be coordinated with the security council and if the fact that the Fault Dispute Game isn’t fully audited is deemed a blocker, we can delay the deployment in July? We believe we can vote for the proposal and time the deployment appropriately, relying on the judgement and coordination by the council and OP Labs.
Joxes: Hey @zachobront, thanks for sharing your perspective on this proposal. We appreciate it, especially given your position.
Many, if not all, of the risks you described are very valid points.
As far as I know, the proposal follows the previously published audit framework, falling into the safety and reputational category. A bug does not immediately compromise the system since it implements various defensive mechanisms, including the Guardian setup itself. Therefore, some bugs are expected, and the security setup needs to be prepared for them.
zachobront:
look forward to voting yes later in the summer when the risks have been addressed.
Right now, I would appreciate having a complete understanding of your perspective. If this upgrade does not move forward, what would be viable actions to resubmit it? Should we wait for the audit contest to be completed or pay for a new audit?
I am happy to see a careful evaluation here, reconciling the security efforts made by core developers with what is believed to be concretely left to do. It is impossible to determine when code is completely bug-free, even with several audits completed. However, we should ensure that our reputation is not easily put at risk (e.g., if several bugs are found shortly after implementation).
For us, if there is a clear risk that we can feasibly avoid, we should make every effort to mitigate it.
I love seeing these conversations happen and am happy that other delegates share their perspectives based on what is described above. CC: L2Beat team @kaereste and @GFXlabs, as well others.
inphi: Hi I’m Mofi, a protocol engineer at OP Labs. I do not represent or speak on behalf of the Optimism Foundation.
I shared an objective overview of the facts of this upgrade above on behalf of the Developer Advisory Board, but wanted to follow up with a personal message explaining why I plan to vote no on this proposal.
First and foremost, we sincerely appreciate you taking the time to evaluate the system and share your concerns. It is incredibly valuable to have experts like you participate in the governance system and thoroughly review proposals. We understand your concerns here and want to address them directly so that governance participants can make an informed decision.
I think it is highly likely (80%+) that there are critical bugs still in the Fault Dispute Game. This is no fault of the OP Labs dev team. It’s incredible complex code and hasn’t been audited. It would honestly be astonishing if there were no serious bugs.
The Fault Dispute Game is certainly a complex system. It’s important to consider that audits aren’t the only way to ensure code quality, nor are they a silver bullet. The OP Labs Audit Framework is based on the idea that security starts with developers and an audit is a final assurance, not the basis for considering a system secure.
In this case, OP Labs ran a Sherlock contest focused on the safety nets and overrides — the components of the fault proof for which safety is of existential importance. The Fault Dispute Game is considered a reputational risk but not an existential risk. The Audit Framework explicitly notes “fault proofs with training wheels” as the sole example in the “reputational/safety” quadrant (image reproduced below) of the audit rubric.
Most of the code outside of the Fault Dispute Game contracts falls into the liveness/reputational risk quadrant. The majority of code in the fault dispute system is in op-program (a combination of the consensus critical parts of op-node and op-geth) and op-challenger which are the types of code that experience has shown audits are less effective for vs what is learned by getting code running in the real world. That’s why we’ve been rolling this out incrementally for some time now, including a lot of internal deployments, the public Fault Proof Alpha release and upgrading op-sepolia.
It’s also worth noting that the Immunefi bounty program is being updated to include these contracts so that auditors and bug hunters will have an opportunity to disclose issues in the Fault Dispute Game contracts before any mainnet launch.
In the event that a single critical bug is found and requires shutting down the bridge, it would cause major reputational damage for Optimism. Even though there are safeguards, mainnet bridge code having a critical bug would be very bad for public perception.
Pausing withdrawals is the final safety measure, but not the only one. The Guardian also has the ability to blacklist specific games, allowing withdrawals proven against valid output roots to continue unaffected. The respected game type can also be changed to a permissioned game which does invalidate already proven withdrawals but allows them to be re-proven and therefore does not shut down the bridge. The exact way in which the system should respond depends on the severity and impact of the bug.
We do believe it’s important that governance participants understand that reputational risk does exist here no matter what — it’s never a good thing to need to fix bugs in production. Our position is that the purpose of Stage 1 is to make it possible to deploy fault proofs into production without requiring perfection. OP Stack developers will learn a lot from seeing this system on mainnet. Even Stage 2 explicitly assumes that there will be bugs in the fault proof system and uses multiple independent proof systems to mitigate this risk.
In general, I feel uncomfortable about the idea that proactive action is needed to secure a multibillion dollar protocol. Although it is unlikely, it feels like there is just too much that could go wrong with this much at stake.
For example, after Protocol Upgrade #8 2, the guardian role is performed by the 10/13 security multisig. For a normal protocol, this might be sufficient, but with billions of dollars on the line, it doesn’t seem out of the question that an attacker could take 4 signers temporarily offline for a few days until their withdrawal is processed.
Proactive action for security is ultimately part and parcel of an optimistic rollup. Rather than using a positive proof of validity, users permissionlessly publish and challenge output root proposals. Challengers must be able to detect invalid proposals in the same way that the Guardian must be able to detect these proposals. In a meaningful way, it is not possible to separate an optimistic rollup from proactive action.
Even today, under the permissioned proposer model, it assumed that the proposer may be fault and a delay is added so that the Guardian role can intervene to remove a proposal if needed. While the contracts that support this process are simpler than the fault dispute game contracts, calculating the correct output root requires correct operation of op-node, op-geth, and op-proposer, none of which are audited before each release. Great care is taken in the development of these components, but the Guardian role is the backstop to ensure security even if they fail — just as in the proposed Stage 1 fault proof system.
I want to make clear that I have the utmost respect for the OP Labs team and think the Fault Dispute Game is incredible well built. I am excited for it to be deployed.
Thank you for your kind words, and again thank you for the work you have done to look into the proposed system and share your concerns.
Following the explanation by the posters in the topic I am voting for this proposal.
Following the explanation by the posters in the topic I am voting for this proposal.
ajsutton:
See the final report for further details.
Screenshot 2024 - 05 - 26 at 3 . 21 …
ajsutton:
See the final report for further details.
Screenshot 2024 - 05 - 26 at 3 . 21 . 07 p.m. 755 × 182 2 . 64 KB
Hey @ajsutton! I think this link is no longer working. Can you please update it?
ajsutton: brichis:
Hey @ajsutton! I think this link is no longer working. Can you please update it?
The link should be working again now. It appears to have been a temporary issue with the Sherlock site.
Thanks @zachobront for your personal thoughts I share the same concerns. As much as I want to see F…
Thanks @zachobront for your personal thoughts I share the same concerns. As much as I want to see Fault Proofs go live, I can’t help but feel that we moving too fast with too much on the line.
I do appreciate all the work put into getting Fault Proofs and all its components like the Fault Dispute Game to the level they are at today. I’d be comfortable voting for after the FDG audit.
Unfortunately I will be voting against this time round.
Thanks for raising great points. We have a question about the timing of the deployment.
ajsutto…
Thanks for raising great points. We have a question about the timing of the deployment.
ajsutton:
There isn’t a specific timeline. The upgrade will require coordination with the security council to obtain the appropriate signatures. As mentioned in the proposal, the recommendation is to perform the upgrade shortly after the end of the veto period and I’m definitely excited to see it go live as soon as possible.
According to Adrian’s clarification, the deployment will be coordinated with the security council and if the fact that the Fault Dispute Game isn’t fully audited is deemed a blocker, we can delay the deployment in July? We believe we can vote for the proposal and time the deployment appropriately, relying on the judgement and coordination by the council and OP Labs.
zachobront: Hi @Joxes — thanks so much for the thoughtful response. I’ll do my best to share specific details of my thinking below, but please let me know anywhere you disagree or you feel my explanation is unclear.
Joxes:
As far as I know, the proposal follows the previously published audit framework, falling into the safety and reputational category.
I largely agree with your assessment here. The core Fault Dispute Game (because of the training wheels) is probably best described by the Safety / Reputational quadrant, which seems to have undefined behavior in the audit framework.
But there is a subtle and important distinction in what is meant by training wheels. The current safeguards require proactive action to block a fraudulent proposal. It’s important to recognize that any “black swan” risk to this off chain system would immediately move all Fault Dispute Game code into the Safety / Existential quadrant.
I assume the recent SEAL Wargames focused on the robustness of these systems, but we can’t have the same auditable security guarantees for an off chain system requiring human intervention as on chain code.
Joxes:
Right now, I would appreciate having a complete understanding of your perspective. If this upgrade does not move forward, what would be viable actions to resubmit it? Should we wait for the audit contest to be completed or pay for a new audit?
My perspective is that at least one high quality audit is required for the (large) reputational risk and (small) safety risk to be worthwhile.
I believe waiting for the already funded audit contest in mid July is the most effective way to do that. As long as that contest doesn’t uncover a large amount of deep issues requiring major rewrites, I would be comfortable voting yes as soon as it’s complete.
Tane:
According to Adrian’s clarification, the deployment will be coordinated with the security council and if the fact that the Fault Dispute Game isn’t fully audited is deemed a blocker, we can delay the deployment in July? We believe we can vote for the proposal and time the deployment appropriately, relying on the judgement and coordination by the council and OP Labs.
For further clarity, I would like to state that I am 100% on board with @Tane suggestion here. If OP Labs decides to time the deployment for after the scheduled audit, that would be sufficient for me to feel comfortable with the current proposal.
ajsutton:
It’s not expected that normal users run op-proposer to regularly propose output root…
ajsutton:
It’s not expected that normal users run op-proposer to regularly propose output roots, they’d generally just propose a single output root if they need to withdraw and the chain operator isn’t proposing outputs for them. They can do that through direct calls to the DisputeGameFactory even via Etherscan or could use the create-game subcommand of op-challenger.
One question is that when proposing an output root, could we only store the minimum necessary data on-chain and delay creating the game contract until it is challenged?
The rational is that the current create() method of DisputeGameFactory takes about 429 k gas, which is more than 4 x higher than 93 k of L 2 OutputOracle.proposeL 2 Output().
ajsutton: qizhou:
One question is that when proposing an output root, could we only store the minimum necessary data on-chain and delay creating the game contract until it is challenged?
It is possible that could be done as an optimisation in the future. For simplicity, we haven’t done so at this stage. Note that if this were done, the proposer’s bond would need to be increased to cover the cost of the challenger creating the game to ensure the system remains compatible. So the upfront cost would likely be similar, but you could reclaim that bond if the output root is valid.
In terms of costs to operate a chain, there is also the balancing factor that, unlike the L2OutputOracle, the DisputeGameFactory does not require proposals be made at a fixed interval. So proposals could be made less often for chains that don’t typically see many withdrawals to save costs then made more frequent as chain usage grows. The timeliness of proposals is also less important because they are no longer restricted to a privileged actor so users can propose their own output root if they don’t want to wait.
brichis:
Hey @ajsutton! I think this link is no longer working. Can you please update it?
Th…
brichis:
Hey @ajsutton! I think this link is no longer working. Can you please update it?
The link should be working again now. It appears to have been a temporary issue with the Sherlock site.
Hey @zachobront, thanks for sharing your perspective on this proposal. We appreciate it, especially…
Hey @zachobront, thanks for sharing your perspective on this proposal. We appreciate it, especially given your position.
Many, if not all, of the risks you described are very valid points.
As far as I know, the proposal follows the previously published audit framework 4 , falling into the safety and reputational category. A bug does not immediately compromise the system since it implements various defensive mechanisms, including the Guardian setup itself. Therefore, some bugs are expected, and the security setup needs to be prepared for them.
zachobront:
look forward to voting yes later in the summer when the risks have been addressed.
Right now, I would appreciate having a complete understanding of your perspective. If this upgrade does not move forward, what would be viable actions to resubmit it? Should we wait for the audit contest to be completed or pay for a new audit?
I am happy to see a careful evaluation here, reconciling the security efforts made by core developers with what is believed to be concretely left to do. It is impossible to determine when code is completely bug-free, even with several audits completed. However, we should ensure that our reputation is not easily put at risk (e.g., if several bugs are found shortly after implementation).
For us, if there is a clear risk that we can feasibly avoid, we should make every effort to mitigate it.
I love seeing these conversations happen and am happy that other delegates share their perspectives based on what is described above. CC: L 2 Beat team @kaereste and @GFXlabs, as well others.
zachobront: Hi @Joxes — thanks so much for the thoughtful response. I’ll do my best to share specific details of my thinking below, but please let me know anywhere you disagree or you feel my explanation is unclear.
Joxes:
As far as I know, the proposal follows the previously published audit framework, falling into the safety and reputational category.
I largely agree with your assessment here. The core Fault Dispute Game (because of the training wheels) is probably best described by the Safety / Reputational quadrant, which seems to have undefined behavior in the audit framework.
But there is a subtle and important distinction in what is meant by training wheels. The current safeguards require proactive action to block a fraudulent proposal. It’s important to recognize that any “black swan” risk to this off chain system would immediately move all Fault Dispute Game code into the Safety / Existential quadrant.
I assume the recent SEAL Wargames focused on the robustness of these systems, but we can’t have the same auditable security guarantees for an off chain system requiring human intervention as on chain code.
Joxes:
Right now, I would appreciate having a complete understanding of your perspective. If this upgrade does not move forward, what would be viable actions to resubmit it? Should we wait for the audit contest to be completed or pay for a new audit?
My perspective is that at least one high quality audit is required for the (large) reputational risk and (small) safety risk to be worthwhile.
I believe waiting for the already funded audit contest in mid July is the most effective way to do that. As long as that contest doesn’t uncover a large amount of deep issues requiring major rewrites, I would be comfortable voting yes as soon as it’s complete.
Tane:
According to Adrian’s clarification, the deployment will be coordinated with the security council and if the fact that the Fault Dispute Game isn’t fully audited is deemed a blocker, we can delay the deployment in July? We believe we can vote for the proposal and time the deployment appropriately, relying on the judgement and coordination by the council and OP Labs.
For further clarity, I would like to state that I am 100% on board with @Tane suggestion here. If OP Labs decides to time the deployment for after the scheduled audit, that would be sufficient for me to feel comfortable with the current proposal.
https://www.coinbase.com/blog/strengthening-our-defenses-with-seal-wargame-simulations 3
TL;DR: …
https://www.coinbase.com/blog/strengthening-our-defenses-with-seal-wargame-simulations 3
TL;DR: We conducted a successful SEAL wargame with Base and Optimism (OP), testing our response to a simulated vulnerability in bridge withdrawals.
Hi @Joxes — thanks so much for the thoughtful response. I’ll do my best to share specific details o…
Hi @Joxes — thanks so much for the thoughtful response. I’ll do my best to share specific details of my thinking below, but please let me know anywhere you disagree or you feel my explanation is unclear.
Joxes:
As far as I know, the proposal follows the previously published audit framework, falling into the safety and reputational category.
I largely agree with your assessment here. The core Fault Dispute Game (because of the training wheels) is probably best described by the Safety / Reputational quadrant, which seems to have undefined behavior in the audit framework.
But there is a subtle and important distinction in what is meant by training wheels. The current safeguards require proactive action to block a fraudulent proposal. It’s important to recognize that any “black swan” risk to this off chain system would immediately move all Fault Dispute Game code into the Safety / Existential quadrant.
I assume the recent SEAL Wargames 3 focused on the robustness of these systems, but we can’t have the same auditable security guarantees for an off chain system requiring human intervention as on chain code.
Joxes:
Right now, I would appreciate having a complete understanding of your perspective. If this upgrade does not move forward, what would be viable actions to resubmit it? Should we wait for the audit contest to be completed or pay for a new audit?
My perspective is that at least one high quality audit is required for the (large) reputational risk and (small) safety risk to be worthwhile.
I believe waiting for the already funded audit contest in mid July is the most effective way to do that. As long as that contest doesn’t uncover a large amount of deep issues requiring major rewrites, I would be comfortable voting yes as soon as it’s complete.
Tane:
According to Adrian’s clarification, the deployment will be coordinated with the security council and if the fact that the Fault Dispute Game isn’t fully audited is deemed a blocker, we can delay the deployment in July? We believe we can vote for the proposal and time the deployment appropriately, relying on the judgement and coordination by the council and OP Labs.
For further clarity, I would like to state that I am 100 % on board with @Tane suggestion here. If OP Labs decides to time the deployment for after the scheduled audit, that would be sufficient for me to feel comfortable with the current proposal.
Hi I’m Mofi, a protocol engineer at OP Labs. I do not represent or speak on behalf of the Optimism …
Hi I’m Mofi, a protocol engineer at OP Labs. I do not represent or speak on behalf of the Optimism Foundation.
I shared an objective overview of the facts of this upgrade above on behalf of the Developer Advisory Board, but wanted to follow up with a personal message explaining why I plan to vote no on this proposal.
First and foremost, we sincerely appreciate you taking the time to evaluate the system and share your concerns. It is incredibly valuable to have experts like you participate in the governance system and thoroughly review proposals. We understand your concerns here and want to address them directly so that governance participants can make an informed decision.
I think it is highly likely ( 80 %+) that there are critical bugs still in the Fault Dispute Game. This is no fault of the OP Labs dev team. It’s incredible complex code and hasn’t been audited. It would honestly be astonishing if there were no serious bugs.
The Fault Dispute Game is certainly a complex system. It’s important to consider that audits aren’t the only way to ensure code quality, nor are they a silver bullet. The OP Labs Audit Framework 3 is based on the idea that security starts with developers and an audit is a final assurance, not the basis for considering a system secure.
In this case, OP Labs ran a Sherlock contest focused on the safety nets and overrides — the components of the fault proof for which safety is of existential importance. The Fault Dispute Game is considered a reputational risk but not an existential risk. The Audit Framework explicitly notes “fault proofs with training wheels” as the sole example in the “reputational/safety” quadrant (image reproduced below) of the audit rubric.
image 2282 × 1940 270 KB
Most of the code outside of the Fault Dispute Game contracts falls into the liveness/reputational risk quadrant. The majority of code in the fault dispute system is in op-program (a combination of the consensus critical parts of op-node and op-geth) and op-challenger which are the types of code that experience has shown audits are less effective for vs what is learned by getting code running in the real world. That’s why we’ve been rolling this out incrementally for some time now, including a lot of internal deployments, the public Fault Proof Alpha release and upgrading op-sepolia.
It’s also worth noting that the Immunefi bounty program 2 is being updated to include these contracts so that auditors and bug hunters will have an opportunity to disclose issues in the Fault Dispute Game contracts before any mainnet launch.
In the event that a single critical bug is found and requires shutting down the bridge, it would cause major reputational damage for Optimism. Even though there are safeguards, mainnet bridge code having a critical bug would be very bad for public perception.
Pausing withdrawals is the final safety measure, but not the only one. The Guardian also has the ability to blacklist specific games, allowing withdrawals proven against valid output roots to continue unaffected. The respected game type can also be changed to a permissioned game which does invalidate already proven withdrawals but allows them to be re-proven and therefore does not shut down the bridge. The exact way in which the system should respond depends on the severity and impact of the bug.
We do believe it’s important that governance participants understand that reputational risk does exist here no matter what — it’s never a good thing to need to fix bugs in production. Our position is that the purpose of Stage 1 is to make it possible to deploy fault proofs into production without requiring perfection. OP Stack developers will learn a lot from seeing this system on mainnet. Even Stage 2 explicitly assumes that there will be bugs in the fault proof system and uses multiple independent proof systems to mitigate this risk.
In general, I feel uncomfortable about the idea that proactive action is needed to secure a multibillion dollar protocol. Although it is unlikely, it feels like there is just too much that could go wrong with this much at stake.
For example, after Protocol Upgrade # 8 2 , the guardian role is performed by the 10 / 13 security multisig. For a normal protocol, this might be sufficient, but with billions of dollars on the line, it doesn’t seem out of the question that an attacker could take 4 signers temporarily offline for a few days until their withdrawal is processed.
Proactive action for security is ultimately part and parcel of an optimistic rollup. Rather than using a positive proof of validity, users permissionlessly publish and challenge output root proposals. Challengers must be able to detect invalid proposals in the same way that the Guardian must be able to detect these proposals. In a meaningful way, it is not possible to separate an optimistic rollup from proactive action.
Even today, under the permissioned proposer model, it assumed that the proposer may be fault and a delay is added so that the Guardian role can intervene to remove a proposal if needed. While the contracts that support this process are simpler than the fault dispute game contracts, calculating the correct output root requires correct operation of op-node, op-geth, and op-proposer, none of which are audited before each release. Great care is taken in the development of these components, but the Guardian role is the backstop to ensure security even if they fail — just as in the proposed Stage 1 fault proof system.
I want to make clear that I have the utmost respect for the OP Labs team and think the Fault Dispute Game is incredible well built. I am excited for it to be deployed.
Thank you for your kind words, and again thank you for the work you have done to look into the proposed system and share your concerns.
qizhou:
One question is that when proposing an output root, could we only store the minimum ne…
qizhou:
One question is that when proposing an output root, could we only store the minimum necessary data on-chain and delay creating the game contract until it is challenged?
It is possible that could be done as an optimisation in the future. For simplicity, we haven’t done so at this stage. Note that if this were done, the proposer’s bond would need to be increased to cover the cost of the challenger creating the game to ensure the system remains compatible. So the upfront cost would likely be similar, but you could reclaim that bond if the output root is valid.
In terms of costs to operate a chain, there is also the balancing factor that, unlike the L 2 OutputOracle, the DisputeGameFactory does not require proposals be made at a fixed interval. So proposals could be made less often for chains that don’t typically see many withdrawals to save costs then made more frequent as chain usage grows. The timeliness of proposals is also less important because they are no longer restricted to a privileged actor so users can propose their own output root if they don’t want to wait.
The following reflects the views of L 2 BEAT’s governance team, composed of @kaereste and @Sinkas, …
The following reflects the views of L 2 BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
While we understand and appreciate @zachobront’s points and concerns, we’ll vote in favor of the proposal.
Given that the vote has no immediate consequences as it’s not an on-chain executable vote, we treat it as a way to signal support in the overall direction of implementing fault proofs. We trust the Foundation and OP Labs judgement as to whether the implementation is ready to be moved to production and the timing of the actual upgrade.
Firstly, thank you for the proposal. We consider every step taken towards permissionlessness to be …
Firstly, thank you for the proposal. We consider every step taken towards permissionlessness to be important. We really like the structure of the new mechanism, especially its allowance for anyone to propose output roots and participate in the dispute system. However, we still have concerns about the exit window. As mentioned in the Optimism Docs under Privileged Roles, this structure may create some delays. Nevertheless, as the ITU Blockchain Delegation Committee, we are aware of the value of this development and support this proposal.
As a OP holder, I am happy that this has taken the time to ship as it did and I am in favor of the …
As a OP holder, I am happy that this has taken the time to ship as it did and I am in favor of the proposal
The SEED Latam delegation, as we have communicated here 1 , with @Joxes being an Optimism delegate…
The SEED Latam delegation, as we have communicated here 1 , with @Joxes being an Optimism delegate 1 , we ABSTAIN from this proposal.
After carefully reviewing the proposal, we decided to abstain as a way to differentiate from a straightforward vote FOR. This is because we highly value the reputational risk involved with this proposal and want to minimize it. This means that in our assessment, Fault Proofs definitely need to happen at some point, but considering other security contests that are set to launch in the coming weeks, it makes sense to us that Fault Proofs deployment is not yet necessary. We believe that Fault Proofs as a whole, and the measures taken at the design level to convert OP Mainnet into a Stage 1 rollup, are correct. While the Guardian Role still holds central power, the setup designed around it makes sense to accomplish their expected function.
Finally, as we always emphasize, we hope that any findings regarding the Fault Proof protocol that could compromise its functionality or require alterations to its proposed design will be promptly communicated and the upgrade rescheduled accordingly.
As a delegate who is not a developer these plain English non-technical explanations actually allow …
As a delegate who is not a developer these plain English non-technical explanations actually allow me to be an informed voter on protocol upgrades. Otherwise my options would be limited to abstaining or trying to find another delegates assessment that I trust.
Very glad to hear this. Lots more improvements to come next Season :slight_smile:
Very glad to hear this. Lots more improvements to come next Season :slight_smile:
ajsutton:
If this proposal passes a Token House vote, the L 1 contracts will be upgraded foll…
ajsutton:
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.
To clarify, there has been no change to the original deployment timeline.
