get block receipts method

[AskAlexSharov]

No description provided.

[MysticRyuujin]

I see 2 things wrong...

1. Nethermind returns 2 additional keys:
   error
   and
   type

Alexy says type is for EIP-2718

From the random block I grabbed all the type fields were just 0x00

Error is otherwise just a blank string when there is no error.

2. "logIndex" is sometimes wrong
   TG:

                {
                    "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
                    "blockHash": "0x649706785500df0cd065ab57f6e93e38fde80a052c3ba33f824bc2b374491023",
                    "blockNumber": "0xaf8a4d",
                    "data": "0x00000000000000000000000000000000000000000000000000000000b2d05e00",
                    "logIndex": "0x1", <--- This is different
                    "removed": false,
                    "topics": [
                        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                        "0x000000000000000000000000392cb8d8280e1a61faa3c3fd608ac63eaf05ce9f",
                        "0x000000000000000000000000d18748b9839b0081a867a1a871d5b562b2ec9884"
                    ],
                    "transactionHash": "0xdcb01462ab9ba85cee17e7239fb06dd9ef67a61a7822b078b179ecb14a2d2616",
                    "transactionIndex": "0x3"
                }

vs
Nethermind:

                {
                    "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
                    "blockHash": "0x649706785500df0cd065ab57f6e93e38fde80a052c3ba33f824bc2b374491023",
                    "blockNumber": "0xaf8a4d",
                    "data": "0x00000000000000000000000000000000000000000000000000000000b2d05e00",
                    "logIndex": "0x0", <--- This is different
                    "removed": false,
                    "topics": [
                        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                        "0x000000000000000000000000392cb8d8280e1a61faa3c3fd608ac63eaf05ce9f",
                        "0x000000000000000000000000d18748b9839b0081a867a1a871d5b562b2ec9884"
                    ],
                    "transactionHash": "0xdcb01462ab9ba85cee17e7239fb06dd9ef67a61a7822b078b179ecb14a2d2616",
                    "transactionIndex": "0x3"
                }

[AskAlexSharov]

1. added "type" field
2. logIdx logic is: logIdx is unique within the block and starts from 0

[MysticRyuujin]

1. Type is being returned as "0" not "0x00"
2. I don't know what this means, does this mean it's normal for logIndex to not match or something?

                {
                    "address": "0x626e8036deb333b408be468f951bdb42433cbf18",
                    "blockHash": "0xd7fb3d01db4000ebcbe57c1a5525d95a4d5b49de2e7d81c080c2b6612c366834",
                    "blockNumber": "0xbb0c5e",
                    "data": "0x000000000000000000000000000000000000000000000078f485b013b646260b",
--->                "logIndex": "0x3",
                    "removed": false,
                    "topics": [
                        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                        "0x000000000000000000000000f956cdc8f43637f34f4be368fa1cb7da01d622be",
                        "0x000000000000000000000000d60b3f7fff21b47f53c412f3c20ea55dd851419c"
                    ],
                    "transactionHash": "0x7f60457f3c3de495a11deb741131456f4c57685ca6e9acfbcdf8b7f33ccabea3",
                    "transactionIndex": "0x3"
                }

vs

                {
                    "address": "0x626e8036deb333b408be468f951bdb42433cbf18",
                    "blockHash": "0xd7fb3d01db4000ebcbe57c1a5525d95a4d5b49de2e7d81c080c2b6612c366834",
                    "blockNumber": "0xbb0c5e",
                    "data": "0x000000000000000000000000000000000000000000000078f485b013b646260b",
--->                "logIndex": "0x2",
                    "removed": false,
                    "topics": [
                        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                        "0x000000000000000000000000f956cdc8f43637f34f4be368fa1cb7da01d622be",
                        "0x000000000000000000000000d60b3f7fff21b47f53c412f3c20ea55dd851419c"
                    ],
                    "transactionHash": "0x7f60457f3c3de495a11deb741131456f4c57685ca6e9acfbcdf8b7f33ccabea3",
                    "transactionIndex": "0x3"
                }

3. Error is still missing:

        {
            "blockHash": "0xd7fb3d01db4000ebcbe57c1a5525d95a4d5b49de2e7d81c080c2b6612c366834",
            "blockNumber": "0xbb0c5e",
            "contractAddress": null,
            "cumulativeGasUsed": "0x1cdad",
            "from": "0x9c98bb2e42fd6a98c8227e97101dd2b3955b5804",
            "gasUsed": "0x84c8",
            "logs": [
            ],
            "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
            "status": "0x0",
            "to": "0x00000000006e3895f955d0a15f79b7477d7b9b2f",
            "transactionHash": "0x1cb4ebffce54ba9418653b3ab704e8253897afc96ada8f626346d5665f180c36",
            "transactionIndex": "0x2",
            "type": 0
        }

vs

        {
            "blockHash": "0xd7fb3d01db4000ebcbe57c1a5525d95a4d5b49de2e7d81c080c2b6612c366834",
            "blockNumber": "0xbb0c5e",
            "contractAddress": null,
            "cumulativeGasUsed": "0x1cdad",
--->        "error": "revert: UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT",
            "from": "0x9c98bb2e42fd6a98c8227e97101dd2b3955b5804",
            "gasUsed": "0x84c8",
            "logs": [
            ],
            "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
            "status": "0x0",
            "to": "0x00000000006e3895f955d0a15f79b7477d7b9b2f",
            "transactionHash": "0x1cb4ebffce54ba9418653b3ab704e8253897afc96ada8f626346d5665f180c36",
            "transactionIndex": "0x2",
            "type": "0x00"
        }

[MysticRyuujin]

Hmmm I also see a discrepancy in the "from" field here:

            "blockHash": "0xd7fb3d01db4000ebcbe57c1a5525d95a4d5b49de2e7d81c080c2b6612c366834",
            "blockNumber": "0xbb0c5e",
            "contractAddress": null,
            "cumulativeGasUsed": "0x9457a",
            "from": "0x0000000000000000000000000000000000000000",
            "gasUsed": "0x25575",

vs

            "blockHash": "0xd7fb3d01db4000ebcbe57c1a5525d95a4d5b49de2e7d81c080c2b6612c366834",
            "blockNumber": "0xbb0c5e",
            "contractAddress": null,
            "cumulativeGasUsed": "0x9457a",
            "from": "0x0087366b4a4e44fcb96b7d0897d68c3daf45780a",
            "gasUsed": "0x25575",

[MysticRyuujin]

I think I got extremely lucky finding this mismatched from value...I've written a script that does a json comparison. I somehow managed to call that faulty block on the 1st try, but most blocks otherwise match.

Removing the values we know are differing (type, error, and logIndex), I ran against random blocks from 11052984 to 12253328 and block number 0xbb0c5e (12258398) is the only block that has thrown an error, that error being the the from value above.

So I ran backwards from the tip and found mismatches on these other blocks:
12258398
12258582
12258564
12258515

Hopefully that will help. This could be a Nethermind bug too, I don't know, maybe @AlexeyAkhunov can try against OE?

Here's a script:

blockNumber=12258589
while :
do
  # Get TG Output
  curl -s -H "Content-Type: application/json" -d "{\"method\":\"eth_getBlockReceipts\",\"params\":[\"${blockNumber}\"],\"id\":1,\"jsonrpc\":\"2.0\"}" http://localhost:8544 > tg.json
  
  # Temp fixes for TG
  cat tg.json | jq 'del(.. | .type?)' | jq 'del(.. | .logIndex?)' | jq '.' > tg.fixed.json

  # Get Nethermind Output
  curl -s -H "Content-Type: application/json" -d "{\"method\":\"parity_getBlockReceipts\",\"params\":[\"${blockNumber}\"],\"id\":1,\"jsonrpc\":\"2.0\"}" http://nethermind01:8545 > nethermind.json
  
  # Temp Fixes for Nethermind
  cat nethermind.json | jq 'del(.. | .type?)' | jq 'del(.. | .logIndex?)' | jq 'del(.. | .error?)' | jq '.' > nethermind.fixed.json
  
  RESULT=$(jq --argfile a tg.fixed.json --argfile b nethermind.fixed.json -n 'def post_recurse(f): def r: (f | select(. != null) | r), .; r; def post_recurse: post_recurse(.[]?); ($a | (post_recurse | arrays) |= sort) as $a | ($b | (post_recurse | arrays) |= sort) as $b | $a == $b')
  if [ $RESULT == "false" ]; then
    echo "${blockNumber}: ERROR"
  else
    echo "${blockNumber}: MATCH"
  fi
  blockNumber=`expr $blockNumber - 1`
done

[AskAlexSharov]

type fixed
error investigating
logIndex - in response of getBlockReceipts it must start from 0 and then just increase by +1 from receipt to receipt. Does it follow this rule?

[MysticRyuujin]

This question seems to be WAY over my head here. Maybe @tjayrush can comment?

ethereum/go-ethereum#2028

[AskAlexSharov]

Then let's skip error field, and keep logIndex logic as is for now.

[tjayrush]

I was involved in that old issue that @MysticRyuujin mentions above.

When the bug was written, Geth started logIndex at zero and numbered each log in the block by incrementing: 0, 1, 2, 3... no matter which transaction the log was in. OpenEthereum (Parity) would number each logIndex by starting at zero for each new transactions: 0, 1, 0, 1, 2, 0, 0.... etc.

By late 2016, OpenEthereum had definitely fixed this issue and agreed with Geth. I've been testing that as part of my automated testing since then. OE is still correct as best I know.

When I first started testing TurboGeth with the same automated tests, it had the same problem #1091, but that was fixed. So all three of Turbo, Geth, and OpenEthereum agreed.

If NetherMind is disagreeing, then I would say it's Nethermind that has the issue.