A blockchain turns independently verified transactions into one ordered record that many computers can reproduce. Blocks batch accepted updates, cryptographic links expose changes to earlier history, and consensus rules let nodes converge without giving one database operator unilateral editing power.
That mechanism is valuable when several parties need durable shared state and none should control the record alone. Bitcoin uses it to order ownership of bitcoin; Ethereum combines it with programmable state. A blockchain does not prove every external statement true, but it can make the acceptance, ordering, and later alteration of digital records inspectable.
What you will learn
- Explain how transactions, blocks, hashes, and nodes form a shared record
- Distinguish ledger integrity from the truth of external information
- Identify the trust problem that can justify blockchain costs
From proposed updates to a common history
A participant begins by proposing an update, commonly called a transaction. The proposal might transfer a digital asset, invoke program logic, or record a change in ownership. It carries the information and authorization required by that network. Peers relay it, but relay does not mean acceptance; each validating computer checks it first.
Valid proposals wait to be ordered. A designated producer collects a batch, applies the protocol's size and ordering rules, and proposes that batch as a block. Other computers verify every included update and the block itself. Only a block that satisfies their locally enforced rules can extend the history they recognize.
Why blocks point backward
A block normally includes a compact cryptographic summary of the preceding block. This summary, called a hash, changes unpredictably when the underlying data changes. Because the next block contains that hash, editing an older record breaks the references in every later block. The links expose tampering; they do not physically prevent someone from editing a file.
Resistance comes from combining those links with agreement rules. An editor must produce an alternative history that other participants will accept under the network's consensus mechanism. Depending on the system, doing so may require substantial computation, control of committed stake, approval from permissioned validators, or cooperation from the governing organization.
Replication changes who must be trusted
In an ordinary hosted application, users typically rely on the database operator to preserve records, authorize changes, and recover from failures. A blockchain gives independent nodes enough information to calculate the accepted state themselves. They can detect a block that creates unauthorized value, spends the same asset twice, or violates published program rules.
This distributes verification, not every responsibility. Software developers define implementations, block producers order transactions, interfaces translate user intent, and data providers may report facts from outside the network. A sound assessment identifies each actor's power. Saying that a system is decentralized without describing these roles hides the actual trust model.
What the ledger can and cannot establish
The ledger can establish that a particular signed message was accepted at a particular position under a particular rule set. Participants can replay the history and compare results. This supports shared asset ownership and auditable state transitions, especially where organizations would otherwise reconcile separate records after every disagreement.
The ledger cannot independently know whether a house exists, a temperature sensor is calibrated, or a borrower used an authentic identity. Those claims enter through people, devices, or services commonly called oracles. Blockchain integrity can preserve a false input perfectly. Verification of digital rules must therefore be separated from verification of real-world facts.
Common misconceptions
“A blockchain is automatically better than a normal database.”
Replication and consensus add cost and delay. A normal database is usually preferable when one accountable operator is accepted and can correct errors.
“Information written to a transparent blockchain must be true.”
The network can verify authorization, ordering, and internal consistency, but external claims remain only as reliable as the people, devices, and services supplying them.
“Hash links make historical records mathematically impossible to change.”
Hash links reveal edits. Consensus, incentives, validator independence, and social coordination determine whether an altered history can gain acceptance.
Risks and limitations
- Replication consumes storage, networking, computation, and governance effort that a centralized system may not need.
- Incorrect external data can become durable because ledger validation does not establish whether a real-world claim was honest.
- Concentrated validators, administrators, software clients, or interfaces can undermine the independence implied by a shared ledger.
- Public records may expose sensitive relationships and can be difficult or impossible to erase when law or user needs require correction.
Key takeaways
- A blockchain is a replicated, ordered record whose updates are checked under shared rules.
- Blocks refer to previous blocks, so historical edits disturb later cryptographic references.
- Consensus determines which valid history participants accept when alternatives exist.
- Ledger integrity does not guarantee the truth of facts imported from outside the network.
- The design earns its cost only when independent verification solves a real trust problem.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.