erigon
erigon copied to clipboard
erigon returns 0 as value in rpc calls which are addressing pruned data.
System information
Erigon version: 2022.08.3-alpha-defbddf8
Relevant command line parameters: ./erigon --prune=h
OS & Version: Linux/Debian 11
Expected behaviour
The RPC call {"id":1,"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2","value":"0x0","data":"0x70a082310000000000000000000000008ee7d9235e01e6b42345120b5d270bdb763624c7"},"0xb2f5f6"]} shouldn't return 0x.
It should return an error instead because the state (according to the command line above) is pruned.
Actual behaviour
Currently {"jsonrpc":"2.0","id":1,"result":"0x"} is returned which makes one think that this is the actual value (which it's not, because those data are pruned).
0x is an empty hexadecimal so it means the state you are looking for is not there aka pruned or not found
But then it's not compatible to at least Nethereum while other Ethereum clients like Nethermind are?
However, you may be right and Nethereum is doing something special there. So if this is normal behavior, then close the ticket, please.
@GhostTyper what error Geth/Nethermind return in this case?
Now we don't have any "prune settings checks" in RPC methods now (in all RPC methods). And many RPC methods (like eth_getBlock) do return nil if block not found - and it's part of API spec (if I remember right). So, in many other RPC methods we also return some kind of nil.
The issue is, that I scrapd my Nethermind full node for an erigon full node. I only have an nethermind archive node left. However, if I query the balance before the smart contract was deployed then nethermind also reports 0 and not an error.
I will setup a nethermind node again and test how nethermind replies, if nobody else can't supply this information. (This takes some days for me.)
We can have it return nil I believe if it doesn't specs @AskAlexSharov
@AskAlexSharov: nethermind returns:
{"jsonrpc":"2.0","error":{"code":-32002,"message":"No state available for block 0x6154ade030d3c9d83835de1c0ae9b6c09a567934a1062d9d69ad0b483c7c9148"},"id":1}
This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.
This issue was closed because it has been stalled for 7 days with no activity.