eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

What Is Blockchain? A Clear Guide to Shared Records, Trust and Limits

—

by

eduKate Asia
Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

中文版 · Blockchain learning guide

Blockchain learning · Article BC001

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.
Study photograph for illustration; it does not establish that the pictured students are studying blockchain.

A blockchain is a way for participants to maintain a shared record under agreed rules, with cryptographic links that help reveal changes to its history. Its central problem is coordination: when several parties submit updates, which updates count, in what order, and who can verify the result?

It is useful to picture a jointly maintained register rather than a magical safe. The register can make an accepted history difficult to rewrite. It cannot, by itself, make every statement entered into it true, keep every secret private, or settle every disagreement outside the software.

This guide is for students, curious adults and teams who want a clear technical starting point. You do not need to buy a token, open a trading account or connect a wallet to understand it. By the end, you should be able to explain a blockchain using four ideas: records, rules, agreement and accountability.

Choose your reading route

In this guide

  • New to the subject: start with the shared-register example, then read the four building blocks.
  • Trying to understand the technology: follow a transaction from instruction to accepted state, then examine what cryptography actually proves.
  • Assessing a proposed use: go to the limitations and decision questions, then test the worked example.
  • Revising or teaching: use the misconceptions, short exercise and answers near the end.

Back to contents · Next section

1. Begin with a shared register

Imagine three independent organisations maintaining a record of a laboratory instrument: a manufacturer, a delivery company and a testing centre. Each needs to know which organisation most recently acknowledged responsibility for the instrument. They also want to inspect the sequence of earlier acknowledgements.

A spreadsheet held by one organisation could perform this job. The others would then depend on that organisation to preserve the history, control access and resolve conflicting edits. A shared database could offer stronger controls and backups. These may be perfectly sensible choices.

A blockchain becomes a candidate when the organisations require a jointly governed sequence of updates and do not want one participant to have unilateral authority over the accepted record. Each proposed update must meet the system’s rules. Participants can verify the relevant record rather than relying only on a screenshot from the organisation currently holding the spreadsheet.

The important improvement is therefore specific: a different arrangement for maintaining and checking a shared history. It is not a guarantee that the instrument was actually delivered. A dishonest employee might acknowledge a delivery that never happened. Physical checks, accountable organisations and dispute procedures still matter.

This example is hypothetical. It illustrates the question to ask before discussing platforms: what disagreement about records are we trying to resolve, and which parties must be able to check the answer?

Back to contents · Next section

2. Four building blocks, with four different jobs

Records: what happened, or what is being requested?

A blockchain records protocol-defined data. A transaction may request a transfer, update a contract or record an attestation. “Transaction” does not always mean buying or selling something. In the instrument example, it could mean recording that a named participant acknowledged a handover.

Blocks group records according to the network’s design. A block generally contains or commits to transaction information and refers cryptographically to an earlier block. The resulting chain helps participants check that a presented history is internally connected.

Rules: which changes are permitted?

The software defines what a valid update looks like. A request may need the right signature, sufficient spendable resources and an acceptable sequence number. An application can add rules such as requiring two organisations to approve a handover.

These rules matter more than the visual appearance of the chain. A neatly linked series of blocks containing invalid changes should still be rejected by participants that correctly enforce the protocol. The ability to propose a block is not the authority to make arbitrary changes valid.

Agreement: which valid history is accepted?

Participants may hear about requests at different times. Some may be offline. Two requests may conflict. Consensus rules help the network establish an accepted order or state despite the failures covered by its design.

Different networks solve this coordination problem differently. Some allow broad participation and use resource-based mechanisms; others admit known organisations and use membership and voting arrangements. There is no single “blockchain consensus” that describes every network.

Accountability: who can act, and what happens after failure?

A working system also needs operational and governance arrangements. Who runs the software? Who can change application rules? How are signing keys protected? Can an error be corrected through a new record? Who handles a dispute about goods, identity or entitlement?

These questions are sometimes treated as details to consider later. In practice they determine whether the shared record will remain useful when something goes wrong. A technical diagram without recovery and governance is an incomplete description of the system.

NIST’s introductory overview provides a foundational account of blockchain structure and tamper resistance. It is an October 2018 publication, useful for core concepts rather than evidence of today’s deployment status. Read NIST IR 8202.

Back to contents · Next section

3. The ledger, the state and the application are different

The ledger is the recorded history. The state is the current result obtained by applying the relevant rules to that history. The application gives those records a practical meaning and presents them to a user.

In our example, the ledger might contain “manufacturer issued instrument,” “carrier accepted custody” and “testing centre acknowledged receipt.” The current state might say that the testing centre is the latest recorded custodian. The application might display a delivery timeline.

Notice the careful wording: “latest recorded custodian” is a claim about the system. “The instrument is physically inside the testing centre” is a claim about the world. The second does not follow automatically from the first.

A user interface can also conceal distinctions. A screen showing “complete” may mean that a server received a request, that a transaction appeared in a block, or that a protocol-specific finality condition was met. Those are different events. Understanding the underlying state prevents a friendly screen from becoming the only source of evidence.

Back to contents · Next section

4. Follow one transaction from intention to accepted record

Consider a simplified transfer of ten fictional learning credits from Mei to Arun. These credits have no monetary value. The example is a teaching model, not the transaction format of a named network.

First, Mei expresses an instruction. Her software constructs a message identifying the proposed action and relevant account information. What Mei sees should accurately represent what the software will authorise.

Second, the instruction is authorised. In a simple key-based design, Mei signs the message with the appropriate private key. Other participants can check the signature without receiving that secret key. A more complex account could require several approvals or other programmed conditions.

Third, the network checks eligibility. Does the authorisation satisfy the rules? Are the credits available? Has this instruction already been used? Merely receiving a request does not mean accepting it.

Fourth, a participant proposes an order. Suppose Mei also submits a conflicting instruction to transfer the same ten credits elsewhere. The system needs an accepted ordering so that both requests cannot spend the same available credits in the same accepted history.

Fifth, participants validate the resulting changes. In this teaching model, one valid transfer reduces Mei’s balance and increases Arun’s. If the conflicting request is then evaluated without enough credits remaining, it cannot make the same transfer valid again.

Finally, the result reaches the network’s relevant confirmation or finality condition. The practical meaning of “settled” depends on the protocol and application. It should not be inferred from a universal number of seconds or blocks.

Ethereum’s transaction documentation offers a concrete account-based implementation. Bitcoin’s developer documentation explains a different model using unspent transaction outputs. The shared lesson is that authorisation, ordering and validation have distinct jobs. Ethereum transactions · Bitcoin transactions.

Back to contents · Next section

5. What hashes and signatures actually prove

A cryptographic hash is a compact fingerprint calculated from data. If the data changes, its hash will normally change too. This makes hashes useful for detecting differences and linking records. A hash does not explain why a statement is true, and it does not encrypt the original information.

Imagine hashing a report that says the instrument passed a safety inspection. Later, a verifier can compare a supplied report with the recorded fingerprint. A match can support the conclusion that the report is the one committed to by that fingerprint. It does not establish that the inspection was properly performed.

A digital signature supports a different check: whether a message was signed under the relevant key. A valid signature does not necessarily identify a particular human being. The connection between a key and an organisation depends on identity and authorisation arrangements. If an attacker steals the signing authority, the attacker may produce signatures that are technically valid.

Finally, linking blocks with hashes is not enough on its own. Someone could edit a private copy and calculate new links. The harder question is whether that altered version would be accepted by other participants. Consensus, independent validation and the network’s security assumptions provide the additional protection.

A useful memory aid is: hashes help check data, signatures help check authorisation, and consensus helps coordinate an accepted history. None is a substitute for the others.

Back to contents · Next section

6. “Difficult to change” is more precise than “impossible to change”

Blockchain is often described as immutable. For a beginner, the safest interpretation is resistance to unauthorised changes under specified assumptions.

A network may reorganise recent history when participants learn about a different valid chain. Protocol rules may be upgraded through governance and software adoption. Application administrators may have powers to pause or alter a contract. These are different mechanisms; describing them all as “the blockchain was changed” hides important detail.

Even where an old record remains, the system can support a later corrective record. If a serial number was entered incorrectly, a well-designed register could retain the original entry and add an authorised correction with a reason. Preserving an audit trail and correcting the current understanding can coexist.

Before relying on permanence, ask which part is meant: the transaction history, the current application result, a linked document or an administrator-controlled setting. A document stored outside the chain can disappear even if its fingerprint remains recorded.

Bitcoin’s original paper explains its proof-of-work approach to conflicting histories. It is a 2008 design paper, not a universal description of all blockchains. Read the Bitcoin paper.

Back to contents · Next section

7. Public and permissioned systems answer different questions

A public network can make records widely inspectable. A permissionless design allows participation without a central membership approval, subject to its protocol conditions. A permissioned system limits particular roles to approved participants.

These labels should not be collapsed into one scale. Public visibility, permission to submit transactions, permission to validate and authority to upgrade software are separate dimensions. A system can make information visible while keeping control concentrated. A permissioned network can distribute responsibilities across several organisations while still depending on its membership authorities.

Hyperledger Fabric illustrates a permissioned architecture with distinct endorsement, ordering and validation responsibilities. That makes it a useful contrast with open cryptocurrency networks, rather than evidence that one design is always superior. Fabric introduction.

For the instrument register, publishing all commercial details to everyone may be unnecessary or harmful. The design question is which participants need which evidence, and why. More public data is not automatically more useful accountability.

Back to contents · Next section

8. Blockchain is not the same thing as cryptocurrency

A blockchain is an architecture for records and permitted changes. A cryptocurrency is one application and, in some networks, part of the mechanism that pays for resources or shapes participation incentives.

A permissioned ledger does not necessarily require a publicly traded coin. Conversely, a cryptocurrency exchange is a service with its own accounts, controls and operational risks; it is not identical to the underlying blockchain network.

The same separation applies to smart contracts. A smart contract is code executed according to a platform’s rules. It can make specified actions conditional on specified inputs. It does not independently know what happened in a warehouse or classroom. An oracle supplies information from outside the chain, bringing its own sources and failure risks. Ethereum’s oracle documentation explains this boundary.

Scope note for readers in mainland China: Blockchain technology and virtual-currency business activities are distinct regulatory questions. MIIT/CAC have issued blockchain development guidance; virtual-currency and RWA-related activities are addressed by the PBOC-led notice 银发〔2026〕42号 of 6 February 2026, which replaced the 2021 notice. This educational article does not imply that any financial service is available or permitted for a reader, and does not recommend investment or regulatory workarounds. MIIT guidance · PBOC notice.

Back to contents · Next section

9. Three useful promises, and their limits

A shared history can be independently checked. This is valuable when participants need to inspect what the system accepted. The limit is that the verifier still needs the appropriate data, software and understanding of the rules.

Rules can constrain updates. A protocol can reject a transfer that lacks valid authorisation. The limit is that correctly executing a poorly designed rule can still produce an undesirable result. Software correctness and a good policy are different achievements.

Several participants can maintain continuity. Distributed operation can reduce dependence on one machine or organisation. The limit is that shared software faults, common hosting, concentrated control or an unavailable access provider can create correlated failures.

These are conditional engineering benefits. They should be evaluated against a specific alternative, not against an imaginary database with no access controls, backups or audit logs.

Back to contents · Next section

10. Return to the instrument: a worked design review

Suppose the manufacturer proposes storing a hash of each inspection report, a handover record and the organisation that signed it. Three questions immediately clarify the proposal.

What can a reviewer verify? A reviewer with the report can compare its fingerprint with the recorded value, check the associated authorisation and inspect the recorded sequence. This may make later disputes about which version was submitted easier to investigate.

What remains outside the chain? The quality of the inspection, the actual location of the instrument and the authority of the person operating the signing key still need evidence. The report itself also needs a reliable storage and retrieval arrangement.

How would an error be handled? The proposal should specify corrections, revoked signing authority, disputed handovers and unavailable participants. “Nobody can ever change anything” is not an adequate procedure for a wrongly entered serial number.

A reasonable outcome could be a permissioned ledger. Another could be a shared database with signed records. A third could be a simpler registry operated by an institution all parties already trust. The example does not prove that blockchain wins; it shows how to make the comparison concrete.

Back to contents · Next section

11. Five questions before accepting a blockchain proposal

  1. Who writes? Identify the people, services or organisations allowed to propose each kind of change.
  2. Who verifies? Ask who can independently check the relevant evidence rather than merely view a dashboard.
  3. Who controls exceptions? Find the upgrade, pause, correction and recovery powers, including any administrator keys.
  4. What is still trusted? Include identity providers, document storage, sensors, oracles, interfaces and real-world issuers.
  5. Why is a simpler option insufficient? Compare the proposed system with a database, signed document or shared audit log that has competent operational controls.

If a presentation cannot answer these questions, adding terms such as “decentralised” or “next generation” does not resolve the missing design work.

Back to contents · Next section

12. Check your understanding

Question 1: A shipment record is on a blockchain. Does that prove the correct goods arrived?

Question 2: A message has a valid signature. Does that prove its author was an honest employee?

Question 3: A wallet says “submitted.” Is the requested change necessarily final?

Question 4: A company wants a private database for its own staff, with one administrator and no need for external verification. Is blockchain automatically the best choice?

Answers: No in all four cases. The shipment needs real-world evidence. A signature is checked against signing authority, not a person’s honesty. Submission precedes possible inclusion and finality. The company should first assess a conventional database with access controls and an audit trail.

For a deeper exercise, write one sentence describing the instrument register without using “secure,” “transparent” or “trustless.” A strong answer is: “The organisations share an ordered record of authorised handover statements, while inspections and dispute procedures establish what those statements mean in the real world.”

Back to contents · Next section

Frequently asked questions

Is blockchain just a database?

It stores and coordinates data, so comparison with databases is useful. Its distinguishing concern is how participants agree on and verify permitted changes to shared history. Conventional databases can also be replicated, access-controlled and audited. The appropriate comparison is between complete designs.

Does everyone store everything?

Not necessarily. Nodes can have different roles, retention policies and verification capabilities. Some systems divide data or restrict access. Never infer storage and privacy arrangements from the word blockchain alone.

Can a blockchain contain false information?

Yes. A valid transaction can record a false external assertion. The system may faithfully preserve who submitted that assertion without independently proving it true.

Must I learn programming first?

No. Begin with records, authorisation, ordering and failure handling. Programming becomes useful when you want to inspect or build an implementation, but it should not replace understanding what the system is meant to guarantee.

What should I learn next?

Learn why hashes differ from encryption, how signatures differ from identity, and how a network resolves conflicting updates. Then compare blockchain with a conventional database using one concrete workflow. Understanding those distinctions is a stronger foundation than memorising platform names.

Back to contents · Next section

Sources and further reading

The technical research reference was checked on 12 October 2026, Asia/Singapore. Original publication dates below are preserved; living documentation may change. Examples and design-review questions in this article are explanatory synthesis, not claims about a deployed eduKate system. The mainland China policy links were separately checked during this editorial review.

The central question to carry forward is simple: who can change what, under which rules, and what happens if they fail?

Back to contents

Next: Blockchain vs Traditional Databases