The peer ID in sentry.proto is a H512 / 64 bytes value, and
MarshalPubkey creates it from a public key.
There's no need to cut the first byte, because MarshalPubkey already
does it.
Doing so results in a 63 bytes value that is incompatible with silkworm
sentry.
@shyba hi, seems this lib doesn't work with
ghcr.io/goreleaser/goreleaser-cross (which producing release binaries)
removing it for now, feel free to add it in future - if can make it work
with goreleaser-cross
see: https://github.com/ledgerwatch/erigon/issues/7210
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.
Regarding https://github.com/ledgerwatch/erigon/issues/6260
added flag `--p2p.allowed-ports=<porta>,<portb>` to restrict which ports
to use for sentries for different protocol versions.
Default for this flag is `30303, 30304` (first port is inherited from
`--port` flag defaults.
If `--port` is changed and it's new value is not presented in allowed
port list, provided port will be allowed as well as list provided via
`--p2p.allowed-ports`
Port picking is straightforward, we create sentry gRPC server for
protocol over first allowed port that is not already taken.
If there are no allowed ports left, erigon exits with hint.
Previously "in-memory" MDBX instances for fork validation and mining
were created inside `os.TempDir()`. We should create them inside
Erigon's datadir so that the file permissions and the disk are the same
as for the main database.
Prerequisite: https://github.com/ledgerwatch/erigon-lib/pull/676.
* Add eth/67
* Listen to eth/66 on a separate port
* Fix compilation error
* Fix cfg66.ListenAddr
* Update erigon ports in README
* Expose port 30304 in docker
* P2pProtocolVersionFlag instead of second sentry
* Remove "66 by default" from usage
* Small comment
--nat stun is an automatic external IP detection alternative to manual --nat extip option.
It can be used both at home or on production servers without any extra setup.
It is fast (up to 5 ms) and more reliable than alternatives (as the request goes to the public internet).
This auto-detection is useful to run multiple instances of a service in cloud environments
where the node IPs are not known in advance.
The test fails sometimes on macOS CI with:
v5_udp_test.go:477: unexpected error: "RPC timeout"
Fixing by increasing the timeout from 120ms to 700ms,
and move the test to the integration suite, because it takes up to 1s now.
* TestTable_ReadRandomNodesGetAll: refactor to integration and examples
* TestTable_bumpNoDuplicates: refactor to integration and examples
* TestUDPv4_smallNetConvergence: speed up from 1.7s to 0.3s by applying the test config
* TestUPNP_DDWRT: move to integration tests
* TestFairMix: split in 2, do more iterations in integration tests
* TestDialSched: speed up from 1s to 0.2s by removing the unexpected dial check,
(keep the check during the integration tests)
* configure a 50 ms timeout for tests (like v4 tests)
* use in-memory DB (like v4 tests)
* TestUDPv5_callTimeoutReset: improve speed from 1.2s to 0.2s
* TestUDPv5_callTimeoutReset: reduce the likelihood of "RPC timeout"
* move lookup tests to the "integration" suite
* log details of unmatched packets and sends to non-existing nodes
* fix flaky TestUDPv5_findnodeHandling:
Table.nextRevalidateTime was random (from 0 to 10s).
Sometimes it triggered doRevalidate immediately, and it produced an unexpected ping.
Configure a high interval to not revalidate during the tests.
Time improved from 1.7s to 0.2s.
Test with:
go test ./p2p/discover -run TestUDPv5 -count 1
The test is flaky when the reply timeout is too low.
Increasing the timeout makes it slow.
Move the test to the integration suite.
Having a higher timeout is fine there.
