Removing the central authority does not remove the need for one accepted history. It just makes the network responsible for deciding which history deserves to survive.
"How blockchain consensus works: distributed ledgers, double spending, digital signatures, cryptographic hashes, Proof of Work, mining, forks, chain selection, confirmations, network partitions, and decentralized consensus."
Suppose Alice, Bob, and Peter exchange value with one another.
We could move physical money every time.
Or we could maintain a ledger.
- Alice pays Bob 300
- Bob pays Peter 100
- Peter pays Alice 50
The ledger records the history of transactions, and the current balances can be derived from that history.
Banks already make this idea feel ✨ordinary✨
The important part is not really the rows.
It is who is allowed to add them.
In a traditional system, some trusted institution owns the ledger.
Alice cannot simply write: Alice receives 10,000 from nowhere
and declare herself richer.
The authority validates transactions, controls updates, and provides one accepted version of history.
That gives us something extremely valuable:
There is one place to ask what happened.
Then distributed computing asks the dangerous question.
What if we remove that place?
Replicate the Ledger Everywhere
A centralized ledger comes with familiar problems.
One authority controls it.
One infrastructure operates it.
Its availability depends heavily on that infrastructure.
So imagine replicating the ledger across many independent nodes.
Now many participants hold copies.
The history no longer lives in one place.
That sounds wonderfully resilient.
NIST describes blockchain systems in this general form: a shared digital ledger maintained in a distributed fashion, with transactions grouped into blocks, cryptographically linked, replicated across network participants, and conflicts resolved according to established consensus rules.
So far, this looks like straightforward replication.
Alice transfers 300 to Bob.
Every ledger copy eventually records:
- Alice: 500 → 200
- Bob: 1000 → 1300
Easy.
Until the copies stop agreeing.
Because distributing the ledger did not distribute one magical global view of reality.
It created multiple machines capable of observing different things at different times.
And now the central authority is no longer there to settle the argument.
The Network Splits, and Alice Finds Two Realities
Suppose Alice begins with:
- Alice = 500
- Bob = 1000
- Peter = 500
Alice sends: Transfer 300 to Bob
One part of the network sees it.
That ledger becomes:
- Alice = 200
- Bob = 1300
- Peter = 500
Now imagine a network partition.
Another group of nodes cannot see that transaction yet.
From their point of view, Alice still owns: 500
So Alice sends another transaction: Transfer 400 to Peter
That side accepts it.
Its ledger becomes:
- Alice = 100
- Bob = 1000
- Peter = 900
Now pause.
Alice started with 500.
One history says she spent 300.
Another says she spent 400.
If both histories survive, she has successfully spent: 700
from a balance of: 500
Nothing about copying the ledger prevented this.
In fact, replication created the conditions in which two groups could each believe a conflicting transaction was valid.
This is the double-spending problem.
And it exposes the actual problem blockchain has to solve.
Not:
How do we store transactions on many machines?
But:
How do many machines agree on which sequence of transactions counts as the history?
Bitcoin’s original design begins from exactly this difficulty: digital signatures can establish authorization, but a peer-to-peer system still needs a way to prevent the same value from being spent through conflicting histories without relying on a trusted third party.
Signatures Tell Us Who Authorized Something, Not Which History Won
Public-key cryptography helps.
Alice possesses a private key.
She can digitally sign a transaction.
Other participants can verify that signature using the corresponding public information.
So Alice cannot casually spend Bob’s value merely by writing: Bob pays Alice 500 without the authorization required by the system.
Good.
But signatures do not solve everything.
Alice can legitimately sign two conflicting transactions involving value she controls.
- Alice → Bob 300
- Alice → Peter 400
Both signatures can be perfectly valid.
Cryptography can answer:
Did Alice authorize this transaction?
It does not automatically answer:
Which of Alice’s conflicting transactions belongs in the accepted history?
That is a consensus problem.
The network needs something stronger than authentication.
It needs ordering.
Put Transactions Into Blocks, Then Make History Tamper With Itself
Instead of treating the ledger as unrelated lines, group transactions into blocks.
Then link each block to the previous one using a cryptographic hash.
Conceptually:
- Block 100 ↓ hash
- Block 101 ↓ hash
- Block 102
Each block includes information derived from the previous block.
- Change Block 100 and its hash changes.
- Then Block 101’s reference no longer matches.
- Fix Block 101 and its hash changes too.
- Now Block 102 has to change.
And so on.
NIST describes this as the fundamental tamper-evident property of a blockchain: blocks are cryptographically linked to their predecessors, so altering older data changes those links and affects the chain that follows.
This gives history structure.
But there is still a missing piece.
Anyone can calculate hashes.
If producing a new valid block is cheap, a malicious participant could simply create an alternative sequence quickly.
So we need to make extending history costly.
Make the Right to Extend History Expensive to Produce and Cheap to Verify
Enter Proof of Work.
The idea feels backward at first.
Normally, computing systems try to make work cheaper.
Proof of Work deliberately asks participants to perform computation that is: difficult to produce, but easy for everyone else to verify.
For Bitcoin, a miner varies a value called a nonce while hashing block data, searching for an output that satisfies the current difficulty requirement.
There is no known shortcut that simply reveals the successful nonce.
You try. Hash. Try again. Hash. Again.
Eventually someone finds a valid result.
Everyone else can check it quickly.
Bitcoin’s Proof of Work is built around precisely this asymmetry: finding a suitable hash requires repeated computation, while verifying the resulting proof requires little work.
The network has created a strange kind of authority.
Nobody is appointed permanently.
Nobody is inherently trusted.
Anyone may compete.
But proposing the next block now requires evidence that computational work was actually performed.
You cannot merely shout:
My history wins.
You have to bring receipts.
The First Valid Block Still Does Not Give Us Permanent Truth
Suppose two miners solve the Proof-of-Work problem at nearly the same time.
Miner A broadcasts: … → Block X
Miner B broadcasts: … → Block Y
Both blocks extend the same previous block.
Both may contain valid transactions.
Both may contain valid Proof of Work.
Some nodes hear about X first.
Others hear about Y first.
Now we have:
Excellent.
We built a system whose entire purpose was to maintain one ledger, and it has produced two truths.
For a while.
And that last phrase matters.
Bitcoin explicitly allows temporary competing branches. Nodes can initially work on whichever valid branch they learned about first while retaining knowledge of the alternative.
The system does not guarantee that every node sees the same newest block at the same instant.
That would be difficult in a distributed network.
Instead, it gives the disagreement somewhere to go.
Keep Building, and Make the Competition Resolve Itself
Now another miner finds the next valid block.
Suppose it builds on X:
The X branch now represents more accepted Proof-of-Work history.
Nodes following Y can see that the competing branch has moved ahead.
So they switch.
Traditionally, this is described as:
The longest chain wins.
More precisely in modern Bitcoin implementations, nodes prefer the valid chain with the greatest accumulated Proof of Work rather than merely counting blocks. The older “longest chain” wording is useful intuition because the winning chain represents the branch backed by the greatest demonstrated work.
This is the clever part.
There is no global coordinator sending:
ATTENTION EVERYONE: X IS NOW OFFICIAL
Participants follow the same deterministic rule.
So as one valid branch accumulates more work, rational participants have reason to build on that branch rather than invest computation into a history that is increasingly likely to be discarded.
Agreement emerges from everyone following the same rule for which history deserves further work.
The Losing History Does Not Get to Keep Its Transactions
Now consider what happens to a transaction that existed only inside Y.
Perhaps Alice’s payment to Peter was there.
If the network converges on X, Y is no longer part of the accepted chain.
That transaction may therefore no longer be considered confirmed in the ledger history.
This is why seeing a transaction inside one block is not the same thing as receiving an eternal commitment from the universe.
A newer competing history can temporarily replace what a node previously believed was the best history.
Bitcoin’s developer documentation makes the consequence explicit: recently confirmed transactions carry more double-spend risk because recent blocks can occasionally be replaced when competing branches are resolved.
This can feel wrong if we bring database intuition with us.
In a conventional transaction system COMMIT usually means the transaction crossed a fairly crisp boundary.
In Proof-of-Work blockchain consensus, confidence can be probabilistic.
One block gives some confidence.
Another block built on top gives more.
Then another.
Then another.
The transaction becomes progressively harder to replace because replacing it requires rebuilding the work behind its block and catching up with the continuing chain.
The “commit point” has turned into a slope.
Confirmations Are Confidence Accumulating Behind You
Suppose Alice pays Bob.
The transaction enters a block.
That block now has: 1 confirmation
A new block is added after it.
Now: 2 confirmations
More blocks accumulate: 3 , 4 , 5 , 6
Each additional block represents more Proof of Work layered on top of the history containing Alice’s transaction.
An attacker trying to replace that transaction must construct a competing history and overcome the accumulated work of the chain that honest participants continue extending.
This is why systems can wait for additional confirmations before treating a transaction as sufficiently settled.
Bitcoin developer guidance historically uses six confirmations as an example of a transaction buried beneath substantial additional work, reducing the practical double-spend risk compared with a transaction that has only just appeared.
Notice what the system is saying.
Not:
Six means mathematically impossible to reverse.
But:
The deeper this transaction sits beneath continuing Proof of Work, the harder replacing that history becomes.
Persistence is being built incrementally.
Proof of Work Is Slow Because the Difficulty Is Doing a Job
At this point, Proof of Work looks wasteful.
Participants perform huge amounts of computation merely to find a value satisfying a hash condition.
Then everyone throws away almost all the failed attempts.
Why deliberately make something slow and expensive?
Because if valid history were cheap to manufacture, conflicting histories would also be cheap to manufacture.
The computational difficulty creates a cost for rewriting the past.
Once a block has been accepted and more blocks have accumulated after it, changing that block means reconstructing the Proof of Work for that block and its successors while the rest of the network continues extending the competing chain. Bitcoin’s design relies on exactly this asymmetry.
So the slowness is not an accidental performance bug.
It is part of the security model.
Of course, that creates a trade-off.
Transactions want to be:
- fast,
- persistent,
- and inexpensive.
Proof of Work obtains stronger confidence by deliberately making block production costly.
The protocol is buying resistance to cheap history rewriting with computation and time.
Distributed systems rarely hand out guarantees for free.
The Majority Assumption Was Hiding Underneath Everything
Now suppose an attacker controls enough computational power to build an alternative chain faster than the honest network.
The chain-selection rule has no magical ability to ask:
Which history was created by morally good people?
It sees valid transactions, valid hashes, and accumulated Proof of Work.
If an adversarial group controls the majority of the relevant mining power, it may be able to outpace the honest branch and replace portions of recent history involving its own transactions.
This is the familiar 51% attack idea.
The Bitcoin design states its assumption directly: security depends on honest participants collectively controlling more computational power than any cooperating attacker group, so the honest chain grows faster than competing malicious histories.
This is worth lingering on.
Blockchain did not eliminate trust assumptions.
It changed them.
Instead of:
Trust this central bank.
or:
Trust this database administrator.
the Proof-of-Work system says something closer to:
Trust that the protocol’s validation rules are followed and that attackers do not control enough computational power to dominate history.
Decentralization did not make trust evaporate.
It relocated the trust boundary into the consensus mechanism and its assumptions.
Consensus Does Not Mean Everyone Has the Same View Every Second
This is perhaps the strangest mental shift.
When we hear consensus , we naturally imagine everyone simultaneously agreeing.
- Node A: X
- Node B: X
- Node C: X
Blockchain consensus can spend some time looking more like:
- Node A: X
- Node B: Y
- Node C: X
- Node D: Y
Then:
- Node A: X → X2
- Node B: X → X2
- Node C: X → X2
- Node D: X → X2
Temporary disagreement does not automatically mean consensus failed.
It can be part of the mechanism through which consensus eventually emerges.
NIST describes blockchain consensus mechanisms as the rules by which distributed participants determine which proposed state becomes accepted, with forks representing temporary divergent histories that must be resolved.
That is a softer notion of consistency than a single authoritative database gives us.
But it solves a different problem.
The participants may not trust one central authority.
They may join and leave.
They may receive network messages in different orders.
Some may even behave maliciously.
The protocol’s job is therefore not necessarily:
Prevent disagreement from ever appearing.
It is:
Give disagreement a rule for converging.
That is a much more distributed kind of promise.
The Blockchain Is Really a History-Selection Machine
It is easy to focus on the visible objects.
- Blocks.
- Hashes.
- Nonces.
- Miners.
- Coins.
But underneath them sits one recurring question:
Which history should an independent node believe?
The hash chain makes history tamper-evident.
Digital signatures establish who authorized transactions.
Proof of Work makes producing candidate history expensive while keeping verification cheap.
The chain-selection rule tells nodes what to do when multiple candidate histories exist.
Confirmations let confidence accumulate as more work is built on top.
The majority-computation assumption explains when that process remains secure against a competing attacker.
Put together, these mechanisms create something that a centralized ledger gets much more cheaply:
one history that participants can treat as authoritative enough to continue from.
That is why blockchain is fundamentally a distributed-systems story.
Timing matters.
Ordering matters.
Network partitions matters.
Consensus matters.
Consistency and availability matters.
The Origami Software Engineer’s peace matters.
The cryptography protects particular relationships inside the system.
It does not make the distributed-systems problems disappear.
We Removed the Authority, Then Rebuilt What the Authority Used to Give Us
A central ledger gives us several things almost invisibly.
One place controls updates.
One place orders transactions.
One place rejects double spending.
One place says which history is current.
Remove that authority and none of those responsibilities disappear.
They become protocol problems.
So the system evolves.
Replicate the ledger.
Now replicas can disagree.
Sign transactions.
Now authorization is verifiable, but conflicting authorized transactions can still exist.
Chain blocks with hashes.
Now history becomes tamper-evident.
Make new blocks require Proof of Work.
Now producing competing history has a real cost.
Allow temporary forks.
Now the system can survive nodes learning about valid blocks in different orders.
Choose the chain with the greatest demonstrated work.
Now independent nodes have a shared rule for convergence.
Wait for confirmations.
Now persistence becomes progressively stronger instead of instantly absolute.
Assume honest participants control enough computational power.
Now we can finally state the condition under which that convergence resists an attacker.
Every mechanism exists because removing the trusted ledger owner exposed another responsibility that the owner used to handle for us.
That is the deeper lesson.
Decentralization does not mean nobody decides.
It means the right to decide is no longer concentrated in one trusted actor.
The decision has to emerge from rules that independent participants can verify and follow for themselves.
The strangers do not need to trust one another personally.
They need enough shared rules to eventually agree on which history is worth continuing.
That’s not failure.
That’s evolution.
The “I liked this” Starter Pack:
Don’t let your fingers get lazy now.
- Like : It tells me this was worth writing.
- A Comment: Tell me your thoughts, your favorite snack, or a better title for this blog.
- Boost it: Especially with that one developer who definitely needs this.
Thanks for being here. It genuinely helps more than you know!
— Aaroophan Varatharajan
Find me elsewhere:
- Professional stuff: linkedin.com/in/Aaroophan
- Code stuff: github.com/Aaroophan
- UI stuff: aaroophan.dev/Aaroophan
- Life stuff: instagram.com/Aaroophan
Top comments (0)