tynes
commented
3 weeks ago Coupling this work with a design of the OptimismPortal that doesn't enshrine the DisputeGameFactory or the L2OutputOracle would be nice. This would look like decoupling proveWithdrawalTransaction and finalizeWithdrawalTransaction specific implementations from the OptimismPortal and instead have them exist in a different contract. There are a few levels of abstraction this can be considered with, ie should the proof verification happen in a different contract and the replay protection? It would be assumed that the other contract would auth a withdrawal and if it calls into the OptimismPortal, then it can faciliate sending funds out.
This is good because it modularizes the OptimismPortal. The code is already hitting codesize limits when modified. There is a lot of storage in the OptimismPortal, every storage slot set is a liability. It also makes it easier to implement alternative proof systems like sp1 based validity proofs. It could just be a different proof verification contract that calls into the OptimismPortal
We wanted to share an idea for some teams to explore about creating "Change Respected Game Type Without Invalidating Withdrawals"
Is your feature request related to a problem? Please describe.
When the respected game type is changed in OptimismPortal, it also invalidates any already proven withdrawals, requiring users to reprove them and wait an additional 7 days. While this is desirable in some cases, we need a way to change the respected game type without invalidating withdrawals. This avoids users being impacted when pre-emptively switching to the permissioned game or when switching back to the permissionless game after fixes are deployed.
Additional context
We would like to start this line of work in H2 2024.