Lecture 1: Introduction to 14.129 Blockchain and Design of Financial Systems transcript

[SQUEAKING] [RUSTLING] [CLICKING] ROBERT M. TOWNSEND: So today, what I want to do is to tell you about this class and its contents. So it's 14.129. And the correct title is Blockchain and the Design of Financial Systems. It's incorrectly listed in the registrar's office as Advanced Contract Theory, which is true, but we're going to focus on this topic. And the way I'm going to organize today is to jump right in and tell you the contents of each of the lectures.

It's a bit tricky in the sense that I don't want to actually give each one of those lectures. That's going to happen as the class evolves, but I want to give you a good sense of the topics we're going to be covering and a bit of the way we're going to be covering it, and in particular, featuring this blend of computer science and economics. And after I scroll through a summary of the lectures, then I will turn to the syllabus, tell you a review, again, more about the organization of the class.

And I'll also mention a parallel class and its contents, which are relevant, but not a requirement. And that way, you'll see how everything fits together, ideally. So this is a synthesis of computer science and economics. The buzzwords, so to speak, of computer science will be cryptocurrency, blockchain, tokenization, platforms, and computational algorithms. And the buzzwords, so to speak, of economics are going to be contract theory, mechanism design, general equilibrium theory, and monetary theory.

So we're going to try to get these items on the same page. We want to understand topically the assumptions and shortcomings of three objects-- distributed ledgers, smart contracts, and encryption-- and the potential impact that these technologies have on legacy systems and explore the possibilities for new financial design and the implications for regulation. So each lecture, as you shall see, or at least a cluster of lectures, features one or several of these computer science technologies and doing that in the context of historical or contemporary applications and in that context using the various economic tools.

So examples that you'll see more momentarily-- community currencies, coordination and financial crashes, tokenized assets and trade fails, multilateral payment and trade credit set-offs, liquidity injections, and financial contagion, risk-sharing auctions, and online markets. So the goal here is to unpack these different computer science technologies and their assumptions, sometimes rearranging them rather than accepting conventional bundles and labels.

There is a lot of difference of opinion about these technologies, a lot of hype and exaggeration on the pro side of what can be done with them, but also a lot of criticism on the negative side of Bitcoin and cryptocurrencies and so on. So we want to set this polarization aside and get in the middle and be objective. So for example, we can combine the authentication and commitment schemes of encryption with an automated execution engine on a distributed ledger.

That's the standard package. But we can also do this with computer code without a consensus algorithm or even use trusted third parties and escrow accounts. So we're quite open to and should review alternative ways of implementation. Another way to put this-- different technologies allow different implementations of the central planner, which is econ jargon. You'll see more. That's a key construct of economics. We can gradually abstract away the centralized role of the central planner into concretely deployed mechanisms and into commercial applications.

So we're shooting for this balanced perspective, avoiding the hype and ideological positions, focusing instead on ways to implement use cases, allowing policy designers to leverage these tools for the different problems that they're facing. OK, so lecture 1-- 2-- 1 is today-- is about the blockchain. On each of these slides, as I go through lectures 2, 3, et cetera, you'll see a longer title, which is more descriptive of the components.

So this lecture 2 is about a unified view of distributed ledgers and financial accounts, thinking of them both as databases, distinct views of money, and also providing a larger community perspective. So blockchains and financial accounts are each a database of transactions. And so we're going to think about it that way. However, each is associated with a notion of money. As I've already anticipated, for the blockchain, we think of Bitcoin and cryptocurrency.

And many people stop thinking about it after that. For financial accounts, money is a particular item on the balance sheet of the holder. For example, Fiat money or demand deposits in a commercial bank. So it's also a liability of an issuer, but the truth is that each of distributed ledgers and financial accounts are broader and do not require us to force either one into the construct of money. So these evocative pictures are more details coming next time on Thursday about financial accounts.

And this is actually the blockchain picture of what's going on with the databases. So you basically have data that are hashed pairwise, hashed again, and hashed the third time. So this is basically an archive system that allows you to uncover the individual transactions on, say, Bitcoin. So block, chain, together-- that's where the terminology comes from as a database. OK? Both blockchains and financial accounts can incorporate multiple objects.

And from a monetary perspective, that's fine. You have goods or assets or certificates that, in a monetary theory definition, appear frequently in exchange. So we have-- you can barely see it-- a matrix of transactions of grain, clothing, labor, money, IOUs, and so on. And we count up how often they are used as we are, say, looking at an individual household or aggregating up to a village or the US economy. So a money is something with a high velocity that appears frequently in exchange or the amount traded per unit outstanding is large.

So it's fine to have multiple monies. In this picture that you can barely see, you would notice that grain is actually being used as well as money. Workers get paid in grain, and they use used the grain to purchase other items. And you have IOUs that are denominated in money and IOUs that are denominated in grain. And all of this is coexisting. And you have objects that rarely appear except in the bilateral exchange.

The point here is that blockchains are broader and the financial accounts are broader. Blockchains in particular are a way to write and execute contracts. So you take the concept of a balance of an item and the transfer change in the balance, as in a transaction. That generalizes to the balance as the state and the transfer corresponds to state changes. So with that simple change in vocabulary, we're writing contracts on the blockchain.

An interesting difference, tension really, appears with an individual versus community perspective. From the financial accounts perspective, where money is an asset, the tension is store the asset as a store of value on the one hand, or use it in transactions. And the more people are, shall we say, hoarding it, the less they're going to be using it for transactions. And we could have a liquidity shortage in the market, even though from each individual's point of view, they're being rational.

Now, very much surprising from a financial accounting perspective-- if you go back to the invention of double entry bookkeeping in Italy with Pacioli, he embraced a community perspective, not individual accounting perspective. And for him, money-- yes, you could hold it, but it was really a liability, not an asset. It's a liability in the sense that there was an obligation to spend it to accomplish some community objective.

I promised you balance. So nothing perfect about the blockchain. There's a theorem in computer science called the CAP theorem, which is an impossibility theorem that you cannot have all three of consistency, availability, and partition tolerance at the same time. And so you have to make choices. And that same trilemma can carry over and allow us to interpret village economies and contemporary US economies and so on in the sense of having to make choices.

Well, again, just to repeat, I don't expect us all to completely understand these slides. I'm trying to give you an introduction to what we're going to be doing in more detail in this case on Thursday. So I'll resist the temptation to lecture in too much detail. So this part is having to do with the opportunities of the course, which is these so-called readings, which are featured. Here we have Agustin Carstens, "The Future Monetary System-- Vision to Reality" from the BIS.

Relatively recently, this strange thing called "The Baby-Sitting Economy," which Paul Krugman reviewed, has to do with an object, which are babysitting coupons or certificates that were used in exchange and analogies to money and what can go wrong. Goldstein and co-authors explore this tension in real-time gross settlement between "Payments, Reserves, and Financial Fragility." And De Meijer is an article about Kenya, where cryptocurrency blockchains are being used to serve the purpose of targeting poor households in rural or urban communities.

So in the lectures, I touch on these articles, but the main reason they're here is for your interest. These or other papers may be something you would like to explore. And there's, as I'll say later, no midterm, no exam. It's all about research. So you have the option to pursue what you're interested in most. And we provide some pathways. So at the end of each of these lecture two-page summaries, I'll just list some of the papers.

OK, lecture 3 goes back to these tools-- in this case, distributed ledgers-- and what you can do with them. The longer title is Fragmented Markets, Policy Objectives, Regulatory Solution, and Distributed Ledgers as a Technology Solution. We're going to put some friction in the markets and then see what problem emerges and how to remedy the problem. Sometimes, there are regulatory solutions, as in this US national marketing system, the way the US does the regulation.

And we will also feature the use of distributed ledgers as a solution to an information problem. Now, time and time again, when you're reading on the web, you'll come across a use case or an objective, something perhaps the private sector is doing or central banks are doing. And they just launch right into the application. Why? What are they trying to accomplish, exactly? Heaven forbid just use the new technologies for the sake of doing it without thinking about social welfare.

So we will get into this. Economists have a criterion typically used, called Pareto optimality, which is a weak standard that says whatever is going on currently, you should not be able to make some participants better off without harming other participants because then there's a gain for everyone. So it could not possibly be efficient the way it is. So these slides have to do with prices should be equated, even if we have fragmented markets, which is what the US is doing.

They look at the execution of stock market trades and have regulations that try to make sure people aren't being cheated and buying things more expensively than they would have if they had bought on a different exchange. The blockchain point of view is let's fragment the markets artificially, take that as a given, and then try to achieve what would have been a competitive outcome or an efficient outcome with agents constrained to be trading with each other pairwise in these fragmented markets.

And what happens here is that even if you impose the correct prices, it is, in general, impossible for agents to solve the problem in a decentralized way, looking at their own histories or the histories of people that they've met. It's just like programming code and deciding what information the code is allowed to use or would be required to use in order to get to the objective. And bilateral credits and debits are, in general, not sufficient.

You need to invoke this community perspective, like the common but distributed ledger. These pictures at the bottom are like a balance sheet at a point in time and the transactions that change the balance. And they evolve over time as an individual is trading. And having individuals see only their own accounts like this or even those of their trading partner will not allow you, in general, to get to the Walrasian outcome.

Now, you may think there is a way to do better with money, just like a decentralized system where you carry around your own cash or e-credit and spend it as you wish, each person doing that. The problem is it takes an enormous amount of liquidity for agents to achieve the objective of the efficient Walrasian allocation. So the decentralized way in which we're used to thinking about money is actually inadequate. And in any event, in real-time gross settlement systems, there's a misnomer because if it really were instantaneous real-time, you'd have to have a lot of liquidity for banks to be able to honor presentation of commitments due.

So almost simultaneously, with the coming of real-time gross settlement instead of end-of-day settlement, there came this quest to find liquidity-saving mechanisms. And Ostroy and Starr anticipates this. Another thing you could do is have a warehouse facility so nobody trades until they meet the big trader. And what goes wrong? Well, a couple of things. That trader would have to have enormous inventories of all the goods or assets in order to honor the requests for outflows.

And likewise, having a very big trader like that, he or she will be tempted to exploit their market power, which I claim we also see in practice. And I'll show you more when we get to this lecture. And finally, you could think, well, why money? Why not credit? Let's just have deficit accounts, overdraft accounts, and let people spend out of those accounts. Well, that's a little bit like the end-of-day settlement. And the problem is people show up having bought more in value than they sold.

And they can't honor the commitment to balance their account at the end. So that's like a default, and we see that a lot. So this theory article is amazingly capturing a lot of the current institutions we see, but remember. We're talking about a blockchain-- distributed ledgers as a way to solve those problems. OK, so again, a hint of things to explore. Chester Spatt has written, with his co-author, this "Regulating Market Microstructure." You can read all about what goes on in the US in terms of regulation and other related articles, or this liquidity savings mechanisms that I've already talked about, as described in Martin and McAndrews.

This Alcazar has to do with a very concentrated provision of core banking services-- in other words, imperfect competition. And the "Tri-Party" paper is about these enormous potential liabilities that the Federal Reserve took on in the operation of the repo markets, often having within middle-of-day liabilities, larger than the entire US money stock. Of course, they figured it out eventually and tried to fix it. So again, as your interests emerge-- and you can browse and then decide no, I don't want to go down that path.

That's fine. OK. So featured distributed ledgers-- now, I want to feature smart contracts, and also how you can use them, in this case, as a solution to a coordination problem. So here we're going to have the commodity space being locations and dates and randomly realized dates of the world, but we're going to stick with this Pareto criterion for efficiency. And with fragmented markets, we will try to implement the solution with privately issued securities or monies.

They will be high velocity and circulate in exchange, but it's going to lead to a coordination problem and to crises. And the solution will come with this multi-agent smart contract. So this picture is meant to evoke that agents are getting partitioned. They're either in one location or another. We settle for two. They meet pairwise like that in trade, but then they get buffered around and sorted with different agents in yet other locations.

And they can issue these securities that circulate. One can issue a promise to pay at date 4, issue it to 2, 2 carries it to 4, 4 trades to 3, and 3 presents it for redemption. So this private security, this IOU, will circulate in this model with high velocity. That's fine. It's a privately issued money. The problem is there are other privately issued monies issued in the other location. And if you don't have this coordination problem solved, they may incorrectly anticipate what's going on in other locations where assets are being issued, but they cannot see that.

And if they guess incorrectly, you'll get a crash. Now, we see this in theory very clearly because we've simulated the model. And I'll show you that in this lecture 4. We've also seen it historically. So Walter Bagehot was describing the money markets in London, where these bills of exchange were circulating with high velocity. But then there are these periodic crashes. And I was over the break in London at the central bank, went looking.

It occurred to me-- I was too early for my appointment-- to look for Lombard Street. Lombard Street is still there. And that's where the first clearinghouse was ever established. So it was real, and it was the center of the world's money markets. And what was going on then several hundred years ago is still-- we still face those problems today. There are related things. There's a concern in low and middle income countries with this digitization that is emerging and the fact that it's not coordinated.

So parties will be having to basically cover balances without having the assets, like a big liability. That's a concern in some of these countries. And likewise, even with Decentralized Finance, or DeFi, which are these markets for cryptocurrencies, there is a concern that we don't have enough liquidity or that there is a liquidity problem. So the solution to these problems turns out to be available now with the distributed ledger and smart contracts.

So these articles are using the Pareto criterion to explore whether or not you need to intervene. In this case in the US, the paper by Gorton is about those bills of exchange in England and how-- he calls it private money production without banks. Bagehot, I've just shown you on the screen. Sargent and Wallace is the paper about real bills versus the quantity theory, having to do with causes of inflation. The quantity theory is that inflation is determined by the quantity of money, and we should be careful that all monies be limited in supply for that reason.

The real bills doctrine says no, that's wrong. Financial intermediation is fine as long as there is real backing for the liabilities, the so-called real bills doctrine. And this is the basis of a debate that is still going on today that is relevant for central banks like the US Federal Reserve. And I've mentioned the liquidity fragmentation. OK. Lecture 5 goes further in exploring tokenized and programmable assets. So now, the ledger has become dynamic.

We can talk about atomic trade and settlement and do that on platforms and compare these tokenized immediate settlement assets on the blockchain with the current legacy systems where there are trade fails. So the buzzwords are tokenization and programmable assets that are made possible by multilateral smart contracts. Now, when you think about the accounting point of view of legacy systems, one thing that hits you is the balance sheets, assets, and liabilities should not be just simple static representations of a trader's assets and liabilities.

It should be a dynamic, explicit representation of future assets and liabilities that they contract for under these multilateral smart contracts. And likewise, you can agree for trades into the future and commit to them now. So you have this odd juxtaposition of immediate settlement in the sense of not only trading, but committing to the outcome of the trade, whereas in legacy systems, it's end-of-day or t plus 3. And you may or may not get the asset you thought you purchased.

And the guy with the money may not show up or vice versa. The asset is not there when you need it. So this little example here at the bottom is about three agents, simple prototype, where it's asset lending. And they want to hold different levels of the asset at different points in time as an example of multilateral asset trades. I mentioned the legacy system and trade fails. And it's shocking at first, when you first read about it, the magnitude of the fails.

So for example, here are treasuries in it says, billions of dollars. But 10,000 billion-- we're into the trillions. So we're measuring here the value in dollars of trades that were agreed to, but not executed. So it's, quote, "arguably a big problem." Now, the blockchain isn't a cure-all, either, because various problems would emerge, as will be clear from that example. If it were the case the asset can only be programmed by someone who currently holds it, then entering into a trade could reveal information that they would rather keep private, which, in turn, may mean that they're not going to get a good price.

And there are potential solutions having to do with centralizing these markets or being able to use the conditional release function on the tokenized asset, which we can talk about more later, or with encryption. But in general, these systems that emerge may be only partially interoperable. And even the tokenization raises issues of trust if, in fact, it's a pre-existing asset that has to be put in escrow in order to allow us to tokenize and write code on it.

You're relying on the issuer to hold it to the escrow account to be valid and for them not to cheat and use the asset. It's got to be there when you need it. So there are various explorations going on among domestic central banks and international agencies for a cross-border exchange problem. Such a blockchain has been proposed for foreign exchange transaction. And the BIS has now switched gears a bit and is proposing unified ledgers even for domestic systems.

But we have to be careful that, in fact, we don't end up violating the coherence guarantee, which is a big feature of what you can do with these multilateral smart contracts. So again, these readings-- read all about settlement fails, understand better this risk of tokenization, be mindful of what it means to have programmable money with this coherence guarantee. And these two lines at the end have to do with what we're seeing out there currently from the Swiss National Bank and other consortia of large banks.

So again, each of these, the last in particular, are options for you to explore in your readings. How does it work, exactly, critique it, understand it better-- would all be potential projects. OK, so moving on, we come to algorithmic flows on networks as solution to multilateral settlement problems. Or the longer title is How to Improve Financial Infrastructure-- Taking Advantage of What We Know about Network Cycles and Chains Using Algorithms to Maximize Timely Payment of Multilateral Trade Credit Offsets, or alternatively, back to the US repo market-- what to do about credit guarantees, time permitting.

So we put the obligations of, say, trader I to pay trader J on a network diagram. So for example, A owes 2 units to B, B owes 2 units to C, et cetera. C owes 1 unit to A. So those edges, when they connect the two nodes, represent a liability for one party and an asset for the other party if it's paid. But agents can be indirectly connected in various complicated ways. In fact, when you look at an actual picture of networks-- this is Italian data-- you can actually see the individual nodes and the edges because they're just tens of thousands of transactions.

So you can begin to conjure up this interconnectedness, which is very complicated. In fact, individual agents are very unlikely to know much at all about the overall structure of the network. They'll know their own assets and liabilities, maybe a bit about their partners, but not much more than that, typically. The second problem is even if we had a multilateral smart contract node that did have the complete knowledge of the network, like a community ledger, it would still have to determine the ordering of the payments.

Does A pay B, B pay C, then C pays A? But B has to be paid first in order to pay C, et cetera. It becomes a very large combinatorial problem to figure out the correct judicious ordering of the payments. And finally, even if there were a liquidity pool or some kind of overdraft facility that, in principle, could maximize the amount cleared, you'd still have to decide where to inject the liquidity, how much to inject, and how to recover that liquidity at the collection point in such a way that the system still remains balanced.

So these problems are very typical. Here we're, in this lecture, going to feature the problem of trade credit overdues and how to have this multilateral set-off, either clearing enclosed cycles or injecting liquidity through chains. You can better see that here, where this, what's left of it, is going to turn out to be a closed cycle, where one is paid, paid, paid, and it clears, but the red is the liquidity injection from the source to the target, which also clears a lot more of the trade.

Oh. So for this lecture, I have invited Tomaž Fleischman, who is a collaborator in this work, who is a computer scientist and also helps run a company with a blockchain. So he will tell you much more in that lecture, lecture 6. And there's, indeed, Fleischman with his co-authors, "Liquidity-Saving Obligation." There's a lot to read. I just picked one of his papers. You may, depending on how far you are in your studies, recognize this Cormen, et al. book on Introduction to Algorithms.

It's co-authored with MIT professors. And again, time permitting, we could get into the repo market. I put this here because if we don't do it in class, then that's an option for one of you in terms of your own research project. So the previous slide, lecture 6, was something static, but you can make these networks dynamic and stochastic. So this is a picture of the federal funds market. And you can see, depending on the time of day, the evolution of the network where these traders are, again, are connected with edges.

So in this case, we go back to the basic general equilibrium idea of keeping track of dates and states of the world, but in this case, not just for incomes, but also for who's trading with whom. So that's a larger state. And it becomes a risk-sharing problem to try to stabilize consumption out of income. And then think about injecting liquidity in this context. So if extra liquidity were available, say, from some new monetary policy-- because that is not the standard way that monetary policy is implemented, but it could be implemented on these blockchains-- who should get the liquidity?

And the answer is going to turn out to be the most valued node or recipient of the liquidity, assuming that they have to get the money in advance, would be a trader that participates in market clusters, even when the number of total participants is low, when there's aggregate correlated shocks to those in the cluster where average incomes and yields are low for those in the cluster, and where agents are very risk-averse.

So we have a criterion to determine the most valued players. You would see this in large financial markets if we thought of a bond which pays off when someone is in the market. An individual I-specific bond-- the value of that bond would be the value of this key player. Or in village settings-- and we've done this-- key players turn out to be people who are, as the theory says, participating with other agents, even when there aren't very many transactions.

And those agents turn out to get higher consumption on average, as if they were receiving a premium, all of which is informal. And they don't use that language. And then a juxtaposition. There is another literature that seems to start out the same way-- financial markets with nodes and interconnectedness-- but it's a literature about contagion. There the idea is that traders get hit with an adverse shock, like a disease, and it's contagious, and it spreads to other traders.

And that argues for limiting markets. It's exactly the opposite of the risk-sharing point of view, where you want to increase the number of traders in order to allow risk mitigation. And this picture is just meant to tell you that these two notions of financially central players are different from one another. And I will go into more detail on that later. Here's two papers, this Contagion! book-- exclamation mark-- Systemic Risk in-- that's the framework policymakers are using today.

This is the way they think about financial markets. And so they're trying to limit the damage that would happen if something went wrong rather than the other perspective, which is to try to make markets stick. So you can explore the book with its many chapters. And Martin Sumner has a very nice review piece about financial contagion. OK. So then we get into mechanism design, and in particular, incentives to follow protocols and notions of trust.

So the longer title is Private Information, Incentives to Report and Take Actions, the Byzantine Generals Problem, Differences between Economics and Computer Science Approaches to Trust. So when we do mechanism design, we're clear about the incentives to report the truth and take appropriate actions, as with an insurance company prepared to cover the loss of a client, but the loss is private to the agent, who will be inclined to lie about it in order to get the indemnity, although there are ways to mitigate that problem.

Implementation looks like we might need that central planner that I mentioned earlier, implementing the smart contract code, but we really don't need the central planner at all. We just need the code. The code can be validated by agents in advance with a public commitment to carry out the plan. The payouts that might be necessary can be put in escrow and programmed, as with the dynamic assets, to be available when needed.

Messages about claims can be recorded and put into this database of the contract. And implementation does not require implementation on the blockchain. This layer 1, layer 2 terminology has to do with having the code with the smart contract taking messages from the agents about the state of their ledgers and assigning new balance sheet positions based on what they claim. And I mentioned at the beginning this pragmatic point of view, that you don't have to have every piece of the blockchain in order to make good use of the technology.

This is an example of that. In contrast, the computer scientists tend to rely on parallel computing notions of failure. So the idea is a given computer can fail or give an incorrect answer, but if you're able to put a bound on the probability, then if you have a sufficient number of computers replicating what should be the same outcome, you can determine the truth of the matter. And they use the same framework to think about rogue traders.

That is to say a certain number of evil people could not follow a protocol, but you design the protocol that's tolerant to that, as in Byzantine fault-tolerant validation algorithms. The Bitcoin with its proof of work is, again, a way to-- by effectively randomly choosing the proposed truth of the validation, the odds that you would choose a rogue trader to do the value can be small if there's a large number of people trying to do the proof of work algorithm.

And this bottom part here has to do with the Byzantine generals problem, having to do with two generals who have to communicate with one another. One gets the signal. The enemy is prepared. You don't want to attack if the enemy is it's prepared. But even if the enemy is unprepared, you have to communicate to the other general. And these messages may fail to arrive with a certain probability. There is a protocol that works quite well if agents follow it, which is for the second general to attack under certain conditions.

I won't go into the details, but that protocol is vulnerable to the economic concept of incentives and Bayesian Nash equilibrium. Traders can convince themselves to never attack, actually, even when the enemy is unprepared because they're second-guessing and third-guessing what the other guy is doing. So we'll talk about that more in lecture 8. Here are two articles on computing and mechanism design and distributed ledgers and the governance of money that both have to do with computing and validation algorithms.

So again, these are options for you to consider when you're thinking about reporting in or doing your research proposal. So we finally get, in lecture 9, to the third leg, so to speak, of these new technologies. We covered distributed ledgers and smart contracts. And now, we get to encryption. This little picture over there is meant to remind you that keeping secrets has been with us for a very long time. In Mesopotamia, they used to create tokens as an invoice of what's in the shipment.

And they put those tokens in a clay envelope and baked it hard and then wrote little pictures of the internal tokens that accompanied the shipment. When you think about it, you begin to realize that it would be very, very difficult for someone to steal the shipment without the knowledge of the recipient when it finally gets there. So it's a bit like private and public keys, which are the centerpiece now of modern encryption.

It allows people to send a secret message. And the recipient can decipher it. For outgoing messages, it allows a receiver to authenticate the origin of the message, know who sent it so the sender cannot repudiate it, and verify the message has not been modified. So these are very powerful tools related to hashes and cryptographic puzzles, also to fully homomorphic encryption, which, with the math of it, is like setting up parallel spaces that are one-to-one, the actual text versus the encoded system.

So you can do addition and multiplication on these encrypted systems and end up with the correct answer, even without knowing the actual inputs. And multiparty computation is another leg of this including zero-knowledge proofs, which we will go into. And these are papers, one by this Harvard professor on zero-knowledge mechanisms, which is a mechanism design problem. And again, back to-- see, in practice, chain link, layer zero, and this new Dfinity internet computer in your readings to see.

So these are actual implementations that industry and central banks are adopting. Then in lecture 10, we will go through designs using encryption for auctions, for example. We can encrypt the bids and nevertheless determine the winner. We don't need some third-party auctioneer who is in a position to cheat. Back to that insurance example with agents experiencing shocks to their balance sheets, which they would like to have insured but don't want to reveal to third parties the state of their balances, we will show how to handle that.

And the information here gets scrambled up so no one has the whole picture. And yet somehow, amazingly, the code can do what you want, including randomize at the crucial key moments, even though the code, quote unquote, "is not a person," and does not know the underlying true state. So you get these miracles happening using fully homomorphic encryption and multiparty computation. And you can use this also for centralized matching of agents who submit supply and demand schedules, but they're encrypted.

And nevertheless, you can basically intersect supply and demand schedules in the encrypted space and figure out the equilibrium outcome. And you can put encryption, as in these papers, including this work that MIT is doing with Visa on encryption in the blockchain. And finally, we get lecture 11, which has to do with this juxtaposition-- on the one hand, Dubey, "Price-Quantity Strategic Market Games," which is a classic economics paper on an implementation that gets you to the Walrasian outcome.

And on the other hand, we have SPEEDEX as a decentralized exchange that bears not a small amount of similarity to Dubey. And we need to put those things together somehow and deal with the fact that we have many, many agents, each with their strategies. And it is typically hard to find the Nash equilibrium that we're looking for. It's computationally complex, certainly at the level of individual agents. So this ongoing work-- the idea is to allow the algorithm to compute the [? ideal ?] candidate for the equilibrium and then signal to the agents what their strategy ought to be.

And they know that the mechanism operates that way, so they don't have to have endless conjectures and what-if statements about what the other agents are doing. So that work is based in part on Daskalakis. And Costas is, as you guys know, a computer science professor here. So those are the 11 lectures. I hope you did not find it too bewildering. It is hard to go through it without getting into the details. And yet we always move on to yet another lecture.

I was taught somewhere that if you're teaching well, you tell students what you're going to do and then do it, and then tell them what you did. So this was in the spirit of here's what we're going to do.