A consensus mechanism is the rule set a blockchain uses to get machines that do not trust each other to agree on one ordering of transactions, and to keep agreeing while some of those machines are offline, buggy, or lying on purpose. It is not a transaction verifier. Checking a signature is cheap and any node can do it alone. Agreeing on which valid history is the real one is the expensive part, and that is what a consensus mechanism buys.
Every mechanism in this family buys the same thing, agreement under adversarial conditions, by making dishonesty cost more than it pays. What differs is where that cost sits and whether settlement is probabilistic or explicitly finalized. Those two choices are what you are really selecting when you pick a chain to build on.
Agreement is the hard part, verification is not
Distributed systems theory had a precise definition of consensus decades before blockchains existed. A protocol solves consensus if it satisfies three properties. Termination: every non-faulty node eventually decides. Agreement: all non-faulty nodes decide on the same value. Validity: the decided value must be the input of at least one node.1 Nothing in that list mentions transactions, blocks or money.
Then there is the result that shapes every design since. Fischer, Lynch and Paterson proved in 1985 that no deterministic protocol solves consensus in an asynchronous system, even when a single process can crash.2 Every mechanism in production buys its way around that with a timing assumption, a source of randomness, or by relaxing one property. Cornell's course material states the split cleanly: BFT protocols such as Tendermint favour agreement, longest-chain protocols such as Bitcoin favour termination.2 Either the chain keeps producing and can contradict itself later, or it refuses to contradict itself and can stall.
Where the two thirds threshold comes from
A crashed node stops. A Byzantine node lies, and it can lie differently to different peers. Pease, Shostak and Lamport showed in 1980 that agreement survives Byzantine behaviour only while the Byzantine nodes are strictly fewer than a third of all nodes. The ETH Zurich notes draw out the consequence engineers get wrong most often: to tolerate a single Byzantine machine you need four copies, not three.1
That bound is why two thirds keeps appearing in chains that look nothing like each other. Ethereum's finality rule is the same arithmetic in different clothes. A pair of checkpoints is upgraded once votes representing at least two thirds of total staked ETH support it, and a transaction counts as finalized once its chain carries that supermajority link.4 The threshold is not a parameter somebody tuned. It falls out of the proof.
Nakamoto consensus made a different trade
Bitcoin did not solve the classical problem. It changed it. Instead of a known membership list and voting rounds, the whitepaper substitutes work: proof-of-work is essentially one-CPU-one-vote, and the majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.3 Nobody registers, nobody is counted, and the participant set can change every block.
Open participation is what that buys. Certainty is what it costs. The whitepaper is explicit that an attacker's chance of catching up drops exponentially as blocks are added on top, which makes settlement a probability curve rather than a switch.3 No point exists at which the protocol declares a payment done. There is only the point at which you decide the residual probability is small enough for the amount at risk. Chains with a finality gadget move that judgement out of your risk committee and into the protocol.
The family, mapped
Four branches cover most of what ships. Proof-of-work pays for security with hardware and electricity outside the system and settles probabilistically. Proof-of-stake bonds the chain's own token inside the system, and paired with a Byzantine fault tolerant voting layer it produces explicit finality instead of a probability curve.4 Delegated designs narrow production to a bounded elected set, buying speed and giving up the property that anyone can join with consumer hardware. Gossip and DAG designs drop the single leader and infer votes from message structure.
Two cautions on that map. Names are marketing at least as often as taxonomy, and a chain calling itself proof-of-stake may or may not have a finality gadget attached, which is the difference that decides how long your settlement logic waits. Second, a mechanism is only as sound as the client software running it, and a single-implementation network carries a correlated failure mode that no threshold arithmetic touches.
Scroll to see the full diagram
Somebody pays the security budget
Security is free under none of these designs, and the bill lands in the token supply. Proof-of-work funds hashrate with the block subsidy plus fees. The whitepaper describes the first transaction in a block as a special one creating new coin for that block's creator, and notes the incentive can also be funded with transaction fees.3 Proof-of-stake funds validator opportunity cost with issuance. Different mechanism, same accounting: consensus is an operating expense the token pays for, every block, forever.
This is where the mechanism question stops being technical. If the network earns real fee revenue, usage covers the expense. If it does not, security runs on dilution for as long as the chain does, and holders are funding a guard on an empty vault. We say the same thing to every founder who arrives with a consensus design and no demand model. The mechanism is infrastructure. The business underneath it is the engine.
The decision a founder is actually making
Almost nobody designs a consensus mechanism. You inherit one when you pick a chain, and the inheritance surfaces in four places: how long until settlement is safe enough to credit a user or release goods, what a reorg does to your accounting and your support queue, how concentrated the producer set is and whether that belongs on the risk register you show investors, and whether the mechanism can change underneath you.
That last one is not hypothetical. Ethereum originally used proof-of-work and switched to proof-of-stake in September 2022, changing issuance, validator economics and the finality model of a chain thousands of applications were already running on.4 If your settlement assumptions are written down anywhere, write down which mechanism they depend on. The two spokes off this page, proof-of-work and proof-of-stake, carry the specifics.
Common questions
Why do blockchains need a consensus mechanism?
Because there is no referee. Anyone can broadcast a transaction and any node can check it alone, so verification was never the problem. The problem is that two honest nodes can each hold a different but perfectly valid history and have to end up on the same one, while an unknown number of participants are lying. A consensus mechanism is the rule that settles that disagreement without a trusted party.
What is the difference between a consensus mechanism and a consensus algorithm?
The terms get used interchangeably and the distinction matters less than people claim. If you want it: the algorithm is the specific procedure, such as leader election and vote counting, while the mechanism is the whole incentive structure wrapped around it, including rewards, penalties and eligibility to participate. Most protocol documentation uses mechanism for the package and algorithm for the routine inside it.
Which consensus mechanism is the most secure?
There is no single answer, because these mechanisms buy security with different currencies. Proof-of-work makes attack cost external and physical. Proof-of-stake makes it internal and slashable. Ethereum's own documentation says proof-of-stake is younger and less battle-tested than proof-of-work, and on the same page says proof-of-stake as implemented is more economically secure.4 Both statements sit together, which is the honest position.
How many nodes have to be honest for consensus to hold?
For classical Byzantine agreement, strictly more than two thirds of them. Tolerating one Byzantine machine therefore takes four nodes rather than the three most engineers reach for.1 Longest-chain designs use a different bound entirely, an honest majority of hashpower rather than a two thirds quorum, which is why the safety thresholds quoted for Bitcoin and for Ethereum are not the same number.
See Blockchain Consulting for how this applies in practice.
Sources
- Consensus (Distributed Computing lecture notes, chapter 6)
ETH Zurich, Distributed Computing Group
Termination, agreement and validity as the formal definition, plus the Pease, Shostak and Lamport bound of strictly fewer than a third Byzantine nodes. - Impossibility of Distributed Consensus with One Faulty Process (CS6410 lecture slides)
Cornell University, Department of Computer Science, 2025
The FLP 1985 result and the agreement versus termination split between BFT and longest-chain protocols. - Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto, 2008
Sections 4, 6 and 11: one-CPU-one-vote, the longest chain rule, block subsidy plus fees, and the exponential decay of attacker success. - Proof-of-stake (PoS)
Ethereum Foundation
Checkpoint finality at two thirds of staked ETH, the September 2022 switch from proof-of-work, and the documented pros and cons against it.
Last reviewed 2026-08
Related terms
More in Blockchain Fundamentals
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
80+ projects advised. Complete tokenomics in 4 to 6 weeks.