bug(anvil): inconsistencies in Arbitrum forked anvil instance

[meetmangukiya]

Component

Anvil

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (9444c62 2024-07-26T00:22:19.243928000Z)

What command(s) is the bug in?

No response

Operating System

None

Describe the bug

1. Block's constructed on forked arbitrum constructs on L1BlockNumber.
2. Any block specific queries(cast --block) made are compared with the l2 block number to check if the block predates the fork block(as it should IMO).
3. If you run a cast run <tx> on a tx mined on anvil, it will use tx's block number's parent block number to query the state, but that block number will be L1BlockNumber, so it'll predate the fork, even though it is not. It is not querying the correct state.

# launch a forked anvil
$ anvil --fork-url https://arb1.arbitrum.io/rpc

# check the latest block number
$ cast block | grep number
<this is the l2 block number>

# mine a new block
$ cast rpc evm_mine

# check the latest block number now
$ cast block | grep number
<this is forked block's `L1BlockNumber` + 1>

I think the correct fix is all new blocks that get mined on anvil should mine off the fork l2 block number, any historical state queries should also compare l2 block number to determine if the queried block is before or after fork.

For new blocks, it needs to be determined what the L1BlockNumber should be? Should it also increment by 1 everytime? Should it stay the same? Maybe make it a function of time since forkBlockTimestamp and then make it a function of forkBlockL1BlockNumber + (elapsedTime / 12).

[meetmangukiya]

I think the workaround for now is you explicitly specify the chain id to a non-arbitrum chain id so the l1BlockNumber specific logic doesn't trigger

[grandizzy]

#7360 fixed the issue for eth_blockNumber by returning best number but not for eth_getBlockByNumber