[FINAL] Protocol Upgrade #7: Fault Proofs

Technical Proposals 📃 Protocol Upgrade
1

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 L2 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 L2 to L1 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:

  1. DisputeGameFactory (implementation: 0xc641A33cab81C559F2bd4b21EA34C290E2440C2B proxy: 0xe5965Ab5962eDc7477C8520243A95517CD252fA9) - a factory for creating dispute games that can be used by the upgraded OptimismPortal as the source of proposed output roots.
  2. FaultDisputeGame (0x4146DF64D83acB0DcB0c1a4884a16f090165e122) - an implementation of a dispute game that uses permissionless, interactive bi-section of the chain state
  • This is initialized with an ABSOLUTE_PRESTATE of 0x037ef3c1a487960b0e633d3e513df020c43432769f41a634d18a9595cbf53c55. This is the initial state for the Cannon MIPS VM to run op-program tagged in the optimism repo at commit a6d4eeda11477adfcd106e03131625a40334e3a6(tagged as release op-program/v1.0.0). This prestate can be rebuilt using the make reproducible-prestate command (docs)
  1. PermissionedFaultDisputeGame (0xE9daD167EF4DE8812C1abD013Ac9570C616599A0) - 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.
  2. AnchorStateRegistry (implementation: 0x6B7da1647Aa9684F54B2BEeB699F91F31cd35Fb9 proxy: 0x18DAc71c228D1C32c99489B7323d441E1175e443) - 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 0x2694ac14dcf54b7a77363e3f60e6462dc78da0d43d1e2f058dbb6a1488814977.
  • 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.
  1. DelayedWETH (implementation: 0x97988d5624F1ba266E1da305117BCf20713bee08 proxy: 0xE497B094d6DbB3D5E4CaAc9a14696D7572588d14) - an extension to WETH9 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.
  2. PreimageOracle (0xD326E10B8186e90F4E2adc5c13a2d0C137ee8b34) - 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.
  3. MIPS (0x0f8EdFbDdD3c0256A80AD8C0F2560B1807873C9c) - 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:

  1. Upgrade the OptimismPortal contract (0xe2F826324b2faf99E513D16D266c3F80aE87832B) 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 L2OutputOracle 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.
  1. The L2OutputOracle contract is no longer used
  2. The SystemConfig contract (0xF56D96B2535B932656d3c04Ebf51baBff241D886) is updated to:
  • reference the DisputeGameFactory address instead of the L2OutputOracle 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 L1 (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 L1 Proxy Admin (a 2-of-2 multisig with the Optimism Foundation and Security Council).

These contracts are tagged in the optimism repo at commit 547ea72d9849e13ce169fd31df0f9197651b3f86 (tagged as release candidate op-contracts/v1.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 L2OutputOracle 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 L1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle #23a. 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 L1 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 L1 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.

24 Likes
2

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

For Optimism withdrawals to function, the L2 state root must be posted to L1.

You can think of the L2 state root as a single “summary” value that can be used to prove any fact about L2’s state. This value is used when withdrawing funds to prove those funds were actually withdrawn on L2.

(Optimism actually uses a few different values to make proving simpler, but we can skip that for this discussion.)

Before this upgrade, this L2 root value was posted to the L2OutputOracle 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 L2 root.

How does this work?

L2 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:

  1. An off chain monitoring system has been set up to monitor all proposed roots and ensure they align with the correct state.

  2. 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.

  3. 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.

18 Likes
3

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

Was this non-technical summary useful?

Please provide any additional feedback in the comments below

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

Thanks @zachobront and DAB for the summary. Very helpful!

2 Likes
5

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.

2 Likes
6

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.

7

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

8

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.

1 Like
9

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

10

How long has been active? Is there any performance report?

How does the manual verification happen?

11

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

12

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.

13

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.

14

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

15

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.

16

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:

  1. How large are the bonds expected to be needed to sustain and win a dispute? A summary of the factors involved would be nice.
  2. How many steps/transactions are required to settle a dispute (worst-case scenario)?
  3. 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?
  4. 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.

3 Likes
17

@ajsutton So when will be the proposal implemented on mainnet? Is there a specific timeline? Thank you!

18

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.

19

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.

20

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.

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

1 Like