利用加密技术设计金融基础设施：MIT 公开课

[SQUEAKING] [RUSTLING] [CLICKING] ROBERT TOWNSEND: So today, I'm going to give this application lecture using encryption. So Sam and I have been working on market making, combining economics and computer science, and Sam's going to present that on Thursday. Looking forward to it. All right. So today, designs of financial infrastructure utilizing encryption, and I'm going to go through three examples today varying in detail.

One is an auction, which is a familiar setup, but we'll be encrypting it. Then I have this what I call hybrid credit and insurance, having to do with insurance against balance sheet shocks in various contexts. And then finally, a market implementation using encryption. So first, we'll do the auctions. So auctions are used frequently, but they're typically organized by a third party. And the example here is Mortgage Capital Trading's use of a trade auction manager.

Worrying that perhaps this slide was a bit out of date, I checked this morning on the web, it's alive and well. So Mortgage Capital Trading is still being used, as are many of the others. But trusted third parties like Mortgage-- the trade auction manager there are not always needed, and in fact, they're not always beneficial. So what are called these "bid-wanted-in-competition" dealers are asked to bid on a list of securities.

Not necessarily securitized mortgages in the first example, but much more generally. And there's a typical, as you could imagine, abuse, or at least potential abuse, where the auction manager is on the phone, he's the seller of the asset, so he has an interest in making the price high, so he calls buyer A, he says, I prefer you, my friend, but buyer B just offered a slightly higher price. So if you can just make some effort, the good-- is the security is yours.

But at the same time, he's saying exactly the same thing to buyer B for this example, just say there are two buyers, which has the intent of propping up the price. And of course, neither A nor B can check on what this manager is saying to other clients, and neither can they check on the bids that are coming in in order to verify the claim of the auction manager that, in this case, buyer B was a little bit off. Not to mention, it's potentially improper to be doing that in the first place.

It's not the only example. China had, at one point, these P2P platforms, and there have been articles written about what investors were being told or not, and one of these articles pretty much documented a kind of cream skimming where AI was running over securities that could be put in the securitized pool, but some of them-- some of the prime ones were not put in the pool and were held by individual investors, but other investors were not informed that this was going on.

And China eventually got rid of these P2P platforms altogether. OK. So how do we do an auction without an auctioneer? The answer? Use the tools that we're just learning, homomorphic encryption and multi-party computation. And I'll describe, in the slides that follow, two ways of doing this, and both are instructive. And we're going to be focusing not on the seller with the asset, but the messages that go back and forth, so they're not communicating with the seller.

So the seller is kind of in the background here. First scheme, each bidder has his own server. We haven't spent that much time on infrastructure, but it's, of course, crucial in any application. So in this case, they're going to use their own servers. There are going to be two bidders. And they're going to encrypt their messages, which are their bids, and those bids are going to go-- encrypted messages are going to go back and forth among these two or more bidders.

There's no third-party server. There's no contract node. In particular, each buyer sends his encrypted bid with public-private key pairs, as in homomorphic encryption, to the others, and for the multi-party computation part, they send the results of these encrypted messages to each other. The second scheme-- this is just an outline slide-- is with a contract node. So all communication goes to a third-party server where the contract node resides.

So communication is with these encrypted messages. So the, quote, "server" doesn't see the private values. The server is doing in the code what the agents were doing in the first scheme. It's hard not to refer to this contract as a person, but it isn't, it's just code. I think we call it a pseudo-agent in the subsequent slides. OK. So we've got these in the first scheme, two agents A and B, and they want to see whose bid is higher and who is lower without relying on the trusted third-party seller, but without revealing to each other the exact value of their bids.

And I will forewarn you from the get-go that 2 turns out to be special, but the idea of the example does generalize. And I'll show you where the special revealing feature happens at the end. OK, so this BFV encryption algorithm, which is ring learning with error. I showed you one slide last time with the polynomials and the coefficients of the various orders of terms being drawn from integers and so on, so this is that scheme.

There are private and public keys, of course. The public key is this a, delta. The secret or private keys are the s, e terms. But again, this is in the space of rings, which are polynomials with these integer coefficients modulo some first-- some order polynomials. So we're going to take polynomial operations of addition, multiplication, and so on, and always apply this quotient to get it down to, say, an n minus 1 degree polynomial.

Then this error term is like a normally distributed random variable that's added on for extra noise and security. And I'll show you-- remind you, really, more on that momentarily, but we end up with these private-- sorry, public secret key pairs. a, delta are common across the agent. That's the public part. They're going to draw these public-private keys-- the public part is going to be published on their servers and broadcasted more generally, possibly.

And the private key parts, secret-- see how I keep mixing up my p's? The secret key part is si and ei. And you'll see in a minute, when I give you the example, specifically where a and delta enter and where's si and ei enter. It's only the secret keys that are indexed by the agent, obviously, because the public key is common. So here's the example of why we need the noise. This is just matrix-- a system of linear equations.

We got a 7-by-4 matrix multiplied by a 4-by-1 column. So we're going to-- the answer is going to be a 7-by-1 column. And the secret is supposed to be what's in red there. If this was a non-singular square matrix, we could just invert and multiply by both sides. That's not necessary. Gaussian elimination, which works row by row, can also solve the system of equations, so the red secret would be revealed. AUDIENCE: What is the blue thing here.

What is-- does that map to our alpha, delta-- ROBERT TOWNSEND: You're like seeing the blue stuff and you want to-- and we want to prevent outsiders from deciphering the red. AUDIENCE: I see. OK. ROBERT TOWNSEND: So we add in a 7-by-1 column vector with noise, and that, in principle, very hard to decipher the red. AUDIENCE: The blue is not invertible, so-- ROBERT TOWNSEND: It's not, no. But Gaussian elimination can solve this system.

I checked it this morning. AUDIENCE: Yeah. So if I know the blue stuff, and I want to know what the red stuff is-- I see. ROBERT TOWNSEND: Yeah, yeah. That's the idea. This thing with the noise, i'll just remind you, because I had a slide about MPC last time with the secret sharing. And I drew this analogy to who is the richest person. And I didn't quite pull it off, but you'll see it coming back today. The main thing is, in that example, one person had a secret, added noise, passed it down the line to the next one, who had a secret, and added noise, and then we summed that up, and we went all the way across the first row at the

原文超出正文长度上限，此处截断——上游还有内容，完整版见上方「原文 ↗」。