Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eth: don't enforce minimum broadcast, fix broadcast test #20678

Merged
merged 1 commit into from
Feb 17, 2020

Conversation

karalabe
Copy link
Member

@karalabe karalabe commented Feb 17, 2020

Currently we always propagate a block/transaction to at least 4 peers, even if the square root is less (e.g. if I have 5 peers, I will propagate to 4, not just to 2). As far as I know this was added when there was no announcement mechanism at all (i.e. eth/60).

I think this is misguided:

  • If a node is so unhealthy that it barely has a few connections, there's no point in pushing even more load onto it.
    • Every node will surely broadcast to at least 1 more peer (sqrt(whatever_gt_1) >= 1) and the announces will cover any gaps for super degenerate topologies.
  • If a node is healthy, it will always happen (when broadcast saturates the network) that most of its peers already sent it a block/tx, so PeersWithoutBlock and PeersWithoutTx will return a small subset of peers. With the enforced 4 peer propagation, the node will send the block/tx forward to 4 further peers, even if 46 out of 50 peers already know of it, which is pointless.
    • Announces should handle degenerate connections, everything else can still be saturated with sqrt(whatever) (since sqrt(whatever_gt_1) >= 1, so we will always send the block in its entirety to at least one peer).

The PR also reduces the test time of the BroadcastTest from 18 seconds to 1.

@karalabe karalabe added this to the 1.9.11 milestone Feb 17, 2020
@karalabe karalabe merged commit c211798 into ethereum:master Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants