Span Batch Hard Fork Activation Rule Update

[pcw109550]

This diff fixes subset of #7289 (comment)

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.

1. Added span batch hardfork spec.
2. Harden span batch hardfork check using L1 inclusion block time.

Additional context

We may update superchain-upgrades spec in the separate PR, resolving below sentence.

This should be added to the span-batch derivation specs, and then referenced as a feature of Canyon,

in the superchain-upgrades spec document.

Base branch will be changed to develop when #7621 is merged in develop branch.

[tynes]

We want to move away from IsSpanBatch towards IsCanyon right?

[pcw109550]

We want to move away from IsSpanBatch towards IsCanyon right?

@tynes Yes. Span batch is part of Canyon network upgrade, so IsSpanBatch will be replaced using IsCanyon.

Will open a separate PR after every span batch PR (tracked here) has reached the develop branch.

Span Batch will not be part of Canyon, so will leave as is.

[protolambda]

Rebased on develop 👍

[ImTei]

Applied the new proposal.

• Updated the specs. We can use only L1 origin block time without L2 block time. because there's an invariant: L2 block time > L1 origin block time
• Implemented the new rule in CheckBatch().
• Left the existing L1 inclusion block check in ChannelInReader, for early dropping invalid batches.
  • We can use channel.open_l1_block here, but it makes more diffs in the derivation pipeline. I think using the L1 inclusion block is enough because it's just for optimization and safety, not for the strict check. I want to hear your thoughts about this part. @protolambda @ajsutton