A database organises information for storage and use. A blockchain adds a particular shared-history and acceptance arrangement. Choosing well means defining the coordination problem and comparing the complete service, rather than assuming that one label is always better.
Continue from How Blockchain Works | Simplest Explanation, or begin here with the question closest to yours. This guide develops the idea through 18 chapters, concrete situations and a paper activity. Its scenarios are fictional teaching models; a real service follows its specified network, programme and operating arrangements.
The Master Blockchain technical companion provides the deeper route after the everyday explanation here.
Choose your reading route
- Define the record problem · Chapters 1–3
- Compare control and evidence · Chapters 4–7
- Inspect the complete service · Chapters 8–11
- Choose against explicit requirements · Chapters 12–15
- Practise the decision · Chapters 16–18
Full chapter index · Worked situations · Answer check · Master Blockchain hub
Full chapter index
Define the record problem · Chapters 1–3
Compare control and evidence · Chapters 4–7
Inspect the complete service · Chapters 8–11
Choose against explicit requirements · Chapters 12–15
Practise the decision · Chapters 16–18
CHAPTER 1 OF 18 · Define the record problem
1. A community garden needs a booking record
A fictional community garden lends a shared storage cabinet to several groups.
The groups want to record reservations, authorised access and returned keys.
They do not begin with a blockchain requirement. They begin with a job that needs reliable information.
A database can organise their records. A blockchain-based service might address particular shared-control concerns. A simpler signed-report arrangement could also be relevant.
This guide compares the questions behind those choices.
The garden is a teaching example, not a deployment proposal.
No technology is declared universally superior.
The useful starting point is to describe the users, operations, evidence and failure cases.
Who may reserve the cabinet? Who approves access? What happens when two groups request the same period? Who can correct an error?
Once those questions are clear, the architecture can be assessed against them.
Choosing the label first risks solving a problem the garden does not actually have.
A database is an organised way to store and retrieve data, with behaviour determined by its software and design.
Conventional database services can have permissions, constraints, backups, transaction handling and audit arrangements.
They are not defined by having no security or no history.
Likewise, a blockchain application can use databases internally or alongside its ledger.
The categories are therefore not simply “ordinary computer” versus “blockchain computer”.
For our garden, one service might store current reservations and an audit history under an association’s administration.
Another might coordinate accepted records among several organisational participants.
Both need software, operators and user interfaces.
For learners, draw the stored records separately from the authority arrangement.
That makes it easier to compare what the service does.
A useful explanation describes actual capabilities and control rather than treating one broad category as automatically weak and another as automatically trustworthy.
CHAPTER 3 OF 18 · Define the record problem
3. Current state answers what the record says now
The cabinet is reserved by Group A for Saturday morning.
That is the current recorded position.
Users often need this answer quickly, without reading every earlier reservation.
A well-designed service can maintain a current-state view for that purpose.
The same service may also preserve a history explaining how the position developed.
These are different reading jobs.
For the classroom, keep a reservation board and a pile of accepted action cards.
The board supplies the current answer. The cards explain the journey.
A blockchain design can combine an accepted event history with a state database or other current-state representation, depending on its architecture.
A conventional service can also maintain history and current information.
The comparison should identify how each view is created, checked and governed.
The word History alone does not establish immutability, and the word Database alone does not establish that no earlier information is preserved.
CHAPTER 4 OF 18 · Compare control and evidence
4. An audit trail can support accountability
The garden association wants to know who changed a reservation and why.
An audit arrangement can preserve relevant information about actions under the service’s design.
Its usefulness depends on what it records, who can alter it and how readers check its completeness.
The existence of an audit log is therefore useful but not self-explanatory.
For our classroom, record every approved reservation change with the acting role and a reference to the request.
Then ask who holds the log and whether the same administrator can replace it unnoticed.
A shared ledger may constrain particular unilateral changes through its protocol and governance arrangement.
A conventional service may use other protections and independent records.
Compare the actual evidence paths.
A good architecture answers the accountability requirement at an acceptable cost.
The learner should ask what alteration the arrangement makes detectable or difficult, rather than assuming a familiar log format or a chain label settles the question.
CHAPTER 5 OF 18 · Compare control and evidence
5. One accepted operator can simplify coordination
The groups already trust the garden association to run the cabinet booking service.
They accept its authority to resolve conflicts and correct mistakes.
That fact can make a conventional administered service a sensible candidate.
It does not remove the need for permissions, clear rules, reliable operation and suitable evidence.
It changes the coordination requirement.
A blockchain arrangement intended to reduce dependence on one operator might provide limited additional benefit if the groups deliberately retain that operator’s decisive powers.
For learners, put the association’s actual authority card beside each proposed architecture.
Ask whether either proposal changes the power the groups care about.
If not, the comparison should examine other benefits and burdens honestly.
A simple service can be well designed.
A complex service can be justified by a specific requirement.
The choice follows the arrangement people need, not a rule that every shared record must be distributed across a blockchain network.
CHAPTER 6 OF 18 · Compare control and evidence
6. Several organisations can create a shared-control problem
Now imagine the cabinet serves three independently governed garden organisations.
None wants another to change the joint history unilaterally.
That is a more specific coordination concern.
The organisations can consider designs that give them a common account of accepted events under agreed limits on individual control.
A blockchain or another distributed arrangement may be relevant, alongside signed reports and other coordination methods.
The requirement should identify the particular power being constrained.
It is not enough to say there are several users. Many conventional services serve many users.
The question is whether independent parties need shared evidence and decision rules without accepting one party’s unrestricted control.
For learners, give each organisation an administrator card and ask which actions should require support from others.
That produces a concrete comparison.
A useful shared ledger addresses actual authority boundaries.
Its purpose should be stated in terms another reader can test.
CHAPTER 7 OF 18 · Compare control and evidence
7. Hashing alone does not distribute authority
The association adds hash links to its own reservation log.
The links can support integrity checks against an accepted reference.
They do not automatically prevent the association from proposing a replacement log and calculating new links.
The service still needs an authority and acceptance arrangement.
Digital Fingerprints explains why recalculating hashes is not the same as satisfying a network’s history rules.
For our comparison, identify who supplies the trusted reference and who can approve a new history.
Several stored copies can also remain under one organisation’s control.
The learner should distinguish data structure from governance.
A chained log may serve particular needs without being a full blockchain network.
Conversely, a blockchain’s useful properties come from more than linking pages.
The complete explanation includes validation, accepted-history rules, operators and change powers.
A diagram of connected hashes should therefore prompt the next question: what prevents the relevant actor from replacing the reference everyone is told to use?
CHAPTER 8 OF 18 · Inspect the complete service
8. Ordinary permissions and network roles are different layers
A borrower may request access while an administrator approves it.
Those application permissions can exist in either a conventional service or a blockchain-based one.
A blockchain design also has roles concerning network participation, validation and accepted history.
The layers should be mapped separately.
For our garden, giving borrowers a website login does not automatically give them authority to approve protocol history.
Likewise, operating a network participant should not automatically grant permission to alter every cabinet booking.
A useful architecture specifies the allowed action at each layer.
For the classroom, use distinct cards for borrower, application administrator and network operator.
Try the same instruction under each role and apply the written rules.
This exposes accidental concentration or expansion of power.
A comparison based only on who can see the interface would miss it.
Good permissions follow the actual job.
The technology category does not excuse the designer from making those boundaries clear.
CHAPTER 9 OF 18 · Inspect the complete service
9. Every architecture needs accurate inputs
The cabinet key was returned, but a person records that it remains borrowed.
A conventional database can preserve the mistaken report. A blockchain can preserve it too.
Changing the storage arrangement does not independently observe the physical key.
The service needs an appropriate reporting and reconciliation process.
Oracles and the Outside World examines that evidence boundary.
For the classroom, move the key card physically while leaving the report unchanged.
Ask which design notices the discrepancy and through which input.
If neither has an observation procedure, both share the gap.
This is a useful way to compare real proposals.
Separate the coordination benefit from the accuracy of the evidence entering the service.
A shared accepted history can make reports easier to inspect while still containing errors.
The correct architecture question is which improvement the proposal actually supplies.
It should not claim to repair outside information through record structure alone.
CHAPTER 10 OF 18 · Inspect the complete service
10. Recovery belongs in the original requirements
The administrator loses access. A server becomes unavailable. A participant leaves.
The garden still needs to understand and continue its reservations.
Every candidate architecture should describe recovery for the relevant failures.
A conventional service might use backups and administrative procedures. A blockchain arrangement may have its own synchronisation, authority and governance requirements.
Neither should be evaluated only through its happy-path demonstration.
For learners, remove one operational card from the paper service and ask what functions remain possible.
Then use only the written recovery powers.
If the solution requires inventing a new administrator after the failure, note the missing specification.
A recovery power can introduce a dependency, but absence of recovery can create a different practical problem.
The design should make that tradeoff visible.
Recoverability is part of meeting the garden’s needs.
It is not a bonus to discuss only after the first irreversible or difficult situation occurs.
CHAPTER 11 OF 18 · Inspect the complete service
11. Correction can coexist with a preserved history
A reservation was entered for Sunday instead of Saturday.
The service should have a defined correction process.
One design may update a current-state view while keeping an audit record. Another may record a later corrective event.
The important questions are who may correct, what evidence is required and how later readers understand the change.
Do not assume that an editable current state has no accountability or that a preserved history prevents every practical correction.
The actual design matters.
For the classroom, keep the original request, the mistaken entry and the authorised correction as distinguishable information.
Calculate the current reservation board.
Now ask whether a reviewer can explain the mistake and the remedy.
That is the evidence requirement.
An architecture serves it when the history remains intelligible and the present state reflects the permitted correction.
The comparison should judge the actual behaviour, rather than opposing all change to all integrity.
CHAPTER 12 OF 18 · Choose against explicit requirements
12. Privacy needs a field-by-field account
The booking service could contain names, contact details, availability patterns and internal notes.
Different architectures distribute and expose that information differently.
A blockchain label does not automatically make the arrangement confidential. A conventional database label does not automatically make it private.
The design must specify fields, recipients, access controls and retention arrangements appropriate to the actual task.
Our classroom uses invented groups and no personal information.
For learners, colour each data card according to who needs it.
Then compare the proposed distribution.
If every network participant receives a field that only one administrator needs, the design should explain why.
The same test applies to a shared spreadsheet or ordinary service.
Privacy is part of the complete workflow.
A useful technical choice reduces unnecessary exposure while keeping the required evidence available to authorised readers.
That cannot be determined by architecture naming alone.
CHAPTER 13 OF 18 · Choose against explicit requirements
13. Availability is more than keeping the history somewhere
The record survives, but the booking website cannot reach its query service.
Users may be unable to make or inspect reservations.
The complete service includes interfaces, network connections, access arrangements and people who operate them.
A durable underlying record does not make every component available.
Nodes and Shared Copies explains this distinction for blockchain applications.
The database comparison needs the same complete view.
For the classroom, keep the history cards intact while closing the interface desk.
Ask whether users can complete the task and what approved alternative route exists.
This locates a practical dependency.
An architecture may improve some availability properties while leaving a particular provider as a common bottleneck.
The proposal should identify those limits.
The useful question is whether the people can obtain the necessary answer and perform the necessary action under the relevant failure conditions.
Survival of data is one important part of that answer, not the whole.
CHAPTER 14 OF 18 · Choose against explicit requirements
14. The total burden should match the benefit
A garden service needs setup, software maintenance, monitoring, permissions and staff capable of handling incidents.
A shared network may add coordination among several operators and a change process spanning organisations.
A simpler service may concentrate those duties under one administrator.
The comparison should include the complete operating burden, not only a transaction fee or a demonstration speed.
This guide quotes no prices and recommends no vendor.
Its goal is to make the evaluation concrete.
What benefit does the proposed design provide? Which failure or unilateral action does it address? Who performs the ongoing work?
For learners, place responsibility cards beside each option.
An empty card identifies an unassigned duty, not a free feature.
A complex design can be worthwhile when it meets an important requirement.
It can also be unnecessary when a simpler arrangement meets the same need.
A sound decision explains the benefit and the work required to sustain it together.
CHAPTER 15 OF 18 · Choose against explicit requirements
15. Use explicit requirements to compare proposals
Write the garden’s requirements before evaluating architecture.
They might include authorised booking changes, a common accepted history, limited unilateral revision, current availability, intelligible correction and recoverable access.
Then describe how each candidate meets each requirement.
Use “not established” where the proposal has no evidence.
This is more useful than a general score for being modern or decentralised.
For the classroom, compare an association database, exchanged signed reports and a toy shared-ledger arrangement.
Their strengths and responsibilities can differ.
Do not assume one must win every category.
The decision should follow the requirements that actually matter and the tradeoffs the groups accept.
A missing outside-world reporting procedure may affect all three.
A governance concern may distinguish them.
The requirement table makes these relationships visible.
It also lets a later reviewer understand why the chosen architecture was reasonable without needing to share the original designer’s enthusiasm for a particular label.
CHAPTER 16 OF 18 · Practise the decision
16. A small trial can test the claimed improvement
The groups can test a proposed workflow with invented records before relying on it for real cabinet access.
The trial should target the requirement the architecture claims to improve.
If the concern is unilateral revision, introduce an attempted unauthorised history change.
If the concern is recovery, remove a participant or access capability.
If the concern is report accuracy, supply a wrong physical-key acknowledgement.
A demonstration that only processes one valid booking does not test those claims.
The classroom can run the same cases through each toy architecture and compare the evidence retained.
The exercise does not establish production security or operational readiness.
It helps identify what the design still needs to demonstrate.
Useful validation is connected to the actual benefit and failure model.
The learner should explain which requirement was tested, what happened and what remains unresolved.
That is stronger evidence than declaring the trial successful because the interface displayed a green tick.
Give three groups the same fictional cabinet requirements and different control arrangements.
One has a trusted administrator. Another exchanges signed action reports. A third uses a toy shared-history agreement.
Process valid requests, conflicting requests, a mistaken key return, an unavailable operator and a correction.
At each stage, record who can act, what evidence is available and which dependency remains.
Then ask each group whether its arrangement meets the stated requirements.
Use the same tests for all.
Do not invent extra benefits for a favourite option.
The paper models do not implement actual databases or secure distributed protocols.
They teach the comparison method.
A learner succeeds when they can identify why a particular arrangement fits the job and which limitations it retains.
The result may favour different designs under different authority assumptions.
That is evidence of a useful decision process, not a failure to produce one universal answer.
CHAPTER 18 OF 18 · Practise the decision
18. Choose blockchain for a defined contribution
A database organises information. A blockchain introduces a particular accepted-history and coordination arrangement under specified rules.
The categories can overlap inside a complete application.
The beginner’s question is what shared-record problem needs solving.
An adult explanation examines control, integrity, evidence, recovery, privacy, availability and operating responsibility.
Return to Public, Private and Consortium Networks for authority maps. Supply Chains and Handovers examines shared events. Certificates and Credentials explains specific claims and optional anchors.
The technical database companion offers a deeper comparison.
Hyperledger Fabric’s ledger documentation supplies one concrete example of history and current-state views working together.
The closing question is precise: which requirement does this design meet better, through which mechanism and at which cost?
A clear answer can justify blockchain.
It can also justify a conventional service.
Understanding how the technology works includes understanding when its additional machinery helps the people using it.
Worked situations: identify the evidence and next step
| Situation | Careful interpretation | Next check |
|---|---|---|
| All groups accept one administrator | The coordination requirement may be simpler. | Compare a conventional administered service seriously. |
| Several organisations reject unilateral history revision | A specific shared-control requirement exists. | Evaluate which mechanism constrains the relevant power. |
| A wrong physical key report enters the record | Storage architecture does not independently observe the event. | Improve the reporting and reconciliation process. |
| History survives but interface service fails | Data durability and task availability differ. | Inspect the whole operating path and recovery route. |
Check your understanding
Five questions: Does every conventional database lack history? Does hashing alone distribute authority? Does blockchain independently verify every physical input? Can correction preserve accountability? Should requirements precede the architecture label?
Answer check: No; no; no; yes; yes. Connect each answer to a control, evidence or operating requirement.
Continue through the beginner collection
- Simplest Explanation
- A Record’s Journey
- Digital Fingerprints
- Keys and Digital Signatures
- Nodes and Shared Copies
- Consensus and Agreement
- Smart Contracts and Rules
- Oracles and the Outside World
- Public, Private and Consortium Networks
- Confirmations and Finality
- Wallets and Custody
Technical companion · Structured technical learning guide
Primary references and scope
Reference pages checked 13 October 2026. The fictional classroom examples explain the mechanisms and evidence questions. The programme, issuer or organisation in a real service must define its actual claims, permissions and responsibilities.
- Hyperledger Fabric: Ledger — a primary reference for the specific data model or technical mechanism. Its scope does not establish every external promise made by an application.
- NIST IR 8202: Blockchain Technology Overview — published October 2018; broader shared-ledger terminology and mechanisms.
How Blockchain Works · beginner reading sequence: 1. Simplest Explanation · 2. A Record’s Journey · 3. Digital Fingerprints · 4. Keys and Digital Signatures · 5. Nodes and Shared Copies · 6. Consensus and Agreement · 7. Smart Contracts and Rules · 8. Oracles and the Outside World · 9. Public, Private and Consortium Networks · 10. Confirmations and Finality · 11. Wallets and Custody · 12. Tokens and What They Represent · 13. Supply Chains and Handovers · 14. Certificates and Credentials · 15. Databases and When Blockchain Helps · 16. Scaling and Layers · 17. Bridges Between Networks · 18. Fees and Computing Resources · 19. Governance and Upgrades · 20. Privacy and What Records Reveal · 21. Zero-Knowledge Proofs · 22. Block Explorers and Reading a Record · 23. Testing Rules and Finding Mistakes · 24. Merkle Trees and Small Proofs · 25. Data Availability and Missing Pieces · 26. Forks and Changing Histories · 27. Digital Identity and Proving Who You Are. Start with the Simplest Explanation, then follow the guides in order or choose the topic you need. Continue into the technical learning guide for deeper study.