eth_getStorageAt api can not work with go-etheruem/ethclient and umbracle/go-web3

[laizy]

#1700 (comment)

The storage‘s key/value in ethereum is fixed 20 bytes, and should be encoded as Hash. But it seems hardhat take it as integer and only accept data without leading zeros.

Here is the signature from ethereuem's go code :

func (ec *Client) StorageAt(ctx context.Context, account common.Address, key common.Hash, blockNumber *big.Int) ([]byte, error) 

and hardhat node will report error:

---> {"jsonrpc":"2.0","id":17,"method":"eth_getStorageAt","params":["0x851356ae760d987e095750cceb3bc6014560891c","0x0000000000000000000000000000000000000000000000000000000000000001","latest"]}
<--- {"code":-32602,"message":"Errors encountered in param 1: Invalid value \"0x0000000000000000000000000000000000000000000000000000000000000001\" supplied to : QUANTITY"}

[alcuadrado]

Hey,

I don't think your description is correct. How geth represents these types internally doesn't necessary match the json rpc spec.

Take a look at this: https://eth.wiki/json-rpc/API#eth_getstorageat

[laizy]

@alcuadrado thanks for the link. what I paste above is geth's client side code, not server side code. so it will send the key as hash with leading zeros. And I tried and found the geth server node will accept two forms of data.

But the eips also have some inconsistencies , like the eth_getproof api take the keys as 32bytes hash.

It is up to you to remove the restriction or just close this.

[fvictorio]

I think this is a duplicate of #1585. Tentatively closing this, but please re-open if you think it's a different issue.

[meetmangukiya]

@fvictorio while the linked issue is correct about not accepting leading zeros for getBlockByNumber because it is a uint type according to the specl, for getStorageAt the spec is uint256 which does accept leading zeros:
https://github.com/ethereum/execution-apis/blob/9bc4c1afaa7ab7961fd0d82c9403860063cc20ac/src/eth/state.json#L39-L45
https://github.com/ethereum/execution-apis/blob/9bc4c1afaa7ab7961fd0d82c9403860063cc20ac/src/schemas/base-types.json#L42-L46

[fvictorio]

@meetmangukiya you are right. In fact, I think the storage slot must always have 64 characters. We have a new issue about this: #2230

[meetmangukiya]

@fvictorio right, the regex certainly looks like it