Reason behind incompatibility with Updated Go (v1.23) and Geth (v1.14.11), ERROR: Function Selector Not Recognized on Hardhat[2.11.1]

[Yashk767]

For my go project which is a go client to interact with contracts, after upgrading the Go version from 1.21 to 1.23 and the Geth version from v1.12.2 to v1.14.11, I encountered an issue when making contract calls on locally deployed contracts using Hardhat. Specifically, I received the following error message for all contract calls:

Error: Transaction reverted: function selector was not recognized and there's no fallback nor receive function

This issue only occurs when interacting with contracts deployed on Hardhat and not on other testnets. I use ABIs installed in npm modules, which are then used by the Go client to generate bindings via abigen.

Initially, I was using Hardhat version ^2.11.1 for my contracts.
However, after updating Hardhat to version 2.22.17, the issue was resolved, and I was able to make successful contract calls. This suggests that there might be an incompatibility between the older version of Hardhat and the newer versions of Geth and Go.

Steps to Reproduce:

Deploy contracts on Hardhat using version ^2.11.1.

Upgrade Go to v1.23 and Geth to v1.14.11.

Use the Go client to generate bindings using abigen with ABIs fetched from npm modules.

Attempt to make contract calls using the Go client.

Observe the error related to function selector recognition.

Context:

The issue seems to be related to changes in ABI encoding/decoding or EVM behaviour between versions. It would be helpful if Hardhat provided compatibility updates or documentation regarding such changes for users upgrading their Go or Geth versions.

What exactly is the issue, and what are the changes expected to make contract calls successful with the newer versions of Go and Geth? Any insights or documentation updates would be highly appreciated.

[fvictorio]

Hey @Yashk767, I don't know (nor I can even guess) why you got that error when upgrading geth.

But I guess your underlying question is how the compatibility between Hardhat and geth looks like. I'll answer this and hopefully that explains why the problem you got is hard to explain if the only thing that changed was the geth version.

One part of the compatibility is the JSON-RPC layer. This is normally the biggest source of problems and confusion. Now and then geth will change or remove some property of the JSON-RPC objects, which will cause issues with Hardhat. We normally fix those quickly, and just upgrading Hardhat fixes the problem. (And usually we fix it in a backwards-compatible way, meaning that using the new version of Hardhat with older versions of geth should work fine.)

Another part of the compatibility is the supported hardforks and the default one that is used. This is usually even less important, unless you are using features from the latest hardfork, in which case you would need to upgrade both hardhat and geth (or only one, depending which one you are using as client and which one as node).

So you can see why the error you got is strange. That error means that a transaction reverted because you, for example, send a call to a foo() function but that function doesn't exist. This happens at the solidity/ABI level, so it's unlikely to be related to either JSON-RPC or hardfork changes.

[fvictorio]

Ok, I wrote that comment and then I realized the possible reason.

When making a call, the JSON-RPC layer used to use the data field, but at some point the geth client moved to using the input field (or the other way around, I never remember which one is which). Previous versions of Hardhat only accepted one of these. So when you upgraded geth, the calldata became effectively empty (because it was being sent in a non-recognized field) and you got that error. When you upgraded Hardhat to a version that accepts either field, the problem went away.

That's my theory anyway. So yeah, the answer to the compatibility question is: we try to respect the JSON-RPC spec, but also to play well with geth (or any client) when that's compatible with the spec. Normally just using the latest version of Hardhat should be fine.

[Yashk767]

Thanks for the response. @fvictorio

Do you mean when the Geth upgrade happened, the JSON-RPC layer started using a field (data or input) that the older Hardhat version didn’t recognize.
This resulted in the contract calls being sent without the expected calldata, making the contract think that it was being called without any specific function or parameters. Hence, it caused the error function selector was not recognized.

And the updated version of Hardhat was able to recognize both the data and input fields, or it made an adjustment to handle the field change made by Geth. [Is this correct that the latest hardhat version supports this?].

And to verify whether the underlying cause was indeed due to a change in the JSON-RPC specification that Geth implemented (such as moving from using data to input fields), I need to check the geth release changes, Will check on this.

[fvictorio]

Is this correct that the latest hardhat version supports this?

Yes