Flashblocks BlockBuildingAlgorithm

[liamaharon]

A new BlockBuildingAlgorithm implementation is required for Flashblocks.

The idea is a timing config can be specified with the millis since last block it should "checkpoint". Checkpointing means to cache the orders at that point in time, and always use those orders as the head of the block when suggesting future blocks.

e.g. timings set to [250, 500, 750, 950] should result in:

• While building block N
  • Between 0 - 250ms since block N-1, build_blocks produces and returns empty blocks
  • The first build_blocks call 250 - 500ms since block N-1 produces, caches, and returns f1 (Flashblock 1) using the existing simple gas price ordering algorithm.
  • Subsequent build_blocks calls 250 - 500ms since block N-1 returns f1.
  • The first build_blocks call 500 - 750ms since block N-1 produces, caches, and returns f2 (Flashblock 2) using the existing simple gas price ordering algorithm.
  • Subsequent build_blocks calls 500 - 750ms since block N-1 returns f2.
  • The first build_blocks call 750 - 900ms since block N-1 produces, caches, and returns f3 (Flashblock 3) using the existing simple gas price ordering algorithm.
  • Subsequent build_blocks calls 750 - 950ms since block N-1 returns f3.
  • The first build_blocks call 900 - ∞ms since block N-1 produces, caches, and returns f4 (Flashblock 4) using the existing simple gas price ordering algorithm.
  • Subsequent build_blocks calls 950 - ∞ms since block N-1 returns f4.

Notes

• It should probably be a wrapper around an existing BlockBuildingAlgorithm implementation, like one that simply orders by gas price.
• Flexible Flashblock counts and intervals per block

[minnoise]

Hi had some questions about these steps, wanted to give some scenarios and clarify my undestanding.

Between 0 - 250ms since block N-1, build_blocks produces and returns empty blocks

So the very first time build_blocks is called will fall into this bucket?

Also does returns empty blocks refer to build_block, which returns Result<Box<dyn BlockBuildingHelper>>, instead of build_blocks, which has no return value? Is the intention to eventually call input.sink.new_block?

The first build_blocks call 250 - 500ms since block N-1 produces, caches, and returns f1 (Flashblock 1) using the existing simple gas price ordering algorithm.

Say another call to build_blocks happens at 251 ms, so it falls into this bucket. We can call OrderingBuildingAlgorithm::build_blocks, which will end up calling input.sink.new_block? We cache f1 by caching the BlockBuildingHelperFromProvider that was created.

Subsequent build_blocks calls 250 - 500ms since block N-1 returns f1.

Another call to build_blocks happens at 252 ms, so it falls into this bucket. It saves these SimulatedOrders for later. Not sure how to return f1 as noted earlier.

The first build_blocks call 500 - 750ms since block N-1 produces, caches, and returns f2 (Flashblock 2) using the existing simple gas price ordering algorithm.

Another call to build_blocks happens at 501 ms, so it falls into this bucket. We add SimulatedOrders from the prior build_blocks call at 252ms to this current call's SimulatedOrders, and call OrderingBuildingAlgorithm::build_blocks.

Subsequent build_blocks calls 500 - 750ms since block N-1 returns f2.

Another call to build_blocks happens at 502 ms, so it falls into this bucket. It saves these SimulatedOrders for later. What happens if this is the last call to build_blocks, are these SimulatedOrders never submitted? Or are we guanteed a final build_blocks call post 950ms?

Thanks!