add call state overrides

[ncitron]

support eth_call state override set as per https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-eth#3-object---state-override-set

[ryanschneider]

Oh nice I just came here to see if this was on your roadmap :)

I've only briefly looked at the code, but I think this could be done by passing the set overrides down to this level, and adding the overrides to the account_map here: https://github.com/a16z/helios/blob/master/execution/src/evm.rs#L53

I have little to no Rust experience but was just setting myself up locally to see if I was on the right track.

[ryanschneider]

Here's a very rough impl of what I mean (go easy on me I'm pretty sure this is the first Rust code I've written): 7b0b303

LMK if you think this is the right track and I'll try to proceed time permitting!

[ncitron]

Yeah this is seems like the right direction to me. One concern I have though is that we cannot pre-fetch all the required state proofs by predicting them with eth_createAccessList since that call does not allow for state overrides. This means that any call with an override that touches lots of state will run very slowly.

I wonder if it is worth it to have this feature given it will run quite slowly?

[ncitron]

Although if we assume the state overrides don't effect the state accesses of the call it will be fine. Unfortunately this is not the case in a major usecase of state overrides where you override an accounts code to create a "phantom" contract and call it.

[ryanschneider]

Maybe just support the per-account state option (and leave stateDiff unsupported)? Since the override would then contain the entire state of said account are proofs even necessary for that account?

[ncitron]

Even limiting it to just that won't prevent the accessed state from radically diverging. Changing any state can cause calls to take unexpected branches which may cause it to call different contracts. The most damaging of these state changes are contract code overrides actually since this causes the execution to change quite a bit generally.

The more I think about it the more it seems like it's not worth the drawbacks, especially considering I don't thing the feature will be heavily used.

Do you have a specific usecase for using state overrides in Helios?

[ryanschneider]

One use case I've seen is where a user has a "view" contract similar to the multicall contract (https://github.com/makerdao/multicall) where for whatever reason they don't want to publish the contract to the chain so instead send the full code as an override for an otherwise unused address. Sorry but I don't think I can give any specifics details.

And yes, I guess in that case the state reads are going to be totally different (since eth_createAccessList will return nothing since the "real" tx is basically sending data to what the chain thinks is an EOA wallet w/o any code).

I fully admit this is probably not a common use case by any stretch, it just one of the corner cases I usually try out when looking at new ethereum clients.

FWIW my guess is that the geth team might be open to adding override support to eth_createAccessList.