Consensus Protocol

1.6 — Consensus Protocol

Recall first. Two honest nodes each receive a different next transaction. With no central server, how could they ever agree on which one is “real” without a trusted referee? Write one idea. Then read.

Reference-book anchor

Primary reference: Blockchain Technology, Chapter 2, §2.4 — converted Markdown lines 1410–1493.¹

The book’s anchor covers the consensus definition, Byzantine Generals Problem, objectives, PoW, PoS, PoET, PoA, and permissioned consensus. The note preserves that syllabus foundation while stating each protocol’s membership, fault, and finality assumptions.

What “consensus” means, precisely

In a blockchain context, a consensus protocol is the set of rules by which distributed participants agree on the next accepted state or history. It commonly specifies:

1. Agreement: which valid transactions or state transitions are accepted and in what order.
2. Progress: how the system chooses a proposer, leader, or validator and continues making progress.
3. Fault handling: what happens when participants are slow, offline, contradictory, or malicious.

Not every consensus protocol uses blocks or elects a permanent leader, so state the particular protocol’s mechanism rather than treating “consensus” as one algorithm.

Without consensus, the “shared notebook” from §1.1 falls apart the moment two people write conflicting lines.

The core problem: the Byzantine Generals

The theoretical bedrock is the Byzantine Generals Problem (Lamport, 1982): generals surrounding a city must agree on attack/retreat, but some may be traitors sending conflicting messages. Byzantine fault tolerance (BFT) means a system can preserve agreement and, under its liveness assumptions, make progress despite a bounded number of arbitrary faults. The bound depends on the protocol and its membership/network assumptions; for classical PBFT-style replication, the usual requirement is at least 3f+1 nodes to tolerate f Byzantine nodes.²³

Beginner reframe. “Byzantine” just means arbitrary / adversarial failure — a node can lie, equivocate, or send different messages, not just crash. A blockchain must state how many such faults it can tolerate and under what network assumptions; “honest nodes outnumber attackers” is not a complete BFT specification.

Two families of consensus

The type from §1.5 decides the family:

Family A — Nakamoto consensus (Proof-of-Work, PoW)

In Bitcoin, mining = finding a nonce so SHA256d(header) < target. The rule: among valid candidates, the chain with the most cumulative work wins (often called the heaviest chain); block count alone is not the criterion. Nodes build on the tip of that chain.

• Why it works without identity: “who gets to propose” is proportional to computing power, which is a real, costly, pseudonymous resource. In Bitcoin-style PoW, controlling a majority of hash rate lets an attacker reliably dominate chain selection; this is the classic 51% attack. It does not let the attacker create valid coins from nothing or make invalid transactions acceptable, because honest nodes still check validity.⁴⁵
• Forks happen when two valid blocks are found near-simultaneously; they resolve when one branch gains more cumulative work, while the other becomes stale and is no longer the canonical chain.

Refresher — Sybil attack. An adversary creates many fake identities to outvote honest nodes. Permissionless systems can’t ban identities, so they bind “voting power” to an external scarce resource (hashpower in PoW, stake in PoS) instead of to identity.

Family B — permissioned replication and voting

Known validators exchange authenticated messages. Practical Byzantine Fault Tolerance (PBFT) tolerates up to f Byzantine nodes when the system has at least 3f+1 known, authenticated validators, under its stated network and timing assumptions; the quorum is commonly 2f+1. Raft is a simpler crash-fault-tolerant protocol: it assumes non-Byzantine members and handles nodes that stop or become unavailable, not nodes that deliberately lie. Raft also needs a majority quorum to commit and make progress. Permissioned protocols can provide deterministic or near-immediate finality, but they require controlled membership and governance. (Detailed in Module V.)³

Properties a good consensus must balance

Worked example — why PoW resists Sybil

An attacker spins up 1,000,000 fake nodes in a permissionless network but controls 1% of hashpower. Can they double-spend by out-voting honest nodes?

Answer: No. In Nakamoto consensus, “votes” are blocks of work, not node counts. With 1% of hashpower the attacker finds ~1% of blocks; to rewrite history they’d need >50% (a 51% attack), which 1,000,000 cheap identities cannot fake because each block requires real, costly computation.⁴⁵

Exercise

PBFT needs 3f+1 nodes to tolerate f Byzantine faults. (a) How many faulty nodes can a 10-node PBFT network tolerate? (b) Why can’t you just use PBFT directly on a public chain with millions of anonymous miners?

Exam lens

Definition to write: Consensus is the protocol-level process that lets distributed participants agree on valid state/history and make progress despite specified failures.

High-value comparison:

Common traps:

• Consensus is not merely “all nodes vote”; the voting weight and fault model matter.
• The longest valid chain is not permission to accept invalid transactions.
• Raft is not Byzantine fault tolerant.
• A 51% attack is a chain-selection/history attack, not a magic ability to forge another user’s signature.

Rapid revision

• Can I define safety, liveness, and finality separately?
• Can I explain why one-IP-address-one-vote is vulnerable to Sybil identities?
• Can I calculate PBFT’s 3f+1 requirement for a given f?
• Can I state why public and permissioned networks choose different consensus families?

Key takeaways

• Consensus = agreeing on transaction order + next block, despite faults/malice.
• The Byzantine Generals Problem is the theoretical core; classical PBFT-style BFT tolerates f Byzantine nodes with at least 3f+1 total, under its assumptions.
• Public chains use Nakamoto-style mechanisms such as PoW or PoS: voting weight comes from a scarce resource, and finality depends on the specific protocol.
• Consortium/private chains may use BFT or Raft: known validators coordinate, with finality and fault tolerance determined by the chosen protocol and quorum.
• Every consensus trades off safety, liveness, decentralization, and finality.

Sources