faultproof_withdrawals: Skip withdrawal events whose proof was deleted - #199
Open
ajsutton wants to merge 4 commits into
Open
faultproof_withdrawals: Skip withdrawal events whose proof was deleted#199ajsutton wants to merge 4 commits into
ajsutton wants to merge 4 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The forgery detector reads the proof record from state, because neither prove event carries the
game address. If the record is gone,
provenWithdrawals(hash, submitter)returns the zeroaddress, the monitor binds a dispute game at
0x0, andRootClaimfails on an address with nocode.
Monitor.Runthen logs the error and returns without advancingm.state.nextL1Height, soevery later tick re-scans the same range and fails the same way. The monitor stops permanently.
ethereum-optimism/optimism#22669 adds
OptimismPortal.deleteProvenWithdrawal, which lets anyonedelete a proof record once its game resolved
CHALLENGER_WINSor was blacklisted. The proveevents stay in the logs forever, and a fresh monitor start backfills 14 days, so one deletion
inside that window would brick the monitor at its next restart. This change must ship and deploy
before that contract change.
An empty record on its own does not prove a deletion. The record is read at the head of the
chain, so a lagging node, a failover between nodes, or a reorg of the prove transaction can all
return an empty record for a proof that is still live. Skipping on the empty read alone would
turn a stall into a silent miss of a live proof. So an empty record is only treated as a deletion
when the portal also emitted a matching
WithdrawalProofDeletedevent at or after the proveblock. Then the validator returns
ErrWithdrawalProofDeleted, both enrichment loops log theevent and skip it, and the monitor advances its cursor.
An empty record with no deletion event returns
ErrWithdrawalProofMissing, which fails the blockrange as before. That case is transient: the range is retried on the next tick and succeeds once
the node catches up, or once the reorged prove event stops being returned.
The deletion topic is computed from the event signature, because the checked-in binding predates
the event.
Tests use a fake JSON-RPC L1, so they pin the behaviour without a devnet. They cover the skip
with a deletion event, the retry without one, and a control proving live proofs are still
enriched. The skip tests fail without the fix.