中文版 · Blockchain learning guide · Previous: Public, Private and Consortium Blockchains
Blockchain learning · Article BC010
A blockchain is useful when its particular coordination and verification properties solve a real problem that simpler arrangements do not solve well enough. It is not useful merely because a project has several users, stores important information or wants to appear modern.
The strongest starting point is a concrete disagreement: independent parties need to maintain a common record, verify permitted changes or avoid giving one participant unilateral control. Even then, the benefits must survive the realities of data quality, privacy, governance, recovery and operating cost.
This guide is an application-screening workshop. Rather than comparing technical architectures in the abstract, it asks what evidence would justify using blockchain for a particular workflow and what evidence should make a team stop.
Choose your reading route
In this guide
- 1. Complete the benefit sentence without a buzzword
- 2. Three patterns that deserve serious evaluation
- 3. Three weak-fit patterns
- 4. Separate the onchain contribution from the whole outcome
- 5. Worked case: disputed design revisions
- 6. Turn the case into a testable hypothesis
- 7. Measure the user outcome, not just the transaction counter
- 8. Identify the minimum information that must be shared
- 9. Count responsibilities as well as costs
- 10. Write stopping rules before the pilot begins
- 11. When “not yet” is the best answer
- 12. Five short application screens
- A decision note you can actually review
- Check your understanding
- Frequently asked questions
- Sources and scope
- Screen a new idea: start with the one-sentence benefit test and the three promising patterns.
- Challenge an overclaim: read the weak-fit patterns and the boundary between records and reality.
- Plan a small experiment: use the design-review case, evidence plan and stopping rules.
- Learn by practice: classify the scenarios and explain what fact could change your answer.
Back to contents · Next section
1. Complete the benefit sentence without a buzzword
Try this sentence: “The system helps these participants do this specific task with this checkable improvement, because no single participant can perform this unwanted action alone.”
If the idea concerns verification rather than shared control, use: “The recipient can check this particular statement using this evidence without depending solely on this service’s current display.”
These are editorial prompts, not definitions of every valid blockchain application. Their purpose is to replace vague benefits with claims that can be tested.
For example, “make records transparent” is incomplete. Transparent to whom? Which records? Can the reader verify omissions or only inspect what the operator chooses to show? What consequence improves because of that access?
Likewise, “eliminate trust” is usually too broad. A more useful claim identifies one dependency being reduced while naming the dependencies that remain.
If the sentence cannot be completed, the next step is usually better problem research, not selecting a chain.
Back to contents · Next section
2. Three patterns that deserve serious evaluation
Independent parties need shared control of updates
Several organisations may need a common history while refusing to give one member final unilateral control. A jointly governed ledger can be a candidate if its actual permissions support the intended balance.
The requirement must be specific. “Many organisations use our website” does not establish shared-control needs if they all accept the same operator and its ordinary audit process.
Recipients need evidence they can check independently
A system may benefit from publishing commitments or records that recipients can compare with received documents or events in the system. The contribution is a defined verification capability.
This still does not automatically require a full blockchain application. Signed documents, independently retained receipts or verifiable credentials may provide enough evidence with less complexity.
Open participation is part of the purpose
Some systems are designed so that participation in specified roles does not depend on a single membership authority. That requirement can justify examining a permissionless architecture, subject to its protocol conditions and application constraints.
Open participation is not automatically the right goal for every workflow. A private internal service may gain little from it while taking on additional privacy and operating challenges.
Wüst and Gervais’s 2018 paper Do you Need a Blockchain? offers a requirements-led framework centred on writers and trust arrangements. Use it as a starting question set, not a current performance ranking of every platform.
Back to contents · Next section
3. Three weak-fit patterns
The problem is mainly poor input quality
If staff enter incorrect serial numbers or sensors are miscalibrated, preserving the submitted record does not correct the input. Better capture, review and accountability may solve more of the problem than a new ledger.
A blockchain might still help trace who submitted a disputed entry. That is a narrower benefit than guaranteeing the entry was true.
One accepted operator already has legitimate authority
A single organisation may own the process, control the data and be responsible for corrections. A conventional system with appropriate permissions and audit records should be a serious starting point.
There could still be a need for external verification. But it must be identified rather than assumed. Adding several nodes controlled by the same operator does not automatically change the authority structure.
The project promises permanence without a retention plan
A durable commitment does not ensure that a linked document remains obtainable. Nor does permanent disclosure automatically benefit the people described in a record.
Before preserving information broadly, decide what should be retained, who needs it and how errors or sensitive content are handled. “We can never remove anything” is not a complete information policy.
Back to contents · Next section
4. Separate the onchain contribution from the whole outcome
Consider a claim that a blockchain will make a supply process reliable. That outcome can depend on inspections, identification, transport, storage, authorisation and dispute handling.
The ledger may improve one part: keeping an agreed sequence of signed statements. The physical goods can still be damaged, substituted or incorrectly described. A reliable project must connect the digital record to accountable real-world procedures.
The same reasoning applies to certificates. A signature can help identify the issuer of a statement, but does not automatically make the issuer credible. W3C’s Verifiable Credentials Data Model v2.0 separates issuer, holder and verifier roles and permits multiple registry arrangements; blockchain is optional.
A good proposal names the contribution precisely and then shows how it fits into the larger process. It does not claim the entire outcome on behalf of one technical component.
Back to contents · Next section
5. Worked case: disputed design revisions
Imagine three independent engineering teams collaborating on a set of non-sensitive demonstration drawings. They repeatedly disagree about which revision was approved before a handover. This is a fictional planning exercise, not an account of a deployed project.
Their initial proposal is “put all drawings on blockchain.” That says little about the actual problem and may create unnecessary storage and access complications.
A better problem statement is: each team needs evidence of the exact revision it approved, the scope of that approval and the order of later corrections. They also need reliable access to the corresponding files.
Now separate the requirements. File matching can use fingerprints. Approval needs an authorised statement with clear meaning. Joint history may need shared control or independent retention. File retrieval needs storage. None of these alone proves the drawing is technically correct.
The strongest candidate is the smallest arrangement that meets those requirements. It could be signed approvals in an existing document system. It could be a shared audit service. It could include a permissioned ledger if unilateral rewriting remains an important unresolved risk.
The team should compare those possibilities before assuming that every byte of every drawing belongs onchain.
Back to contents · Next section
6. Turn the case into a testable hypothesis
A useful hypothesis might say: “Independent retention of approved-version evidence will reduce disputes about which file was approved, without making corrections or retrieval unacceptably difficult.”
Notice that the hypothesis does not require blockchain to win. It defines an improvement and leaves room to test how best to achieve it.
Choose a baseline. How does the team currently record approvals? Are disagreements caused by missing records, unclear wording, inaccessible files or genuinely conflicting decisions? A new ledger solves little if the real issue is that “approved” means different things to different teams.
Then choose a comparison workflow using synthetic documents. Have participants approve versions, make a correction and retrieve the evidence later. Evaluate both the ordinary system and the proposed ledger arrangement against the same tasks.
Do not invent savings percentages before measuring. A pilot should produce evidence, not merely decorate an already fixed decision.
Back to contents · Next section
7. Measure the user outcome, not just the transaction counter
For the revision case, useful observations include whether a reviewer can identify the approved file, how long it takes to resolve a deliberately introduced version dispute, whether participants understand the approval wording and whether files remain retrievable after a service interruption.
These are proposed measures, not reported results. They relate directly to the problem the team wants to solve.
A raw transactions-per-second number may matter for some workloads, but it does not answer those questions. Nor does the number of stored records show whether anyone can use the evidence effectively.
Include the failure path. If the website is unavailable, can participants still retrieve and interpret their approval evidence? If a signing authority is replaced, can the team explain the status of earlier statements? If a file is missing, what recovery path exists?
A useful benefit must survive more than the demonstration in which every component works perfectly.
Back to contents · Next section
8. Identify the minimum information that must be shared
A project can often separate a public or shared commitment from the underlying document. That can reduce disclosure, but it does not make privacy automatic.
Predictable information may be guessable even when only a hash is published. Metadata can reveal relationships or timing. Participants may also share more through interfaces and exports than the core ledger requires.
Ask what the verifier needs to learn. In the revision case, it may be enough to check a particular file against an approved fingerprint and signed statement. The verifier may not need access to every other drawing or every internal discussion.
Also distinguish verification from retrieval. Ethereum’s data-availability documentation explains why access to the required data matters. A commitment is not a promise that all relevant information can be obtained forever.
The design should state storage, access and retention arrangements explicitly. Privacy and availability cannot be outsourced to the word blockchain.
Back to contents · Next section
9. Count responsibilities as well as costs
A system’s burden includes more than server bills or transaction fees. Someone must maintain software, review permissions, handle incidents, explain corrections and help users recover from ordinary mistakes.
For the three design teams, ask who administers signing authority, who runs shared infrastructure and who answers a dispute after a team member leaves. If these responsibilities are unclear, a technically successful pilot may still be unsuitable for regular use.
Also ask whether the intended participants will perform their part. A consortium design that assumes independent operation may lose its purpose if every organisation delegates all control to the same unmanaged account.
These are not arguments against outsourcing or managed services. They are reasons to describe the actual arrangement. A managed service can be appropriate, but it should not claim a form of independence it does not provide.
A useful application fits the institutions that will operate it, not just the software diagram.
Back to contents · Next section
10. Write stopping rules before the pilot begins
A project needs reasons to continue and reasons to stop. Without both, every problem can become an excuse to add another layer.
For the revision case, sensible stopping conditions might include: the ordinary signed-document workflow already resolves the disputed-version problem; users cannot reliably understand what they are approving; retrieval remains dependent on an unacceptable single point of failure; or the proposed governance has no accountable owner.
These conditions are illustrative. The real project should set its own consequences and acceptance criteria before testing.
A stop does not mean the research was wasted. Finding that a simpler process meets the need is a useful outcome. Likewise, finding a narrow role for blockchain is often more credible than expanding it to every part of the workflow.
The decision should follow evidence about the problem, not the amount of effort already invested in the preferred technology.
Back to contents · Next section
11. When “not yet” is the best answer
Sometimes the need is real but the prerequisites are missing. The participants may not agree on what a record means, who can correct it or which organisation bears responsibility for a false submission.
In that situation, selecting a chain does not settle the disagreement. The software could faithfully enforce rules that nobody has actually agreed upon.
A productive next step may be a shared vocabulary, a written approval policy, a small signed-record prototype or a better inventory of existing data. Those steps can clarify whether a ledger is necessary later.
“Not yet” is therefore different from “never.” It identifies the missing condition that would make a future evaluation meaningful. A good project note states that condition explicitly, so the team knows what progress would change the answer.
This approach prevents technical implementation from outrunning the institutional agreement it depends on.
Back to contents · Next section
12. Five short application screens
An internal staff timetable: if one accepted administrator controls scheduling and corrections, begin with an ordinary scheduling system. Multiple viewers do not create a blockchain requirement.
A multi-organisation revision register: consider a ledger if independent control of the accepted history is genuinely necessary and signed-document alternatives do not meet the requirement. Verify retrieval and correction separately.
A portable adult training credential: first examine signatures and verifiable credentials. A blockchain is not automatically required merely because recipients are outside the issuing organisation.
A sensor record claimed to prove clean water: a ledger may preserve submitted observations, but calibration, sampling and scientific interpretation remain essential. Do not confuse provenance with truth.
A permanent record of every learner’s early mistake: permanence alone is not a benefit. Consider privacy, correction and the person’s future interests before choosing any durable disclosure mechanism; real personal data is unnecessary for a learning prototype.
These screens are provisional judgments about stated requirements, not universal bans or approvals. A changed requirement can change the answer.
Back to contents · Next section
A decision note you can actually review
Write a short paragraph containing the participant group, the current problem, the specific ledger contribution, the strongest simpler alternative and the evidence needed to decide.
For the design case: “Three teams need to identify approved drawing versions across handovers. A shared ledger might reduce unilateral changes to the approval sequence, while signed records in the existing document service may already meet the need. We will compare dispute reconstruction, correction clarity and file retrieval using synthetic documents before choosing.”
This note avoids promising outcomes that have not been measured. It also makes the alternative visible, so the pilot can produce a genuine decision.
Add one sentence about remaining dependencies: “Neither option establishes that the drawing is technically correct; professional review and accountable approval remain separate.”
The result is a bounded proposal that another person can challenge constructively.
Back to contents · Next section
Check your understanding
Question 1: A project has thousands of users. Does that establish a need for blockchain?
Answer: No. User count alone does not explain shared-control or independent-verification requirements. Identify the actual coordination problem.
Question 2: A file’s fingerprint is onchain. Has long-term access to the file been solved?
Answer: No. Matching and retrieval are different. The project needs a storage and retention arrangement.
Question 3: A pilot shows that a signed-document workflow solves the problem more simply. Is the pilot a failure?
Answer: No. It produced useful evidence for selecting an appropriate solution.
Question 4: The participants disagree about who can approve a correction. Should the team assume consensus software will resolve the policy question?
Answer: No. They need an agreed governance rule before software can enforce it meaningfully.
Back to contents · Next section
Frequently asked questions
Is blockchain useful only for money?
No. Shared records, attestations and programmable coordination can concern non-financial workflows. Suitability still depends on the particular requirements and remaining dependencies.
Must an application be fully decentralised to be useful?
No. A bounded improvement can be useful even when some authority remains concentrated. The claim should accurately describe which dependency is reduced and which is retained.
Does a successful demonstration justify deployment?
Not by itself. A demonstration usually shows a chosen path under chosen conditions. Deployment needs evidence about failure handling, governance, privacy and continuing operation.
What should I learn next?
Study the guarantees offered by hashes and signatures and the assumptions that support them. Clear cryptographic boundaries make application claims easier to evaluate.
Back to contents · Next section
Sources and scope
The underlying technical reference was researched on 12 October 2026, Asia/Singapore. The application screens, pilot measures and stopping rules are editorial synthesis. They are not measured outcomes or legal clearance for a particular service.
- Wüst and Gervais: Do you Need a Blockchain?, 2018 conference paper, author manuscript: requirements, writers and trust arrangements.
- NIST IR 8202: Blockchain Technology Overview, October 2018: foundational mechanisms and limitations.
- W3C Verifiable Credentials Data Model v2.0, Recommendation, 15 May 2025: issuer, holder and verifier roles; multiple registry arrangements.
- Ethereum: Data availability, living documentation: why verification depends on accessible data.
The practical standard is simple: identify a real problem, state the narrow contribution, compare a credible alternative and let evidence decide.