Update Span batch specs to allow overlapping batches

[ImTei]

Context

• Current span batch spec does not allow span batches that overlaps current safe chain.
• So the op-node cannot proceed derivation if the pipeline is reset to the middle of span batch.
• It's very hard to guarantee that the op-node will always reset the safe head to the boundary of the span batch.
• Therefore we need to allow overlapping span batches.

Changes

• Specs
  • Updated span batch validation rules to allow overlapping batches

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ImTei]

@protolambda Please review this PR when you get a chance

[trianglesphere]

This overlapped case is pretty weird, but we need to pay very careful attention to it.

Starting from normal operation, my assumption is that when we have a span batch which contains first a string of valid batches & then an invalid batch & then valid batches again, we will process all the valid batches, reject the invalid batch, and then wait for a sequence window timeout before discarding the span batch & processing more.

Looking at the implementation, we actually just pop all of the batches out of the span batch regardless of if a batch was successfully applied or not. It will get to the attributes queue & will reset the entire pipeline.

[ImTei]

@trianglesphere Thanks for the comment. It seems to be a very critical point.
so I understand that we need to consider the atomicity of the span-batch. This is a different topic than overlapping batch. Is it correct?

• As you said, we don't check if the previous singular batch is applied successfully and just pop the next batch in the current implementation of span batch derivation.
• We must check that. This can be done simply by comparing the given safe head's block hash and the cached batch's parent hash.
• And if some singular batch derived from the span batch fails to be applied, we have to discard the entire span batch. It means that we need to reorg the chain to the state before the span batch.
• This reorg does not mean resetting the entire pipeline. we should just reset the safe head and keep the rest states.

@protolambda what do you think?

[trianglesphere]

@ImTei, yep, we do need to consider the atomicity. I would also take a step back & think about what behavior we want if there is an invalid batch inside a span batch. The other thing is that we need to think about this in the context of re-orgs & also other singular batches which have been included.

[ImTei]

@trianglesphere @protolambda

I have specified the problematic scenario and what to implement. I'll implement those things in the next follow-up PR. let me know if there are any concerns or suggestions! :)

• Even if the span batch passed the batch queue’s validity checks, a singular batch from the span batch might fail to be applied to the safe chain due to the BlockInsertPayloadErr.
• In this case, we suppress the error and retry the pipeline with the next batch from the batch queue.
• If this case occurs in the middle of a span batch, i.e. we already applied some singular batches from the span batch to the engine, we must revert them for the atomicity of span batches.
• Therefore, we need the following behaviors when BlockInsertPayloadErr occurs during processing span batches:
  • Engine queue must trigger safe chain reorg by resetting its safe head
  • Batch queue must reset cached singular batches derived from the reverted span batch.
• And this reorg must be possible, even if we’re deriving the already finalized blocks. So we have to finalize the L2 blocks when an entire span batch is successfully applied to the chain.
  • To achieve this, the pipeline should pass the signal to indicate whether the current processing singular batch is the last one from the span batch.
  • And the engine queue must consider this signal to schedule the L2 finalization, and to use it for the reorg target block.

[ajsutton]

I commented in #7621 about the atomicity issues being detected here. If we're delaying the update of the finalized block until the end of the span batch I think we should also consider delaying the update of safe head - that's another step towards actually applying span batches atomically. We'd still have changes to the l1 origin and things like batch queue l1Blocks which are hard to roll back though.

Whichever we go technically, I'd encourage having a really strong focus on simplifying things so rather than trying to handle interesting corner cases like span batches being partially applied, we try to find approaches that reduce the number of corner cases and simplify the way we need to reason about the protocol.