Consensus Vote

Overview

Votes let distributed participants convert individual observations into a collective consensus decision. CometBFT validators send prevotes and precommits for a block or nil during a round. Ethereum validators publish attestations that support a chain head and checkpoint links. Other protocols use prepare, commit, certificate, or notarization messages. The names differ, but each vote is meaningful only inside the state machine that defines it.

A valid vote includes enough context to prevent reuse in another decision. Height, round, block ID, vote type, chain domain, and protocol version can be part of the signed bytes. Signature Verification establishes cryptographic authenticity, while validator-set checks establish eligibility and weight. A vote signed for one round cannot be silently counted toward another, even if it references the same block.

Nodes collect compatible votes and determine whether they reach a Consensus Quorum. Missing votes can stall progress. Conflicting votes by the same validator can be evidence of equivocation and may lead to slashing or removal. Different validators voting for different candidates can be normal before convergence, provided the protocol’s locking and quorum rules prevent incompatible commitments.

Consensus votes are usually infrastructure evidence rather than direct payment events. Payment systems should consume verified canonical and finalized states, but operators may inspect vote participation when finality is delayed. Records used for audits or light-client verification should preserve the signer set, voting weights, message root, block reference, and validator-set version. Counting signatures without these details can overstate support and create false settlement confidence.

Vote evidence should also be retained long enough to investigate equivocation, disputed finality, and validator-set changes without relying only on a later summary status.