How consensus mechanisms work

Underneath, a blockchain is a ledger copied across many computers. For those copies to be worth anything, everyone has to agree on which transactions go in and in what order. The rules that produce that agreement make up the consensus mechanism.

ethereum.org defines the term broadly: it is the full set of ideas, protocols and incentives that allows a distributed group of nodes to agree on the state of the network. And it makes an important caveat: proof of work and proof of stake, on their own, “are not consensus protocols” (ethereum.org, Consensus mechanisms). They are one piece, the one that prevents someone from dominating the vote by creating fake identities. The other piece is the rule that picks the correct chain when competing versions exist.

This article presents the major families of consensus and the trade-offs between them. The detailed comparison between proof of work and proof of stake is in Proof of Work or Proof of Stake; here the focus is the overall map.

The problem every consensus solves

Computer science has studied this problem since long before Bitcoin. The technical name is state machine replication: several servers start in the same state and execute the same commands in the same order. Because the commands are deterministic, they all reach the same result. The role of consensus is to ensure that everyone receives the commands in the same order (Ongaro and Ousterhout, Raft).

The difficulty lies in failures. There are two types that matter:

• Crash failure: the computer simply stops responding. It may come back later, but it never lies.
• Byzantine failure: the computer behaves arbitrarily. It may send contradictory messages, lie or act in bad faith. The name comes from a classic problem about Byzantine generals who need to coordinate an attack without knowing which of them are traitors.

The paper introducing Tendermint describes well the shift that cryptocurrencies brought. Before, replication ran in data centers, with three to seven replicas belonging to the same organization, and dealt only with crash failures. With blockchains, the challenge became reaching agreement over the internet, among hundreds or thousands of nodes with different owners, some possibly malicious (Buchman, Kwon and Milosevic, arXiv).

Four questions to evaluate any mechanism

Before looking at the families, it helps to have a yardstick. Four properties sum up what a mechanism delivers:

• Safety: honest nodes never record conflicting versions. Nothing bad happens.
• Liveness: the network keeps accepting new transactions. Something useful eventually happens.
• Finality: the point after which a transaction can no longer be reversed.
• Permission: who can take part in consensus. Anyone, or only authorized nodes.

In general, no mechanism maximizes all four at once. The families below are, to a large extent, different choices about what to prioritize.

Raft: consensus for those who trust the participants

Raft was published in 2014 by Diego Ongaro and John Ousterhout, of Stanford University, with a stated goal: to be easier to understand than Paxos, the algorithm that dominated the field. A leader receives commands and replicates them on the other servers. If the leader goes down, a new one is elected using randomized timers (Ongaro and Ousterhout, Raft).

The guarantees are clear:

• safety holds under all non-Byzantine conditions, including delays and message loss;
• the network works as long as a majority of servers is up. A group of five tolerates two going down.

The limit is also clear: Raft was not designed for malicious participants. That is why it appears in environments where all operators are trusted. Hyperledger Fabric, a platform for enterprise networks, uses Raft as the recommended ordering service for production and classifies it as crash fault tolerant, not Byzantine fault tolerant (Hyperledger Fabric, Ordering Service).

The BFT family: agreement with up to one third traitors

BFT stands for Byzantine fault tolerance. The work that made this family viable in practice was PBFT, by Miguel Castro and Barbara Liskov, of MIT, presented in 1999 (Castro and Liskov, USENIX OSDI 99).

PBFT works with a fixed number of replicas that know each other. To tolerate f malicious replicas, 3f + 1 replicas are needed in total. With four, one can be tolerated; with seven, two. One replica, called the primary, proposes the order of requests, and the others confirm in three phases: pre-prepare, prepare and commit. If the primary fails or misbehaves, the others replace it in a view change.

Why one third? The Tendermint proof sums up the argument: with 3f + 1 participants, any two groups of 2f + 1 overlap in at least f + 1 members, that is, in at least one honest member. That honest member prevents the two groups from approving conflicting decisions.

PBFT also showed that the cost could be low. According to the authors, a network file service (NFS) replicated with the algorithm was only 3% slower than the unreplicated version.

Tendermint, described in 2018 by Ethan Buchman, Jae Kwon and Zarko Milosevic, adapted this family to blockchains. It draws on PBFT, decides in three communication steps when everything goes well and uses gossip communication between peers, suited to networks in which each node talks only to a few neighbors. The premise is that malicious participants hold less than one third of the voting power (Buchman, Kwon and Milosevic, arXiv).

The same principle appears in enterprise networks. In Hyperledger Besu, the QBFT and IBFT 2.0 protocols require at least four validators, need two thirds of them active to keep producing blocks and offer immediate finality: according to the documentation, there are no forks and every valid block goes into the main chain (Hyperledger Besu, Proof of authority consensus). Fabric began offering a BFT ordering service from version 3.0.

The trade-offs of the BFT family:

• For: immediate finality and safety even with malicious participants, within the one-third limit.
• Against: the validator set has to be known. The Besu documentation records another cost: block time increases as the number of validators grows. And if more than one third stops responding, the network stops deciding. The protocol prefers to halt rather than err.

Nakamoto consensus: open to anyone

Bitcoin solved a problem the BFT family did not: reaching agreement without knowing who or how many the participants are.

The solution has two parts, described in the whitepaper (Nakamoto, Bitcoin whitepaper):

• Votes tied to a resource. If each internet address counted as one vote, it would be enough to create many addresses. With proof of work, voting becomes “one CPU, one vote”.
• Longest chain rule. Nodes always consider the chain with the most accumulated work to be the correct one. If two blocks appear at the same time, each node works on the first one it received and keeps the other; the tie is broken when the next block appears.

The result is a consensus in which nodes “vote with their CPU power”, can join and leave at will and do not need to be identified. Security depends on the majority of processing power being honest. How mining works is covered in how Bitcoin mining works, and the structure of the chain in how the Bitcoin blockchain works.

The trade-off lies in finality. It is probabilistic: a recent block can be replaced if another version of the chain becomes longer. NIST notes that, for this reason, most users wait for a few blocks before considering a transaction valid (NIST, NISTIR 8202).

In the newsroom’s reading, Nakamoto consensus and the BFT family make opposite choices when faced with a split network. BFT prefers to halt rather than risk two versions. Nakamoto keeps producing blocks on both sides and resolves the divergence later, when one chain overtakes the other.

Proof of stake and its variants

In proof of stake, the resource that confers voting rights is the network’s own currency, deposited as collateral. According to NIST, a participant’s chance of publishing the next block is proportional to the share they have deposited relative to the total.

NIST records a classic problem with this model, nothing at stake: if there are two competing chains, voting on both costs nothing, and a participant may do so to increase their chance of being rewarded. This can keep forks open for a long time.

Ethereum’s answer is punishment. A validator deposits 32 ETH and, if they sign two blocks for the same slot or cast contradictory votes, they lose part or all of the deposit, the so-called slashing (ethereum.org, Proof-of-stake).

Ethereum’s current protocol, Gasper, is a hybrid of the two previous families:

• a fork choice rule, related to the longest chain, that weighs each chain by the votes it has received;
• a BFT-style finality mechanism, Casper FFG, proposed by Vitalik Buterin and Virgil Griffith in 2017 as a finality layer overlaid on an existing chain (Buterin and Griffith, arXiv).

When validators holding two thirds of the staked ether vote on successive checkpoint blocks, the earlier one is finalized. Reversing it would require destroying at least one third of all staked ether. If finalization stalls for more than four epochs, the inactivity leak kicks in: validators that do not vote with the majority gradually lose stake until the majority again adds up to two thirds (ethereum.org, Gasper). It is a way of restoring liveness without giving up safety.

Other variants:

• Ouroboros, by Aggelos Kiayias and co-authors (2016), presented by the authors as the first proof-of-stake protocol with formal security guarantees, comparable to Bitcoin’s (Kiayias et al., IACR ePrint 2016/889).
• Delegated proof of stake (DPoS): coin holders elect delegates who produce the blocks. NIST’s comparison table lists efficiency as an advantage and, as disadvantages, less node diversity, higher risk of compromise because there are few operators, and a possible incentive for collusion and bribery among known delegates.

Proof of authority and other permissioned models

In proof of authority (PoA), blocks are produced by a group of authorized signers, chosen for their reputation, usually known organizations. ethereum.org describes how Clique, the standard implementation on Ethereum, works: signers take turns and each can only produce one block every so many, which limits the damage from a malicious signer while the others vote to remove them (ethereum.org, Proof-of-authority).

• For: fast confirmation, according to ethereum.org potentially under one second, and low cost.
• Against: few validators, hence more centralization, and malicious signers can still reorganize the chain or censor transactions. It is used mainly in private networks, test networks and development.

NIST also describes two models for permissioned networks (NIST, NISTIR 8202):

• Round robin: nodes take turns creating blocks. It is simple and cheap, but requires a lot of trust; on an open network, an attacker could create extra nodes to win more turns.
• Proof of elapsed time (PoET): each node receives a random wait time from a secure hardware component, and whoever wakes up first publishes. The model depends on that hardware not having been compromised.

The difference between open and closed networks, and why they choose different mechanisms, is the subject of public versus private blockchain.

DAG: when the ledger stops being a queue

Some systems abandon the linear chain. Instead of each block pointing to a single predecessor, transactions or blocks form a directed acyclic graph (DAG): a web of references that can be created in parallel without ever forming cycles.

A 2020 academic review by Qin Wang and co-authors sums up the motivation: linear chains have high latency and limited scalability, and DAGs aim for fast confirmation and parallel processing without weakening security too much (Wang et al., arXiv). The same work analyzes the security and performance of several systems and points to challenges that remain open. In the newsroom’s assessment, a DAG is a data structure, not a complete consensus mechanism: each system still needs rules to decide the final order.

Summary comparison

Family	Who takes part	Failures tolerated	Finality	Main cost
Raft	Known, trusted nodes	Crash of up to a minority	Immediate	Does not withstand malicious nodes
BFT (PBFT, Tendermint, QBFT)	Known validators	Fewer than 1/3 malicious	Immediate	Halts if 1/3 goes offline; closed set
Nakamoto (proof of work)	Anyone	Minority of processing power	Probabilistic	Energy; waiting for confirmations
Proof of stake (Ethereum)	Anyone with a deposit	Reversing finality costs at least 1/3 of the stake	After checkpoints	Complexity; locked capital
Proof of authority	Authorized signers	Minority of signers	Fast	Centralization
DAG	Varies by system	Varies by system	Varies by system	Design still under research

The figures in the table are each protocol’s assumptions, according to the sources cited. In practice, security also depends on the implementation, the incentives and how many participants actually control the network.

Key takeaways

• Consensus is what keeps many copies of a ledger identical, in the same order, even when some participants fail or lie.
• Raft tolerates crashes, not betrayals. The BFT family tolerates up to one third of malicious participants and gives immediate finality, but requires known validators.
• Nakamoto consensus opened participation to anyone, trading immediate finality for probabilistic finality.
• Ethereum’s proof of stake combines both traditions: Nakamoto-style chain selection and BFT-style finality, with punishment for those who vote on conflicting versions.
• Proof of authority, round robin and PoET serve permissioned networks, where trust comes from the participants’ identity.