Session 9: Permissioned Systems

• Download English-US transcript (PDF)

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.