A blockchain consensus algorithm decides which proposed ledger update the network accepts and when that decision is final enough to build on. The useful question is not which acronym sounds safest. You need to know who can validate, what resource or vote makes a decision credible, and how the network handles faulty participants.

Blockchain consensus algorithms: a practical cheat sheet

I checked the Bitcoin, Ethereum, CometBFT, and Hyperledger Fabric documentation while rebuilding this cheat sheet. Their designs start from different trust assumptions, which is why proof of work, proof of stake, validator voting, and Raft are not interchangeable choices.

What a consensus algorithm decides

Nodes can receive transactions and blocks in a different order, while a faulty node can send conflicting messages. Consensus gives honest participants rules for selecting one history and rejecting competing histories under a stated failure model.

Consensus does not validate your application logic by itself, and a validly committed block can still contain a smart-contract bug, an authorization mistake, or data that your application should never have accepted, so transaction validity rules still belong in the application design.

Blockchain consensus algorithms at a glance

Start with the membership model. An open network needs a Sybil-resistance mechanism that makes it costly to create influence, while a permissioned network can assign voting rights to identified participants.

Mechanism	Who participates	How agreement is reached	Typical fit
Proof of work	Open miners	Most accumulated valid work	Open networks that accept probabilistic settlement
Proof of stake	Open validators with bonded assets	Validator proposals, attestations, and economic penalties	Open networks with staking-based security
Delegated proof of stake	Elected validators	Token holders choose a smaller validating set	Networks that accept governance concentration
Byzantine fault tolerant voting	Known validator set	Signed proposal and voting rounds	Permissioned or validator-set networks needing fast finality
Proof of authority	Identified authorities	Approved validators create blocks	Private networks with accountable operators
Raft	Known non-Byzantine members	Leader replication and majority agreement	Permissioned ordering when malicious validators are outside the model

How the main mechanisms work

The labels in the table hide different ways of paying for influence, so read the mechanism and its boundary together before choosing one for a product.

Proof of work

Proof of work (PoW) requires miners to search for a block hash that satisfies the network target. Bitcoin’s white paper describes work that is expensive to produce but cheap for other nodes to verify, then uses the chain with the most accumulated work as its ordering signal.

This fits a permissionless network because influence follows computational work rather than an account registry, although settlement remains probabilistic and a payment that needs more confidence waits for more blocks.

Proof of stake

Proof of stake (PoS) uses validators that lock an asset under protocol rules. Ethereum documents that validators stake ETH, check propagated blocks, and can be penalized when they behave dishonestly under provable conditions.

Stake does not mean the largest holder can casually rewrite history because a PoS protocol still needs defined proposer selection, attestation rules, a fork-choice rule, finality conditions, and penalties that make conflicting behavior costly.

Delegated proof of stake

Delegated proof of stake (DPoS) asks token holders to elect a limited set of block producers. The smaller group can reduce coordination overhead, but it moves security toward voter participation, delegate selection, and the rules for replacing an underperforming producer.

Use DPoS only when that governance model belongs in the product’s security design, since calling it a faster version of PoS hides the decision that token holders delegate operational influence to a smaller group.

Byzantine fault tolerant voting

Practical Byzantine Fault Tolerance (PBFT) and related protocols use rounds of signed messages among a known validator set. They aim to keep making one safe choice even when some participants send conflicting messages or fail.

CometBFT provides a concrete boundary. Its specification defines a commit as signed messages from more than two-thirds of validator weight and sets safety under less than one-third Byzantine voting weight, which gives you a stated threshold to evaluate.

Proof of authority

Proof of authority (PoA) assigns block-production authority to approved identities and can suit a private consortium when members need named operators and operational accountability, but identity approval becomes part of the security boundary.

PoA is a governance choice as much as a technical mechanism. Document who approves validators, how a compromised validator is removed, and what audit trail the consortium keeps.

Raft for permissioned ordering

Raft elects a leader and replicates an ordered log through a known cluster. It assumes members do not behave maliciously, which makes it a different tool from Byzantine fault tolerant voting.

Hyperledger Fabric documents Raft in its ordering service and describes Byzantine fault tolerance as a separate development direction. Use Raft when your membership, transport, and operations model can enforce its non-Byzantine assumption.

Choose by network assumptions

Public participation points toward a mechanism that resists cheap identity creation. A consortium can instead use explicit validator membership and operational controls, so membership is the first decision that removes unsuitable choices.

• Choose proof of work when an open network accepts energy-backed competition and probabilistic settlement.
• Choose proof of stake when an open network can use bonded assets, validator penalties, and protocol-defined finality.
• Choose BFT voting when validators are known and the application needs a stated Byzantine-fault boundary.
• Choose proof of authority when a private network wants named validators and governance accountability.
• Choose Raft only when malicious members are outside the failure model.

What consensus does not solve

Consensus can establish an order for valid messages under its own rules, but it cannot establish whether an oracle supplied correct data, whether a private key was stolen, or whether a contract’s business rule is safe.

That boundary matters when you evaluate a blockchain architecture. Pair the consensus decision with key management, identity controls, transaction validation, monitoring, backup, and an incident plan.

Sources and your next move

Read the Bitcoin white paper, Ethereum proof-of-stake documentation, CometBFT specification, and Hyperledger Fabric ordering-service documentation before making a protocol decision.

Write down your validator membership model, fault assumption, and finality requirement first. Those constraints narrow the consensus options faster than an acronym list can.