Gossip: Add dynamic stake weighting based on fraction of unstaked nodes

[gregcusack]

Problem

This PR addresses this Issue: #6903
Unstaked and low staked nodes in gossip do not receive many messages on testnet due to the testnet stake distribution and the aggressive quadratic weighting of peers by stake. As a result, unstaked nodes have a poor and inconsistent view of the peers in the network.

Linear weighting is not aggressive enough and causes a disproportionate number of messages to be sent to unstaked nodes on mainnet.

We need weighting that falls in between linear and quadratic.

Summary of Changes

Add a dynamic weighting element alpha. alpha fluctuates between 1 and 2 at runtime and is linearly proportional to the number of unstaked nodes in the cluster.
For example, on mainnet, there are 82% unstaked nodes, so alpha will converge on 1.82. On testnet, there are 4% unstaked nodes, so alpha will converge on 1.04.

We use a first-order, low-pass filter to update alpha to avoid constant alpha thrashing and overshooting the new target. Unit tests show that alpha converges on the target alpha within approximately 4-5 push active set rotations (30-38s).

Note: floating point operations are expensive but rotate() is called once every 7.5s, so should not add any significant overhead.

Testing has shown that flattening out the weight curve when their aren't many unstaked nodes (as on testnet), increases an unstaked nodes ingress gossip traffic as desired. On the other hand, high staked nodes don't see a significant reduction in received traffic.

All calculations and data that backup and support this PR here:

1. Statistical Gossip Propagation Analysis
2. Low Pass Filter Discussion on Discord
3. Testing data on mininet and using statistical analysis on Discord

[alexpyattaev]

Should we extract the IIR filter into its own module and stick it in net-utils or something like it? Would make it far easier to test and also to guard against possible invalid inputs and such.

[gregcusack]

ya i think that's a good idea. locally, i have it pulled out into a separate file within the gossip module. not sure it fits in net-utils since its not really a network-related method. maybe we leave in gossip module for now. but if anyone wants to reuse the filter in the future, we can pull it into it's own standalone module?

[alexpyattaev]

Does rust-analyzer not compute consts? Also would be nice to get an idea of how long this filter takes to reach 0.5 in response to a step input from 0 to 1.

[gregcusack]

oh it does on my end, i can remove the comment: // K ~ 0.611

[gregcusack]

good call. will add a comment in the code. But this is what it is:

/// - From a step change in target from 0 to 1, `alpha` reaches:
///   - ~61% of the way to target after 1 update
///   - ~85% after 2
///   - ~94% after 3
///   - ~98% after 4
///   - ~99% after 5
Each update occurs every 7.5s. So we reach 94% of the way to the target in 22.5 seconds

[alexpyattaev]

Would it not be better to have an explicit is_finite check followed by a clamp to the target range? Then we would not need to have an error here.

[alexpyattaev]

Overall the PR looks good, thank you!

[gregcusack]

@alexpyattaev Does it make sense to keep floating point math or switch over to fixed point? I have a fixed point implementation. Sounds like trent would prefer fixed point to avoid possible bugs even though we can try and make them as unlikely as possible.

[gregcusack]

i suggest we switch over to this pr with fixed point math: #7098

[alexpyattaev]

@alexpyattaev Does it make sense to keep floating point math or switch over to fixed point? I have a fixed point implementation. Sounds like trent would prefer fixed point to avoid possible bugs even though we can try and make them as unlikely as possible.

In this case it is not critically important, but floats require some extra caution around possible NANs. So if we can avoid them let us do so.

[gregcusack]

moving to: #7098