How Blockchain Works | Nodes and Shared Copies

Our fictional astronomy clubs share an equipment record. A printed agreement explains the permissions, but someone must carry out the digital work.

Computers receive requests, communicate with other computers, check data and maintain information used by the service. A participating instance of the relevant network software is commonly called a node.

A node is not necessarily the phone displaying a booking screen. The phone may ask a remote service for an answer without doing the network’s checks itself.

Nor does “node” tell us every role the computer performs. Designs differ, and one machine can run several software components.

Begin with the work. What messages does this participant receive? Which rules does it check? What does it keep? Which decisions can it influence?

That approach makes a large network easier to understand than a picture containing hundreds of identical glowing dots.

The clubs are a teaching model. They help us follow roles without pretending that every real network uses their exact arrangement.

Contents · Next chapter

A client is software that implements specified functions of a system. A node runs the software needed to participate in the network.

People sometimes use the terms loosely. For learning, it helps to separate the program from the running participant.

An organisation can run an appropriate client on its computer. The resulting participant receives and processes the relevant network information.

Different client implementations can follow the same protocol. That does not make their internal code identical. It means they are intended to agree on the relevant rules.

A real system can also divide functions across components. Ethereum, for example, distinguishes execution and consensus clients in its node architecture. That platform-specific division is not a universal template for all chains.

For the clubs, label computers by their jobs rather than assuming one program does everything.

The terminology becomes useful when it lets us ask where a particular check happens.

When reading a service description, ask whether “client” means a network implementation or an ordinary user-facing application. The context determines the answer.

Contents · Previous chapter · Next chapter

Alicia opens the booking page on her phone. It shows that Central has the telescope.

Her phone might be displaying an answer supplied by a remote service. It may not have independently validated the ledger history supporting that answer.

This is not automatically bad design. Many applications rely on remote services. The important point is knowing where the checking responsibility sits.

A friendly interface and an independently verified answer are different properties.

Our equipment service should identify the relevant network and show enough context for significant decisions. If a handover is disputed, the clubs need a route beyond the last screenshot.

Imagine asking a library assistant which borrower has a book. The answer may be correct, but you are relying on the assistant’s source and procedure.

The digital version has similar dependencies: application, server, network connection and the source the server uses.

A beginner does not need to run a node to understand this.

They need to distinguish looking at an answer from performing the checks behind it.

Contents · Previous chapter · Next chapter

Suppose South Club saves every file North sends. South now has many copies of the equipment record.

Did South check whether the entries were authorised? Did it check the accepted sequence? Did it reject invalid changes?

If not, its storage is useful for some purposes but does not provide independent validation.

A node’s value depends on what it actually checks under the protocol. A backup server and a validating participant can both hold information while performing different jobs.

For the classroom, give one player a stack of copied pages and another the rulebook plus the pages. Ask each to identify an unauthorised booking change.

The first player may faithfully preserve the bad entry. The second can detect a violation if the necessary evidence and rules are available.

The lesson is about the work, not the number of copies.

A network diagram should therefore distinguish storing, checking, proposing and presenting answers.

Otherwise, a reader may mistake a crowd of replicas for a crowd of independent verifiers.

Contents · Previous chapter · Next chapter

North accepts a new acknowledgement and sends the relevant information onward. Central receives it quickly. South’s connection is slower.

For a short period, their local views may refer to different stages of the history.

That difference does not automatically prove misconduct or a broken protocol. Network communication is not instantaneous.

The system needs specified behaviour for receiving messages in different orders, detecting missing information and catching up.

Our beginner should ask which point in the history each answer refers to before comparing the answers.

On paper, give North pages 1 through 5 and South pages 1 through 4. Their current summaries can differ because one copy is older.

Now provide page 5 and apply the agreed rules. Compare again.

The exercise explains why freshness and consistency are related but distinct.

A service should not casually describe an old answer as current merely because the connection succeeded.

Understanding the journey of messages helps readers investigate an unexpected display more calmly and precisely.

Contents · Previous chapter · Next chapter

Network participants can communicate with peers to exchange relevant data. Peer-to-peer does not mean every participant maintains a direct connection to every other participant.

Real systems use particular discovery and communication arrangements. Connections can appear, disappear or fail.

A participant may hear about information through more than one path. That can help distribution, but the received data still needs the relevant checks.

If North sends an invalid record through Central, the extra hop does not turn it into a valid one.

Our clubs’ diagram can therefore show both message paths and checking responsibilities. An arrow describes communication, not automatic endorsement.

For a child, imagine a message being passed through several classmates. The last person should not accept its authority merely because three people passed it along.

The computer version is more structured, but the basic reading habit travels well.

Ask who originally supplied the claim, what evidence accompanies it and what the receiving participant checks.

Communication spreads information. Validation determines whether particular information meets the rules.

Contents · Previous chapter · Next chapter

Some participants maintain and validate substantial network data. Lighter arrangements may obtain more limited evidence and rely on particular proofs or trusted starting information.

The exact meaning of “full node” and “light client” depends on the system. Neither term should be used as a universal promise.

The helpful question is what the participant checks for itself and what it receives from others.

A lighter service may be appropriate for a device with limited resources. Its security explanation should identify the evidence and assumptions supporting its answers.

A full participant also has operational dependencies: working software, adequate resources, relevant network information and an acceptable starting point.

For our clubs, compare a checker holding the complete toy history with a reader receiving a signed summary. Their available evidence differs.

Do not conclude that every summary is useless. Ask whether it is sufficient for the actual task and which authority it depends on.

The Ethereum nodes and clients documentation provides one platform’s terminology and roles.

Consult the actual protocol before generalising its categories.

Contents · Previous chapter · Next chapter

Alicia reads the equipment schedule. That does not necessarily make her a participant with authority to propose or approve network history.

Some networks define particular validator roles. Other participants may check the resulting history without performing that same role.

The distinction prevents a common error: imagining that every user casts an equal vote each time a request arrives.

Our fictional permissioned network appoints designated organisations for particular duties. Its readers and authorised equipment representatives perform different jobs.

A real permissionless network has its own rules governing participation and influence. Simply creating another username does not explain those rules.

For learners, give separate paper cards to reader, checker and proposer. Let a reader discover a mistake without granting them unilateral power to rewrite the record.

Checking and deciding can be related without being identical.

The key question is which role can do what, under which protocol conditions.

A count of users, computers or accounts does not answer that question unless the system’s authority structure is also explained.

Contents · Previous chapter · Next chapter

South’s application says “latest result”. Latest according to whom?

A computer may be working normally while its view remains behind other relevant participants. An index used for searching may lag even when the underlying node has newer records.

A useful answer includes context: network, relevant block or record position, and the question being answered.

Our clubs can compare “TEL-01 assigned to North at position 41” with “TEL-01 assigned to Central at position 43”. The different positions immediately explain something important.

The two answers should not be compared as though both describe the same point.

This habit also helps with multiple services. One may answer from an earlier snapshot; another may interpret a different field.

Before accusing either of lying, align the network, data identifier and history position.

A beginner can learn this with two dated sheets.

The practical lesson is that an answer’s provenance includes where it came from and which state it reflects.

A polished interface should make those details easier to obtain when they matter.

Contents · Previous chapter · Next chapter

South’s computer is turned off for a week. When it returns, it has an old view of the equipment history.

It needs to obtain and check the relevant newer information under the network’s synchronisation rules.

This is not the same as permitting South to declare its old copy current. Nor should a service blindly adopt whichever file an unfamiliar peer supplies.

The starting point and validation procedure matter.

Our paper model lets South keep pages 1 through 4 while North advances to page 8. South asks for the missing sequence, checks its links and permissions under the toy rules and updates its summary.

Actual networks can use different synchronisation methods. The example teaches the questions rather than prescribing an implementation.

What information is missing? Which starting state is accepted? What is independently checked? When is the participant ready to answer current questions?

These questions also explain why availability requires ongoing operation.

A node is not a permanent guarantee purchased once. It is a running participant that needs maintenance and a reliable recovery path.

Contents · Previous chapter · Next chapter

A network advertises a thousand nodes. Does that establish a thousand independent organisations?

One operator might control many machines. Several services might rely on the same infrastructure provider. Multiple interfaces might ask the same underlying source.

The machine count is useful information, but it does not settle independence.

For the equipment clubs, three computers owned and administered by North create a different arrangement from one independently administered computer at each club.

Even that comparison leaves questions. Do they use the same credentials, hosting provider or operational team? Can one organisation remove everyone else’s access?

Our learner should distinguish replicas, operators and decision rights.

This makes decentralisation easier to discuss concretely. Ask which relevant power is spread across which independent parties.

There is no need to dismiss every shared dependency. The goal is to identify it and understand its implications.

A large number in a diagram cannot replace that explanation.

The best next question is what failure or unilateral action the distribution is supposed to make harder.

Contents · Previous chapter · Next chapter

Several independently developed clients may implement the same network rules. This can reduce reliance on a single software implementation.

However, differences between implementations can also create compatibility and operational challenges. Diversity is a design consideration, not a magic shield.

The participants need to understand which versions are supported and how rule changes are adopted.

For our clubs, imagine two teams implementing the equipment booking rule. Both should reject an acknowledgement for an inactive booking. If one accepts it, they disagree about the permitted state transition.

The response is to investigate the specification and implementations, not to count which team has more attractive screens.

A classroom can use two rule interpreters and the same action cards. Deliberately introduce an ambiguous rule and compare their outcomes.

The exercise shows why protocol definitions, testing and upgrade coordination matter.

Different software can be valuable when it faithfully implements the relevant shared rules.

The word “different” alone does not establish independence, correctness or useful resilience.

Contents · Previous chapter · Next chapter

Alicia’s app uses one provider to submit requests and retrieve results. That provider may operate well, but it is still part of the service’s dependency path.

If it becomes unavailable, the app can fail even while the underlying network continues.

If it supplies stale information, users may see a misleading summary.

The clubs should therefore understand where requests travel and where answers originate. For important actions, they may define checking and fallback arrangements appropriate to their requirements.

The aim is not to make every user operate infrastructure. It is to give operators and users a truthful description of the complete system.

For the learner, draw a path from screen to service to network participant. Place a failure marker on the service while leaving the network intact.

Ask what the user would experience.

This demonstrates why “the blockchain is running” does not prove “the application is working”.

A complete explanation connects the visible service to the computers and providers supporting it.

Contents · Previous chapter · Next chapter

The equipment clubs want common handover information. They may not want every participant to receive private contact details or internal inspection discussions.

Data distribution must match the actual privacy and access requirements.

Different networks and applications provide different arrangements. A node does not automatically hold every possible document, and a blockchain does not automatically make every field confidential.

Copies also affect recovery and information management. Once data is distributed, the organisations need to understand which copies exist and who controls them.

For our fictional model, the shared record uses invented equipment and booking identifiers. Sensitive operational documents, if needed, belong in a separately specified access arrangement.

The classroom uses no real personal information.

Ask what each participant needs to receive to perform its job. Then ask whether the design sends more than necessary.

These questions improve both intelligibility and practical restraint.

A useful shared history is not a reason to place every piece of an organisation’s information into the same distribution mechanism.

Contents · Previous chapter · Next chapter

Give three learners copies of a fictional equipment log. A fourth learner holds the agreed rules and distributes new action cards.

Let North receive two updates, Central receive one and South receive none. Ask each to report the current borrower and the position of its copy.

The answers can differ without deliberate deception. Compare positions before discussing disagreement.

Now distribute an invalid card. Each checker should reject it under the rules, regardless of how many other players forwarded it.

Finally, disconnect one learner for several rounds. Reconnect them and practise obtaining and checking the missing information.

The paper pages are not a blockchain, and the hand-delivery method is not a real synchronisation protocol. The activity makes roles, delays and checking visible.

Ask each learner to describe whether they stored information, validated it or merely repeated someone else’s answer.

When they can explain those distinctions, “node” becomes a useful word rather than an impressive label.

The complete question is what work each participant performed to support its reported result.

Contents · Previous chapter · Next chapter

When a blockchain application displays a result, ask where that answer came from, which history position it describes and which checks support it.

Then ask who operates the relevant participants and what happens when one service is unavailable or behind.

A child-friendly explanation is that nodes are computers running the network’s relevant software. They exchange information and perform particular jobs. The phone showing an answer may depend on those jobs being done elsewhere.

An adult explanation adds the role boundaries: storing, validating, proposing, synchronising and serving queries.

Consensus and Agreement continues the story by asking how participants establish an accepted history when messages, proposed records and local views differ.

Return to A Record’s Journey for the whole path from request to result.

Nodes matter because they carry out the work. A collection of copies is useful only when the checking, authority and recovery arrangement makes sense.

The strongest question is concrete: what did this participant actually verify before giving me this answer?

Contents · Previous chapter · Continue to worked situations