Introduction to Blockchain

You've probably heard blockchain described as "digital money" or "the future of the internet." These explanations miss the point entirely.

Blockchains are distributed systems: networks of computers that must agree on shared data without trusting each other. This course teaches blockchain from first principles: the distributed systems problems it solves, how it solves them, and why the tradeoffs matter.

Let's start by understanding why building distributed systems is one of the hardest problems in computer science.

Distributed Systems

Most people think scaling from one computer to many is just "more of the same." That's like thinking coordinating one person is the same as coordinating a thousand people across different time zones who might not always be reachable.

When you write code on a single computer, you live in a predictable world:

• Operations either succeed or fail immediately
• Data doesn't mysteriously change between reads
• Time moves forward consistently
• When you save something, it's actually saved

Let's take a simple banking system. Transferring $100 from Alice to Bob in that case is extremely easy:

def transfer(from_account, to_account, amount):
    if from_account.balance >= amount:
        from_account.balance -= amount
        to_account.balance += amount
        return "Transfer successful"
    return "Insufficient funds"

This works perfectly... until you need to scale.

Your bank grows beyond what one computer can handle, so you now split accounts evenly across different databases:

• Server A: Accounts 1 to 1,000,000
• Server B: Accounts 1,000,001 to 2,000,000
• Server C: Accounts 2,000,001 to 3,000,000

Now Alice (on Server A) wants to send $100 to Bob (on Server B). That simple transfer becomes:

def distributed_transfer(alice_server, bob_server, amount):
    # Check Alice's balance on Server A
    if alice_server.get_balance("alice") >= amount:
        alice_server.deduct("alice", amount)    # Step 1
        bob_server.add("bob", amount)           # Step 2
        return "Transfer successful"
    return "Insufficient funds"

Still seems straightforward? Here's what can go wrong:

• Network Partition: The connection between servers fails right after Step 1 but before Step 2. Alice's $100 vanishes into the digital void.
• Server Crash: Server B crashes after receiving the "add money" command but before confirming it processed. Did Bob get the money? Nobody knows.
• Race Conditions: Two transfers from Alice happen simultaneously. Both check her $100 balance, see that she has sufficient funds, and both proceed. Alice has now spent $100 that she did not have.

CAP Theorem

In 1999, computer scientist Eric Brewer formulated the CAP Theorem, which states that any distributed system can guarantee at most two of these three properties:

• Consistency (C): All servers always show the same data. When Alice's balance changes on Server A, every other server immediately reflects this.
• Availability (A): The system keeps working even when servers crash. If Server A goes down, users can still access accounts through Servers B and C.
• Partition Tolerance (P): The system survives network failures that split servers into isolated groups.

We must guarantee partition tolerance since network partitions are inevitable: cables get cut, routers fail, data centers lose power. This leaves us choosing between Consistency OR Availability.

Traditional banking systems usually choose Consistency + Partition Tolerance (CP Systems). They'd rather shut down than show incorrect account balances.

Social media platforms often choose Availability + Partition Tolerance (AP Systems). They'd rather let you post (even if friends can't see it immediately) than prevent you from posting at all.

The Byzantine Generals Problem

In addition to the CAP Theorem, most distributed systems assume participants are honest: they might fail or disconnect, but they won't actively deceive each other. This assumption breaks down when participants can be malicious.

The Byzantine Generals Problem, formulated by computer scientists in 1982, illustrates this challenge:

You're a Byzantine general planning to attack a fortified city. You have several allied generals positioned around the city, each commanding their own army. To succeed, you must coordinate a simultaneous attack. If some attack while others retreat, the attacking forces will be slaughtered.

You communicate only through messengers, and some generals might be traitors who want the attack to fail. Traitors can:

• Send "attack" messages to some generals and "retreat" to others
• Modify messages from loyal generals as they pass through
• Coordinate with other traitors to maximize confusion

How do you reach consensus on "attack" or "retreat" when you can't distinguish loyal generals from traitors, and you can't trust the communication channels?

This seemed impossible. For decades, computer scientists believed you couldn't build a system that was simultaneously:

• Byzantine fault tolerant (works despite malicious participants)
• Permissionless (anyone can join without approval)
• Decentralized (no central authority)

Then in 2008, someone calling themselves Satoshi Nakamoto proved them wrong.

Bitcoin: the first blockchain

Bitcoin was the first practical implementation of blockchain technology. While the individual components existed before (cryptographic hashing, digital signatures, peer-to-peer networks), Satoshi was the first to combine them to solve the double-spending problem for digital currency.

Blockchain, or a "chain of blocks" as it was called in the original Bitcoin whitepaper, finally created a system that was distributed, Byzantine fault tolerant, and permissionless simultaneously.

The breakthrough wasn't trying to identify who to trust; it was making lying more economically expensive than telling the truth. Proof of Work accomplishes this by requiring participants to spend real computational energy to propose changes. An attacker would need to spend more on electricity than they could gain from an attack.