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

Priority Peer Broadcasting #180

Closed
jmank88 opened this issue May 17, 2018 · 1 comment
Closed

Priority Peer Broadcasting #180

jmank88 opened this issue May 17, 2018 · 1 comment

Comments

@jmank88
Copy link
Contributor

jmank88 commented May 17, 2018

Some of the peer broadcasts (e.g. tx broadcasts) go out to randomized subsets of peers. This is suboptimal, and we should be able to improve stability by prioritizing peers based on whether they are trusted, known to be a signer, or even based on who is likely to sign upcoming blocks. Essentially, it is more important for signers to be up to date than proxies or third party nodes, and it is most important that the next signer be up to date.

Every node in the network can't connect to the signer nodes at once, but if a node happens to have signing peers connected (randomly, or if it is signing itself), then I think it makes sense to favor those peers. So rather than a random sqrt(n) subset of peers, maybe we send to all signing peers and some others, up to a limit. Then again, maybe we can just send to all peers, and not limit to a subset at all. <- This is costly and scales poorly

@jmank88
Copy link
Contributor Author

jmank88 commented May 28, 2018

Another option to consider for txs would be to select the subset of peers based on the sender address. This would decrease the chance of txs from the same account arriving out of order, which wastes CPU cycles and holds locks while managing the pool queue, and increase the chance of the txs arriving in order and quickly slotting right into pending.
On the other hand, this only affects very high volume accounts (e.g. chainload), which may not be realistic. Additionally, any non-random subset selection will provide a similar benefit.

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

No branches or pull requests

2 participants