How Blockchain Works | Who Runs a Blockchain?

Who runs a blockchain? People and organisations do. Computers store and check the data, but people write the software, operate the machines, protect the keys, create applications, pay the bills and decide which changes they are prepared to accept. A public blockchain may be maintained by many independent participants. A permissioned blockchain may be run by a defined group of organisations. There is no single answer that fits every network.

That is why saying “the blockchain did it” often leaves out the most important part of the story. Who submitted the information? Who checked the rules? Who was allowed to put the next block forward? Who maintains the website? And who can change the system? Those are different jobs, sometimes performed by the same organisation and sometimes deliberately separated.

We will answer them through a fictional community story prize. Four libraries cooperate to celebrate children’s writing. They receive entries, verify submissions, record awards and issue certificates. When a parent asks, “Who runs the record?”, the answer turns out to involve more than the computer displaying the prize results.

For the complete technical curriculum, use the Master Blockchain English learning guide or the Simplified Chinese learning guide. This article is a practical map of people and responsibilities. It does not recreate the detailed network architecture in How Blockchain Works | The Complete System.

The answer in 30 seconds

Think of a blockchain as a shared record maintained under specific rules. The computers that store, check or help update this record are called nodes. A node runs software, but the node has an operator: a person or organisation responsible for keeping that machine running.

In some public systems, particular participants can propose new blocks. Bitcoin uses miners competing through proof of work. Ethereum uses proof-of-stake validators. Other blockchain systems arrange this work differently.

Software developers write and maintain the programs. Users submit transactions. Applications and service providers help people read and interact with the records. A governance process determines how rules might change. In a permissioned network, named organisations can control membership and specified roles.

A blockchain is therefore not one magical computer and not necessarily one company. It is a technical system operated within a human arrangement. The precise distribution of responsibilities must be checked for the particular network.

Meet the four libraries and their writing prize

Alicia enters a story about the sea. Tricia enters a story about a city after dark. Kai Kai joins the organisers as a volunteer. Four libraries are helping to run the competition.

Alicia submits her document through a website. A librarian checks that the entry arrived before the deadline. Two judges read the work. An administrator records the result and issues a certificate.

Imagine the libraries have agreed to share an independently checkable record of accepted submissions and awards. They might manage that with an ordinary shared database and signed receipts. That is often the sensible solution.

But suppose they specifically want multiple institutions to maintain and verify one accepted history under agreed rules, without giving a single participating library unchecked power to rewrite it. They could evaluate a permissioned blockchain.

Now ask a simple question: Who is running the system?

The answer is not “the website”. The website is only one doorway. It is not “the judges”, because deciding the literary award is different from checking the record. It is not “the computers”, because someone owns or operates them and decides what actions those machines are authorised to perform.

We need a cast of participants before we can understand the machinery.

The cast: who does what?

Participant	Main job in our learning map	What the job does not automatically prove
User or applicant	Submits a request or record	That the submitted facts are true
Authorised officer	Confirms a particular permission or decision	That every later system action is correct
Application developer	Builds the form, logic and display	That the developer controls the entire network
Node operator	Runs software that receives, checks or stores network information	That their node produces blocks or controls every rule
Block producer or proposer	Puts forward blocks under the network’s mechanism	That an invalid block will be accepted by independent verifiers
Other verifying participants	Check results against the applicable rules	That the real-world story behind a report is accurate
Software maintainers	Improve client software and address defects	That every operator must install every change
Governing participants	Decide policies, membership or acceptable upgrades according to the design	That they can change facts in the physical world
Website or API provider	Makes information convenient to reach and read	That the provider’s display is the network’s only possible truth

This is a conceptual role map. One person may perform several jobs, and some networks do not have each role in the form described. The purpose is to notice what authority comes from where, not invent one universal blockchain organisation chart.

1. Users make requests; they do not necessarily maintain the network

Alicia submits her competition entry. She clicks a button, uploads a file and receives a confirmation message.

She is using the application. She is not necessarily operating a blockchain node, checking the network’s full history or producing a new block.

In many systems a user relies on an application provider to help construct and submit transactions. In others, users may run their own verifying software. The choice changes which information they independently check and which services they trust.

A child who opens a website is not automatically a network validator. Nor does using a cryptocurrency wallet mean the person runs the ledger.

For the competition, distinguish three actions: Alicia sent a submission; the organisers accepted a submission; and the judges later awarded a result. One event should not be mistaken for the others.

A good interface explains which step actually happened. The same discipline is useful in online school registration, ticketing and financial services.

2. Real-world officers decide what they are authorised to confirm

A librarian may verify that Alicia submitted her entry before a deadline. A judge may give the story a particular score. An administrator may approve the publication of the final result.

Those are human or institutional decisions.

Even if the record is secured by cryptographic methods, the ledger does not read Alicia’s story and independently decide whether it deserves first prize. It can record that the authorised judge submitted a result under the agreed rules.

What if a judge makes a mistake? What if the school entered the wrong author’s name? The organisers still need an appeal, correction or review procedure.

That is why checking who approved a statement is different from checking whether the statement is justified.

A responsible design specifies the meaning of each approved action, the evidence the officer should examine and the consequences of a mistaken entry. A perfectly working blockchain does not substitute for fair judging or careful administration.

3. Node operators provide the computers that check the system

A node is a computer running relevant blockchain software and participating in the network. Depending on the design, it can receive and relay messages, verify transactions and blocks, keep state or serve requests from applications.

Someone has to install the software, configure it, keep it running, apply updates and investigate failures. That person or organisation is the node operator.

For a public network, node operators may be individuals, businesses, institutions or groups using their own hardware or hosting services. For a permissioned consortium, participating organisations may operate nodes under a common agreement.

Not every node performs every role. Some nodes maintain comprehensive information and independently verify protocol rules; others work with more limited data or rely on a service.

The US National Institute of Standards and Technology describes a blockchain network as participants maintaining ledger copies according to validation and consensus rules in its blockchain overview.

Here is the child-friendly version: the computer is doing the checking, but someone still maintains the computer. The machine performs the job; a person or organisation remains responsible for operating it.

4. A full node is not automatically a miner or validator

This is one of the most important distinctions in the entire chapter.

A verifying full node can check relevant blockchain information against the network’s rules. A miner or validator may take part in proposing new blocks or otherwise participating in the network’s consensus mechanism.

The jobs can overlap, but they are not identical.

Bitcoin’s full-node explanation describes software that fully validates transactions and blocks and commonly relays valid information to other nodes. The separate Bitcoin mining guide describes the process of producing candidate blocks through proof of work.

Ethereum’s node and client documentation explains how an operator can run a verifying node without operating a staking validator.

Imagine a library that checks the published competition record but never gets to propose the next page. It still performs useful verification. Conversely, the participant proposing an update does not automatically decide whether every independent verifier must accept it.

Checking the rules and proposing the next block are different powers. A learner who understands that has moved beyond the misleading phrase “everyone votes on every transaction”.

5. Bitcoin: miners propose blocks, full nodes check the rules

Bitcoin provides a useful example because the division of jobs is visible.

A miner assembles or participates in assembling a candidate block and performs the proof-of-work process. When a valid block is found, it can be broadcast to the network.

That does not give the miner an unlimited ability to invent protocol rules. Independently verifying full nodes check whether the proposed block satisfies the applicable consensus rules. A block that fails the validation requirements does not become valid merely because a miner announces it.

The official Bitcoin blockchain developer guide describes how full nodes validate blocks and follow the chain they consider valid under their rules. The mining documentation explains block production.

Mining pools add another distinction: the entity organising work, the machines contributing computational power and the independent nodes verifying the resulting block need not be the same operator.

For a child, think of somebody being allowed to suggest the next page. Other people must still check it against the agreed rules.

This is not an exercise in cryptocurrency investment. It is an explanation of the system’s division of responsibility.

6. Ethereum: nodes, execution software and validators have different jobs

Ethereum uses a different architecture.

Its documented node design includes an execution client, which processes transactions and maintains execution state, and a consensus client, which follows the proof-of-stake chain and related agreement rules.

A validator can be attached to that arrangement to carry out protocol duties such as attesting and occasionally proposing a new block. A normal verifying node does not have to be a validator.

Ethereum’s node architecture documentation, updated in March 2026, distinguishes those components explicitly.

That is a more accurate explanation than saying every computer mining away in the background makes Ethereum work. Ethereum changed from proof of work to proof of stake in September 2022; it does not currently use Bitcoin-style mining as its block-production system.

There are additional roles associated with building blocks, operating services and maintaining software. For a beginner, however, the essential difference is enough: the node checks and follows the network; a validator participates in particular consensus duties.

Operating a node or validator is an advanced technical task. Children do not need to stake ETH, handle real keys or place assets at risk to learn the distinction.

7. A permissioned blockchain can have named organisational operators

Return to the four libraries. They might decide that only approved participating organisations can run specified parts of their network.

A framework such as Hyperledger Fabric supports permissioned participation. It has a different operating arrangement from the Bitcoin and Ethereum examples.

Peers can host ledger data and application logic. Endorsing peers can execute or simulate particular proposed transactions and sign responses according to endorsement policies. An ordering service sequences approved proposals into blocks. Committing peers perform the relevant checks before applying valid updates.

These stages and responsibilities are described in Fabric’s peers documentation and ordering-service documentation.

But a Fabric network does not decide which library’s employees deserve particular roles. The participating organisations and their governance agreements determine membership and appropriate authority.

In our fictional competition, the libraries might jointly require selected institutions to endorse a publication request. That is a possible design, not a claim that any real school competition should adopt Fabric.

Permissioned does not mean unaccountable; public does not mean nobody has responsibilities. Both kinds of system require us to identify the actual operators.

8. Who writes and maintains the software?

Programmers and software-maintenance teams write the client software that nodes run. They work on defects, updates, performance, interoperability and security.

A developer can propose a change or publish a new version of software. That does not automatically force every independently operated node to install the change or make the new rules universally accepted.

Ethereum’s governance explanation describes proposals, client developers, node operators, validators, users and other stakeholders in its off-chain coordination process.

This point is especially important when people say, “The developers can do anything.” They may have substantial influence through expertise and software distribution, but influence is not the same as unilateral power to change the rules enforced by every independent participant.

On a small private network the situation can be different. The owner or governing group might control all deployments, membership rules and software updates. We should not give that system a fictional independence it does not possess.

A useful classroom question is: “If somebody writes a new rule into a program, who still has to accept or install it before our system uses it?”

That moves the conversation from the person who typed code to the people who can adopt, refuse or dispute its effects.

9. Who controls the website that ordinary people see?

Alicia opens a page showing that she won the writing prize. The banner is green and says “Verified”.

But who operates that website? Where did the displayed result come from? Is the app showing the current accepted record, an old cached copy or a separately maintained database?

A web interface is not necessarily the same thing as the underlying network. Its operator may control how records are labelled, which records appear and which questions a user can ask.

The label “Verified” may mean that a transaction was found in a particular ledger. It does not necessarily mean the judge was fair, the story was written by the claimed person or the certificate has the meaning a parent assumes.

A person using a block explorer may see a transaction and a convenient name attached to an address. The on-chain data and the website’s interpretation of it have different evidentiary status.

The related specialist lesson is BC054 — Reading a Block Explorer.

When teaching a child, ask, “Is this what the network confirmed, or what the website says about it?” That is a remarkably useful digital-literacy question.

10. The service providers behind the doorway also matter

Many applications connect to blockchains through remote services known as RPC providers, gateways, indexers or infrastructure platforms. Those services can make access easier without operating every part of the underlying network.

They can also fail independently. A remote service may be unavailable while other participants continue verifying blocks and transactions. An index may lag behind the accepted network history.

If most users rely on one provider, that provider can become a practical point of dependence even when the underlying ledger has several independent participants.

The presence of a public blockchain therefore does not mean every application built on it has an equally distributed operating structure.

For our competition, imagine the libraries share a record through multiple independent operators but every family checks results through one single website. If that site disappears, parents may struggle to see the results even while the record remains available elsewhere.

Distributed data and distributed access are not the same guarantee.

See BC051 — Infrastructure Dependencies and BC055 — Who Actually Checks the Claim? for the technical detail.

11. Who is responsible for the truth of the information?

The judges award Alicia first prize. An administrator signs and submits the result. The network accepts the record according to its rules.

What can a verifying node establish? It may check the transaction’s structure, authorisation and accepted place in the ledger. It cannot independently read every story and decide whether the judges were right.

The organisers remain responsible for having an appropriate judging procedure, correcting factual mistakes and responding to appeals.

The distinction appears in many real-world applications: a shipment record is not the shipment, a school certificate is not the student’s actual competence, and a sensor’s measurement is not guaranteed to be correctly calibrated.

Blockchain systems that use external data need identifiable and checkable sources. Ethereum’s oracle documentation discusses that boundary.

A complete operational question therefore sounds like this: Who is responsible for the quality of the claim before the network records it?

Technical consensus may agree that a message was accepted. It does not appoint an honest judge or turn uncertain evidence into established fact.

12. Who can change the rules?

A student might ask: “If the rules were written by people, couldn’t those people change them tomorrow?”

Yes, people can propose changes. Whether changes become effective depends on the system’s governance and operating arrangements.

In a public network, proposed protocol changes can involve documentation, discussion, implementation, testing and adoption by different participants. No single proposal automatically controls all nodes. The network may experience disagreement about what should change.

Ethereum’s governance documentation provides one current example. The Ethereum Improvement Proposals guide explains how potential protocol changes are specified and debated.

In a permissioned network, participating organisations may adopt documented membership or channel-configuration policies, with specific administrative permissions. The Fabric policies documentation shows one such approach.

The word governance covers the human process for deciding and implementing rules. It should not be mistaken for an automatic vote by every computer or token holder in every network.

For our writing competition, changes to judging criteria and changes to the digital ledger’s processing rules are separate issues. A fair system must know which authority governs each.

13. Five powers that should be examined separately

When someone asks “Who controls the blockchain?”, the question is too broad for a one-word answer. Try separating control into five powers.

Power to submit: Who can send a transaction or statement?

Power to validate: Who can independently check whether proposed information follows the technical rules?

Power to propose or order: Who can influence the order in which candidate changes are considered?

Power to change protocol rules: Which parties can propose, implement and adopt different software or policies?

Power to decide real-world meaning: Who can legitimately award a certificate, declare a delivery complete or resolve a factual dispute?

These powers may be distributed differently. A public network might allow broad submission and verification, but some specialised providers may still dominate ordinary users’ access. A permissioned network may have explicit membership authorities and limited validators.

Even if many independent computers store the history, one website may determine which labels users see. Even if two organisations sign a transaction, an outside institution may determine the legal ownership of an asset.

Decentralisation should be examined by responsibility, not treated as a single magic adjective.

The deeper exercise is BC030 — Measuring Blockchain Decentralisation Without a Single Score.

14. Does anybody own a blockchain?

Some networks are maintained by organisations that own servers, client software or trademarks. Others are public protocols with independently operated infrastructure and a variety of stakeholder groups.

Asking who owns a computer is different from asking who controls the consensus rules. Owning a token is different again from owning the company behind a service. A legal claim about artwork or land is another issue entirely.

Imagine our four libraries. Library A owns its node’s server. Library B owns a second server. A joint agreement may govern the shared ledger. That does not mean Library A owns every prize certificate simply because its computer stores a copy.

For Bitcoin, running a verifying node does not grant ownership of other users’ funds. For Ethereum, owning ETH does not automatically mean owning the protocol or controlling every network upgrade.

For a specific permissioned system, the organisations’ contracts, roles and technical configuration determine who controls what. We must inspect that actual arrangement.

A good parent explanation is: “You can own one machine that helps run a network without owning everybody’s records or the whole network.”

15. What happens when an operator disappears?

Suppose one of our libraries loses internet access. Its node cannot follow the shared record in real time.

What happens next depends on the network design. Other participants may keep processing changes, or the agreement process may need to pause if too many necessary participants are unavailable.

The disconnected library might later reconnect, obtain missing records and verify the accepted history. But that is a capability to establish in the actual network, not a guarantee that any particular service can recover instantly.

Now imagine something more serious. The only website through which parents can retrieve certificates shuts down. The blockchain may still preserve technical data, yet the convenient service and the supporting documents may be inaccessible.

The lesson is that survival of the ledger and continuity of the service are different requirements.

A complete plan must address backups where appropriate, independent evidence access, software maintenance, qualified staff, service outages and the organisation responsible for recovery.

For further reading, see BC070 — Blockchain Incident Tabletop.

16. Who pays for everything?

Blockchain systems require computing resources, connectivity, software work, storage, security and support. None of that is free simply because there is no central administrator.

On public networks, economic incentives and fees can play a role. On permissioned networks, participating organisations may pay for infrastructure and ongoing management according to agreements.

Who pays to keep the nodes online? Who handles a security incident? Who upgrades the software? Who answers users’ questions? Who maintains archives when a project finishes?

These questions matter more to an ordinary school than the exciting claim that a network can operate without a central company.

A project can work technically and still fail to remain useful if nobody commits to maintaining it. History, records and promised independent checking mean little if the relevant people cannot access or interpret the evidence.

The specialist guide BC080 — Blockchain Operating Budgets explores the operating-cost question.

17. A public blockchain is not the same as a school-controlled one

Our fictional writing-prize organisers could use a private or consortium arrangement where the member libraries define the network’s roles.

That differs from a public network designed for participation without an identical membership process.

It would be misleading to say every blockchain is owned by a group of banks, just as it would be misleading to say every blockchain has no administrators whatsoever. The network category matters, and the actual architecture matters more.

For an ordinary school competition, a shared database may be more appropriate than either blockchain option. The organisers can still teach the concept as an enrichment topic without deploying it.

The technical distinction is covered in BC009 — Public, Private and Consortium Blockchains and BC045 — Hyperledger Fabric Transaction Flow.

18. Does the organisation that wrote the code control the network forever?

Not necessarily. In a public network, writing client software may give a team significant influence, but independently operated participants can choose what compatible software and rules to use.

In an organisation-controlled project, whoever holds administrator privileges may have much more direct power. The actual rights must be examined rather than inferred from the marketing name.

Even an application deployed onto a public blockchain can have its own administrator keys, upgrade powers or emergency controls. Such application-level privileges do not automatically grant control of the underlying network.

A learner should therefore ask two different questions: Who controls this application? Who controls the network it uses?

For an older student, compare the writing-prize website with the shared record beneath it. Replacing the website may not rewrite the history, but it can affect who sees which information and whether they can act on it.

That distinction helps prevent the misleading conclusion that every product on a public blockchain is governed in the same decentralised way.

19. A read-aloud explanation for children

Imagine explaining it at a kitchen table.

“Suppose four schools want a shared record. Some people submit information. Other people check whether the information was authorised. Computers use agreed rules to maintain a history that participants can examine.

“The computers have operators who keep them working. Programmers maintain the software. In some networks miners or validators help propose new blocks. But the person who proposes an update cannot necessarily force everyone else to accept one that breaks the rules.

“The people organising the real activity are still responsible for it. If a teacher records the wrong result, the blockchain does not become an expert teacher. And if a website shows an old result, the underlying network might still be working properly.

“So a blockchain is run by people and software under rules. The interesting question is which people do which jobs, and what happens if one of them makes a mistake?”

That is enough for a first explanation. There is no need to introduce cryptocurrency purchases or a mining machine to a young learner.

20. A twenty-minute classroom activity: run the roles, not a real blockchain

You need five role cards and a few sheets of paper. Write Submitter, Checker, Proposer, Record Reader, and Organiser. Everyone uses fictional entries. No accounts, keys or real personal information are required.

First, the Organiser writes the rules for a pretend writing competition: a submission needs an entry number and a deadline check before its accepted receipt is recorded.

Next, the Submitter creates an entry. The Checker decides whether it satisfies the written rules. The Proposer suggests the next page of accepted activity. The Record Reader checks whether the page contains an approved entry and whether it follows the agreed sequence.

Then the teacher quietly adds a proposal for an entry submitted after the deadline. Ask who detects the problem and which role is allowed to reject it. If the Proposer wrote the invalid entry, should the Record Reader accept it anyway?

Introduce a second surprise. The Organiser announces that the deadline should now be different. Does that announcement automatically change what the group accepted earlier? Discuss who is authorised to change a rule and whether every participant has agreed to apply it.

Finally, say that a judge made an unfair assessment. Can our record check establish literary fairness? No. It can show what was recorded under the rules. The judging process needs its own scrutiny.

The exercise is not a secure blockchain. It demonstrates a division of responsibilities, not proof of work, proof of stake, cryptographic verification or distributed consensus. That boundary should be stated clearly to the class.

21. Age-appropriate learning routes

Primary 1–3: Use just two roles: the person writing a record and the person checking it. Ask why a copied message is not automatically an approved decision. Focus on sequence and fair rules.

Primary 4–6: Add a third role that proposes a page. Give children an invalid entry and let them discover why proposing a page is not the same as making it acceptable. Introduce the word node only after the activity makes sense.

Secondary 1–2: Discuss users, node operators, software developers, miners, validators and application administrators. Compare the roles without claiming every network has them all.

Secondary 3–4: Add network-specific designs, key authority, governance and service failures. Compare a public blockchain with a permissioned consortium and an ordinary database.

Older students and adults: Investigate implementation-specific consensus rules, protocol upgrades, infrastructure concentration, administrative powers and incident recovery. Separate technical validation from the real-world meaning of recorded claims.

These are teaching routes, not compulsory examination syllabus statements. Progress when the learner can explain the responsibility and its limits in their own words.

22. Six questions that reveal who actually holds power

When evaluating any blockchain-based service, ask:

Who submits? What messages can ordinary users propose, and what permissions must they have?

Who verifies? Can independent participants check results, or must they rely on one provider’s display?

Who produces or orders? Which actors can propose blocks, sequence transactions or influence what is processed first?

Who changes the rules? How are upgrades proposed, implemented and adopted? Can a particular administrator override the advertised process?

Who holds real-world responsibility? Who checks source facts, protects people and handles disagreements when the ledger conflicts with reality?

Who keeps the service operating? Which organisations provide the machines, staff, connectivity, security and recovery plans?

If a brochure says “fully decentralised” but cannot answer these questions, the label is not enough information to evaluate the system.

23. Common misunderstandings to correct

“There must be one company running the blockchain.” Not necessarily. Public networks can have many independent operators. Permissioned systems can have defined organisational control.

“Every user runs a node.” No. Many users interact through applications and service providers, while a different set of participants operates nodes.

“Every node mines cryptocurrency.” No. Mining applies to particular proof-of-work designs. Nodes can verify without mining; Ethereum uses proof-of-stake validators rather than Bitcoin-style mining.

“Miners or validators can make any rule they want.” They have specific protocol roles, and independent verification and governance affect which changes other participants accept.

“A software developer’s proposal immediately changes everyone’s network.” Not necessarily. In networks with independent operators, protocol changes require implementation and adoption through the applicable coordination process.

“The website is the blockchain.” No. The website is an application or information service. It may show an incomplete or stale view of the underlying system.

“Blockchain confirms the judge told the truth.” It can record an authorised statement. It does not independently assess literary quality or fair judging.

“Nobody is responsible because the network is decentralised.” People and organisations remain responsible for their own actions, systems and applicable obligations.

The better question is always what the particular actor is empowered to do and which evidence establishes the result.

24. Frequently asked questions

Who owns Bitcoin’s blockchain?

Bitcoin is an open network with independently operated participants rather than a single owner of everyone’s ledger. People may own computers or assets, but that is different from owning the entire protocol or controlling every independent node.

Who runs Ethereum?

Ethereum is maintained through multiple participants with different roles, including node operators, validators, software developers, application teams and users. Its official governance guide distinguishes the governance process from ordinary use of the protocol.

Is a miner the same as a validator?

The terms describe different consensus-related roles in different network designs. Bitcoin uses proof-of-work miners; Ethereum currently uses proof-of-stake validators. Do not apply one network’s internal rules to the other.

Can I use a blockchain without running a node?

Yes. Applications and service providers can offer access without requiring every user to maintain a node. That convenience can also introduce dependency on the provider.

Can someone run a node without owning cryptocurrency?

For some networks, yes. For example, Ethereum’s own solo-node explanation says a person can run a node without staking ETH. Operating a validator has separate protocol requirements.

Do nodes decide whether an award was fair?

No. They check the network and application rules they are designed to check. The judging evidence and fairness of an external competition are separate matters.

Who decides on a blockchain software upgrade?

It depends on the network. A public protocol may require coordination among developers, operators and other stakeholders; a permissioned system may have formal institutional policy and administrator roles.

What happens if one node goes offline?

It depends on the architecture and how many necessary participants remain. Some systems continue operating, while others may pause new changes until enough participants are available.

Does more decentralisation always mean better service?

Not automatically. A design may gain independent checking or resistance to unilateral control while also increasing coordination, maintenance and recovery challenges. The right arrangement depends on its purpose.

Should a school set up a real blockchain for children to understand it?

No. Children can learn the roles and trust boundaries safely using paper activities and invented information. A genuine deployment needs a separate and justified institutional decision.

25. Connect the actors to the full learning library

This article is the people-and-roles doorway. It explains the humans and organisations behind the machines. It does not replace the existing specialist studies of nodes, consensus, governance or network architecture.

Start with How Blockchain Works | Why We Need Blockchain for the problem of jointly maintained commitments. Continue to How Blockchain Works | The Complete System for an end-to-end architecture map.

For practical applications, use How Blockchain Works | What Can We Do with It. For origins, visit How Blockchain Works | The History. For a parent’s starting point, How to Explain Blockchain to a Child? (Or an Adult) provides a read-aloud example.

The numbered technical route includes BC007 — Nodes, Clients and Peer-to-Peer Networks, BC021 — Consensus Claims, BC042 — Who Does What in Bitcoin?, BC043 — Ethereum Client Boundaries, BC045 — Hyperledger Fabric Transaction Flow and BC081 — Mapping Governance.

The complete English technical guide and Simplified Chinese technical guide connect the wider 100-topic curricula. The main Master Blockchain hub connects the parent-and-child explanations and the full system.

Sources, distinctions and a final thought

The foundational description follows the NIST blockchain overview. The Bitcoin distinction between full nodes, blockchain validation and mining is taken from the project’s published documentation.

Ethereum-specific descriptions follow its node architecture, node operator and validator information, and governance guide. Hyperledger Fabric’s permissioned design is documented through its peer roles, ordering workflow and policies. These are implementation-specific documents, not proof that every blockchain works identically. Sources reviewed in October 2026.

The writing competition, its characters, libraries, role cards, entries and award decisions are fictional educational examples. They describe no real deployed blockchain at eduKateSG or any school. The activities need no cryptocurrency, private keys or real children’s personal information.

Ask a student once more: “Who runs a blockchain?” They may answer, “People run different computers and software under agreed rules.” That is a useful start.

Then ask, “Who was responsible for the information, who verified the update, who could change the rules, and who helped the user see the result?”

When we can answer those questions separately, blockchain stops looking like a mysterious machine that runs itself—and starts looking like a system whose responsibilities can be understood, tested and improved.