Level 4 · Module 6: Digital Money and New Financial Systems · Lesson 3
Blockchain — What It Does and What It Doesn't
A blockchain is a specific type of database — linked blocks of data, cryptographically chained together, maintained redundantly across thousands of computers that agree on state without a central authority. It is deliberately slow, expensive, and redundant. Those are features for one narrow problem: establishing consensus about ownership without trusting a central party. For almost every other problem, a regular database is faster, cheaper, and better. Most blockchain projects failed because they forgot that.
Why It Matters
Between roughly 2017 and 2022, 'blockchain' became a word that companies added to press releases to raise their stock price and attract funding. IBM, Walmart, Maersk, and hundreds of others launched blockchain initiatives with genuine fanfare. Most of those initiatives have since been quietly wound down. Understanding why they failed tells you more about how technology adoption actually works than almost any success story.
The failure was not technical. The technology worked. The failure was conceptual: most of the problems those companies were trying to solve did not require the specific property that blockchain provides — trustless consensus across parties with no central authority. They required fast, cheap, reliable data storage. Regular databases do that better by every measurable metric.
Where blockchain does provide something real — Bitcoin, Ethereum, cross-border transfers without intermediaries, programmable settlement — it has produced durable value. Understanding the distinction between 'this problem genuinely needs trustless consensus' and 'this problem needs a database' is the entire key to evaluating blockchain claims. Most people making blockchain claims cannot articulate that distinction.
Smart contracts — code that runs automatically on a blockchain — extend the genuine use case but also extend the attack surface. Ethereum's smart contract ecosystem has generated real applications (decentralized exchanges, lending protocols, stablecoins) and real disasters (the Ronin Network hack: $625 million stolen in 2022; the Wormhole bridge hack: $325 million in 2022). The code runs automatically and irreversibly. Bugs are permanent. This is a real constraint that most DeFi promoters underemphasize.
A Story
The Right Answer Is Not the Popular One
In the spring of 2018, a logistics company called Meridian Freight gave an engineer named Priya a six-month project: 'Explore whether blockchain can improve our supply chain tracking.'
Priya had been at the company for three years. She knew their systems well. She also knew the assignment was partly driven by a consultant's presentation and a competitor's press release, not a specific problem anyone had articulated.
She started by writing down what supply chain tracking actually required: record who picked up a shipment, when, and where; record every handoff; make that record auditable; and ensure no one could retroactively alter it to hide a loss or delay.
'Okay,' she said to herself. 'Which of those requires no central authority?'
None of them, she realized. Meridian Freight was the central authority. They were the ones issuing shipments, contracting carriers, and paying claims. The problem was not that they couldn't trust a database. The problem was that their existing database was eight years old, had terrible query performance, and was maintained by a contractor in a different time zone.
She spent two months exploring blockchain implementations anyway — Hyperledger Fabric, a private Ethereum deployment, a consortium chain with their top three carriers. The technology worked. But every implementation was slower to query than their existing database, required a dedicated team to maintain, and introduced complexity around who ran the nodes.
The fundamental problem: a blockchain's value is proportional to the number of mutually distrustful parties who need to agree on shared state. Meridian Freight trusted their own systems. Their carriers trusted Meridian Freight enough to do business with them. There was no untrusted-consensus problem to solve.
By month four, Priya had written a 12-page internal report. Her conclusion was blunt: 'A blockchain is the correct solution if and only if you need multiple parties who do not trust each other to agree on a shared record without a central authority. We are the central authority. We need a better database, not a different kind of database.'
Her manager looked uncomfortable. 'We told the VP of Operations we'd have a blockchain pilot by Q3.'
'We can have a better database by Q3,' Priya said. 'I can present it either way.'
They went with the database. Performance improved by 80%. No one wrote a press release. The project was never mentioned in the company's annual report.
Two years later, Priya read that TradeLens — Maersk and IBM's heavily promoted global shipping blockchain — had shut down after failing to attract enough participants. The reason given was almost word-for-word her internal report: the industry could not agree on governance for a shared chain, and most participants were not willing to give up control to a system they did not run.
She saved the article. Not because she was right. Because the failure pattern was worth remembering.
Vocabulary
- consensus mechanism
- The method by which all computers in a blockchain network agree on which transactions are valid and in what order. Bitcoin uses proof-of-work. Ethereum switched to proof-of-stake in 2022. The mechanism determines speed, energy use, and security tradeoffs.
- proof-of-stake
- A consensus mechanism where validators are chosen to add new blocks based on how much cryptocurrency they have locked up ('staked') as collateral. Much more energy-efficient than proof-of-work, but critics argue it concentrates power among large holders.
- smart contract
- Code stored on a blockchain that executes automatically when preset conditions are met, without requiring any party to manually trigger it. Ethereum's main innovation. Useful for trustless agreements; also the primary vector for DeFi hacks, since bugs execute automatically and cannot be reversed.
- gas fees
- The cost paid to compensate Ethereum validators for the computation required to execute a transaction or smart contract. Fees spike during periods of high network demand and can exceed the value of small transactions.
- immutability
- Once a transaction is recorded and confirmed on a blockchain, it cannot be altered or deleted. This is a feature for establishing permanent records — and a problem when mistakes are made, since corrections require new transactions rather than edits.
Guided Teaching
Start with what a blockchain actually is — technically. It is a linked list of data blocks. Each block contains a set of transactions and a cryptographic hash of the previous block. If you change any old block, its hash changes, which invalidates the next block's hash, and so on through the entire chain. Ask: 'What property does that give you that a regular database doesn't have?' Answer: tamper-evidence. You can tell if historical records were altered.
Explain the redundancy. The same chain is copied across thousands of computers around the world. When a new block is proposed, the network runs a consensus mechanism to agree it is valid before adding it. This means no single computer controls the record. Ask: 'Why would you want that? What are you afraid of that a single database can't protect against?' Answer: a central administrator who might alter records, or a single point of failure.
Now name the costs. Because every computer runs every transaction, blockchain is slow — Bitcoin processes roughly 7 transactions per second. Visa processes roughly 24,000. Because storage is duplicated across thousands of nodes, it is expensive. Because consensus takes time, finality is slower than a database write. Ask: 'If you were running a business where customers expect instant transactions, would those tradeoffs work?'
Introduce the key question for evaluating any blockchain use case. The right question is: 'Do I have multiple parties who do not trust each other, who need to agree on a shared record, and where no single party is acceptable as the central authority?' If the answer is no, you probably want a regular database. Ask: 'Can you think of a real situation where that description applies?' Bitcoin and cross-border settlement are strong examples. Enterprise supply chains — usually — are not.
Walk through the TradeLens failure. In 2018, Maersk and IBM launched TradeLens with significant fanfare — a blockchain to track global shipping containers. By 2022, it had shut down. The reason: competitors were unwilling to share logistics data on a chain partly controlled by Maersk, their rival. The governance problem killed the technical solution. Ask: 'What does that tell you about the difference between 'the technology works' and 'the solution works'?'
Introduce smart contracts and their risks. Ethereum allows arbitrary code — smart contracts — to run on the blockchain automatically. This enables things like decentralized exchanges and lending protocols that operate without a company behind them. It also means that bugs in the code execute automatically and irreversibly. The Ronin Network (an Ethereum sidechain for the game Axie Infinity) was exploited for $625 million in March 2022. The Wormhole bridge lost $325 million to a bug in February 2022. Ask: 'What is the tradeoff between 'no central authority can interfere' and 'no central authority can fix mistakes'?'
Be fair about where blockchain does work. Bitcoin as a settlement layer for cross-border value transfer with no intermediary is a real use case. Ethereum's smart contract ecosystem has produced working decentralized exchanges (Uniswap), working stablecoin infrastructure (USDC is partially backed by on-chain mechanisms), and working prediction markets. These are not hypothetical. Ask: 'What property of blockchain makes those applications possible, and why can't a regular company just build the same thing?'
Close with the career lesson. Priya, in the story, did the right technical analysis and delivered an unpopular answer. That is harder than it sounds. In most organizations, the incentive is to validate whatever the VP of Operations announced in a press release. Ask: 'What would you need — in terms of job security, personal credibility, or organizational culture — to be able to tell your manager 'we don't actually need blockchain'?' That is as much a lesson in professional honesty as in technology.
Pattern to Notice
Notice that every major 'enterprise blockchain' failure follows the same pattern: a real technology was applied to a problem that did not require its specific properties, because the word 'blockchain' was valuable for marketing even when the technology was not. The pattern is not unique to blockchain — it repeats with every new technology that attracts enough hype.
A Good Response
A good response to 'we should use blockchain for this' is: 'Which specific property of blockchain do we need — tamper-evident records, trustless consensus across distrustful parties, censorship resistance — and why can't a regular database provide that?' If no one can answer that question, the project will probably fail.
Moral Thread
Technical honesty
Knowing what a tool is actually good for — and being honest when it is the wrong tool — is one of the most valuable skills in any technical or financial domain. The blockchain hype cycle is a case study in what happens when a solution goes looking for problems.
Misuse Warning
Do not conclude from blockchain's enterprise failures that it has no real uses. Bitcoin has been running continuously since 2009. Ethereum processes billions of dollars in transactions daily. The failure of IBM Food Trust or TradeLens says nothing about whether decentralized, trustless networks have value — it says only that most enterprise problems do not require those specific properties.
For Discussion
- 1.What is the one specific problem that blockchain is genuinely better at than a regular database? What makes it better at that problem?
- 2.TradeLens failed not because the technology was bad but because of a governance problem. What does that tell you about how to evaluate a technology's prospects?
- 3.Smart contracts execute automatically and cannot be reversed. Name one situation where that is a feature and one where it is a bug.
- 4.Priya's manager wanted a blockchain pilot even after she demonstrated it wasn't the right solution. What incentives explain that reaction?
- 5.If Ethereum processes $10 billion in transactions per day but also hosts multiple $300 million+ hacks per year, how would you evaluate whether the ecosystem is 'working'?
- 6.Why did IBM, Walmart, and Maersk — sophisticated organizations with access to excellent technical talent — invest heavily in blockchain projects that failed? What does that tell you about how technology adoption decisions are made?
- 7.Is 'immutability' — records that can't be changed — always a good property for a financial system? Think of a case where you would want a record to be correctable.
Practice
Blockchain or Database?
- 1.Read the following four scenarios and for each one, decide: does this problem require a blockchain, or would a regular database work better? Write one sentence justifying each answer. (1) A bank tracks which customers own which accounts. (2) Five competing shipping companies need a shared record of which containers are where, and none trusts the others to run the system. (3) A hospital tracks patient medical records internally. (4) A government issues digital currency that citizens can hold without going through a bank.
- 2.Look up one real blockchain project that launched with significant press coverage and has since been discontinued or scaled back. Write two sentences: what problem it was trying to solve, and what the stated reason for failure was.
- 3.Write the strongest argument you can for why Ethereum's smart contract ecosystem is a genuine innovation, not just hype. Use at least one specific example of a working application.
- 4.Write the strongest argument you can for why smart contract risk — bugs that execute permanently and can't be reversed — is a serious unsolved problem. Use at least one specific example of a real hack.
- 5.After doing all four steps: write one sentence stating what you think the practical rule is for deciding when blockchain is the right tool and when it is not.
Memory Questions
- 1.What is the one problem blockchain is genuinely better at than a regular database?
- 2.What is a smart contract, and what is the main risk associated with them?
- 3.What happened to TradeLens, and why did it fail?
- 4.What is immutability, and why is it both a feature and a limitation?
- 5.What is the key question you should ask before deciding whether a problem requires blockchain?
- 6.Name two large-scale DeFi hacks and approximately how much was stolen in each.
A Note for Parents
This lesson makes an argument that goes against the conventional excitement around blockchain technology — that for most practical problems, it is the wrong tool. That is a defensible technical position, but it is not the only position. If your teenager has heard or read enthusiastic claims about enterprise blockchain or Web3 applications, encourage them to bring those claims to the conversation and test them against the framework in this lesson. The goal is not to produce skeptics — it is to produce people who can evaluate specific claims rather than defaulting to either enthusiasm or dismissal.
Share This Lesson
Found this useful? Pass it along to another family walking the same road.