op-supernode: Block Replacement

[axelKingsley]

Tool Use Notice

This code was generated with a TDD pattern, iterated and then ultimately rewritten through self-review by the author. Tests remain largely generative. All architecture patterns and directions were previously well defined, so none of the solutions in this PR are themselves AI generated. Wherever possible the "jump" from point A to point B by the model was as small as possible.

A "feature.md" diary file can be found in the PR presently, which can be read to understand the tool use better. I only started the diary part way though this work so some of it is backfill.

Block Invalidation Feature

Overview

This PR implements block invalidation for the op-supernode. When the Interop activity detects an invalid cross-chain executing message, it invalidates the containing block, triggers a chain rewind, and rebuilds a replacement block using Holocene's deposits-only mechanism.

Data Flow: Invalid Message Detection → Block Replacement

Changes

• DenyList & InvalidateBlock (op-supernode/supernode/chain_container/)
  • bbolt-backed persistence for denied block payload hashes
  • InvalidateBlock(height, hash) adds to denylist and triggers rewind if currently in use
  • IsDenied(height, hash) for querying denied blocks
• SuperAuthority Injection (op-node/rollup/engine/)
  • New SuperAuthority interface allows supernode to deny payloads before engine insertion
  • Denied payloads create deposits-only replacement blocks
• Activity Reset Notification (op-supernode/)
  • ResetOn(chainID, timestamp) method on Activity interface
  • Chain container notifies supernode on rewind → supernode broadcasts to all activities
  • Interop activity clears logsDB and verifiedDB for affected timestamps
• Interop → ChainContainer Wiring (op-supernode/supernode/activity/interop/)
  • invalidateBlock() connects invalid message detection to chain container invalidation

---

Work Breakdown

Because this work was done generatively, I am able to produce good record of the order and ways in which each piece was created.

Milestone 1: DenyList + InvalidateBlock

Synopsis

A bbolt-backed persistence layer for tracking invalid block payload hashes, plus the mechanism to trigger chain rewinds when an invalid block is currently in use. The DenyList stores hashes keyed by block height, allowing multiple denied hashes per height. When InvalidateBlock is called, the hash is persisted and the chain container checks if the current chain tip matches—if so, a rewind is triggered.

Specified Behavior

Scenario	Behavior
Add hash at height	Persisted immediately to bbolt
Add duplicate hash	Idempotent, no error
Height == 0	Error: cannot invalidate genesis block
Current block matches invalidated hash	Rewind triggered, returns (true, nil)
Current block differs from invalidated hash	No rewind, returns (false, nil)
Engine unavailable	Hash added to denylist, no rewind check

Tests Introduced

Test	Cases	Assertions
TestDenyList_AddAndContains	4	Single hash, multiple hashes same height, wrong height returns false, duplicate is idempotent
TestDenyList_Persistence	2	Survives close/reopen, empty DB on fresh open
TestDenyList_GetDeniedHashes	3	Returns all at height, empty for clean height, isolated by height
TestDenyList_ConcurrentAccess	1	10 goroutines × 100 ops, all succeed
TestInvalidateBlock	5	Matches triggers rewind, differs no rewind, engine unavailable, timestamp calculation, genesis block error
TestIsDenied	3	Denied returns true, non-denied false, wrong height false

---

Milestone 2: Wire Interop → ChainContainer

Synopsis

Connects the Interop activity's invalid message detection to the ChainContainer's invalidation mechanism created in the previous milestone. When the Interop activity identifies an executing message that references a non-existent initiating message, it calls invalidateBlock which looks up the appropriate chain container and delegates to its InvalidateBlock method.

Specified Behavior

Scenario	Behavior
Chain not found	Return error "chain %s not found"
ChainContainer.InvalidateBlock errors	Log error, return error
Rewind triggered	Log warn "chain rewound due to invalid block"
No rewind needed	Log info "block added to denylist"

Tests Introduced

Test	Cases	Assertions
TestInvalidateBlock (interop)	4	Correct args passed to container, chain not found error, error propagation, handleResult calls for each invalid head

---

Milestone 3: SuperAuthority Injection

Synopsis

Allows the op-supernode to inject a "SuperAuthority" into the op-node's engine controller. This authority is consulted before payload insertion—if it denies a payload, the engine controller either emits a PayloadInvalidEvent (pre-Holocene) or requests a deposits-only replacement block (Holocene, the actual expected behavior). This prevents denied blocks from being re-inserted after a rewind.

Specified Behavior

Scenario	Behavior
IsDenied returns (true, nil)	Payload rejected
Rejected + Holocene + derived	emitDepositsOnlyPayloadAttributesRequest called
Rejected + pre-Holocene	PayloadInvalidEvent emitted
IsDenied returns (false, nil)	Payload proceeds to engine
IsDenied returns error	Log warning, proceed with payload (graceful degradation)
SuperAuthority is nil	No check, proceed with payload

Tests Introduced

Test	Cases	Assertions
TestSuperAuthority_DeniedPayload_EmitsInvalidEvent	1	PayloadInvalidEvent emitted, NewPayload NOT called
TestSuperAuthority_AllowedPayload_Proceeds	1	NewPayload called, PayloadSuccessEvent emitted
TestSuperAuthority_Error_ProceedsWithPayload	1	NewPayload called despite error (graceful degradation)
TestSuperAuthority_NilAuthority_Proceeds	1	NewPayload called when SuperAuthority is nil

---

Milestone 4: Activity Reset Notification Chain

Synopsis

When a chain container rewinds, it notifies the supernode via a callback, which then broadcasts ResetOn(chainID, timestamp) to all activities. This allows activities to clear any cached state that may have become stale. The Interop activity specifically rewinds its logsDB (clearing logs at or after the timestamp) and verifiedDB (clearing verification results at or after the timestamp).

Specified Behavior

Activity	ResetOn Behavior
Heartbeat	No-op (no cached state)
Superroot	No-op (queries containers directly)
Interop	Rewind logsDB, rewind verifiedDB, reset currentL1

Interop ResetOn Scenario	Behavior
Previous block available	logsDB.Rewind(prevBlockID)
Previous block not found	logsDB.Clear()
timestamp ≤ blockTime	logsDB.Clear()
Verified results deleted	Log ERROR (unexpected)

Tests Introduced

Test	Cases	Assertions
TestVerifiedDB_RewindTo	4	Removes entries at/after timestamp, returns false when none deleted, rewind all entries, allows sequential commits after
TestResetOn	6	Rewinds logsDB when prev block available, clears when not, clears when timestamp ≤ blockTime, rewinds verifiedDB, resets currentL1, handles unknown chain

---

---

Acceptance Test

Synopsis

End-to-end test with two L2 chains and a supernode. Sends a valid initiating message on chain A, then sends an invalid executing message on chain B (referencing a non-existent log index). Observes that the supernode detects the invalid message, rewinds chain B, and builds a replacement block without the invalid transaction.

Notably, this test utilizes a test-only pause functionality on the interop activity, which allows it to stall at a specific timestamp. this allows for Acceptance tests to positively witness the original block and the replacement separately.

Test	File
TestSupernodeInteropInvalidMessageReplacement	op-acceptance-tests/tests/supernode/interop/reorg/invalid_message_reorg_test.go

Assertions

#	Assertion	Purpose
1	resetDetected == true	Rewind was triggered by invalidation
2	replacementDetected == true	New block created at same height
3	replacementHash ≠ invalidHash	Block was actually replaced
4	invalidTx NOT in replacementTxs	Invalid transaction removed via Holocene deposits-only
5	verified == true	Replacement block passes interop verification

[wiz-inc-a178a98b5d]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	1
Software Management Findings	-
Total	1

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.0%. Comparing base (151ae07) to head (d889adf).
⚠️ Report is 43 commits behind head on supernode/messageValidation.

Additional details and impacted files

@@                      Coverage Diff                       @@
##           supernode/messageValidation   #19091     +/-   ##
==============================================================
- Coverage                         76.0%    76.0%   -0.1%     
==============================================================
  Files                              188      188             
  Lines                            10943    10943             
==============================================================
- Hits                              8326     8323      -3     
- Misses                            2473     2476      +3     
  Partials                           144      144             

Flag	Coverage Δ
cannon-go-tests-64	66.4% <ø> (ø)
contracts-bedrock-tests	81.6% <ø> (-0.1%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[axelKingsley]

Doing a cycle of self-review. These comments are made while editing, meaning they likely are immediately outdated for the better.

[ajsutton]

Nice to see the behaviour being validated with an AT (which is the only code I really read...). Some non-blocking suggestions to help build up a library of utility method that will make writing future ATs easier and keep things maintainable.

[almanax-ai]

Plan expired

Your subscription has expired. Please renew your subscription to continue using CI/CD integration and other features.

[geoknee]

Review Part 1, Part 2 to follow tomorrow.

[geoknee]

👏