Problems a Blockchain Might Experience | What Can Go Wrong and Why

What problems might a blockchain experience? A blockchain network can become slow, lose contact with some computers, disagree temporarily about recent records, or struggle to process new transactions. Applications built on top can have software bugs, stolen credentials, wrong information, privacy mistakes, or dependencies that stop working. Sometimes the underlying blockchain continues to operate correctly while the app on somebody’s screen fails.

That distinction matters because the word blockchain is often used for several different things at once: the shared ledger, the computers maintaining it, the software using it, the people supplying information, and sometimes a cryptocurrency whose market price moves independently. When one part goes wrong, it is easy to blame the entire technology. When a network does fail, it is equally easy to mistake a tidy-looking screen for proof that nothing is wrong.

This guide explains common blockchain problems in plain English, using a fictional school science fair. Parents, children and adult beginners can follow the opening story without programming or buying cryptocurrency. Later sections explain what to check when a record appears missing, a system stops updating, a program behaves incorrectly, or a digital history becomes difficult to interpret. The aim is not to frighten readers about technology. It is to teach them how to ask better questions when something does not work as expected.

The 30-second answer: a blockchain can go wrong in several different ways

A blockchain is a system for maintaining a shared, checkable history under agreed rules. It is not a guarantee that every participant, application, message, sensor or user will always be correct.

A blockchain network can experience delays, outages, partitions, competing recent versions of history, trouble reaching agreement, overloaded resources, malicious behaviour and difficult upgrades. Software applications can also suffer coding mistakes, compromised permissions, unavailable services or confusing displays.

Some problems affect the accepted ledger itself. Others affect only the route by which a person reads or uses it. Still others begin outside the computer, with a human misunderstanding or a faulty measurement.

The first question to ask is: “Which part failed?” Once we know the layer, we can ask what evidence would distinguish a delay from a loss, a bad input from a broken rule, and an application outage from a network-wide problem.

Meet the school science fair and its shared record

Imagine three schools running a joint science fair. They share portable microscopes, a small robotics kit and a display of student experiments. Each school has its own organiser and its own equipment register.

The organisers want a shared log of which school has each item, which transfers were accepted, and when an item is due back. For the sake of our story, they choose to experiment with a simple, fictional permissioned blockchain.

That choice is a teaching device, not a recommendation. In real life, the schools might quite reasonably use a shared spreadsheet or ordinary database. A blockchain only becomes interesting when the organisations need a specific form of shared checking and agreement that simpler systems do not supply.

At 9:00 a.m., Alicia requests the microscope for her school’s biology demonstration. At 9:03, Tricia logs its transfer from another school. At 9:05, Kai Kai opens his screen and still sees yesterday’s location.

Has somebody stolen the microscope? Has the record been changed? Has the blockchain stopped? Or has Kai Kai’s app simply not received the latest update?

We do not know yet. And that is our first lesson: a surprising screen is a clue, not a diagnosis.

Before blaming the blockchain, separate its five layers

It helps to imagine five layers stacked on top of each other.

Layer 1 — The network. Computers communicate, exchange information and participate in maintaining a shared history. Connections and machines can fail.

Layer 2 — Agreement and validation. The rules determine which proposed updates are valid and which history is accepted. Conflicting messages or missing participation can slow or prevent progress.

Layer 3 — Applications and services. Programs read the ledger, show screens, process requests and sometimes execute smart contracts. An application can contain errors even while the network functions.

Layer 4 — People and the outside world. Someone counts microscopes, reports a delivery, protects a secret key and decides who has authority. A record can faithfully preserve a false statement.

Layer 5 — Governance and purpose. Organisations must agree how rules change, how incidents are managed, and whether the system is worth maintaining. A technically functioning network can still be the wrong solution.

Cryptocurrency trading, where it exists, introduces further financial risks. Price volatility is not evidence that a blockchain protocol has stopped functioning. Likewise, a healthy price does not prove that software and users are safe.

We will use these layers as our map. They prevent a broad question—“Is blockchain broken?”—from hiding several much narrower questions.

Problem 1: messages travel slowly

Kai Kai’s screen shows yesterday’s microscope location. Alicia’s screen shows today’s accepted transfer. It is tempting to think there must be two realities.

But computers do not receive every message at exactly the same instant. Networks have latency: information takes time to travel, and different participants may learn about an update at different moments.

A request might be sent promptly but arrive at a validating service later. A new accepted block might reach one computer before another. A third-party app might refresh on a separate schedule.

For our school fair, the first sensible check is not to accuse somebody of rewriting the register. It is to ask which update each screen is displaying, when that update was observed, and whether both screens are using the same system.

A delayed view may eventually catch up. A persistent disagreement may require deeper investigation. The difference depends on timestamps, network context and the system’s agreement rules.

What to remember: seeing an older state does not, by itself, prove the accepted ledger is wrong.

Problem 2: one computer goes offline

During the fair, one participating school’s server loses electricity. Its copy of the register is no longer updating.

That can sound disastrous until we ask what the network was designed to tolerate. A distributed system can sometimes continue while one participant is offline. Redundancy is one reason people build distributed systems in the first place.

However, availability is not limitless. In a permissioned network, the required endorsers or ordering participants may not all be available. A rule that requires several independent approvals can protect against unauthorised changes while also making certain failures harder to recover from.

The system should have documented requirements for connectivity, recovery and the minimum participation needed to keep processing records.

The lesson for a child is straightforward: three people each having a notebook does not mean that any one notebook can make the whole group agree while everyone else has disappeared.

For adults, the question is sharper: which exact service went down, what function depended on it, and what redundancy was available?

Problem 3: two groups cannot communicate

Imagine the schools are split between two internet connections. The first group can talk internally. The second group can talk internally. But messages are not getting through between the groups.

This is a network partition. It means parts of a network are separated from one another.

Why is this harder than one computer being offline? Because each group may see its own recent information and assume it has the latest picture. Depending on the system’s design, some operations may pause, some may continue under carefully defined rules, and some recent candidate histories may need reconciliation.

A responsible design cannot simply announce that both conflicting bookings are final. It needs explicit rules for availability, agreement and recovery.

Our fair has one microscope. If two disconnected groups both claim it for the same hour, a digital record does not create a second microscope. The real-world resource is still singular.

For learners, draw two islands of computers with a broken line between them. Then ask which messages cannot cross that line. That is enough to understand the problem before learning the technical protocol.

A deeper worked example appears in Two Blockchain Nodes During a Network Partition.

Problem 4: two recent versions of the history appear

Some blockchain networks can temporarily have competing candidate blocks near the newest point in the chain. The participating computers must follow their protocol’s rules to determine which history becomes accepted.

That is why the word fork appears in blockchain conversations. A fork can refer to competing chain histories, but it can also refer to changes in software rules. They are related ideas, not interchangeable explanations of an incident.

For a child, picture two groups writing different versions of the next page at nearly the same time. The problem is not that one group has more colourful paper. The problem is deciding which page the system will recognise under its established rules.

Some systems allow recent chain reorganisations before stronger finality conditions are satisfied. Other systems, including permissioned designs with deterministic finality, use different arrangements. It would be wrong to promise that every blockchain regularly rewrites recent blocks—or that none ever can.

A screen saying “record seen” is therefore not always equivalent to “outcome final”. The application needs to explain what level of confidence or finality its status actually represents.

For the technical distinctions, see Finality, Confirmations and Reorganisations and Hyperledger Fabric’s ordering service documentation.

Problem 5: the system stops making progress

At noon, the school’s shared register stops accepting new transfers. Old entries remain visible, but no new accepted update appears.

This is not automatically the same as losing existing history. A system can remain readable while the machinery that orders or finalises new changes is unable to progress.

The problem might involve disconnected participants, a required service outage, incompatible software, a serious configuration error or a disturbance to the network’s agreement process. The appropriate evidence depends on the design.

For our school fair, the immediate operational question is practical: can the organiser safely continue sharing equipment without an accepted digital handover? If not, the schools may need a pre-agreed manual contingency, with later reconciliation performed under controlled rules.

An organisation should decide those procedures *before* an outage. Inventing a different authority for every emergency makes an incident more confusing.

Technical operators should distinguish no new proposals, proposals received but not ordered, ordered proposals not committed, and committed data not shown by the app. These are different points in a process.

The eduKateSG guide to diagnosing stalled progress and finality develops those distinctions.

Problem 6: there are too many requests at once

After lunch, all three schools try to check equipment, book demonstrations and submit results within a few minutes. The interface grows slow.

A blockchain has finite capacity, and its surrounding services also have limits. More requests than the system can comfortably process may create queues, delays or increased resource costs. It is not a magical system with unlimited storage, processing and network bandwidth.

On some public networks, users pay fees for computation or inclusion. High demand can make some operations more expensive. Those costs vary by network; not every blockchain charges a public cryptocurrency gas fee.

For our fictional school network, there may be no traded coin at all. It can still suffer congestion, insufficient server capacity, expensive infrastructure requirements or a badly designed application that sends unnecessary requests.

An important distinction is throughput versus finality. Throughput asks how much the system handles over time. Finality asks when an outcome can be relied on. Improving one measure does not automatically improve every other property.

See Ethereum’s scaling documentation and Hyperledger Fabric’s performance guidance for concrete examples of different engineering concerns.

Problem 7: fees or operating costs become unreasonable

Some applications are technically possible but too expensive to operate at the scale someone wants.

For a public network with fees, a simple operation might be affordable under one set of conditions and costly under another. For an enterprise or school network, the expense may appear as servers, monitoring, networking, security, backups, independent operators and staff time.

Imagine spending more on running the science-fair register than on all the microscopes it is supposed to manage. The system may be functioning exactly as designed and still be a poor choice.

The right comparison is not “Does blockchain cost anything?” Every database and business process costs something. The right comparison is “What are we gaining, and can we achieve it more simply?”

It is also important to avoid confusing network fees with an app’s own charges. The app provider may impose costs or limits separately.

The Ethereum gas-and-fees documentation explains one particular public-network model. It should not be copied as a description of all blockchains.

Problem 8: somebody deliberately overwhelms a service

Not every large queue is caused by excited students trying to register their science projects.

Digital services can also be targeted by unwanted or malicious traffic. The aim may be to make an application difficult to use or to exhaust some of its resources. The specific risks and defenses vary across network protocols and application designs.

Our imaginary science-fair register might be accessible through a public website. If that website becomes overwhelmed, parents may see a blank page even when the underlying shared ledger remains healthy.

That distinction is useful for incident response. Defending a website endpoint is not the same job as defending the rules that make a blockchain agree on records.

Do not assume every slow screen is an attack. Ordinary demand, a faulty software release and insufficient capacity can look similar at first.

For a beginner, the main question is: What was overloaded—the network, a validating service, a public website, or somebody’s phone?

Problem 9: participants with authority misbehave

A shared ledger depends on rules for participation. Those rules need to account for participants who fail accidentally and, in some threat models, participants who act dishonestly.

A small permissioned network may give recognised organisations specified roles. A public network can use other mechanisms to determine which participants influence consensus. Neither arrangement means that every participant is trustworthy by definition.

Attacks involving disproportionate control, censorship or dishonest block proposals are important subjects. But it is misleading to say that one universal “51% rule” explains every blockchain. Different systems have different security assumptions, resources and ways of selecting an accepted history.

Even where a network has protective mechanisms, concentration of power may affect whose transactions are included, which changes are prioritised or how difficult an attack would be.

For our school fair, imagine the school responsible for approvals intentionally ignores another school’s requests. A technically functioning record system might still be governed unfairly. The rules must consider oversight and accountability.

A deeper route is Sybil Attacks and Permissionless Participation and Measuring Blockchain Decentralisation.

Problem 10: the computer agrees with a faulty program

A smart contract is programmed behaviour executed within a blockchain system. It can enforce specified conditions, but code can contain bugs.

Suppose the science fair uses a booking program that is supposed to prevent two schools from reserving the same robotics kit for the same period. A programmer makes a mistake in the rule. Under certain conditions, the program accepts conflicting reservations.

If the network faithfully runs the program, it may still accept an undesirable result. This is a smart-contract application problem, not necessarily a failure of the network’s cryptographic links or consensus.

Some deployed code is difficult to patch. Certain systems offer carefully designed upgrade or emergency-control mechanisms, but those introduce further decisions about who may use them and when.

Independent review, testing, access controls and incident planning reduce risk. They do not guarantee the absence of all defects.

The Ethereum smart-contract security guide discusses why secure application design matters. The eduKateSG Smart Contracts as State Machines guide shows how to examine a program’s rules before trusting an output.

Problem 11: a secret key is lost or stolen

In some blockchain applications, cryptographic keys are used to authorise actions. If someone loses control of the relevant private key, they may lose the ability to act. If someone else obtains it, that person may be able to issue apparently authorised instructions.

This can create serious consequences even if the blockchain network itself is operating correctly.

Imagine the science-fair organiser’s signing credentials are stolen. An attacker may try to approve an equipment transfer. The system may verify a mathematically valid signature but cannot automatically know that the rightful organiser did not intend the action.

That is a difference between cryptographic authorisation and human intent.

Recovery varies. A centrally managed classroom system may revoke credentials and reissue access. Other applications may have a documented recovery design. Some public assets offer little or no practical recovery when a key is lost or a final transfer is sent to the wrong address.

Children do not need actual private keys or wallets to learn this idea. A pretend key card in a role-play is sufficient. Never ask students to reveal passwords, recovery phrases or private credentials.

For a deeper explanation, use Blockchain Recovery: Match the Lost Capability to the Recovery Evidence.

Problem 12: a person approves an action they did not understand

A screen might say “Continue”, “Connect” or “Approve”. But which authority is being granted underneath?

In systems that support programmable permissions, a confirmation might authorise more than a user believes. Malicious websites, deceptive interfaces and confusing prompts can create danger without changing the core blockchain protocol.

Our science-fair example is simple: the organiser believes she is approving one robotics-kit checkout. An unclear interface could instead authorise repeated future transfers. The most important failure may be the mismatch between what the person believed and what the system was authorised to do.

For an adult learning about a real blockchain application, inspect the precise scope of any requested permission and the trustworthiness of the service. Do not sign unfamiliar actions or connect real financial accounts merely to follow this article.

For students, teach the wider digital-literacy rule: a polished button is not proof that the underlying action is harmless.

The technical companion is Blockchain Confirmation Screens: Compare Displayed Intent with Signed Authority.

Problem 13: the information entered was wrong

Tricia records that the robotics kit arrived at the north school. The record is accepted. Unfortunately, the kit is still sitting on a table at the south school.

The digital history may preserve the report perfectly. That does not make the report true.

This is often called an input problem or an outside-world data problem. People, sensors or other systems supply information. A blockchain cannot personally examine a classroom table and decide whether a physical kit has moved.

The schools need reliable evidence and agreed rules for correction. That might involve a handover acknowledgement, a photograph handled with appropriate privacy protections, a scan or a second authorised check. No single method is automatically infallible.

The lesson applies to supply chains, certificates, school inventories and other proposed blockchain uses. A secure history of claims is not the same thing as verified reality.

For the difference between preserving an incorrect entry and correcting it, read Can You Correct a Mistake on a Blockchain?.

Problem 14: the outside data source becomes unavailable

Some blockchain applications need information from outside their network: an event result, a price, a delivery acknowledgement or a sensor reading.

The mechanism bringing external information into a blockchain application is often called an oracle. The term is technical, not supernatural.

If the external source stops responding, responds late, supplies stale information or reports incorrect data, the application may be unable to make a sensible decision. The blockchain’s agreement mechanism does not automatically repair those outside sources.

Our schools might use a weather station to decide whether an outdoor science demonstration can proceed. If the weather station fails and repeats yesterday’s reading, the application could be working correctly with bad information.

The practical questions are: which source provided the data, when was it observed, what check was performed, and what happens if the source cannot be trusted?

See Blockchain Oracles: Check the Report Before Trusting the External Fact and Ethereum’s explanation of oracles for the deeper mechanism.

Problem 15: two separate blockchains cannot safely exchange a message

Some projects try to move information or digital assets between different blockchain networks. That introduces a new problem: one system must decide what evidence from another system to accept.

This is not the same as copying text between two school notebooks. A destination application needs carefully defined rules about origin, finality, authorisation and whether a message has already been processed.

A poorly designed bridge or cross-chain application may rely on vulnerable software, compromised operators, mistaken verification assumptions or unsafe custody arrangements. A failure can be serious even if both underlying blockchains continue to produce blocks.

For the school fair, imagine two organisations each maintain a separate record and an adapter promises to transfer approved bookings between them. If the adapter duplicates a message or trusts an unauthorised source, a clash can appear despite both ledgers operating normally.

The lesson is to inspect the connection between systems, not automatically blame either ledger.

The technical route is Cross-Chain Messages: Decide What the Destination Is Allowed to Accept.

Problem 16: a good network is hidden behind a broken website

A parent presses “View today’s science fair results”. Nothing loads.

What failed? Maybe the blockchain is down. But maybe the website is offline, the API endpoint has failed, the application database is stale, an indexer is behind, or the user’s internet connection has dropped.

The front end is the part that people interact with. It can depend on several services even when the underlying ledger is healthy.

One common mistake is to take a screen’s error message as a complete explanation of the network. Another is to assume that a successful app request proves the underlying chain finalised the expected result.

A reliable operator should be able to distinguish requests submitted, accepted, ordered, finalised and displayed. The correct vocabulary depends on the network architecture.

For beginners, use three labels on paper: the record, the service that reads the record, and the screen. Ask which one the person actually observed.

The deeper guide is Blockchain Infrastructure Dependencies: Find the Failure Behind the Interface.

Problem 17: the screen says “confirmed” but the status is unclear

People often assume that a green label must mean the entire story is complete. Yet different applications use words such as submitted, pending, included, successful, confirmed and final in different ways.

A transaction might be submitted but never accepted. It might be included and execute unsuccessfully. A successful execution might still be shown through a stale interface. Some networks distinguish inclusion from stronger finality conditions.

The reader needs to ask what the word on the screen means in that specific application. A label without context is not enough.

Our science-fair organiser should not send the same equipment transfer request repeatedly merely because a webpage appears stuck. In a real system, resending requests without understanding their status could create duplicates or new conflicts.

A safer conceptual approach is to verify which system the interface is showing, which event the label refers to and what evidence supports that status. In an actual financial setting, use official support channels rather than following unverified instructions.

For the technical distinctions, read Reading a Block Explorer and Diagnosing Failed Blockchain Transactions.

Problem 18: the system becomes difficult to store or maintain

A blockchain records history over time. More activity can mean more data to store, transmit, verify or index.

Some participating computers store extensive historical information; others are designed to access or verify a subset. These arrangements vary. It is inaccurate to say that every device in every blockchain must permanently hold every byte of history.

Growing storage, bandwidth and computing requirements can nonetheless increase operational costs. If participation becomes too expensive for some operators, the network’s structure and resilience may change.

Our fair lasts one afternoon, but imagine extending the experiment to many schools over several years. Storing every tiny status update forever may be an unnecessarily burdensome design.

A good system decides which events need an auditable history, which supporting documents belong elsewhere, how historical information remains available and who takes responsibility for maintaining it.

For a deeper distinction between verification, archive data and infrastructure, see Blockchain Data Availability and Blockchain Historical Indexes.

Problem 19: private information becomes too visible

Imagine the science-fair application records each child’s home address, health information and individual school results in a publicly accessible permanent ledger.

The network may function exactly as designed, yet the application creates a serious privacy problem. Data replication and tamper resistance can make later removal difficult.

Singapore’s Personal Data Protection Commission guide to blockchain design asks organisations to think carefully about personal information, network type, access and data-protection obligations before using blockchain.

The safest beginner exercise uses fictional names and pretend events. Never publish children’s personal records to demonstrate that a technology works.

The privacy challenge does not disappear just because the information is encrypted or reduced to a hash. The full context determines whether something can still be linked to a person.

A responsible designer asks what truly needs to go on the ledger, what can remain in an access-controlled conventional system, who can see it, and what happens when someone requests a correction or deletion.

Problem 20: correcting a mistake is harder than expected

Sometimes a valid update contains a wrong quantity, the wrong identity or an unintended instruction. An application may support a new authorised correction, but the old accepted event can remain in its history.

That is not a universal defect. An audit trail can be valuable. Yet organisations must design how to recognise corrections, display the current state and make the history understandable.

Some effects cannot simply be undone by adding an explanatory note. A transferred digital asset may require the present controller to cooperate. A private fact that has been publicly copied cannot reliably be erased by posting “please ignore”.

The science-fair register should therefore have a rule for correcting a mistaken equipment entry. It should not pretend the rule allows it to make old photographs, downloads or real-world events disappear.

For our complete parent-friendly treatment, visit Can You Correct a Mistake on a Blockchain?.

Problem 21: a software update divides the participants

Digital systems need maintenance. Bugs are found, security measures change and new capabilities become necessary. In a network shared by several organisations, updates may require coordination.

Suppose two of the schools install new software while a third school keeps running an older version. Depending on compatibility and the rules involved, the participants may disagree, lose interoperability or require a managed upgrade process.

Some protocol changes are backward-compatible; others are not. The word fork is sometimes used for these rule changes as well as for competing histories, which is why a technical explanation must say which meaning it intends.

A permissioned network needs defined governance: who can propose a change, who approves it, which systems must update, and what happens if someone refuses or cannot comply.

The problem is not solved by shouting “decentralised”. Shared control makes the decision structure important.

Children can understand this using a game. If one group changes the rules halfway through and the others keep the old rules, the players may no longer agree on a valid move.

Problem 22: everyone expects someone else to be responsible

A network can have several organisations, many computers and sophisticated mathematical checks—and still have an unclear incident-response plan.

Who takes the call when the science-fair register is unavailable? Who verifies that a correction is legitimate? Who can revoke a stolen credential? Who pays for independent testing? Who tells schools about a safety problem?

If nobody owns these duties, the system’s weakness lies partly in governance rather than code.

The answer is not necessarily to appoint one organisation with unchecked control. It is to assign responsibilities that match the design. A consortium may share important decisions while still allocating clear operational roles.

A child can learn this with a simple question: “If all three schools are responsible, which teacher do we tell when the borrowing register goes wrong?” If nobody can answer, the process is incomplete.

A complete technology lesson includes people, procedures and accountability, not just computers.

Problem 23: a blockchain is used where a database would be better

Not every blockchain problem begins with a cyberattack or broken server. Sometimes the first mistake is choosing blockchain for a problem that does not require it.

For the science fair, a trusted school administrator may be able to manage equipment loans with a normal database and an audit log. If that solves the work reliably, requiring a complex multi-party network may add cost, maintenance and confusion without useful benefit.

A shared database can offer permissions, backups, change history and good performance. Blockchain is one particular set of design choices about shared records and agreement, not a synonym for all trustworthy data.

Ask: Why do we need several independent participants to validate the history, rather than one accountable operator? If the answer is vague, the case for blockchain is weak.

The relevant technical reading is Blockchain vs Traditional Databases and When a Blockchain Is Useful and When It Is Not.

Problem 24: people confuse market losses with a broken technology

Blockchain became famous through cryptocurrency, and market headlines have shaped public expectations. But cryptocurrency prices are influenced by buyers, sellers, regulation, speculation, liquidity and many other market factors.

A token can fall sharply in value while the underlying network continues functioning as designed. Conversely, an asset can command a high market price while the app or system supporting it has serious security, governance or financial problems.

A child should not be asked to interpret a price chart as evidence about distributed systems. These are separate questions.

To understand blockchain, begin with records, validation, agreement, security and limitations. To discuss investing, one would need a different conversation about financial risk and suitability. Learning blockchain does not require purchasing any cryptocurrency.

That separation is built into our earlier What Is Blockchain? How Children Should Learn About It the Right Way.

Problem 25: the environmental cost is ignored

Operating a network requires computing equipment, electricity and infrastructure. The scale and nature of those requirements differ considerably across designs.

Proof-of-work networks rely on computational work as part of their security mechanism. Proof-of-stake and permissioned systems use different arrangements, with different resource profiles. It would be wrong to treat every blockchain as having the same energy use—or to claim that none has an environmental footprint.

There are also costs in hardware, manufacturing, data centres, cooling, staff and replacing equipment. These should be considered as part of system design.

For the science fair, a complex distributed network that requires more resources than the actual educational activity is a questionable choice.

The sensible question is not “Is technology clean or dirty?” It is “What resources does this particular system consume, what benefit does it deliver, and is there a more efficient way to accomplish the task?”

That is an excellent science lesson about energy, resource use and responsible engineering.

A quick symptom guide: what should we check first?

A symptom is what somebody observes. A cause is what explains it. Keeping those separate prevents an understandable frustration from turning into an unsupported accusation.

Symptom: “My screen still shows the old result.” Check which network or application you are viewing, when its information was last updated, and whether a later accepted record exists. The issue may be delayed synchronisation or an outdated display.

Symptom: “My request is stuck.” Distinguish a request that was never submitted, one awaiting processing, one included but unsuccessful, and one accepted by the network but not reflected in the application.

Symptom: “Two people see different records.” Compare the network, block or checkpoint context, software version, data source and time. Do not infer a malicious rewrite from two screenshots alone.

Symptom: “The website is unavailable.” Check whether the issue is specific to the website or also affects the underlying network and independent services. A front-end outage is not proof of a chain-wide halt.

Symptom: “The system accepted something wrong.” Ask whether the input was incorrect, the program rule was defective, a key was misused, or the displayed interpretation was wrong. Those problems demand different responses.

Symptom: “Information that should be private is public.” Treat this as a privacy and incident-response concern, not merely a formatting correction. Do not repost the private data while attempting to investigate it.

Symptom: “A token’s price collapsed.” This is a financial-market event. It does not by itself establish a network failure.

These are diagnostic questions, not instructions to interact with live financial accounts or attempt risky fixes.

Return to the science fair: a complete afternoon of problems

Let’s revisit Alicia, Tricia and Kai Kai. The science fair begins with one shared equipment history and a simple goal: every school should be able to find the agreed status of its equipment.

At 9:05, Kai Kai sees an old location. The first investigation reveals an app that has not refreshed. The underlying accepted transfer is not necessarily wrong.

At 10:10, one school’s server loses connectivity. The others can read old records, but the schools have to check whether enough authorised participants remain available for new updates.

At 11:00, two organisers make competing reservations. A well-designed application should apply its agreed ordering and booking rules; it should not promise one physical kit to two schools for the same hour.

At 12:20, the weather sensor reports yesterday’s temperature. Even an impeccably linked record of that reading would not make it today’s temperature.

At 1:15, a volunteer notices that the app is asking for permission to perform more actions than the role requires. The right response is to review the permission design, not simply praise the cryptography.

At 2:00, the organisers realise the system has become more difficult to operate than they expected. They ask whether a conventional shared database could handle the same tasks with less burden.

The six problems came from different layers. Some involve the network, some involve software, and some involve people or the outside world.

That is why a broad “blockchain problems” article needs a map of failure types rather than one universal explanation.

Five questions every learner should ask

Whenever someone reports that “the blockchain failed”, try asking these five questions in order.

What exactly did you observe? Give the visible symptom: an old status, a rejected request, an unavailable website or a conflicting record.

Which layer was involved? Is the concern about network messages, consensus, an application, a user’s key, outside information, governance or financial markets?

What evidence supports the explanation? Look for a specific event, authoritative record, relevant timestamp, controlled test or documented network behaviour—not just an alarming screenshot.

What can this evidence not prove? A cryptographic signature does not prove honest intent. An accepted record does not prove a physical delivery. An error message does not prove the network has stopped.

What is the safe next action? In an educational simulation, that might be to compare logs and draw the system. In a real organisation, it might involve authorised operators, incident procedures or a temporary pause. Never improvise with private credentials or other people’s data.

This small method is useful far beyond blockchain. It is a way of practising clear thinking under uncertainty.

A no-money classroom experiment: the interrupted science-fair register

This activity uses three paper notebooks and cards. It is a teaching model, not a working blockchain. It does not establish cryptographic security or faithfully reproduce a public consensus protocol.

Give Alicia, Tricia and Kai Kai one notebook each. Write the same initial state in all three: “Robotics kit R1 is at School A.”

Round 1 — A normal handover. An authorised card says, “R1 moves to School B.” The organiser checks the rule and tells each learner to record the accepted event. Ask what the current state should be.

Round 2 — Delayed messages. Quietly hold back Kai Kai’s card. Alicia and Tricia show School B, but Kai Kai still shows School A. Ask whether he necessarily has the wrong *history* or merely an older view.

Round 3 — A disconnected participant. Take Tricia to another table. The other two can no longer send her the update. Ask whether the class’s rules permit progress without her. Do not invent a universal answer; write down the rule the class chooses.

Round 4 — Conflicting requests. Two learners propose booking R1 for the same hour. The teacher checks the class’s predefined order and authorisation rules. Ask why both requests cannot simply be called accepted.

Round 5 — Wrong real-world input. Write, “R1 returned to School A,” but leave the model kit at School B. Ask which evidence would resolve the claim.

Round 6 — A broken screen. Cover Kai Kai’s notebook with a sheet labelled “Website unavailable”. Ask what we know about the record underneath. Very little from the covered screen alone.

Round 7 — Privacy. Ask what should happen if a real child’s home address appears in the notebook that everyone has copied. Explain why preventing disclosure is easier than collecting every copy later. For the activity, use a fictional placeholder, never an actual address.

Finish by asking students to sort each round into network, agreement, application, real-world or privacy problems. They can disagree about a label if they explain the dependency and make their reasoning clear.

How parents can teach this without technical overload

For a younger child, there is no need to start with “Byzantine consensus”. Start with a notebook that does not update, two children trying to reserve the same kit, and a card containing a wrong fact. Ask what they would check.

For an upper-primary student, add the difference between an accepted event and the current displayed state. Invite them to put cards in time order and identify when a missing message changes a person’s view.

For lower-secondary learners, introduce the idea of a network partition, software rule and cryptographic permission. Compare the benefit of several independent recordkeepers with the extra coordination they require.

For older students, add finality, smart-contract flaws, failure domains, threat models, network economics, governance and privacy safeguards. Ask for evidence and alternative solutions rather than memorised terminology.

Adults benefit from the same foundation. A parent who can explain the difference between a broken website and a broken ledger has learned a meaningful system-design principle.

None of these lessons requires a cryptocurrency exchange, real wallet, online account or financial investment.

A 35-minute lesson plan

Minutes 0–5: Present the mystery. Kai Kai sees yesterday’s location while Alicia sees today’s. Ask students to invent at least three possible explanations. Do not reveal the answer.

Minutes 5–12: Draw the system. Place the network, agreement process, app and outside world on separate sheets. Ask students where information can be delayed or mistaken.

Minutes 12–22: Run the paper experiment. Work through one normal handover, one held-back message and one faulty real-world report.

Minutes 22–28: Compare failures. Ask whether all three problems would need the same repair. Introduce the difference between a correction, a technical recovery and an incident involving privacy.

Minutes 28–35: Explain it back. Each learner finishes: “I saw…”, “It might be caused by…”, “I would check…”, and “This evidence would not prove…”.

The lesson succeeds when a learner can identify what went wrong without treating an impressive technical term as the explanation.

Frequently asked questions

Can a blockchain crash?

A blockchain network or service can become unavailable, stop processing new updates, or suffer interruptions. Whether the entire network halts depends on the system’s design and the nature of the failure. A single unavailable website does not necessarily mean the distributed ledger has stopped.

Can a blockchain be hacked?

Different parts of a blockchain ecosystem can suffer security failures. The core consensus mechanism has its own threat model; smart contracts, wallets, bridges, apps and services have additional risks. A hacked application does not automatically mean the blockchain’s accepted history was broken.

Can two computers disagree about a blockchain?

Yes, particularly when messages are delayed, software versions differ or parts of a network become disconnected. Protocols are designed to handle specified kinds of disagreement, but their guarantees and limits differ.

Can a blockchain lose data?

Availability, persistence and recoverability depend on the network design and supporting infrastructure. A local service may lose access to data while other participants retain it. An application’s missing display is not by itself proof of permanent loss. Some systems also rely on separate data availability and archive arrangements.

Why are some blockchains slow?

Transactions and validation require computing and communication. Capacity, demand, design trade-offs and supporting services all affect performance. It is not accurate to compare different networks using one unexplained speed number.

Can the price of Bitcoin fall because a blockchain has a problem?

Technical incidents can affect confidence and markets, but cryptocurrency prices move for many reasons. A price decline alone is not a reliable diagnosis of a blockchain technical problem. Financial analysis belongs to a separate discussion.

What if a smart contract has a bug?

The result depends on the code and available controls. Testing, audits, limited authority, monitoring and contingency mechanisms may reduce risk, but cannot guarantee that every problem is preventable or reversible. Some deployed code is difficult to change.

Does an unchangeable record guarantee truth?

No. It can preserve a wrong statement. A physical delivery, sensor measurement or school result still requires trustworthy inputs and appropriate checks.

Is a private blockchain automatically safer?

Not necessarily. Permissioned systems can define participant roles and access controls, but can still suffer bad configuration, concentrated authority, faulty programs, operational outages or governance failures.

Can we teach blockchain problems without using cryptocurrency?

Yes. Paper registers, fictional science-fair events and classroom activities are enough to explore delays, agreement, permissions, corrections, security and system design.

A practical assessment worksheet for an adult

A parent, educator or project team evaluating a blockchain proposal can use this checklist before trusting a claim of reliability.

• Purpose: What real coordination problem requires a shared ledger?
• Participants: Which organisations or computers maintain and check it?
• Availability: What happens if a node or service goes offline?
• Agreement: What prevents conflicting updates from both being accepted?
• Finality: When is an outcome safe to rely on?
• Security: Who can approve sensitive actions and how are credentials protected?
• Application quality: How are programs tested, reviewed and monitored?
• Outside data: How are measurements and reports checked?
• Privacy: What personal data is excluded from the shared history?
• Correction: What happens if an accepted record is wrong?
• Dependencies: Which websites, databases, indexes and service providers are required?
• Governance: Who decides on upgrades and emergency responses?
• Economics: What is the total operating cost compared with a simpler system?
• Recovery: How is a serious incident identified, communicated and resolved?

These questions are not a certificate of safety. They are an invitation to inspect the real design rather than trusting a slogan.

How to know whether the explanation worked

Ask a student to explain this sentence: “The science-fair website is down, so the blockchain must be broken.”

A thoughtful learner may reply: “Maybe. But the website could be the problem. We should find out whether the shared ledger is still working.”

Now ask: “The blockchain says the kit was returned, so it must be in the cupboard.”

A thoughtful learner may say: “The record shows someone reported a return. We still need evidence that it happened.”

Finally ask: “A cryptocurrency fell in price, so its blockchain failed.”

A thoughtful learner can answer: “Those are different things. We need evidence about the network before making that claim.”

Three small distinctions show that the student understands the structure of the problem. They are more useful than memorising 25 technical terms.

Where this fits inside the eduKateSG blockchain library

This article is the problem map of our beginner blockchain route. It does not replace the deep technical articles already in the Master Blockchain series. It helps readers recognise which of those detailed guides they should open when a particular question appears.

If the term blockchain itself is still unfamiliar, start with How to Explain Blockchain to a Child? (Or an Adult) and the parent-first article What Is Blockchain? How Children Should Learn About It the Right Way.

For the broad mechanism, read How Blockchain Works | Simplest Explanation and then the Master Blockchain learning hub. The hub links into the more technical, structured English–Chinese material.

For specific faults, follow the appropriate specialised guide: stalled progress and finality, network partitions, smart-contract state machines, oracles, infrastructure dependencies and data availability.

The next useful learning step is not “Find more frightening blockchain headlines”. It is choose one failure, identify its layer, trace its evidence, and compare the available solutions.

Technical sources and further reading

The explanation of shared ledgers, cryptographic links, agreement models, limitations and threat assumptions draws on the US National Institute of Standards and Technology’s Blockchain Technology Overview, NIST IR 8202 and NIST’s Blockchain overview.

For an example of a public-network architecture, Ethereum’s consensus documentation, scaling guidance, gas and fees documentation and smart-contract security guidance describe different mechanisms and associated risks. They are Ethereum-specific examples, not definitions of every blockchain.

For an example of a permissioned architecture, read Hyperledger Fabric’s ordering-service documentation, gateway failure-handling documentation and performance considerations. Its design differs in important ways from open, permissionless networks.

For Singapore’s privacy context, use the Personal Data Protection Commission’s Guide on Personal Data Protection Considerations for Blockchain Design. This provides design guidance, not individual legal advice.

Sources and the linked eduKateSG article inventory reviewed in October 2026. The science-fair examples and paper activities are fictional teaching exercises, not claims about any real Singapore school or deployed blockchain.

The main lesson is simple: a blockchain is a system made from people, computers, messages, software, rules and evidence. When something goes wrong, don’t begin by blaming everything. Find out which part failed, what can be verified, and what the safest correction or recovery would look like.