feat(protocol): add preconfirmation support [helder]

[Brechtpd]

For now these changes are only to support the upcoming preconfirmation testnet!

• Implement feat(protocol): Longer term predictability of block parameters (for fast tx confirmation) #14793
• Add support for proposer selection mechanisms through ISequencerRegistry. Currently the testnet needs some very simple whitelisting implementation, this will be replaced when the actual registry can be used.

Tried to minimize changes with how ISequencerRegistry is implemented using a callback inside the propose function, otherwise I would probably add an additional contract in front of TaikoL1 but that seems like a bigger change for multiple reasons.

Untested.

[openzeppelin-code]

feat(protocol): add preconfirmation support [helder]

Generated at commit: 915f88852aea88e828a94181b07148dd9c753f28

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 2 0 8 42 54
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]

Brecht, my understanding is that if we have two preconfers on slot 5 and 31, only the first perconfer can propose blocks in slot 0 to slot 5, and only the second preconfer can propose block in slot 6 to 31 (this is Justin's original proposal I believe). The l1StateBlockNumber in your PR is to help these preconfers to propose blocks with new restrictions so that L2 blocks proposed by a preconfer will not be included in other out-of-range L1 blocks unexpected.

In the implementation of isEligibleSigner, should we also check if the msg.sender can propose block for block.number % 32?

[Brechtpd]

Two more changes in latest version:

• Also allow the L2 block's timestamp to be chosen by the proposer with similar constraints as the l1StateBlockNumber. This is to solve potential problems if there are missed slots which made the previous calculation not deterministic (thanks gd for noticing this!)
• Saw that the difficulty calculation still contained a dependency on block.number which also made it not deterministic. It is calculated like this: difficulty = keccak256(abi.encodePacked(blockhash(params.l1StateBlockNumber), b.numBlocks));

@davidtaikocha @dantaik @YoGhurt111

[adaki2004]

I tend to think, it might be better like this below if we wanna support calldata efficiently.

        if(txLists.length != 0) {
            require(params.length == _txLists.length, "mismatched params length"));
        }

So currently protocol can handle both, but with the above change, we would have to create empty _txLists -matched to the length of _params, even if we use blob OR some empty if we use blob + calldata both, separately, paralel with one L1 TXN.

I dont think it is practical to use different data avail. layer for multiple L2 blocks but one L1 TXN. (Maybe i'm wrong in here, and in this case inefficiency is i guess negligible).