Consensus Node

Overview

Consensus nodes maintain a view of blockchain height, round or slot, candidate blocks, votes, and canonical state. They verify incoming data, relay messages to peers, and apply the fork-choice or state-machine rules that determine progress. In CometBFT, a node can participate in relaying proposals, blocks, and votes without possessing a validator private key. A validator node adds the ability and responsibility to sign consensus votes.

This distinction matters operationally. A non-validating node can independently verify history and serve application queries but contributes no voting power. A validator node influences consensus according to its assigned weight and must protect an online signing key from compromise or double signing. One operator may run several machines, yet the protocol can still recognize only one validator identity or voting allocation.

A consensus node can be synchronized, lagging, partitioned, misconfigured, or connected to the wrong network. Applications should verify chain identifiers, software versions, peer health, and current height before trusting responses. A node’s local Best Chain is not automatically the global final state, especially during an incident. High-value payment infrastructure can compare independent nodes while using protocol finality as the primary settlement evidence.

Operators need monitoring for missed votes, message latency, disk or database errors, clock issues, and incompatible upgrades. Validator nodes also need remote-signing or hardware controls, double-sign prevention, and tested recovery. A healthy node does not guarantee network health, and a failed node does not necessarily mean Consensus Failure. The impact depends on how much voting power or data availability the affected participants represent.