The problem: who decides what is true?
In a normal system, one server decides. If you transfer money at a bank, the bank’s database is the authority, and its record is the record. A distributed ledger has no such authority. Many computers hold copies, messages between them can be delayed or lost, and some participants may be dishonest or simply broken.
Consensus is the set of rules that lets such a network settle on one shared version of the record anyway. Without it, two people could each be told they own the same asset, because different parts of the network accepted different entries. That scenario is called double spending, and preventing it is the central job of any consensus method.
What makes this hard
Computer scientists have studied agreement among unreliable machines for decades, long before blockchains. Two obstacles recur.
- Faulty participants. Some nodes crash, and some may lie or send conflicting messages to different peers. Systems designed to tolerate deliberate lying are usually said to be “Byzantine fault tolerant,” a name taken from a classic thought puzzle about generals who must coordinate by messenger when some may be traitors.
- Open membership. If anyone can join under any number of identities, a single attacker could pretend to be a crowd. Simply counting votes then means little, so the system needs something scarce to anchor influence.
Different consensus mechanisms are, in large part, different answers to the question of what should be scarce.
Proof of work
In proof of work, participants compete to solve a guessing puzzle built on cryptographic hashing. The puzzle has no shortcut, so success takes a large amount of computation, but anyone can check a proposed answer almost instantly. The winner earns the right to add the next block.
Influence therefore depends on computing power, which is costly to acquire. To rewrite history, an attacker would have to redo the work for the changed block and everything after it, while the honest network keeps moving ahead. Nodes generally follow the chain with the most accumulated work.
The trade-off is cost. The competition uses electricity and specialized hardware, a topic covered in the article on blockchain energy use. Throughput is also limited, and finality is probabilistic: the deeper a block sits under later blocks, the less likely it is to be reversed, but it is never mathematically certain.
Proof of stake
In proof of stake, influence depends on how much of the network’s asset a participant locks up as a deposit, often called a stake. The protocol selects who proposes and confirms blocks, with chances usually tied to the size of the stake. Participants who break the rules can have part of their stake taken away.
The scarce resource is thus the asset itself rather than electricity. This typically uses far less energy. The open questions are different: whether wealth concentrating among large holders gives them too much control, how well the penalties deter misbehavior, and whether the design resists less obvious attacks. It is a younger approach than proof of work, so it has a shorter track record in practice.
Voting among known participants
Permissioned networks, where the members are known and approved, can use older voting-style protocols. A leader proposes an entry, the members exchange messages, and the entry is accepted once a large enough majority, often more than two thirds in designs that tolerate dishonest members, agrees.
This approach is usually fast and gives clear finality, because once the vote is complete the entry is settled. The cost is that membership has to be controlled and the number of participants cannot grow as freely, since the message traffic rises with each additional member. It trades openness for efficiency.
Other variations
Many variations exist, such as delegating voting power to elected representatives, or using a small rotating committee. Each shifts the balance among decentralization, speed and security. A useful rule of thumb is that designs rarely improve all three at once, and claims that a new method does so deserve careful reading.
A side-by-side summary
| Approach | What is scarce | Typical strength | Typical weakness |
|---|---|---|---|
| Proof of work | Computing effort | Open participation, long record | High energy use, slow |
| Proof of stake | Locked-up assets | Much lower energy use | Wealth concentration questions |
| Known-member voting | Approved identities | Fast, clear finality | Requires trusted membership |
These are broad generalizations. Real systems mix ideas, and specific designs can differ in important ways.
Forks and finality
Sometimes two valid blocks appear at nearly the same moment, and parts of the network briefly see different versions. This is a temporary fork. The rules include a way to choose between them, such as following the chain with more work behind it, and the shorter branch is dropped. Entries on the dropped branch return to the waiting pool.
Permanent splits can also happen when a community disagrees about the rules themselves. Because there is no central authority, such disagreements are resolved by which version people choose to run, which can be messy and contentious.
Why the choice matters
The agreement method shapes nearly everything else about a network: how fast entries are confirmed, how much it costs to run, how easy it is to join, and what kind of attack is realistic. It also determines what smart contracts built on top can rely on, since their results are only as settled as the underlying record.
None of these mechanisms is simply better. A public network with unknown participants and a consortium of banks have different needs, and the right choice depends on who is involved, what they trust and what a failure would cost.