eth_getLogs returns bogus results that are different every time

[samsondav]

Describe the bug
eth_getLogs returns wrong results

To Reproduce

curl -v --data '{"method":"eth_getLogs","id":"1","params":[{"blockhash": "0x892a8b3ccc78359e059e67ec44c83bfed496721d48c2d1dd929d6e4cd6559d35"}],"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST http:https://goerli-nethermind-rpc.example

It returns totally wrong results, including logs from a different blockhash than the one that was requested (actually, it gives different results every time you query it):

{
  "jsonrpc": "2.0",
  "result": [
    {
      "address": "0xb5f27a4278c1eecef9dfc3f4cee5a05b2f8117db",
      "blockHash": "0xe91bdd1d9a7b49a211a52d9efdd12dc03e61dcb6aad959620413f4a5b00c58b5",
      "blockNumber": "0x70705b",
      "data": "0x0000000000000000000000000000000000000000000000000000000000000004",
      "logIndex": "0x0",
      "removed": false,
      "topics": [
        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
        "0x0000000000000000000000003be0ec232d2d9b3912de6f1ff941cb499db4ece7",
        "0x00000000000000000000000035fff9272293a0e3c4a847b0842b8ec75c541bdf"
      ],
      "transactionHash": "0x38fa8389d32d771050cb1c2d17fab0494ba17c6823e33b5888f2183aa5508371",
      "transactionIndex": "0x0",
      "transactionLogIndex": "0x0"
    },
    {
      "address": "0x454f1ec431470063a1792ead14c1f10876796e5f",
      "blockHash": "0xe91bdd1d9a7b49a211a52d9efdd12dc03e61dcb6aad959620413f4a5b00c58b5",
      "blockNumber": "0x70705b",
      "data": "0x7321ab4b0d5d229683dc9f8f7dc2429a7825fd75cc1af7d058ea89097aabf13c0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000004c00000bb9000000000000000000000000f5e6cc7fa0bf3c96b3def2863ec0dc03ce5dc7370000388600000fa100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "logIndex": "0x1",
      "removed": false,
      "topics": [
        "0x9d4c83d2e57d7d381feb264b44a5015e7f9ef26340f4fc46b558a6dc16dd811a",
        "0x76c7c52fc9db019864fb4f2291c7732082a4b3ec3fbed6a20b69ae2a6af49d9b",
        "0x000000000000000000000000000000000000000000000000000000000000c6a8",
        "0x00000000000000000000000000000000000000000000000000000fa100003886"
      ],
      "transactionHash": "0xa774689f14930686c6a253be1ff1f7a7af2b7a4611fb45a957c4db143095a6e3",
      "transactionIndex": "0x1",
      "transactionLogIndex": "0x0"
    },
    {
      "address": "0x7ecef15fd609888c33df044a135baa11298a6430",
      "blockHash": "0xe91bdd1d9a7b49a211a52d9efdd12dc03e61dcb6aad959620413f4a5b00c58b5",
      "blockNumber": "0x70705b",
      "data": "0x00000000000000000000000000000000000000000000000000000000000000010000000000000000000000006338fa4588a5b203218ba49ed5300a099fbed25f0000000000000000000000000000000000000000000000000000000000701c150000000000000000000000000000000000000000000000000000000000707059000000000000000000000000000000000000000000000000000000000070705b",
      "logIndex": "0x2",
      "removed": false,
      "topics": [
        "0xbd6b6608a51477954e8b498c633bda87e5cd555e06ead50486398d9e3b9cebc0"
      ],
      "transactionHash": "0x39712b388a44f931029fa99f7ff8f12d8556d0b80d080ece02273d0d1081c4c5",
      "transactionIndex": "0x3",
      "transactionLogIndex": "0x0"
    },
    {
      "address": "0x4c0ce02c1219ce5d2afffba97e484272a4637b49",
      "blockHash": "0xe91bdd1d9a7b49a211a52d9efdd12dc03e61dcb6aad959620413f4a5b00c58b5",
      "blockNumber": "0x70705b",
      "data": "0x00000000000000000000000000000000000000000000000000c5d4c776274fec000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000",
      "logIndex": "0x3",
      "removed": false,
      "topics": [
        "0xcaacad83e47cc45c280d487ec84184eee2fa3b54ebaa393bda7549f13da228f6",
        "0x0000000000000000000000000000000000000000000000000000000000000009",
        "0x0000000000000000000000000000000000000000000000000000000000000001",
        "0x0000000000000000000000006338fa4588a5b203218ba49ed5300a099fbed25f"
      ],
      "transactionHash": "0x39712b388a44f931029fa99f7ff8f12d8556d0b80d080ece02273d0d1081c4c5",
      "transactionIndex": "0x3",
      "transactionLogIndex": "0x1"
    }
  ],
  "id": "1"
}

Expected behavior

I expect to see the same results that I would get from making the same query against go-ethereum, which is consistent every time and returns the logs from the block hash that was requested.

curl -v --data '{"method":"eth_getLogs","id":"1","params":[{"blockhash": "0x892a8b3ccc78359e059e67ec44c83bfed496721d48c2d1dd929d6e4cd6559d35"}],"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST http:https://goerli-go-ethereum-rpc.example

Version
Nethermind/v1.13.6-0-be7b4ab4c-20220805/X64-Linux/6.0.7

[prashantkumar1982]

To add more context, this is a major blocking bug for Chainlink services running on nethermind.

[rubo]

Currently, the blockhash parameter is not supported. While the fix is on the way, you can use the pair of fromBlock and toBlock instead (if that's an option) as follows:

{
  "fromBlock": "0x707032",
  "toBlock": "0x707032"
}

@samsondav What version of Geth are you comparing to?

[prashantkumar1982]

geth version used was v1.10.21.
However geth has always been consistent with this behavior, in older client versions too.

Changing the blockhash param is not possible for us, since we have that common code for all clients, and even other chains.

[LukaszRozmej]

Hi @samsondav and @prashantkumar1982 I see we never implemented https://github.com/ethereum/EIPs/blob/master/EIPS/eip-234.md So we don't support blockhash. The only block limits we currently support is fromBlock and toBlock. If you don't supply anything there those default to latest hence the changing behaviour.

Currently you can just use fromBlock and toBlock with both number as well as block hash, so your request of
curl -v --data '{"method":"eth_getLogs","id":"1","params":[{"fromBlock": "0x892a8b3ccc78359e059e67ec44c83bfed496721d48c2d1dd929d6e4cd6559d35","toBlock": "0x892a8b3ccc78359e059e67ec44c83bfed496721d48c2d1dd929d6e4cd6559d35"}],"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST http:https://goerli-nethermind-rpc.example
should behave like in Geth.

We will implement blockHash as an option here to have feature parity with Geth. Ah probably Geth in fromBlock and toBlock supports only block numbers.

[prashantkumar1982]

Feature Parity will be definitely appreciated!

Trying to have custom code for nethermind is hard to maintain, as then we need to configure our Nodes to know which client it is using, and based on that, which code logic should be used.

We already are dealing with mutilple eth clients, eth RPC providers, other EVM chains.
Any custom logic can cause nightmare around our testing matrix, and general maintenance.

[LukaszRozmej]

@prashantkumar1982 sure just reassuring its simple API mismatch rather than some serious bug in the inner mechanism.

[prashantkumar1982]

Thanks. I understand it is not a major bug in nethermind implementation.

We were planning to test all Chainlink services running on nethermind client during Goerli Merge. But it seems like this bug will prevent testing during the Goerli merge, since that is just 2 days away.
However once you release a build with the fix, we will test it for mainnet, and hopefully be ready for Eth mainnet before the Merge.

[rubo]

I noticed some inconsistencies with the parameter casing. In the case of Geth, it ignores casing when running locally, while on Alchemy, only blockHash is accepted. Infura states blockhash. So does QuickNode. In its code, Geth uses blockHash.

This said, Nethermind accepts blockHash only.