Skip to content

Remove excess consensus state messages #2710

@evan-forbes

Description

@evan-forbes

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

No one assigned

    Type

    No type

    Projects

    Status

    Needs Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions