What problem does a blockchain solve?

A record everyone can copy

Imagine a neighborhood tool library. Mira borrows the drill on Monday. Three volunteers each keep a copy of the checkout sheet. On Tuesday, one copy says the drill was returned; another says Mira renewed it. Copying the sheet has not answered which version the library should use.

The volunteers could appoint a librarian to decide. That is often a sensible design. A database with backups and access controls might do everything this library needs. The librarian becomes a point of responsibility: someone can correct mistakes and resolve disputes, but someone can also alter the accepted record.

A blockchain addresses a different arrangement: participants want to verify an evolving record under shared rules without giving a single record keeper unilateral control over its history. The difficult question is not “Can we copy these entries?” It is “Which valid ordering will participants build on?”

Rules, ordering, and evidence

Bitcoin makes this question concrete. Two payments might each attempt to spend the same previous output. A signature alone cannot choose between them: the owner could authorize both. Nodes need rules for valid spending and a way to select a history in which an output is spent at most once.

Blocks group transactions. Hash links connect blocks to earlier blocks. Proof of work contributes to selecting among competing valid histories. These parts have different jobs; a hash link by itself does not settle a disagreement.

Return to the tool library. Linking sheets together with digital fingerprints would help reveal that a past sheet changed. It would not make a volunteer’s claim that the drill was returned physically true. A reliable record of a claim and a reliable claim are different achievements.

What trust moves, rather than disappears

A useful architecture discussion lists who can do what. Who may propose an entry? Who checks it? What happens if participants disagree? Who can recover a lost credential? What information is public?

Decision	Shared database example	Bitcoin example
Who changes the record?	An authorized application writes it	Transactions and blocks must satisfy node rules
Who resolves competing histories?	An administrator or database system	Nodes select a valid chain using accumulated work
How are mistakes handled?	An administrator may amend data	A new valid transaction can change state; past inclusion has different constraints

This is not a scorecard declaring a winner. Our tool library might value reversible corrections more than independently verifiable ownership. A public payment system makes a different set of tradeoffs.

Replication also has costs. More parties need enough data to check the rules; public data can expose relationships; confirmation involves uncertainty. “Decentralized” is a starting point for questions about control and failure, not a complete answer to them.

Sketch the decision before choosing the technology

Draw three boxes for the tool library: borrower, librarian, and record. Add arrows for who can propose a checkout and who can correct one.

Now imagine replacing the librarian with five volunteers who independently check a shared rulebook. Write down a conflict: “Mira and Sam both hold an authorization to borrow the same drill.” Which mechanism resolves this? If your answer is “the hash,” you have only named a way to identify data, not a rule for deciding between histories.

Expected result: a design with explicit authority and conflict handling. You may conclude that an ordinary database is appropriate. The exercise succeeds when that conclusion follows from the system’s needs rather than the appeal of a label.