The trust problem — why do we need banks?

When I first started looking into blockchain, I kept asking myself: Why on earth did we go through all this trouble to invent a slow, complex, cryptographically intense database? What was wrong with just using a PostgreSQL database run by a bank?

It wasn't until I dug into history that it hit me: We didn't invent blockchain because databases were broken. We invented it because human trust is fragile.

1. The Problem: The Double-Spend Conundrum

In the physical world, if I give you a $10 bill, I no longer have it. It’s physically gone. The transaction is self-verifying.

But in the digital world, everything is just bytes. A file is just a collection of 1s and 0s. If I send you a digital photo, I still have a copy of that photo on my hard drive.

If we try to make digital money without a central authority, what stops me from sending the same digital $10 to you, and then immediately sending that same digital $10 to my landlord, and then to a grocery store? This is the Double-Spend Problem.

Before Bitcoin, the only way to solve this was to have a central ledger keeper (like Chase Bank, PayPal, or Venmo) that sits in the middle. When Alice sends $10 to Bob, the bank subtracts $10 from Alice's balance and adds $10 to Bob's balance.

2. Layman Explanation: The Pub Tab

Imagine a group of friends who go out for drinks every Friday. Instead of paying for every single round individually, they decide to keep a joint notepad tab.

If they give the notepad to one person, say Alice, she becomes the "central bookkeeper." Every time Bob buys Charlie a drink, Alice writes it down. This is fast and easy. But there's a problem:

• What if Alice gets lazy and makes a mistake?
• What if Alice secretly subtracts $5 from her own balance because she's short on cash?
• What if Alice gets angry and refuses to let Bob buy Charlie a drink?

To solve this, they decide: No single person gets the notepad. Instead, everyone carries their own identical copy of the notepad. Every time someone buys a drink, they shout it out, and everyone writes it down on their own sheet. At the end of the night, they compare notebooks. If Alice tries to cheat, her notepad won't match the other five, and her changes are ignored.

This is what a blockchain does. It's the multi-notebook pub tab.

3. Technical Explanation: Centralization vs. Consensus

In a centralized system, state changes are trivial. A single database node executes an UPDATE users SET balance = balance - 10 WHERE id = 'alice' query inside a transaction lock. The trust boundary is simple: you trust the DBA and the security of that single server.

In a decentralized ledger, there is no master server. Instead:

1. P2P State Propagation: When Alice signs a transaction, it is broadcast to all nodes on the peer-to-peer network.
2. Deterministic Validation: Each node verifies that Alice has the cryptographic signatures and sufficient balance to execute the state change.
3. Consensus Protocols: Nodes must agree on the chronological order of transactions to prevent double-spending. This is achieved via Proof of Work (PoW) or Proof of Stake (PoS), ensuring that changing history requires controlling the majority of the network's stake or computing power.

4. Real-World Usage: The Cost of Centralized Arbitrage

In production, global payment networks like SWIFT charge substantial fees and take 3–5 days to settle cross-border transactions because they require navigating a chain of intermediate "correspondent banks," each keeping their own closed ledgers. Smart contracts settle globally in seconds to minutes because there is only one shared global ledger state.