How Blockchain Works | Smart Contracts and Rules

The fictional astronomy clubs share a telescope. Their agreement says a handover is complete when the authorised sender acknowledges release and the authorised receiver acknowledges receipt for the same equipment and booking.

That is a rule we can read before writing any program.

A smart contract can implement defined logic in a blockchain environment. Its work depends on the inputs, state and execution rules of the particular system.

The term “smart” does not mean the program understands the telescope, the people or the purpose of astronomy.

The term “contract” also does not automatically establish that every program is a complete legal agreement.

Our story is a teaching model. We will describe conditions and outcomes in ordinary language, then use paper cards to practise.

Start with the decision: when should the recorded handover status change?

A clear answer gives us something to test. An impressive technical label without a readable rule does not.

Contents · Next chapter

“Complete the handover when everything is fine” sounds reassuring. It is too vague for our toy program.

Which information represents “fine”? Who supplies it? Which conditions count as sufficient?

The clubs replace the phrase with explicit requirements: the booking is active; the equipment identifier matches; the sender is authorised; the receiver is authorised; both acknowledgements refer to the same booking.

These conditions make the digital check more precise.

They also make its limits visible. None independently establishes that the lens is undamaged. That would need a separately specified inspection claim and evidence procedure.

A useful programme begins by describing what it will check and what it will leave to another process.

For a child, compare “be fair” with a board-game rule saying when a particular move is allowed.

The wider human purpose still matters, but the executable rule needs an unambiguous test.

If the clubs cannot agree what a condition means, software can reproduce their ambiguity rather than resolve it.

Contents · Previous chapter · Next chapter

The record currently says TEL-01 belongs to active booking B-17, with release not yet acknowledged and receipt not yet acknowledged.

This is our toy starting state.

A proposed instruction is checked against that position. The same instruction can be allowed in one state and refused in another.

Acknowledging release may be permitted before the booking closes. It may be refused after a completed handover under that booking.

Imagine a board game. “Move this piece” cannot be judged without knowing the current arrangement and whose turn it is.

A smart contract’s rules similarly operate on defined information and inputs under the particular environment.

The analogy should not suggest the program knows every relevant fact outside the record. The telescope may be in a car while the state still describes a pending handover.

Keep the recorded position and the physical position distinct.

The programme can apply rules consistently to the former while the service still needs evidence about the latter.

Contents · Previous chapter · Next chapter

Alicia submits “acknowledge release of TEL-01 under B-17”. The programme does not receive her entire intention or life story.

It receives the structured input the application prepared.

If the action is allowed, the relevant recorded state can change from release pending to release acknowledged.

This movement from one specified position to another is a state transition.

The complete handover remains incomplete until the receiver’s required acknowledgement also arrives and satisfies the rule.

That distinction prevents an interface from describing Alicia’s completed step as the entire business task’s completion.

For learners, draw two boxes on paper: before and after. List the fields that change and those that do not.

Then ask which condition authorises each change.

A good rule has a visible relationship between the instruction, the starting state and the permitted result.

“Something happened on blockchain” leaves out that relationship.

The transition model makes the machinery much easier to understand and test.

Contents · Previous chapter · Next chapter

The same acknowledgement text can be submitted by an authorised sender or an unrelated reader.

Our toy rule should accept the former when other conditions fit and refuse the latter.

Recognising the caller and checking permissions are therefore part of programme behaviour, not decorative information beside it.

A signature or account mechanism can support caller identification under the system’s design. The programme still needs to determine which powers that caller has.

A reader may view the telescope schedule without being able to change its borrower. A sender may acknowledge release without impersonating the receiver.

These boundaries should be written clearly.

For the classroom, give one action card to several players with different role cards. The action’s text is identical; the permission result differs.

That is not unfairness. It is the agreed authority arrangement.

A programme that ignores the caller can permit changes the humans never intended to authorise.

Ask who can invoke each important operation before assuming that automation makes the service reliable.

Contents · Previous chapter · Next chapter

The programme sees a receipt acknowledgement. It does not, by itself, see the telescope enter the storeroom.

A person or another service must provide information about the outside event.

That creates an evidence boundary.

The programme can check whether a report arrived from an accepted source and whether it fits the required format. Those checks do not guarantee that the source observed the event correctly.

Perhaps Tricia selected the wrong equipment item. Perhaps an inspection device reported faulty data. Perhaps two people approved a report without inspecting anything.

The digital process can preserve and apply those inputs consistently while the underlying claim remains wrong.

Our learner should distinguish checking a report’s authority from checking the reported fact.

Some applications use external-data mechanisms often called oracles. Their trust, timing and failure behaviour need separate explanation.

A smart contract is useful when the evidence path is designed responsibly.

It is not a way to avoid asking who supplied the facts and how those facts were established.

Contents · Previous chapter · Next chapter

People sometimes say a smart contract “runs itself”. The phrase hides useful questions.

An operation may need a submitted transaction or another mechanism that invokes execution. The relevant network must process the operation, and conditions must permit the result.

A rule sitting in programme code is not necessarily an action that occurs at the moment a real-world event happens.

For the telescope clubs, the handover status does not change merely because the equipment physically moves. The required acknowledgements need to enter the system.

If an application waits for an event, someone must explain how that event is observed and how the operation is triggered.

Different environments provide different scheduling and invocation arrangements.

The beginner’s rule is to follow the full path: event, report, request, execution and result.

Leaving out a step can make an apparently automatic service depend on an unmentioned operator.

Automation becomes intelligible when the trigger and the supporting infrastructure are named.

That is a stronger explanation than describing the code as permanently awake and aware.

Contents · Previous chapter · Next chapter

Kai Kai tries to acknowledge Central’s receipt. His role permits South’s actions, not Central’s.

The programme refuses.

That result may frustrate the user, but it is exactly what the permission rule requires.

Other refusals can occur because an identifier is wrong, a booking is already closed or a required acknowledgement is missing.

A useful application explains the relevant condition in ordinary language. “Central’s authorised receiver must acknowledge receipt” is more helpful than a mysterious error.

Real execution environments distinguish several kinds of failure and transaction outcomes. The details vary, so a generic guide should not promise that every failure has the same fee or ledger treatment.

For our paper model, simply record whether the proposed transition occurred and why.

Then compare a correctly refused action with a wrongly accepted action.

Reliability includes refusing changes that violate the rule.

Successful automation is not measured only by how often the screen says Completed. It is measured by whether the permitted result follows from the specified conditions.

Contents · Previous chapter · Next chapter

Alicia’s release acknowledgement and an authorised booking cancellation arrive near the same time.

If cancellation takes effect first, the release request may no longer satisfy the active-booking condition. If the acknowledgement takes effect first, different subsequent rules may apply.

The programme’s outcome therefore depends on both its logic and the accepted sequence of relevant operations.

Consensus and Agreement explains how a network establishes the history it uses. The contract logic determines what permitted transitions follow within that history.

Neither part should be ignored.

For learners, reset the toy starting state twice. Process the same two cards in opposite orders. Write the resulting states.

If they differ, identify the condition responsible.

This does not automatically mean the programme is broken. The difference may be intended. It does mean the designers must understand the consequence.

A service should not claim that each instruction’s result is independent of all other activity unless its actual rules support that claim.

Shared-state programming requires reasoning about interactions.

Contents · Previous chapter · Next chapter

The clubs intend to require both release and receipt acknowledgements. The programme accidentally checks only release.

It can execute consistently and still violate the intended agreement.

This is why correctness has more than one layer. Does the code implement its written logic? Does that logic implement the intended rule? Does the intended rule serve the real workflow?

A passing demonstration of one happy case does not answer every question.

Testing should include cases that must be refused: wrong caller, wrong equipment, missing receiver, closed booking and conflicting changes.

Our classroom can deliberately use a faulty rule card. Let the players carry it out accurately, then compare the result with the clubs’ actual agreement.

They will see that faithful execution does not cure a bad instruction.

The response is to identify the mismatch and correct the appropriate layer under the service’s change process.

Calling a programme “smart” is no substitute for checking its conditions, exceptions and consequences.

Contents · Previous chapter · Next chapter

Someone says the programme was audited. What exactly was examined?

The answer might concern one code version, particular tests or a specific set of properties. It does not automatically cover every later deployment, interface, operator or external-data source.

Our telescope service needs to connect the reviewed programme with the programme actually in use.

It should also identify known limits and relevant changes since the review.

The beginner does not need to interpret every line of an audit report. They can understand that a check applies to a particular object and scope.

Imagine an inspector approving one telescope and someone applying that approval to every future telescope purchase. The inference would be too broad.

The same principle applies to code evidence.

Ask which version, which environment, which assumptions and which unresolved issues the review describes.

Audits can be valuable. Their value increases when the reader knows what they examined.

A label saying “audited” should lead to a precise explanation rather than a universal guarantee of safety.

Contents · Previous chapter · Next chapter

The clubs later change the handover rule. Can the deployed programme be altered? Who has that power?

Different designs answer differently. Some arrangements support changes through specified upgrade mechanisms. Others require a new deployment or migration.

A reader should not infer that all programme behaviour is forever fixed merely because it is associated with blockchain.

If an administrator can change important logic, that authority belongs in the service’s trust explanation.

The change procedure should address permission, testing, communication and the interpretation of earlier records.

For our toy model, issue a revised rule card through an agreed approval process. Ask which actions use the old rule and which use the new one.

The activity exposes transition questions that a slogan about immutability can conceal.

A programme’s useful guarantees depend on its actual change and control arrangements.

Ask who can alter what and what evidence makes the change visible.

Governance is part of understanding automated rules, not a topic that disappears once the first version has been deployed.

Contents · Previous chapter · Next chapter

A faulty external report marks the telescope damaged, blocking all bookings. The club investigates and discovers the report was mistaken.

What can the service do?

Perhaps its design permits an authorised correction. Perhaps it has a pause function. Perhaps changing the recorded interpretation requires a specified governance process.

These capabilities vary. There is no universal smart-contract recovery button.

The clubs should define the relevant powers before the incident: who may intervene, under which evidence, with which limits and with what record of the intervention.

An unrestricted override can weaken important guarantees. No recovery path can leave people stuck with a preventable mistake.

The useful design question is which recovery fits the requirements.

For learners, introduce a mistaken report into the paper state and ask them to resolve it using only the written powers.

If no power exists, note the gap rather than secretly changing the rules mid-round.

The exercise makes recoverability concrete.

A dependable system explains both ordinary execution and exceptional intervention.

Contents · Previous chapter · Next chapter

The club’s programme records a completed handover. Does that settle every possible legal dispute about the equipment?

Not automatically.

Legal rights and responsibilities depend on applicable arrangements and law. Code behaviour is a technical fact within a defined system. The relationship between the two requires an explicit legal and operational design.

This article does not determine that relationship for a real service. It uses a fictional workflow to separate the questions.

A programme may assign a digital status while people still dispute damage, ownership, responsibility or whether an authorisation was legitimate.

The next step may require evidence review or a dispute process outside the programme.

For a child, explain that a computer rule does not replace every human agreement.

For an adult, ask which real obligations the recorded event is intended to affect and who is responsible for resolving disagreement.

Clear terminology helps: programmed transition, business completion and legal consequence are related concepts with different tests.

Do not allow the word “contract” to merge them silently.

Contents · Previous chapter · Next chapter

Write a fictional starting state for TEL-01 under B-17. Give learners separate sender, receiver and reader roles.

Write the conditions for completing the handover. Process release and receipt cards one at a time, checking the caller, identifiers and booking status before updating the state.

Run a valid case, then several invalid cases. Use the wrong receiver, omit an acknowledgement, close the booking first and submit conflicting instructions.

Next, introduce the faulty rule requiring only release. Compare its result with the intended agreement.

Finally, add a false inspection claim and ask which facts the programme never observed.

This is a state-transition exercise, not a deployed smart contract. No real assets, accounts or personal data are involved.

The learner should explain the starting state, requested action, applicable condition and resulting state for each round.

That explanation is the core achievement.

Writing code can come later, after the rule and its failure cases are understood.

Contents · Previous chapter · Next chapter

A child-friendly explanation is that a smart contract applies computer rules to information it receives and records it can access.

An adult explanation adds the caller, permissions, current state, input boundaries, execution conditions and control over changes.

Neither explanation needs to pretend the programme knows every outside event or decides every dispute.

The Ethereum smart-contract introduction describes its platform’s programme model. Other blockchain environments require their own technical descriptions.

Return to A Record’s Journey to connect execution with submission, validation and the final result. Use Keys and Digital Signatures for authority, Nodes and Shared Copies for the running participants, and Consensus and Agreement for accepted history.

The complete service succeeds when these pieces fit its real requirements.

A useful closing question is simple: which rule produced this result, using which inputs and authority, and what remains outside that rule?

Once a reader can answer that, the phrase “smart contract” becomes a clearer description of machinery rather than a promise of automatic wisdom.

Contents · Previous chapter · Continue to worked situations