6. Smart Contracts and DApps - VoiceTube: Learn English through videos!

Subtitles section Play video

The following content is provided under a Creative
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.
PROFESSOR: So permissioned and public
are two different types of blockchains.
Remind me your name again.
Stephanie.
AUDIENCE: Balance ledgers and transaction ledgers.
PROFESSOR: All right.
So balance ledger and transaction ledger.
You can keep a list of transactions.
And this goes back thousands of years.
This is not a blockchain.
Or you can keep balances.
Bitcoin is, in essence, a transaction ledger.
Ethereum and many of the other smart contract
platforms are balance ledgers.
There's a lot of technological and mathematical reasons why,
which I'd be glad to do in office hours.
But because of that, when you're moving
from one set of balances, like--
is it Bo?
Bo has $100 at Bank of America to Bo having $101.
You need to have a transition.
It's called a state transition, which would mean add $1.
So Ethereum is account based and, in fact, doesn't even
have one programming language.
There's six or seven programming languages
you can write in, for those who are so inclined.
So I'm going to go through really quickly my analysis,
and many other people's, but my sort
of rendition of the difference between Ethereum and bitcoin.
But stop me if there's a question.
So the founder.
There's actually a founder.
The mythology around Vatalik Buterin
might not be as great as Satoshi Nakamoto.
But a 19-year-old journalist who was writing about bitcoin for--
was it Bitcoin Magazine, if I remember where he was writing--
said, we can build something on top
of it using Nick Szabo's thoughts about smart contracts,
about six years after bitcoin.
He made it Turing complete.
Does anyone want to remind the class what Turing complete is?
Did I see a hand up?
Yes.
Bold of you.
What's your first name again?
AUDIENCE: Alana.
PROFESSOR: Alana.
AUDIENCE: You could write pretty much any-- well,
you can write loops, but you write any kind of program,
like any form of logic is expressed.
PROFESSOR: So Alana says Turing complete
means you can write loops.
But what that really means for the business crowd is it
means you can write a program to do just about anything.
It's highly flexible.
I'm sure the technologist in here will say, well, maybe
there's something you can't do with it.
But the point in what Vatalik said
is we shouldn't just limit it to a scripting language that
was non-Turing complete that can just
move a little bit of peer-to-peer value around,
that he wanted to do basically a peer-to-peer virtual computer
that could move code and complete code.
And over the years, it's being able to be
written in a bunch of things.
But Solidity is the main program language.
And thus, it's account based rather than transaction
based because of the loops.
If you could loop and be Turing complete with transactions,
there is a vulnerability in attack factors
that he made it account based.
The transactions are stored in Merkle keys.
But guess what?
If you were really interested and wanted to learn everything
about Ethereum, there's at least four key Merkle trees
that get summarized up into the block headers.
There's the transactions, which, in essence,
aren't transactions.
They call them state transitions.
There's the state itself, something
called storage, which is really related to each one
of the individual Ethereum accounts, and then,
believe it or not, actually, receipts.
There's written records of receipts from every state
transition.
So there's a lot more complexity inside the Ethereum blockchain.
They run about 14 seconds a block instead of 10 minutes.
And that change is a bunch of the economics.
Proof of work, for some reason, which others can study.
Vatalik decided to use a different hash function.
It's still based on elliptic curves, I think,
but a different hash function.
What about the economics?
Well, it's called ETH or E-T-H. It's programmed in such a way
that you can't use ASICs, purposely
makes it that mining is more decentralized,
and you don't have the big factories.
The entire hash community, the entire mining community,
is much smaller.
In fact, I think it's about--
what would that be?
200,000 times smaller.
There's 260 terahashes per second as of yesterday.
And the bitcoin mining community has 54 exahashes.
That means lots more computers, a lot more electricity,
a lot more gnashing of teeth about resources.
Bitcoin started in January of 2009.
And nobody owned any bitcoin, whereas Ethereum started
with a presale and an ICO, which we'll be talking about,
about 72 million Ethereum.
Vatalik wanted to raise money he was maybe 19 years old.
He looped in with a venture capitalist
from Canada, Joe Lubin, who now runs ConsenSys.
Lubin took about 10% or 9 and 1/2% of the offering.
They put 9 and 1/2% in a foundation
called the Ethereum Foundation.
And the other 80% was sold to the public for $18 million.
We'll talk later in the semester as
to whether that was really a securities offering.
I've publicly said I think so, but that was in 2014.
And in 2018, the Securities and Exchange Commission
has said regardless of why it might have been in '14,
it's now sufficiently decentralized
that we'll consider it not a security.
But in essence, they raised $18 million
and were off to the races.
Oh, and the 10% that Joe Lubin kept, if he still owned it,
would be worth about $2 billion now.
But he probably sold some of it along the way.
There are block rewards.
The monetary policy in Ethereum, if you remember,
it splits every four years.
There's the block reward splits.
Ethereum was set up that it was five Ether per block.
And then a year ago, they just announced
they were going to change the software
to three Ether per block.
And a month ago, they announced they're
going to change it to two Ether per block.
So the monetary policy of bitcoin is said to be immutable
and fixed forever.
But I would say that because Ethereum supposedly was fixed
and now, twice, they've changed the monetary policy,
there is a form that if all the miners and all the computer
nodes decide, they can change the monetary policy.
And Ethereum has shown that.
I think Ethereum's a bit more centralized
and has more leadership, because Vatalik Buterin
is an actual human who is willing to disclose who he is.
And he still has the sort of founder following.
And Satoshi Nakamoto went--
he ghosted all of us, in a sense.
And so thus, it's in some ways socially just more
decentralized.
And then fees are voluntary in bitcoin.
They're a necessary part to channel everything.
Emily.
AUDIENCE: Going back to monetary policy,
in practice, what does it actually mean
for a difference between bitcoin and Ethereum that it's fixed
but changing versus staying at the same rate?
PROFESSOR: So Emily asks, what does it mean in practice?
In practice, bitcoin has a much slower growth rate or inflation
rate, which is currently, if I'm not mistaken, about half.
What's that?
About 4%.
But it's about half of the inflation rate at Ethereum,
which is running in the 7% range.
Every one of the 1,600 live tokens
that are right now Ott coins have
separate monetary policies.
And one could do a complete economic study
about what it means.
But in terms of Ethereum versus bitcoin,
Ethereum has a higher inflation rate.
And secondly, because they've shown
that they can form some consensus and change it,
I think it sends an interesting question
into that ecosystem as to how hard a monetary policy versus
a more human-based, flexible monetary policy.
Hugo.
AUDIENCE: So is it that the core developers of the Ethereum
blockchain decide?
I'm not familiar with how they make that decision to change
the monetary policy.
PROFESSOR: So the core developers of any coin
can propose to the various mining and nodes
to make a change, including the monetary policy.
Even in bitcoin, the monetary policy
could change if there was a proposal
from the core developers.
In the Ethereum case, they have done that twice.
The core development of Ethereum is
highly concentrated around the Ethereum Foundation.
ConsenSys, the company that Joe Lubin runs,
has some normative social standing in the community,
as well.
But it's been part of proposals.
And in reading the proposals, it goes back to Emily's question.
The core developers have said we should bring down the inflation
rate.
There's an active advocacy to bring down the inflation rate.
AUDIENCE: So you go by updating your node software?
PROFESSOR: Yes, in essence.
And it could lead to a hard fork, I believe.
So that's the background.
Let me just talk about the platforms.
We know about Ethereum.
We've just chatted about it.
Its actual current market value is $22 billion.
While we're not going to spend a lot of time in this class
this semester about market values,
I thought it would give you a sense
of how people think about it.
The other five that you did some reading about.
EOS, whose market value is about $5 billion,
is so new, because they just finished an initial coin
offering in July.
And they just went live in July.
But they raised $4.2 billion.
So my estimate, my prediction, is EOS is going to be real
and going to be around.
They've taken $1 billion of that $4.2 billion
and set up a Kickstarter sort of venture firm
literally so that they could maybe support some of you.
You could be knocking on the EOS venture firm's door
and saying fund me.
I've got a great idea.
And they'd have one condition, amongst others.
You'd have to use EOS as the platform.
So it's a self-reinforcing business model.
NEO is the other big one that I'd mention,
which was started two years ago out of China, a lot of people
think with the backing of the Chinese government.
Even if not officially, certainly with the verbal
and help of there.
Some people think of it as the Ethereum of China,
but it does use a different proof of work.
And those are the main ones.
Ethereum Classic is there because there
was a hard fork off of Ethereum after the DAO circumstance.
Any quick questions about the platforms?
And NEO and EOS are thought to be
a little bit higher throughput and faster because
of the different proof of work that each of them have.
So maybe they're more scalable than Ethereum long term.
AUDIENCE: [INAUDIBLE]
PROFESSOR: What's that?
AUDIENCE: [INAUDIBLE]
PROFESSOR: So Hugo is pointing out that neither one truly
use--
NEO and EOS truly use decentralized proof of work.
They use a delegated Byzantine fault tolerance.
This was from the reading.
We're not going to spend time on it.
But there was 12 use cases that the Digital Chamber of Commerce
came up with.
And we're going to study most of these, not all
of these, later in the semester.
Please tell me, Sean.
AUDIENCE: So from the growth perspective
across different platforms, do you
support multi programming language platforms as opposed
to single-language programming platforms?
Which one do you think has more potential?
PROFESSOR: The question is, do multi-language platforms
have more potential or less than single-language platforms?
I haven't done a real study.
My gut tells me that there's some trade-offs.
So a multi-language platform probably
allows for more development of apps,
just like on the internet, if you
can have more app development.
Though if you have only one single language,
you might have fewer vulnerabilities,
vulnerabilities either to attack or coming down.
So there's probably some trade-offs.
And I'm more into democratizing capital markets,
so probably my biases would be to the ones that
have multi-language potential.
But I can't say for sure whether it will necessarily
win, because there are some trade-offs, if that helps.
So we'll take a view of all of these later in the semester.
But what's interesting is none of them have yet taken off.
And in fact, if you look at the dApps today,
the decentralized applications which
run on a decentralized blockchain,
they generally have native tokens.
They don't have to have a native token, by the way.
You can run a dApp based on Ether.
You could run a dApp on an underlying token.
But they almost always have their own native token.
This is a list that I pulled off the internet yesterday
similar to your reading.
These are the actual dApps that are working the highest--
gaming, gambling, exchanges, and finance.
The most active dApp is a gambling site that
only has 1,500 users a day.
In the last 24 hours--
I pulled this down yesterday, so that was a Monday.
So this would have been Sunday night to Monday night.
There was only 1,500 users to the most active gambling site.
CryptoKitties that some of you might know
had 418 users in those 24 hours.
These are not economy wise use cases.
You would see numbers that were hundreds of thousands.
Or if it's like Facebook, there's two billion members.
And probably in any 24 hours, there's a half a billion
to a billion people that check in on Facebook.
So these are pretty limited at this stage.
But it has led to something called initial coin
offerings, which we're going to study
a bunch later in the semester.
Initial coin offerings raise money to build a network.
But the tokens are usually issued before they're usable.
And a token is some native currency
to be used on a network.
The development is open but highly centralized.
The promoters usually give themselves some skin
in the game or some vig.
In the Ethereum initial coin offering,
the Foundation kept 10%.
Joe Lubin kept 10%.
And the other 80% was sold to the public.
But some keep 60% or 80% for themselves.
I mean, it's a whole wide range of economic incentives
and models.
And the tokens are usually fungible and transferable.
And thus, you can sort put them on an exchange
and try to sell them and promote them.
And again, we're going to come back.
But I thought if we're talking about smart contracts,
they tie into initial coin offerings.
Daniel.
AUDIENCE: If the tokens aren't functional,
what goes into their evaluation?
PROFESSOR: That is an excellent question.
Daniel says, what goes into the valuation of something
that is not functional?
And there are many things that go in.
Ultimately, it's in the anticipation
of the potential profit and appreciation in the future.
So if you were just to have a laundromat,
a corner laundromat here in Cambridge,
you probably would only pay for the laundromat token what
you thought the value was to do your laundry, $0.75 or whatever
the--
frankly, I don't know what the tokens go for in Cambridge.
You're going to tell me what a laundromat token goes for?
But if it's prefunctional and the laundromat has not
been built yet and you have confidence it will be built,
you'll probably discount back.
You might pay $0.50 instead of the $0.75, ultimately.
If you think it's going to be a really popular laundromat
and it's going to be the place to be seen by all MIT students
and you think that token might one day be worth $5,
then you're starting to speculate
on the community's interest.
So these tokens, if you really believe in them,
you're trying to pay for what others will
pay for them in the future.
And the economic equilibrium would be discounted.
So thus, you're buying it because you think
they'll appreciate in value.
AUDIENCE: Couldn't you make an argument sort
of following numismatics, how people
assign some aesthetic value to physical coins?
So, too, you could have an impulse
beyond speculation [INAUDIBLE].
PROFESSOR: Your first name is?
AUDIENCE: Isaac.
PROFESSOR: Isaac.
Isaac says maybe there could be a numismatic or other value
to it.
It's possible.
I mean, certainly, CryptoKitties caught
into the whole collectibles wave.
Let me try to wrap up so that I can hand it off to Larry.
So there's been $28 billion raised
per one website, Elementis.
Others that track it think it's only
between $20 and $25 billion.
There are no official arithmetic and no official records.
But the $28 billion raised in initial coin offerings,
this is a cut of a neat video that I just
took the last slide of from Elementis.
You can watch it in a minute and a half.
And over the years, it's geographically
dispersed with blue being Oceana, Australia,
and so forth, green being Asia, North America being orange.
But the biggest ones, EOS raised $4.2 billion.
Telegram, $1.7 billion and the like.
These are not small figures.
There's been at least 4,500 proposed initial coin
offerings.
Many of them didn't raise any money, but over 2,000 to 3,000
have raised money.
I'm going to use the 3,000 figure.
Less than half of them are even live today.
There's one study that shows that 59% fail
within the first nine months.
There are other studies that say between 1/4 and 3/4 are scams.
Christian Catalina here has a study
which I think is probably the most valid and reliable,
which says 25% are scams or frauds.
Statis has one that says 80% might be.
AUDIENCE: You said 59% fail.
Can you talk more about what "failure" means here?
Does that mean it just goes to 0 or there's
a technological deficiency?
PROFESSOR: Can I hold that until later
when we're going to dig into these in the class?
But broad definition of fail, so it's not just technology.
It means that you can't even find the website anymore.
They took your money, and they ran.
Or they still have a website, but it's not live.
It doesn't seem like there's a development team any longer.
So multiple definitions of failure.
So that brings us to legal issues.
And as Larry brings up his computer,
let me just introduce our guest lecturer, Larry Lessig, who's
an esteemed Harvard professor of law.
He was at Stanford.
He started something called the Center
for Internet and Society.
You clerked for Justice Scalia, so you
must have some real views on what's going on this week,
then.
And this incredible appellate court judge, Posner.
And Larry also-- his first of--
whatever you're up to, 9 or 10 books now?
LARRY LESSIG: It's something.
I don't know.
PROFESSOR: But his first was code and the law
that I referenced in our first lecture.
Larry is going to take it away.
LARRY LESSIG: OK, great.
So I'm really happy to be able to say
that I've taught business school students at MIT.
I mean, I'm a tech wannabe.
But I have never been allowed to be officially here,
so this is exciting.
But what I want to do is really address
what I've experienced as misperceptions
about the nature of the law as it
might interact with the issues around digital contracts.
So I teach contracts.
Contract law is one of the subjects which I've taught
since I started teaching.
And so I want to frame four points for you
about how to think about contract law
as it relates to these potential digital contracts.
But the first thing to do is just
to make sure we understand we're all
talking about the same thing.
OK.
So here's what the core of contract law
teaches us contracts are.
Contract is a promise or performance
given in exchange for a promise or performance.
"Given in exchange for" is really critical.
That's the quid pro quo that's sometimes
referred to as the consideration for the promise.
But notice here, this is mapping out
four different possibilities.
You can have a promise in exchange for a promise.
I promise to pay you $10,000 if you promise to sing
an opera for me tomorrow.
Or it can be a promise for a performance.
I promise to pay you, Andy, $5 if you sing a song for us now.
So it's the performance I want.
I don't want a promise from him, because we know
what Andy's promises are worth.
Or it could be a performance for a promise.
I'll sing if you promise to pay me after I'm done.
Or the really interesting one for our purposes
is a performance for a performance.
I'll sing if you pay me $5,000.
I didn't want a promise from you, because I don't trust you.
You're business school students.
So I just want the money.
But I'm not promising to do anything.
I'm actually going to do something for you.
Now, that's the one that we're going
to think about in the context of digital contracts.
Oh, I'm sorry.
Let me just fix one thing here.
Actually, I was going to make three points,
but then I decided I was going to make four.
So let me fix that.
Four points about contracts.
So the first point about contracts,
so think about this case.
All right.
It's not quite digital, but it's a physical contract
machine in the sense that it's a performance for a performance.
If you drop a dime into this machine,
then out will come Dr. Pepper or something else.
OK.
So there's no promises involved.
And we understand there's a mechanism that's
to produce this result. And obviously, these
have been here for a long time.
And these mechanisms provide real value,
because to the extent you don't have to hire somebody
to stand there handing out Dr. Peppers,
you can lower the cost of delivering Dr. Peppers
and increase the market for Dr. Pepper.
So this is the motivation-- lower
the transaction costs of engaging
in a particular kind of contract, which
is performance for performance.
Now, when you look at that contract,
you should ask yourself, what are the terms of this contract?
All right.
So some of them are express, and they're pretty obvious.
So this says $0.10.
It says if you pay $0.10, you will get the Dr. Pepper.
Or that's what you kind of expect.
There's a great cartoon I couldn't find where you come
to a machine that says deposit $0.50.
Deposits $0.50, and the light comes on.
It says, thank you very much.
Right.
So you think you know what this contract is,
but that joke hints that maybe you don't
know what that contract is.
But the express terms of the one we expect
go with a statement, the machine.
But then there's a whole bunch of implied terms.
So one implied term if this machine is in the United States
is that when you take the Dr. Pepper out and you drink it,
it's actually going to be safe to drink.
It's actually going to be Dr. Pepper.
It's actually not going to make you sick.
And none of that is written on the Dr. Pepper machine.
That's instead a term, a contract term,
that gets created by the law and gets imposed or wrapped
around the delivery of that drink.
OK.
That's their first point.
The second point is to think more
about what these implied terms imply.
Because if these implied terms are implied by a legal system,
then that means the legal system has
an interest in your contract.
Legal system is not undisinterested
in your contract.
So we should always think that our contract
is going to have two parties.
We call them the promisor and the promisee.
I've told you we've had contracts
that can be performance.
"The performancer" isn't really a word.
But let's just say promisor and promisee.
But there's always a third party,
which is the state, who is in the middle of the contract
in the sense that the state will police many contracts
and decide whether the state likes the contract or not.
And if the state doesn't like the contract,
then the state won't enforce the contract.
Or the state might actually punish you
because of the contract.
So for example, the state cares about the kinds of contracts.
You can have contracts for the sale of tables.
You can't have contracts for the sale of people.
But you can sell dogs for reasons I can't understand.
But the point is we are deciding which type of things
can be sold and which kind of things can't be sold.
The state cares about the effect of the contract.
If the contract is to render your corporation
vulnerable to bankruptcy, the state
might have an interest in deciding
whether that contract will be enforced
or not or whether it'll be allowed or not,
whether it's permissible under bankruptcy laws
to engage in that contract because of the risk
that it's going to create.
The state's going to care about the terms of the contract.
So if you're selling your labor in a state with a minimum wage
law, the state's going to care.
Does the term that specifies your wage equal
or exceed the minimum wage?
And states can obviously care-- the most important thing
for the state is whether and how the state
taxes the transaction in the contract.
So when does it tax the transaction?
What is the event that's going to manifest it?
And of course, the contract can try
to play with that sort of deal with whether it will be taxed.
And the state will care about how the contract deals with it.
OK.
So the point is to fight against the first real bias
that especially, let's say, tech people
and maybe business tech people bring
to the idea of contract law, which is that contracts are not
about the state.
They're about private parties.
That's not true.
They're about private parties and the state.
And the state is always going to be there.
Now, so if I say to you, I'm trying
to sell my parents' house.
I can't sell it.
So if I say to you, I'll offer you
$10,000 to anyone who will burn down my parents' house.
You're trying to accept that contract.
You're raising your hand, so you're trying to accept.
I want to say officially it's a joke so nobody gets
any uncertainty about this.
Now, you're going to ask a question, because I
didn't want you to accept.
Because if you accepted my offer, then that's it.
I'm stuck.
So now it's clear it's not really an offer,
and I can ask you a question.
AUDIENCE: So you said contracts cannot be between two parties.
They have to be between two parties and the state.
LARRY LESSIG: No.
So let me say it more clearly.
Contracts always have the state present,
so it's always between two parties
or three parties or four.
So you and I enter into a contract.
Not this one, but another one.
But the state is in the room and deciding
whether the state's going to allow the contract to happen.
So most contracts, the state doesn't care about.
But some contracts, the state's going to say,
hell no, we're not going to allow it, like this one.
If you didn't get that notice it was a joke
and you thought I was serious and you went and you
burned down my parents' house so that we could get the insurance
and not have to worry about selling the house,
and then you came to me, and you said, OK, pay the $10,000.
And I said, it was an obvious joke.
And you went to a court, and you said, force Lessig
to pay the $10,000.
The court will say this is an illegal contract.
I'm not going to enforce this contract.
So my point is the state, in a certain sense,
is the censor of this contract.
The state is in the room when we make this contract.
And the state's judgment about it
will decide whether we enforce it or not.
Is that clearer?
AUDIENCE: So you're not saying the state has to be there.
LARRY LESSIG: I'm not saying the state is technically
signing the document.
But I'm getting you to recognize the fact
that the contract is valuable to the extent it's enforceable.
And the state is the essential agent in enforcement
in the real world.
AUDIENCE: So I guess that's my question, because it seems
like nowadays, we can have contracts where the enforcement
is not the state.
I can put a contract out there that says,
hey, if you can factor this number,
give me the prime factors of it, I'll give you 10 Ether.
LARRY LESSIG: Yeah.
And what I started with when I was showing you
this picture was to say, actually, that's
been true for a while, right?
So in what sense is the state here?
Well, the state is here if when you put the dime in
and you get the drink out and the drink doesn't have Dr.
Pepper but it has gasoline in it,
the state would come in and say, whoa, wait.
You've breached the implied term that said
that this was safe to consume.
So the state is in this contract, too.
And so what I'm trying to lead to or get to the place
where we say, is there ever a place where the state is not
there, which is what I think your blockchain-like invocation
is.
So that's a question we're going to get to in a second.
Here's another contract.
We'll offer you $50,000 to lobby Congress to pass HR102.
This contract looks pretty normal to us.
You can imagine lobbyists have a contract like this
all the time.
In fact, in the middle of the 19th century,
the Supreme Court ruled this contract
was an illegal contract.
You weren't allowed to hire people to lobby Congress,
right?
So again, the background norm of what
is appropriate or not for the contract controlled what type
of contracting was allowed.
OK.
So that's about the type of contract.
But then think about the terms of the contract.
And so now, I want to get you to recognize
the way in which the terms that the law wants a contract
to have can be defeated or not by technology.
And the way I'm going to get you to think about that
is to think about not contract law but something that
will create the intuitions I want you to have.
Think about copyright law.
Everybody knows copyright law, right?
I hope you know something about copyright law.
So copyright law is a basic contract with the state.
But the state says, if you create something,
then you're going to get an exclusive right to it
or exclusive rights, a set of rights--
an inclusive right to copy, an exclusive right to sell it,
exclusive right to make derivative works of it--
for a period of time--
and in America right now, that's your life plus 70 years--
subject to fair use, meaning the law
says you can't control every use of my copyrighted work.
If you want to take a book of mine and quote a section
and write a review that says, see how idiotic Lessig is?
You can do that.
And I can't wrap the book in a contract that
says you're not allowed to quote it for purposes of criticizing.
I'm just not allowed to do that.
So copyright law, imagine this bundle of rights
that it was offering.
But now imagine something called DRM, Digital Rights Management.
All right.
So DRM is a set of code that we can wrap copyrighted material
in in the process of making it available to others
across networks and whatever else.
It's pretty trivial to see the way
DRM could, in effect, destroy the limitations on the term.
You can wrap it, encrypt it, make it
so that my ability to control it will be my ability
to control it, conceivably, as long as machines are running.
If it's a Microsoft-based system,
four years later, it won't be workable.
But the point is, in principle, it could be forever.
Same thing with fair use.
You can imagine it being wrapped in a way that
disables the capacity to engage in fair use.
So I make tons of presentations all the time
where I need to capture video.
And I was astonished to discover the latest
round of this operating system basically
makes it incredibly difficult to rip
video for the purpose of capturing even two
seconds of it.
So if you have a video program that is capturing your screen,
this operating system will now disable it
for any period of time that you're
trying to capture the screen.
They've built the technology so that, now, there
is no capacity, technical capacity,
to engage in fair use of copyrighted
material on the Apple platform.
Now, you might say, why should they
be allowed to do that if the law intended
that the contract gives you the free use of fair use?
Why should they be allowed to do that?
But that's the battle that's been going on about DRM
ever since the beginning of the beginning of copyrighted
work on the internet.
So my point is to get you to realize
the way the code becomes part of the law of this contract.
And you have to ask yourself the question
whether that law is respecting the law of the sovereign,
the law of the jurisdiction.
So when Apple and Disney get together
and they sell this technology and they
sell movies across the iTunes platform
that make it practically impossible--
there's not even code.
I mean, if you go out there and you look,
you can find everybody who says, yeah, with this version,
nobody's yet found a way to break it.
So right now, we're in a world where, right now, it's
not possible for me to capture three seconds to put
into a presentation.
And the issue that raises is, to what extent
is that consistent with copyright law
if the technology now disables you
from doing exactly what copyright law wants?
So this is the trade-off to think about,
the relationship between the policy that the law wants
and the policy of the technology.
And there's no reason to believe the policy of the technology
will always be consistent with the law.
And to the extent it's not consistent with the law,
it challenges the law.
It says to the law, OK, come out and get me.
Now, that obviously is implicated
in the context of smart contracts,
because the biggest fear about smart contracts
is that they enable a kind of transaction that can hide
from the policy of the law.
So the question for the law is, what will you do to step in?
And this is, I think, where your question was going.
How does the state appear in the middle of that contract?
But let's take one more step before we get to that.
OK.
That's the second point.
Here's the third point.
There's often this intuition that, especially technologists,
people have about what the particular aim of contract law
is.
So in the very beginning of me writing
about the law of cyberspace, somebody from MIT--
I won't name any names-- it wasn't Andy--
showed up at the Harvard Law School and said,
I've solved the problem of contract law.
I said, what do you mean?
He said, I have a system that will eliminate risks
in contracts.
And he was really disappointed when I said, you know,
the objective of contract law is not to eliminate risks.
The objective of contract law is just to allocate risk,
to figure out who has the risk, so each of us
can figure out what to do in light of the risk.
So if I say I will buy 10,000 bushels of corn
from you at $350 a bushel--
turns out that is the price of corn right now.
He always looks up things on the internet.
I figure I should look it up before I present it.
So $350 is the price of a bushel of corn right now delivered
September 1.
What that's basically doing is it's allocating
the risk of the price of corn.
So if you're a farmer and you don't
want to face the risk the price of corn is going to fall to $3,
you enter into this contract.
If you're a buyer, you accept this contract.
But if the price of corn falls to $3,
well, you're out of luck.
So the point is it relocates the price change,
reallocates the risk of price change,
also reallocates the risk of delivery.
So if I've got all this corn, I can place it in a certain place
to shift the risk of delivery so that, once again, I
use the contract to shift my risk of storage
or my risk of delivery and you on the other side.
So the objective of contract law, number one,
is risk allocation.
Number one.
But allocation matters only if--
trying to say only if for me--
only if there is a system to process
the breach of a contract, only if you've got a technology,
let's say, for processing the breach.
So if I have a contract with you--
10,000 bushels of corn, $3.50, on September 1--
and you don't deliver, that's a breach.
My risk has only been reallocated
if there's some way for me to enforce
the contract at that point.
So it requires the system.
And the system we ordinarily take for granted
is a legal system.
And I say we take it for granted,
meaning some people can take it for granted,
like people in well-developed legal contexts.
But that's also to emphasized other people can't take it
for granted--
so for example, people in developing worlds.
They can't take the legal system for granted.
They can't assume that if the contract is breached,
they go into a court and say, enforce the contract
or give me damages.
Or if you've got a contract between somebody
in Rwanda and somebody in Alaska,
then there, too, there's a question
of whether we've got sufficient infrastructure to develop.
So the point I want to emphasize at the end
of this little intervention is to suggest
that this fact that it takes for granted the system
of enforcement shows the real potential benefit of this class
of contracting devices.
Because if we think about this as a representation
of a well-developed legal system and we
think of first-world countries as having those
and we compare third-world or developing world
countries, which don't have these well-developed legal
systems, you might say that first-world countries are
better off relative to third-world countries,
because they have the legal infrastructure
to enable this risk allocation that will enable
all sorts of market transactions to happen which otherwise
wouldn't happen.
But if we imagine infrastructure like
blockchain-like infrastructures or Ethereum
infrastructures to enter the mix,
providing a technical infrastructure that
doesn't require judges and lawyers but just requires code,
then that can substitute for the legal infrastructure,
provide the infrastructure the contract needs
at a much lower cost, and thereby enable
people to contract who otherwise wouldn't rationally contract,
because they could never count on the infrastructure
of the legal system to deliver what they need.
OK.
So the point is this picture is trying
to say that one key value of these technologies
is that they will be a substitute for a failed
legal system or a legal system that's not yet developed.
They will provide the infrastructure
of a legal system or the legal systems.
AUDIENCE: How can they really do anything?
Because you can't make that contract like,
I will pay you $3.50 per bushel on September 1 in Ethereum,
because you're making a statement about the real world.
The Ethereum blockchain cannot verify that I gave you
the bushels.
LARRY LESSIG: OK.
So I've got two slides to get to your example [INAUDIBLE]..
OK.
AUDIENCE: There's ways to do it, but they're very risky,
I should say.
LARRY LESSIG: Right.
But let's bracket it for just--
I'm not sure if it's two, but it's n slides.
But n is less than 100, I promise.
So just hold one second, OK?
So if you say that one function here
is to substitute for a failed legal system,
that suggests that the other key opportunity here
is to enable contracts where the transaction costs right now are
otherwise too high.
So this is a key opportunity to think of places where
if you can lower the transaction costs of the contract,
you will enable a contract which otherwise
can't exist right now.
So I'm on a scientific board for an insurance company.
So I was meeting the president last week.
And he was all excited about a new product which
they were investing in, which was going to provide
flight delay insurance.
And this product was going to be completely blockchain driven.
And this is what I'm trying to get to your point.
It would trigger payments in a completely automatic way based
on the information that's being reported
from the n different sites that are reporting information
about flights.
So I buy the contract.
It says, if my flight is delayed more than an hour,
I get paid $200.
And automatically, as he put it, it's
a no-touch product, by which he meant
no human needs to touch this product for this contract
to be enabled.
It's a kind of product that never
would have been available before, because the transaction
costs of engaging it were way too high.
But now that we've lowered the transaction cost
and have an infrastructure of trust, which
is what the blockchain is providing here,
there's a huge market that now is
available for a contract that otherwise just
wasn't there before.
Now, that market depends on making a couple assumptions.
You're not saying that there's 100% certainty
that everything in that market is working
the way it's supposed to work.
But the point is you don't need 100% certainty
for the vast majority of these kinds of contracts.
If it gets it wrong every once in a while,
that's good enough for government work
or good enough for airplane work.
And so that's going to be sufficient to enable
the market, recognizing that even in the legal system
market, guess what?
It doesn't always get it right either.
But it doesn't always enforce the contract well either.
In fact, the costs are much, much higher
to fail in the legal system.
OK.
So two kinds of transaction costs.
One system transaction cost suggests
that where you have less developed legal systems,
the blockchain is going to provide a real opportunity,
because you're going to lower the transaction
costs for those systems.
And the other is just contract transaction costs.
There'll be a huge explosion of markets where,
right now, the contract transaction costs are so high,
and we can lower them and thereby enable
a certain kind of transaction that
otherwise wouldn't be there.
OK.
Final point I want to make.
The other thing technologists always love to say
is the great thing we will do when
we do contract technology is they'll
solve the clarity problem.
Every term will be perfectly clear.
Because you write those contracts out,
and there's all sorts of ambiguity and vagueness,
and it's a total mess.
But when we've coded all of our contracts,
our smart contracts, then we'll have
perfect certainty for every single outcome,
and that will be great.
And the point I want to suggest to you
is that, often, obscurity is a real value.
Obscurity is what you want, because here's a way to see it.
So imagine this is a decision tree.
And it's really small, because I just
stole it from the internet.
And it doesn't have anything to do really with what
I'm talking about here.
But imagine a really complicated decision tree
like this, which is to represent all the possible things that
could happen with our deal.
So I want to buy the house.
But what happens if the house gets hit by a meteor?
Or what happens if you go bankrupt?
All of these possible outcomes.
And in principle, we could say we should be negotiating
every one of these blue dots.
We should be saying, what happens if this happens?
OK, then this is what you get, and this is what I get.
What happens if that happens?
What you get, what I get.
OK.
So imagine this blue dot here has
a 0.002% chance of happening.
So you know the chance of that happening is practically zero.
And so what's the reasonable amount of time
you should spend negotiating that term?
Zero, right?
Especially because if this term is something
you know he's really worked up about
and you could never come to an agreement about that term,
it would be ridiculous that the whole contract fall apart
because of this 0.002% possibility.
So what contracts do all the time
is they create these fuzzy or vague
or ambiguous places as a gamble.
It's like, OK, we'll go forward.
We're going to just gamble that this 0.002% outcome won't
happen.
Most of the time, in fact, you can work out how often
it doesn't happen, right?
So most of the time, that would be just fine.
And if it turns out to happen, then what we'll do
is ask somebody--
namely, a judge-- to figure that term out.
We'll say, what should that term be interpreted as?
It was ambiguous, so what should the answer be?
And the judge will look at it.
And judge will say, well, it's fair that you win or he wins.
So the point is there are many times
when you ask the question, should you
negotiate a term ex ante?
And the answer to that question is no.
And in those contexts, an ambiguity
is a way to negotiate it ex post, meaning after the fact,
ex post, by using the court.
So as we think about these digital smart contracts,
this is why smart contracts are referred to as dumb contracts.
They're smart contracts for the equivalent
of dropping a dime in and getting a Dr.
Pepper, the sorts of things where the possibilities are
really small and narrow, or, like my CEO was really excited,
is your plane late?
Yes, I get $50.
No, I don't.
Things where it's relatively clear.
But there's a really important conceptual question
about what happens when we're trying
to use them for the kinds of contracts where what we want
is ambiguity.
Because if the very terms of deployment of the platform
demand specifying all of the outcomes in this tree, then
your basic thing is a whole bunch of contracts
you're just not going to be able to have in this space,
because the cost of specifying that tree will be higher
than the benefit of those contracts.
So it's a weird sense in which, on the one hand,
I've said to you that this technology can
lower the transaction costs of contracts.
But for this kind of contract, it
can actually increase the transaction costs of contract.
Because for this kind of contract,
if it reveals the ambiguities we need to negotiate about
and those negotiating ambiguities are just
too costly for us to negotiate, then
it's going to block us from having that contract.
It forces us to see the 0.002%, and you and I
have to come to terms on it.
And we don't yet have a good way to fake ambiguity.
I mean, the legal system fakes ambiguity,
because we just say, oh, yeah, yeah, we didn't see that.
They saw it.
He knew it when they wrote the contract.
But they don't have to admit they knew it.
But the code has to admit it knows there's an ambiguity.
And that's a hard thing to self consciously prevent.
OK.
So I've given you four ideas.
Happy to take questions or abuse.
Usually, I get abuse from business school students,
but OK.
AUDIENCE: So what if you can code into a contract the easy
scenarios and then say else-if--
LARRY LESSIG: Go to court.
AUDIENCE: --go to court or some multinational court
that is the Ethereum court or whatever.
LARRY LESSIG: Yeah.
And even the Ethereum court will have to have a court above it
if it wants to avoid government saying, if you have anything
to do with Ethereum, we're going to punish you, right?
So this is the sense of which I wanted to suggest,
to go back to your first question,
that if you think about it as layers of an onion, peel layers
back enough, and you're going to, in the end,
have to get to a state in some sense, a state
as an enforceable mechanism.
And that enforceable mechanism doesn't
have to be for every case.
Again, 99% of the time, you drop the dime in,
you get the Dr. Pepper.
But there's a contingency where you drop the dime in, and out
comes a bottle of gasoline.
And then you need to go to somebody and say,
you breached this contract.
And that person--
AUDIENCE: But if it's a contract between somebody in Alaska
and somebody in Rwanda, you still
have the question of which state you go to.
What's the jurisdiction?
So I feel like there would have to be
some extranational extra-state.
LARRY LESSIG: Yeah.
So you will see in these types of contracts
is there'll be a whole bunch of boilerplate that specifies
choice of law, which turns out to be a relatively easy thing
to do right now, choice of jurisdictions.
For most countries, it's pretty easy.
There are standard ways to do that.
All of that will plug in automatically.
But again, all of those are outside of the code.
All of those are law.
AUDIENCE: Comment and a question.
So I don't trust Vatalik or other software engineers
that they have the legal understanding and capacity
to write legally binding contracts.
So I trust the government or I trust the court.
I don't trust a software engineer
to write a proper code to protect me or my counterparty.
So what is your take on those smart contracts?
PROFESSOR: Can I add to that?
Not only your take on whether to trust but what
the courts in Europe and the US right now do if somebody says,
I wrote the contract, and here's the code.
LARRY LESSIG: Well, so when you say-- let me just
me understand the question better.
I'm sorry.
Your name is--
AUDIENCE: Hugo.
LARRY LESSIG: Hugo.
The way Hugo described it, I think,
is nice, with a whole bunch of conditional statements, which
is the code.
So the code says, if the plane leaves
more than 30 minutes late, then transfer $100 to his account.
So you don't trust Vatalik's system
to be able to implement that conditional?
AUDIENCE: Yep.
I don't understand-- I mean, I don't know the code.
I don't know if it's breakable.
I don't know if Jean can log in and change it.
LARRY LESSIG: I'm sure she can.
But the point is, for most people,
this is true of everything.
When I say to you, I'm a lawyer, I'm
going to write the contract so you can sell your car to Andy,
you can have the same questions.
You can have the question whether Andy
is going to have a way to flip the price so instead
of $10,000, it's 15,000.
So this uncertainty is everywhere.
It might be Vatalik would say, actually,
there's a more robust way to verify my code
than Lessig's contract code.
Because Lessig's contract code is written in English,
and we have all sorts of--
but my code, you can have independent people
who verify it.
So at the level of conditionals, I'm pretty confident.
What I'm not confident about is--
and I had the great pleasure in December of 2015 spending
a weekend with them, watching that group.
And it's this weird kind of--
he is like the messiah figure, and there's
12 people sitting on the floor around him listening
to his every bit of wisdom.
So it was inspirational and scary at the same time,
because you see how much money is resting
on this messiah's structure.
But I have a lot of confidence in their ability
to do the conditionals.
But I'm not so confident that they yet
thought through how it plugs into the bigger legal story.
And that's part of what I was trying to pitch to them,
that's what I'm trying--
to him, and that's what I'm trying
to pitch to you, that it's never going to be the case.
I was at this conference in Australia where I met them.
And so many of the people there were speaking the way people
spoke about the internet 20 years ago.
It's like, oh, there's the real world.
We have governments.
But we're going to create--
like John Perry Barlow speak.
We're going to create this virtual world where
there is no governments, where we just
live free of government.
And it's so fucking naive about the way this stuff works,
because it's always embedded in a real world which
has a real government.
And that real government is not going
to look the other way if you're doing lots of damage
or not paying your taxes.
So the question isn't whether.
The question is just how and how much.
PROFESSOR: Can we go back there?
AUDIENCE: Yeah.
So I have a question about, what kind of implications
do you think this technology has to broaden access
to legal services in general, like letting people know when
they're being taken advantage or being able to provide more
standard versions of really common contracts,
like employment contracts or lease contacts
and things like that?
Do you think that this is going to be a game changer for those?
LARRY LESSIG: Absolutely.
I mean, you've got to muster the political will
to break the monopoly lawyers have in this space.
And I'll tell you, we're going to fight hard against it.
But there is no reason for 90% of what lawyers
do to be done by lawyers.
Just like if you buy a house and you
have to have a lawyer who sits there
and basically signs documents for you.
You're like, why?
And the answer is because the law
has been written to require that person to sit there and sign
documents.
And why?
Because the people who get paid to sign documents
have corrupted the law.
So there's lots to clean up.
But if we can clean it up, absolutely.
99% of this stuff ought to be automatic.
And then let's get the lawyers to focus on the hard corner
cases, not on everything that should be automatic.
And that certainly should be true
not just within a jurisdiction but across jurisdiction.
AUDIENCE: Can I return to your insurance examples?
I got the idea that you could write a smart contract that
would pay you automatically if the plane was late.
But then you said it puts it on a blockchain.
Can you connect why he put it on the blockchain as opposed
to just putting it on his disc and letting
your credit card get credited?
I mean, where did the blockchain enter into that?
And why did he need a blockchain in order
to maintain that statement?
LARRY LESSIG: I think that the thing that he thought
he was getting out of the blockchain
is to increase the verifiability of third parties
of the actual payments according to the data.
So if I say to you, I'm going to be paying you
$500 if your plane is an hour late
and we have the data out there about the planes being late,
if he did it inside of his insurance company,
I wouldn't have any way to know that he paid you
$500 for the plane being late.
But if it's in a blockchain, there's at least conceptually
a way in which we could be doing this--
not that I'm reviewing it to you,
but we could be signaling--
AUDIENCE: That doesn't follow.
So that depends on who maintains the blockchain.
And then at the same time, it returns that.
Suddenly, everybody knows the cash flow
of that insurance company, which is likely
not something he wants to do.
LARRY LESSIG: Well, the cash flow of the insurance company's
bigger than authenticating the truth about certain types
of contracts.
AUDIENCE: Well, let us know the cash flow
of that part of the business.
So I mean, he may not want that.
I may not want everybody to know what planes I'm flying.
So you've implied that there's now
a public blockchain that does that to everyone to verify.
LARRY LESSIG: Yeah.
All I mean to argue--
and I didn't interrogate him far.
I was just taking his statement that he's doing.
So I'm trying to think, why would he want to do it?
Because I had the same kind of question you wanted to.
And it's just that if you are trying to create credibility
around your claim--
but do I have a reason to trust this insurance company
that, in fact, it's going to be doing this?
Then there's some transparency that this enables--
not necessarily the transparency of your credit card number
or your name or the flights that you're taking,
but that there was somebody who was on this who had a contract,
and we then made this kind of payment.
That would be a potential value that he has.
Now, if there's no value from that, then you're right.
The overhead of the blockchain or public
or private or whatever is too high,
and he just could do it inside.
And for certain companies, like if you
went to a credible insurance company, the credible insurance
company, you probably trust that credible insurance company.
But again, if you're a not credible insurance company,
if you're a startup and you are out there in the market
and you're saying, give me your money
and I'll pay you if the plane's late,
people are going to say, why should I trust you?
And you're like, well, here.
You don't really have to trust me.
Here's the data.
Here's the evidence in a more credible way than if I just
published a report on my website that I'm
doing what I say I'm doing.
PROFESSOR: Let's try to--
AUDIENCE: He has to escrow the $500.
PROFESSOR: Andy, let's try to get a couple more questions.
But my hunch is that it's probably a permission rather
than permissionless blockchain.
And it may be the insurance company
wants to ride on the buzz of blockchain.
But it's possible, also, that he thinks
that there'll be more trust, that consumers
will trust that if it's called a blockchain.
But you did an interview.
You can pick who you want to--
LARRY LESSIG: Right here.
AUDIENCE: So proof of performance,
could this whole smart contract solve it?
So for instance, some countries will receive--
and I was talking to Leonardo about it in Cargill,
in his company.
They deliver wheat to some countries.
And proof of performance is always delayed.
And hence, it becomes a private issue.
So could smart contracts solve something like that?
LARRY LESSIG: Yeah.
If you had an alternative way to credibly represent a fact--
and again, this is kind of connected to Andy's point.
Is there an alternative way?
And is this the alternative way?
Then you lower the transaction cost of that kind of contract,
because I'm going to trust the contracting process more
if I'm confident that, in fact, the fact that I'm not late
doesn't penalize me, or you don't
penalize me claiming I'm late.
So to the extent you lower the cost of verifying
facts in the world, you increase the opportunity
for certain contracts to happen who otherwise wouldn't happen.
And that's the only trade-off that I'm
trying to emphasize by emphasizing the transaction
cost part of these contracts.
You had a question here?
AUDIENCE: Oh, yeah.
I was just saying maybe one of the benefits of applying
blockchain here would be not for one-off transactions
but for the insurance company, perhaps,
to have an aggregate thousands of transactions
where they've shown performance.
And they can use this for commercial reasons
to show that, yes, people get paid
when they purchase our insurance and get credibility
for particular products.
LARRY LESSIG: Yeah.
You would frame that as it would have
to be that that would be a value it was providing.
Otherwise, to Andy's point, there
would be no reason to adopt this.
PROFESSOR: OK.
Go on the back right.
I don't remember your name
AUDIENCE: Kyle.
So with, I guess, easier access to these derivative contracts,
do you foresee a world where there's
a lot more leverage in any type of market
outside of financial markets?
And do you foresee this creating kind of a risk in that way?
LARRY LESSIG: Well, I mean, this is your expertise, right?
Because, I mean, we already saw in the derivatives market
the fact that the choice by policymakers
was to allow it to be an invisible market
and not to regulate that market.
It created all sorts of risks that sensible people might
think shouldn't have been there.
And I think the same potential is
here, which is, again, to come back to the point,
don't expect there not to be government here.
I mean, to the extent people realize this risk
and don't have as much political corrupting power
as Wall Street did in our system,
we should expect governments [INAUDIBLE]..
PROFESSOR: I would say yes.
Even on bitcoin, you can create something called discrete log
contracts to do contracts for differences or derivatives.
But with smart contracts, you can put a lot of leverage
into the system.
And transactions can move quickly.
So I think the state will have an interest, particularly
if it grows.
We probably only have time for two more questions.
And I'm still wondering, how do courts currently look
at these as a matter of law?
In the late 1990s, I was honored to work
with Senator John McCain on something which
became the e-signature law.
I was just playing point for the US Department of Treasury.
It was really John McCain's law Congress was doing.
But I'm wondering how the courts today
would see these contracts.
Do we need something like an e-signature law
to have code accepted beyond what e-signature accepted?
LARRY LESSIG: No.
I think the e-signature infrastructure
is going to be 99% of what this system is.
PROFESSOR: You mean that which I worked on 20 years ago?
LARRY LESSIG: Yeah.
You solved 99% of the problem.
PROFESSOR: Little did I know.
LARRY LESSIG: Here, too.
Yeah.
I mean, that's why I wanted to wrap this
around the idea of a soda pop machine, right?
So it's nothing new, in some sense.
Contract law has always dealt with machines that
are delivering on obligations.
It's just a more sophisticated set
of proofs you're going to have to make in a court.
But it's the same underlying plot.
PROFESSOR: One more question.
We're MIT.
We're supposed to end five minutes early.
LARRY LESSIG: Oh, OK.
PROFESSOR: I don't know what you do at Harvard.
LARRY LESSIG: I don't remember.
PROFESSOR: It's Harvard Law.
LARRY LESSIG: Right here.
AUDIENCE: So I have a little bit of the opposite question
from Elon, which is a lot of the contracts you're talking about,
simple contracts, right?
You've got individuals on one side.
You've got large companies, like your insurance company,
on the other.
The insurance company can't, in fact,
go through the entire decision tree
and decide what every term is in their favor.
And the law deals with that all the time.
But here, you have another problem, which is now,
it's going to be OK.
It's going to be written in computer code.
How are the judges going to deal with that?
Now it's a language that is going
to be even tougher to deal with that problem.
LARRY LESSIG: Great question.
And the answer is--
so this is actually another version of your question.
The answer to that is nobody knows right now.
And so this issue gets raised in a lot of parallel contexts.
For example, there's a Supreme Court Justice from California
who's doing a lot of work about the question of black boxes
that predict whether you are likely to commit a crime again.
So if you're convicted of crime, the question
is whether you're going to have parole.
The parole process is supposed to decide your likelihood
of committing a crime.
So these companies have built these black boxes where
you spit in every bit of data.
And it comes out and says yes, you're a criminal,
or no, you're not.
And then the lawyers come forward,
and they say, well, I want to interrogate the black box.
I want to know what--
And the courts are completely confused about this.
Because on the one hand, they say,
no, no, this is their trade secret.
But on the other hand, they're like, wait a minute.
You can't decide whether I have liberty or not
based on these black boxes that just spit out numbers, right?
So I've got to be able to interrogate them.
Right.
So this is the most important innovation that's
got to happen in the law.
Lawyers have to become technically
sophisticated to be able to read code
like they read legal contracts.
They have to have a conceptual understanding of what
code can do so they can think creatively about code
like they think creatively about language, right?
And one of the most important innovations
that we, like the Berkman Center and people like that,
are trying to push into the legal environment
is to insist that just like lawyers now all study
economics, because that's a core way of thinking about the law,
we also should study basic code so we
can think about this modality of regulation.
Not expect people are going to be writing code,
but at least that they can think through it.
So I completely agree.
That's a fudge space that I didn't talk about at all.
But I think it's a really important problem, thinking
about whether the legal system is going
to be able to deal with it.
Because if none of the lawyers understand it, yeah.
Let me just end with one story about that.
So when I first started doing this work, talking
about code and--
I went to Paris 20 years ago, and I gave a speech
to some lawyer group.
And I sat down after the speech.
And the chairman of this legal group sat down next to me.
And I introduced myself.
And he stood up, and he grabbed my card.
And he crushed it.
And he threw it to the ground.
And he said, I am not a technician.
And his point was he, as a lawyer,
could never accept the idea that what he needed to understand
was code.
That was forbidden.
It was beneath him.
And I think it's a hugely important cultural problem
to integrate this form of knowledge.
Because if we don't, then the problem you're talking about
is really a huge problem.
But I think we can, because we've seen lots of--
PROFESSOR: So I want to thank you
on behalf of the class, Blockchain and Money.
[APPLAUSE]
I also want to say you're much better than Christopher Lloyd.
And if anybody wants to know the joke,
watch that West Wing episode that Christopher Lloyd plays
Professor Lawrence Lessig.
So thank you.
See you on Thursday.