bug(anvil): arbitrum and anvil block mining inconsistency

[yash-atreya]

          There's a deeper issue with how we handle Arbitrum in anvil, which is causing the `test_arbitrum_fork_block_number` to fail.

On arbitrum env.block.number is l1BlockNumber. See

foundry/crates/evm/core/src/utils.rs

Line 54 in 09824ad

// on arbitrum `block.number` is the L1 block which is included in the

So when we fork off of arbitrum the env.block.number is set to l1BlockNumber that we get from get_block(fork_block_number).

However, upon mining a new block we incrementenv.block.number. See

foundry/crates/anvil/src/eth/backend/mem/mod.rs

Line 1102 in 09824ad

env.block.number = env.block.number.saturating_add(U256::from(1));

.

This BlockEnv is then used in the TransactionExecutor which results in the block being mined with the incorrect block number (i.e l1BlockNumber + 1), instead of fork_block_number + 1.

Fix for this is a bit hacky:

In do_mine_block, for Arb specific chain_id's; temporarily set the env.block.number to storage.best_number (which is being correctly maintained). Use this modified BlockEnv in TransactionExecutor. After tx execution is complete and block is mined. Flip env.block.number back to maintain l1BlockNumber consistency.

@mattsse wdyt?

Originally posted by @yash-atreya in #9151 (comment)