eth: optimise initial transaction sync #1262
Assignees
Labels
Comments
|
@fjl This has been done, right? |
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
tony-ricciardi
pushed a commit
to tony-ricciardi/go-ethereum
that referenced
this issue
Jan 20, 2022
…#1263) ### Description This changes the `light.serve` default back to zero so that serving light clients becomes opt-in rather than opt-out. The reason is that there are many use-cases for running a node that don't involve light clients, and only one use-case that is about serving light clients, so it makes more sense to have it opt-in to avoid people running the light server without realizing it. ### Other changes * Change `light.maxpeers` default value from 99 back to 100 (the change to 99 was to work around an issue that no longer exists, see below under "Related issues") * Fix a bug in the logic for the `lightPeers` variable in `SetP2PConfig()` (it was not respecting the default value of LightPeers, leading to incorrect values in the `Maximum peer count` log line and to `MaxPeers` not being increased when it should have been. ### Tested * Automated tests pass * Without specifying any flags, LES is off, max peers is 175 * Specifying `--light.serve 100`, LES is on, total max peers is 275, max eth peers is 175, max light peers is 100 * Specifying `--light.serve 100 --light.maxpeers 200`, LES is on, total max peers is 375, max eth peers is 175, max light peers is 200 * Specifying `--light.serve 100 --maxpeers 150`, LES is on, total max peers is 250, max eth peers is 150, max light peers is 100 * Specifying `--light.serve 100 --light.maxpeers 1000 --maxpeers 100`, LES is on, total max peers is 1100, max eth peers is 100, max light peers is 1000 (these are the flag values recommended in the docs for serving light clients, and are based on the fact that if (and only if) you specify both `light.maxpeers` and `maxpeers` then `maxpeers` is assumed to include `light.maxpeers`) ### Related issues - Closes ethereum#1262 - Additional context: ethereum#395, ethereum#416, ethereum#864 ### Backwards compatibility Breaking change to the defaults, most notably `--light.serve`, but with limited impact, because in the docs for running a full node we specify `--light.serve`, `--light.maxpeers` and `--maxpeers`, so it's not relying on the defaults anyway. And for users who are not intending to serve light clients, the new defaults make more sense.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Under normal conditions, most nodes will have the current transactions in their pool.
When a connection starts up, all current transactions are sent in both directions.
We can mimise the amount of transactions sent by tracking which txs where sent by the remote side
and excluding those from the initial sync. If transactions to send were picked randomly, this would
ensure that most transactions would only be sent once.
The text was updated successfully, but these errors were encountered: