Agreeing on a ledger without a central server
A bank records transactions in a ledger on its own servers. A blockchain has no central keeper; thousands of computers around the world hold copies of the same ledger. The method by which they agree on which transactions happened, and in what order, is the consensus mechanism.
This guide explains why consensus is needed, how major designs produce and validate blocks, and what it takes for a transaction to become final. A hypothetical comparison shows how each design responds to failures and attacks, and the guide ends with how to read a protocol's documentation.
The problem consensus solves
Ethereum.org describes a consensus mechanism as the full stack of protocols, incentives, and ideas that let a network of nodes agree on the state of a blockchain. Without it, the same coin could be spent twice, or different versions of the ledger could exist at once.
The hard part is that the honest participants must still agree on the correct ledger even if some participants fail or lie on purpose. Each design is built on an assumption about how large a share of participants can be faulty or dishonest before things break.
Validators and block proposals
In proof of work, as on Bitcoin, miners compete computationally for the right to produce a block, and nodes follow the chain with the most accumulated work. The Bitcoin Developer Guide explains that each additional block increases the work needed to change the transactions beneath it.
In proof of stake, as on Ethereum, a block proposer is chosen at random from validators who have staked assets, and other validators attest to the block. Some networks use a small set of a few dozen validators who take turns producing blocks and finalize them immediately once two-thirds have signed. Each approach trades off speed, decentralization, and how it behaves when things go wrong.
A hypothetical comparison
The table compares networks using three kinds of consensus.
| Item | Proof of work | Proof of stake (large validator set) | Small-validator BFT |
|---|---|---|---|
| Right to propose | Computational competition | Random selection weighted by stake | Fixed rotation among validators |
| Finality | Probabilistic as confirmations accumulate | Finalized by checkpoint votes | Immediate once two-thirds sign |
| Dishonest share tolerated | Under half of hash power | Under one-third of stake for finality | Under one-third of validators |
| Hypothetical: some participants offline | Blocks slow down | Finality delayed, chain continues | 7 of 21 offline can halt the chain |
Small-validator designs finalize quickly but can halt entirely if more than a third stop. Proof of stake keeps producing blocks when some validators drop out; only finality is delayed.
What finality means
Finality is the point at which a recorded transaction can be treated as irreversible. In proof of work it is probabilistic, with reversal growing less likely as confirmations pile up. In Ethereum's proof of stake, blocks are finalized when a supermajority of validators votes on a checkpoint. Ethereum.org's proof-of-stake documentation explains that reverting a finalized block would require an attacker to lose a large amount of staked ETH.
"Final" means different things, and takes different amounts of time, on different networks. That is why exchanges set different deposit requirements for each network.
Failure and attack assumptions
Every consensus design breaks when its assumption about honest participants fails. In proof of work, an attacker with a majority of hash power can rewrite recent transactions; in proof of stake, an attacker controlling a large share of stake can block finality or censor transactions.
As a hypothetical example, a network where 21 validators finalize blocks with two-thirds of signatures needs 15 signers. If seven of them run in the same data center and it goes down, the remaining 14 cannot reach the threshold and the network can halt. That is why validators' independence matters as much as their number.
Reading the protocol documentation
When looking at a blockchain's consensus, work through these steps.
- Find the consensus design (proof of work, proof of stake, BFT-style, or other) and how block proposers are chosen in the official documentation.
- Note how and when transactions become final, and the typical time to finality.
- Check the number of validators or miners, the share held by the largest, and how they are spread across regions and operators.
- See what happens when some participants stop or misbehave: delays, halts, or penalties.
- Look for any history of network halts or chain reorganizations.
Limits of comparing consensus designs
Theoretical security assumptions and real-world operation can differ. A large validator count means less if most validators run with a few operators or cloud providers.
The comparison and failure scenario here describe general tendencies and hypothetical examples. When assessing a real blockchain, rely on Ethereum.org and each project's official documentation with their dates, and ask how many validators would have to stop for the network to stop before asking what the design is called.