Finality

The core guarantee of finality is that once a block of transactions is finalized, it becomes immutable and cannot be reverted or altered. This provides a permanent settlement layer, crucial for financial transactions and state updates. In Byzantine Fault Tolerant (BFT) protocols like Tendermint, this is achieved through a supermajority of validators cryptographically committing to the block.

• Absolute vs. Probabilistic: Some protocols offer absolute finality (e.g., BFT-based), while others like Nakamoto Consensus (Bitcoin) provide probabilistic finality, where reversion risk decreases exponentially with each subsequent block.

Finality is deeply tied to the fundamental safety-liveness trade-off in distributed systems, as defined by the FLP impossibility result.

• Safety: The guarantee that all correct nodes agree on the same finalized history. A system prioritizing safety will halt progress rather than risk finalizing conflicting blocks.
• Liveness: The guarantee that the system will eventually produce new finalized blocks. Protocols must be designed to ensure progress even with faulty validators.

Finality mechanisms explicitly prioritize safety, ensuring that once a value is agreed upon, it is correct and permanent, even if it temporarily impacts the rate of progress.

The method for achieving finality is dictated by the underlying consensus algorithm.

• Voting-Based Finality: Used in BFT and Proof of Stake (PoS) variants. Validators explicitly vote in rounds to finalize blocks. Examples include Tendermint's two-phase voting and Ethereum's Casper FFG checkpoint finality.
• Probabilistic Finality: In Proof of Work (PoW), finality is economic. A block is considered "final" when the computational cost to reorganize the chain (via a 51% attack) becomes prohibitively expensive. The longest chain rule is the fork choice rule.
• Instant vs. Delayed: Instant finality protocols (e.g., BFT) finalize blocks within a single round. Delayed finality protocols (e.g., PoW, some PoS) require multiple confirmations or epochs.

Finality is enforced through a combination of cryptography and economic incentives designed to make attacks cost-prohibitive.

• Cryptographic Proofs: Digital signatures from validators provide verifiable proof of agreement. Threshold signatures can aggregate these for efficiency.
• Staking and Slashing: In PoS systems, validators lock capital (stake) as collateral. Provably malicious acts like equivocation (signing conflicting blocks) trigger slashing, where the stake is destroyed. This creates a strong economic disincentive against attacking finality.
• Cost of Attack: The security of finality is measured by the astronomical cost required to revert a finalized block, often requiring control of a supermajority of staked value or hash power.

A key property of finality-granting protocols is the ability to detect and punish validators who attempt to create conflicting finalized states, a critical defense against long-range attacks.

• Equivocation: This occurs when a validator signs two different blocks at the same height. In protocols with accountable safety, cryptographic evidence of this fault (slashing conditions) can be produced and punished.
• Finality Gadgets: Protocols like Casper FFG are designed as an overlay that adds accountable finality to an underlying chain. They define checkpoints and punish validators who finalize conflicting checkpoints.
• This accountability is what distinguishes finality from mere probabilistic settlement, as it provides a mechanism to penalize Byzantine behavior after the fact.

Finality is the property that enables State Machine Replication (SMR), a core technique for building fault-tolerant services. In SMR, a set of replicas must all execute the same sequence of commands in the same order.

• Atomic Broadcast: Finality solves the Atomic Broadcast problem—guaranteeing that all correct replicas deliver the same messages in the same order. A finalized block represents a delivered batch of commands.
• Linearizability: For client operations, finality helps achieve linearizable consistency. Once a transaction is finalized, its result is permanently visible to all participants, appearing to take effect instantaneously at the point of finalization.
• This makes finality essential not just for blockchains, but for any distributed system requiring a single, authoritative history of events.

In distributed consensus, safety is the guarantee that all correct processes in the system agree on the same value and that a faulty process cannot cause the system to decide on an incorrect or contradictory value. It is the assurance that nothing bad happens, meaning the system never reaches an inconsistent state. Safety is often paired with liveness and is prioritized in systems where correctness is paramount, such as financial ledgers.

• Core Property: Prevents consensus on invalid or conflicting data.
• Trade-off: Strong safety guarantees can sometimes come at the cost of latency or availability during network partitions.

Liveness is the guarantee that a distributed system will eventually make progress and decide on a value, despite delays or failures of some participants. It ensures that something good eventually happens—the system does not halt indefinitely. In blockchain contexts, liveness means new transactions will eventually be confirmed.

• Core Property: Ensures the system continues to produce outputs over time.
• Trade-off: Pursuing maximum liveness can sometimes weaken safety guarantees under certain failure conditions. The CAP theorem formalizes the inherent tension between consistency (related to safety) and availability (related to liveness).

Byzantine Fault Tolerance (BFT) is a property of a distributed system that allows it to reach consensus and continue operating correctly even when some of its components fail arbitrarily, including through malicious or "Byzantine" behavior. Protocols like Tendermint Core and PBFT achieve this. BFT is a prerequisite for deterministic finality in adversarial environments.

• Failure Model: Handles nodes that may lie, send conflicting messages, or otherwise deviate from the protocol.
• Threshold: Classical BFT protocols typically require more than two-thirds of nodes to be honest to guarantee safety and liveness.

Probabilistic Finality is a property where the likelihood of a transaction being reverted decreases exponentially as more blocks are built on top of it, but it never reaches absolute zero. This is the model used in Nakamoto Consensus (e.g., Bitcoin). Users accept a transaction after a certain number of confirmations, at which point the probability of a reorganization is deemed acceptably low.

• Contrast with Deterministic Finality: Does not provide an absolute, cryptographic guarantee of irreversibility.
• Trade-off: Enables simpler, more robust consensus in permissionless settings but requires confidence intervals for settlement.

Deterministic Finality provides an absolute, cryptographic guarantee that once a block is finalized, it is irreversible under the protocol's security assumptions. This is achieved through explicit voting and agreement mechanisms, as in BFT-style protocols like Tendermint or Casper FFG. Finality is reached after a specific round of voting, not after a waiting period.

• Core Property: Offers immediate settlement certainty, crucial for high-value financial transactions.
• Mechanism: Typically involves a two-phase commit or voting process among validators to finalize a block.

State Machine Replication (SMR) is a fundamental technique for providing fault-tolerant services. It ensures that a deterministic service, replicated across multiple machines (or agents), processes the same sequence of commands in the same order, leading all replicas to identical states. Consensus algorithms like Raft and Paxos implement SMR.

• Relation to Finality: Achieving consensus on the log of commands is how SMR systems establish a final, agreed-upon state.
• Atomic Broadcast: Solving consensus for SMR is equivalent to implementing Atomic Broadcast, guaranteeing all nodes deliver the same messages in the same order.