Lazy Aggregator: remaining transactions in mempool

[S1nus]

When in lazy mode, centralized aggregators will build a block 1 second after transactions become available in the mempool. If transactions remain in the mempool after block-building is complete, those transactions will sit there until mempool.TxsAvailable is triggered again, by an incoming transaction.

Previously, Executor would notify BlockManager if transactions remained after building a block, however that was removed to reduce complexity.

If this becomes an annoyance, refer to this issue when restoring the fix.

[Manav-Aggarwal]

cc: @S1nus

[S1nus]

After the 1 second timer in lazy sequencing, transactions remaining in the mempool will stay pending in there until the lazy sequencer is awakened by a new transaction from a user. One solution is for the Executor to signal the BlockManager to make and publish another block, if transactions remain in the pool after building the block.

Create a channel in the Manager, pass it into NewBlockExecutor. Have the Executor signal the channel if transactions remain in the mempool following ReapMaxBytesMaxGas, and immediately build another block.

However, this issue will only arise if the rollup is lazy-sequenced, and simultaneously busy enough for lots of transactions to arrive in the 1 second window, but not busy enough for inflow of transactions to keep the pipes clean. It doesn't seem to be a likely scenario, so one option is to leave it be unless it becomes a problem in production.

[tuxcanfly]

After the 1 second timer in lazy sequencing, transactions remaining in the mempool will stay pending in there until the lazy sequencer is awakened by a new transaction from a user. One solution is for the Executor to signal the BlockManager to make and publish another block, if transactions remain in the pool after building the block.

Create a channel in the Manager, pass it into NewBlockExecutor. Have the Executor signal the channel if transactions remain in the mempool following ReapMaxBytesMaxGas, and immediately build another block.

However, this issue will only arise if the rollup is lazy-sequenced, and simultaneously busy enough for lots of transactions to arrive in the 1 second window, but not busy enough for inflow of transactions to keep the pipes clean. It doesn't seem to be a likely scenario, so one option is to leave it be unless it becomes a problem in production.

#1800 refactors the window to be 10% of the block time and maybe be configurable in the future so the 1 second is not hard coded any more. The remaining edge case is an optimization that can be revisited in the future, closing for now.