erigontech
trace_transaction hash inconsistency
System information
Erigon version: ./erigon --version
v2022.08.01
OS & Version: Windows/Linux/OSX
Linux
Commit hash :
Expected behaviour
{
"jsonrpc": "2.0",
"id": 1,
"result": [
{
"action": {
"from": "0x2b333ae41632c0266ae275e811bb5eeb3f21fd03",
"callType": "call",
"gas": "0x5f64",
"input": "0x095ea7b30000000000000000000000001e0049783f008a0085193e00003d00cd54003c71ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"value": "0x0"
},
"blockHash": "0xd31fbe1dd0e247d7084e91bb8c6041abcee777c77dd83dcaa571d4fbd93c0fb1",
"blockNumber": 15315375,
"result": {
"gasUsed": "0x5f64",
"output": "0x0000000000000000000000000000000000000000000000000000000000000001"
},
"subtraces": 0,
"traceAddress": [],
"transactionHash": "0x6d0a4fdc4ea75e998038ef225f72c60c11997fd1ecdd82f4dde6205ec9532c5b",
"transactionPosition": 31,
"type": "call"
}
]
}
Actual behaviour
{
"jsonrpc":"2.0",
"id":1,
"result":[
{
"action":{
"from":"0xba9aef1909662f7e7a271ad0d512b772a8d962b5",
"callType":"call",
"gas":"0x35a0",
"input":"0xf7654176",
"to":"0xfa52274dd61e1643d2205169732f29114bc240b3",
"value":"0xdd88b644262218c"
},
"blockHash":"0xaf5545b6315dd184cb11a0fb2d027aa663d732d8c22985bf4bb0ae178a1dbab9",
"blockNumber":2441022,
"result":{
"gasUsed":"0x229b",
"output":"0x"
},
"subtraces":1,
"traceAddress":[
],
"transactionHash":"0x10723e078173d5f2bf0e1c08be895b6b437c601aa02db952fa5bb8f13f732410",
"transactionPosition":0,
"type":"call"
},
{
"action":{
"from":"0xfa52274dd61e1643d2205169732f29114bc240b3",
"callType":"call",
"gas":"0x8fc",
"input":"0x",
"to":"0x267be1c1d684f78cb4f6a176c4911b741e4ffdc0",
"value":"0xdd88b644262218c"
},
"blockHash":"0xaf5545b6315dd184cb11a0fb2d027aa663d732d8c22985bf4bb0ae178a1dbab9",
"blockNumber":2441022,
"result":{
"gasUsed":"0x0",
"output":"0x"
},
"subtraces":0,
"traceAddress":[
0
],
"transactionHash":"0x10723e078173d5f2bf0e1c08be895b6b437c601aa02db952fa5bb8f13f732410",
"transactionPosition":0,
"type":"call"
}
]
}
Steps to reproduce the behaviour
curl -s --data '{"id":1,"jsonrpc":"2.0","method":"trace_transaction","params":["0x6d0a4fdc4ea75e998038ef225f72c60c11997fd1ecdd82f4dde6205ec9532c5b"]}' -H "Content-Type: application/json" -X POST http://localhost:8545 | jq
This is a bit difficult to reproduce, but TLDR every so often when I call trace_transaction with txn hash A that is close to head (as reported by geth, which erigon might not know about yet) I will get back a response with txn hash B that is completely unrelated (often times for a block that is far back in the future - see example above). Note that eventually I will get back the proper response with txn hash A. Also note that my node is running the rpcdaemon in local mode with --datadir specified.
Some possible theories/questions as to what could be going on:
- This could possibly be a race condition related to reorgs. Is trace_transaction safe against reorgs?
- This could possibly be a syncing issue with shared memory in local mode. Is all state necessary for trace_transation updated atomically?
- This could possibly be a caching issue. Is any state necessary for trace_transacation cached?
Has anyone else run into this issue/is able to reproduce?
Backtrace
[backtrace]
I have a similar situation with eth_getBlockReceipts, it also returns incorrect data but will eventually solve itself. Will post more info when I have gathered enough data
