Chapter 3 · What If We Do Not Trust the Bookkeeper?

A Real-World Problem

A badminton group of about twenty people meets weekly. Members take turns paying for courts and shuttlecocks, and everyone reimburses them afterward.

Wang initially volunteers to keep the accounts in the group announcement. Everyone is happy. Three months later, the first disagreement appears: Wang says you owe 180, but after checking your transfers, you think you owe 120.

Nobody is lying. Wang may have missed an entry, or you may have confused it with another transfer. The group argues for two days, then compromises at 150.

The incident is minor. But scale it up by changing three variables, and its nature changes:

Twenty people become two hundred. Nobody can reconcile from memory now; everyone must trust the announcement's numbers.

Hundreds in payments become hundreds of thousands. Omitting a payment now brings enough benefit to tempt someone.

You and Wang become strangers. You no longer even have the judgment that he probably would not cheat you.

The question emerges: without a bookkeeper everyone accepts, how can a group maintain one shared record?

Notice the shape of the question. Finding a more honest person or buying better software does not answer it. Chapter 2 explained how real-world ledgers gain credibility through licenses, audits, regulation, and courts. This chapter asks whether another method exists when those constraints are absent.

Thought Experiment

Move the village into a room.

Ten people each hold a notebook. There is no bookkeeper or village chief. One rule applies: to transfer money, stand up and shout—for example, “I send five shells to number 3.” Everyone who hears it records the transfer in their own notebook.

In theory, all ten notebooks should stay identical. In practice, problems appear one after another.

First problem: someone does not hear clearly. Number 4 sneezes and misses a transfer. Half an hour later, people discover a mismatch but cannot say whose book is wrong.

This is manageable: stop periodically, reconcile, and correct minority versions to match the majority.

Second problem: impersonation. Number 7 lowers their voice and shouts, “I am number 3; I send fifty shells to number 7.” Everyone records it. Number 3 returns to discover fifty missing.

This too can be handled: each person posts a secret mark on the wall that only they can reproduce and must show it when announcing transfers. Everyone hears the announcement, but everyone can immediately verify whether it really came from the claimed person.

Third problem: conflicting announcements at opposite ends of the room.

Number 3 has only five shells. They go left and tell A, B, and C, “I send five to A.” Simultaneously, an accomplice on the right tells D, E, and F, “I send five to F.”

Both announcements carry number 3's genuine mark, and each is completely valid in isolation. The three notebooks on the left assign the five to A; the three on the right assign them to F.

Reconciliation now reveals two plausible versions, not a recording error. Majority rule also fails because each side has the same number of people.

Fourth problem: head counts can be forged.

Someone suggests majority voting. Number 9 immediately realizes they can wear different hats and impersonate twenty people. Nobody can verify whether a new arrival is an independent person; they only see another hat.

Majority voting assumes one person, one vote, but this room cannot establish that each person has only one identity.

So far, only the first two problems are solved. Stop and think: what would you do about the third and fourth?

Your Decision

Three different notebooks now exist. The group must choose a rule for which version counts.

What Happens

The four rules appear to debate different things but address the same problems. Maintaining a shared record among mutually distrustful people has four layers:

The first two layers are verification: each person can complete them independently without asking anyone's opinion. Checking marks and sufficient balances in your own notebook yields the same conclusion as everyone else's.

The last two are different. Ordering and finality have no objective answer, only shared agreement. Neither of number 3's announcements is physically more “first”; the room must choose one.

Pause here, because this is among the course's most misunderstood points:

The hard part of maintaining a shared record among people who distrust one another is ordering, not storing data.

An ordinary database can handle tens of thousands of writes per second, faster and more reliably. Its efficiency rests on an assumption: there is one writer, and that writer does not lie. Ordering is straightforward because one party determines it.

Remove that assumption, and throughput is no longer the main issue. A database processing a million writes per second still cannot choose between number 3's conflicting statements. This is a question of agreement, not performance.

So a system with an administrator everyone accepts needs none of this chapter's mechanisms. Use a database; it is faster and cheaper. Remember this when judging why a project needs a blockchain.

Build a Model

Turn the four layers into a chain. Every transaction moves from left to right:

The second model is a measuring scale. Use it on any supposedly decentralized system: whom are you still trusting?

Two marks on this scale are easily overlooked.

First, the final level does not mean no trust. It replaces trust in someone's goodwill with trust in rules you can inspect. Trust changes form rather than disappearing. This is why the course repeatedly asks you to verify personally instead of memorizing conclusions.

Second, moving right is not always better. It reduces efficiency, raises costs, and removes remedies after mistakes. The badminton group does not need the final level. A bookkeeper everyone trusts is the best solution for that setting.

The last model concerns how many malicious participants a system tolerates. There is a major distinction:

• If participants only disconnect or crash, without lying, fault tolerance requirements are more relaxed.
• If participants can lie deliberately and send different messages to different people, the threshold becomes much stricter. Such designs typically require malicious participants to control less than one-third or one-half, depending on the design, for all honest parties eventually to see the same record.

This chapter concerns the second category. A system that handles crashes does not necessarily handle betrayal. The engineering difficulty differs by an order of magnitude.

What It Is Called

Now name the phenomena.

Bring it together:

Consensus is a set of rules for ordering and finality without an administrator, not merely a database technology.

Begin evaluating any chain by asking whether the task could still be done without it. If so, it does not need a chain.

Hands-on

A：10
B：10
C：10

AI Lab

Design an accounting system where participants can freely join and leave,
do not trust one another, and may lie or send different messages to different people.
No role may require everyone's trust.

Explain four things:
1. How to establish that a transfer came from its claimed sender
2. How to determine whether a transfer is valid
3. Which rule chooses between conflicting transfers
4. When a transfer can no longer be overturned

Do not use the words “blockchain” or “consensus algorithm.” Describe the mechanisms themselves.

Scenario 1 (double spending): Someone with five units simultaneously sends a five-unit transfer
to each half of the network. Both have valid signatures.
Which takes effect in your design? Who decides, and within what time?

Scenario 2 (Sybil): Someone creates ten thousand identities and joins the network.
Which part of your design fails? What does creating one identity cost?

Scenario 3 (collusion): Some participants secretly coordinate and lie consistently to others.
What maximum proportion can your design tolerate? What happens above it?
How is that proportion calculated?

Real-World Case

Change One Variable

Takeaway Questions

Choose three of the Eighteen Questions for this chapter.

Chapter Check