CheatCalls and Mempool

[stuparm]

Hey, I really like the addition of mempool configuration in the cheat_mining_mode method! I've noticed a demand for supporting multiple transactions per block and for mining new blocks at specified intervals.

Do you think having a 'number of transactions per block' setting as a mining option would be useful? I believe Uniswap might cache parameters at the block level, so they would need to know when a block will be constructed. They might be able to achieve this with cheat_mine(), but that leads to different behavior depending on whether automine is enabled or not, as evm_mine() mines an empty block when automine is off.

I also like the cheat_setBlockGasLimit, which could serve as a configuration parameter for the mempool to better mimic real network behavior. When automining is enabled, it effectively sets a cap on "how expensive a single transaction can be."

[stuparm]

One more thing that came to mind regarding mempools is the presence of the "nonce." I noticed you’ve defined the ordering with:

type MiningOrdering =
  | "fees" // default
  | "fifo";

What do you think about replacing "fees" with a term that reflects a nonce+fees rule, to better represent real network behavior? I just don't have the right naming :)

[krzkaczor]

@stuparm I really like the idea of mining next block based on the number of transactions in the mempool. It could be called "threshold":

threshold - mine new blocks when the mempool reaches a specified transaction count

However, this behaviour could be achieved with manual mining mode. I would approach this in the way that if we have more support for this feature we add it to EIP but for now I would avoid making the proposal even more complex if something can be already achieved using already existing features.

Also I just realized that mempool is missing any form of introspection. Perhaps NodeInfo should return mempool info (for example as part of mining mode for modes that support mempools).