feat(protocol): support delayed forced inclusion of txs

[dantaik]

The idea is inspired by @cyberhorsey's PR: https://github.com/taikoxyz/taiko-mono/pull/18824/files#diff-bea5dd46ba3d231a238b7c76adc7d09dfa3f8ebd3bf552407f9098492f3ff8f5

The difference:

• Moved forced inclusion related code to two files: TaikoInboxWithForcedTxInclusion and IForcedInclusionStore (impl missing). IPreconfRouter shall now callTaikoInboxWithForcedTxInclusion, not TaikoInbox.

• Forced-inclusion data (txLists) are now in blobs, not writen to storage as bytes

[openzeppelin-code]

feat(protocol): support delayed forced inclusion of txs

Generated at commit: b96c0efb230108c57d1f8e9c7cc1ecd68ddaeaac

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	3 3 0 10 40 56
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[dantaik]

@jeff, I had a call with our friends from Nethermind, here are some feedback/suggestions:

• In the ForcedInclusionStore, we should support using both calldata and a blob to submit their transactions (lets implement the blob support as the first step)
• A request should be processed with a 12*x seconds delay since 1) the time it is saved or 2) the time the previous request is processed or 3) the time the last batch is proposed. which ever is the biggest.

[dantaik]

need a better name

[Brechtpd]

I'm kind of thinking that making the inclusion of these forced transactions "automatic" (as in the preconfer cannot decide easily when they are included) could be problematic for a preconfer. Because the preconfer will not always know in which L1 block its propose transaction will be included, but depending on when that happens, these forced transactions need to be inserted at the right place to be able to give preconfirmations after these are supposed to happen. It does seem to introduce a level of non-determinism that could be quite tricky for a preconfer to fully control easily.

When the preconfer can decide on his own when these transactions actually get included within a window, that seems to make the preconfers job much easier to make things 100% predictable without any tricky boundaries enforced onchai, resulting with a hard deadline on when a propose tx actually needs to be included onchain to not mess with the expected order of the preconfer.

[Brechtpd]

It seems that this is still only callable by the whitelisted preconfers right? If so, would say again that forced inclusion != inclusion. Wrote about that here before: #18815 (comment)

Inclusion can only be guaranteed when block proposing is made permissionless again (at least for the forced blocks, but may as well allow any block to be proposed when that happens because why not).