op-supernode: Interop Message Validation#19051
Merged
axelKingsley merged 15 commits intodevelopfrom Feb 5, 2026
Merged
Conversation
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #19051 +/- ##
==========================================
- Coverage 76.3% 76.0% -0.4%
==========================================
Files 188 188
Lines 10943 10943
==========================================
- Hits 8359 8326 -33
- Misses 2438 2473 +35
+ Partials 146 144 -2
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
geoknee
reviewed
Feb 3, 2026
op-acceptance-tests/tests/supernode/interop/halt/invalid_message_halt_test.go
Show resolved
Hide resolved
geoknee
reviewed
Feb 3, 2026
geoknee
reviewed
Feb 3, 2026
op-acceptance-tests/tests/supernode/interop/invalid_message_halt_test.go
Outdated
Show resolved
Hide resolved
axelKingsley
commented
Feb 4, 2026
axelKingsley
commented
Feb 4, 2026
This TDD test verifies the Interop Activity's behavior when an invalid executing message is included in a chain: - Validity should NEVER advance to include the invalid block's timestamp - Safety and unsafety for both chains should continue to advance The test sends a valid initiating message on chain A, then sends an invalid executing message on chain B (with an impossible log index), and observes that the Supernode correctly halts validity advancement while allowing safety heads to progress.
This prepares the interop activity for implementing the actual interop algorithm by: 1. Moving stubbed algorithm functions to algo.go: - loadLogs: loads and persists logs up to a timestamp - verifyInteropMessages: validates executing messages - invalidateBlock: handles invalid blocks 2. Adding per-chain logs.DB for log persistence: - Uses op-supervisor's logs.DB directly (no wrapper) - openLogsDB helper creates DB per chain in data directory - Full persistence support (data survives restart) 3. Extending ChainContainer interface with FetchReceipts: - Added to ChainContainer, EngineController, and l2Provider interfaces - Enables interop activity to fetch receipts for log processing 4. Initializing logsDBs in Interop activity: - Creates one logs.DB per chain on startup - Properly closes all logsDBs on Stop() 5. Unit tests for log persistence: - Tests for open/close, seal block, persistence - Tests for multiple chain isolation
This commit reorganizes the interop activity code and adds comprehensive tests: 1. File reorganization: - Renamed algo.go to logdb.go for log persistence code - Created new algo.go with just verifyInteropMessages - Moved invalidateBlock back to interop.go 2. Added LogsDB interface: - Defines interface around logs.DB for better testability - Enables mock implementations in unit tests 3. Added chain continuity check: - verifyPreviousTimestampSealed now returns previous block hash - loadLogs verifies block parent matches logsDB hash - Added ErrParentHashMismatch error 4. Expanded unit test coverage for logdb: - Tests for verifyPreviousTimestampSealed (activation/non-activation) - Tests for processBlockLogs (empty, with logs, errors) - Tests for loadLogs parent hash mismatch 5. Improved interop_test.go assertions: - Verify logsDBs population in constructor tests - Verify verifyFn receives correct args - Verify timestamps before activation return true - Verify Result.IsEmpty for various scenarios - Verify data retrieval after handleResult - Full cycle tests verify logsDB and L2Heads
This commit implements the core verification logic for the interop activity, completing the TDD cycle for the InvalidMessageHalt acceptance test. Key changes: - Implement verifyInteropMessages to validate executing messages at each timestamp - Verify initiating messages exist in source chain's logsDB via Contains query - Verify timestamp ordering: initiating timestamp < executing timestamp - Fix verifyPreviousTimestampSealed to accept any sealed block timestamp < ts (not just ts-1), handling block times > 1 second - Add comprehensive unit tests for verification logic The acceptance test now passes, demonstrating that: - Valid cross-chain messages are verified successfully - Invalid executing messages (wrong LogIndex) halt validity advancement - Safe/unsafe heads continue to advance independently
Refactor tests for better organization and reduced redundancy: - Create logdb_test.go for logsDB infrastructure tests - TestLogsDB_Persistence (data persistence, multi-chain isolation) - TestVerifyPreviousTimestampSealed (7 table-driven cases) - TestProcessBlockLogs (5 subtests) - TestLoadLogs_ParentHashMismatch - Rewrite algo_test.go for verification algorithm only - TestVerifyInteropMessages_ValidBlocks (3 subtests) - TestVerifyInteropMessages_InvalidBlocks (5 subtests) - TestVerifyInteropMessages_Errors - Consolidate interop_test.go for lifecycle/coordination - Merge related tests into table-driven patterns - Remove trivial getter/empty-case tests Test count: 62 functions → 19 functions (~55 cases via subtests) Removed 8 trivial tests that added no value.
55ec7d1 to
4ae5b66
Compare
a7bc995 to
0ab024e
Compare
0ab024e to
5d27cad
Compare
fb2860d to
309ed88
Compare
geoknee
approved these changes
Feb 5, 2026
For activation-after-genesis, the logsDB cannot handle non-sequential block sealing (starting from block N instead of genesis). At activation timestamp: - Skip loading logs (logsDB requires sequential blocks from genesis) - Skip verification (can't verify cross-chain messages referencing pre-activation data) - Trust blocks at activation time Also allow empty logsDB at activation+blockTime (the first real timestamp).
4a9b39b to
0e10164
Compare
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.
What
Implements the actual Message Validation task of Interop. Does Not yet have any handling for the invalid blocks it discovers.
Invalid messages in blocks cause a chain halt, which is demonstrated by an acceptance test.
How
1. Acceptance Test (op-acceptance-tests)
2. LogsDB Infrastructure (logdb.go)
3. Verification Logic (algo.go)
verifyInteropMessages - for each chain, opens the block from logsDB and validates all executing messages
4. Chain Container / Engine Controller
5. Result Types (types.go)