ethereum-optimism / ethereum-optimism/specs
feat: Easy Game Rotation
- Dominant language
- Python
- Stars
- 178
- Forks
- 206
- Avg merge
- 5d 2h
- Merged PRs (30d)
- 6
Description
## Overview
Currently, the `OptimismPortal2` contract respects a single dispute game type at a time, as outlined in the [specification](https://specs.optimism.io/fault-proof/stage-one/bridge-integration.html#fpac-optimismportal-mods-specification) for the `OptimismPortal` modifications made as a part of the Stage 1 fault proofs release.
The issue with this is that changing the respected game type issues a large user experience burden to the users of the chain by delaying their withdrawals for a week. This process happens in [this codepath](https://github.com/ethereum-optimism/optimism/blob/375b9766bdf4678253932beae8234cc52f1f46ee/packages/contracts-bedrock/src/L1/OptimismPortal2.sol#L655-L665), where during withdrawal finalization, the dispute game that the withdrawal was proven against is checked to both be of the current respected game type and created after the most recent time the respected game type was updated.
```solidity
// The game type of the dispute game must be the respected game type. This was also checked in
// `proveWithdrawalTransaction`, but we check it again in case the respected game type has changed since
// the withdrawal was proven.
if (disputeGameProxy.gameType().raw() != respectedGameType.raw()) revert InvalidGameType();
// The game must have been created after `respectedGameTypeUpdatedAt`. This is to prevent users from creating
// invalid disputes against a deployed game type while the off-chain challenge agents are not watching.
require(
createdAt >= respectedGameTypeUpdatedAt,
"OptimismPortal: dispute game created before respected game type was updated"
);
```
### Desired Change
The new behavior here should be such that the `Guardian` can _optionally_ invalidate, rather than always having to invalidate, the proofs of ongoing user withdrawals.
The behavior should enable a "rollover period," where withdrawals proven against dispute games of the previous game type are allowed, if the Guardian did not specify that old games were to be invalidated. No functionality around the rest of the withdrawal path should change.
Contributor guide
Research direction
Start with the OptimismPortal2 withdrawal-finalization codepath linked in the issue, especially lines 655–665, and read the linked FPAC OptimismPortal specification. Define how a Guardian optionally invalidates old-game proofs while preserving the rest of the withdrawal path. Done means the rollover behavior and Guardian choice are specified without the current mandatory invalidation delay.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- solidity
- Domain
- blockchain, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100