You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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 poorlyThe text was updated successfully, but these errors were encountered: