go-ethereum v1.13.0 changed "eth_call" to take data in the "input" field rather than the "data" field

[zomglings]

Expected behaviour

Programs which make JSONRPC eth_call requests should not have to worry about the version of the client they are connecting to as long as it accepts "jsonrpc": "2.0" requests.

Actual behaviour

If the client is on tag v1.12.2, then the eth_call parameters must specify the view call using the "data" field. If the client is on tag v1.13.0 or higher, then they must instead use the "input" field.

This is not backwards compatible in any way shape or form, and the only way to understand what request schema to use is to inspect web3_clientVersion.

Steps to reproduce the behaviour

Run two go-ethereum nodes, one at v1.12.2 and the other at v1.13.0. Deploy a contract with a view method. Construct a JSONRPC API eth_call request for that method. The request that works for v1.12.2 clients will not work for v1.13.0 clients.

Note

Incidentally, I suspect most clients would be ok with both fields being passed.

[karalabe]

Geth AFAIK accepts both input or data. The spec was changed 6 years ago to be input vs. the old data.

[karalabe]

I'm not aware of anything changing on the server side wrt not accepting one name or another. AFAIK only ethclient was changed to start doing calls with input instead of data

[ntauth]

Following, it's honestly ridiculous, this breaks compatibility with other EVM chains like BESU

[karalabe]

Why do you feel Geth is at fault for implementing the spec, and not Besu for not implementing the spec?

[fjl]

@zomglings can you please provide some information about your usage of the API, i.e. how did you discover this issue. We are very confident Geth still supports the data field for calls. We did make a change on the client side (ethclient) though. Please let us know more details.

[holiman]

This ticket is obviously based on a misunderstanding. I'll just close it

[zomglings]

Hi guys, I apologize for my delayed response - I don't receive GitHub notifications for some reason.

My issue isn't based on a misunderstanding. At least I do not think it is. It's not obvious to me what my misunderstanding is, so I would appreciate clarification on that point @holiman

This is my interpretation of what happened:

1. The geth change implicitly reflected a change to the specification of the JSONRPC API.
2. Since the implicit specification change to the JSONRPC API didn't come with an associated change to the version number, the treatment of eth_call now becomes unspecified behavior in general client implementations.

In my case, it broke my tooling when interacting with a client for a Polygon rollup that was using an old version of the OP stack.

Now you can say this isn't geth's problem because its eth_call implementation handles all cases correctly.

But whoever is maintaining the JSONRPC API specification should take responsibility for this. It could be handled by simple increasing the "jsonrpc" version number from "2.0" to "2.1" or something.

My understanding is that the geth implementation becomes the JSONRPC API specification. This is why I filed the issue against go-ethereum.

If my misunderstanding is that I filed the issue in the wrong place, then I apologize and I would appreciate a pointer to the right place to file this issue. Because whether or not it is an issue for geth it is certainly an issue for the Ethereum ecosystem.

If there is not misunderstanding, then let us continue the conversation here. I will set a reminder to poll this thread once a week so that I don't miss notifications.

[fjl]

You still haven't answered the question. Are you using the go-ethereum RPC client, and the ethclient package?

[zomglings]

You still haven't answered the question. Are you using the go-ethereum RPC client, and the ethclient package?

Yes, this is my import:

	"github.com/ethereum/go-ethereum/ethclient"

This is how I create the client:

	client, err := ethclient.Dial(rpcURL)

Pinning to this version of go-ethereum fixed my issues (from my go.mod file):

	github.com/ethereum/go-ethereum v1.12.2

[fjl]

Thank you! And which server software are you communicating to? A Polygon node?

[zomglings]

Thank you! And which server software are you communicating to? A Polygon node?

It rolls up to Polygon, but the rollup itself uses the Optimism stack, but I am not sure of the version details.

It might help if I make a terminal recording demonstrating the issue, I'll do so tonight.

[zomglings]

@fjl : Demonstration of the issue - the eth_call call works with go-ethereum 1.12.2 and doesn't work with go-ethereum 1.13.5:

[jaspeen]

Tron still supports only "data" - https://developers.tron.network/reference/eth_call

[zomglings]

By the way, I can now reproduce this using the anvil tool that comes with Foundry.

This is the error message I get:

unknown field `input`, expected one of `from`, `to`, `gasPrice`, `maxFeePerGas`, `maxPriorityFeePerGas`, `gas`, `value`, `data`, `nonce`, `chainId`, `accessList`, `type`

This is my anvil version:

$ anvil --version
anvil 0.1.0 (c331b5e 2023-05-19T22:28:03.499558780Z)

I feel as if this issue has been closed prematurely, is there any way to appeal the closure or should I create a new issue? There is a genuine problem here for sure with ethclient.

[namiloh]

So, the issue here is not 'geth' in the sense of an api provided by geth. The issue seems to be when people use ethclient against non-mainnet / non-ethereum backends.

[namiloh]

We should ping these non-updated backends and ask them to update

[fjl]

It was fixed in Foundry here: foundry-rs/foundry#5918