So you might be asking, "What is a smart contract?" And the answer is, it's like a regular contract but defined by code. But let's take a step back. What is a contract anyway? Normally when we think of contracts, we think of a piece of paper where you sign on the dotted line, but the idea of a contract is a lot more general than that. Fundamentally, a contract is an agreement between two parties, and we agree on and participate in contracts all the time. Maybe it's an agreement to buy a car and pay the lender every month, or maybe we'll make an agreement with our library that we can borrow a book and we'll return it on time or else we'll pay a fee of $0.10 per day. Maybe it's an agreement to pay monthly for fire insurance, and if our house burns down, the insurance company agrees to pay us a lump sum. Or maybe we have an implicit social contract with our friends, that when we go to dinner, we'll all split the bill evenly. Another place where contracts are used extensively is financial products. Stocks are a good example of this. Owning shares in a business gives you certain rights as a shareholder. You might receive a portion of the business's profits through dividends, have access to their financials, or hold certain voting rights, etc. These rights are defined by a company's shareholders agreement, which itself is shaped by the governing laws in a particular jurisdiction. And even then, enforcement of any particular clause depends on the lawyers and judges and lawmakers involved. The idea with a smart contract is that we're totally defining the rules of our agreement in code. We should look at some examples. Nick Sabo, the inventor of BitGold, developed the concept of smart contracts. In his essay titled "The Idea of Smart Contracts," he gives two examples. One, the idea of a vending machine, and two, a car loan with a twist. Let's start with a vending machine. You can think of a vending machine as a mechanical contract between a thirsty buyer and a beverage manufacturer. The buyer puts in a certain amount of money, and the machine dispenses a drink and change if necessary. There's even a rollback mechanism if the buyer requests a refund or the drink can't be delivered. The vending machine acts as an escrow between the buyer and the seller. And although what's at stake is small, there is a moment where the vending machine controls both the drink and the funds. The buyer and seller both agree to this arrangement, because there's an understanding that the machine will act according to its programming and treat both sides fairly. Of course, one weakness of the vending machine metaphor is that the vending machine is controlled by the drink manufacturer. Which, as a buyer, means that there is a chance that the machine will cheat you by taking your money and not dispensing a drink. In smart contracts, however, this asymmetry of trust can be removed. That is, in the ideal smart contract, there's no scenario where one party can defraud the other. You can't inspect the code of your vending machine, but you can inspect the code, or at least the proofs, of your smart contracts. Another example Sabo gives is the idea of a car loan. But in this case, the keys to the car are cryptographic keys, and these keys are initially controlled by the smart contract. The idea is that the terms of the loan are encoded in the smart contract, and the contract gives control of the car to whoever rightly owns it. For instance, the buyer needs to make payments each month, and if he pays on time, he keeps control of the car. However, if the buyer were to fall far behind on his payments, the smart contract would automatically return control of the keys to the lender . On the other hand, if the buyer keeps his payment schedule, when the loan balances paid off, the smart contract will return control of the car to him irrevocably. That is, the smart contract would permanently, cryptographically, give control of the keys to the car to the buyer. To generalize, the key idea here is that any property which can be represented digitally can be managed in code with smart contracts. Another way to view smart contracts is as a board game. When you and I agree to play chess, we're agreeing to a specific set of rules, such as the board will have 64 spaces or a pawn can move two spaces on his first turn. We can model chess in a smart contract and then sit down and play the game. Any move made within this game must abide by the rules. And conversely, any move that's within the defined rules is permissible. When we agree to abide by a contracting code, whatever is logically valid within that code, that's what we'll hold to no matter what. However, a problem with this approach is that many contracts are a lot more open-ended than the rules of chess. And it can be very difficult to define every possible outcome. Traditional contract law is dynamic and has been refined through thousands of years. And this means it can remain robust in the face of complex and ambiguous situations. Nixable is fond of saying that a contract is a program that runs on the brains of lawyers. And the upside is that these brains are very sophisticated. But the downside is that these human executions are non-deterministic. And this idea of contracts as a program is really at the heart of what we're trying to do. When we talk about smart contracts, it's really just code. In Bitcoin, a smart contract might be something as simple as a list of operations that check for a required number of signatures. In Ethereum with Solidity, a smart contract is essentially an instance of an object. Our vending machine, for example, could be a smart contract. From a programmer's perspective, this vending machine's smart contract code is an object. It holds its own state variables, such as the current inventory of the sodas. And it also has methods which can read and write that state. It's early days for smart contracts. And the scope of what contracts can be written in code remains to be seen. But we now have the tools to start experimenting, in code on production decentralized systems. Let's start writing a smart contract in code. [Music]