Lecture 6: Smart Contracts and DApps

What this lecture covers

This lecture moves from Bitcoin to Ethereum and smart contracts, comparing the two systems' cryptography, consensus and transaction formats, then covers decentralized applications (DApps) and initial coin offering (ICO) economics. Guest lecturer Larry Lessig, a Harvard law professor, joins for the second half to explain how existing contract law concepts apply to smart contracts. It follows directly from the prior lecture on Bitcoin's transaction design.

After watching, you should be able to contrast Ethereum's account-based, Turing-complete design with Bitcoin's transaction-based model, describe how ICOs raised funds for platforms like Ethereum and EOS, and explain why a legal scholar argues smart contracts still depend on courts and the state.

Key ideas

• Smart contract: Nick Szabo's 1996 definition, a set of promises specified in digital form, including protocols by which the parties perform on those promises.
• Account-based ledger: Ethereum tracks balances and state transitions rather than the input/output transaction chain Bitcoin uses.
• Turing-complete: a system that supports loops and can, in principle, compute anything; Ethereum's Solidity language is Turing-complete, unlike Bitcoin's script.
• Initial coin offering (ICO): a token sale used to fund a network's development, typically before the network or token has any working use.
• Risk allocation: Lessig's core teaching that contract law's purpose is not to eliminate risk but to assign who bears it, and to provide a system (courts) to enforce the outcome.
• Transaction cost: the cost of forming and enforcing an agreement; smart contracts can lower it for simple, clearly defined conditions but can raise it for contracts that rely on useful ambiguity.
• Obscurity as value: Lessig's point that some contract terms are deliberately left vague because negotiating every low-probability outcome in advance costs more than leaving it to a court later.

Walkthrough

Comparing Ethereum's design to Bitcoin (9:14)

The lecture reviews the three categories used to study Bitcoin (cryptography, consensus, transaction format) and applies them to Ethereum. Both networks share similar cryptographic primitives, and Ethereum currently uses proof-of-work with discussion of a future move to proof-of-stake. The key divergence is transaction format: Ethereum has no UTXO or script system, instead using account balances and state transitions, because Vitalik Buterin wanted a Turing-complete system capable of running arbitrary programs.

Ethereum's origins and monetary policy (13:22)

The instructor describes Ethereum's pre-sale, which raised about 18 million dollars for roughly 72 million ether, with about 10 percent retained by the Ethereum Foundation and early backer Joe Lubin. Unlike Bitcoin's fixed monetary policy, Ethereum's block reward has been changed twice by community proposal, from 5 to 3 to 2 ether per block, which the lecture uses to argue Ethereum is more centralized and socially governed than Bitcoin.

Competing platforms and DApp activity (22:38)

EOS, NEO and other smart contract platforms are introduced as competitors that raised large sums via ICOs, some using delegated Byzantine fault tolerance instead of proof-of-work for higher throughput. The lecture notes that actual DApp usage remained small, with even the most active gambling and collectible applications drawing only a few hundred to a couple thousand daily users at the time.

ICO economics and failure rates (28:45)

The instructor explains how token buyers are effectively speculating on future demand for a not-yet-functional product, using a laundromat token example to illustrate discounting for uncertainty. Citing outside estimates, the lecture reports that thousands of ICOs raised a combined 20 to 28 billion dollars, but a large share failed or turned out to be fraudulent, with estimates of failure ranging widely depending on definition.

Contracts are never fully private from the state (34:50)

Lessig opens by defining a contract as a promise or performance exchanged for a promise or performance, then argues that every contract implicitly involves a third party: the state, which decides which contracts are enforceable, taxable or even legal. Using a vending machine as an analogy for a performance-for-performance contract, he shows that even a fully mechanized exchange carries implied legal terms, such as the product being safe to consume.

Risk allocation and lowering transaction costs (51:04)

Lessig reframes the purpose of contract law as allocating risk rather than eliminating it, and argues smart contracts can be genuinely valuable where they substitute for a weak or absent legal system, or where they lower the transaction cost of contracts that previously were not economical to write, such as automated flight-delay insurance.

The limits of coding every outcome (58:11)

The lecture's final point is that deliberate ambiguity has value in traditional contracts, since negotiating every low-probability contingency in advance is more expensive than resolving rare disputes later through a court. Smart contracts that force every outcome to be specified in code, Lessig argues, can therefore raise transaction costs and block certain kinds of agreements, and questions of jurisdiction, dispute resolution and legal literacy about code remain unresolved.

Before you watch

• Watch the earlier lecture on Bitcoin transactions and script, since this lecture explicitly contrasts Ethereum's design against it.
• Basic familiarity with the terms proof-of-work and consensus, introduced in earlier sessions, is assumed.
• No legal background is needed; Lessig's section builds its concepts from first principles.

Check your understanding

1. What is the core technical reason Ethereum uses an account-based ledger instead of Bitcoin's transaction and UTXO model?
2. How has Ethereum's monetary policy differed in practice from Bitcoin's, according to the lecture?
3. What does Lessig mean when he says contract law's objective is risk allocation rather than risk elimination?
4. In what situations does Lessig argue smart contracts can lower transaction costs, and in what situations can they raise them?
5. Why does Lessig argue that even a fully coded smart contract still cannot escape the involvement of the state?