What a Toy Blockchain Reveals About Trust
Checking that a record belongs, deciding which history to follow, and safely moving money are different problems.
Imagine a cashier checking your account and confirming that you have $100 available. They hand you the money, then turn to record the withdrawal. Before they finish, you ask again.
The account still shows $100.
The cashier checked your balance. What went wrong was the timing of the update.
That distinction helped me make sense of my blockchain coursework at Cornell Tech. Across Python exercises and Solidity contracts, I encountered several mechanisms that could be described loosely as making a system trustworthy. Looking back, the more useful question was specific: what does each mechanism actually establish?
A document can belong and still be wrong
Imagine a collection of documents protected by a tamper-evident seal. You want to establish that a particular document belongs to that collection without inspecting every document inside it.
A Merkle tree makes a digital version of that check possible. It combines hashes (digital fingerprints of data) into a single value called a root. Given a document and a short proof, a verifier can calculate whether that document fits the collection represented by the root.
In my exercise, this meant combining the document’s hash with the hashes supplied in the proof, in the specified order, and checking whether the result matched the expected root.
But inclusion tells us nothing about whether the document’s claims are true. A false statement can be faithfully preserved in an archive. An unauthorized record can also be included if whoever assembled the collection put it there.
The proof establishes a relationship between the document and a particular commitment to a collection. Deciding whether to trust that commitment, or accept the document’s contents, requires additional checks.
The longest route does not always win
A blockchain can contain competing branches: different sequences of blocks extending a shared history. Following the links backward tells us which blocks belong to a branch. It does not, by itself, tell us which branch to choose.
Think of two routes made of stepping stones. One route contains ten stones worth one point each. Another contains six stones worth three points each. The first route is longer, but the second has the greater total score.
My assignment used a similar rule. Each block added its own weight to its parent’s accumulated weight. The branch whose final block had the greatest total was selected.
When weights differed, counting blocks could produce a different answer from adding their weights. A longer branch was not necessarily the preferred one.
This was a rule within the educational model, not a universal description of how blockchains work. Its lesson was about separating decisions: determining whether a branch satisfies the rules and determining which eligible branch to follow are different tasks.
Paying and recording must happen in a safe order
The Solidity exercises brought me back to the cashier.
A smart contract is a program that manages state and executes rules on a blockchain. When it calls another contract, that other contract may execute code of its own. In some circumstances, it can call back into the original contract before the first operation has finished.
This is the situation a reentrancy exercise explores. A receiving contract attempts another withdrawal during a callback. If the withdrawing contract has not yet updated the relevant state, the second request may encounter an account record that still reflects the balance before the first withdrawal.
The cashier analogy is imperfect, but the ordering problem is the same: handing over money and recording that it has left are separate actions. What happens between them matters.
The archived exercise contains an attempted repeat withdrawal, not evidence that a real-world exploit succeeded. Reading it nevertheless makes the engineering question concrete: when another piece of code gets a turn to run, what state will it find?
Ask what has actually been checked
These exercises taught me to be more precise about the word “trust.”
A proof can establish that a document belongs to a committed collection without endorsing its contents. A selection rule can identify a preferred branch without replacing the checks that determine whether it is acceptable. A balance check can confirm that funds are available without ensuring that the subsequent withdrawal is handled safely.
Each mechanism has a job. Trouble begins when we assume that doing one job correctly settles the others.
Before calling a system trustworthy, I want to be able to name what it has checked and what remains unanswered.