eth_getBlockByHash for genesis block does not work

[winor30]

Description

There was a problem that genesis block data was null when retrieved with eth_getBlockByHash.
We discovered this problem when we were trying to use graph-node with Shibuya network, and the data retrieval of the genesis block failed.

Steps to Reproduce

I tried with Shibuya network, ETH main network, and Moonbase alpha Testnet, and confirmed that only Shibuya network could not acquire data.

Shibuya network

ETH main network

Moonbase alpha Testnet

Expected vs. Actual Behavior

Ideally, I believe that the Astar network should also be able to retrieve genesis block data using block hash.
However, if there is a reason specific to Astar, I do not see a problem if the genesis block data cannot be retrieved using block hash.

Additional Information

I have seen similar issues with issues ( polkadot-evm/frontier#78 ) in the library ( https://github.com/paritytech/frontier ) used by Astar.
However, I do not know why it occurs only in Astar, as this issue has been resolved, although the Issue has not been closed.

Moonbeam appears to have the issue resolved.
https://github.com/PureStake/moonbeam/blob/master/tests/tests/test-block/test-block-genesis.ts#L37-L53

[akru]

Hi @winor30, do you have same issue on Astar?

[winor30]

Hi @akru.
yes, also there is same issue on Astar

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[Dinonard]

The bug was fixed in release v4.9.0.

The cause was incorrect caching of the block schema which caused errors while decoding some blocks.

[shunsukew]

The bug was fixed in release v4.9.0.

The cause was incorrect caching of the block schema which caused errors while decoding some blocks.

@Dinonard
No, this hasn't been fixed yet. This is a different issue from what we've seen with eth_getLogs.

Shibuya (v4.13.0):

$ curl http://localhost:9933 -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["earliest", false],"id":1}'
{"jsonrpc":"2.0","result":{"author":"0x0000000000000000000000000000000000000000","difficulty":"0x0","extraData":"0x","gasLimit":"0xe4e1c0","gasUsed":"0x0","hash":"0x43b5bb950907bfbf1db7f7a03f28d7130418b6c58bd2428079b59c446633bd2e","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","miner":"0x0000000000000000000000000000000000000000","nonce":"0x0000000000000000","number":"0x0","parentHash":"0x0000000000000000000000000000000000000000000000000000000000000000","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","size":"0x1f8","stateRoot":"0x86c439ef262223d0a26d8c3cfae5c70932925a4c2ef12af31812ecd8a7071bfb","timestamp":"0x0","totalDifficulty":"0x0","transactions":[],"transactionsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","uncles":[]},"id":1}

$ curl http://localhost:9933 -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0x43b5bb950907bfbf1db7f7a03f28d7130418b6c58bd2428079b59c446633bd2e", false],"id":1}'
{"jsonrpc":"2.0","result":null,"id":1}

I think this is something related to eth block hash <> substrate hash mapping

[shunsukew]

This load_hash function returns Ok(None) in case with genesis block hash, this means genesis block hash key doesn't exist in frontier backend MappingDb (eth hash <> substrate hash).
https://github.com/AstarNetwork/frontier/blob/09b2fcaddf3bc801ac32041d7f7b867f1bfe5cd7/client/rpc/src/eth/block.rs#L51

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[shunsukew]

Found the root cause, working on fixing it.

[shunsukew]

PR has been merged to upstream master branch.
polkadot-evm/frontier#917

Genesis block issue persist until this commit will be included in Astar repo by uplifting frontier pallet version.