[Tracker] Acceptance tests

[theodorebugnet]

Improvements to add to the suite of acceptance tests.

1. State assertions

• Write module that
  • Stores a value, with a CallMessage taking (previous_value, new_value) that asserts the current value before updating it
  • Has a CallMessage to update an accessory state value
  • Has CallMessages to assert on state.current_rollup_height(), state.current_rollup_visible_slot_number(), state.max_allowed_slot_number_to_access(), and the state root (from the begin_block_hook)
• Implement TransactionGenerator for this module, keeping track of the user value when submitting transactions Add state assertion module sovereign-sdk#1784
  • Improve TransactionGenerator setup to be more flexible when adding modules Refactor soak tests to use builder pattern rather than hardcoded TxType in the lib sovereign-sdk#1790
• Update the acceptance tests to generate transactions for the module, for user state assertions Acceptance tests kernel + user state testing #38
  • Quick fix logging in the starter caused by recent changes in the SDK Replace ad-hoc init_logging with library function from rollup blueprint #39
• Also send an accessory state update transactions, and save the accessory values at each block in the acceptance data
  • During resync, verify the state values at each block
• Update the acceptance test generator to query the values for rollup_height, visible slot number, state root and max slot number, and send an assert transaction for these Acceptance tests kernel + user state testing #38
• Improve shutdown behaviour in the acceptance tests, to avoid dangling docker containers and rollup processes

2. CI testing

CI server has been set up. See Sovereign-Labs/sovereign-sdk#2095 for TODOs and improvements on that front

3. API assertions

• Sequencer websocket testing:

  • Subscribe to TXs. Drop all incoming notifications except on slots where children are fetched and saved; when tx.batch_number % FULL_SLOT_SAVE_INTERVAL == 0, collect the txs and, once the slot is over, verify that they match the saved slot data exactly (including ordering).
  • Subscribe to TX from number: have a check at the end(?) of a soak test: subscribe from various fully-saved slots and ensure the full tx set is returned again, with nothing extra. Unsubscribe once the slot has been verified and resubscribe at the next slot etc. Could also be done in parallel for past slots rather than waiting till the end of the test.
  • Subscribe to TX status updates: TODO
  • Subscribe to events: similar logic. Complication: events don't contain a batch reference. Possibly keep a list of transaction hashes from the above, and detect when an event comes in matching the first transaction hash in a fully-saved slot, then verify that all events from the slot have been processed. This would require keeping a cache of events in case the event subscription runs ahead of the transaction subscription, until we know when the next event of interest starts.
  • Subscribe to events with filter: Same as above in parallel but with a filter; soak transactions with events include bank transfer and state-consistency value updates, non-soak transactions are accessory state updates.

• State value testing:

  • Accessory state value queries: covered by the state consistency checks
  • Historical accessory state queries: add additional API queries to ensure correct state is returned for the past few slots, plus some older historical ones
  • User state queries: save the final user state value (from the state consistency soak transactions) into the test data alongside the accessory value
  • User state: mirror the accessory state logic to validate user state on resync, both current and historical
  • Kernel state: TODO: do we have APIs for directly querying kernel state?

WIP section

• Events
• Static APIs: mostly following the current snapshot method, but ensure comprehensiveness covering them all

A) Sequencer APIs

• Add transaction/event assertions. The snapshot data already includes the transactions and events at the full snapshot heights; add assertions to verify that they become available during resync at the expected block heights and with matching data.
• Websocket APIs: subscribe and await for updates matching the expected data from the acceptance data

B) Rollup APIs

• Save GET data in acceptance data and verify at given block heights, i.e. /rollup/base-fee-per-gas/latest and /rollup/addresses/:address/dedup (for a list of known accounts)

C) Ledger APIs

• Slot snapshots are already saved; we can perform queries to each sub-API (batches, txs etc.) and verify it matches the data in the snapshot. TODO: comprehensively or sample?