op-node: Span Batch Derivation

[ImTei]

Contexts

This PR contains the derivation code for Span Batch.

Please refer to the Implementations - Derivation and Hard Fork Activation sections of the Design Docs and op-node section of Implementation Design Docs for details & rationales.

This PR has a dependency on the Span Batch Type, Encoding, and Decoding PR.

Changes

• Modifications:
  • Modify ChannelReader to decode both SingularBatch and SpanBatch.
  • Verify if the processing batch’s timestamp matches the expected batch type by spanBatchTime at BatchQueue.
  • BatchQueue splits a SpanBatch to multiple SingularBatch-es.
  • Leave the rest of the derivation stages as-is by passing SingularBatches.
  • ^ Please refer to the op-node section of Implementation Design Docs for details.
• Added unit tests.
  • ^ Please refer to the Derivation category in the Test List Sheet for each test’s details.

[mergify]

Hey @ImTei! This PR has merge conflicts. Please fix them before continuing review.

[protolambda]

Looks good, left a few comments about testing and edge-cases to harden against. I will do a second review pass later, since the derivation code is quite critical.

[protolambda]

Adding a do-not-merge label to give others the chance to review as well.

[protolambda]

Opened #7621 to resolve conflicts with develop

Follow-ups to implement after this PR:

• [in response to span-batch origin-bits checking]:
  I think this is safe-ish: it's limited by the origin_bits length, and can thus not be infinite.
  But we might end up waiting for a very large span-batch (in terms of covered L1 origins) if one is crafted maliciously like that.
  We may need to harden it with additional checks/limits here. We can do so in a follow-up PR however.
• The Batch typing improved a little, but we should look if we can clean this up more:
  ideally there are less different types of intermediate batch forms.
• Proto moved the fix from last PR that filters span-batches upon reading from the batch-reader to the channel-in-reader,
  since the batch-reader no longer has L1 inclusion data (due to the way span-batches work).
  We still want to avoid span-batch code-paths before the hardfork activates however,
  so it's worth checking the L1 data before converting a raw span-batch into a full one.
• In the batch-checking function we need to review the hardfork activation conditions,
  and update the specs as well, so the span-batches activate at the right moment (w.r.t. L1 inclusion and L2 block time)
  This should be added to the span-batch derivation specs, and then referenced as a feature of Canyon,
  in the superchain-upgrades spec document.

[protolambda]

Closing in favor of #7621