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: Welcome back. I know we're sort of getting
into the middle of the week. Some of you maybe want to
keep your laptops open to work on other courses'
midterms, but I will ask you to try to focus
on Blockchain and Money today. Today, we're going to
chat about permissioned versus permissionless systems. I want to thank-- I have a guest here. I call out guest when
they're here and I know them. Mark Snyderman, who runs
a fund at Fidelity-- Mark runs a 6--
about $6 billion? Called the Real Estate
Income Fund at Fidelity. And you might say,
well, why does he want to come to a
Blockchain and Money course? It's because we went to
high school together. [LAUGHTER] So-- and I was at his wedding. And he's getting
married again next week. Yeah. [APPLAUSE] But you can all inundate
Mark later about Fidelity, because he's been there
for a lot of years. See what I'm going to do? I'm shamelessly for
MIT and MIT students. So let's get going. I was letting a little bit
of time for a few more people to wander in. Today, we're going to talk-- of course, we're going to chat
a little bit about the readings and study questions. Going to go back
again to, what are the technical and
commercial challenges? And this is relative-- this is relevant for
all of our lectures, but it's particularly
relevant today, because we're going to
be talking about two different database structures. One's the permissionless
blockchain of Bitcoin. But now, today, we're going
to introduce and go deeper into the permissioned, or
private, set of blockchains, like the IBM
Hyperledger and Corda. But the technical issues
relate to all of that. And then, of course,
we're going to talk about that against a
third type of database-- traditional databases. So aligning permissionless,
like Bitcoin, permissioned-- IBM Hyperledger type of-- and then traditional databases,
and why, in a business setting, you might think of one versus
another versus another. And I'm sure if I run
off the rails anywhere on traditional databases, which
I have not personally studied, Alon will help bail
me out somewhere. Is that a deal? Maybe? AUDIENCE: OK. PROFESSOR: All right. [LAUGHTER] AUDIENCE: You asked for it. PROFESSOR: Yeah, I asked for it. Mark, Alon is a
computer scientists from other parts of MIT, so
he helps me out in subjects I don't know, and even in
subjects I think I know. So let's just start a
little bit with what did you take from the readings? There were four or five
readings, of course. But what is a permissioned or
private distributed ledger? Now, I can do this. I can light them up, as some
people said, because Toledo's given me my list. But again, class participation--
anybody who hasn't spoken yet might want to sort of chime
in and give it a shot. I'm not seeing any volunteers. If I can-- ooh, yes. Do you want to tell me
your first name again? AUDIENCE: Jayati PROFESSOR: Jayati. AUDIENCE: Jayati. PROFESSOR: OK. AUDIENCE: So the
permissioned DODs, unlike the permissioned
[INAUDIBLE] Bitcoin, they limit the number
of participants. Essentially, they
require the participants to be authorized
before they can enter into this sort of technology. And in addition to that, they
are said to be stakeholders. And since they are
the only ones involved in verifying the transaction-- unlike the permissionless
ones, where it has to be verified
at all the nodes, this limits the
permissions required [INAUDIBLE] stakeholders,
which increases, also, the transaction speed. So it's like the
triangular dilemma we learned about, about the
security and decentralization and scalability. So it moves away
from decentralization and towards scalability. PROFESSOR: OK. So Jayeta-- AUDIENCE: Jayehta. PROFESSOR: Jayeta went
through a whole lot. It's about the number of
nodes and permissioned into it, and that
it addresses some of that Buterin's trilemma. So at its core, it
sort of addresses some of the scalability issues. But it does that at a trade
off that it's not truly open. It's not, anyone can
write to the ledger. I mean, that's sort of
the fundamental things. Anything else that folks
took out of the core readings as to how it separates
and how it's different? I mean-- all right. We'll get a chance
to add a little bit. And then we're going to dive
into Hyperledger and Corda a bit. We'll talk about
Digital Asset Holdings. What's Digital Asset Holdings? Anybody know this company? Alon knows it. Brotish knows it. Eilon. So Eilon. AUDIENCE: Yeah. It's basically a
competitor of [INAUDIBLE].. They're trying to build
a DLT protocol that will allow financial
institutions to exchange information and value. And they started,
to my understanding, in 2016, which is two
years after R3 Corda funded by [INAUDIBLE]
JPMorgan, Goldman Sachs. They're basically the same
amount of money-- $110 million. PROFESSOR: And who,
other than Alon can tell me who runs
Digital Asset Holdings? Just, it shows that
you did the reading. Somebody out there. Yes. Priya? AUDIENCE: It was-- AUDIENCE: Priya. AUDIENCE: Yes. Blythe Mas-- Blythe
Masters, or Blythe-- PROFESSOR: Blythe Masters. AUDIENCE: Yes. PROFESSOR: All right. Does anybody know
who Blythe Masters is and what she's famous for
beyond Digital Asset Holdings? AUDIENCE: She worked at
JPMorgan, and she [INAUDIBLE] credit default swaps. PROFESSOR: So she
worked at JPMorgan, and she's known around the
world of credit default swaps. Gillian Tett, who some of you-- the Sloan Fellows
will get a chance to chat with Gillian Tett
in New York in a few weeks. Gillian Tett wrote a whole
book about credit default swaps and JPMorgan. And Blythe Masters is
a central character in that whole narrative art. And this is what
she's doing now. She's brilliant, and she's
a very good businesswoman. I ran the Commodity
Futures Trading Commission and had an opportunity
to meet with her a lot because she ran the swap dealer
association ISDA at the time, or was the outside chair
of ISDA, if I recall. And then we're going to talk
about the business trade-offs as well. But what do you think some
of the central business trade-offs, if I could
get two or three of you to help me out on what
are the central business trade-offs between permissioned
and permissionless blockchains? Let me see if I can get
somebody other than Pria. Yes. Remind me of your first name. AUDIENCE: Misha. So permissioned blockchain have
better privacy and protection, and better scalability. And no mining [INAUDIBLE]. PROFESSOR: Misha, let's
pause for a minute. So better scalability, better
privacy, and the third point you're saying? AUDIENCE: No mining. PROFESSOR: No mining. Or, mining is associated
with this proof of work. Any other business trade-off? AUDIENCE: So for
permissioned, you have some more flexibility
with governance. If you need to make changes, you
don't need to rely [INAUDIBLE].. PROFESSOR: So more flexibility
of governance, in essence, because if you have a club
deal or group deal, maybe you can do that
governance changes amongst the group instead of
having thousands of people participating. Kelly? AUDIENCE: There's also a key
technological differentiator, which is the coding language
sort of that the inputs can be made in. So with Hyperledger, they
can use the smart contacts in any variety of them, versus
the alternative, which is the domain specific language. PROFESSOR: Right. So Hyperledger at least
promotes themselves in their own write-ups-- because the
reading was really from them-- that their embedded language
is much more flexible, and that you can use Java,
you can use Go, and so forth-- at least they say they can. I don't know if it's really
as limited in Ethereum. But they think and they
promote that they're more flexible than Ethereum. So Kelly's right in that, too. So these were the readings. And now, so we're
back to basics again. What is a blockchain? I know we've spent four
or five lectures on it, but these key components-- let's start. Append-only timestamped logs. Are they both--
by show of hands, are they in permissionless
blockchains? I hope every single
hand goes up. Are they in permissioned
or closed blockchains? I'm watching. I'm not-- I'm just
going to watch. All right. Every hand should go up. So both sets of blockchains
have this concept that goes back nearly
30 years to our friend Haber, who started the
whole blockchain that's in The New York Times. This whole concept is in
both sets of blockchains. Brotish? AUDIENCE: So I have a
question about basically kind of [INAUDIBLE] append-only
[INAUDIBLE] of the ledger. I think I read in
one of the readings that Corda has a
feature where you can make some changes to
the history, which is not equivalent to a hard fault.
So that will probably be one example where
it is not purely append-only in a
permission [INAUDIBLE].. PROFESSOR: So Brotish
is raising that there's certain features
that are promoted in one of the private
blockchains, Corda, that may allow you not to
append-only, but in essence, delete data, or
replace data, possibly. And I'm not-- because there's
also, in private blockchains, an inability to partition,
and in essence, sh-- it's kind of a
form of shorting-- but to partition the data. I don't know enough about
Corda, whether they literally allow you to delete-- or is it something
in this partitioning? But maybe Hugo? AUDIENCE: I was going to raise
a similar point that if-- I mean, to my understanding, if
you have a permissioned system and there are only a small
number of-- we'll still call them nodes, then if you
realize you did something wrong, or something
needs to be changed, can't they all go
in and change that? PROFESSOR: So Hugo's
raising the point, if you're down to,
like, three nodes-- as I've shared with you all,
the Australian Stock Exchange is putting a
permissioned blockchain up using Digital Asset Holdings,
which I think is backed by also the Hyperledger
Fabric technology. But if it's just the
Australian Stock Exchange, and it's one node,
or three nodes, couldn't they just
change it on all three? And I think, in essence, yes. I mean, that may not be what
the database structure is, but I still think
it's potentially yes. So as you get more
concentration, you have more chance. But Brotish, I will try
to research the Corda thing more specifically. Other thoughts? So then you create an auditable
database-- some database with cryptography. Hash functions, which half
the class said they understood and the other half
was sort of, you know, a little rough on, all
is in permissioned systems, using cryptographic
schemes to ensure for the validity of the
data and, so to speak, the immutable
nature of the data. What's different is
consensus protocols. In essence, it all goes down,
except for Brotish's point, maybe, about Corda, as
to who gets the chance to add the additional data. Is it a small club deal,
or is it broad, wide open? Everybody together, roughly? So back to the
technical features. Remember, it's a
bunch of cryptography. Love it or hate it, it
actually allows us all to use the internet--
well past, obviously, the blockchain that we're
discussing in this class. Network consensus, and
then all the ledgers. So both permissioned and
permissionless have ledgers, have cryptography. It's that middle bucket that's
different between the two. So what were some
of the challenges that we talked
about in blockchain? We just talked about them
10 minutes ago, which is, what's the list again? See, this is the easy part. If you haven't spoken yet, this
is, like, the easy questions. Oh, I'm hopelessly shameless. Yes. Do you want to say your first
name so Toledo takes you off the list? AUDIENCE: [INAUDIBLE] PROFESSOR: Did you get it? No. Do you want to say it louder? Because Thalita [INAUDIBLE]. [INTERPOSING VOICES] [LAUGHTER] AUDIENCE: [INAUDIBLE] issue
about the scalability. PROFESSOR: Scalability. AUDIENCE: [INAUDIBLE]
takes the time to create the next
block about [INAUDIBLE].. PROFESSOR: All right. So scalability and some time. So efficiency and scalability. Anything else? AUDIENCE: Privacy? PROFESSOR: Privacy. So it's basically
the scalability, the privacy are two big things
that permissioned systems address. Interoperability-- basically,
how does this blockchain talk to other blockchains,
or how does this blockchain talk to other legacy systems? Permissioned and
permissionless systems both have issues of
interoperability. However, the smaller
the club deal, the more likely that a bank or
the Australian Stock Exchange might address its
interoperability right within the system, whereas if
it's a big open-sourced, open project-- so IBM would say, we can even
help you with interoperability. IBM would say, we can help
you with all four lines. We can help you with
scalability, efficiency. We can help you with privacy. We can help you with
interoperability and governance. I think it's less clear
they can help with all four, but they can certainly
help with the first two. And Alon, you've switched
from using a permissionless to a permissioned system-- AUDIENCE: Correct. PROFESSOR: --in
your startup, right? Which of these four is the
reason why you switched? AUDIENCE: So
actually, I switched-- PROFESSOR: Or something else? AUDIENCE: Something else. So for me, it was a
business use case. So I was trying-- my business is selling to banks. PROFESSOR: So that's the next
line-- commercial use case. AUDIENCE: There it is. PROFESSOR: There's a setup. So what was the reason
that you switched? AUDIENCE: So I was building
on Ethereum, which is public. And I thought that it's unlikely
that, in the near future, banks are going
to adopt Ethereum as their underlying technology. And then I learned
about R3 and Corda, and learned that banks
actually funded that project. So I switched to where
the banks put their money. PROFESSOR: So I would
contend that it's a bit about interoperability. You felt your
users would be more likely to be able to
work with your system if you were using Corda, with
which they were familiar. AUDIENCE: Correct. So there's a business reason
and technological reason. PROFESSOR: And then,
of course, there's the public policy reasons. And IBM would even
say that they're going to score higher
points on the public policy if, for no other
reason, that there's better privacy and security. Now, I'm not trying
to shill for IBM. I'm just saying these would
be their selling points-- or Corda, or elsewhere. We talked about
Buterin's trilemma. But in another way,
many people would say decentralization competes
with scalability and security. If you want scalability
and security, you can't have decentralization. I'm not a big believer
in this trilemma, even though I've
now raised it twice. But it's often talked about
at blockchain conferences, and blockchain papers,
and business discussions. So I've always told you I want
to be a fair representation of the debate that's going on. I think it's more possible to
solve these three over time together than some others. But maybe I'm just a cockeyed
optimist about technology. So public policy framework. What were the big
three slipstreams? So I went fast last time-- last class. Leonardo, what are you
going to tell me about the-- it's because you were
adjusting your glasses. AUDIENCE: Yeah. No, we spoke about
the difficulty to implement framework. And you were talking more
about the need [INAUDIBLE] offer security to
protect people. PROFESSOR: To protect
people-- so it's sort of a privacy thing. I think I have a hand
up here from Catalina. AUDIENCE: There are three big
things that [INAUDIBLE] public policy working against
illicit activity-- PROFESSOR: Illicit activity. AUDIENCE: --financial
instability, and protecting the investors. PROFESSOR: There you go. All right. So you know my style. I try to drop things
into three buckets. But it's the only way I
can remember anything. But it is the three
big buckets, of course. And since I went
fast last time-- and we're going to be
coming back to a lot of it, but were there any
questions that you have? And this is just an opportunity. Brotish? AUDIENCE: So I have a
question on the [INAUDIBLE] stability point. Like, you mentioned that
because of the world value of the digital currency
is very minimal compared to, let's say, [INAUDIBLE]. PROFESSOR: The value
of crypto finance is about $220 billion right now,
compared to worldwide capital markets that, in aggregate,
are over $300 trillion of debt, bonds, and equities. AUDIENCE: So my question was
more like [INAUDIBLE] opinion on this, that this value is also
concentrated within a limited number of people compared to
the other assets that we are talking about, and hence-- I mean, it can still be
important to regularize on the financial
stability side, because it can have a effect which is not
in proportion to just the size. PROFESSOR: So Brotish is
asking the question that even though it's only $200
billion versus $300 plus trillion of worldwide
financial assets, couldn't it still be relevant
to financial stability? And the answer is yes. But it's still relatively-- it's
less than one one-thousandths of the broad size. AUDIENCE: [INAUDIBLE] PROFESSOR: Yes, please. Better you than me. AUDIENCE: So basically,
we did an analysis between the correlation [INAUDIBLE]
public market [INAUDIBLE] and basically there's a
correlation of roughly 80% to 85% when the public-- when the Bitcoin market's
down, within the past year, the public market's
likely to lift up. Because there's a lot of
leverage built into the system. And once the
volatility kicks in, a lot of the
investors [INAUDIBLE] they have to get money out
from the public market, and that kind of
feeds into a loop. PROFESSOR: So you're
saying there's correlation, and there may be feedback loops. Tom? AUDIENCE: Sort of
a related question. So Mervyn King was in this
room a couple hours ago, and he was talking
about, in the '08 crisis, two issues of trust-- one where
there was a counterparty trust issue. Even though the overall
derivatives market was [INAUDIBLE],, banks
didn't individually know which other bank
was most at risk. And so they wouldn't
trade with each other or lend to one another. And then on the opposite
side, the solution-- the salvation-- was two
people in a room trusting each other that the central
bank-- that the government would fund tens of billions of
dollars [INAUDIBLE] capital. And so I wonder your
thoughts on blockchain's role in addressing that
first problem of knowing your counterparty,
or at least being able to trust their
position, and then the risk of eliminating the second
chance of injection of capital into the financial
system in a blockchain. PROFESSOR: Russ, [INAUDIBLE]. AUDIENCE: I had a question. It's related to this-- PROFESSOR: All right. AUDIENCE: --which is-- PROFESSOR: Thanks, Brotish. [INAUDIBLE] AUDIENCE: But the
question is this. It does strike me that you
only have a financial stability problem if people are relying
on the value of people's Bitcoin holdings, for example,
which is the bulk of crypto assets, right? The reason you have the
problem during the crisis is you have all these banks. They're carrying these assets
on their balance sheet. And all of the
sudden, people think they don't know what
they're worth, right? Who, if anyone, is actually
carrying a Bitcoin assets on a balance sheet that
someone else is relying on? Or, to put it differently,
who's extending the leverage? PROFESSOR: All right. So let me-- AUDIENCE: [INAUDIBLE] PROFESSOR: Let me
wrap these together. I think that what many central
bankers and the Financial Stability Board would
say, at 200 billion versus 300 trillion, it's
probably not that financially relevant at this point. Where it could get relevant is,
as Russ has sort of suggested, is if there's
leverage behind it. If it's in a balance sheet, it's
an asset on a balance sheet, and there's a liability
on the other side. And thus it could
bring down that entity, whether it's a hedge
fund, whether it's a bank. But something that's relying
[INAUDIBLE] to tie it back to the questions
that Tom raised is, could blockchain
lower systemic risk? Possibly, if it's a
better database solution. If it answers-- what Mervyn
King was speaking about, we also addressed
in the late 90s. I remember quite well
when Secretary Rubin called a number of us
into his office and said, I don't understand. The banks can't tell us
their exposure to Korea. A number of countries-- South Korea was about
to have-- but they didn't default on
their debt, but they were coming close to
defaulting on their debt. And of course, it was
only a short while before other countries,
like Indonesia and Thailand, were getting into that
same debt challenge. But why couldn't banks tell
the US Department of Treasury their exposure? It's usually
through derivatives. And derivatives,
both in the late '90s and the financial
crisis, were often something that propagated
risk through the system. Now, the numbers were larger-- I mean, depending upon the time. The '90s was less than this. But it was $300, $400
trillion of notional amount of derivatives. So just the sheer
notional size, even though the capital at
risk in derivatives was much smaller
because the leverage of this notional--
big, notional size. And the transparency
was pretty low. It wasn't zero, actually. It wasn't zero. But it was really low. And so I think that's
what Mervyn King would have been mentioning. And I do think blockchain can
help in that transparency. But it takes a big
collective action. And so Europe, the US,
and Asia-- a lot of laws were passed to get more
transparency in the derivatives space. Brotish, I would say that
there could be problems. And I've had conversations
with elected leaders that say, don't get
lulled into the sense that it won't have
financial stability issues. Because that was what
happened in the 1980s and '90s when people said, well,
derivatives will not create instability,
because it's only the institutional investors,
the sophisticated investors-- the so to speak big boys
or big girls, you know? And I was part of those debates,
that consensus that formed that it was only institutional
and it wouldn't-- but there was a lot of leverage
and a lack of transparency when big leverage-- multiple hundreds of
trillions of dollars-- associated with it, of course,
was part of the crisis-- not the only part of the crisis. But any other
questions before Hugo? AUDIENCE: Yeah. On the protecting the
investing public front, I was just wondering,
like, a lot of people are now using Robinhood and
zero fee things like that to invest in the stock market. And companies like
Robinhood and Vanguard often sell order book data
to high frequency traders so that they can kind
of know what's going on and maybe front run. So I was wondering how
that fits into what we were talking
about last time where there's no transparency on
many of the cryptocurrency exchanges. And then in addition to that,
big institutional investors can, I think, buy upwards
of 5% of any stock and then wait a few days before
they have to report on that. So that can also have a
huge effect on stock price. And then they can,
afterwards, dump on people. So how is that different
from what's going on in cryptocurrency exchanges? PROFESSOR: All right. So that's an investor
protection one. Was there another one in the-- is this investor
protection, or-- AUDIENCE: No, it's a
little bit different. PROFESSOR: A little different. All right. Any other investor protection? Because I'm going to collect
them and then [INAUDIBLE].. AUDIENCE: It's about the former. I was a little bit-- it was kind of [INAUDIBLE] to me
when you say the blockchain can help to stabilize the
financial markets-- PROFESSOR: All right. So that's back to
financial stability. AUDIENCE: Yeah. If it can-- PROFESSOR: All right. Can I hold it? Let me just answer Hugo's
investor protection one. So all markets-- not
just crypto markets-- all markets are susceptible to
some forms of front running. In essence, if you have
a client relationship and you get information
from your client that might affect the
market pricing, you might jump ahead of that
client with their information. Their information might be
a buy order, a sell order. Or frankly, it might be
some other information. But traditionally, if they have
a buy order or a sell order, you have information. And then you're sort of jumping
ahead and saying, all right. I'll buy or sell
in front of them. That's the classic
sort of front running, even though there's
other methods. It's not supposed to happen. On regulated exchanges, you
have some policing of it. Even before
governments stood in, you could have
some policing of it in self-regulatory
organizations. In the crypto world, there
is Katy bar the door. Anything can really happen. And it's my belief
and understanding that many crypto
exchanges-- not all of them. Not all of them. But many crypto
exchanges are basically trading in front
of their customers. And in fact, most
crypto exchanges make markets, as they
are both market makers-- meaning they are buying when
you're selling and selling when you're buying. That's the nature
of a market maker. It's very typical, very
legal, very important function of market. But the exchanges are
both market makers, and then they show order books. And so it sort of helps
them do front running. Not that a lot of people
necessarily agree with me, I think these markets
would be better off if there were some forms of
rules about front running and manipulation in
markets and the like. On your 5% question,
can we take it up in office hours or something? Because it's sort of
outside of crypto. But I would be glad to
talk about the SEC rules about the 5%. Is this investor protection? And that-- AUDIENCE: I think so. The reading that we had
that talked about the Fabric technology, it
mentioned something about execute order validate. Does that mechanism
tie into the way that front running
would work at all? PROFESSOR: All
blockchain technology, whether it's permissioned,
like Fabric, or permissionless, can-- if it was efficient
and scalable-- could help out, because you
could actually timestamp when did the order come in. When did the
client's information get to the exchange, and is
somebody standing in front? AUDIENCE: So it's
sort of like a cascade that you can't necessarily
pause once it starts? PROFESSOR: Right, right. So if you look at the algorithms
at the New York Stock Exchange right now, which
are not blockchain-- they're not permissioned,
and they're not permissionless blockchain. But if you look at both the
algorithms and the data flows, they have very
good timestamping. I'm not going to
say it's perfect, but they have very
good timestamping to ensure when are orders-- basically message timestamping
every message that comes in. And some order books, like
the New York Stock Exchange-- some order books are
price and time priority, price priority meaning high bid
gets hit before the next bid, or lowest offer
gets lifted first. That's price priority. But they might also
have time priority for any bid that has the same
price and any offer that's the same price. So they have to have
very good timestamping. I truly believe you could
not use a blockchain solution for the New York Stock
Exchange order book right now. Whether you can in 10
years, I'm not sure. But time latency is so relevant
in the middle of those order books-- you know, the
nanoseconds that matter. I'm going to take this
stability question. There were two
stability-- and then we're going to move on to
the rest of today's lecture. You're having fun now. AUDIENCE: Can you
explain a little bit more about, like, well,
say if blockchain can be a better
database so it can help stabilize the financial market? Can you give some examples? PROFESSOR: So how
blockchain could possibly help-- be a stabilizer. A lot of financial instability-- or, beyond the
financial markets, instability is a
question of resilience. And when things are
centralized, you create single points of
failure in any system-- really, in military
or financial. You centralize something,
you then, thus-- you know what to attack. You can also maybe have
higher walls or better moats, but you still know of
something to attack. So blockchain, in its
decentralized nature, might be a more
resilient database, because even if half or
two thirds of it goes down, you still have the other third. I'm going to say something about
the New York Stock Exchange again. Whether it's the New York Stock
Exchange, the London Stock Exchange, the Chicago
Mercantile Exchange, they all are required by
their various local laws to have backup data centers. And those backup data centers
even have to be lots of miles away if, God forbid, a bomb
comes and takes out the center. AUDIENCE: [INAUDIBLE] PROFESSOR: What's that? It's called-- Its basically
disaster recovery. So maybe blockchain
will be more resilient. I'm going to take
two more questions and then get back
to permissioned versus permissionless. Way back in the corner--
your first name, again, is? AUDIENCE: Matt. PROFESSOR: Matt. Thank you, Matt. I should know that. AUDIENCE: So I'm kind
of just curious how, essentially, the nasency,
for lack of a better word-- PROFESSOR: The [INAUDIBLE]? AUDIENCE: Like, the nasency-- how kind of, like,
new this market is and how that affects policy,
because when you're shaping policy, and you
don't necessarily have a bunch of years of
knowing how people are going to react to that policy, I
feel like it could almost be a chicken and egg situation. PROFESSOR: OK, I understand. Anybody else with
the same theme? No? So the question is, how
does it affect policy makers when a whole technology is new? And I would say, we have a
lot of history with this. Whether it was railroads,
or the telegraph, or the telephone, or television,
we have a lot of history. Technology and
commercial applications move ahead of the public sector. I mean, it's just inevitable. The official sector,
the public sector-- unless it just basically
does what Mark Carney says, and the choice is to isolate
something, to sort of put up the moats of a
society and says, we can't use that technology here. Unless you have that, technology
usually supersedes the markets, and the markets and technology
come before official sector. Depending upon the
area, it can take single digit years and sometimes
decades for public sector to catch up, literally. But let's take the internet. The internet was being
worked on for 15ish years. But the protocol layer
that helped take off was the worldwide web
in 1991 or '92, and then the security protocols in '96. Just taking
financial regulation, the SEC was asked in 1995,
could bulletin boards-- there were electronic
bulletin boards listing stocks and bonds-- be exempted from being
considered stock exchanges? Well, the people
that were asking that were the people putting
up the bulletin boards. They didn't want
to be regulated. The New York Stock Exchange
that was fully regulated, and NASDAQ that was
fully regulated, was coming at the
other side and asking the SEC to shut them down. They didn't want the
competition from the disruptors. It took three years for the
SEC to answer that question. I don't mean answer it,
like, with a letter. They had to propose a rule, and
they had to do a final rule, and it was three
years to do that. And blockchain, I think,
we are through some of the big questions. We know how most
jurisdictions tax-- T-A-X-- tax it as property
and not as currency, and some of the tax issues. We know, in most
jurisdictions, how it fits into,
broadly, Bank Secrecy Act and illicit activity. There's very choppy
implementation, very spotty implementation. I would say the investor
protection side, we're at the early stages. And it's going to take, in most
jurisdictions, another three years, maybe, to sort
through some of how-- and this is just crypto finance. I don't know. Matt, does that-- I'm giving you some predictions. Some of it could be
multiple decades. We're still, today,
trying to figure out-- the public sector's figuring
out how to regulate Facebook and Google. I'm going to take one last
question, because I've got to do permissioned. AUDIENCE: [INAUDIBLE]
because I was kind of, like-- it kind of answers the side
following the technology. But I think, for
me, what I was kind of wondering about was this, the
way we're like-- as soon as you apply regulations to something
that at least a good portion of the market seems to
value being deregulated, it seems like a lot of
the activity will change, either in scope or scale. PROFESSOR: So Matt's
raising there's a trade-off about
bringing something under regulation or into
the public policy sphere. I'm probably just
one voice of this, but I think it's probably true. There's very few
economic activities that grow large that stay fully
outside of the public policy framework of a society. It doesn't mean that public
policy frameworks don't change, get adopted, get adapted. The internet comes
along, and at first, it's a question of-- you
know, with Amazon, is it going to be taxed or not? Is there sales tax? And then later-- you
know, at first, it's not. Later, it is. And in some jurisdictions,
questions on the internet was liability. And this was a very critical
question of early internet was, was there liability for
any of the information or the flow of information? I'm talking about libel laws
and all the liability issues and so forth. And so in the US, there's a
section of the law in 1996 was passed. And now we're coming back
and saying, wait a minute. That gave too broad-- it
basically exempted the internet from liability as carriers. But now, that was
modified in 2018-- 22 years later-- to say, well,
if it has to do, I think, with basically children
trafficking and slavery and everything, maybe we should
tighten that up a little bit. So I don't believe any
broad economic activity is going to remain fully outside
public policy frameworks. And I'm glad to be
challenged on that. And I think blockchain, and
particularly crypto finance, is at this grappling
stage to get in. So let me move
forward, because this is more about permissioned
and permissionless. I just wanted to
cover some of these. We will cover initial coin
offerings and the public policy issues around initial coin
offerings in the Howey Test. We will cover crypto
exchanges, and we will cover central bank
digital currencies a lot in the second half
of this semester. So back to the trade-offs
that we talked about already-- the trade-offs of centralization
and decentralizations and Coase's work from
the 1930s about the firm. This is the cost, remember. This is the cost. As we get centralized, there's
more cost of economic rents, single points of
failure, and capture. Some fragility, in a
sense, in the system. But decentralization
has its cost as well. You'll notice that these two
lines are crossing somewhere. It was my failed attempt
to say, you know, maybe there's a balance. Maybe overall, while
some organizations will find all the way
to decentralization, and some to
centralization, I think economic systems tend more
towards the centralized side of things. But you can change the slope
of these two lines if you want. I'm just trying to give you a
framework of thinking about it. So as we've talked about,
the financial sector pretty much favors
permissioned systems. The financial sector is
saying, going back, no. Too many costs of coordination,
governance, security, privacy, and scalability. We're over in the other side. And so that's where
they are today. I'm not sure that's where
they'll be in five or 10 years, but it is definitely
where they are today. So let's go back down
our list, in a sense. I'm going to have a
bunch of check marks and x's on the right. Where do you think I'm going
to have check marks and x's? This is the same
three big buckets, because I can't
think of anything. Emily, do you have
a point of view? AUDIENCE: I mean,
I think in terms of the permissioned technical
features, one of them is obviously that it's not
using that proof of work. PROFESSOR: Not using-- AUDIENCE: It's not using
the same proof of work. PROFESSOR: Not
using proof of work. So I had to give away-- you
know, reveal the [INAUDIBLE].. All the cryptography that's
used in permissionless systems is used in the
permissioned systems. It might be used a
little differently. I'm not going to say the Merkle
trees are exactly the same. But all that broccoli we were
eating a few lectures ago are relevant on both sides. Sorry, Alin. AUDIENCE: [INAUDIBLE] PROFESSOR: What's that? You-- AUDIENCE: I like broccoli. PROFESSOR: You like broccoli. A computer scientist speaking. Everything, though, about
digital signatures and hash functions and so forth are
relevant to both of these. But they're not
necessarily relevant to every traditional
database, which we'll talk about in 10 minutes or so. But as Emily said,
there's really not-- I said, no. There's not decentralized
network consensus. I'm stretching it a little bit,
because permissioned systems can be decentralized. There could be five
or 10 or 20 nodes. And so that is decentralized. So I shouldn't have
really said no. I should have said
maybe, or hybrid. And instead of proof of work,
the permissioned systems use a bunch of
consensus mechanisms. And I just listed
a couple notary nodes or PBFT for Byzantine
Fault Tolerance again. But they don't have
native currencies. So that is a very
big difference-- no native currency. If you have a solution
for your final projects, or you have a solution for
some entrepreneurial business that you're going
to do in the future that you want a native currency,
you're probably more over into the permissionless world. You want to have an incentive
structure, something to motivate customers or users,
or create token economics. Token economics is more
in the permissionless. I say more because you
can create a token even in the permissioned space. We'll talk about it in a moment. And then transaction
script or UTXOs. They're not technically
UTXOs in a bunch of permissioned systems,
but you need some ledger. This last box, if I
just called it ledgers, you'd still have ledgers in. So it's really the consensus
mechanism in the middle, as Emily said. A couple of key design features. First, membership's limited
to basically an authorized set of nodes. So does anybody want to
say, if you were a bank, who you might-- you know,
what might you do if you were a bank, and who might you
authorize if you're doing a bank-- I don't know. Let's say that it
was loans, or if it's Mark Snyderman's real estate. It's real estate loans. Could you ever see
real estate loans going on a blockchain, Mark? MARK SNYDERMAN: Loans, maybe. Loans could. PROFESSOR: All right. So-- MARK SNYDERMAN: Loans
aren't traded as much. PROFESSOR: So if
real estate loans were on a permissioned
blockchain, who might be that
membership, the limited-- who would-- it's not just
a rhetorical question. Who would actually care about
the database of the loans? MARK SNYDERMAN:
Broker dealers that are active in loans,
institutional investors that are active in loans. PROFESSOR: So the
broker dealers who are actually trading the
loans, and maybe the investors. Alon? AUDIENCE: Yeah. Just rating agencies when
you securitize those loans-- AUDIENCE: Loan servicers. AUDIENCE: Loan servicers. PROFESSOR: Amanda,
loan servicers. So maybe loan servicers,
maybe the rating agencies. So it's basically, who has
a need and needs that data? I'm not sure that this
is the right community, but it's the discussion
I'm thinking about. And again, as you're
thinking about-- I'm jumping again to a little
bit final projects, but when you're thinking about
who actually needs data and who has a reason
to amend the data, or write to the ledger-- because if you don't
have a desire and a need to actually amend or change the
data, move value in the system, you might not need
an open database. Please. AUDIENCE: When we
were talking about that additional layer of
blocks, is that layer also-- can you change the
membership with that layer? PROFESSOR: I'm not sure
I follow your question. When you say an additional
layer of blocks-- [INTERPOSING VOICES] PROFESSOR: Oh, I'm sorry. Layer 2. AUDIENCE: Yeah. Can you alter the-- because it's a different level
of refinement of information that's stored. PROFESSOR: So what
Kelly is asking is, we've talked about how
to make permissionless blockchains more scalable
by having a layer 2, like the Lightning Network. That's what you're referencing. So in permissionless systems,
it's open to everyone, even though if you're opening
up an individual payment channel in the
Lightning Network, it's really just
two counterparties opening up a channel. So in a sense, you've
already narrowed the scope, because you might
just have a payment channel between two parties-- some side chains or
multiple parties. Lightning Network
and payment channels tend to be two parties. So I don't know if-- was that what you're asking? AUDIENCE: That network
in and of itself is a mechanism of membership. PROFESSOR: The layer
2 can be a membership. That is correct. But it's a technology that's
available to everybody. So it has attributes where you
can open up bilateral channels. James. AUDIENCE: I was
just going to say, for permissioned
blockchains, couldn't you imagine that the layer
1 would be, say, the Fed with all of the big
commercial banks? But in effect, if
you're thinking about a different
layer, you could have another layer
on top of that, which [INAUDIBLE] central banks. So you could naturally-- PROFESSOR: All right. AUDIENCE: --have two
layers of deals with-- PROFESSOR: So where
we're headed is, is do permissioned
systems have the same need to have a second layer
as permissionless? And even if they don't
have the same needs, might it actually
provide something? So I would say, I don't
think they have the same need to have a second layer,
because they're more scalable, they're more
efficient right now. And they're already
closed clubs. But even if they don't
have the same need, they might actually want to
put a second layer on top. And some of them actually do
this right in their technology. And it's what I put up here
as the second and third bullet point. The transactions can be
limited to only authorized known participants. So in many permissioned systems,
it's a one broad technology. It might only be 20 people that
can authorize transactions. But now in some transactions,
it will only be Anton and May. And in other transactions,
it will be Alpha and Amanda. So I might not be able to-- by the way, Alpha
might be Goldman Sachs, and Amanda might be Barclays. And then it might
make more sense. And Mark might be Fidelity. And I don't know, am I the
US Department of Treasury in this one? Mark and I both
started out in finance. I just went off to
public service later. But so Corda and Hyperledger and
many of the private blockchains literally allow for partitioning
right in the blockchain. I don't know if you'd
need to put a layer 2 on top, because they allow
for partitioning and segregated pools of authority
inside of the blockchain. I'm sorry? There was a question, I thought. Oh. Oh, yeah. AUDIENCE: [INAUDIBLE] you
see insurance companies, like title insurance,
as part of this. PROFESSOR: Can you speak up? [INAUDIBLE] AUDIENCE: Insurance companies
for title for the houses-- PROFESSOR: Right. AUDIENCE: --I think blockchain
could be really helpful, because sometimes you have
the trust issue around who owned the house before
you, or the title where it goes backwards in history. So I think title
insurance companies would be part of this blockchain
in terms of [INAUDIBLE].. PROFESSOR: So your point is,
is that titling of real estate could be an important part of
blockchains, and as [AUDIO OUT] MARK SNYDERMAN:
Probably someday, but every little town has its
own system for keeping property records. And getting them all to
cooperate in a blockchain kind of solution seems remote. They don't think they
have a real problem that needs solving. So yeah, maybe someday. But I doubt it will
happen anytime soon. But it makes some logical sense. And that would probably be
a permissionless system, because there's not a huge
amount of times a piece of property transacts, right? So it's not like moving
money around the world. It's a much simpler,
less frequent event. AUDIENCE: Yeah-- MARK SNYDERMAN: And
land records are public. People often have to go to the
town offices to look at them. AUDIENCE: Yeah, you have to
pay a lot of transaction fees, whether you're transacting on a
plant or anything that involves real estate here in the US. You have to pay
considerable amount of fees to the title
insurance companies. And in my mind, that
could eliminate that role if you have blockchain and
[INAUDIBLE] where the system. MARK SNYDERMAN: Maybe,
but you're paying money because you're asking-- AUDIENCE: Somebody to-- MARK SNYDERMAN:
--them and lawyers to make sure the
title's free and clear. AUDIENCE: [INAUDIBLE] MARK SNYDERMAN: And there's
all sorts of claims on a title to property-- somebody that fixed the
roof, or the utility company that has an easement through
the middle to put lines and so forth. So there are some
complications that are different than just
transferring money. PROFESSOR: So to bring it
back, to broaden it out, the que-- it's Rahim? AUDIENCE: Rahem. PROFESSOR: Rahem. Rahem's question
is, is, well, what about real estate and title? Might that be appropriate? And as Mark has given us a
sense of, yes, it might be. But we're back to that sort of
thing of the collective action issues that we've talked
about in previous classes-- the collective action of
many municipal authorities that keep the land records, that
keep the real estate records. Yeah, it might help, but
why do I need to do this? And it's also a [INAUDIBLE]. It's a low volume,
low transaction. And yet, it could be
an enormous benefit, because there's something
called title insurance. And title insurance trying
to clean up the title and making sure that
something is free and clear could be recorded in the future. So I'll be a long-term optimist. I don't see this one being
solved in the next handful of years-- single digit years-- particularly because of the
[INAUDIBLE] collective action issues. I'm sorry. We have somebody
here who's going to take the other side before I
give my conclusionary estimate. Yes? AUDIENCE: Yes. That's exactly my startup. The first phase is
collecting all the data from all those munis
departmentals [INAUDIBLE].. The information
is there publicly. So yes, they will not probably
immediately adopt a Corda node and record their stuff. But you can publicly
pool that information and then use that information
and record that information on the blockchain. And then once I become
stronger and bigger, then they will probably
have to adopt it. PROFESSOR: All right. [LAUGHTER] So maybe I'll move
up my estimate from double digit years
to single digit years. But I think it's going to be,
with all respect, some time. Pria, then I'm going to move on. AUDIENCE: So I used
to work at Habitat for Humanity International. So access to proper
land rights or land title, that was a big
issue for us overseas, not so much in the US. And so I could see a
real application there, where in several countries
where there is no land record, or there are no title
systems, or they're buried in layers of obfuscation. This is a great solution
to get something like that started in those
contexts, where there is-- establishing the
property right of record could be of immeasurable
social value. PROFESSOR: You
know, I agree, and I think there's been a
tremendous amount of literature in the last 24 months
around whether blockchain can help free up a lot of
illiquid capital and assets. I'm just saying I'm probably
closer to Mark's thinking than to Alon's thinking. I think it's going
to take some time. AUDIENCE: But depending
on the context, right? In the context-- PROFESSOR: Context, the country,
the system, the legal system, how decentralized, and how
tough the collective action issues are. So just going back to
private blockchains, technical features--
let's go back. Membership limited
to authorized nodes. Transactions can be
partitioned as well. It's kind of Kelly's point. Right in the technology, you
can partition and segregate information. So data and ledgers
can be partitioned because transactions
can be partitioned. That doesn't mean you
can't have a layer 2. I'm just saying there's a
lot less need for a layer 2, because they do it in the
data structures itself. The consensus is permissioned
private protocols. They do have a consensus. Somebody has to agree
on the next block. But it's a tight, limited group. It does use cryptography,
but often, there's something called a
registration authority. The registration authority
is helping mask data. So they address
privacy two ways. They address privacy because
it's a smaller group. They can actually see
the whole network. But even within the network,
even on the network, they're further
addressing privacy that Alpha's and my
transaction, Amanda maybe can't even see, even though
she's on the network, because it's encrypted. And then there's sort of
what's called a registration authority, or authority within
the system, that can unmask it. Yes. AUDIENCE: I just have
a question about the-- how is a segregated system a
subgroup of two [INAUDIBLE] different from a layer? If [INAUDIBLE] is already doing
subnetting off of calculations, or whatever it may
be-- transactions-- and then the net [INAUDIBLE]-- PROFESSOR: All right. So I've got another question
I have to follow up on. I have to follow up on
Brotish's Corda question, and now James' question
about, well, wait a minute. How is this partitioning
different than a layer 2? And it's beyond my
knowledge, but I'm going to see if I can get it for you. That's a good-- they're
both-- they're good questions. And then smart contracts--
yes, smart contracts can happen on these systems as
well as permissionless systems. IBM-- they say
they use chaincode. But they say chaincode really
could be any language, at least they advertise, and
no native currency. So that's kind of
the technical-- not deeply technical. It's not like learning
hash functions. But yes to cryptography. Well, they partition
the ledgers. The consensus is closed loop. Yes, they have smart contracts. But they can even have
additional privacy. But it comes at a cost. There's an authority
that has to protect something-- a registration
authority inside of it. Oh, I forgot. The code is generally
open source. It does not have
to be open source. Hyperledger is
open source, but it doesn't have to be open source. So this was from
one of the readings. I'm just putting up that
chart that was in the reading. And I just found it helpful. It's a different way. It's not Gensler's way. It's somebody else's way
of thinking about Ethereum, Hyperledger, and Corda. I'm only using
Hyperledger and Corda because they're two of the
biggest private platforms. There are many others. Different programming
language-- you might say, from a business
point of view, who cares? And to some level,
you're probably right. But you're not completely right. I mean, there's probably
more that people can write on top of Hyperledger Fabric. They say more developers could
work on that than Solidity. Governance-- that's
the governance of the system itself. They all can do smart contracts. We've talked about consensus. And the scalability
is much harder. Ethereum, remember, almost
crashed on CryptoKitties last December. And I shared that story about
one initial coin offering was 30% of the Ethereum
network on the one day it was closing [INAUDIBLE]. DTCC, in a given day,
can do as much as 100 million transactions in a day. That's the Depository
Trust Corporation. Ethereum does about a million
and a half transactions a day, and Bitcoin, about 400,000 to
500,000 transactions a day. So you know, we've still got a
ways to go on this scalability. So what about
traditional databases? I think that to talk
about permissioned versus permissionless,
a lot of people, even some of my
colleagues here at MIT, says, well, if you're talking
about Hyperledger, Corda, and Fabric and Corda,
that's like Oracle. That's just a
traditional database. That's not really blockchain. The Bitcoin and
blockchain purist would say, if it doesn't have
Nakamoto consensus, forget it. It's not a member of the club. That's not how I've chosen
to teach that this class, as you know. I think both are
relevant, possibly, to business solutions, and it's
worthwhile to think of them. But so what separates-- and this is not in the
reading, so I'm just going to, you know, kind of-- but what separates it versus
a traditional database? Well, back to the basics. Permissioned private blockchains
have append-only logs. You're adding-- I know. Thank you, Brotish. But basically, they
have append-only logs. Traditional databases-- and I'm
at the edge of my knowledge-- you can create. You can read. You can update. You can delete. Again, I'm taking the mainstream
traditional databases, or what's called
CRUD, if you wish-- C-R-U-D. Whereas these,
you always are adding to the database. Two, these databases
use cryptography to have commitment schemes. You may remember, what
is a hash function? It not only compresses
data, but it means you're committing to the data. And when you finish The New
York Times crossword puzzle, you can actually send it in. And if it's identical to-- and hash it. And if you remember our
discussion about The New York Times crossword puzzle, if it's
hashed, and the hashes match, voilá. You solved The New York
Times crossword puzzle. So you can have commitment
schemes for the data. And it can be distributed. Yes, Joequinn. AUDIENCE: So even
if it's append-only, if you take away
the proof of work, you can rewrite it in
a very quick manner. PROFESSOR: So Joequinn's
raising a very important point. So even if it's append-only,
you get rid of proof of work, can't somebody go
in and rewrite it? Permissioned blockchains make
a different trade-off on trust. Permissionless system say,
we're going to address trust through this proof of work. And at least 51% of
all of the network has to, in essence, agree
and validate, and the like. Permissioned
basically are saying, I'm going to trust
the 10 or 15 or 20 nodes that are in the system
can validate against each other. And so there's something
about the club that's authorized in the network. But they're still
using append-only. You're right that
within those 20, somebody could try to
rush through and do a whole entire new append-only. But then within the
club, it's exposed. AUDIENCE: If the club
agrees that the last two days have to be rewritten, they
can do it in a very easy way. PROFESSOR: Correct. But I would contend
that even in Bitcoin, if 10,000 nodes decided to
rewrite the last two days, they could. It's a-- AUDIENCE: Taken a lot of
time, because they have-- PROFESSOR: Yes. AUDIENCE: --to find-- PROFESSOR: That's correct. AUDIENCE: [INAUDIBLE] PROFESSOR: That's correct. So what Joequinn's
saying is in Bitcoin, what protects against that
is partly the proof of work, and partly that it takes
10,000, or at least 51% of them, probably, to rewrite
the last two days. The economic
incentives in Bitcoin is, is why waste all your
computer power and electricity and so forth doing that when
you may as well just go forward? I think Bitcoin could be
susceptible to state actors. I think, you know, if
North Korea wanted-- or Russia wanted-- to spend
probably single digit billions, but at most maybe 10 billion,
they could overwhelm the whole system and bring-- they could do a 51%
attack by buying up enough mining
equipment, the ASICs, and just bigfooting
the whole system. But it's multiple billio-- and
there's academic papers on this now. It's single digit billions. A state actor could-- an individual wouldn't
want to do it, because you'd crush $110 billion
market cap down to [INAUDIBLE].. So that would be kind of unwise. This is a very critical part
of what a private blockchain-- to me, economically,
what a private blockchain can do and facilitate better
than a traditional database. I'm not saying this
list is the only list. I'm not even saying this list
is completely the right list. This is Gary
Gensler's list trying to say, what's the
business that separates traditional blockchains? Append-only timestamping. Some cryptography
and schemes that makes the data immutable so
you can put it in a ledger-- so it's back to
ledgers and so forth-- and thus, finality
of settlement. Does anybody want to remind the
class what settlement means? Anybody? Take a shot. Where's my accountant? Aviva's not here. Oh, please. AUDIENCE: [INAUDIBLE]
do with the UTXO. PROFESSOR: No,
forget about UTXO. Just tell me what
settlement means. AUDIENCE: Oh, like, making
off your debit and credit. PROFESSOR: Yeah,
debits and credits. Settlement means changing
the data in a ledger, and doing it with finality. In essence, do I
have $10 or $11? A payment settlement system
is when you finally say, I've got $11, no longer $10. And Amanda's got
$9 instead of $10. You went down. I went up. Is that all right? AUDIENCE: Yeah. PROFESSOR: Thank you. You'll hear a lot about
clearing and settlement. The word settlement
means to finally change the data in a ledger,
and that we're not going to come back to it. It's done. It's final. If we're moving
something of value-- and the value could be grapes. The value could be diamonds. The value can be real estate. The value can be money. But if we're moving
something of value and storing it on a ledger, it's
more adaptable to blockchain. If you're doing
some database that has nothing to do with
things of value and ledger, you don't need final
immutable settlement. I would contend you
probably have less reason to use any of this
blockchain stuff. Zan. AUDIENCE: Can you
maybe talk a little bit about a real-world
implementation of this? So I saw recently that Walmart
is forcing their suppliers to basically add themselves
into this private blockchain to basically track
their supply chain. I'm having a really
hard time understanding why that needs to
be on a blockchain, whether permissioned
or nonpermissioned, and why that needs to be. PROFESSOR: So the question
is, why is Walmart putting supply chain with a
bunch of agricultural products on a blockchain? Agricultural products
are something of value, whether it's corn,
wheat, grapes. It's something of value. And when it moves from one
owner to another owner, if you keep that
on a ledger, you can record that
Amanda has the grapes, and Gary no longer
has the grapes. And another thing that
blockchains help with is they lower the cost of
reconciling multiple databases. We could keep-- as
in agriculture-- we can keep separate
ledgers, separate databases. The farmers keeping
their database. The wholesaler with
the grain elevators are keeping their database,
and up the supply chain, from the farm, to
the grain elevator, to the millers and
merchants, all the way to General Mills, all the
way to Kroger and the store. Right now, those are multiple
databases that, by and large, don't have to communicate. So the question is, will
Walmart get to the place where that's a good idea? But I'm just pointing out if
you're moving things of value where you want to keep final
settlement that you know who owns that thing of
value in ledgers, and lastly, if you want to
lower any reconciliation-- if you have multiple
ledgers and things of value, blockchain, I think,
is more valuable. Zan's asking, well,
is that Walmart? I don't know. We're going to find out. Tom, and I've got about
seven minutes to finish. AUDIENCE: There was
a talk last year. Somebody [INAUDIBLE] came
in and talked about the-- they were then
piloting this program. But the example they used
was, in E. coli outbreak in their spinach supply, rather
than taking a whole supplier, an entire wholesaler
offline and recalling all of that product,
through the blockchain, they could trace it
to a particular farm and a single point of origin
almost instantaneously and just take off a much
smaller portion of it. PROFESSOR: So let me do this. Let me just-- hold on. I know we've got
two questions here. Let me just hold on, just
for-- is that all right? All right. We got permission. So this was what we
talked about earlier-- Coase's trade-offs of costs. Let me try another
one, which is going to be my shot at blockchains
and traditional databases. So one is access control. Who has access to the ledger? Who has access, if I
might, to the data? Three different types of
approaches we talked about-- open permissionless,
multiple permissioned, and client server. I'm using the word
client server just to say traditional database. You can use another words. But I'm just trying to say
three different types of data structures. And to Zan's question,
why would you be in one bucket versus another? And I'm saying this. If you're a venture
capitalist one day, and somebody comes in to you
with a blockchain solution, this is the same thing. Hopefully, you'll
make it better. This is just my approach to it. Public blockchain-- do
you need, basically, public write capability,
that lots of people can write to these ledgers? Do you need that somewhere? Secondly, do you want some peer
to peer transaction capability across the distributed ledger? Do you kind of not want
any central intermediary? Maybe you don't want
the central intermediary because they're
slow and sluggish. Maybe you don't want
the central intermediary because they have a
lot of economic rents. It doesn't matter to me
why you want to get rid of the central intermediary. But if you want to get rid
of a central intermediary, or lessen their control,
or lower their control, raise peer to peer transactions,
have a lot of public writing-- oh, and by the way, if you
want some token economics, you're probably
somewhere over here. I'm not saying you
have to have all four. But to me, those are
the kind of three or four things that
are floating around why you might be over there. Private blockchains--
well, maybe you actually don't want public
write capability. You need private. Whether it's just the Australian
Stock Exchange or 15 to 20 club deal, you still want kind
of multiple people to write, but you want it to be private. But if you still need finality
of data and an append-only log, that you need this appending-- the log, and you need
some public verifiability, that you still need that
data to be verified amongst-- and this public means
15 or 20 players. But you need it to be
able to be verified-- so the trust mechanism is
not thousands and open. The trust mechanism is
15 or 20 or 5 parties. But you still need it-- you might be there. Where I come out is there's
some cases that you just don't need any of this. There's a trusted party
that hosts the data. Your trust mechanism
is one party. The trusted party can do the-- I use the letters CRUD. That's the create, and update,
and delete, and so forth. And that's based on client
service architecture, this client server architecture. There's always, in that
circumstance, somebody right in the middle that
basically owns, updates, governs that
whole architecture. My business judgment
on this is if you're moving things of value, you
want those things to value to have some final
settlement and immutability. And immutability
append-only logs give you some of that final settlement. We talked very briefly
about a lawsuit that was 300 plus years ago--
the Crawford case in Scotland that you won't have to remember. But this-- watch this. So steal this from me. Just do me a favor. Just steal it. OK. Right now, I have
a right of action. But if you give it to-- who
are you going to give it to? I don't have any
rights against you. No. Well, wait. It depends whether he
knew you stole it from me. But it's gone. That's final settlement. Those $2 are gone. That's final settlement. It's immutable. I can't get them back. What, Christopher? You want them? AUDIENCE: I just was
asking for the money. PROFESSOR: You were
asking for the money. I just use that as
a visualization. Money is a social consensus
and a social construct. But if you think of it
in terms of ledgers-- look, the money's gone. I can't get it. That's it, you know? That's good. You all go to Sloan, I can tell. Yeah, yeah. But it's an important concept. I think of this whole that way. So there were two
questions, and then we'll-- and then this is the
decentralized end. Bitcoin and Ethereum are kind
of at the decentralized end. I would contend Bitcoin's more
decentralized than Ethereum. And centralized databases--
initial coin offerings that we'll talk
about later, I think, are actually maybe
a little bit more centralized, even, than
permissioned blockchains. But we'll get to that. AUDIENCE: No, mine
was already answered. And then the other
comment was more about the supply chain link. When you think about the
millions and millions of dollars, the
element of transparency that blockchain kind of
brings in to all the parties probably saves an
insane amount of money to what you're talking
about kind of reconciling all the databases. PROFESSOR: So
we're going to talk about finance next Thursday
and some of the strengths and weaknesses in finance,
and some of the attributes, and you know, one
of the readings-- Sheila Bair-- and
there's a bunch of optional readings
about what's happened after the financial
crisis and so forth. And then we're going to
talk about the economics. But I've had three or four
groups come in already talking about the final projects. So I'll just say, think
about whatever you're working on as this new
technology-- blockchain-- whether it's permissioned
or permissionless-- either one-- does this new
technology really address some pain point that you're
trying to solve, whether it's about
payment systems or-- actually, there's a group
that's talking about doing supply chain on wine. And I figured, why not? I'll probably approve it. But it's, what is the pain
point that you're actually trying to solve? Or will decentralized
peer to peer networking somehow create a business
opportunity in a new model? It might not be a pain point. It might be a
business opportunity that decentralized
systems solve. Or it might be an opportunity
that token economics can help solve. But if there's no pain
point you're solving, no token economics, no
decentralization peer to peer, I ask you to use your
critical reasoning and move to the next use
case, because this is really about-- this is
a business class. This is about finding places
for this incredible set of new technologies in
the context of markets and to have a really
healthy sense of ground truth about what's possible. If not, traditional databases. Move on. I'm not looking for
projects at the end of the semester that are
using traditional databases. It's got to really
use blockchain. So I thank you. I'll see you next Thursday.
