Inconsistent debug_storageRangeAt Behavior in Erigon 2.60.10

[jwelch-qn]

System information

Erigon version: Erigon/2.60.10

OS & Version: Ubuntu 24.04

Commit hash:

Erigon Command (with flags/config):

curl <ERIGON ENDPOINT> \
 -X POST \
 -H "Content-Type: application/json" \
 --data '{"method":"debug_storageRangeAt","params":["0x4058c0ab3483dd92e7a872330eb3f0086e4664b846549592d672cc4f31776013",0,"0x3a10dc1a145da500d5fba38b9ec49c8ff11a981f","0x00",1],"id":1,"jsonrpc":"2.0"}'

Consensus Layer: Lighthouse

Chain/Network: Mainnet Ethereum

Expected behaviour

Calling a geth archive node we get a full accurate response:

{"jsonrpc":"2.0","id":1,"result":{"storage":{"0x0175b7a638427703f0dbe7bb9bbf987a2551717b34e79f33b5b1008d1fa01db9":{"key":"0x000000000000000000000000000000000000000000000000000000000000000b","value":"0x0000000000000000000000008680a87a6ff5a2467eeb8a877f3dcfefde7b65b5"}},"nextKey":"0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db0"}}

Actual behaviour

When calling an erigon archive node we get 0x000 key values which are not accurate.

{"jsonrpc":"2.0","id":1,"result":{"storage":{"0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563":{"key":"0x0000000000000000000000000000000000000000000000000000000000000000","value":"0x0000000000000000000000000000000000000000000000000000000000000001"}},"nextKey":"0x0000000000000000000000000000000000000000000000000000000000000001"}}

Steps to reproduce the behaviour

See Erigon Command^^^

[JkLondon]

works in e3, due to upcoming release e2 is not priority

[Wollac]

@JkLondon

works in e3, due to upcoming release e2 is not priority

I retested the debug_storageRangeAt call using the latest Erigon v3 (main branch) build and still observe the same issue. The call is iterating over the raw storage keys rather than using their key hashes (i.e., the MPT ordering).

For example, my response looks like this:

{
  "storage": {
    "0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563": {
      "key": "0x0000000000000000000000000000000000000000000000000000000000000000",
      "value": "0x0000000000000000000000000000000000000000000000000000000067d3fe29"
    },
    "0xb10e2d527612073b26eecdfd717e6a320cf44b4afac2b0732d9fcbe2b7fa0cf6": {
      "key": "0x0000000000000000000000000000000000000000000000000000000000000001",
      "value": "0x0000000000000000000000000000000000000000000000000000000067d3fe1d"
    },
    "0x405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3bb5ace": {
      "key": "0x0000000000000000000000000000000000000000000000000000000000000002",
      "value": "0x0000000000000000000000000000000000000000000000000000000067d3fe1d"
    }
  },
  "nextKey": "0x0000000000000000000000000000000000000000000000000000000000000004"
}

In contrast, a geth archive node iterates based on the key hashes (starting from the first hash after provided start parameter) and nextKey also contains the next key hash.
This discrepancy makes it harder to correlate the returned keys with their respective positions in the MPT.

I realize the initial note mentioned that E3 was working and E2 wasn't a priority for an upcoming release, but it seems this behavior still persists in v3.