reth: trace compatibility testing with Trueblocks
Describe the bug
trying to create a local trueblocks unchained index, I’m getting some warnings:
Unknown trace type selfdestruct
Unknown trace type selfdestruct
Unknown trace type selfdestructng 391 of 2000 at block 11182389 of 17659147 (6476758 blocks from head)
Unknown trace type selfdestruct
Unknown trace type selfdestruct
I’m not clear how impactful this particular warning is to Trueblocks operation, but it points to something non-standard in Reth’s trace implementation.
Digging into this further, I couldn’t find specifically where in the trueblocks or erigon codebases they deal with selfdestruct in a way that could explain this discrepancy.
However, Trueblocks has a long list of tests for expected tracing functionality in /src/other/trace_tests/curl_tests. Running these on my reth node, I get a difference from expected for 26 out of 35 tests. You can find the diffs of those tests in this PR: https://github.com/TrueBlocks/trueblocks-core/pull/3037/files
@tjayrush could explain these further.
Steps to reproduce
reproduce warnings above:
- sync erigon
- install trueblocks
- run
chifra scrape
get comparison vs. expected Trueblocks trace tests
- run_all in /src/other/trace_tests/curl_tests of trueblocks repo (modify line 3 as needed:
export RPC_ENDPOINT="http://localhost:23456") - compare_expected_produced.sh
Node logs
No response
Platform(s)
Linux (x86)
What version/commit are you on?
reth Version: 0.1.0-alpha.2 Commit
SHA: 1330fc11
Build Timestamp: 2023-07-08T22:15:01.820025074Z
Build Features:
Build Profile: release
What database version are you on?
Current database version: 1 Local database is uninitialized
If you’ve built Reth from source, provide the full command you used
cargo build --release
Code of Conduct
- I agree to follow the Code of Conduct
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 25 (7 by maintainers)
I got my hands on an erigon node. Here are the reth vs. erigon results:
You can find the diffs here: https://github.com/wakamex/trueblocks-core/tree/compare_script/src/other/trace_tests/curl_tests/reth_erigon
See this PR for the scripts I used, or run it yourselves: https://github.com/TrueBlocks/trueblocks-core/pull/3037
I thought I’d add some color to some of these test cases. This is from memory, so take it with a grain of salt, but…
These failed tests return
nullinstead of[]for traceAddress. This should be simple to fix.We thought that someone had hand-coded assembly language for this transaction and had made a mistake, so reporting an error is correct. The error, I think, is correct if you look at the actual data. Not sure why it’s saying something about the nonce.
Be a little bit careful with this one. I’m not sure this is the exact transaction, but I remember that OpenEthereum may have had a bug in certain places where the first trace in some transactions was incorrectly reported. Erigon found may have hit on this same issue (which is why this test is included). If I remember right, Erigon ended up adding a “compatibility” mode for some cases where they would act correctly by default but allow the user to cause old OpenEthereum bugs to persist. I don’t know if this is such a case, but be careful here.
This may have been one of those backward compatibility things. The spec may say it requires a u64, but most of the other RPC endpoints require hex. So, as a compromise, even thought it’s not in the spec, this was allowed. The spec is not really a spec after all.
Personally, I think better error messages are better, but this may break existing code. It won’t break TrueBlocks, but it may break others.
Just a quick note. These tests are purposefully using
curl(as opposed to say, TrueBlocks) so as to eliminate any weird processing in TrueBlocks. Thecurlresponses from both nodes should be identical (at least that’s what I think).