Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Peers list should include some unmatched broadhash peers to broadcast to #2025
When broadcasting, we should broadcast not only to peers which match our own broadhash but also to peers which do not match our broadhash (because they might be behind).
Right now when doing a broadcast, a node will try to select 100 peers in total; if it finds fewer than 100 peers with a matching broadhash, then it will select remaining peers which do not match its broadhash.
If our node is able to find 100 peers which match its own broadhash, then it will not broadcast to any non-matching peers (after it selects 25 from those 100); this means that the remaining (non-matching) peers in the network may not receive the latest block from our node.
Steps to reproduce
Run on latest betanet; some of the nodes fall behind the latest height because some blocks are not reaching them.
Which version(s) does this affect? (Environment, OS, etc...)
I believe broadcast should only be done to matched broad hash peers at least if we have them to maximum of our required limit. e.g. As we have 25 limit, so we should select 25 from matched broadhash and if we found less than we take more from unmatched boardhash. This is a good way to optimize network load if there is a real fork going on in the network. Consider that broadcast is almost a realtime event going in the network, and we should optimize it for network capacity.
The safeguard and fork recovery should rely on syncing mechanism. During syncing, it should ask look for every peer in network to build the histogram irrespective of broadhash. So it could pull the blocks and can perform fork recovery.
There can be edge cases in above syncing mechanism, that we should discuss and consider thoroughly further with actual cases.
I think main purpose of the broadcast is to broadcast whatever new information it gets to the peers that they know of.
I agree that syncing on the other hand, main purpose is to sync up to the network if the node falls behind. It should only take information from a "good peer" from network prospective (not node prospective).
I think, in theory, we should be only connecting to "good peer" outbound and let "bad peer" to connect to you to become "good".
referenced this issue
May 12, 2018
There is some inconsistency, possibly not the best logic also.
So behavior is slightly different between versions. In
We were able to find a fix to the betanet block propagation issue issue without having to change the broadcast algorithm. See #2031
Since the current broadcast algorithm is essentially the same as the one used in 0.9, I think that it makes sense to keep it as it is in order to minimise change/risk.
I agree with Shu though that it would be nice to not have to take into account the broadhash when doing broadcast but I guess it would require changes to peer discovery/selection first. I guess this would be an enhancement so could potentially be done after 1.0.