Description
Summary
Proposed changes to the OptimismPortal that will improve fallbacks so that user withdrawal proofs are not invalidated by default when a fallback is activated.
Context
The OptimismPortal contract allows users to prove withdrawals by demonstrating that those withdrawals exist inside of the state root of a FaultDisputeGame instance. Withdrawals can be
finalized if the FaultDisputeGame instance resolves in favor of the defender, the instance is not blacklisted, and the game has sat around for the air-gap period.
The DisputeGameFactory can create different implementations of the DisputeGame which typically have different code and are identified by an integer "game type". The OptimismPortal currently defines a variable respectedGameType which determines the particular DisputeGame code that users can utilize when proving and finalizing withdrawals. The "fallback" safety net action is the ability for the Guardian or Deputy Guardian address to change the respectedGameType variable to some alternative game type (e.g., the PermissionedDisputeGame) in the case that the FaultDisputeGame contract is found to be buggy.
Problem Statement
The fallback action of changing the respectedGameType variable updates another variable called respectedGameTypeUpdatedAt that keeps track of exactly when the respected game type was changed. Currently, the OptimismPortal contract enforces that withdrawals can only be proven or finalized against DisputeGame contracts that were created with a timestamp greater than the respectedGameTypeUpdatedAt variable. This effectively invalidates any withdrawal proofs that were submitted prior to the activation of the fallback mechanism.
Withdrawal invalidation is a powerful tool in the incident response playbook as it can mitigate the impact of a large number of invalid dispute games at the same time. However, it also forces users to resubmit their withdrawal proofs and wait an additional 7 days to execute a withdrawal. Users have reported that this invalidation and additional delay period is a pain point. This user impact means that the fallback is highly disruptive as a standard security mechanism.
Project Updates
- [2024-09-27] Draft design document is available here.
- [2024-09-27] Draft design document is being actively reviewed.
- [2024-10-28] Design document has been approved and merged.