Breaking Change to eth_call Behaviour In 1.10.7

[nlordell]

System information

Geth version: 1.10.7
OS & Version: Windows/Linux/OSX

Expected behaviour

With the release of 1.10.7 which includes #23303, the behaviour of eth_call has changed in non-backwards compatible ways.

Specifically, it was previously possible to use eth_call with a from address that was an account with code. This was useful to simulate a transaction sent from that contract, for example simulating a transaction from a SC wallet. This appears to no longer be possible.

Steps to reproduce the behaviour

Perform an eth_call where the from address is an account with code:

{"jsonrpc":"2.0","method":"eth_call","params":[{"from":"$CONTRACT_ADDRESS","other":"parameters..."},"latest"],"id":0}

And receive an error response:

{"jsonrpc":"2.0","id":0,"error":{"code":-32000,"message":"err: sender not an eoa: address $CONTRACT_ADDRESS, codehash: ... (supplied gas ...)"}}

[rmeissner]

Same limitation started to apply to the eth_estimateGas rpc, which was not the case before (and is not the case for other nodes)

[MariusVanDerWijden]

Yes, this is due to EIP-3607 which makes sending transactions from accounts with contract code illegal

[nlordell]

Yes, this is due to EIP-3607

Makes sense. Out of curiosity, once the EIP lands, can the reverse attack also be done? Where a malicious party could search for a CREATE2 address that is an existing EOA to lock it out?

edit: It looks like this was already thought of:

Specifically, if nonce or code is nonzero, then the create-operation fails.

In general the issue was not really a comment about the change in itself, and more that it was included from 1.10.6 to 1.10.7 which was, AFAIU meant a maintenance release and surprised me that a more significant change such as this one was included.

[MicahZoltu]

Yes, this is due to EIP-3607 which makes sending transactions from accounts with contract code illegal

A. 3607 is still in dForraft, not final.
B. 3607 is for executing transactions on chain, the error reported here is for eth_call, eth_estimateGas.
C. I tend to agree with the others, this should have been a major version bump per semver, or at least minor.

[MariusVanDerWijden]

Yes, we'll fix eth_call and eth_estimateGas to be able to still create transactions from contracts.

[karalabe]

C. I tend to agree with the others, this should have been a major version bump per semver, or at least minor.

Geth does not follow semver.

[karalabe]

Fixed in #23424.