eth_getStorageAt spec ambiguity

[aathan]

See NomicFoundation/hardhat#2581 and NomicFoundation/hardhat#2581 ... and in particular NomicFoundation/hardhat#2581 (comment)

The specification for eth_getStorageAt seems to be causing confusion for multiple projects, specifically around whether or not the RPC endpoint SHOULD accept hex encoded integers of length < 66 bytes.

This spec itself seems to contain an error in that uint256 is output as ^0x[0-9a-f]{0,64}$ ... shouldn't that say {1,64} ? Is it intended that 0x is acceptable (vs 0x0)?

[lightclient]

Thanks for pointing this out @aathan. I've taken a look and you are indeed correct, it is not intended for 0x to be accepted as a uint256. However, it is acceptable as a Byte value in general. This is a better definition of the storage keys.

I've created a new type BytesMax32 in #305 to be used in places where storage keys are referenced. PTAL at the PR and let me know if the solution seems acceptable to you.

RPC endpoints SHOULD accept hex encoded byte values of length < 66 bytes. I apologize for the error in the specification.