5

Is there a reason that geth propagates new txs to all peers but parity only propagates txs to 1/sqrt(n) (on average) peers? I see a comment in geth to the effect of //FIXME include this again: peers = peers[:int(math.Sqrt(float64(len(peers))))] (https://github.com/ethereum/go-ethereum/commit/8fe01b4bfa28ad5a1fdde7f9837e8f982843389a) but it seems that that was put in 3 years ago

1

This would answer your question: https://github.com/ethereum/aleth/issues/5277

Namely:

Propagating to all peers would lead to O(nm) messages being sent, where n is the number of nodes and m the number of peers per node - this devolves to O(n^2) in a fully connected network. If we propagate to sqrt(m) peers, then in a fully connected network we send O(n * sqrt(n)) messages, which grows much slower.

There's a "diminishing returns" argument for propagating to all nodes; i.e. it takes computational effort but doesn't significantly improve global transaction throughput beyond the initial sqrt(len(peers)). This probably comes from some network/graph theory research.

1
  • Oh, and to answer your question about the difference between Geth and Parity: there are obviously trade-offs between efficiency and accuracy; e.g. > the reason transactions are propagated to all peers is to avoid gaps if we start propagating transactions to sqrt peers, we'll fill up every txpool with nonce gaps, causing transactions to be dumped So different implementations come to different conclusions about such things. – Sasa Milic Feb 9 at 23:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.