Commons license.

Your support will help MIT OpenCourseWare

continue to offer high-quality educational resources for free.

To make a donation or to view additional materials

from hundreds of MIT courses, visit MIT OpenCourseWare

at OCW.MIT.edu.

PROFESSOR: I'm excited, because I'm going to get the chance

to co-teach today with--

I would say one of the students, but it's not really

one of the students.

But Larry Lessig has consented to join us in a few minutes.

So I'm going to be breezing through

a little faster than usual.

And then we'll co-teach this.

Blockchain and Money.

Here we are.

We're at smart contracts.

Everybody seems to be coming back,

which is a sign of your interest more than it is in my teaching.

But I thank you for being here.

We made it through the last three classes

together on bitcoin and the basics of that technology.

And in one class, we're going to try

to chew off a bit on smart contracts,

both the technology side, a little bit on the markets,

and then the law that Larry is going to take us through.

And so as I said, I want to start

with a little administrative, because we

are on the sixth class.

I'm going to review a bit about the projects very quickly.

We're going to do smart contracts, the design.

What design features?

Yes, we're going to go back a little bit

about hash functions and Merkle trees but not too much.

DApps, which are basically decentralized applications,

and token sales.

Larry's going to take us through legal issues,

and then we'll sum it all up.

So let me just, real fast on the administrative side again--

class participation, 30%.

That's why we're all here together.

That means, hopefully, reading the assignments

and participating.

About half of you have participated,

so I guess I'm going to go with a little bit more

cold calling starting Thursday.

I'm not going to do a bunch of it today, because Larry

and I are joining.

So you can ease off.

But really be conscious.

If you haven't been participating, try to get in

and join the conversation and discussion.

The two individual write-ups, I think we have seven.

But it's quite possible some of you have submitted already.

It's just meant to be critical business reasoning.

We are in a business school.

To the extent you just summarize some readings,

I'm sure we'll give you a pass on that.

But that's not what I'm looking for.

I'm really looking for critical reasoning

and thinking from a business perspective

of, why does this matter?

What are its strengths or its values

in terms of business reasoning and critical reasoning?

One by the 10th class, one by the 23rd, always before class.

What it likely means is we'll be getting

most of these on the 8th, 9th, and 10th class.

I know how that works and so forth.

And that's OK.

That's OK.

But I'm just reminding you of that.

In terms of the group research paper,

again, Sabrina and Thalita stood up a Google App--

I think it's in Google, but--

where you can go in and team up in teams of three or four.

It's not required to do this by the eighth class next Tuesday,

but I'm strongly suggesting it to figure out

who your teams are and not sort of wait till the second half

of the semester.

And I'd like to encourage everybody

to choose an area for your use case by midway.

Again, you're not going to get graded

if it takes you another class or two to figure it out.

But I just think it's much better if you know your teams,

you know what your use case will be.

If it's not about finance--

one group has already asked me if that's all right.

I just want to know more detailed what it's going to be.

I'm probably going to say yes, but it

needs a little bit of preapproval

if it's outside of finance.

So any questions about the requirements?

I just wanted to--

So the study questions.

Today's smart contracts and basically how they

compare to regular contracts.

And what are the tokens that are used within that ecosystem?

And what are the platforms?

In a very similar sense to the internet, we have the internet.

And then above the internet, you have, you might say,

applications--

Facebook and other applications.

Well, this, too, has a series of platforms

and then decentralized applications

potentially on top of that.

And basically, a quick touch on decentralized applications.

Later in the semester, we're going

to take two sessions on initial coin offerings.

And thus, we're going to talk a lot about token economics.

So this will be just the first taste test,

and then we'll come back to it later.

And then the readings, hopefully, everybody

read through "Smart Contracts."

I thought the Chamber of Digital Commerce,

even though this is almost two years ago,

this paper was a very helpful sort of flavor

for what folks in commerce are thinking

and what developers were thinking.

And I love that Nick Szabo wrote the introduction to it.

And it's interesting to see and question,

why is it that it's two years later,

and many of those use cases are still being discussed

but haven't fully been adopted?

And then the "State of the Dapps,"

and then who are the competitors to Ethereum?

So don't you feel good?

I haven't asked anybody a cold question yet.

And then the optional readings, I don't know.

Did anybody actually go back?

They're optional.

Did anybody go back and read either Szabo's original piece

from 20 years ago on smart contracts?

Oh, a few of you are kind of into that rabbit hole

of blockchain and ether.

Brotish what did you think of-- it's 20 years ago he wrote this

thing on--

Nick Szabo wrote this thing.

AUDIENCE: Actually, I spent more time

on the Ethereum white paper.

PROFESSOR: All right.

So what did you think about the Ethereum white paper one?

AUDIENCE: Yeah, I think it was pretty good.

It gave me a very good overview of the world potential

of the [INAUDIBLE].

PROFESSOR: Yeah.

And what's interesting is even if you didn't do it

for the class and you find yourself more and more

interested in this over the next couple of months or even later,

going back and reading the Ethereum white paper,

it's not highly technical in the first, I don't know,

10 or 15 pages.

It really gives a history of bitcoin.

It talks about distributed applications

and largely written at the time by a 19-year-old, as well.

It's a remarkable thing.

And then one of Larry's colleague, or maybe it's

two of them, but De Philippi paper, as well,

on the regulatory issues.

So let me talk a little bit about smart contracts

and laying groundwork before Larry gives us the law.

A smart contract is a set of promises

specified in a digital form.

I'm going to say four things.

It's just a set of promises in a digital form.

So it's not handwritten out.

It includes protocols.

What's a protocol?

Andrew.

AUDIENCE: Standard operating procedure.

PROFESSOR: Standard operating procedure.

I like that.

Anybody else give me another word for it, maybe?

An algorithm.

So a set of promises in digital form.

But it can include math, basically, if you wish

or standard operating procedures-- if-then statements

and so forth.

And the parties then perform against these promises.

And guess what?

Nick Szabo wrote that in 1996.

And I thought it was still probably the best

definition of smart contract.

He coined the phrase 22 years ago.

He might actually be Satoshi Nakamoto.

Three of the tables in here, you all

voted that it was Nick Szabo.

So I thought that's kind of the best definition

if you've got to just-- kind of a root.

Now, I would also say, however, that smart contracts may not

be so smart.

A lot of people have come to be calling them

dumb contracts that are just algorithms

that perform a function.

So don't think of them as artificial intelligence.

That's another class provided next semester by Simon Johnson.

Think of them almost as just dumb contracts.

And in a sense, they're mechanizing

what might otherwise be done amongst and between humans.

And smart contracts may or may not be really contracts.

And that's why Larry's going to speak to it.

So remember, even though Nick Szabo calls it smart contracts,

they may not be smart, and they may not be contracts.

So a little bit about the technical features.

Remember our three ways we did this.

What are the big technical features that we studied?

I'm sorry to do this.

Anton, what are the three big buckets?

Remember, we took three classes and three buckets

of information.

It can be one to three.

AUDIENCE: Cryptography.

PROFESSOR: Cryptography.

Great.

You got one.

Two other people will give me the others.

So cryptography.

Guess what?

Bitcoin and Ethereum all have the same cryptography.

It's not identical.

But for the purposes of design features,

it has cryptographic hashes, timestamps, block headers,

Merkle trees.

Though Ethereum has more than one Merkle tree, and bitcoin

has one.

And it has digital signatures and addresses.

So everything we talked about three

lectures ago about cryptography, both forms of blockchains.

Anybody want to give me what our second bucket was?

Geramo.

AUDIENCE: Decentralization.

PROFESSOR: Decentralization.

What else did we talk about?

Eilon.

AUDIENCE: Consensus.

PROFESSOR: Consensus.

So again, decentralized network consensus.

Ethereum actually uses proof of work

even there's some talk that Ether

will move to proof of stake.

But it's currently proof of work.

There is a native currency.

It's ETH, or "eh-th," or E-T-H, or Ether, instead of bitcoin.

And it has a network.

The third thing that we talked about, Alpha.

AUDIENCE: Transaction format.

PROFESSOR: Transaction format.

So we talked about transactions and script.

Well, guess what?

Ethereum does not have a transaction script or UTXO.

So that's the one place that Vatalik Buterin, who

designed all of this, said no, had to go a different way.

Instead of transaction inputs and outputs,

there's something called state transitions.

Isabella, ledgers.

What are the two different types of ledgers

that we talked about and set a class to?

AUDIENCE: Permissioned and public.