Ethereum JSON-RPC responses should not include leading zero in hex

[iand]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• This is not a question or a support request. If you have any lotus related questions, please ask in the lotus forum.
• This is not a new feature request. If it is, please file a feature request instead.
• This is not an enhancement request. If it is, please file a improvement suggestion instead.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, or the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

Lotus component

• lotus daemon - chain sync
• lotus miner - mining and block production
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt)
• lotus miner/market - storage deal
• lotus miner/market - retrieval deal
• lotus miner/market - data transfer
• lotus client
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Lotus Version

release/v1.20.0

Describe the Bug

According to the json-rpc schema, many places that represent values as hex must not contain a leading zero (after the 0x). For example 0x098a0c6ef2224342b2a8727ae5111fd000000000000000000000000000000000 must be encoded as 0x98a0c6ef2224342b2a8727ae5111fd000000000000000000000000000000000. The Go hex encoder pads to an even number of characters by including a leading zero if necessary.

The conformance tests in #10102 enforce this and I'm seeing intermittent failures

The fields that are affected can be found by grepping itests/specs/eth_openrpc.json for ^0x([1-9a-f]. At a glance I think it affects the json encoding of types like EthUint64 and EthBytes but I haven't made a comprehensive list.

For more information see:

• Integer values and leading zeros ethereum/execution-apis#40
• Accept leading zeros in QUANTITY NomicFoundation/hardhat#1585

Logging Information

None

Repo Steps

No response

[jennijuju]

@iand are you working on this?

[iand]

@jennijuju not currently

[snissn]

hey @iand Are you able to provide some more feedback on what actions should be taken on #10170 ? I have added some tests to the eth types module and don't see any problems with encoding and decoding and leading zeroes. Are you saying that this test case should fail because there's a leading zero? https://github.com/filecoin-project/lotus/pull/10229/files#diff-9b386017c36b3007a1b2f036c642d2577c9a54ddbd161b4fdc05237ae5abd8baR41

[snissn]

I think that our issue here related to the type "EthFilterID" and the lotus codebase has this as a EthHash. The JsonRPC api returns it as a hash, and then seperately the conformation json spec believes that it should be an "int" like variable which would not allow leading 0x01 zeroes, but a hash may have them.

I think the biggest question I have now is whether it makes sense for EthFilterID to be an EthHash throughout the lotus codebase, but when passed to the JSONRPC should we act as if it's an int?

[snissn]

an example EthFilterID return result is 0x05c76148449d4e5a8b13803734b3568800000000000000000000000000000000 -- so question is whether that should be returned as is, or as 0x5c76148449d4e5a8b13803734b35688 or 0x5c76148449d4e5a8b13803734b3568800000000000000000000000000000000 or if there are deeper changes that need to be made