eth_call go-ethereum incompatibilities

[rvagg]

We support a 2 parameter version of eth_call, see here:

lotus/node/impl/eth/gas.go

Lines 240 to 241 in 58c1ed8

	func (e *ethGas) EthCall(ctx context.Context, tx ethtypes.EthCall, blkParam ethtypes.EthBlockNumberOrHash) (ethtypes.EthBytes, error) {
	msg, err := tx.ToFilecoinMessage()

Essentially: eth_call(txn, block)

But there's a third argument called "state overrides" that lets you adjust the state prior to the call. This is widely documented, e.g. https://www.quicknode.com/docs/ethereum/eth_call, and I noticed from using cast call that it's failing because it tries to present this third argument.

There's also now, since the last couple of years, a fourth argument you can supply (I believe these two additional arguments are optional) that lets you override even more about the execution point, but this is block focused, like gas. This doesn't seem to be as well documented and I'm not sure Erigon supports this.

https://github.com/ethereum/go-ethereum/blob/35dd84ce2999ecf5ca8ace50a4d1a6abc231c370/internal/ethapi/api.go#L757C58-L757C73

I imagine it would be very difficult to support even some of those "state override" options in our version, but I wonder if we shouldn't at least accept the parameter as optional and error when it tries to supply things we can't do. Then if you're showing up with a {} as a third argument it would be fine. I'm not sure what cast call is trying to do, it might be nontrivial but it would be worth investigating to find what the common path is.

[ameeetgaikwad]

would like to pick this up!

would be just adding the 3rd and 4th args as optional and if they are non empty will throw exception

[rvagg]

Not quite as easy as that unfortunately, because "optional" is not something you can just do in Go here. There's a jsonrpc type that you can receive on the function and then decode that into the various forms - 2, 3, and 4 field forms. Then you need to validate that each of the forms is correct according to what's expected. Once you have that you can proceed to the logic of "are these empty and can I ignore them or do I need to return an unsupported error?".

Have a look through api/api_full.go and at the functions that take jsonrpc.RawParams, they are all doing this. In those you'll find various examples of how this can be achieved.

I'd be happy for you to have a go at this @ameeetgaikwad but unfortunately I may not have a whole lot of time to provide much of a feedback loop at the moment, but I'll try and provide guidance if you want to make a start and run into hurdles of have something to run by me (us).

[ameeetgaikwad]

hey @rvagg alright I can do this.

[rvagg]

Looks like the pressure is off a bit as foundry merged a change that reverts to a 2 arg call if the user doesn't provide explicit overrides: https://github.com/foundry-rs/foundry/releases/tag/v1.2.3
Still would be good to do this for maximal compatibility though.