You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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):
txListBytes[42]=0xAB
, but the proposed blob hadblobBytes[block offset within blob + 42]=0xFF
". This would require each preconfirmation to include some commitment (likely KZG?) to the individual L2 blocks.The text was updated successfully, but these errors were encountered: