Genesis block not accessible

[crystalin]

When doing a eth_getBlockByNumber using 0 (and "earliest" too ?), it returns null.

I believe it should return the genesis block

[tgmichel]

• Using earliest is expected to return block 0x1: https://github.com/paritytech/frontier/blob/master/rpc/src/lib.rs#L205
• In reference the genesis block: pallet-ethereum emulates the block processing on_finalize and the genesis block is not produced by the runtime, but hardcoded as part of the chain spec. It is currently not present in the pallet-ethereum's storage.

@sorpaas we may want to include it as part of the pallet's storage initialization?

[crystalin]

@tgmichel the "earliest" block should be 0 I believe.
Testing on "ganache" =>

curl -s -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["earliest", true],"id":1}'  http://localhost:8545/ | jq . 
{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "number": "0x0",
    "hash": "0x1e4a23c2ace68e7c8ddffa3c0c9a85036d67bce081aa7efd73fab77bb95a8feb",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "nonce": "0x0000000000000000",
    "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "stateRoot": "0x7f8a4e12aa068a6a53a549a25826018dbbfe62662f94dea3ecd89e99c5eee534",
    "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "miner": "0x0000000000000000000000000000000000000000",
    "difficulty": "0x0",
    "totalDifficulty": "0x0",
    "extraData": "0x",
    "size": "0x3e8",
    "gasLimit": "0x6691b7",
    "gasUsed": "0x0",
    "timestamp": "0x5f15f4bd",
    "transactions": [],
    "uncles": []
  }
}

[tgmichel]

PR #79 fixes this.

[ermalkaleci]

@sorpaas This is fixed

[tgmichel]

@ermalkaleci Plot twist :)

It was working before introducing AuxStore-based block import but the mapping is not done for the genesis block (as it is not imported). Calls that require hash to hash translation don't work for it (i.e. eth_getBlockByHash).

[ermalkaleci]

@tgmichel that's fixed as well

[tgmichel]

Strange, just tried it and still getting a null response. Do you mind pointing me to the commit that fix it?

[ermalkaleci]

@tgmichel #134

[tgmichel]

@ermalkaleci

• Your PR only covers manual sealing used for testing.
• get block by hash assertion is being perfomed on block 1, not in genesis (is using latest to get the block, and latest is already 1 when reaching the assertion).

So if you run the node without manual sealing, genesis block still not mapped in the AuxStore.

[ermalkaleci]

@tgmichel it's working for me

[tgmichel]

Still I don't know how. Could you explain how #134 fixes or is it related with this?

For me it is returning null doing:

curl http://localhost:9933 -H "Content-Type:application/json;charset=utf-8" -d \
  '{
    "jsonrpc":"2.0",
    "id":1,
    "method":"eth_getBlockByNumber",
    "params": ["0x0",true]
  }'

And using its 0xHASH in:

curl http://localhost:9933 -H "Content-Type:application/json;charset=utf-8" -d \
  '{
    "jsonrpc":"2.0",
    "id":1,
    "method":"eth_getBlockByHash",
    "params": ["0xHASH",true]
  }'

[ermalkaleci]

@tgmichel ok got it. FrontierBlockImport not called for genesis block when using aura import queue

[mario-sangar]

Using Moonbeam Alphanet, which is using frontier, I discovered this same issue. I'm able to get the block 0 using the eth_getBlockByNumber RPC call, but using then the hash that appears there to get the block again with eth_getBlockByHash, it results in null.

# get hash of block 0 or "earliest"
curl -sL \
   -H "Content-Type: application/json" \
   -d '{
       "jsonrpc": "2.0",
       "method": "eth_getBlockByNumber",
       "params": ["0x0", false],
       "id":666
   }' \
   https://rpc.testnet.moonbeam.network | jq -r '.result.hash'

# try to get block 0 from hash -> NULL/ERROR
curl -sL \
   -H "Content-Type: application/json" \
   -d '{
       "jsonrpc": "2.0",
       "method": "eth_getBlockByHash",
       "params": ["0x177faa2eb3975cfb29d14ec337b66656ab120cdaa1656ce1d7cb93e68b06049e", false],
       "id":666
   }' \
   https://rpc.testnet.moonbeam.network

Do you know if this fix is in the roadmap? Will this be fixed at some point?

Thank you

[joelamouche]

Problem confirmed by this test moonbeam-foundation/moonbeam#209

[tgmichel]

This can be closed now (at last!)

[shunsukew]

@tgmichel @JoshOrndorff

Hello,
eth_getBlockByHash returns null for GenesisBlock in our case.
I found genesis block ethereum hash key doesn't exist in Ethereum <> Substrate block hash mapping. So, this line returns Ok(None). https://github.com/AstarNetwork/frontier/blob/09b2fcaddf3bc801ac32041d7f7b867f1bfe5cd7/client/rpc/src/eth/block.rs#L51

I can see lots of discussion about workaround here #279.
What is the current approach for getting genesis block by hash? and Is there any necessity for data migration?