Blockchain nodes run software, and that software needs maintenance. An update can fix bugs, improve performance or change protocol behaviour. But installing a new version is not the same as changing the network’s accepted rules: independent participants and compatibility requirements matter.
Three schools operate computers that share a fictional equipment ledger. Alicia installs a new version of the booking application. Tricia’s computer still uses the older version. Kai Kai asks whether they can continue sharing the same accepted history and who approved any rule changes.
This chapter is written for parents, children and adults who want a clear explanation of the technology without cryptocurrency speculation. The school example is fictional; no live blockchain account or student data is needed.
The quick answer
Blockchain nodes run software, and that software needs maintenance. An update can fix bugs, improve performance or change protocol behaviour. But installing a new version is not the same as changing the network’s accepted rules: independent participants and compatibility requirements matter.
The story behind the mechanism
Three schools operate computers that share a fictional equipment ledger. Alicia installs a new version of the booking application. Tricia’s computer still uses the older version. Kai Kai asks whether they can continue sharing the same accepted history and who approved any rule changes.
1. Separate ordinary maintenance from rule changes
A security patch, interface improvement and consensus-rule change are not the same operation. Some updates preserve compatibility with the current network rules; others require coordinated adoption or a defined activation process.
2. Client software and protocol are related but distinct
A node implementation executes network rules. A network may have multiple client implementations or versions. A developer publishing software does not automatically compel independent operators to install it.
3. Compatibility is the real question
If nodes apply incompatible validity rules, they may disagree on which blocks or transactions are acceptable. A project should document the intended network, software versions and activation conditions.
4. Testing before deployment
Use an appropriate test environment to check normal transactions, rejected transactions, peer connectivity, recovery and data compatibility. A local demonstration is not proof of production readiness.
5. Governance decides who may act
A permissioned consortium may define administrators and change-control approvals. A public network may rely on a broader adoption process. In both cases, the actual distribution of authority should be explained rather than assumed.
6. Plan for rollback and recovery carefully
A software rollback may not be safe after a protocol or database migration. Operators need backups, version-specific instructions, incident ownership and tested recovery procedures. Reversing an installation is not the same as reversing blockchain history.
7. Keep users informed
A family-facing application should explain outages, changed rules and pending actions in ordinary language. A software upgrade does not justify silently changing what an existing certificate or booking means.
8. Paper activity: two versions of the rules
Give two groups the same booking history but different cancellation rules. Ask whether they will always accept the same future events. Then have them agree on a documented rule version and effective point.
9. Why long-term maintenance matters
A blockchain is not a self-running organisation. Someone must monitor dependencies, patch vulnerabilities, review protocol changes, protect keys and support users. A simpler database may be preferable if the additional network responsibilities are not justified.
A five-question learning check
Ask: What does this mechanism actually establish? Which network or reference does it use? Who supplies the information? What happens if a component fails? What real-world fact remains to be checked? Encourage specific answers rather than the general label ‘verified’.
A parent-and-child exercise
Use the paper example above and change one assumption: disconnect a computer, introduce a conflicting record or change a rule. Ask whether the original result is still supported. The paper activity illustrates reasoning, not real cryptographic security.
When an ordinary system may be better
A school with one accountable administrator may need only a database, signed documents and an audit trail. Blockchain is justified when its particular shared verification or governance properties solve a real problem that simpler alternatives do not adequately address.
Frequently asked questions
Does this prove every claim in the record is true?
No. Technical validity and the accuracy of outside-world claims are different questions.
Can children learn without cryptocurrency?
Yes. Fictional records and paper exercises are enough. There is no need for wallets, private keys or financial transactions.
Does every blockchain work the same way?
No. Network-specific consensus, state, data and software rules matter. Check the appropriate technical documentation for precise claims.
Continue through the learning hubs
For deeper detail, use the specialist technical companion, the English Master Blockchain guide, the Simplified Chinese guide and the main Master Blockchain hub.
Sources and scope
Technical source: https://ethereum.org/governance/. Broader foundation: NIST IR 8202. The school scenarios are fictional and do not describe an actual eduKateSG blockchain deployment.
Takeaway: Blockchain nodes run software, and that software needs maintenance. An update can fix bugs, improve performance or change protocol behaviour. But installing a new version is not the same as changing the network’s accepted rules: independent participants and compatibility requirements matter.