-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Tracker] Proofs: Incident Response Improvements (Upgrade 13) #12172
Comments
Re: Proofs: Basic DelayedWETH Capability Expansion #12174 fired off a few questions in discord, let me know if they're more appropriately located here! |
Re: AnchorStateRegistry poisoning #12173 and OptimismPortal2 withdrawal invalidation #12175 spec in draft: https://www.notion.so/oplabs/AnchorStateRegistry-Spec-12ff153ee1628019a698e6231353847d#12ff153ee162803fb788fb772b24b41a convo in discord (for now!) |
Summary
We are working on a number of proposed improvements to the incident response process for the OP Stack fault proof system. The goal of these improvements is to simplify the safety nets and fallbacks available in the proof system and to minimize the stress factors that may impact the decision to execute a fallback.
Context and Problem Statement
The OP Stack fault proof system was built with a number of safety nets and fallbacks designed to catch and prevent issues in the core proof system from impacting system safety. One important learning from the Granite Network Upgrade was that any potential negative side-effects of a fallback can cause stress when deciding to execute that fallback. For example, there was considerable debate about preemptively executing the fallback to the
PermissionedDisputeGame
because this fallback option causes existing user withdrawal proofs to be invalidated.The goal of this project is to make a number of improvements to the fault proof system that simplify the existing fallbacks and reduce or eliminate any negative side-effects when the fallbacks are activated.
Scope
We want to make a relatively minimal number of changes to the proof system that don't involve sweeping architectural changes. We accept that a number of architectural changes may be necessary but want to limit this as much as possible.
Sub-Projects
Please refer to the following GitHub issues to understand the work items involved in this project and the current status of those items.
The text was updated successfully, but these errors were encountered: