Read call on forked chain times out

[eyezick]

Environment information

• Operating System: macOS Sonoma 14.1
• Supersim Version: Commit

Foundry version.
forge 0.3.0 (5a8bd89 2024-12-20T08:45:53.204298000Z)

Describe the bug
Large read calls on forked OP Mainnet time out consistently. Simpler calls to the same contract return data successfully.

Steps to reproduce

0. Setup docker per README.
1. Create env file in same directory per below and add with your own OP mainnet RPC SUPERSIM_RPC_URL_OP=https://....
2. Run docker with config

docker run --rm -it -p 4444:4444 --env-file my-rpc.env supersim:latest fork  --l2.host=0.0.0.0 --l2.starting.port=4444 --chains=op,mode

3. Observe console output confirming RPC override detected rpc override name=op
4. Make calls.

% cast call 0x7F6D3A4c8a1111DDbFe282794f4D608aB7Cb23A2 "MAX_TOKENS()(uint256)" --rpc-url http://localhost:4444                                                                           
2000
% cast call 0x7F6D3A4c8a1111DDbFe282794f4D608aB7Cb23A2 "tokens(uint256,uint256,address,address[])" 1000 0 0x0000000000000000000000000000000000000000 "[]"  --rpc-url http://localhost:4444
Error: error sending request for url (http://localhost:4444/)

Context:
- Error #0: error sending request for url (http://localhost:4444/)
- Error #1: operation timed out

Comments
I was able further to repro this on our web app, where the same call hangs indefinitely. Wanted to note that the private RPC var I'm using is the same that we use on our web app so it already handles these size calls in dev/production so it should be able to handle them when used with supersim.
Ref link for function

[fainashalts]

Seems like the same issue as #338 - @hamdiallam @jakim929 should we combine these or are they different?

[hamdiallam]

ahh yea same issue! I'll close mine in favor of this

[jakim929]

Anvil is making lots (~2000) of eth_storageAt calls to the underlying RPC in fork mode when doing the get_all_tokens call (before it times out, likely uses more). Because these eth_storageAt are called sequentially as part of the evm execution, it's probably very difficult to parallelize. Even at 100ms per call would take 200s.

Just tested that it fails by using anvil directly in fork mode, so the issue probably isn’t the supersim layer either.

This is hard to fix just based on how local node forking works. Even if we proxy directly to the RPC instead of running the evm execution locally, we would have to "refork" otherwise the local state will be outdated on later calls/writes.

I think this is a hard to solve problem in a generalizable way - I remember @roninjin10 had the idea of doing symbolic execution on the EVM for https://tevm.sh/ which would help with the average (not worst case) scenario by allowing parallelized fetches for storage instead of the "waterfall" type of way it currently happens. Something like this will likely need to be built into the local node implementation directly (anvil)

[roninjin10]

For practical advice to workaround this:

You do batches of balanceOf calls to the contracts so anvil caches all this storage first

[eyezick]

@jakim929 thanks for looking into this! 🙏

Our usecase is to use fork mode for FE e2e. Is your suggestion for us to make underlying calls to all the contracts first for caching or is some other kind of Supersim abstraction possible?

[fainashalts]

@eyezick if you can proceed with the approach mentioned by @roninjin10 that is the fastest way to get this done. I'm giving some thought to how we may be able to add supersim abstractions to help but @jakim929 is right this is not an easily generalizable solution (though I think the FE e2e testing problem is an important and common one!). I don't have a timeline on a fix but will update here when there's more progress.