In Erlay, transaction can be sent to peers using fanout or reconciliation. In our current approach, we are selecting what peers to fanout to on a per transaction basis1️⃣, and we will be reconciling with the rest of our neighborhood. When selecting the fanout candidates for a given transaction, we could be filtering out the ones that already know about it (as in, those that may have sent us an INV
containing it). Independently of whether filtering is applied or not, the transaction should not be announced more than once. That is to say, if our target fanout rate is x
, and we are filtering out based on transaction knowledge, it could be the case that we end up faning out to a nu
However, the peer selection strategy may affect how the fanout rate evolves based on how propagated the transaction is.
When selecting fanout candidates for a given transaction, we could be filtering out the ones that already know about it (i.e., those that have already announced it to us). Regardless of whether filtering is applied, a transaction should not be announced more than once through the same link. However, filtering may affect the effective fanout rate, since the more propagated a transaction is, the more likely it is for a peer to receive multiple announcements of it. As a result, the filtered subset of peers may fall below the target fanout rate.
Filtering out nodes based on the knowledge of the transaction should have the effect that the fanout rate stays high when the propagation of the transaction is low, and it should decrease suddenly when the transaction reaches a bigger chunk of the network. This is because, as long as the number of peers that don’t know about the transaction is smaller than our fanout target rate, the rate would remain constant, and once the number grows too small, the remaining peers will be picked.
Not filtering peers should have a smoother effect. On average, nodes should be able to reach the target fanout rate when few of their peers know about the transaction, and mostly select peers that already know about it the further the transaction has propagated. However, being this a probabilistic approach, some nodes could be “unlucky” for the propagation of certain transactions, mostly selecting peers that already know about it, and relaying at a fanout rate below what would be expected based on how far the transaction has propagated.
To simulate the difference between these two approaches, a new filtering functionality has been added to the simulator that would filter fanout candidates based on their knowledge of the transaction (local knowledge, as seen by the node that makes the decision, not the global simulation knowledge). The code for this can be found at https://github.com/sr-gi/hyperion/pull/31
The main result of this simulation is that there is no significant difference between filtering or not, which, surprisingly, didn’t fit our thesis.
Here are the results of a network of 110000 nodes, 10000 reachable, 100000 unreachable with 8 outbounds per node without filtering:
2024-12-17T18:45:04.569Z INFO [hyper_lib::simulator] Using user provided rng seed: 14569482637851975056
2024-12-17T18:45:04.578Z INFO [hyper_lib::network] Creating nodes (110000: 10000 reachable, 100000 unreachable)
2024-12-17T18:45:04.721Z INFO [hyperion] The simulation will be run 100 times and results will be averaged
2024-12-17T18:49:49.995Z INFO [hyper_lib] Transaction reached 90% of nodes in the network in 20.593739s
2024-12-17T18:49:49.995Z INFO [hyper_lib] Reachable nodes sent/received 219.7265/365.32852 messages (715.5123/1067.8059 bytes) (avg)
2024-12-17T18:49:49.995Z INFO [hyper_lib] Unreachable nodes sent/received 31.987862/17.427662 messages (94.282135/59.05277 bytes) (avg)
The same simulation with filtering yields:
2024-12-17T18:56:26.415Z INFO [hyper_lib::simulator] Using user provided rng seed: 14569482637851975056
2024-12-17T18:56:26.422Z INFO [hyper_lib::network] Creating nodes (110000: 10000 reachable, 100000 unreachable)
2024-12-17T18:56:26.568Z INFO [hyperion] The simulation will be run 100 times and results will be averaged
2024-12-17T19:01:15.641Z INFO [hyper_lib] Transaction reached 90% of nodes in the network in 20.795815s
2024-12-17T19:01:15.641Z INFO [hyper_lib] Reachable nodes sent/received 222.6441/371.3514 messages (720.47595/1109.9666 bytes) (avg)
2024-12-17T19:01:15.641Z INFO [hyper_lib] Unreachable nodes sent/received 32.525223/17.654491 messages (98.37036/59.421295 bytes) (avg)