中文版 · Blockchain learning guide · Previous: Distributed Systems vs Blockchain
Blockchain learning · Article BC004
A trust model states which actors and components a system relies on, what powers they hold and which failures its guarantees can withstand. It turns a broad claim such as “the record is trustworthy” into questions that can be checked.
For a blockchain application, the model must extend beyond the chain. A user may also depend on a website, signing device, identity service, administrator, document store and source of outside information. Strong agreement about a ledger does not automatically make every surrounding dependency reliable.
The aim is not to declare that everyone is untrustworthy. It is to make reliance explicit, limit unnecessary power and design a sensible response when an assumption fails. This guide shows how using a hypothetical research-report archive.
Choose your reading route
In this guide
- 1. A trust model is not a popularity score
- 2. The archive example: a real need with several boundaries
- 3. Start with the claim the reader needs
- 4. List actors by role, not by brand name
- 5. Follow one report through the whole path
- 6. Distinguish a dependency from a trust assumption
- 7. Examine the powers that ordinary users do not see
- 8. Ask what happens when an assumption fails
- 9. Integrity, availability and confidentiality require separate answers
- 10. External facts need accountable sources
- 11. A practical trust-model worksheet
- 12. Test independence rather than counting participants
- 13. Trust models should change when the system changes
- Exercise: rewrite three vague claims
- Frequently asked questions
- Sources and scope
- Understand the concept: begin with assumptions, actors and the worked archive example.
- Evaluate an application: follow the record through its dependencies and examine control paths.
- Prepare a project discussion: use the trust-model worksheet and failure review.
- Revise the lesson: complete the claim-rewriting exercise and check the answers.
Back to contents · Next section
1. A trust model is not a popularity score
A trustworthy person can make a mistake. A reputable organisation can experience an outage. A correctly functioning service can hold more authority than the application actually needs.
A trust model therefore does not simply rank participants as good or bad. It describes specific reliance. For example: “The archive relies on the laboratory’s signing authority to identify the submitted report” is more useful than “The laboratory is trusted.”
The first statement can be examined. Who controls the signing authority? Does the author approve the exact file? What happens if a key is compromised? Can a verifier distinguish an old signature from a new unauthorised submission?
The second statement is too broad. It hides identity, authorisation, scientific quality and operational reliability inside one word.
Begin by replacing “we trust X” with “we rely on X to do Y, and if X fails, Z may happen.” That sentence is the smallest useful unit of a trust model.
Back to contents · Next section
2. The archive example: a real need with several boundaries
Imagine three independent laboratories sharing an archive of research reports. They want readers to identify which organisation submitted a particular version, see later corrections and obtain the referenced document.
They are considering recording report fingerprints and signed submission statements on a jointly maintained ledger. The full reports would remain in a separate document store. The example is hypothetical and does not describe a deployed eduKate service.
The proposal contains several different promises. A fingerprint may help compare a retrieved file with the committed version. A signature may support attribution to a signing authority. The ledger may establish the accepted sequence of submissions. The document store must make the file obtainable.
None of these promises establishes that the experiment was well designed or the conclusions are correct. Scientific review remains a separate process. A trustworthy archive can preserve a flawed report accurately.
A useful trust model keeps these boundaries visible instead of allowing the word “verified” to cover them all.
Back to contents · Next section
3. Start with the claim the reader needs
Before drawing actors and arrows, write the claim a user should be able to rely on.
For the archive, a narrow claim might be: “This file matches the version registered by Laboratory A under its recognised submission authority.” That is different from “Laboratory A’s conclusions are true” or “Every author personally approved publication.”
Next, identify what evidence supports the narrow claim. The verifier needs the file, the fingerprint calculation, the registered value and the relevant authorisation information. If the site supplies only a green badge, the verifier needs to know how the badge was produced and whether its conclusion can be checked independently.
Finally, state the exclusions. The archive may not verify experimental methods, consent for publication or legal ownership of all included material. These omissions are not automatically defects, but they must not be disguised as guarantees.
A clear claim prevents the technical system from taking credit for work it does not perform.
Back to contents · Next section
4. List actors by role, not by brand name
Useful roles in the archive include the report author, laboratory approver, signing service, ledger participant, website operator, document-storage provider and reader.
One organisation may fill several roles. One role may also be divided among several organisations. The trust model should show both situations, because shared branding does not prove shared authority, and different names do not prove genuine independence.
For each role, ask what it can actually do. Can the website operator merely display records, or can it also authorise new entries? Can the storage provider replace a file, delete it or deny access? Can the laboratory administrator rotate the signing key without another party’s approval?
Record powers rather than job titles. “Maintainer” sounds modest, but an account that can replace application code may have greater effective control than a committee with no execution authority.
This is especially important when a product uses a public blockchain. An open underlying network does not reveal who controls the particular application built on it.
Back to contents · Next section
5. Follow one report through the whole path
Creation: an author produces a report. The archive does not automatically observe how the experiments were performed or whether the report includes an error.
Approval: the laboratory decides which version it authorises for submission. If approval happens in an email while a different file is uploaded, the process needs a way to detect the mismatch.
Signing: the appropriate authority signs a statement about the chosen version. The statement should have a clear meaning: submission, approval, authorship and quality certification are different assertions.
Recording: the ledger accepts the statement according to its rules. A valid record says something about accepted authorisation and ordering, not about every scientific proposition inside the report.
Storage: the complete file remains accessible somewhere. A recorded fingerprint is not a backup and cannot reconstruct a missing report.
Presentation: the website shows the record to a reader. The interface might be mistaken or compromised even if the underlying ledger is functioning correctly.
Verification: the reader obtains the necessary evidence and checks the intended claim. The strength of the result depends on the whole path, not its most impressive component.
Back to contents · Next section
6. Distinguish a dependency from a trust assumption
A dependency is something the application needs. A trust assumption states how that thing is expected to behave for a particular guarantee to hold.
The archive depends on document storage. For availability, it assumes that at least one suitable source can supply the file when needed. For integrity, it may rely less on the storage provider if the reader independently checks the file against a trusted commitment.
This distinction reveals useful design opportunities. You may not need to trust the storage provider to avoid replacing bytes silently, provided replacements are detectable and the reader actually performs the check. You still need a way to obtain the correct bytes. Detection and recovery are different capabilities.
Similarly, a reader may avoid relying on a website’s displayed status by independently checking a signed record. But this shifts work and assumptions to verification software, data access and key information. It does not make the system dependency-free.
The goal is to understand where reliance has moved, not merely to claim that it has disappeared.
Back to contents · Next section
7. Examine the powers that ordinary users do not see
Application interfaces usually emphasise routine actions: submit, view and download. A trust model must also cover privileged actions.
Who can upgrade the contract or application rules? Who can pause submissions? Who can change which laboratory keys are recognised? Who can replace the website’s data source or alter the meaning of a verification badge?
Some of these powers may be necessary. Recovery from a compromised key or a serious software bug can require an authorised intervention. The design question is whether that intervention is constrained, visible and reviewable.
For example, a policy could require distinct approvals for changing a laboratory’s recognised signing authority. That reduces unilateral power only if the approvers are genuinely separate and the implementation enforces the policy. Several approvals controlled by one person may offer less protection than the diagram suggests.
Solidity’s security guidance emphasises that contracts operate within a wider technical environment and that application correctness does not remove every risk. Treat review and testing as evidence about defined code and assumptions, not a permanent guarantee. Solidity security considerations.
Back to contents · Next section
8. Ask what happens when an assumption fails
Consider four failures in the archive.
The laboratory key is compromised. An attacker may submit a statement with a technically valid signature. The response needs to distinguish recognising the compromise, changing future authority and explaining affected past records. The ledger cannot infer the moment of compromise merely from the signature.
The website displays a false status. Independent verification might reveal the mismatch, but only if readers can access another route and understand the check. A theoretical verification capability that nobody can use offers limited practical reassurance.
The document store loses the file. The ledger can retain its fingerprint, yet the report may be unavailable. Redundant storage and retrieval testing address a different problem from record integrity.
A report is corrected. The archive needs to connect versions and explain which claim is current. Keeping the old version can support accountability, but access and retention still need an appropriate policy.
These scenarios are not predictions of failure. They are probes: each asks whether the proposed guarantee survives and, if not, whether the consequence is acceptable and recoverable.
Back to contents · Next section
9. Integrity, availability and confidentiality require separate answers
Integrity concerns whether information has been changed in an unauthorised way or whether a presented result matches the relevant evidence.
Availability concerns whether authorised users can obtain the information or service when needed.
Confidentiality concerns which information is revealed and to whom.
In the archive, a publicly visible fingerprint may contribute to an integrity check, but it does not ensure that the report can be downloaded. Publishing the entire report might improve access while violating a restriction on disclosure. Encrypting a file can protect content under the chosen design but introduces key-management and recovery requirements.
Avoid trading one property for another without saying so. “The record is secure” should become a set of bounded statements: which modifications are detectable, how retrieval works, what is exposed and which assumptions each statement needs.
NIST’s Blockchain Technology Overview, October 2018, helps establish the record-integrity vocabulary. It does not remove the need to analyse application-specific privacy and operational arrangements.
Back to contents · Next section
10. External facts need accountable sources
Suppose the archive adds a label saying “peer review completed.” A smart contract cannot simply know that reviewers performed a meaningful review. Some actor or mechanism must supply the relevant statement.
The trust model should identify that source, the statement’s scope and the correction process. Does “completed” mean that a report was sent to reviewers, that comments were received or that a formal decision was approved? Ambiguous inputs produce ambiguous guarantees even when execution is perfectly consistent.
Multiple reporters do not automatically establish independence if all copy the same upstream status. The important question is how the information was obtained and what failure patterns the reporting design covers.
Ethereum’s oracle documentation explains why outside data introduces additional trust assumptions. The archive example applies that boundary to an ordinary information workflow, without assuming that a ledger can judge research quality.
Back to contents · Next section
11. A practical trust-model worksheet
Write one short entry for each important role or component. Use six prompts.
- Role: who or what performs the function?
- Power: which action can it take, and can it act alone?
- Reliance: what behaviour does the user depend on?
- Evidence: how can the relevant action or result be checked?
- Failure: what happens if the component stops, lies or is compromised?
- Response: who can detect the issue, limit harm and recover?
For the document store, an entry might say: it serves report files; it can deny access; users rely on retrieval; file fingerprints allow integrity comparison; deletion can break availability; independently retained copies may support recovery.
For the laboratory approver, the entry might say: it authorises a specific version; users rely on a meaningful approval process; signed statements provide evidence of the authorised claim; compromised authority can produce false submissions; revocation and incident notices govern future handling.
These entries should be brief enough to review but specific enough to challenge. If every response says “the blockchain handles it,” the model is not finished.
Back to contents · Next section
12. Test independence rather than counting participants
A diagram may show five approvers, but all five accounts could be managed by one service. Three storage providers could share one upstream copy. Several oracle reporters could repeat the same database entry.
Ask what shared failure would affect the supposedly independent parties together. Shared credentials, software, hosting, source data and decision-making can each matter.
Independence is also purpose-specific. Two copies in different buildings might protect against a local equipment failure but not against a common administrator deleting both. Separate organisations may constrain unilateral policy changes without protecting against a shared software bug.
A realistic model names the failure it addresses. It does not imply that a larger participant count creates unlimited safety.
Back to contents · Next section
13. Trust models should change when the system changes
A model is useful only while its assumptions describe reality. Revisit it when an application changes its administrator, upgrades important code, introduces a bridge, changes identity providers or moves document storage.
Also revisit it when the claim changes. An archive that originally proved version matching may later advertise certification of scientific quality. That stronger claim requires different evidence and responsibilities, even if the underlying ledger is unchanged.
Keep a dated record of major assumptions and the reason for each change. A short explanation of a new dependency is more useful than retaining an old “decentralised” badge after the operating model has changed.
This is an editorial governance recommendation, not a claim that every application requires the same review schedule. The appropriate trigger depends on the consequences of the change.
Back to contents · Next section
Exercise: rewrite three vague claims
Claim A: “Our reports are verified by blockchain.”
Better version: “The archive records a fingerprint and an authorised submission statement for each version; readers can compare a retrieved file with that record. Scientific accuracy is assessed separately.”
Claim B: “No one needs to trust the operator.”
Better version: “Readers can independently check specified records if they obtain the required data and verification tools. The operator still controls the website and its availability.”
Claim C: “Five signatures make the update safe.”
Better version: “The update requires five approvals under the stated policy. Its protection depends on who controls those approvals, what they review and how compromised authority is handled.”
The exercise is not about making every sentence longer. It is about giving the reader a claim they can actually evaluate.
Back to contents · Next section
Frequently asked questions
Does a trust model prove a system is secure?
No. It states assumptions and dependencies so that design, testing and review can assess them. A precise model can still describe a weak system; its benefit is that the weakness becomes easier to identify.
Is trust always something to eliminate?
No. Accountable institutions and explicit authority can be useful. The aim is to avoid hidden or unnecessary reliance and to ensure that the remaining reliance fits the task.
Can signatures establish identity?
They support a connection to signing authority. Relating that authority to a real organisation or person requires an identity arrangement. W3C’s credential model distinguishes issuers, holders and verifiers and does not make issuer honesty automatic. Verifiable Credentials Data Model v2.0.
What should a beginner draw first?
Draw the user, the claim they need, the evidence they receive and each actor able to change or withhold that evidence. Add the blockchain only where it actually contributes to that path.
Back to contents · Next section
Sources and scope
The foundational technical reference was researched on 12 October 2026, Asia/Singapore. The archive, worksheet and rewritten claims are hypothetical educational analysis. They do not describe a deployed product or certify an application.
- NIST IR 8202: Blockchain Technology Overview, October 2018: foundational record and trust concepts.
- Ethereum: Oracles, living documentation: external inputs and additional assumptions.
- Solidity: Security Considerations, living documentation: code, platform and operational risks.
- W3C Verifiable Credentials Data Model v2.0, Recommendation, 15 May 2025: issuer, holder and verifier roles.
A good trust model does not end with “trust the chain.” It explains the whole route from a user’s question to the evidence that supports the answer.
Next: Blockchain History: From Digital Cash to Programmable Systems