recent anvil --state/dump-state changes are broken

[samlaf]

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 (563e062 2024-03-26T00:16:13.950236000Z)

What command(s) is the bug in?

anvil --state

Operating System

macOS (Apple Silicon)

Describe the bug

There was an upgrade to anvil --load-state/--dump-state/--state flags recently, and now my deploy scripts are broken. I think the main problem is block-header information is now also dumped to the state (verified that it isn't on https://github.com/foundry-rs/foundry/releases/tag/nightly-293fad73670b7b59ca901c7f2105bf7a29165a90 https://github.com/foundry-rs/foundry/releases/tag/nightly-5b7e4cb3c882b28f3c32ba580de27ce7381f415a, so I was probably using a version before this).

Seems like the block-header information is loaded, but in an incorrect way, because the block-number is high, but the blocks are not available other than the genesis block. Here's how to repro:

1. anvil --dump-state state.json
2. in another terminal, cast send 0x3347f1B5fE96332fEb50ec2B6D5fb5fca7997C30 --value 1wei --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
3. close the anvil terminal
4. anvil --load-state state.json
5. in another terminal, cast block-number returns 1, but cast block 1 returns this error

Error: 
block Number(Number(1)) not found

whereas cast block 0 works.

[grandizzy]

this happens because storage hashes are not dumped / reloaded from state file

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

Line 1474 in 9148dbc

BlockNumber::Number(num) => *storage.hashes.get(&U64::from(num))?,

@mattsse would be ok to include them?

le: it will also require persisting blocks which cannot be deserialized out of the box....

[samlaf]

Bump. Still seeing this error which is blocking us from switching to anvil (which we would love to now that the RLP encoding fix has unblocked us):

2024-04-10T05:07:05.562591Z ERROR foundry_evm_core::fork::init: It looks like you're trying to fork from an older block with a non-archive node which is not supported. Please try to change your RPC url to an archive node if the issue persists.
Error: 
Could not instantiate forked environment with fork url: http://localhost:8545

Context:
- Failed to get block for block number: 64
latest block number: 64

[samlaf]

Any updates on this? It looks like it should be a relatively simple fix?

[sambacha]

block 0 is technically the correct number for the genesis block

any update @mattsse

[mattsse]

It looks like it should be a relatively simple fix?

what's the fix here?

blocks are not exported, just the state, should they be included?

[samlaf]

@mattsse was just carelessly saying.. my bad; I have never actually dived into the anvil codebase.
Just assumed this was "simple" from https://x.com/gakonst/status/1775266582966788549

We have all this info and dumping more stuff is a simple job, just didn't know what people need!

So was assuming you guys would soon be able to dump the block info as well as events (see my other #5906 )

But not sure why @grandizzy was saying blocks can't be deserialized out of the box?

[mattsse]

I guess we should consider dumping all blocks as well?

should be possible, and yes "just didn't know what people need!"

[dalechyn]

Assuming this to be an issue in my case as well.

My goal is to have a persisted anvil setup to be served along with Otterscan, basically creating a persisted on-premise testnet.

On the first launch, when there is no state to load, everything works fine, but after the restart, transaction history (and the block history) can't be loaded. In the image attached below you can see an account having a non-10,000 ETH balance (since it broadcasted some transactions, but they never loaded).

Assuming that if this issue gets fixed, Otterscan would be able to read block data properly.

[dalechyn]

@mattsse, friendly bump 👉💙

[samlaf]

@mattsse opened a PR with something working. Let me know what you think.