Blockchain is a way for several participants to maintain and check a shared history of records under agreed rules. Cryptographic links help expose changes to that history; network rules determine which proposed updates become accepted. Its usefulness depends on who participates, what they need to agree about, and which failures the system must withstand.
To understand blockchain technology, start with a practical question: if several organisations keep records of the same activity, whose version should everyone use? This guide develops the answer through a shared equipment register, then connects it to signatures, blocks, consensus, smart contracts and real-world limits. No cryptocurrency purchase, software installation or coding experience is needed.
Guide 001 / 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 a disagreement about a record
2. State and history are different things
3. Why copying a file does not create agreement
6. Digital signatures answer a narrower question than identity
Chapters 7–12
7. Follow one transaction from request to result
8. Validation and consensus do different jobs
9. Two public-network approaches, briefly
10. Public and permissioned systems have different boundaries
Chapters 13–18
13. Smart contracts automate explicit rules
14. The outside world enters through people and systems
15. A token is a representation with rules
16. Privacy requires deliberate choices
Chapters 19–23
19. Reading blockchain technology in a China context
20. Test your understanding with four small failures
21. Common questions, answered precisely
22. A worked comparison: two reservations for one instrument
23. A first-principles explanation you can give someone else
1. Start with a disagreement about a record
Three organisations, one piece of equipment
Imagine a fictional training partnership. A school, a laboratory and a maintenance company share a specialist microscope. Each organisation keeps a spreadsheet recording where it is, whether it is available and who may move it. On Monday, the school records a transfer to the laboratory. The maintenance company still sees the school as the holder. On Tuesday, two people try to reserve the same instrument.
The immediate problem is not that a spreadsheet cannot store a microscope record. It can. The problem is that several organisations need a dependable way to recognise the same sequence of changes. If one administrator controls the master spreadsheet, everyone must accept that administrator's authority and procedures. That may be perfectly reasonable. If no organisation is willing or permitted to take that role, the design question becomes harder.
A ledger records events, not just today's answer
A ledger could record “the school transferred custody to the laboratory,” followed by “the laboratory sent the microscope for maintenance.” The current holder is calculated from that accepted history. This makes the sequence important: the laboratory should not transfer an item before it has received it. Our example is hypothetical, but the distinction between a present value and the events that produced it is fundamental.
2. State and history are different things
The present state
The register's state might say: microscope M17, custodian laboratory, condition operational, reservation none. An application reads this state to answer a question such as “Can we book it tomorrow?” A transaction proposes a change: reserve it for a particular session, acknowledge delivery or mark it unavailable.
The accepted sequence
History explains how the state became what it is. Suppose two reservations both look valid when the instrument is free. Once one reservation is accepted, the other may no longer be valid. The system therefore needs more than two correctly written messages. It needs rules for processing competing proposals against the appropriate state.
A useful beginner exercise is to draw two columns headed “event” and “state after event.” Start with “M17 created in register,” then add a transfer and a reservation. Calculate the resulting custodian and availability after each step. If you cannot explain each state change, adding blocks will obscure the problem rather than solve it.
Contents · Previous chapter · Next chapter
3. Why copying a file does not create agreement
Replication helps availability
Keeping copies on several machines can make a service more resilient. A broken laptop need not destroy the only record. Yet copying by itself does not tell the participants which of two conflicting updates to accept. Ten inconsistent spreadsheets are still inconsistent.
Different computers see different things first
Messages travel through networks with delays. The school may see one reservation before another, while the laboratory receives them in the opposite order. A computer can also go offline, restart from older data or receive a deliberately misleading message. A shared system needs explicit behaviour for these situations.
This is why “distributed” and “decentralised” answer different questions. Distributed describes work or data spread across machines. Decentralised concerns the distribution of control. One company can run hundreds of servers while retaining the power to change every important rule. Counting machines alone tells us little about who holds authority.
Contents · Previous chapter · Next chapter
4. What a blockchain adds
Records are linked in batches
In a typical blockchain, accepted transactions are collected into blocks. Each block refers cryptographically to a preceding block. That relationship makes the history a chain: changing an earlier block changes the information later links depend on. The exact fields and validation rules differ among systems.
A chain needs rules around it
A hash-linked file on one laptop is not the same thing as a working multi-party blockchain network. Participants also need rules for valid transactions, block production, message handling, choosing or finalising history, and joining the system. Software must implement those rules, and people must operate it.
NIST's Blockchain Technology Overview describes blockchains in terms of distributed ledgers that make tampering evident and resistant under normal operation. The careful wording matters. A useful definition should explain a protection and its assumptions, rather than promise that every record becomes eternally unchangeable in every possible circumstance.
| 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. Hashes help detect changes
A compact result derived from data
A cryptographic hash function takes input data and produces a fixed-length result. For a suitable modern function, changing the input is expected to produce a different result, and deliberately finding different inputs with the same result should be computationally infeasible. A hash is not a compressed copy from which the original file can simply be reconstructed.
Apply it to our microscope register
Suppose a signed handover document is stored separately and its hash is recorded in the register. Later, someone presents a document claiming to be the original. Recomputing the hash lets a verifier test whether the presented bytes match the committed bytes. This does not reveal whether the original statement was honest or whether the microscope physically arrived.
Even formatting can matter: two documents that look identical to a person may contain different bytes. A robust system defines the file format and exactly what is hashed. “The words look the same” and “the digital object is identical” are different tests. This is a small example of why precise engineering matters more than a fashionable label.
Contents · Previous chapter · Next chapter
6. Digital signatures answer a narrower question than identity
Authorisation through keys
A digital signature enables verification that a message was signed using the private key corresponding to a public key. The protocol can associate that key with authority to perform certain actions. In our example, the laboratory's authorised key may sign a handover request.
A valid signature is not a complete explanation
The signature does not independently prove that the person using the key was the intended employee, understood the request or acted honestly. The key may have been stolen. An employee may have left. A compromised application may show a harmless description while asking for a harmful signature.
The register therefore needs an operational policy: who receives keys, how permissions are assigned, how departures are handled, and what happens after compromise. Keep these questions beside the cryptography rather than treating them as an afterthought. An elegant mathematical check can verify a message from a key that the organisation should no longer trust.
Contents · Previous chapter · Next chapter
7. Follow one transaction from request to result
Construct, sign and broadcast
The school prepares a request transferring M17 to the laboratory. It includes the required identifier and any protocol-specific information needed to prevent accidental or malicious reuse. An authorised party signs the request, and a client submits it to the network. At this point it is a proposal, not an accepted change.
Validate, order and apply
Nodes check the request against the system's rules. Does the signature verify? Does the school have the required authority? Is the item in a state that allows transfer? The network's ordering and consensus machinery determines how accepted requests enter history. Participants then derive the updated state according to the protocol.
Confirm the relevant outcome
An interface should distinguish submitted, included, accepted and sufficiently final for the intended activity. These labels are not interchangeable. A transaction can also be included yet fail during execution in some systems. Before the laboratory releases another item in exchange, it needs a clear rule for which outcome counts as completion. Ethereum's transaction documentation illustrates one implementation; other ledgers use different transaction structures.
Contents · Previous chapter · Next chapter
8. Validation and consensus do different jobs
Validation checks the rules
An invalid request does not become valid merely because it is popular. If the laboratory lacks permission to transfer a microscope held by the school, a correctly implemented validator should reject that request under the register's rules. Validation asks whether a candidate action satisfies defined conditions.
Consensus coordinates accepted history
Consensus addresses how participants reach or preserve agreement despite delays and specified kinds of failure. The mechanism, trust assumptions and guarantees vary. Some systems use proof of work, some proof of stake, and some rely on identified organisations running a fault-tolerant protocol.
Our register could allow only three named organisations to participate, but “three” alone tells us nothing about its fault tolerance. We need to know the protocol, the required voting conditions, what kinds of fault it handles and which parties can collude. Do not infer security from a node count or from the word consensus. Ask what the network is actually assuming about its participants.
Contents · Previous chapter · Next chapter
9. Two public-network approaches, briefly
Proof of work
Proof of work makes block production depend on performing computational work. Bitcoin's design combines that mechanism with transaction validation and rules for selecting a chain with the most accumulated work. Rewriting accepted history faces constraints related to competing work and network conditions. The original Bitcoin paper is a historical primary source for the design.
Proof of stake
Proof-of-stake systems use economically committed stake and protocol-specific rules to select or coordinate validators. Rewards and penalties are part of their design. Ethereum's proof-of-stake explanation describes its particular validator system; it should not be treated as the definition of every proof-of-stake network.
Neither mechanism automatically makes an application well designed. A secure base network can still process a harmful transaction that a user genuinely authorised, or run vulnerable application code. Separate the question “Did the network enforce its rules?” from “Were those rules and that request good for this user?”
Contents · Previous chapter · Next chapter
10. Public and permissioned systems have different boundaries
Participation rules matter
A public, permissionless network generally allows participation without approval from a central membership administrator, subject to the protocol's requirements. A permissioned network restricts one or more roles to approved participants. Reading records, submitting transactions and validating updates can have separate access rules.
Choose for the actual relationship
Our training partnership may want identified organisations, private business information and clear responsibility for mistakes. Those requirements differ from a network designed to let strangers transact without a shared administrator. Hyperledger Fabric is an example of a platform designed for permissioned enterprise networks.
Do not rank all systems on a single scale from “less blockchain” to “more blockchain.” Evaluate the protection needed and the authority accepted. A private network may distribute recordkeeping while still granting substantial power to a membership operator. That arrangement can be useful if it is understood and suitable for the participants.
Contents · Previous chapter · Next chapter
11. What immutable should mean in careful explanations
Tampering can become detectable and costly
Cryptographic links can expose changes. Replicated records and consensus rules can make replacing accepted history difficult under specified assumptions. These properties support auditability, but they are not a universal law that prevents every conceivable change.
Corrections still need a design
Suppose M17 was recorded as damaged because someone selected the wrong menu item. An append-only approach can add a correction with a reason and an authorised signature, retaining the original event. The current application view may then show the corrected condition while the audit view explains the change.
Different problems need different remedies. An incorrect business record, an unauthorised transaction, a software bug and a disputed protocol upgrade are not the same event. Recovery may involve an application-level correction, emergency controls or human governance. Ask which mechanisms exist before something goes wrong. “Immutable” should lead to a discussion of responsibilities, not end it.
Contents · Previous chapter · Next chapter
12. Finality is about when to rely on a result
Inclusion is not always the last step
Some systems can temporarily produce competing histories. A later decision may change which recent blocks are accepted. Other protocols define explicit finalisation conditions under stated assumptions. The meaning of a confirmation therefore depends on the network.
Match the decision to the consequence
In our example, displaying a provisional reservation is different from shipping an expensive microscope. The interface can show progress early while the shipping process waits for the required finality condition. The business must decide what to do if the network stalls rather than silently interpreting “no answer” as approval.
A useful design document names the condition, its assumptions and the fallback. “Wait until safe” is not testable. “Proceed only after the designated finality signal; otherwise hold the shipment for review” gives the team a procedure to implement and examine. The precise signal must come from the selected protocol rather than a generic blockchain rule.
Contents · Previous chapter · Next chapter
13. Smart contracts automate explicit rules
A program can enforce a transition
A smart contract is program logic executed within a blockchain system. For our register, it might prevent a transfer unless the signer is the current custodian and require an acknowledgement from the receiving organisation. It may also record events that an application uses to update its display.
The program only has the information it receives
The contract cannot look through a laboratory window to see the microscope arrive. It can check a digital acknowledgement, but someone or something must supply it. It also cannot resolve an ambiguous physical dispute merely because the code ran successfully.
Smart contracts need tests, permission design and carefully specified exceptional cases. Their name does not mean they possess intelligence or necessarily constitute a complete legal agreement. Ethereum's smart-contract introduction provides a platform-specific starting point. When reading any example, ask what the program knows, what it assumes and who can change it.
Contents · Previous chapter · Next chapter
14. The outside world enters through people and systems
An oracle supplies external information
A blockchain application may depend on a delivery status, sensor reading or market price. An oracle is a mechanism for bringing such external information into the application's on-chain decision process. The data source, update method and failure handling become part of the trust model.
A perfect record can preserve a false statement
If an employee falsely acknowledges delivery, faithfully recording that acknowledgement does not make the delivery real. If a sensor is attached to the wrong crate, a valid signature from that sensor does not fix the physical mismatch. The register must distinguish evidence of a submitted claim from evidence that the claim is true.
For M17, a stronger workflow might combine a receiver's acknowledgement, a serial-number check and a defined dispute window. That is an illustrative design choice, not proof that a blockchain is needed. Ethereum's oracle documentation explains the general boundary between deterministic execution and external inputs.
Contents · Previous chapter · Next chapter
15. A token is a representation with rules
The ledger can track a digital unit
A token may represent a native network unit, a claim defined by an issuer, an access right or another application concept. Its meaning depends on the system. The register could assign a digital identifier to M17, but the identifier would not physically contain the microscope.
Control and rights must be connected
If the ledger says one organisation controls an M17 token, does that mean ownership, temporary custody, booking rights or something else? Who recognises that meaning? Can the token be transferred independently of the actual equipment? What happens after loss or damage?
These questions prevent a common shortcut: assuming that creating a digital record creates the desired real-world right. In our teaching example, the agreement among organisations would need to define the relationship. A technical transfer and a legally or operationally effective transfer may be separate events. The article teaches the distinction without recommending any asset or transaction.
Contents · Previous chapter · Next chapter
16. Privacy requires deliberate choices
Shared does not automatically mean confidential
Putting information on a widely readable ledger can expose it to people beyond the original participants. Encrypting a field does not erase metadata, and giving several parties access expands the set of places where data may be copied. Long retention can create problems long after the original use case changes.
Minimise what needs to be shared
Our register might need an equipment identifier and an organisation's acknowledgement, while staff contact details remain in a controlled off-chain system. The design should ask which parties need each field and for how long. A hash is not a universal anonymisation tool: if the underlying value is easy to guess, someone may test candidate values.
Keep an inventory of both on-chain and off-chain data. Explain where documents reside, who may retrieve them, how access changes and what happens if a storage provider disappears. A permanent pointer to an unavailable document is still an unavailable document. Integrity, availability and confidentiality are separate requirements.
Contents · Previous chapter · Next chapter
17. The rest of the technology stack still matters
Users interact with more than a ledger
A typical application also has a website or mobile interface, identity tools, servers, network connections, data storage, monitoring and support. A wallet or signing service handles keys and requests. An indexer may turn raw events into a searchable view. Each component can fail independently.
Diagnose the layer before proposing the cure
If the laboratory's screen shows yesterday's status, the cause could be a stale cache or broken indexer rather than a consensus failure. If a transaction cannot be submitted, the chosen access endpoint may be down while the underlying network continues operating. If a document cannot be opened, its off-chain storage may be the issue.
The wider lesson is that blockchain belongs within an information system. It does not replace all the other layers. The companion article, linked in the reading navigation, follows a single equipment handover through those layers and explains what each technology contributes.
Contents · Previous chapter · Next chapter
18. Decide whether the added coordination is worthwhile
Compare at least three designs
For M17, compare a central database run by an agreed operator, a signed event log shared among organisations, and a permissioned blockchain. All three can record transfers. Their differences include control, independent checking, operational complexity, privacy and recovery.
State the reason before choosing the product
A useful requirement might be: each participating organisation must be able to verify the accepted transfer history without relying solely on another organisation's private database export. That is more specific than “we need blockchain.” It still leaves room to evaluate alternative ways of meeting the requirement.
Include the cost of running nodes, managing keys, upgrading software and resolving disputes. If all participants already accept a single responsible operator, a conventional system may meet the need more simply. Choosing it is evidence of sound reasoning when the comparison supports that choice. The goal is a dependable service, not a predetermined architecture.
Contents · Previous chapter · Next chapter
19. Reading blockchain technology in a China context
Use the right conceptual category
For readers in China, it helps to separate distributed recordkeeping, industrial applications and cryptocurrency-related activities as different topics. Understanding hashes or a consortium ledger does not itself answer a question about a particular commercial service's legal status.
Read official documents with their dates and scope
The 2021 MIIT and CAC guidance on blockchain technology applications and industrial development discusses integration with other information technologies and applications such as traceability. Its stated goals are policy objectives, not evidence that every goal has been achieved. The CAC announcement of the 2019 blockchain information service provisions concerns a specific regulatory framework.
These dated sources provide context, not a complete current legal assessment. A real deployment requires checking the latest applicable rules for the actual service, data, participants and jurisdiction. The Chinese sibling explains the same engineering ideas in natural Simplified Chinese; it does not present overseas financial activity as a recommended route for Chinese readers.
Contents · Previous chapter · Next chapter
20. Test your understanding with four small failures
Failure A: the same transfer arrives twice
The application must distinguish a repeated submission from a second authorised action. A retry should not accidentally create two equipment movements. Protocol identifiers and application-level handling must be designed together. The lesson is about recognising the same intent, not merely rejecting every repeated network packet.
Failure B: the signing key is stolen
The signature may verify correctly. The failure lies in control of authority. Identify who can revoke or replace the key, what actions can be paused and how the organisation investigates already accepted events. This separates mathematical validity from operational legitimacy.
Failure C: the sensor reports the wrong crate
The ledger may faithfully preserve an authentic message from the wrong sensor. Improve the physical association and verification process. Adding more ledger replicas does not repair the source measurement.
Failure D: the network stops making progress
A safe workflow needs a visible pending state and an escalation path. It should not invent confirmation to keep the interface looking successful. Decide which activities may continue locally and which must wait. Availability choices belong in the design before an outage occurs.
Contents · Previous chapter · Next chapter
21. Common questions, answered precisely
Is blockchain the same as Bitcoin?
No. Bitcoin is a particular system with a particular purpose and protocol. Blockchain is a broader family of techniques and architectures. Studying Bitcoin is useful, but its choices should not be silently attributed to every other implementation.
Must every blockchain have a tradable cryptocurrency?
No. A permissioned business ledger can be designed without a publicly traded native asset. Some public networks use native assets in fees and security incentives. The answer depends on the network design, not on the word blockchain alone.
Does consensus make the information true?
Consensus can establish agreement about a history under specified rules. It cannot independently establish every real-world fact described by that history. A false delivery acknowledgement remains a false claim even if participants agree that it was submitted.
Does decentralisation remove trust?
It changes where trust is placed. Readers still need to examine software, keys, data sources, operators, upgrade processes and economic or organisational assumptions. A useful explanation names those dependencies rather than hiding them behind a slogan.
Contents · Previous chapter · Next chapter
22. A worked comparison: two reservations for one instrument
Begin with one shared starting state
At the start, M17 is free for Wednesday afternoon. The school submits reservation A for that period, and the laboratory submits reservation B for the same period. Both proposals may have valid signatures. Both may have been prepared when their respective screens showed availability. There is no need to assume dishonesty to create a conflict.
If the system accepts A first, it applies A to the free state and produces a reserved state. When it evaluates B against that new state, the overlap rule prevents B from obtaining the same slot. If the agreed ordering selects B first, the outcome reverses. The important property is a consistent application of the defined rule, not a guarantee that a particular organisation always wins.
Explain fairness separately
The partnership might decide that reservations are allocated through a timetable, a priority policy or a review process rather than simple arrival order. That is a business decision. The software should encode or support the chosen process clearly. A consensus algorithm does not automatically determine the fairest way to share teaching equipment.
Now imagine that A is accepted but the school loses its connection before seeing the response. On reconnection, the interface should retrieve A's outcome. Creating a new request with a different identifier might obscure the original intent. This is why transaction tracking, retry handling and a useful history view matter alongside the underlying ledger.
Identify what the exercise proves
The exercise demonstrates ordering, state transitions and a conflict rule. It does not demonstrate that blockchain is superior to a conventional reservation database: both can implement such constraints. Blockchain becomes relevant only if the multi-party verification and control requirements justify its extra coordination. That final comparison keeps the example intellectually honest.
Contents · Previous chapter · Next chapter
23. A first-principles explanation you can give someone else
Explain the mechanism in your own words
Try this sequence: several parties need a common record; transactions propose changes; signatures support authorisation; validation checks rules; consensus coordinates history; cryptographic links help expose tampering; applications interpret the result. Then name at least one thing the system cannot establish by itself, such as whether a physical delivery actually occurred.
Return to the original need
For the microscope partnership, success means fewer unresolved disagreements, clear custody and an understandable correction process. It does not mean the largest number of technical components. After learning more about any blockchain proposal, return to that practical test: what shared problem does this design solve, under which assumptions, and at what cost?
The next article expands the view from the ledger to the wider system: Internet connectivity, cloud infrastructure, databases, APIs, identities, sensors, artificial intelligence and governance. Keep the microscope example in mind. Following one concrete event through the system makes the relationships easier to understand than memorising a list of technologies.
Continue learning
Where Blockchain Fits in the Wider Technology Stack
Source context checked: 12 October 2026. Platform details and policy requirements can change. The equipment partnership is a fictional teaching example.