Calls such as eth_getStorageAt are very lenient on input format

[aathan]

System information

Geth version: latest/all
OS & Version: all

Expected behaviour

Validity checks on input parameter formats

Actual behaviour

Few or no checks. See:

NomicFoundation/hardhat#2581 (comment)

Steps to reproduce the behaviour

Make calls to eth_getStorageAt that

Backtrace

n/a

---

I'm opening this bug mostly to raise awareness in this project regarding the following issues at hardhat and foundry projects:

NomicFoundation/hardhat#3164
gakonst/ethers-rs#1687

In summary there is some confusion as to whether 0x000000002 vs 0x2 vs 0x0....2 (64 digits, 66 length total) should/must be provided, etc.

Those projects seem to use the geth implementation as a reference implementation when the open rpc spec is either erroneous or ambiguous. In this case, that spec, for the second parameter in eth_getStorageAt says:

title
hex encoded unsigned integer

pattern
^0x[0-9a-f]{0,64}$

(1) I've already opened ethereum/execution-apis#303 over there, because it seems to me that {0,64} should be {1,64}, otherwise 0x would be valid.

(2) It's unclear to me how geth does or does not, in general, validate input formats for the RPC calls, and what the project's opinion is regarding strictness on these issues. There also seems to be some folding of the "Hash" vs "Uint256" input types for RPC calls in the source code. There may be some cleanups warranted relative to "quantity" (uint) vs true "uint256" values vs "uint 256 that's a slot reference" (frequently keccak hashes), etc.

I just wanted to raise awareness here because it's probably best for the community as a whole if there was consensus on how to handle strictness of input formats for JSON RPC; and/or that all projects adopt a possible configuration flag to allow operation in "not strict" mode. Otherwise, interoperability issues may arise (and in fact, already have).