Consensus Message

Overview

Consensus protocols rely on structured communication rather than informal node agreement. A proposer can broadcast a candidate block, validators can send prevotes or precommits, and peers can exchange information about known votes or current round state. Proof-of-stake systems can use attestations that support a head and checkpoints. Each message is interpreted within a specific height, round, slot, committee, or epoch.

Authentication prevents an observer from inventing another validator’s message, but verification also checks context. The signer must belong to the relevant validator set, the message must use the expected domain and version, and duplicate or conflicting messages may constitute slashable evidence. A correct Digital Signature on the wrong height or message type is not a valid consensus contribution.

Messages are inputs to consensus, not final decisions. Nodes collect them, apply locking and fork-choice rules, and determine whether their combined voting power reaches a Consensus Quorum. Delayed, missing, or reordered messages can slow progress without violating safety. Conflicting messages from one validator can reveal equivocation, while conflicting messages from different validators may be normal before the protocol converges.

Operators should monitor message propagation, participation, and validation errors without exposing private signing keys. Logs and evidence should preserve message type, signer, block ID, height, round, and verification result. Payment applications normally consume higher-level canonical and finality states rather than raw consensus traffic, but understanding messages helps diagnose stalled finality, provider disagreement, and incidents in which ordinary confirmation assumptions no longer hold.

Message schemas can change at protocol upgrades, so validators and monitoring tools must apply the serialization and domain rules active for the relevant height or epoch.