DAWN-491 ⁃ Block Production Time is Unbounded, needs to be Time Bounded

[bytemaster]

The current block production algorithm operates without any consideration to the time it takes to process a block. A block producer has about 300 ms to produce a block so that it can relay via 6 degrees of P2P network processing and get to the next block in time (allowing for 1.2 seconds of network propagation time).

This constraint will naturally limit the real-time throughput to a fraction of what a node would be capable of.

This should probably be configurable by the block producer so we can experiment and adjust as necessary.

[wanderingbort]

notes from discussion

scheduler needs to limit the amount of transactions it will schedule when considering "time"
best case message time: 20 usec
scheduler should cut off at ~300ms per thread given "best case" time for a message

chain_controller::generate_block should then use wall clock to time the application of the produced schedule and return any overages to the pending transactions.

[bytemaster]

This issue ultimately reveals a bigger design change in how transactions are scheduled and blocks are produced:

1. transactions need to be scheduled as they are received, eg we should have a "pending block" rather than a "pending transactions list".

2. In the future pending transactions will also have to execute in parallel as they come in or we will be unable to build blocks fast enough even if we can execute on 1000 threads once built.

3. For developer testing purposes people will not be pushing the limits of their own network so this issue can be postponed until a better scheduling design can be finalized.

[blockone-syncclient]

➤ Dhanesh Valappil commented:

Pls can you add the ATC for it?