erigon
erigon copied to clipboard
Many RPC APIs off one block
I posted this issue into Erigon discord two months ago. However, this issue still persists in the latest version and it makes many RPC APIs misbehave. I don't have time to deal with it so I create an issue here to track it.
Original chat:
zzh1996 — 2022/06/25
@Alex Sharov
https://github.com/ledgerwatch/erigon/pull/3737/files This commit only fix some RPC, but not all Searching forNewPlainState(
in source code gives you a lot of RPCs not fixed zzh1996 — 2022/06/25 Like eth_createAccessList trace_call trace_callMany debug_traceCall eth_callBundle, etc Alex Sharov — 2022/06/25 maybe zzh1996 — 2022/06/25 Plus all RPCs which use ComputeTxEnv, many debug / trace APIs zzh1996 — 2022/06/25 It is real. I tested it. Alex Sharov — 2022/06/25 if you tested - can you PR pls? I just didn't test. zzh1996 — 2022/06/25 Do you design the API to be off one block? Is it correct that I create a PR adding +1 everywhere? Or should I change the underlying function, and delete all +1 Alex Sharov — 2022/06/25 Here is what happened:
- if you send request "exec tx A on block N", it's unclear for me why need pass N+1 to NewPlainState()
- but here is how we do store history (let's assume that N is latest block): in record N we store state which was before change in this block (not after). Because we have special table for "CurrentState" - then no reason to store same values in history table. More compact history.
My opinion:
- NewPlainState must handle this knowledge (because it works with history db format directly, and maybe reading other tables in another format), not user of this class.
To summarize:
- need pass N to NewPlainState(). I looked now inside NewPlainState() and it using blockNr only for funcs like "GetAsOf, WalkAsOf" (it's history). Means can just do +1 inside NewPlainState() and leave comment why.
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 is still there. Please do not close.
Can you please present a concrete example via curl
? I'm fairly certain that we are not seeing this on our installations, but I would be willing to try to confirm the ability to duplicate. If it can't be duplicated, this issue could be closed, I think. But I'm willing to try to duplicate before that. If you can also present the same query against Nethermind (if those endpoints are available), that would be helpful.
@tjayrush Just one example below (I don't have time to test every RPC endpoint)
Erigon v2022.09.03 (wrong result)
$ curl http://127.0.0.1:8545 -H 'content-type: application/json' --data '{"jsonrpc": "2.0", "id": 0, "method": "debug_traceCall", "params": [
{
"to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"data": "0x70a082310000000000000000000000008ad599c3a0ff1de082011efddc58f1908eb6e6d8",
"gasPrice": "0x174876e800"
}, "0xeefbd5", {"tracer":"callTracer"}
]}'
{"jsonrpc":"2.0","id":0,"result":{"type":"CALL","from":"0x0000000000000000000000000000000000000000","to":"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2","value":"0x0","gas":"0x2fa9cc8","gasUsed":"0x9e6","input":"0x70a082310000000000000000000000008ad599c3a0ff1de082011efddc58f1908eb6e6d8","output":"0x0000000000000000000000000000000000000000000017600c616b51d138f911","time":"377.35µs"}}
Erigon using eth_call
:
$ curl http://127.0.0.1:8545 -H 'content-type: application/json' --data '{"jsonrpc": "2.0", "id": 0, "method": "eth_call", "params": [
{
"to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"data": "0x70a082310000000000000000000000008ad599c3a0ff1de082011efddc58f1908eb6e6d8",
"gasPrice": "0x174876e800"
}, "0xeefbd5"
]}'
{"jsonrpc":"2.0","id":0,"result":"0x0000000000000000000000000000000000000000000017601a3a477d1a446e2d"}
Geth:
$ curl http://127.0.0.1:8545 -H 'content-type: application/json' --data '{"jsonrpc": "2.0", "id": 0, "method": "debug_traceCall", "params": [
{
"to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"data": "0x70a082310000000000000000000000008ad599c3a0ff1de082011efddc58f1908eb6e6d8",
"gasPrice": "0x174876e800"
}, "0xeefbd5", {"tracer":"callTracer"}
]}'
{"jsonrpc":"2.0","id":0,"result":{"type":"CALL","from":"0x0000000000000000000000000000000000000000","to":"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2","value":"0x0","gas":"0x2fa9cc8","gasUsed":"0x9e6","input":"0x70a082310000000000000000000000008ad599c3a0ff1de082011efddc58f1908eb6e6d8","output":"0x0000000000000000000000000000000000000000000017601a3a477d1a446e2d"}}
This is not even json (nullnull?)
$ curl http://127.0.0.1:8545 -H 'content-type: application/json' --data '{"jsonrpc": "2.0", "id": 0, "method": "debug_traceCall", "params": [
{
"to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"data": "0x70a082310000000000000000000000008ad599c3a0ff1de082011efddc58f1908eb6e6d8",
"gasPrice": "0x174876e800"
}, "0x1", {"tracer":"callTracer"}
]}'
{"jsonrpc":"2.0","id":0,"result":nullnull,"error":{"code":-32000,"message":"block 1(88e96d4537bea4d9c05d12549907b32561d3bf31f45aae734cdc119f13406cb6) not found"}}
This is not even json (nullnull?)
$ curl http://127.0.0.1:8545 -H 'content-type: application/json' --data '{"jsonrpc": "2.0", "id": 0, "method": "debug_traceCall", "params": [ { "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", "data": "0x70a082310000000000000000000000008ad599c3a0ff1de082011efddc58f1908eb6e6d8", "gasPrice": "0x174876e800" }, "0x1", {"tracer":"callTracer"} ]}' {"jsonrpc":"2.0","id":0,"result":nullnull,"error":{"code":-32000,"message":"block 1(88e96d4537bea4d9c05d12549907b32561d3bf31f45aae734cdc119f13406cb6) not found"}}
Thanks for this. I can confirm that I'm seeing this myself on commit 32bd69e5316050005e34448ec6b0165f97173d50 (tag: v2022.09.03, origin/alpha)
A bit of further information. I get a valid block data is I query the given hash (which says not found).
curl -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id": 1, "method": "eth_getBlockByHash", "params": ["0x88e96d4537bea4d9c05d12549907b32561d3bf31f45aae734cdc119f13406cb6", true]}' http://localhost:23456
{"jsonrpc":"2.0","id":1,"result":{"difficulty":"0x3ff800000","extraData":"0x476574682f76312e302e302f6c696e75782f676f312e342e32","gasLimit":"0x1388","gasUsed":"0x0","hash":"0x88e96d4537bea4d9c05d12549907b32561d3bf31f45aae734cdc119f13406cb6","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","miner":"0x05a56e2d52c817161883f50c441c3228cfe54d9f","mixHash":"0x969b900de27b6ac6a67742365dd65f55a0526c41fd18e1b16f1a1215c2e66f59","nonce":"0x539bd4979fef1ec4","number":"0x1","parentHash":"0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","size":"0x219","stateRoot":"0xd67e4d450343046425ae4271474353857ab860dbc0a1dde64b41b5cd3a532bf3","timestamp":"0x55ba4224","totalDifficulty":"0x7ff800000","transactions":[],"transactionsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","uncles":[]}}
@tjayrush Just one example below (I don't have time to test every RPC endpoint)
Thanks for this. It's helpful if you can provide an open source project reproducible examples. It saves the devs a lot of time fixing your issue.
(I'm not a dev by the way -- just a community member.)
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 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.
Don't close
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 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 bot does not make any sense at all because an issue without any activity does not mean the bug is fixed
Just getting my hands on a mainnet node - now I'm assigned the bot should leave this one alone - open to ideas for refining this.
Please re-open if the issue still happens with v2.59.2 or later.