How Blockchain Works | A Record’s Journey

Three neighbourhood astronomy clubs share one telescope. It is too expensive for each club to buy its own, and they do not all meet in the same place. They agree that the telescope may be borrowed for one evening at a time. A shared record should tell them which club has it, which booking is next and whether a handover has been acknowledged.

This is a fictional teaching example. It is not a claim that astronomy clubs need blockchain, or that a particular service already works this way. An ordinary booking system may be their best choice. We are choosing a familiar object so that the machinery can become visible.

At six o’clock, Alicia, an authorised representative of the North Club, wants to return the telescope to the Central Club. She presses a button labelled “Record handover”. On the screen, this looks like one action. Behind the screen, several different questions need answers.

What exactly did Alicia request? Was she allowed to request it? Did the receiving club agree? Was another request already changing the same booking? Did the network accept this request? Has the accepted change reached the application that the next club will use?

Blockchain becomes easier to understand when we follow those questions in order. The important journey is from intention to a checked change in a shared record. The button begins that journey; it does not finish it.

Contents · Next chapter

The telescope is a physical object. Its record is information about that object. Those two things can move differently.

Alicia may put the telescope into the Central Club’s storeroom while the computer record still says “North Club”. Equally, a record may say “Central Club” while the telescope remains in Alicia’s car. The mismatch is possible because a computer system does not automatically observe everything outside itself.

We should therefore give the example two separate questions: where is the telescope, and what does the shared record currently say? A useful service needs a way to reconcile them. Perhaps both clubs inspect the equipment and acknowledge receipt. Perhaps a staff member investigates a disputed handover.

A blockchain can help preserve the submitted acknowledgements and apply the agreed recording rules. It cannot replace the inspection merely by keeping more copies of the statement.

This distinction travels far beyond telescopes. A record about a parcel is not the parcel. A record referring to a certificate is not, by itself, proof that its issuer was trustworthy. A token associated with a work of art does not automatically grant every right to that artwork.

Keep the distinction close as we continue. The digital journey can be checked carefully while the physical story still needs evidence. Both parts matter; neither should disappear behind the word “verified”.

Contents · Previous chapter · Next chapter

Before building the system, the clubs need a shared vocabulary. “Returned” might mean left outside a door, received by a person, inspected for damage or made available for the next borrower. Those are different events.

Their agreement defines a completed handover as two authorised acknowledgements referring to the same equipment item and booking. The sending club acknowledges release. The receiving club acknowledges receipt. Inspection findings belong in a separate report.

Notice what this definition does. It makes the computer’s job more precise, but it also limits the meaning of the result. A completed handover record means the required parties acknowledged the handover. It does not mean the telescope is undamaged unless a separate, properly supported condition establishes that.

The clubs also decide how to identify the item. They use a fictional equipment number, TEL-01. A booking has its own identifier. Two similar telescopes should not become one record simply because somebody typed “the telescope”.

A surprising amount of reliable technology begins with this ordinary work: decide what words mean, identify the things being discussed and agree on which evidence is needed.

If the parties disagree about the meaning of an entry, a fast network may only spread the disagreement faster. Computers can enforce a shared rule more consistently once people have made that rule intelligible.

Contents · Previous chapter · Next chapter

Before Alicia’s request, the current record says that TEL-01 is assigned to the North Club for booking B-17. The booking is active. No completed return is recorded yet.

Think of this as the position on a board before the next move. A move is judged against that position. The same instruction can make sense in one position and fail in another.

“Return TEL-01 under B-17” may be allowed while B-17 is active. It may be refused after the booking has already been closed. It may also be refused if the equipment identifier belongs to another booking.

The system needs more than a list of sentences. It needs a way to work out the current situation from accepted changes. In computing, this situation is often called the state.

Our toy state is small enough to put on paper: equipment identifier, assigned club, active booking and handover status. A real application might have many more fields, along with access controls and rules for who can see them.

The practical lesson is simple. To understand a requested change, ask what the record says before the change. A screenshot showing only the requested action leaves out half the story. We need the starting position as well as the proposed next position.

Contents · Previous chapter · Next chapter

Alicia’s intention is “the telescope is going back to Central”. The application must translate that intention into a particular instruction.

In our example, the instruction names the equipment, the booking, the sending club, the receiving club and the kind of acknowledgement being made. It also identifies the network on which the request belongs. An instruction for one network should not be casually treated as an instruction for another.

This translation is an important point of possible error. A person can choose the wrong equipment item from a menu. An application can display one action while preparing a different one. A confusing screen can hide a permission that is broader than the user expects.

A readable confirmation screen should therefore explain the meaningful change. “Acknowledge release of TEL-01, booking B-17, from North to Central” is more useful than a large button saying “Confirm blockchain”.

The request is still only a proposal. Preparing its fields does not make it an accepted part of the shared history.

For a child, the comparison is filling in a library return slip. Writing the slip clearly is necessary, but the slip is not yet the library’s completed return record. Someone still needs to check which book, which loan and which person the slip refers to.

Contents · Previous chapter · Next chapter

The next question is who authorised the instruction. Blockchain applications commonly use digital signatures to help answer it.

A digital signature is produced using a private key and checked using the corresponding public key. For this explanation, picture a special way of approving a particular message that other computers can check. The handwritten-signature analogy is useful for the job of authorisation, but the mechanism is mathematical.

A successful check supports a narrow conclusion: the message has a valid signature for the relevant key. The application still needs a reason to connect that key to Alicia’s role at the North Club.

It also needs permission rules. An authorised North Club representative might acknowledge release, but should not be able to impersonate the Central Club’s receiver. The fact that a message is signed does not make every requested action permissible.

There is another limit. If someone obtains the signing capability without permission, a valid signature can appear on an unwanted instruction. The computer’s check does not automatically recover the person’s true intention.

In our story, key handling is an adult operational responsibility. The classroom exercise later in this article uses paper role cards. No learner needs to generate, share or use real private keys to understand the principle.

The useful question is not merely “is it signed?” It is “which key signed this exact instruction, and what is that key allowed to do?”

Contents · Previous chapter · Next chapter

Alicia approves the prepared request, and the application sends it to a network service. That service may acknowledge that it received the request.

This acknowledgement matters, but its meaning is limited. “Received” is not the same as “accepted into the shared history”. A message can arrive and later fail a permission check, lose a conflict with another instruction or remain waiting.

Think about posting a form to an office. A receipt from the delivery service establishes delivery to that service’s destination. It does not establish that the application on the form has been approved.

The screen should reflect the distinction. “Submitted” can be a useful status. “Completed” would be misleading if the application has not yet learned the result.

An interrupted connection creates a particularly awkward situation. The request may have reached the service even though Alicia never received the acknowledgement. Pressing the button again without checking could create another attempt.

Well-designed applications provide identifiers and ways to retrieve the result. Our toy request receives identifier R-104. Alicia can ask what happened to R-104 rather than guessing from the last screen she saw.

Keep that identifier in the story. It gives us a way to follow the same request through several stages without confusing it with another request that happened to look similar.

Contents · Previous chapter · Next chapter

A receiving computer should not accept every message simply because it arrived. It can check whether the message has the required structure, whether the signature is acceptable and whether the sender has the relevant permission.

For our clubs, an incomplete request missing the booking identifier cannot support a reliable handover. A request naming a nonexistent equipment item also needs a clear response. A request from a person who no longer represents the North Club should not quietly continue.

Some checks depend on the network and application design. There is no single checklist that every blockchain performs in the same order.

The key idea is that a shared record is maintained under rules. It is not a public noticeboard where every submitted sentence automatically becomes an authorised change.

Early refusal can be useful. The application can explain “this account cannot acknowledge release for North Club” while the problem is still close to the user’s original action.

Yet early checks do not settle every later question. A request may be well formed and authorised but still conflict with a change accepted afterwards. Other checks may be needed before the record is finally updated.

A child-friendly explanation is that a referee can check whether a player is allowed to move a piece before deciding whether the move is legal in the current board position. These are related checks, with different jobs.

Contents · Previous chapter · Next chapter

At this point, it is tempting to say that every blockchain sends the instruction to every computer and asks everyone to vote. That picture is too simple.

Different systems divide the work differently. Some restrict participation to approved organisations. Others allow broader participation under their protocol rules. They can use different ways to propose blocks, order requests, execute instructions and settle disagreements about history.

Hyperledger Fabric provides a useful concrete contrast: a proposal can be evaluated and endorsed before it is ordered, with later validation deciding which changes apply. Ethereum uses a different transaction and execution design. These examples should not be collapsed into one universal sequence.

Our telescope story is a permissioned teaching model. We will use endorsement, ordering and later checking because that makes several distinctions visible. This is a model for learning, not a complete implementation specification.

The model’s recurring questions remain useful elsewhere: who may request a change, who checks it, how conflicting instructions are ordered and what evidence tells a reader which result to accept?

When someone explains a real service, ask them to name its actual network and mechanism. “It uses blockchain” is a starting label. It does not yet explain the journey of your request.

For the platform-specific sequence, the Fabric transaction-flow documentation and Ethereum transaction documentation describe their respective systems.

Contents · Previous chapter · Next chapter

In our teaching model, the relevant organisations evaluate the proposed handover acknowledgement. They check the agreed rule against the information they currently have.

Perhaps the rule requires an authorised sender and an active booking. The computer evaluates the instruction and prepares a proposed result: record North’s release acknowledgement for TEL-01 under B-17.

An endorsement supports that evaluated proposal under the model’s rules. It does not yet mean every later participant has accepted and applied it.

Imagine two staff members agreeing that a form is complete before it enters the office’s official processing queue. Their agreement is useful evidence. The queue and final processing steps still exist.

This distinction matters because information can change between evaluation and commitment. Another request might close the booking, replace a representative or record a conflicting handover while our request is travelling.

The system must decide which earlier assumptions remain valid. A proposed result based on an old situation may no longer be safe to apply to the newer situation.

For the beginner, the phrase “provisional result” is enough. Something has been checked at one stage, but the full journey has not finished.

Whenever an interface displays “approved”, ask what that approval covers. A preparation-stage approval, a network-stage acceptance and a business-stage completion can all be real, while meaning different things.

Contents · Previous chapter · Next chapter

Suppose Alicia sends R-104 to acknowledge release to Central. At almost the same time, another North representative sends R-105 to change the booking’s recipient to South.

Each request might look reasonable when examined against the same earlier state. Together, however, they may conflict with the clubs’ agreement. The equipment cannot be handed over under two incompatible versions of the booking.

This is why checking requests one at a time is not the whole problem. Shared systems also need rules for how requests interact.

On paper, put the starting state at the top. Beneath it, write the proposed result of R-104 and the proposed result of R-105. You can now see why blindly accepting both would be confusing.

A real application must define the conflict precisely. Does a release acknowledgement prevent changing the recipient? Does a booking change invalidate an earlier evaluated proposal? Can a new authorised correction supersede the earlier record?

Those questions belong to the application’s rules, not to a vague promise that the chain is “secure”.

The constructive next step is to make the rules explicit. Once the clubs decide which sequences are allowed, the software can check them consistently.

Blockchain does not remove the need to resolve incompatible intentions. It supplies mechanisms within which the resolution rules can be applied and recorded.

Contents · Previous chapter · Next chapter

For our clubs, the network must establish an accepted order for relevant requests. An order gives the application a sequence to work through.

Suppose R-104 comes before R-105. The system first considers the release acknowledgement, then evaluates the later booking change according to its rules. If the order is reversed, a request relying on the old recipient might fail.

The result depends on the rules and the sequence together. A queue is therefore more than a waiting area. It can affect which proposed changes remain valid.

Ordering should not be confused with deciding whether a physical handover really happened. Placing a claim first does not make that claim factually correct. Nor does ordering automatically mean every proposed change will be applied.

This is also where we can stop using the classroom-vote analogy. Agreeing on a sequence under a network protocol is not necessarily a show of hands among everyone who uses the application.

For a learner, use numbered cards. Place R-104 and R-105 in one order, apply your written rules, then reset the starting state and reverse the cards. Record whether the outcome changes.

If the activity produces two different outcomes, ask which sequence the real participants are supposed to accept and how they can check that sequence. You have reached one of the central questions behind shared ledgers without needing a price chart.

Contents · Previous chapter · Next chapter

A block gathers records into a structured unit. In many explanations, the block is compared with a page in a notebook.

That comparison helps with grouping. It does not tell us all the conditions for accepting the page. A page containing forbidden instructions should not become acceptable merely because it has a neat border.

Our teaching model puts the ordered requests into a block. The receiving computers still check the requests according to the design’s validation rules.

The details vary by system. In our Fabric-inspired model, a request can be included in a block but marked invalid, with its proposed changes excluded from the current state update. Other systems handle failures differently.

This gives us an important reading habit. “In a block” and “successfully changed the application state” are not interchangeable claims.

A useful status display should show enough detail to distinguish them. If R-105 was recorded as invalid, the clubs should be able to see that its proposed recipient change did not take effect.

For the child, the comparison is a teacher keeping both accepted and refused requests in an office folder. Being in the folder tells you a request was processed in some way. The result label tells you what happened to it.

Ask what the particular network’s block actually contains before drawing conclusions from the block’s existence.

Contents · Previous chapter · Next chapter

A blockchain’s blocks are connected using cryptographic information. A common ingredient is a hash: a fixed-length result computed from the input data.

For a first explanation, think of a hash as a digital fingerprint. The analogy is about comparing data, not about identifying a human being. It is also not encryption; hashing a public record does not make that record secret.

When a later block refers to information derived from an earlier block, altering the earlier data breaks the expected relationship. A reader can detect that the proposed history no longer matches the links they expect.

But there is a second question. Could someone rewrite the altered block and the following links? The calculations themselves can be recomputed. The network’s acceptance rules and security assumptions are what make an alternative rewritten history difficult or unacceptable under the design.

This is why “a hash makes it impossible to change” is an incomplete explanation. The links help reveal alterations; the broader protocol determines which history participants accept.

Our paper exercise will use simple page codes as labels. These codes are not real cryptographic hashes. They illustrate references between pages without pretending that classroom arithmetic has the security of an actual hash function.

For a more precise introduction to the terminology, see NIST’s Blockchain Technology Overview.

Contents · Previous chapter · Next chapter

The block reaches computers that maintain the shared record. In our model, they examine whether R-104 has the required endorsements and whether the assumptions used to evaluate it still fit the relevant state.

Perhaps the booking has not changed. Then the release acknowledgement may be accepted and applied. Perhaps an earlier request changed a field on which R-104 depended. Then the proposal may fail a later check.

The important point is that earlier approval and later acceptance are different stages. A journey can stop after making progress.

Imagine reserving a seat while a booking service checks availability. Seeing the seat during a search is not the same as holding a completed reservation. The service must settle the relevant conditions before it tells you the booking succeeded.

For our clubs, the later check should produce an understandable result. “Booking changed before your acknowledgement was applied” helps Alicia decide what to inspect next. An unexplained error code leaves her guessing.

A refusal is not automatically evidence of an attack. It can be the correct result of enforcing the agreed rules.

Equally, a system that accepts an instruction does not thereby prove the physical claim inside it. R-104 can be valid under the recording rules while the actual telescope handover is disputed.

Keep both meanings available: valid as a permitted digital change, and accurate as a description of the world.

Contents · Previous chapter · Next chapter

Assume R-104 passes the relevant checks. The accepted record now contains North’s release acknowledgement.

The current state can show that North has acknowledged release while Central’s receipt is still outstanding. When Central submits its valid acknowledgement, the rule can mark the handover complete.

History and state have different reading jobs. History helps answer “which accepted events led here?” Current state helps answer “what does the system currently consider the position?”

You can compare them with a bank statement and a current balance, while remembering that our equipment example is not a banking service. The sequence explains how the position developed. The current position summarises what is available now.

A useful interface may show only the summary. That can make ordinary use simpler, but it can hide important context during a dispute.

If someone asks why TEL-01 is assigned to Central, the answer should lead back through the relevant accepted acknowledgements and booking rules. “The screen says so” is not a satisfying explanation on its own.

This is where a shared history can support accountability. Participants can inspect the route to a recorded result instead of relying only on a mutable summary.

They still need understandable identifiers, access permissions and a way to retrieve the relevant evidence. A history that nobody can interpret is a poor practical guide.

Contents · Previous chapter · Next chapter

The North, Central and South organisations may each maintain a copy of the ledger relevant to their shared arrangement. Copies can improve the ability to compare and recover records.

However, three copies of an unclear document are still unclear. Three copies of a false acknowledgement do not make the acknowledgement true.

The useful combination is records, checking and rules for accepting a shared history. Replication alone is not enough.

Nor should we imagine that every copy is always identical at every instant. Messages take time to travel. A computer may be offline. An application may be reading an older result.

When South checks the next booking, its service might briefly show the earlier assignment. A carefully designed application can expose which point in the ledger its answer reflects or obtain fresher evidence before making a consequential decision.

For a learner, compare three printed copies with a version label. Ask whether they refer to the same stage of the story before comparing their contents.

This ordinary habit is surprisingly powerful. Many apparent contradictions are really comparisons between different times, different networks or different questions.

The goal is not to trust the copy with the brightest interface. The goal is to identify which relevant history the parties are supposed to accept and what checking supports that acceptance.

Contents · Previous chapter · Next chapter

Alicia now wants to know whether she can rely on the recorded result. This is where the idea of finality matters.

Different networks provide different ways of judging how settled a transaction or block is. Some systems give an explicit finality result under their protocol assumptions. Others use evidence that becomes stronger as the accepted history develops.

A universal instruction such as “wait three blocks and it is permanent” would be misleading. The appropriate evidence depends on the network and the action.

Our fictional clubs choose an operational policy: the application must receive the network’s relevant successful commitment result before it reports a completed acknowledgement. That policy still needs the actual network’s guarantees to be specified if anyone builds the service.

The human action should also match the importance of the result. Checking a casual practice record and releasing a valuable piece of equipment may require different procedures.

Finality does not mean the outside world has become incapable of change. Central can later discover damage. A booking can later need correction. The point is which recorded history is settled under the system’s rules, not whether all future business questions have disappeared.

The beginner’s question is “what evidence allows us to treat this result as settled enough for our next step?”

A responsible explanation names that evidence instead of replacing it with the word “instant”.

Contents · Previous chapter · Next chapter

The shared record has changed, yet South’s booking page still displays North as the borrower. Has the blockchain failed?

Possibly, but that is only one explanation. The page could be reading a delayed index, a cached answer or a service that has not caught up. The browser could also be showing information loaded before the latest change.

The complete service includes more than the ledger. It includes the application, the services it asks, any additional databases used for searching and the interface through which people read the answer.

A practical investigation starts with a specific claim. What does the application show? Which record identifier does it refer to? What is the latest accepted result for that identifier? At what point in the history was the application’s answer produced?

Our clubs can compare R-104’s result with the equipment summary. If the accepted record is current but the summary is old, the problem may sit in the reading path.

This is a helpful lesson for children and adults alike: an interface is a window onto a system. The window can be misted, delayed or aimed at the wrong place.

We should neither assume every screen is authoritative nor assume every unexpected display proves the underlying history is wrong.

Follow the answer back to its source and the source back to the relevant record.

Contents · Previous chapter · Next chapter

Alicia receives a confirmation containing R-104’s identifier and a result. What can she reasonably infer?

She needs to know which network the receipt refers to, which instruction it describes and which stage has completed. A receipt for submission should not be presented as a receipt for successful application.

For our clubs, a useful receipt states that North’s release acknowledgement for TEL-01 under B-17 was accepted and applied according to the network’s result. It also shows whether Central’s separate receipt acknowledgement is still needed.

That second sentence prevents a common misunderstanding. Alicia’s completed step is not necessarily the whole handover’s completed status.

A receipt can also help someone investigate later. If the application loses connection after submission, R-104 can be looked up. If the summary appears wrong, the result can be compared with the relevant history.

The receipt’s own authenticity matters too. A picture containing a transaction identifier may be edited. A copied identifier may belong to another network or action. The reader needs a checking route appropriate to the service.

The exercise is to finish this sentence carefully: “This evidence establishes that …”

If the sentence suddenly claims the telescope was undamaged, the recipient was physically present or every future dispute is resolved, we have gone beyond what our digital receipt supports.

Contents · Previous chapter · Next chapter

Suppose a connection problem divides the organisations. North can contact Central but cannot contact South. The exact effect depends on the network’s design and the failures it is built to tolerate.

A system may continue under some conditions and pause under others. A pause can be the consequence of refusing to accept a result without enough required support.

For our example, the clubs should decide what users see when a request cannot yet settle. “Waiting for network confirmation” tells a different story from “handover failed”. One describes an unresolved result; the other claims a concluded failure.

Users also need a plan for the physical equipment. The telescope does not stop existing because a network pauses. An agreed manual procedure may record the handover separately and reconcile it when the service returns.

Such a procedure needs authority and evidence. It should not let any person rewrite the official history casually, nor leave staff unable to act during an outage.

The most useful discussion therefore includes both protocol behaviour and operational recovery. Who monitors the pause? Who tells the clubs what to do? How are temporary records checked later?

A system is easier to trust when its failure behaviour is understandable. Promising that failures cannot occur removes the very questions a serious design should answer.

Contents · Previous chapter · Next chapter

Now imagine that North and Central both acknowledge the wrong equipment number. They meant TEL-01 but selected TEL-02.

The requests might satisfy the written permission and sequence rules. The network may therefore preserve a validly authorised but mistaken record.

This is not a contradiction. The computers checked the conditions they were designed to check. The clubs supplied inaccurate information about the event.

A useful correction process connects a later authorised record to the earlier mistake. It explains what was wrong, which evidence supports the correction and how the application should now interpret the equipment’s status.

The particular mechanism depends on the application. We should not claim every blockchain has a universal “undo” button. Nor should we say that an uneditable old entry prevents every possible correction to the current business state.

For our clubs, the original mistaken acknowledgement remains part of the history. A corrective event, approved under a separate rule, can explain the intended equipment identifier. The resulting state can then be recalculated or updated as specified.

That approach preserves a distinction between changing the present interpretation and silently pretending the mistake never happened.

For more everyday examples, continue to Can You Correct a Mistake on a Blockchain? A reliable record needs a recovery story as well as a writing rule.

Contents · Previous chapter · Next chapter

Alicia eventually leaves the North Club. Another adult becomes its equipment representative.

The club’s authority records must reflect that change. Leaving an old signing capability active can permit requests that no longer match the organisation’s intentions.

Again, blockchain does not solve the whole problem by itself. Someone must decide who holds the role, how a replacement is approved and how the old capability is retired.

A well-designed service also considers earlier records. A signature from Alicia’s authorised period should not automatically become meaningless just because she later leaves. The reader may need evidence about the relevant authority at the time of the request.

These are two different questions: who may act now, and who was authorised when an earlier act happened?

Our clubs keep a dated role history and a process for changing active permissions. If a signing device is lost, they follow the network and application’s agreed recovery procedure.

For the child’s paper exercise, swap the “North representative” role card between players. Then ask whether the former representative should be allowed to submit the next acknowledgement.

The activity exposes a simple principle: authority belongs to a defined arrangement, not permanently to whichever person once pressed the button.

Reliable shared records require care as people, organisations and devices change over time.

Contents · Previous chapter · Next chapter

A tempting design would include everything: Alicia’s home address, telephone number, personal identity details and a long account of the club’s internal discussions.

That would usually make our fictional equipment record harder to manage and more intrusive than necessary.

The clubs should begin with the minimum information needed for the recording job. Their equipment identifier, booking reference and authorised organisational acknowledgements may answer the core question without publishing private personal details.

The visibility of a record depends on the network and service. “Blockchain” does not automatically mean either public access or complete confidentiality.

Even putting a hash on a ledger does not settle every privacy question. The surrounding identifiers, timing and linked information may still reveal something meaningful. A design needs to consider the whole information path.

Sensitive documents can be kept in controlled storage where appropriate, with limited references in the shared record. That choice still requires a plan for access, retention, deletion where applicable and the availability of the referenced evidence.

Our classroom exercise uses invented names, toy identifiers and fictional bookings. It does not record students’ personal information or real equipment ownership.

The broader lesson is to choose data because it serves the task. A record can be more useful when it says less, provided that the right evidence remains available to the right people.

Contents · Previous chapter · Next chapter

We have followed the telescope through a long digital journey. Does that prove the clubs should build a blockchain?

No. It proves that we can ask more informed questions about the choice.

If all three clubs are comfortable letting one trusted organisation operate the booking service, an ordinary database with sensible permissions, backups and an audit trail may be simpler. They should compare that option seriously.

A shared ledger becomes more interesting when participants need a common history while limiting unilateral control by one organisation. Even then, the network’s design must actually address the relevant concern.

Compare the entire service: who operates it, who can change records, who pays, how mistakes are handled, what users can check and how everyone recovers from failure.

The telescope example does not need a tradeable token to teach those questions. It also does not need to turn equipment borrowing into an investment product.

A sensible conclusion might be “use a conventional system”. Another might be “test a permissioned shared ledger because the organisations have a specific coordination problem”. The explanation should show the reason for the choice.

Technology is useful when it fits the job. Understanding blockchain gives us the ability to choose it carefully, and the ability to recognise when a clearer, cheaper arrangement will serve the same people better.

Contents · Previous chapter · Next chapter

Give three players the fictional roles North, Central and South. Give one player the role of recorder and another the role of checker. Use a drawing of a telescope rather than real property.

Write the starting position: TEL-01, booking B-17, assigned to North, handover incomplete. Put the rules beside it. Only the current North representative can acknowledge release. Only the current Central representative can acknowledge receipt. Both acknowledgements must name the same booking and equipment.

North prepares R-104. The checker examines its fields and role card. The recorder places the accepted request in an agreed sequence and updates the toy state. Central prepares R-106 to acknowledge receipt. Repeat the checks. Mark the handover complete only when the written conditions are satisfied.

Now reset the starting position. Try a request with the wrong equipment identifier. Try two incompatible booking changes. Let one player’s copy fall behind. Replace the North representative. Introduce a mistaken acknowledgement and write a later correction.

After each round, compare the request, the accepted history and the current state. Ask which facts the paper process never observed.

This is a role-play, not a secure blockchain. Role cards are not digital signatures. Page labels are not cryptographic hashes. The value is seeing where each question belongs.

If learners can explain why “submitted”, “accepted” and “physically true” differ, the exercise has done its most useful work.

Contents · Previous chapter · Next chapter

Imagine someone now says, “Our equipment service is on blockchain, so all handovers are trustworthy.”

You can respond with a calmer and more precise set of questions. Which network? Who may submit a handover? Who checks the acknowledgement? Which order is accepted? What result establishes that the change applied? Who verifies the physical equipment? How are mistakes corrected?

You can also ask how the screen obtains its answer and whether the organisations have an agreed recovery procedure. These questions do not demand that every beginner become a programmer. They demand an explanation of the parts on which the user is relying.

For a child, the complete story is this: someone asks to change a shared record; the system checks permission and rules; the network establishes an accepted history; the record changes when the request succeeds; people still need evidence about the real event.

For an adult, add the important distinctions: intention and instruction; signature and authority; evaluation and commitment; inclusion and successful effect; history and state; recorded claim and external truth.

Return to the Simplest Explanation for the whole beginner map. Continue to the structured technical learning guide when you want to examine the mechanisms more closely.

The journey has taken us from one button to a shared history. Each step adds a particular kind of evidence. Understanding the subject means knowing what that evidence establishes, and what still needs checking.

Contents · Previous chapter · Continue reading