issue：arpc responses with a blockhash that doesnt exist.

we are currently doing graphnode compatibility project,when we send request to arpc

curl -X POST https://arpc.apothem.network/ -H "Content-Type: application/json" -d '
{
"id": 1610,
"jsonrpc": "2.0",
"method": "eth_getLogs",
"params": [
{
"address": "0x53350795c11cee781a7e174479778f848d76ab2a",
"fromBlock": "0x22b2277",
"toBlock": "0x22b2277",
"topics": [
[
"0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925",
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x6a12b3df6cba4203bd7fd06b816789f87de8c594299aed5717ae070fac781bac"
]
]
}
]
}'

it returns the following

{
"id": 1610,
"jsonrpc": "2.0",
"result": [
{
"address": "xdc53350795c11cee781a7e174479778f848d76ab2a",
"blockHash": "0x194a513ea40c94fccaca470cccb24c2ff3bd6398dec9a04e3eb3a4bfef8a330e",
"blockNumber": "0x22b2277",
"data": "0x000000000000000000000000000000000000000000084595161401484a000000",
"logIndex": "0x2",
"removed": false,
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x0000000000000000000000000000000000000000000000000000000000000000",
"0x000000000000000000000000ce77393582d39048a4fc73770ab19d2b239c45dd"
],
"transactionHash": "0xbebc0bab1a0f9844b86b8edf3a169bb1eef9337ac8d2684d5ae758b6521c12fe",
"transactionIndex": "0x1"
}
]
}

and we found that the blockHash is 0x194a513ea40c94fccaca470cccb24c2ff3bd6398dec9a04e3eb3a4bfef8a330e which doesnt exist.

Anyone knows the reason?

Discussion (9)

Blockchain Minions • Aug 11 • Edited on Aug 11

Just an update on the findings. So, the issue is from this line of code: github.com/XinFinOrg/XDPoSChain/bl...
Basically, at the time of this line being executed, the block is missing values for its validator.
The value of block.hash() when validator is missing returned 0x194a513ea40c94fccaca470cccb24c2ff3bd6398dec9a04e3eb3a4bfef8a330e, and this hash has been written into the DB. At later stage, the block is fully finalised: github.com/XinFinOrg/XDPoSChain/bl... Which included the value of validator into its header, and the block.hash() is 0xe8ec0bfc021f839fd0a69ae89689e309632af2cc434e8a096732068f0736864b(this matches the one on canonical chain).

In short, this 0x194a...30e hash does not belong to any block, it's a bug in the code where "in-progress" block somehow had its hash wrote into DB.
I would recommend to ignore this hash value from getLogs API calls. This issue likely to exist in all getLogs calls.
We may try fix this issue in the near future, but it's probably gonna take a while.
I can also confirm the rest of the data in this getLogs shall be accurate(except the blockHash)

Blockchain Minions • Aug 13 • Edited on Aug 13

@xu_zhaolin_fcf881856ae0b5
I'm not too sure what you using this API for, hence I can only provide a suggestion based on the assumption that you trying to perform a data migration into a new table and index it for graphQl purpose.
You can still do that by making two API calls.

One to the getLogs where wrong blockHash is returned. (Use the result except the blockHash)
Another one to the getTransaction by supplying the tx hash you get from step 1. This shall give you the correct blockHash corresponding to the tx.

You can then combine the two data source into a single one and continue processing.

Blockchain Minions • Aug 6

btw, are you able to provide a bit more context on what you trying to achieve, as well as the values of the topics you put in the parameters?

xu zhaolin • Aug 6

we are trying to make it compatible with the graph

Blockchain Minions • Aug 7

I'm not too sure what graph is or its relationship with XDC consensus engine.
Did you by any chance created a smart contract?
Basically try provide as much information/context as possible so that we can help identify the root cause