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 altcoins
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.
PSA: Some exchange customers may experience some exchange downtime/service interruption as exchanges complete their Alonzo integration work.
Check the status of Alonzo readiness for your exchange here: Alonzo readiness of third parties
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
Ole Gary
Sun Tzu - "Understand your enemy"
This is a v good session. Has Lawrence Lessig (expert on contract law from Harvard) talk about contract law, smart contracts, & visiting Ethereum for a week. Compares the dot.com era with current crypto era. Well worth your time.
Whole course is a pretty good watch.
Why don't you ask Gary about how fraud works within major markets.
He should be able to tell you all about it.
Many thanks for finding and sharing this!
this teacher is a TROJAN
Haha I watched this lecture yesterday