Add deal support in testActions

[Rubilmax]

Include the deal utility to viem's built-in testActions in order to ease viem-based test developments for setStorageAt-compatible networks

deal is heavily inspired by foundry's deal cheatcode: it allows to deal any amount of most ERC20 tokens to any account on the test network, which avoids having to impersonate whales (because whale A may not be a whale anymore when the fork's block number is changed later in time - and it happens a lot throughout a software lifetime)

Important

I am the developer & maintainer of viem-deal

[jxom]

Looks great! I will accept a PR for this.

[jxom]

What is the perf impact of not having it? Wouldn’t Anvil be nearly instantaneous for storage slot access over a local network?

[Rubilmax]

It depends on the configuration of the runtime environment because anvil caches RPC queries

So having RPC cache + storage slot cache makes it instantaneous

Having RPC cache but no storage slot cache takes 20ms for most tokens and up to 100ms for complex tokens where the storage slot is at index 50 (e.g. aave tokens)

Having no RPC cache but storage slot cache takes the time of an RPC call and it's ok imo because the environment has no RPC cache anyway

Having no RPC cache and no storage slot cache is obv the slowest, and it's ok imo because it only happens the first time

Case 2 would be the most common case if there is no storage slot cache, so the answer to your question is 20-100ms as measured with vitest. For tests where you deal multiple times, I do think it's worth having a storage slot cache. What's the downside of storing it at the same place as foundry's cache?

[jxom]

the answer to your question is 20-100ms as measured with vitest

This seems like an acceptable startup time with no warmed cache.

I am open to introducing an abstraction for FS caching, but if the optimization is just to cut 20-100ms from initial setup, then I don't think it's really worth it? IMO, the in-memory cache (for storage slot access post-setup) should suffice for this use-case.

[roninjin10]

@Rubilmax I looked at your implementation out of curiousity. Is the slowness you are worried about mostly because it's finding the storage slot via trial and error?

If so what do you think about finding the storage slot instead via requesting an access list while doing a balanceOf call? That should get you the storage slot in a single request.

[Rubilmax]

Right, I didn't think about an in-memory cache so I was thinking about 20-100ms at every deal. I agree it's ok to have this delay at the first only, using an in-memory cache such as the LRU map you suggested @jxom

Very interesting idea @roninjin10 , I'll add this to the issue on foundry!

[roninjin10]

+1 to adding this would like this to get inherited by tevm

[jxom]

Maybe this is worth upstreaming in Anvil itself too: foundry-rs/foundry#8956

[roninjin10]

If it ends up in anvil instead I will still happily take the js action in Tevm. Let me know if you want contribution credit for it in that case otherwise I’ll just copy paste the implementation

[Rubilmax]

Best would indeed to have it included in anvil. I'll push for this