Blockchain learning guide · 中文版 · Related reading: Blockchain vs Traditional Databases
Blockchain sits inside a much wider technology system. Networks move messages, databases organise information, cloud infrastructure supplies computing resources, cryptography supports verification, and applications turn rules into usable services. A blockchain adds a particular method of coordinating shared state and history. It does not perform every job in that system.
This guide explains the relationships by following one fictional event: a school transfers a shared microscope to a laboratory. We trace the event from a person's screen to a signed request, through processing and storage, and back to a useful answer. The goal is to understand where blockchain belongs, what surrounding technologies contribute, and how to recognise a problem that a blockchain cannot fix.
Guide BC006 / 100 · English
Choose a route through the guide. The teaching sections remain expanded; open the contents to jump to a chapter.
Start from the problem · Understand the mechanism · Apply the ideas · Continue reading
Contents
Chapters 1–6
1. Start with the service people actually need
2. Read the system as a set of cooperating responsibilities
3. The interface translates human intention
4. Digital information represents the event
Chapters 7–12
7. Databases support organised retrieval
8. Ledgers emphasise events and accountability
9. Cloud computing supplies resources
10. Storage keeps large objects available
Chapters 13–18
13. Wallets and signing tools mediate control
14. Consensus coordinates a limited part of the system
15. Smart contracts formalise executable conditions
16. Sensors connect digital records to physical processes
Chapters 19–24
19. AI agents need bounded authority
20. A digital twin is a model, not the physical object
21. Privacy spans the entire data journey
22. Governance determines how the system changes
1. Start with the service people actually need
Describe success without naming a product
The school wants to know who holds microscope M17. The laboratory wants to reserve it without conflicting bookings. A maintenance company needs to record repairs. Together, they want a history they can examine when something goes wrong. These are service requirements, and they exist before anyone chooses a technical architecture.
Writing the requirements this way keeps the discussion grounded. “Use blockchain, AI and cloud” names possible components, but does not tell us whether a late delivery should block a reservation or who is responsible for a disputed repair. Technology choices become easier to evaluate when the desired behaviour is explicit.
Define the boundaries
Our fictional service records custody, reservations and maintenance status. It does not automatically prove legal ownership or physical condition. If the project later expands to payments or personal records, those additions introduce new requirements. A good architecture states both its scope and the circumstances that would require a new review.
2. Read the system as a set of cooperating responsibilities
One event travels through several components
A person opens an application, identifies an item and requests a handover. Software checks their role, prepares a message and obtains the necessary signature. A network carries the request. A ledger or database processes it. Other components retrieve the result and display the current status.
The components need not form a simple vertical ladder
The phrase technology stack is useful, but real systems also have side connections. Monitoring observes several layers. Identity affects both the interface and transaction permissions. Governance determines who can update software and who pays for infrastructure. Off-chain document storage may operate beside the ledger rather than beneath it.
Draw responsibility boundaries before drawing product logos. Label “stores documents,” “authorises transfers,” “orders accepted events” and “shows current custody.” Then ask which component provides each function and how the functions interact. This makes it much harder for an impressive diagram to conceal a missing responsibility.
Contents · Previous chapter · Next chapter
3. The interface translates human intention
A button is the beginning of a request
When an employee selects “Transfer M17,” the interface should explain what will change, which recipient is selected and what authority is required. It should distinguish a request being prepared from one accepted by the system. A reassuring animation is not evidence of completion.
Translation is part of correctness
An English interface might use “custody,” “ownership” and “reservation.” These are different meanings and need equally distinct Chinese wording: 保管责任, 所有权 and 预约. If the interface translates them all as a vague form of possession, the user may approve the wrong action even when the software works as designed.
For our handover, a review screen can show the equipment identifier, current custodian, intended recipient and effective condition. That is a design suggestion, not a claim that every application uses such a screen. Good interface design brings the actual consequence close to the moment of authorisation.
Contents · Previous chapter · Next chapter
4. Digital information represents the event
Computers process defined representations
The statement “M17 moves to the laboratory” must become structured data. Fields might include an equipment identifier, sender, receiver and request identifier. The system must define which fields are required, which values are permitted and how different versions of the message are interpreted.
Meaning requires agreement
One organisation might use “received” to mean a parcel arrived at reception; another might mean a technician inspected it. Identical field names do not guarantee identical business meaning. A shared schema therefore needs definitions and examples, including rejected cases.
In a teaching exercise, ask two groups to write a handover form independently, then exchange forms without explanation. Differences will appear quickly: one group records a date, another a time; one records a room, another an organisation. The exercise exposes the integration problem before any network or blockchain is involved. Shared semantics are essential to shared records.
| Mechanism | Question it helps answer |
|---|---|
| Hash | Detect a change to committed bytes |
| Signature | Verify a message against a key |
| Consensus | Coordinate accepted history |
Contents · Previous chapter · Next chapter
5. The Internet transports messages
Connectivity does not create agreement
The Internet connects networks so that applications can exchange data. The Web is one service built using that infrastructure. Blockchain nodes also use networking to communicate, but ordinary message delivery does not decide which competing equipment reservation is accepted. MDN's Internet explanation is a useful introduction to that infrastructure distinction.
Design for delays and interruption
An employee may submit a request while connectivity is unstable. A timeout means the client did not receive a timely response; it does not necessarily mean the server did nothing. Retrying blindly can create confusion unless the application can recognise the original request and report its status.
For M17, the client should be able to ask, “What happened to request R42?” rather than guessing from the last screen. This gives users a way to recover after interruption and prevents connection quality from silently determining the meaning of a business action.
Contents · Previous chapter · Next chapter
6. APIs connect programs
An interface for software, not just people
An application programming interface defines how one program asks another to do something or return information. A school booking system might call an equipment service to check availability. The equipment service might call a ledger access endpoint to submit an authorised transaction.
An API is not the underlying network
If one access endpoint stops responding, the ledger itself may still be functioning. Conversely, a responsive endpoint may return stale or incomplete information. The application needs to know what the returned status means and which evidence supports it.
An integration contract should specify request identifiers, error categories, authentication, versioning and retry behaviour. For example, “temporarily unavailable” should not be handled in the same way as “you lack permission.” These distinctions reduce accidental misuse and make recovery possible. They also show why adding a blockchain cannot compensate for an unclear API between two organisations.
Contents · Previous chapter · Next chapter
7. Databases support organised retrieval
A database answers operational questions
A conventional database can store equipment, reservations, staff roles and maintenance schedules. It can enforce constraints and support useful queries. A blockchain application may still use such a database to deliver fast searches or build a reporting view from accepted ledger events.
A displayed view can lag behind its source
Suppose the transfer is accepted, but the reporting database has not processed the new event. The laboratory may see the old custodian until the view catches up. This is an application synchronisation issue, and the interface should show enough status to avoid confusion.
Designers need to specify the source of authority for each field. Is the maintenance note authoritative in a service database, while custody is derived from the shared ledger? If two stores disagree, which process resolves the difference? A diagram containing both “database” and “blockchain” is incomplete until it explains those relationships.
Contents · Previous chapter · Next chapter
8. Ledgers emphasise events and accountability
Logs can explain change over time
An event log records things that happened or were accepted: item registered, reservation approved, handover acknowledged. It can support reconstruction of state and investigation of unexpected outcomes. A signed log can provide evidence about who authorised an entry without necessarily using a blockchain.
Blockchain is one possible coordination design
A blockchain adds protocol rules around a shared sequence and its verification. Whether this is needed depends on relationships among writers, readers and operators. If the training partnership accepts a central service provider, a conventional database with a well-designed audit trail might meet its needs.
Compare alternatives using the same requirements. Do not compare a carefully designed blockchain against a deliberately weak spreadsheet with no access controls or backups. A fair evaluation gives each candidate sensible security and operations. The useful difference should survive that comparison rather than depend on a poor baseline.
Contents · Previous chapter · Next chapter
9. Cloud computing supplies resources
Hosting answers a different question
Cloud infrastructure can provide computing, storage and networking resources on demand. It may host a database, an application server, a blockchain node or all three. NIST's cloud computing definition describes the resource-delivery model; it is not a claim about who governs an application running on it.
Many nodes can share one failure domain
Our three organisations might each operate a node but place them in the same cloud region under the same administrative account. The architecture appears distributed on a diagram while remaining exposed to a common outage or account compromise. Independence must be assessed across ownership, credentials, locations and dependencies.
Cloud use is not inherently incompatible with a distributed system. The important question is which failures the chosen arrangement can survive. Write those expectations explicitly, then examine whether hosting choices support them. Three boxes on a slide are not evidence of three independent operational environments.
Contents · Previous chapter · Next chapter
10. Storage keeps large objects available
Documents do not have to live on the ledger
A microscope handover may include photographs, inspection reports and manuals. Keeping all of these in a replicated ledger may be unnecessary or unsuitable. A design can store documents separately while recording identifiers or integrity commitments in the shared record.
A reference is not a preservation strategy
The document still needs access controls, backups, retention decisions and a retrieval procedure. If the storage service disappears, a valid hash only helps verify a copy that someone can actually obtain. It does not recreate the missing photographs.
Separate the questions: can the reader find the object; can the reader obtain it; can the reader check that it is the intended object; and is the reader allowed to see it? These questions involve discovery, availability, integrity and authorisation. They often require different mechanisms even when a product presents them as one storage feature.
Contents · Previous chapter · Next chapter
11. Cryptography supplies specific building blocks
Different tools solve different problems
Encryption protects the confidentiality of content under a particular key arrangement. Hashing supports comparison and commitment to data. Digital signatures support verification of messages associated with keys. None of these functions should be substituted casually for another.
Ask the exact question being answered
For M17, encryption could help keep an inspection report confidential. A hash could help detect whether the report changed. A signature could help verify which authorised key approved it. Those checks still do not prove that the technician inspected the correct microscope.
This three-question exercise is useful whenever a proposal says only “secured by cryptography.” What is kept secret? What change can be detected? What authority is being checked? Then ask how keys are created, protected, replaced and revoked. The quality of the key-management process determines whether the cryptographic design can be used safely in practice.
Contents · Previous chapter · Next chapter
12. Identity connects roles to authority
Login and transaction authority may differ
Logging into a school portal may allow an employee to view bookings without allowing them to transfer equipment. A separate approval role or signing process may govern that action. The application should not assume that a successful login grants every permission.
Identity has a life cycle
People join, change roles and leave. Devices are replaced. Service accounts are retired. The system needs timely updates to permissions and a way to investigate who held which authority when an action occurred. A permanent public key does not remove these administrative needs.
Credentials can also express claims that a verifier evaluates. The W3C Verifiable Credentials Data Model describes an issuer-holder-verifier approach without making blockchain mandatory for every implementation. This is a useful reminder: a technology can be valuable alongside blockchain while also being useful without it.
Contents · Previous chapter · Next chapter
13. Wallets and signing tools mediate control
A wallet is more than a balance display
In blockchain systems, a wallet commonly helps manage keys and prepare or authorise requests. The authoritative record of an asset or permission may live in the ledger state rather than inside the device's interface. Some arrangements delegate key management to a service provider.
Show the consequence that matters
For equipment custody, the user needs to understand which item is moving, to whom and under which authority. Showing only a long encoded message may satisfy a technical interface while failing the human decision. Simulation or decoded summaries can help, but their reliability and limitations still need consideration.
An organisation should define who can approve routine transfers, who can grant new permissions and who can recover access. These are different powers. Combining all of them in one everyday account can create an avoidable concentration of risk. The appropriate arrangement depends on operational needs rather than a universal wallet template.
Contents · Previous chapter · Next chapter
14. Consensus coordinates a limited part of the system
Agreement concerns defined data and rules
The ledger's consensus mechanism helps participants coordinate the accepted history under its assumptions. It does not decide whether the application interface is clear or whether a supplier's business terms are fair. Those problems sit outside the mechanism's direct responsibility.
Find the actual shared decision
In our example, the shared decision may be whether a properly authorised transfer changes the recorded custodian. The system does not necessarily need every participant to agree about a draft maintenance note or a private staff schedule. Keeping the shared state focused can reduce unnecessary complexity.
When a proposal sends every business detail into a consensus process, ask why. Some data may need only controlled storage or bilateral exchange. Architecture improves when each mechanism has a specific job, and when the team can explain what would break if that mechanism were removed.
Contents · Previous chapter · Next chapter
15. Smart contracts formalise executable conditions
Code can enforce a defined workflow
A contract might require the current custodian's approval and the recipient's acknowledgement before a transfer reaches a completed state. A different design might record dispatch and receipt as separate events. These choices shape what users see and how disputes are handled.
Automation requires exceptional cases
What if the item is dispatched but never received? What if the receiving organisation closes? What if a software error prevents acknowledgement? A workflow that handles only the happy path is incomplete, regardless of whether its code is stored on a blockchain.
Write the states and transitions in ordinary language first. Identify who can trigger each transition and what evidence it needs. Then check the implementation against that description. Solidity's security guidance illustrates why contract development requires security reasoning beyond simply making a program compile.
Contents · Previous chapter · Next chapter
16. Sensors connect digital records to physical processes
A reading is a claim made by a device
A temperature sensor may report that a shipment stayed within a certain range. Device identity and signed readings can help establish where a digital message came from. They do not independently prove the sensor was calibrated, installed correctly or attached to the intended shipment.
Inspect the whole measurement chain
For M17, a vibration sensor might help document transport conditions. The team would still need to associate the sensor with the microscope, maintain it, interpret missing readings and determine what a threshold crossing means. A quiet graph is not conclusive if the device was switched off.
This is the physical-to-digital boundary. Improving it often involves procedures, hardware checks and human accountability. Blockchain can preserve accepted records of those activities; it cannot substitute for performing them. The distinction is especially useful when evaluating supply-chain demonstrations that move quickly from a scanned code to a claim of complete authenticity.
Contents · Previous chapter · Next chapter
17. Oracles bring external inputs into execution
The data path creates dependencies
A smart contract may require an external condition: delivery acknowledged, inspection passed or a reference value updated. The mechanism supplying that information becomes part of the application. Its access rights and update timing matter as much as the contract's internal logic.
Decide what happens when data is unavailable
If the inspection service stops responding, should M17 remain unavailable, allow a manual review or follow another defined process? There is no universal answer. The consequence of a mistaken approval and the consequence of a delay need to be considered together.
An explicit stale-data rule is better than silently using an old result. The application should know which observation it is relying on and why that observation is suitable for the current decision. This is a broader engineering principle that applies to ordinary databases and AI systems as well as blockchain applications.
Contents · Previous chapter · Next chapter
18. Artificial intelligence interprets and predicts
AI can assist with unstructured information
An AI system might summarise a maintenance report, classify an issue or help a user locate the relevant procedure. These tasks differ from maintaining an agreed event history. A useful prediction can still be uncertain, and a fluent summary can omit or misinterpret a detail.
Recording an output does not validate it
If the service records an AI-generated assessment in an immutable-style log, the record may show what assessment was produced at a particular stage. It does not prove the assessment was correct. Verification of the record and evaluation of the model's reasoning are separate jobs.
For M17, an AI assistant could propose “schedule inspection” after reading a technician's note. A human or a tightly bounded workflow might then decide whether to act. The design should state whether the AI is advising, preparing a request or authorised to execute one. Those roles carry different consequences.
Contents · Previous chapter · Next chapter
19. AI agents need bounded authority
Capability is not permission
An agent that can call an API may be technically capable of requesting a transfer. The system should still decide whether it is allowed to do so, for which equipment and under what conditions. Natural-language instructions alone are not a complete access-control mechanism.
Make delegation reviewable
An illustrative policy might allow an agent to draft maintenance requests but require a staff member to approve custody changes. The policy should be enforced by the receiving system, not only described in the agent's prompt. Logging should connect the request to the relevant delegation and approval.
This connection between AI and blockchain is often overstated. Blockchain may help maintain a shared record of authorised actions, but it does not automatically make an agent reliable or supply the correct permission policy. The same disciplined separation of roles is useful even if the final architecture uses a conventional database.
Contents · Previous chapter · Next chapter
20. A digital twin is a model, not the physical object
Representations can become stale
A digital twin may bring together information about equipment condition, location and expected behaviour. Its usefulness depends on how accurately it is updated and how its model relates to the physical system. A beautiful visual model can be wrong.
Keep observation and inference distinct
For M17, “sensor measured a vibration event” is an observation. “The microscope probably needs recalibration” is an inference. “A technician completed recalibration” is a reported action. These statements need different evidence and should not be merged into a single unexplained status.
A shared ledger might record selected events used by the model. It would not make every inference true. A good interface lets users inspect the reason for a status, including where the data came from and whether it is recent enough. That makes the representation useful for decisions rather than merely attractive.
Contents · Previous chapter · Next chapter
21. Privacy spans the entire data journey
Look beyond the shared ledger
Sensitive information can leak through logs, analytics, support screenshots, backups and exported reports. Keeping personal data off-chain is often helpful, but it does not by itself secure all those other locations. The system needs a data-flow view.
Match access to purpose
The maintenance company may need the fault description without needing a learner's name. A school administrator may need a staff contact without needing every repair photograph. These differences should shape fields, views and access permissions.
For a classroom exercise, mark every place a staff email address would travel during a handover. Then ask which copies are necessary. Removing an unnecessary field can sometimes reduce more risk than adding another cryptographic feature. The practical aim is to collect, share and retain information for a clear purpose, with suitable controls at every step.
Contents · Previous chapter · Next chapter
22. Governance determines how the system changes
Every operating system needs decisions
Someone decides when to upgrade software, admit a new organisation, change fees or retire an obsolete interface. Even a technically decentralised network has processes through which changes are proposed, accepted or rejected. These processes affect the service's future behaviour.
Distinguish technical power from formal responsibility
The maintenance company may be able to operate a node without being authorised to change the custody policy. A software administrator may possess a powerful credential while being required to follow a joint approval process. The design should identify both the technical capabilities and the organisational rules.
For M17, write down who can add a new participant, replace a compromised signing key and approve an emergency pause. Then ask how those decisions are recorded and challenged. Unclear governance can undermine a technically sophisticated system precisely when participants most need a dependable resolution.
Contents · Previous chapter · Next chapter
23. Measure the complete service
One fast component does not guarantee a fast outcome
A benchmark might measure how quickly a ledger processes transactions while excluding identity checks, document uploads, indexer delays and human approvals. That number can be useful for a narrow technical comparison, but it does not tell a user how long an equipment handover takes.
Choose measurements tied to the task
For the training partnership, useful measures might include time to visible confirmation, rate of unresolved custody disputes, recovery time after an outage and staff time spent reconciling records. These are proposed evaluation measures, not measured results from an existing deployment.
Record the test conditions. A demonstration with three friendly participants and tiny messages does not establish performance under heavier load or malicious behaviour. Ask what was tested, what was excluded and which assumptions changed between the demonstration and the proposed production environment.
Contents · Previous chapter · Next chapter
24. Compare three complete architectures
Option A: a shared central service
An agreed operator runs the database and audit trail. Participants use controlled accounts and documented procedures. This can be a strong choice when the parties accept that operator and its accountability arrangements.
Option B: independently signed records
Participants exchange signed events and reconcile them through agreed procedures. This may support independent evidence without requiring a full blockchain network, although ordering and dispute resolution still need explicit treatment.
Option C: a permissioned shared ledger
Participants operate or rely on a network with defined membership, validation and agreement rules. This may be appropriate where shared verification and distributed control justify additional operational work.
For each option, use the same test case: two conflicting reservations, one compromised key, a missing document and an operator outage. Compare the resulting behaviour and total operating burden. Architecture selection becomes a reasoned decision when each option faces the same concrete questions.
Contents · Previous chapter · Next chapter
25. A learning route for China-focused readers
Begin with technology and application requirements
Shared industrial records, product traceability and cross-organisational data coordination provide understandable contexts for learning. They let readers examine the engineering without assuming that a financial asset or public token is necessary.
Keep policy context distinct from deployment approval
China's 2021 guidance on blockchain technology applications and industrial development places blockchain alongside other information technologies and discusses industrial applications. A policy direction is not a blanket approval for every product bearing the same label. This article uses the document as dated context, not as a substitute for checking current requirements for a real service.
The English and Chinese articles share the same engineering argument. The Chinese version explains terms in their local linguistic context, retaining English names where they help readers recognise documentation. Translation should preserve important distinctions, especially between a technical record, an operational decision and a legal right.
Contents · Previous chapter · Next chapter
26. Diagnose five failures by layer
The website is unavailable
Check the interface hosting and delivery path. A website outage does not by itself establish that the shared ledger stopped functioning. Users still need a clear alternative support or recovery process.
The screen shows an old custodian
Check the data source, indexer and cache. Compare the accepted event with the displayed view. Avoid submitting another transfer merely to force the screen to change.
An unauthorised person signs a valid request
Investigate key control, role assignment and revocation. The cryptographic check may have worked while the permission process failed.
The recorded delivery never happened
Examine the physical workflow and external evidence. Consensus about a submitted acknowledgement is not proof of the delivery itself.
An AI summary says the instrument is safe
Inspect the underlying report and decision policy. A model's text is not the same as an authorised technical inspection. Recording that text on-chain does not close the gap.
Contents · Previous chapter · Next chapter
27. Build a small architecture review
Write a one-page responsibility map
Name the users, the actions they need, the data involved and the source of authority for each result. Identify the interface, identity system, processing rules, storage, shared record and operational owner. Use ordinary words first; add product choices later.
Trace one success and one failure
Follow M17 through a normal transfer, then repeat the exercise with the receiver offline. At every step, ask what is known, what is merely assumed and which component can provide evidence. Mark where a human decision is required.
If you can explain those two journeys clearly, you understand more than a diagram full of technology names would reveal. Blockchain becomes easier to evaluate when it has a precise place in the system: a possible mechanism for shared state and history, surrounded by the technologies and responsibilities that make the service work.
Continue learning
What Is Blockchain? A First-Principles Guide
Source context checked: 12 October 2026. Platform details and policy requirements can change. The equipment partnership is a fictional teaching example.
Previous: Blockchain History: From Digital Cash to Programmable Systems