feat(protocol): router based forced tx inclusion

[cyberhorsey]

offchain, in the gateway itself, we can:
in the gateway itself, we can:

1. add listeners for the events
2. call forcedTxList = preconfRouter.forcedTxLists[keccak256(event.txList)]
3. check forcedTxList.included
4. if !forcedTxList.included, propose a batch with that txList immediately to get it out of the way

if that isnt done, anyone can propose the block after inclusionWindow passes. TaikoInbox remains untouched.

Needs some more tests, and some are failing, but please look over @dantaik @AnshuJalan @davidtaikocha

[openzeppelin-code]

feat(protocol): router based forced tx inclusion

Generated at commit: 0c990b83b37878ecc364fb9218563a6a0a5c6f9d

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	3 3 0 10 41 57
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]

I really like the idea that forced inclusion of transactions/blocks are done out of the core protocol code. I would suggest to have this inheriting relationship:

TaikoInbox -> TaikoInboxWithForcedInclusion -> MainnetInbox

Then move all forced inclusion logics into TaikoInboxWithForcedInclusion and leave the router unchanged. TaikoInboxWithForcedInclusion shall always check if there is one inclusion request due, if so, it calls proposeBatch twice with the first one being the forced inclusion block. Forced inclusion shall be transparent to both TaikoInbox and the router.

[dantaik]

forcedTxLists[forcedTxListHash].txList is not used. I'm not sure we can simply replace _batchTxList with forcedTxLists[forcedTxListHash].txList, you will also need to construct a batchParams as:

BatchParams memory params;
params.blocks = new BlockParams[](1);
params.blocks[0].numTransactions = some_constant.

[dantaik]

Basically you need to call ITaikoInbox(taikoInbox).proposeBatch twice, one for the forced batch, the other one for the normal batch. The first batch always have 1 block with MAX_FORCED_TRANSACTIONS txs.

[cyberhorsey]

The idea if that you would call this with its own batch, and _batchTxList is forcedTxLists[forcedTxListHash].txList. It is gas inefficient and will likely never be used, since we don't plan on censoring any user's transactions, but it keeps it very simple.

This function is etiher called by the preconfing gateway, with it's own batch, and is profitable because of the priorityFee reward, or by the user themselves, and either way the input _batchTxList is indeed the forcedTxList, because forcedTxListHash is a hash of _batchTxList.

Does this propose a problem?

[dantaik]

Suggested change

	require(msg.value >= requiredStake, InsufficientStakeAmount());
	require(msg.value == requiredStake, InsufficientStakeAmount());

[dantaik]

Otherwise, please send back the overpaid fee.

[cyberhorsey]

will add

[dantaik]

how about priorityFee

[cyberhorsey]

yeah that's maybe a better name

[dantaik]

the preconfer can always use "false" for force, so we are not forcing?

[dantaik]

Maybe we can try to query if there is a forced txs request due, if so, force will be automatically true.

[cyberhorsey]

force is there so that a non preconfer can call this function with force = true, and then it will check the forced block inclusion. That way, the user doesn't rely on a preconfer to include it, nor does it block preconfer from proposing.

[dantaik]

But this will ruin the preconfirmation - the preconfer may already shard some shared blocks before they are proposed on L1, now suddenly a user kicks in with a block which will reorg the chain.