Improper cache configurations for `eth_getProof`

[Daniel-K-Ivanov]

The base goerli RPC endpoint does not have proper cache configuration. I've tried with the public RPC node and a dedicated one from QuickNode. Both of them return improper cached values.

Context Querying eth_getProof in parallel for 2 storage slots of a contract returns a cached value for the second call. The result of the second query to be processed by the node (eth_getProof) always returns the value returned by the first query. There is a short cache period which returns wrong values.

Queries I am executing:

Query 1: The result should return storage proof for key with value 0x67b389cc878116030416d2a1d22a93ba83e3e871a753c665d3363932d5eb0e67

{
    "jsonrpc": "2.0",
    "method": "eth_getProof",
    "params": [
        "0xb6f147a87ce210648e341569b61a132e02990653",
        [
            "0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e56d"
        ],
        "0x5ec534"
    ],
    "id": 0
}

Query 2: The result should return storage proof for key with value 0x688b75e1693aae9cc63d24413222338c66b4cd9aa08b10769c96aaf35ea68f00

{
    "jsonrpc": "2.0",
    "method": "eth_getProof",
    "params": [
        "0xb6f147a87ce210648e341569b61a132e02990653",
        [
            "0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e56c"
        ],
        "0x5ec534"
    ],
    "id": 0
}

If the queries are executed in a short period of time, the second one returns the value of the first one

[Daniel-K-Ivanov]

I've deduced that the cache TTL is ~1second

[slumericanBx]

having a similar problem myself

[mdehoog]

@Daniel-K-Ivanov can you share your full curl? I'm not seeing any response for that request:

REQUEST='{
    "jsonrpc": "2.0",
    "method": "eth_getProof",
    "params": [
        "0xb6f147a87ce210648e341569b61a132e02990653",
        [
            "0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e56d"
        ],
        "0x5ec534"
    ],
    "id": 0
}'
curl -d '$REQUEST'  -H "Content-Type: application/json" https://goerli.base.org

{"jsonrpc":"2.0","id":0,"error":{"code":-32000,"message":"header not found"}}

https://goerli.basescan.org/address/0xb6f147a87ce210648e341569b61a132e02990653 not seeing anything on this account

[Daniel-K-Ivanov]

@mdehoog

@Daniel-K-Ivanov can you share your full curl? I'm not seeing any response for that request:

REQUEST='{
    "jsonrpc": "2.0",
    "method": "eth_getProof",
    "params": [
        "0xb6f147a87ce210648e341569b61a132e02990653",
        [
            "0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e56d"
        ],
        "0x5ec534"
    ],
    "id": 0
}'
curl -d '$REQUEST'  -H "Content-Type: application/json" https://goerli.base.org

{"jsonrpc":"2.0","id":0,"error":{"code":-32000,"message":"header not found"}}

https://goerli.basescan.org/address/0xb6f147a87ce210648e341569b61a132e02990653 not seeing anything on this account

Yes, sorry. I've passed the wrong CURL request (targeting Optimism Goerli State). Here is the proper JSON for Base:

{
    "jsonrpc": "2.0",
    "method": "eth_getProof",
    "params": [
        "0xf904d6c85bacd4d0f4c3c60f170d5052111d5c54",
        [
            "0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e56d"
        ],
        "0x1d70ef"
    ],
    "id": 0
}

Keep in mind that if you execute the request now you will get a proper value populated in the result.storageProof[0].value field. The issue can be reproduced by:

1. Start with an empty storage slot
2. Run queries for getting proof of the storage and checking what the value property is for the storage proof. It will start with 0x0
3. Execute a transaction that manipulates the storage slot and changes the value
4. Notice that the queries for the storage value are persisting to return 0x0 instead of returning the changed value from step 3

[roberto-bayardo]

@Daniel-K-Ivanov Do you see the same behavior from optimism goerli nodes or does this seem specific to Base?

And since the third argument is a fixed block number, wouldn't you expect the returned value to remain unchanging? Or do you see the same behavior when you provide "latest" instead?

[Daniel-K-Ivanov]

@roberto-bayardo

@Daniel-K-Ivanov Do you see the same behaviour from optimism goerli nodes or does this seem specific to Base?

And since the third argument is a fixed block number, wouldn't you expect the returned value to remain unchanging? Or do you see the same behaviour when you provide "latest" instead?

• I see this behaviour only for Base Goerli. Optimism Goerli is working fine and the storage value is not being cached there.
• My application submits a TX to a contract on Base Goerli, which stores bytes32 in an array. Several minutes after the Transaction is processed (mined), I am querying for eth_getProof targeting the L2 block number in which the transaction was accepted. In some cases the returned value for the storage slot is 0x0 even after querying several times in 3-second intervals. In others, the returned value for the storage slot is the correct one.

I've tried using the public endpoint and a dedicated endpoint from QuickNode in both of which the issue is reproducing.

In the coming days, I might have more information/details of the problem and potentially isolate it better. I will update you if that is the case.

[Daniel-K-Ivanov]

I managed to resolve the issue. The problem was on my side and more specifically, the blockNumber that I was specifying at which eth_getProof to be executed was wrong.

I am closing the issue