Consensus

Overview

Consensus allows independent nodes to converge on a shared ledger history without a central database administrator. It combines rules for valid state transitions with procedures for proposing, selecting, voting on, or extending candidate blocks. Consensus must address safety and liveness under a defined fault model. Safety prevents incompatible finalized decisions, while liveness permits continued progress when network and participant assumptions hold. Different protocols provide probabilistic or deterministic finality and tolerate different failures.

Integrators should identify the network’s fork choice, finality signal, fault threshold, and recovery behavior. A transaction being broadcast, executed by one node, or included in a recent block does not alone establish consensus-backed settlement. Recovery plans must reflect whether the design halts to preserve safety, permits temporary reorganization, or relies on social or governance intervention after exceptional failure. Production teams should monitor chain progress, competing branches, participation, and protocol-specific fault indicators.

Evaluation should cover the complete decision process: who may propose data, how other participants validate it, how competing histories are ranked, and what evidence makes an outcome difficult or impossible to reverse. A mechanism’s label does not define those details across every implementation. Safety, liveness, and accountability should be assessed separately under partitions and coordinated failures. Security assumptions depend on the resource or authority used to influence consensus, participant concentration, network timing, client behavior, and the cost of equivocation, censorship, or history revision. Payment applications relying on Consensus need network-specific confirmation and finality policies. Observing a block locally does not establish settlement. The system should confirm canonicality, execution success, and the network’s strongest finality evidence before irreversible fulfillment.