[Epic] Multi-block Blob Support

Problem:

A recent fork of Taiko's contracts added support for including multiple L2 blocks within a single blob. However, our PoC implementation relies on an earlier version before this multi-block support (i.e., we use BlockParams instead of BlockParamsV2).

Supporting multi-block would require reconsideration of design, most notably around preconfirmation slashing. As outlined in our design doc, our current slashing logic (code) works by comparing the txListHash of the preconfirmed block with that of the proposed block. However, with the introduction of multi-block support, the hash of individual proposed blocks is no longer easily accessible on-chain. This is because the Taiko inbox now stores only the blob hash of the entire blob—which contains multiple blocks—along with offset information to introspect the blob.

Potential Solution(s):

• Wait until the L2 tx list is settled in L1, then utilize the settled metadata of the individual L2 blocks for slashing.
• Instead of slashing by comparing the whole tx list hash (or blob hash), we slash by comparing specific bytes within the tx list. E.g., Disputes look like “the preconfer preconfed an L2 block that has txListBytes[42]=0xAB, but the proposed blob had blobBytes[block offset within blob + 42]=0xFF". This would require each preconfirmation to include some commitment (likely KZG?) to the individual L2 blocks.

Read Docs/design-doc.md, TaikoData.sol, and SmartContracts/src/avs/PreconfTaskManager.sol, starting with the current txListHash comparison and the BlockParams versus BlockParamsV2 distinction. The work is done when a multi-block slashing design is selected and its required implementation scope is documented.