the log line here was the culprit for the race. made sense to just
capture this on localnode creation instead and hold onto it for when the
server is started.
ran test with `-race` and `-count=5000` to double check and all looks
good
Hi,
I'm syncing Gnosis on a Celeron N5100 to get familiar with the codebase.
In the process I managed to optimize some things from profiling.
Since I'm not yet on the project Discord, I decided to open this PR as a
suggestion. This pass all tests here and gave me a nice boost for that
platform, although I didn't have time to benchmark it yet.
* reuse VM Memory objects with sync.Pool. It starts with 4k as `evmone`
[code
suggested](0897edb001/lib/evmone/execution_state.hpp (L49))
as a good value.
* set32 simplification: mostly cosmetic
* sha256-simd: Celeron has SHA instructions. We should probably do the
same for torrent later, but this already helped as it is very CPU bound
on such a low end processor. Maybe that helps ARM as well.
This PR adds missing tests for eth_getProof and does some mild
refactoring with switching from strings to more strict types. It's
likely best/most easily reviewed commit by commit.
Note, the tests include quite a number of helper types and functions for
doing the proof validation. This is largely because unlike Geth,
Erigon's approach to trie computations only requires serializing the
trie nodes, not deserializing them. Consequently, it wasn't obvious how
to leverage the existing trie code for doing deserialization and proof
checks. I checked on Discord, but, there were no suggestions. Of course,
any feedback is welcome and I'd be happy to remove this code if it can
be avoided.
Additionally, I've opted to change the interface type for `GetProof` to
use a `common.Hash` for the storage keys instead of a `string`. I
_think_ this should be fairly safe, as until very recently it was
unimplemented. That being said, since it's an interface, it has the
potential to break other consumers, anyone who was generating mocks
against it etc. There's additionally a `GetStorageAt` that follows the
same parameter. I'd be happy to submit a PR modifying this one as well
if desired.
Also, as a small note, there is test code for checking storage proofs,
but, storage proofs aren't currently supported by the implementation. My
hope is to add storage proofs and historic proofs in a followup PR.
---------
Co-authored-by: Jason Yellick <jason@enya.ai>
I was walking the code to try to understand in a bit more detail how the
state root hash is constructed and stumbled across
`retain_list_builder.go` as a consumer of the retain list APIs. But, as
far as I can tell, this file doesn't seem to actually be used anywhere
(including tests), and, it's seen no development (other than import
fixes) since 2020 or so. All linting and tests still pass for me locally
without it, so, I believe it's safe to simply remove.
Co-authored-by: Jason Yellick <jason@enya.ai>
Gateway reported an issue with a trace returning an odd result, similar
to the recent problem we'd seen with gnosis. I found that
debug_traceTransaction worked fine so found where the differences were.
trace_transaction wasn't checking for service transactions so the trace
failed around fees when it shouldn't.
A number of code paths use callManyTransactions so they should all now
check for service messages where needed.
