-
Notifications
You must be signed in to change notification settings - Fork 357
Open
Labels
Description
I noticed that many of my nodes will still hit a consensus reactor queue limit (currently set to 5000 at the time of writing).
There are a large amount of state messages that, while quick to process, also seem to not serve a ton of purposes.
this was written by codex but matches my understanding:
HasVote (StateChannel) — broadcast for every new local vote (broadcastHasVoteMessage, lines 561‑643). Only signals “I have vote (H,R,type,index)”; triggers peers to mark that vote as available. Pure optimization for vote gossip; protocol would still work without it (more redundant vote traffic).
VoteSetMaj23 (StateChannel) — gossiped in queryMaj23Routine (lines 1059‑1146) whenever we see a 2/3 majority for prevotes or precommits at the peer’s height/round (and for POL round or catch‑up commit). Also sent as a reply path for catch‑up commits. It asks the peer to tell us which votes it has for that block. Optional liveness aid under vote-flood/DDoS; could be dropped, increasing bandwidth but not breaking correctness.
VoteSetBits (VoteSetBitsChannel, priority 206) — sent only in response to VoteSetMaj23 (lines 344‑381, 433‑472). Carries our bitarray of votes for the claimed BlockID so the asker knows which votes to request or resend. Optimization only; removable with more blind vote gossip.
the main benefit of removing would likely being reducing the amount of logic in the consensus reactor/state
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Needs Triage