Imagine you and a few friends often borrow money from each other. Without a bookkeeper, each person only records their own part in their notebook: who owes me how much, and whom do I owe. At first it’s fine, but as the number of transactions grows, problems arise—you say you repaid 200 last week, but the other person says they never received it; someone digs out an old record and changes the number; and someone repays the same money to two people on the same day, and both sides record that they received the full amount.
Scale this up to society as a whole, and this is the role played by banks and payment platforms: they are the bookkeeper trusted by everyone, responsible for maintaining a single ledger, deciding who has what balance, and which transactions count. So the question arises: if we remove this bookkeeper, how can a group of people who don’t know each other and don’t fully trust each other still agree on the same ledger?
This is exactly the question an article about blockchain aims to answer. It’s not mysterious; the core is three things: how the ledger is made public, who has the right to record, and why historical records are hard to secretly alter.
First, a Problem Without a Bookkeeper
In traditional centralized bookkeeping, the ledger is kept by a single institution. When you transfer 100, the institution actually performs two operations in its own database: subtract 100 from your balance and add 100 to the other party’s balance. Only it knows the full picture, and only it has the right to modify. This model works on the premise that you trust it not to make mistakes, not to play favorites, and not to be bribed.
Once you remove this middleman, trouble concentrates in three areas.
The first is ledger inconsistency. Each person only sees their own records, and the ledger in someone else’s hands may be completely different, so no one knows which one to follow.
The second is defaulting and repudiation. Without an authoritative record, one party can completely deny having transferred money, or claim the amount was a different number.
The third is double-spending. If no one uniformly deducts balances, the same money can be spent to several people at the same time—because each recipient only sees that ‘you have money’, but not that you have already spent it elsewhere.
So the core contradiction that decentralized bookkeeping must solve is just one: to get everyone to agree on the same transaction history and the order of transactions, under conditions of mutual distrust and no arbitrator.
Making the Ledger Public: Let All Participants See the Same Transaction Record
The first idea is straightforward: since hiding it easily causes problems, let’s spread the ledger open.
In a typical public blockchain, when a transaction is proposed, it is broadcast to participants on the network, rather than first stored in a secret internal database of some company. The computers involved in this work are called nodes. Each node can keep a full copy of the ledger and can independently check whether the transaction is valid. In this way, the ledger changes from ‘a private file of one institution’ into a distributed ledger—the same record exists in many places at the same time.
As a result, who records and what is recorded no longer depends on someone’s verbal promise. If you want to know whether a transaction exists, you don’t have to ask a company; you just look at the ledger.
But be careful of a common misreading here: being public does not mean anyone can change it.
You can imagine it as posting the ledger on a public whiteboard. Everyone can see new records and get a copy, but there are rules standing next to the whiteboard: only records that meet the agreed conditions can be written on it. Seeing and writing are two different things.
It should be noted that this whiteboard analogy has its limits. In reality, a whiteboard usually still has a person guarding it, whereas blockchain has no such whiteboard guard; the ledger is maintained jointly by network nodes according to rules, and there are also hash links and consensus mechanisms to be discussed below, which the whiteboard itself does not have.
Who Gets to Write a Line in the Ledger: Rules and Consensus Mechanisms
Once the ledger is public, the key question follows: on what basis is it decided which transaction can be recorded?
This actually splits into two layers, which many people conflate.
Layer One: Is the Individual Transaction Valid?
Before entering the ledger, every transaction must first pass basic checks. Common checks include:
- Is the balance sufficient? Suppose Alice has 10 units in her account and wants to transfer 4 units to Bob. Nodes only need to check that 10 ≥ 4, and it passes; if she wants to transfer 20 units, the transaction is directly rejected.
- Is it truly authorized by the payer? The transaction needs to carry a digital signature generated by the payer using their own key. Nodes verify that the signature is valid before recognizing it as Alice’s own expression of intent, rather than something written fraudulently by someone else.
This layer addresses ‘can this transaction stand?’ The criteria are rules hardcoded in advance, and no institution’s approval is needed.
(Real systems also handle details like fees and account models, but here you only need to understand: validity comes from rule checks, not from someone’s approval.)
Layer Two: Which Batch of Transactions to Write Next
An individual transaction being valid does not mean it immediately enters the ledger. The network also needs to reach agreement on one thing: which valid transactions to append next, and in what order.
Without a central arbiter, this step cannot rely on ‘whoever is loudest decides’. A consensus mechanism is a whole set of rules designed for this: nodes use it to determine which batch of transactions forms the next record accepted by everyone, and they package them into a block appended to the end of the ledger.
Different blockchains use different consensus methods; some rely on computing resources, others on staked rights, but their common feature is: they replace a single person’s arbitration power with pre-agreed rules that all participants can verify. Even if a node wants to unilaterally write a record that others do not accept, other nodes will not accept it.
Binding Ledger Pages into a Chain: Why History Becomes Harder to Change
If the ledger is public, what happens if someone secretly changes a historical transaction?
This is exactly where the name ‘blockchain’ comes from. Transactions are not stored one by one in isolation, but packed into blocks, each containing a batch of transactions. The key is that each block also records the hash of the previous block.
A hash can be roughly understood as a ‘digital fingerprint’ of a piece of content: the same content always produces the same fingerprint; if the content changes by even one character, the calculated fingerprint becomes completely different. So the structure of a blockchain is like this:
- Block 1 has a fingerprint;
- Block 2, in addition to its own transactions, also records Block 1’s fingerprint;
- Block 3 records Block 2’s fingerprint, and so on.
These references link the blocks one after another, forming a chain.
Why Tampering Is Extremely Costly
Now suppose someone wants to change a record in Block 1. What happens?
When Block 1’s content changes, its fingerprint changes accordingly. But Block 2 still stores the old fingerprint, and a comparison immediately fails. To make the whole chain consistent again, this person must then recalculate Block 1’s new fingerprint, write it into Block 2, then recalculate Block 2’s fingerprint, write it into Block 3… and keep redoing this all the way to the latest page of the ledger.
And this is only the first technical step. After redoing it, he must also get other nodes on the network to accept this altered chain. Under normal consensus rules, the majority of nodes will continue along the original chain, and the altered version will not be recognized at all.
So the precise meaning of ‘immutability’ is: it is not absolutely unmodifiable, but under normal consensus conditions, tampering requires an extremely high cost that is often not worth it, and it cannot be done quietly. If enough resources are concentrated, or if the network rules themselves change, historical records can still potentially be rewritten or forked. Understanding this is more important than treating it as an absolute guarantee.
What Blockchain Actually Solves, and What Is Not Its Job
At this point, we can wrap up.
The core problem blockchain solves is: without a central institution, enabling multiple parties to agree on the history and order of an append-only ledger. It achieves this through three things—public broadcasting and ledger copies enable information sharing, validation rules and consensus mechanisms replace a central arbiter, and hash links expose any historical changes. Trust is no longer placed in a single institution, but in open rules and records maintained collectively.
At the same time, it’s important to be clear about what it does not do.
It does not automatically guarantee that the off-chain world is real. Blockchain can faithfully record the fact that ‘you transferred a payment to someone’, but it cannot prove whether the other party actually delivered goods in reality. Whether the input before going on-chain is true still needs off-chain mechanisms to resolve.
It is not a decentralized cloud database. Blockchain excels at recording transactions and states that require multi-party confirmation and where order matters, while storing large amounts of data is neither economical nor appropriate. Putting all data on-chain is a misinterpretation of its purpose.
Having no central institution does not mean anyone can change the ledger at will. Fewer single bookkeepers does not mean fewer rules; the ledger is still constrained by validation rules and consensus mechanisms. A single node cannot arbitrarily change someone else’s balance, nor can it fabricate a transaction out of thin air.
So a more appropriate way to understand it is: blockchain is a decentralized ledger technology that shifts ‘shared bookkeeping’ from relying on a single institution to relying on open rules and collective maintenance. It solves ledger consistency and tamper resistance, not the entire problem of trust.