How does blockchain consensus work?
By Unlearnt
Blockchain consensus is the process a network uses to agree on a shared history. Checking that a transaction follows the rules is one problem. Agreeing which valid transactions happened first is another, especially when participants receive messages at different times.
Agreement requires more than copying a ledger
Nodes keep and check records independently. A consensus protocol specifies how blocks are proposed, which histories nodes should follow, and when an accepted block becomes difficult or costly to replace. Its security depends on assumptions about participants, resources and communication.
‘Everyone votes’ is an incomplete description. On an open network, creating another identity can be cheap. Protocols therefore need a way to resist an attacker gaining influence simply by running more identities. Proof of work uses computational work; proof of stake uses committed stake, alongside protocol rules and incentives.
Worked example: one balance, two conflicting payments
Imagine a simplified ledger where Mira has five coins. She signs one payment of four coins to Jo and a competing payment of four coins to Lee, each attempting to spend the same available funds. One group of nodes sees Jo's payment first; another sees Lee's first.
Either payment could be valid against the starting balance, but both cannot spend those same funds in one accepted history. Cryptographic signatures establish that Mira authorised the payments; they do not decide which competing history everyone should keep.
A node needs to validate proposed blocks and apply the protocol's rule for choosing between competing valid branches. Once the network converges on a history containing one payment, the competing spend cannot also be accepted against the already-spent funds. The example omits protocol-specific details; it illustrates why ordering matters.
One starting balance, two competing histories
Shared starting point
Mira has 5 coins
Branch A
4 coins → Jo
Mira has 1 left
Branch B
4 coins → Lee
Mira has 1 left
Signatures authorise. Validation checks the rules. Fork choice selects a branch; finality depends on the protocol.
Proof of work and proof of stake choose influence differently
In Bitcoin's proof-of-work design, miners compete to produce blocks with the required computational proof. Nodes check validity and follow the valid chain with the most accumulated work. Work helps distinguish competing histories; it does not permit miners to ignore validation rules.
Ethereum's proof-of-stake system uses validators and votes weighted by stake, with fork-choice and finality rules. Protocol violations can lead to penalties. These are different designs for coordinating a network, not interchangeable labels for a simple majority of people.
Misconception: being included means being irreversible
A recent block can belong to a branch that is later replaced. Bitcoin confirmations reduce reversal risk under its security assumptions; Ethereum has explicit finality conditions. Neither means all networks provide the same guarantee the instant a transaction appears.
Agreement also has limits. A ledger can consistently record a claim about a delivery without proving that the parcel arrived in the physical world. Ask separately whether participants agree on the record and whether the input was trustworthy. Consensus solves the first kind of problem; it does not settle every external fact.
Check your understanding
Optional: apply the idea to a new scenario.
Two nodes validate different recent branches of the same blockchain. Each branch follows the transaction rules, but their histories conflict. Why is transaction validation alone insufficient, and what else must the nodes use to converge?
Answer with the tutor →Free to start, no account needed.