Vote rebroadcasting overhaul

[pwojcikdev]

This PR reworks the vote_rebroadcaster component, making vote rebroadcasting "smarter". Previously we used a simple queue with a naive filter which rebroadcasted all processed votes. Because a vote can contain up to 255 hashes and the same vote can be processed multiple times depending on the exact timing of election activation, this introduced a rather significant inefficiency where we could be rebroadcasting the same vote multiple times, wasting bandwidth.

Here an index is added to track and filter rebroadcasts (with configurable limits, but here are the defaults):

• tracking the top 100 representatives by weight
• per-representative history of up to 32k most recent votes and block hashes
• a 90-second minimum interval between rebroadcasts of the same hash from the same representative (if a vote switches to final vote we rebroadcast immediately, ignoring the cooldown)
• additional vote deduplication by vote hash to avoid rebroadcasting identical votes

Queuing of votes to rebroadcast is now using weighted fair queuing based on rep tiers. Under saturation higher weight reps' votes will get larger proportion of available bandwidth while still reserving some capacity for lower weight reps (by default, tier_3 gets ~55%, tier_2 gets ~30% and the rest goes to tier_1 reps). Each tier's share scales with a configurable priority coefficient.

[gr0vity-dev-bot]

Test Results for Commit 6f53c50

Pull Request 4849: Results
Overall Status: ✅

Test Case Results

• ✅ 5n4pr_conf_10k_bintree: PASS (Duration: 114s)
• ✅ 5n4pr_conf_10k_change: PASS (Duration: 154s)
• ✅ 5n4pr_conf_change_dependant: PASS (Duration: 140s)
• ✅ 5n4pr_conf_change_independant: PASS (Duration: 130s)
• ✅ 5n4pr_conf_send_dependant: PASS (Duration: 133s)
• ✅ 5n4pr_conf_send_independant: PASS (Duration: 132s)
• ✅ 5n4pr_rocks_10k_bintree: PASS (Duration: 118s)
• ✅ 5n4pr_rocks_10k_change: PASS (Duration: 196s)

Last updated: 2025-02-20 14:24:59 UTC