bug(anvil): contract call extremely slow after anvil_reset on a fork hangs
#7966
Comments
cstoneham
changed the title
|
seeing this too |
|
+1. very annoying plz fix |
|
cc @mattsse |
|
checking, sorry about the delay |
|
this is indepent of the anvil_reset call? could you perhaps point me to the contract code? |
|
I'm wondering if Anvil is clearing the local cache of fetched upstream storage slots when reset is called? |
|
it does, because after reset this is no longer useful, but the fetched storage for the old height is cached on disk and the new height is initialized with the corresponding cache file for that block if it exists. |
|
it's definitely a heavy call but if you make an RPC call directly at this block height it's quite fast I would've thought that the fork call would effectively be proxying that rpc call locally and then caching it async - though I'm not super familiar with how anvil forks work under the hood. thanks for looking into this btw! |
|
the way forked evm works is it translates database calls that the evm issues (storage, code, account) into rpc calls, like most expensive ones are accounts because this requires 3 calls balance,code,nonce but fetched data is cached based on chain height, so if the same slot/account is requested again it no longer requires an rpc |
|
Ok, I wrote a little test to understand what's going on. I put together a simple node.js json-rpc proxy that would log out any proxied requests. (I can attach the proxy.js to a gist, etc if needed - but it's nothing special - just a simple logging http proxy). My setup was as follows: Below is what I observed:
# listens on localhost:3000 - and forwards requests to https://eth.llamarpc.com
node proxy.js
rm -rf ~/.foundry/cache;
# anvil listening on localhost:8545
anvil --fork-url=http://localhost:3000 --fork-block-number 20013538The proxy logs:
curl -X POST --header "Content-Type: application/json" --data '{
"jsonrpc": "2.0",
"method": "eth_call",
"params": [
{
"to": "0xC02aaA39b223FE8D0A0e5C4F27ead9083C756Cc2",
"data": "0x95d89b41"
},
"latest"
],
"id": 1
}' http://localhost:8545The proxy logs: This output is expected, as it's our first
curl -X POST --header "Content-Type: application/json" --data '{
"jsonrpc": "2.0",
"method": "eth_call",
"params": [
{
"to": "0xC02aaA39b223FE8D0A0e5C4F27ead9083C756Cc2",
"data": "0x95d89b41"
},
"latest"
],
"id": 1
}' http://localhost:8545The proxy did not log any requests - cache is working as expected!
curl -X POST --header "Content-Type: application/json" --data '{
"jsonrpc": "2.0",
"method": "anvil_reset",
"params": [{ "forking": { "jsonRpcUrl": "http://localhost:3000", "blockNumber": "20013538" } } ],
"id": 1
}' http://localhost:8545The proxy logs:
curl -X POST --header "Content-Type: application/json" --data '{
"jsonrpc": "2.0",
"method": "eth_call",
"params": [
{
"to": "0xC02aaA39b223FE8D0A0e5C4F27ead9083C756Cc2",
"data": "0x95d89b41"
},
"latest"
],
"id": 1
}' http://localhost:8545The proxy logs: I would expect that resetting a forked Anvil server to the same rpc endpoint and block number that was used to originally launch the fork, Anvil would continue to used the cached data fetched before calling I'm using Anvil as part of a test harness that forks a upstream server when testing a sdk. Each integration test involves a little setup and modifies state - so I call |
|
I think that's how hardhat works actually, they cache the state in a directory as JSON files. +1 that it would be amazing if we could get the same caching w/Anvil. I'm in a similar position as @mjpowersjr where I'm building out a test environment w/Anvil so the performance wins would be greatly appreciated. |
zerosnacks
changed the title
anvil): contract call extremely slow after anvil_reset on a fork hangs
|
@mjpowersjr @cstoneham can't you use |
|
afaict and from local testing, This seems like a big differentiator between anvil and hardhat. Is this on the roadmap at this point? |
Component
Anvil
Have you ensured that all of these are up to date?
What version of Foundry are you on?
forge 0.2.0 (a4d79ac 2024-05-10T00:18:07.559888000Z)
What command(s) is the bug in?
cast rpc
Operating System
macOS (Apple Silicon)
Describe the bug
After resetting a forked network to a given block, the next call to a contract fails (but after this it will succeed).
Steps to Repro:
anvil_reset:The text was updated successfully, but these errors were encountered: