Lecture 20: Blockstack and Decentralized Applications

What this lecture covers

This final lecture of MIT 6.824 looks at Blockstack, a system that proposes a different way to build internet applications: instead of a website owning a server and a database, users own their own cloud storage, and application code runs entirely on the client. The lecture asks whether this decentralized model can actually work, and uses Blockstack's naming system, built on top of the Bitcoin blockchain, as the running example.

By the end you should understand why building a global public key infrastructure is hard, how Blockstack uses Bitcoin transactions to allocate human-readable names in a decentralized, first-come-first-served way, and what practical problems (performance, access control, key management, willingness to pay) stand between this architecture and everyday use.

Key ideas

• Decentralized applications: apps whose code runs on the user's own device instead of on servers owned by the website, with user data stored in cloud storage the user owns and pays for.
• Zooko's triangle: the claim that a naming system can't easily be decentralized, unique (globally meaningful), and human-readable all at once.
• Public key infrastructure (PKI): a way of mapping human names to public keys so people can verify signatures and encrypt data for each other; nobody had built a widely used general-purpose one before Blockstack.
• Name registration on Bitcoin: Blockstack embeds name-reservation records inside ordinary Bitcoin transactions, relying on Bitcoin's single ordered transaction log to enforce first-come, first-served naming.
• Atlas and zone records: an intermediate layer that maps the hashes stored in Bitcoin to full zone records describing where a user's data actually lives (in practice, Blockstack's own Gaia storage servers).
• Cryptographic access control: since there is no trusted server to enforce permissions, sharing data with a group requires encrypting for each member's key and re-encrypting whenever the group changes.
• Burn fees: name registrations must pay Bitcoin to an unspendable "burn" address, which discourages squatting and spam.
• Key management risk: because only the client knows a user's private key, losing it means losing access permanently, with no safe recovery mechanism.

Walkthrough

Why look at Blockstack (0:11)

The lecture opens by framing three reasons Blockstack is interesting: it attempts a general-purpose public key infrastructure, it is a non-cryptocurrency use of a blockchain, and it proposes a fundamentally different architecture for internet services. Blockstack is a real, evolving system rather than a finished product.

Centralized websites and their downsides (2:12)

The lecture reviews how a typical website works: browsers talk over HTTP to web servers that the website owns, which in turn talk to a database the website controls. This is easy to program and has been enormously successful, but users have limited control over their own data, are locked into the website's chosen interface, and cannot be sure the website (or its employees) isn't looking at their data.

The decentralized alternative (10:18)

Blockstack's proposal moves application code onto the client and moves data into cloud storage that the user owns and pays for, similar to buying an app that talks to a storage service like Amazon S3 or Dropbox. The primary interface becomes a storage-style put/get interface instead of HTML, and ownership of data becomes much clearer. The lecture works through the requirements this creates: general-purpose storage, sharing and permissions, and per-application restricted keys, and also works through the costs: worse performance from reaching across the internet for every fetch, less flexible queries than SQL, and real difficulty supporting sites like eBay or Reddit that depend on data no single user owns.

Naming and the Zooko's triangle problem (29:36)

Blockstack began as a naming project. The lecture explains why decentralized applications need names at all: to locate where a user's data is stored and to find the public key needed to verify that data's signature. It introduces the three properties a naming system might want (unique, human-readable, decentralized) and why getting all three at once is considered difficult.

How Blockstack names work on Bitcoin (37:41)

Blockstack solves this by piggybacking on Bitcoin's single, globally agreed sequence of transactions. Anyone can submit a Bitcoin transaction that also contains a hidden name-reservation record; Blockstack servers watching the blockchain accept the first registration of any given name and reject later attempts to claim it, giving first-come-first-served allocation without a central authority.

Whether the naming properties are actually useful (44:43)

The lecture questions the value of the properties Blockstack achieves: names drawn from one global pool become long and hard to recognize, human-readable names can be misleading since they carry no verified identity, and knowing someone's Blockstack name in the first place is itself unsolved. Alternatives discussed include using raw public keys or falling back to a centralized identity authority.

System architecture: Atlas, Gaia, and private keys (51:49)

The lecture assembles the full picture: Bitcoin holds hashes of zone records, the Atlas layer resolves those hashes to full zone records pointing at Gaia storage servers, and a separate Blockstack browser process holds the user's real private key, handing untrusted apps only per-app keys so they never see the master key.

Open questions about practicality (1:03:02)

The lecture closes by weighing whether Blockstack needs Bitcoin specifically (comparing it to certificate transparency, which can detect but not resolve naming conflicts), whether the architecture is convenient enough for programmers to adopt, whether it genuinely improves privacy over trusting a provider like Facebook, and whether ordinary users would be willing to pay for their own storage at all.

Before you watch

• Familiarity with how Bitcoin achieves a single agreed-upon transaction order is useful background, since Blockstack's naming system depends on it.
• It helps to have seen the certificate transparency lecture referenced here for comparison, since the lecture contrasts it with Bitcoin as a naming substrate.
• No prior Blockstack-specific knowledge is assumed; the lecture builds the system up from first principles.

Check your understanding

1. Why does the lecture argue that decentralized and unique naming are hard to combine with human-readable names?
2. How does Blockstack use Bitcoin transactions to implement first-come, first-served name registration, and what stops a later transaction from stealing an already-registered name?
3. What role do Atlas and Gaia play, and why isn't the full zone record stored directly in the Bitcoin blockchain?
4. Why does the lecture consider access control on eBay-style or Reddit-style applications difficult to implement in a purely decentralized architecture?
5. What happens to a Blockstack user who loses their private key, and why does the lecture see this as a fundamental design tension?