The JSON-RPC layer is overly permissive about the number formats it accepts

[fvictorio]

These are all being accepted by EDR right now:

send("eth_getBlockByNumber", [0, false])
send("eth_getBlockByNumber", ["0", false])
send("eth_getBlockByNumber", ["0b0", false])
send("eth_getBlockByNumber", ["0o0", false])

send("eth_getStorageAt", ["0x63689f2aE7c74Db7A9D5523d5a1463a0F5bF0cf4", "0"])
send("eth_getStorageAt", ["0x63689f2aE7c74Db7A9D5523d5a1463a0F5bF0cf4", "0b0"])

Curiously, the last two are also accepted by geth, but that's clearly an error.

The full scope of this is not clear, but my guess is that fixing those (and any other examples that come to mind) will already uncover some issues. No need to do a thorough investigation.

[alcuadrado]

eth_getStorageAt is a historically complex case, because different libraries (e.g. ethers) expected different formats at different points in time. See the last version of Hardhat without EDR, it's treated as a special case: https://github.com/NomicFoundation/hardhat/blob/5f0e42d5fdef3fb1f3b5592758f828f03612b8b2/packages/hardhat-core/src/internal/hardhat-network/provider/modules/eth.ts#L711-L719

While in that same file, you'd find that eth_getBlockByNumber uses a block tag, which is eventually a strict rpc quantity, which I think is the expected behaviour, and being more permissive is a bug.

[alcuadrado]

Also note that only eth_getStorageAt accepts that weird type.

[fvictorio]

@alcuadrado can you clarify exactly which of these cases you think we should support? Because to me supporting 0b and 0o prefixes is clearly wrong. I do see that supporting decimal numbers (stringified or not) might make sense in some scenarios (although I would happily remove support for those too).

[Wodann]

Alloy has a crate with serde helpers to handle this nicely.

[Wodann]

As part of my upgrade to the latest REVM, I had to change some types in the JSON-RPC layer. In doing so, I also started switching to the aforementioned alloy-serde crate