Skip to content
Financial Context Wiki

Byzantine Fault Tolerance: Safety, Liveness, and Quorums

Byzantine fault tolerance describes when a distributed protocol remains safe and live despite arbitrary faults. Evaluate the protocol, network model, fault bound, quorum rule, weights, finality condition, and recovery path together.

Updated

Educational protocol analysis only. A BFT label or quorum threshold does not by itself prove safety, liveness, correct execution, decentralization, finality, or asset security.

Direct answer

Byzantine fault tolerance (BFT) is a property of a specified distributed protocol under a specified fault and network model: it continues to satisfy its stated guarantees even when some participants crash, withhold messages, equivocate, send different messages to different peers, or otherwise behave arbitrarily. BFT is not one algorithm and does not mean that every service remains available during every partition.

The guarantees must be separated. safety means honest participants do not decide conflicting values; liveness means eligible inputs can eventually lead to a decision; validity constrains which values may be decided. A protocol may preserve safety by stopping when communication or honest voting power is insufficient. Correct consensus also does not prove that application code, transaction validity rules, bridges, keys, or governance are correct.

For a common class of authenticated, partially synchronous BFT protocols, n=3f+1 replicas can tolerate at most f Byzantine replicas and a commit certificate uses q=2f+1 votes. The familiar “less than one-third faulty” and “more than two-thirds quorum” statements come from that model. Synchronous protocols, randomized asynchronous protocols, crash-fault protocols, proof-of-work chains, and other BFT constructions can have different assumptions and thresholds.

In stake-weighted systems, thresholds refer to voting power defined by the protocol, not necessarily validator count, address count, people, or independent operators. Always name the exact protocol version, weight snapshot, decision type, network assumption, quorum comparison (> or >=), and fault behavior before applying a fraction.

Below threshold
25%
Adversarial share
25%
Margin to threshold
8.4%

Outputs are educational approximations. They exclude venue rules, taxes, latency, oracle behavior, and other protocol-specific parameters unless shown.

How it works

  1. Define the decision. Identify whether nodes are ordering transactions, committing a block, finalizing a checkpoint, electing a leader, accepting a state transition, or choosing a fork. These are not interchangeable decisions.
  2. State the system and adversary model. Record membership, authentication, permission changes, voting weights, adaptive corruption, key compromise, equivocation, crash faults, message loss, censorship, denial of service, and whether faults may be correlated.
  3. State the network model. Distinguish synchrony, partial synchrony, and asynchrony. For partial synchrony, identify what is guaranteed only after an unknown global stabilization time and how timeouts adapt.
  4. Derive the quorum rule. Use the protocol’s exact threshold and locking or voting rules. For the classic n=3f+1 setting, two 2f+1 quorums intersect in at least f+1 replicas, so their intersection contains an honest replica when at most f are Byzantine.
  5. Trace every phase and certificate. Verify proposal, vote, lock, view or round change, commit, fork-choice, and recovery rules. A signed supermajority is meaningful only if nodes validate height, round, value, parent, domain, membership epoch, and prior certificate.
  6. Separate safety from liveness evidence. Prove which conflicting decisions are excluded at all relevant times, then test whether progress resumes after the protocol’s communication and honest-participation assumptions hold. A timeout is a scheduling tool, not proof that a silent peer is malicious.
  7. Verify implementation and operations. Check client diversity, key custody, signer failover, replay protection, state synchronization, evidence handling, membership changes, monitoring, application confirmation policy, and incident recovery against the proved model.

The FLP result says that a deterministic consensus protocol cannot guarantee termination in a fully asynchronous model with even one possible crash fault. It does not say that safety is impossible or that distributed consensus can never work. Partial synchrony, randomization, failure detectors, economic assumptions, or weaker guarantees provide different ways around the specific impossibility conditions.

Worked examples

1. Four equal replicas

Let n=4, f=1, and q=3. Any two three-vote sets overlap in at least 3+3-4=2 replicas. With at most one Byzantine replica, at least one replica in that overlap is honest. If the protocol’s honest-node rules forbid voting for conflicting values in the relevant height and round history, two conflicting commit certificates cannot both form.

If two replicas are offline, only 2 votes remain and no q=3 certificate forms. That is a liveness failure, not automatically a safety failure: a safely designed protocol waits instead of lowering the threshold locally.

2. Seven equal replicas

Let n=7, f=2, and q=5. Two quorums overlap in at least 5+5-7=3=f+1 replicas. Because at most 2 are Byzantine, the overlap contains an honest replica. Two Byzantine replicas alone cannot create a five-vote certificate, but three unavailable or withholding replicas leave only 4 votes and can stop progress.

The threshold arithmetic is necessary but not sufficient. If honest implementations accept votes from the wrong height, reuse a membership set, violate a lock rule, or sign through compromised keys, the proof’s assumptions no longer match the deployed system.

3. Weighted voting power

Suppose validators have weights 40, 30, 20, and 10, totaling 100, and a certificate requires strictly more than 2/3, implemented here as at least 67. The 40+30=70 coalition can form a certificate; 30+20+10=60 cannot, despite containing three of four validators. If the weight-40 validator is offline, only 60 remains and finality halts.

Any two sets of at least 67 weight overlap by at least 67+67-100=34. Therefore, conflicting certificates imply at least 34 weight participated in both sets or some other protocol assumption failed. This is why a safety violation can require only slightly more than one-third equivocation under some protocols; “two-thirds to attack” is not a universal minimum.

4. Partial synchrony and timeouts

Assume four replicas use round timeouts of 1 s, 2 s, 4 s, and 8 s. Before the unknown stabilization time, messages may arrive after every current timeout, so rounds can change without a decision. After the network stabilizes with delays below 3 s, the 4 s or later round can give an honest proposer and quorum enough time to exchange messages and progress, subject to the protocol’s other assumptions.

The numbers illustrate eventual progress, not a universal timeout formula. Shorter timers can cause needless view changes; longer timers extend recovery latency. Safety must not depend on guessing the correct delay bound before stabilization.

Risks and review failures

Model and proof

  • Saying “BFT” without naming the protocol, version, decision, fault model, network model, membership rule, and threshold.
  • Applying n=3f+1 or a one-third fraction to every distributed ledger, including protocols whose proof uses different assumptions.
  • Treating safety, liveness, validity, availability, consistency, finality, fork choice, and transaction correctness as synonyms.
  • Claiming FLP makes consensus impossible without preserving its deterministic, fully asynchronous, guaranteed-termination conditions.
  • Counting nodes or addresses when the protocol counts stake, delegated weight, committees, epochs, or another resource.
  • Rounding “two-thirds” ambiguously or ignoring whether the implementation tests >, >=, integer weights, or a denominator snapshot.
  • Checking quorum size without checking quorum intersection, locks, certificates, view changes, reconfiguration, and state transfer.
  • Assuming a proof covers adaptive corruption, key theft, correlated faults, denial of service, or long-range history when it does not.

Implementation and operations

  • Accepting signatures without binding chain, domain, height, round, value, parent, membership epoch, and message type.
  • Replaying stale votes or certificates across rounds, heights, forks, networks, upgrades, or validator-set changes.
  • Allowing double-signing, lock regression, unsafe signer failover, or two active replicas to share one validator identity.
  • Treating timeout expiry as proof of malice and making a safety-critical decision from local clocks alone.
  • Ignoring common-client, cloud, region, network, hardware, key-management, or operator failures that correlate nominally separate validators.
  • Assuming slashing prevents faults, restores liveness, reverses a finalized application action, or compensates every affected user.
  • Testing only normal operation instead of partitions, delayed and reordered messages, equivocation, proposer failure, restarts, and membership changes.

Application and governance

  • Treating a committed consensus value as a valid application state without deterministic execution and state-transition validation.
  • Crediting deposits, minting bridged assets, or settling trades before the exact finality condition required by the application.
  • Assuming protocol finality is identical to social irreversibility after key compromise, software failure, or governance intervention.
  • Ignoring censorship and inclusion latency because blocks continue to finalize for other users.
  • Inferring decentralization, asset safety, token value, or legal enforceability from a BFT label or advertised validator count.

Common misconceptions

  • BFT means the network never stops. Many BFT protocols deliberately sacrifice liveness during excessive faults or partitions to preserve safety.
  • Honest participants above 51% are always enough. The required threshold depends on the protocol; classic partially synchronous BFT commonly needs more than two-thirds of the relevant voting power for progress.
  • An attacker always needs two-thirds to break safety. Two-thirds may form a certificate alone, but two conflicting supermajority certificates can expose just over one-third equivocation in common quorum designs.
  • More validator addresses automatically improve fault tolerance. Common ownership, delegated weight, clients, infrastructure, keys, and failure domains determine independent fault capacity.
  • Slashing is the BFT proof. Slashing is an economic response available in some PoS systems; safety comes from protocol rules and assumptions, and penalties do not undo external consequences.

Sources

Navigation

Search the wiki...