Thesis

For an optimal network bandwidth utilization when relaying transactions, the fanout rate should be higher the earlier in the transaction propagation state, and lower the later. This is due to fanout being more efficient (and faster) than transaction reconciliation provided the receiving node doesn’t know about the transaction. This means that, in a perfect world, we could start with a high fanout rate to reach a high portion of the network (with minimal redundancy), and slowly scale the fanout down to relay more on set reconciliation when the transaction has spread enough.

Unfortunately, precise knowledge of how far a transaction has propagated along the network is not something the receiver node possesses. We have previously tried to use the number of announcements a node has received about a given transaction as a proxy for this, but it has turned out to work mostly for reachable nodes, but not as much for unreachable (see Filter fanout candidates based on transaction knowledge).

An alternative approach is checking under what method the transaction was received as part of the decision-making to propagate the transaction further. That is, have a fanout rate if the transaction was received via fanout, and a different one if the transaction was received via set reconciliation. Being fanout significantly faster than set reconciliation, it would be expected to the first nodes the learn about a given transaction would do so through fanout, so having a higher propagation rate if the transaction was received via fanout, and a smaller one if it was received via set reconciliation may be a good enough approximation to our ideal solution.

Simulation

To simulate this, we’ll be using a patched version of the simulator that will scale the fanout rate based on how a node received the simulated transaction. The code can be found at https://github.com/sr-gi/hyperion/commit/a0f11424dac30a2bebc22cd534f98a2d9de36cf8.

The simulation will be built on the following two assumptions:

• The fanout rate when receiving a transaction via fanout needs to be higher, but not too high. This is to prevent too much redundancy, given some nodes will still be receiving the transaction via fanout even by the end of the transaction propagation.
• We can scale up the number of outbound connections to fanout to, but the number of inbounds must remain constant. This is to prevent malicious peers from knowing what fanout rate we used by simply establishing multiple connections to our node.

To run the experiment we simply need to define the corresponding env variables representing the low and high fanout targets: OUTBOUND_FANOUT_DESTINATIONS and OUTBOUND_FANOUT_DESTINATIONS_HIGH. An example would be:

OUTBOUND_FANOUT_DESTINATIONS=1 OUTBOUND_FANOUT_DESTINATIONS_HIGH=4 cargo run --release --erlay -n 100

As with all our previous simulations, we will create a network of 110000 nodes, 10000 reachable, 100000 unreachable. In this case, we will run 3 different simulations, corresponding to 8, 10, and 12 outbound peers respectively, as we previously did for Find acceptable target number of peers to fanout to. Every simulation will be run 100 times, with the same random network, picking a different source every time, and the results will be averaged.

The results will be compared with out baseline (same network, no Erlay), as well as with the setting for the currently implemented approach: 1 outbound and 10% of inbounds.

Result

We run simulations for the three following cases (on top of or reference points) 1️⃣:

• 1/10% + 4/10%
• 1/10% + 6/10%
• 1/20% + 4/20%