You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 aFaultDisputeGame
instance. Withdrawals can befinalized 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 theDisputeGame
which typically have different code and are identified by an integer "game type". TheOptimismPortal
currently defines a variablerespectedGameType
which determines the particularDisputeGame
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 therespectedGameType
variable to some alternative game type (e.g., thePermissionedDisputeGame
) in the case that theFaultDisputeGame
contract is found to be buggy.Problem Statement
The fallback action of changing the
respectedGameType
variable updates another variable calledrespectedGameTypeUpdatedAt
that keeps track of exactly when the respected game type was changed. Currently, theOptimismPortal
contract enforces that withdrawals can only be proven or finalized againstDisputeGame
contracts that were created with a timestamp greater than therespectedGameTypeUpdatedAt
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
Resources
The text was updated successfully, but these errors were encountered: