feat(block_production): Skip block time when the bouncer capacity has been reached.

[cchudant]

Is there an existing issue?

• I have searched the existing issues

Motivation

As @apoorvsadana pointed out today, starknet mainnet does not have fixed block times, in fact, when demand is high and the block get full faster than the block time, the sequencer won't wait for the full block time to finish and it will produce a block directly.
Example of such a block: https://voyager.online/block/757717

For context, the bouncer capacity is what limits the size of blocks (gas, n_steps and stuff.)

Request

The current way it is implemented in madara is that each block has a fixed block time, and that time is subdivided in "pending block ticks" that have a proportional bouncer capacity (so that the first block tick can only add a few transactions and not fill the entire block.)
I made it that way to mimick ethereum/bitcoin where you can statically compute the size of the chain in the future with good accuracy, as you can't produce blocks faster than that. This is also a good fit for them as it also forces the sync time of new nodes to be bounded with respect to time, and new nodes can't be locked out of following the chain because they don't have good enough hardware.

However, as @apoorvsadana pointed out to me, this is not the case in starknet and other L2s. It's a trade-off, meeting the supply to the demand also makes a lot of sense and probably gives better UX.

We could still implement a minimum block time to get that theoretical bounded size, but arguably, in a non-decentralized single sequencer network:

its a good problem to have i believe, i won’t be surpised if they [starknet mainnet] haven’t added a minimum for now and will solve if there are issues

Solution

We would have to implement a mode
(perhaps enabled by default, i am unsure if anyone would use the earlier mode but i think it's a good chance to make this behavior generic via a trait for example)
where:

• pending block ticks have full bouncer capacity instead of a proportional one
• once bouncer cap is reached during a pending block tick, block time is skipped

I think we should make the loop and select! part of BlockProductionTask::block_production_task generic over the block time stategy. Currently, it's hardcoded to the only strategy we support, as described earlier.

Are you willing to help with this request?

Maybe (please elaborate above)