fix(anvil): use header.number not best_number

[yash-atreya]

Motivation

Closes #9143

Solution

While applying arb chain specifics in convert_block, we use the self.best_number() to set header.number. This is wrong as best_number keeps increasing as the chain progresses.

Hence, RPC call such as eth_getBlockByNumber would return the incorrect number field.

Note that now header.number and l1BlockNumber in case of Arbitrum will be the same.

[grandizzy]

I think the proper fix would be

            if self.is_fork() {
                // Block number is the best number.
                block.header.number = self.best_number();
            }

and a test for could be

// <https://github.com/foundry-rs/foundry/issues/9143>
#[tokio::test(flavor = "multi_thread")]
async fn test_arbitrum_non_fork_block_number() {
    let (api, _) =
        spawn(NodeConfig::test().with_chain_id(42161u64.into())).await;
    // Mine blocks and check properly returned by `eth_getBlockByNumber` API.
    api.mine_one().await;
    api.mine_one().await;
    let first_block = api.block_by_number(1.into()).await.unwrap().unwrap();
    assert_eq!(1, first_block.header.number);
    let latest_block = api.block_by_number(BlockNumberOrTag::Latest).await.unwrap().unwrap();
    assert_eq!(2, latest_block.header.number);
}

[yash-atreya]

Hmm. Wouldn't that cause the same issue in fork mode?

E.g:
If anvil was forked at X block number and then two blocks were mined i.e self.best_number() == X + 2.

We call eth_getBlockByNumber(X), the resultant block.number field would be X + 2 whereas it should be X.

[yash-atreya]

Am I missing something?

[grandizzy]

hm, I guess you're right, should be the same

[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?

[yash-atreya]

Ignoring test_arbitrum_fork_block_number for now. The solution is a bit hacky and non-trivial. Fixing in a separate PR.

[grandizzy]

This makes sense, would be nice to provide a quick fix for #9152 too so we won't break the other use case