WEBVTT 00:00:00.000 --> 00:00:00.984 align:middle line:90% 00:00:00.984 --> 00:00:02.436 align:middle line:90% [SQUEAKING] 00:00:02.436 --> 00:00:03.888 align:middle line:90% [RUSTLING] 00:00:03.888 --> 00:00:07.276 align:middle line:90% [CLICKING] 00:00:07.276 --> 00:00:10.980 align:middle line:90% 00:00:10.980 --> 00:00:14.120 align:middle line:84% ROBERT TOWNSEND: So today, I'm going to give this application 00:00:14.120 --> 00:00:16.280 align:middle line:90% lecture using encryption. 00:00:16.280 --> 00:00:22.720 align:middle line:84% So Sam and I have been working on market making, combining 00:00:22.720 --> 00:00:26.080 align:middle line:84% economics and computer science, and Sam's 00:00:26.080 --> 00:00:29.680 align:middle line:84% going to present that on Thursday. 00:00:29.680 --> 00:00:31.380 align:middle line:90% Looking forward to it. 00:00:31.380 --> 00:00:31.880 align:middle line:90% All right. 00:00:31.880 --> 00:00:38.560 align:middle line:84% So today, designs of financial infrastructure 00:00:38.560 --> 00:00:41.640 align:middle line:84% utilizing encryption, and I'm going 00:00:41.640 --> 00:00:47.140 align:middle line:84% to go through three examples today varying in detail. 00:00:47.140 --> 00:00:51.360 align:middle line:84% One is an auction, which is a familiar setup, 00:00:51.360 --> 00:00:54.080 align:middle line:90% but we'll be encrypting it. 00:00:54.080 --> 00:00:58.120 align:middle line:84% Then I have this what I call hybrid credit and insurance, 00:00:58.120 --> 00:01:03.070 align:middle line:84% having to do with insurance against balance sheet shocks 00:01:03.070 --> 00:01:06.070 align:middle line:90% in various contexts. 00:01:06.070 --> 00:01:12.950 align:middle line:84% And then finally, a market implementation using encryption. 00:01:12.950 --> 00:01:16.710 align:middle line:90% So first, we'll do the auctions. 00:01:16.710 --> 00:01:19.790 align:middle line:84% So auctions are used frequently, but they're typically 00:01:19.790 --> 00:01:22.670 align:middle line:90% organized by a third party. 00:01:22.670 --> 00:01:26.670 align:middle line:84% And the example here is Mortgage Capital Trading's use 00:01:26.670 --> 00:01:29.990 align:middle line:90% of a trade auction manager. 00:01:29.990 --> 00:01:32.850 align:middle line:84% Worrying that perhaps this slide was a bit out of date, 00:01:32.850 --> 00:01:37.950 align:middle line:84% I checked this morning on the web, it's alive and well. 00:01:37.950 --> 00:01:41.990 align:middle line:84% So Mortgage Capital Trading is still 00:01:41.990 --> 00:01:45.590 align:middle line:84% being used, as are many of the others. 00:01:45.590 --> 00:01:49.550 align:middle line:84% But trusted third parties like Mortgage-- 00:01:49.550 --> 00:01:53.050 align:middle line:84% the trade auction manager there are not always needed, 00:01:53.050 --> 00:01:57.510 align:middle line:84% and in fact, they're not always beneficial. 00:01:57.510 --> 00:02:02.580 align:middle line:84% So what are called these "bid-wanted-in-competition" 00:02:02.580 --> 00:02:06.580 align:middle line:84% dealers are asked to bid on a list of securities. 00:02:06.580 --> 00:02:10.400 align:middle line:84% Not necessarily securitized mortgages in the first example, 00:02:10.400 --> 00:02:12.580 align:middle line:90% but much more generally. 00:02:12.580 --> 00:02:15.440 align:middle line:84% And there's a typical, as you could imagine, 00:02:15.440 --> 00:02:19.380 align:middle line:84% abuse, or at least potential abuse, 00:02:19.380 --> 00:02:24.060 align:middle line:84% where the auction manager is on the phone, 00:02:24.060 --> 00:02:26.180 align:middle line:84% he's the seller of the asset, so he 00:02:26.180 --> 00:02:31.020 align:middle line:84% has an interest in making the price high, so he calls buyer A, 00:02:31.020 --> 00:02:32.840 align:middle line:84% he says, I prefer you, my friend, 00:02:32.840 --> 00:02:35.600 align:middle line:84% but buyer B just offered a slightly higher price. 00:02:35.600 --> 00:02:38.160 align:middle line:84% So if you can just make some effort, 00:02:38.160 --> 00:02:40.980 align:middle line:84% the good-- is the security is yours. 00:02:40.980 --> 00:02:44.780 align:middle line:84% But at the same time, he's saying exactly the same thing 00:02:44.780 --> 00:02:47.660 align:middle line:84% to buyer B for this example, just 00:02:47.660 --> 00:02:53.060 align:middle line:84% say there are two buyers, which has the intent of propping up 00:02:53.060 --> 00:02:53.680 align:middle line:90% the price. 00:02:53.680 --> 00:02:56.540 align:middle line:84% And of course, neither A nor B can 00:02:56.540 --> 00:03:01.730 align:middle line:84% check on what this manager is saying to other clients, 00:03:01.730 --> 00:03:03.770 align:middle line:84% and neither can they check on the bids that 00:03:03.770 --> 00:03:10.970 align:middle line:84% are coming in in order to verify the claim of the auction manager 00:03:10.970 --> 00:03:14.170 align:middle line:84% that, in this case, buyer B was a little bit off. 00:03:14.170 --> 00:03:16.690 align:middle line:84% Not to mention, it's potentially improper 00:03:16.690 --> 00:03:21.290 align:middle line:84% to be doing that in the first place. 00:03:21.290 --> 00:03:24.030 align:middle line:90% It's not the only example. 00:03:24.030 --> 00:03:28.850 align:middle line:84% China had, at one point, these P2P platforms, 00:03:28.850 --> 00:03:34.970 align:middle line:84% and there have been articles written about what investors 00:03:34.970 --> 00:03:39.810 align:middle line:84% were being told or not, and one of these articles pretty 00:03:39.810 --> 00:03:45.410 align:middle line:84% much documented a kind of cream skimming where AI was running 00:03:45.410 --> 00:03:50.630 align:middle line:84% over securities that could be put in the securitized pool, 00:03:50.630 --> 00:03:52.050 align:middle line:90% but some of them-- 00:03:52.050 --> 00:03:57.160 align:middle line:84% some of the prime ones were not put in the pool 00:03:57.160 --> 00:04:01.500 align:middle line:84% and were held by individual investors, 00:04:01.500 --> 00:04:05.480 align:middle line:84% but other investors were not informed that this was going on. 00:04:05.480 --> 00:04:12.560 align:middle line:84% And China eventually got rid of these P2P platforms altogether. 00:04:12.560 --> 00:04:13.280 align:middle line:90% OK. 00:04:13.280 --> 00:04:18.240 align:middle line:84% So how do we do an auction without an auctioneer? 00:04:18.240 --> 00:04:19.160 align:middle line:90% The answer? 00:04:19.160 --> 00:04:22.320 align:middle line:84% Use the tools that we're just learning, 00:04:22.320 --> 00:04:26.000 align:middle line:84% homomorphic encryption and multi-party computation. 00:04:26.000 --> 00:04:28.440 align:middle line:84% And I'll describe, in the slides that 00:04:28.440 --> 00:04:33.040 align:middle line:84% follow, two ways of doing this, and both are instructive. 00:04:33.040 --> 00:04:35.000 align:middle line:84% And we're going to be focusing not 00:04:35.000 --> 00:04:37.600 align:middle line:84% on the seller with the asset, but the messages 00:04:37.600 --> 00:04:39.440 align:middle line:84% that go back and forth, so they're not 00:04:39.440 --> 00:04:41.820 align:middle line:90% communicating with the seller. 00:04:41.820 --> 00:04:44.880 align:middle line:84% So the seller is kind of in the background here. 00:04:44.880 --> 00:04:47.780 align:middle line:84% First scheme, each bidder has his own server. 00:04:47.780 --> 00:04:51.000 align:middle line:84% We haven't spent that much time on infrastructure, 00:04:51.000 --> 00:04:54.710 align:middle line:84% but it's, of course, crucial in any application. 00:04:54.710 --> 00:04:58.550 align:middle line:84% So in this case, they're going to use their own servers. 00:04:58.550 --> 00:05:01.070 align:middle line:84% There are going to be two bidders. 00:05:01.070 --> 00:05:03.310 align:middle line:84% And they're going to encrypt their messages, which 00:05:03.310 --> 00:05:06.230 align:middle line:84% are their bids, and those bids are going to go-- 00:05:06.230 --> 00:05:09.350 align:middle line:84% encrypted messages are going to go back and forth 00:05:09.350 --> 00:05:12.990 align:middle line:90% among these two or more bidders. 00:05:12.990 --> 00:05:14.810 align:middle line:90% There's no third-party server. 00:05:14.810 --> 00:05:16.750 align:middle line:90% There's no contract node. 00:05:16.750 --> 00:05:19.990 align:middle line:84% In particular, each buyer sends his encrypted bid 00:05:19.990 --> 00:05:23.810 align:middle line:84% with public-private key pairs, as in homomorphic encryption, 00:05:23.810 --> 00:05:28.070 align:middle line:84% to the others, and for the multi-party computation part, 00:05:28.070 --> 00:05:31.230 align:middle line:84% they send the results of these encrypted messages 00:05:31.230 --> 00:05:33.270 align:middle line:90% to each other. 00:05:33.270 --> 00:05:36.790 align:middle line:84% The second scheme-- this is just an outline slide-- 00:05:36.790 --> 00:05:39.230 align:middle line:90% is with a contract node. 00:05:39.230 --> 00:05:44.550 align:middle line:84% So all communication goes to a third-party server 00:05:44.550 --> 00:05:47.230 align:middle line:90% where the contract node resides. 00:05:47.230 --> 00:05:51.890 align:middle line:84% So communication is with these encrypted messages. 00:05:51.890 --> 00:05:56.620 align:middle line:84% So the, quote, "server" doesn't see the private values. 00:05:56.620 --> 00:06:00.460 align:middle line:84% The server is doing in the code what the agents were 00:06:00.460 --> 00:06:04.220 align:middle line:90% doing in the first scheme. 00:06:04.220 --> 00:06:09.720 align:middle line:84% It's hard not to refer to this contract as a person, 00:06:09.720 --> 00:06:12.740 align:middle line:90% but it isn't, it's just code. 00:06:12.740 --> 00:06:14.940 align:middle line:84% I think we call it a pseudo-agent 00:06:14.940 --> 00:06:17.650 align:middle line:90% in the subsequent slides. 00:06:17.650 --> 00:06:18.150 align:middle line:90% OK. 00:06:18.150 --> 00:06:23.980 align:middle line:84% So we've got these in the first scheme, two agents A and B, 00:06:23.980 --> 00:06:26.180 align:middle line:84% and they want to see whose bid is higher 00:06:26.180 --> 00:06:29.340 align:middle line:84% and who is lower without relying on the trusted 00:06:29.340 --> 00:06:32.300 align:middle line:84% third-party seller, but without revealing 00:06:32.300 --> 00:06:37.340 align:middle line:84% to each other the exact value of their bids. 00:06:37.340 --> 00:06:40.700 align:middle line:84% And I will forewarn you from the get-go 00:06:40.700 --> 00:06:45.220 align:middle line:84% that 2 turns out to be special, but the idea of the example 00:06:45.220 --> 00:06:47.100 align:middle line:90% does generalize. 00:06:47.100 --> 00:06:50.500 align:middle line:84% And I'll show you where the special revealing feature 00:06:50.500 --> 00:06:51.680 align:middle line:90% happens at the end. 00:06:51.680 --> 00:06:58.490 align:middle line:84% OK, so this BFV encryption algorithm, which is 00:06:58.490 --> 00:07:00.530 align:middle line:90% ring learning with error. 00:07:00.530 --> 00:07:04.770 align:middle line:84% I showed you one slide last time with the polynomials 00:07:04.770 --> 00:07:09.010 align:middle line:84% and the coefficients of the various orders of terms 00:07:09.010 --> 00:07:13.810 align:middle line:84% being drawn from integers and so on, so this is that scheme. 00:07:13.810 --> 00:07:17.710 align:middle line:84% There are private and public keys, of course. 00:07:17.710 --> 00:07:20.650 align:middle line:90% The public key is this a, delta. 00:07:20.650 --> 00:07:25.290 align:middle line:84% The secret or private keys are the s, e terms. 00:07:25.290 --> 00:07:28.250 align:middle line:84% But again, this is in the space of rings, 00:07:28.250 --> 00:07:33.050 align:middle line:84% which are polynomials with these integer coefficients 00:07:33.050 --> 00:07:37.190 align:middle line:84% modulo some first-- some order polynomials. 00:07:37.190 --> 00:07:39.890 align:middle line:84% So we're going to take polynomial operations 00:07:39.890 --> 00:07:43.290 align:middle line:84% of addition, multiplication, and so on, and always apply 00:07:43.290 --> 00:07:46.210 align:middle line:84% this quotient to get it down to, say, 00:07:46.210 --> 00:07:50.360 align:middle line:90% an n minus 1 degree polynomial. 00:07:50.360 --> 00:07:54.840 align:middle line:84% Then this error term is like a normally distributed 00:07:54.840 --> 00:08:01.440 align:middle line:84% random variable that's added on for extra noise and security. 00:08:01.440 --> 00:08:03.600 align:middle line:90% And I'll show you-- 00:08:03.600 --> 00:08:08.440 align:middle line:84% remind you, really, more on that momentarily, but we 00:08:08.440 --> 00:08:10.600 align:middle line:90% end up with these private-- 00:08:10.600 --> 00:08:13.640 align:middle line:90% sorry, public secret key pairs. 00:08:13.640 --> 00:08:17.800 align:middle line:84% a, delta are common across the agent. 00:08:17.800 --> 00:08:20.440 align:middle line:90% That's the public part. 00:08:20.440 --> 00:08:22.660 align:middle line:84% They're going to draw these public-private keys-- 00:08:22.660 --> 00:08:28.400 align:middle line:84% the public part is going to be published on their servers 00:08:28.400 --> 00:08:32.520 align:middle line:84% and broadcasted more generally, possibly. 00:08:32.520 --> 00:08:35.140 align:middle line:84% And the private key parts, secret-- 00:08:35.140 --> 00:08:37.960 align:middle line:90% see how I keep mixing up my p's? 00:08:37.960 --> 00:08:41.419 align:middle line:84% The secret key part is si and ei. 00:08:41.419 --> 00:08:44.760 align:middle line:90% 00:08:44.760 --> 00:08:47.680 align:middle line:84% And you'll see in a minute, when I give you the example, 00:08:47.680 --> 00:08:50.150 align:middle line:84% specifically where a and delta enter 00:08:50.150 --> 00:08:53.390 align:middle line:90% and where's si and ei enter. 00:08:53.390 --> 00:08:57.050 align:middle line:84% It's only the secret keys that are indexed by the agent, 00:08:57.050 --> 00:09:02.230 align:middle line:84% obviously, because the public key is common. 00:09:02.230 --> 00:09:06.910 align:middle line:84% So here's the example of why we need the noise. 00:09:06.910 --> 00:09:09.030 align:middle line:90% This is just matrix-- 00:09:09.030 --> 00:09:11.710 align:middle line:90% a system of linear equations. 00:09:11.710 --> 00:09:18.350 align:middle line:84% We got a 7-by-4 matrix multiplied by a 4-by-1 column. 00:09:18.350 --> 00:09:22.750 align:middle line:84% So we're going to-- the answer is going to be a 7-by-1 column. 00:09:22.750 --> 00:09:28.350 align:middle line:84% And the secret is supposed to be what's in red there. 00:09:28.350 --> 00:09:33.130 align:middle line:84% If this was a non-singular square matrix, 00:09:33.130 --> 00:09:37.530 align:middle line:84% we could just invert and multiply by both sides. 00:09:37.530 --> 00:09:38.770 align:middle line:90% That's not necessary. 00:09:38.770 --> 00:09:42.530 align:middle line:84% Gaussian elimination, which works row by row, 00:09:42.530 --> 00:09:46.810 align:middle line:84% can also solve the system of equations, 00:09:46.810 --> 00:09:50.980 align:middle line:84% so the red secret would be revealed. 00:09:50.980 --> 00:09:53.780 align:middle line:84% AUDIENCE: What is the blue thing here. 00:09:53.780 --> 00:09:56.600 align:middle line:84% What is-- does that map to our alpha, delta-- 00:09:56.600 --> 00:10:00.120 align:middle line:84% ROBERT TOWNSEND: You're like seeing the blue stuff 00:10:00.120 --> 00:10:03.420 align:middle line:84% and you want to-- and we want to prevent outsiders 00:10:03.420 --> 00:10:06.293 align:middle line:90% from deciphering the red. 00:10:06.293 --> 00:10:06.960 align:middle line:90% AUDIENCE: I see. 00:10:06.960 --> 00:10:08.500 align:middle line:90% OK. 00:10:08.500 --> 00:10:14.540 align:middle line:84% ROBERT TOWNSEND: So we add in a 7-by-1 column vector with noise, 00:10:14.540 --> 00:10:21.300 align:middle line:84% and that, in principle, very hard to decipher the red. 00:10:21.300 --> 00:10:23.340 align:middle line:84% AUDIENCE: The blue is not invertible, so-- 00:10:23.340 --> 00:10:26.780 align:middle line:90% ROBERT TOWNSEND: It's not, no. 00:10:26.780 --> 00:10:32.900 align:middle line:84% But Gaussian elimination can solve this system. 00:10:32.900 --> 00:10:35.700 align:middle line:90% I checked it this morning. 00:10:35.700 --> 00:10:37.380 align:middle line:90% AUDIENCE: Yeah. 00:10:37.380 --> 00:10:41.540 align:middle line:84% So if I know the blue stuff, and I want 00:10:41.540 --> 00:10:43.160 align:middle line:90% to know what the red stuff is-- 00:10:43.160 --> 00:10:43.700 align:middle line:90% I see. 00:10:43.700 --> 00:10:44.867 align:middle line:90% ROBERT TOWNSEND: Yeah, yeah. 00:10:44.867 --> 00:10:46.220 align:middle line:90% That's the idea. 00:10:46.220 --> 00:10:47.890 align:middle line:84% This thing with the noise, i'll just 00:10:47.890 --> 00:10:51.170 align:middle line:84% remind you, because I had a slide about MPC 00:10:51.170 --> 00:10:54.950 align:middle line:84% last time with the secret sharing. 00:10:54.950 --> 00:11:00.010 align:middle line:84% And I drew this analogy to who is the richest person. 00:11:00.010 --> 00:11:01.930 align:middle line:84% And I didn't quite pull it off, but you'll 00:11:01.930 --> 00:11:04.210 align:middle line:90% see it coming back today. 00:11:04.210 --> 00:11:07.170 align:middle line:84% The main thing is, in that example, 00:11:07.170 --> 00:11:11.490 align:middle line:84% one person had a secret, added noise, passed it 00:11:11.490 --> 00:11:15.490 align:middle line:84% down the line to the next one, who had a secret, 00:11:15.490 --> 00:11:17.850 align:middle line:84% and added noise, and then we summed that up, 00:11:17.850 --> 00:11:23.130 align:middle line:84% and we went all the way across the first row at the top 00:11:23.130 --> 00:11:25.170 align:middle line:84% with however many players are there, 00:11:25.170 --> 00:11:29.170 align:middle line:84% getting the sum of the secrets plus the sum of the noise, which 00:11:29.170 --> 00:11:32.290 align:middle line:84% means nothing to anyone because the noise is encrypting 00:11:32.290 --> 00:11:33.570 align:middle line:90% everything. 00:11:33.570 --> 00:11:36.430 align:middle line:84% And then we successively took the noise out. 00:11:36.430 --> 00:11:39.450 align:middle line:84% And there is a strong sense in which 00:11:39.450 --> 00:11:43.170 align:middle line:84% that's exactly what's going to happen in this auction. 00:11:43.170 --> 00:11:47.960 align:middle line:84% So it's both a technology reminder of something 00:11:47.960 --> 00:11:54.820 align:middle line:84% you've seen before briefly, and wedded with this application. 00:11:54.820 --> 00:11:58.260 align:middle line:84% OK, so now they have a secret key, 00:11:58.260 --> 00:12:00.360 align:middle line:84% they've shared the public key, they 00:12:00.360 --> 00:12:02.960 align:middle line:90% can start to encrypt their bids. 00:12:02.960 --> 00:12:08.360 align:middle line:84% So let's say A goes first, just for the sake of being clear. 00:12:08.360 --> 00:12:13.400 align:middle line:84% So A sends-- and this was the first scheme 00:12:13.400 --> 00:12:15.520 align:middle line:84% where they each have a server, and they're just 00:12:15.520 --> 00:12:19.860 align:middle line:84% sending messages back and forth across their servers. 00:12:19.860 --> 00:12:25.320 align:middle line:84% So A goes first and sends an encrypted message 00:12:25.320 --> 00:12:32.200 align:middle line:84% to B, which is ciphertext that A sends, and in particular, you 00:12:32.200 --> 00:12:38.260 align:middle line:84% can see the a and delta as the public key multiplying, however, 00:12:38.260 --> 00:12:40.940 align:middle line:84% the secret key, private key of agent A, 00:12:40.940 --> 00:12:45.660 align:middle line:84% and in this case for the delta, the message-- and let's just, 00:12:45.660 --> 00:12:49.560 align:middle line:84% for the sake of argument, if the auction is well-designed, 00:12:49.560 --> 00:12:51.380 align:middle line:84% say that it has an incentive to send 00:12:51.380 --> 00:12:52.880 align:middle line:90% his true willingness to pay. 00:12:52.880 --> 00:12:57.340 align:middle line:84% It doesn't really matter now, that's the bid. 00:12:57.340 --> 00:12:59.600 align:middle line:90% And the error is added. 00:12:59.600 --> 00:13:00.100 align:middle line:90% Yeah. 00:13:00.100 --> 00:13:04.420 align:middle line:84% So intuitively, this is just gobbledygook ciphertext 00:13:04.420 --> 00:13:07.820 align:middle line:84% like a hash message, and B can't interpret it. 00:13:07.820 --> 00:13:11.180 align:middle line:84% B has no idea, partly because of the secret key 00:13:11.180 --> 00:13:14.780 align:middle line:90% and partly because of the error. 00:13:14.780 --> 00:13:17.740 align:middle line:90% And B does the same. 00:13:17.740 --> 00:13:22.580 align:middle line:84% B sends his encrypted bid back to A. 00:13:22.580 --> 00:13:23.600 align:middle line:90% What is delta? 00:13:23.600 --> 00:13:27.180 align:middle line:84% So in a minute, we're about to set delta to 1. 00:13:27.180 --> 00:13:32.300 align:middle line:84% That kind of simplifies the algebra. 00:13:32.300 --> 00:13:35.220 align:middle line:84% I did mention last time that the problem 00:13:35.220 --> 00:13:38.500 align:middle line:84% with adding error and having multiple operations 00:13:38.500 --> 00:13:42.180 align:middle line:84% is that the error term starts to get bigger and bigger. 00:13:42.180 --> 00:13:47.290 align:middle line:84% And so, this counterveiling force here 00:13:47.290 --> 00:13:53.550 align:middle line:84% is to make delta pretty big instead of shrinking the error, 00:13:53.550 --> 00:13:56.010 align:middle line:84% but they're doing a lot of different things 00:13:56.010 --> 00:14:00.270 align:middle line:84% at the same time to try to put some bounds on the error term. 00:14:00.270 --> 00:14:05.210 align:middle line:84% But everything I'm going to show you with delta equal 1 can be 00:14:05.210 --> 00:14:08.350 align:middle line:84% done with a larger delta, it's just, quote, "heavier." 00:14:08.350 --> 00:14:11.250 align:middle line:90% 00:14:11.250 --> 00:14:11.910 align:middle line:90% All right. 00:14:11.910 --> 00:14:17.770 align:middle line:84% So now each is holding the ciphertext 00:14:17.770 --> 00:14:21.170 align:middle line:90% received from the other one. 00:14:21.170 --> 00:14:27.130 align:middle line:84% So agent A has a ciphertext encrypted bid from B, 00:14:27.130 --> 00:14:34.210 align:middle line:84% and A adds in his or her own secret key pair 00:14:34.210 --> 00:14:36.050 align:middle line:90% in an additive way. 00:14:36.050 --> 00:14:41.290 align:middle line:84% So A adds in that term, as of a plus ea, 00:14:41.290 --> 00:14:44.840 align:middle line:84% and B, sitting on the ciphertext from a, 00:14:44.840 --> 00:14:51.320 align:middle line:84% adds in his or her own secret error terms. 00:14:51.320 --> 00:15:02.080 align:middle line:84% And the ciphertext for A, say, had B's encrypted message, 00:15:02.080 --> 00:15:10.920 align:middle line:84% added in his own error term on top like cross-matching. 00:15:10.920 --> 00:15:19.960 align:middle line:84% And so after adding in his own secret key pair, 00:15:19.960 --> 00:15:23.920 align:middle line:84% this new transformed ciphertext of B 00:15:23.920 --> 00:15:28.400 align:middle line:84% is of this form, a of s plus delta mb plus e. 00:15:28.400 --> 00:15:32.520 align:middle line:84% Now there's no subscripts on the s and e, 00:15:32.520 --> 00:15:40.200 align:middle line:84% and the reason is s equals the sum of sa plus sb. 00:15:40.200 --> 00:15:46.470 align:middle line:84% sb was in there because B sent the ciphertext to A, 00:15:46.470 --> 00:15:50.070 align:middle line:84% and sa is in there because A just added it in. 00:15:50.070 --> 00:15:52.250 align:middle line:90% So that's why it's s. 00:15:52.250 --> 00:15:57.310 align:middle line:84% And likewise for the e, the error terms are just adding. 00:15:57.310 --> 00:15:59.163 align:middle line:90% OK. 00:15:59.163 --> 00:16:02.710 align:middle line:84% And likewise, B is in a similar position. 00:16:02.710 --> 00:16:04.910 align:middle line:84% So you could now just take the difference 00:16:04.910 --> 00:16:08.070 align:middle line:90% of these transformed ciphertext. 00:16:08.070 --> 00:16:11.430 align:middle line:84% And you get the final answer, which 00:16:11.430 --> 00:16:14.750 align:middle line:84% is just this difference delta times the difference 00:16:14.750 --> 00:16:16.310 align:middle line:90% of the bids. 00:16:16.310 --> 00:16:19.230 align:middle line:84% Now the only piece we want out of this 00:16:19.230 --> 00:16:24.270 align:middle line:84% is to say that they each now know, 00:16:24.270 --> 00:16:27.350 align:middle line:84% because they're exchanging the ciphertext, which 00:16:27.350 --> 00:16:31.550 align:middle line:84% bid was higher, but it's also true that you know your own bid, 00:16:31.550 --> 00:16:34.110 align:middle line:90% and delta is a public key. 00:16:34.110 --> 00:16:37.390 align:middle line:84% So unfortunately, we have now revealed everything 00:16:37.390 --> 00:16:43.080 align:middle line:84% about the bids to both players, which isn't a total disaster, 00:16:43.080 --> 00:16:47.260 align:middle line:84% but in general, we can do better. 00:16:47.260 --> 00:16:49.840 align:middle line:84% Although there is a related message here, 00:16:49.840 --> 00:16:53.820 align:middle line:84% which is when we go with more than two agents, 00:16:53.820 --> 00:16:56.580 align:middle line:84% it is still possible that a subset of them 00:16:56.580 --> 00:17:00.540 align:middle line:84% could be colluding or coordinating and revealing stuff 00:17:00.540 --> 00:17:05.640 align:middle line:84% to each other, in which case, they could, if they did that, 00:17:05.640 --> 00:17:12.180 align:middle line:84% figure out the bid of, say, for example, the last agent. 00:17:12.180 --> 00:17:17.380 align:middle line:84% So the second scheme uses third-party server 00:17:17.380 --> 00:17:22.540 align:middle line:84% and introduces the pseudo-agent, like the contract code. 00:17:22.540 --> 00:17:25.140 align:middle line:84% And the third party here is going 00:17:25.140 --> 00:17:30.660 align:middle line:84% to be able to decipher the bids without ever having access 00:17:30.660 --> 00:17:34.180 align:middle line:84% to the secret keys of any of the bidders. 00:17:34.180 --> 00:17:37.340 align:middle line:84% So this is the same notation as before 00:17:37.340 --> 00:17:41.970 align:middle line:84% for public and secret keys, public and private keys. 00:17:41.970 --> 00:17:46.130 align:middle line:84% Now, in step 1, they don't send cipher encrypted bids 00:17:46.130 --> 00:17:49.850 align:middle line:84% to each other, they send it to pseudo-agent C, 00:17:49.850 --> 00:17:53.410 align:middle line:90% to the code suitably labeled C. 00:17:53.410 --> 00:17:58.210 align:middle line:84% And the pseudo-agent also gets other information. 00:17:58.210 --> 00:18:06.490 align:middle line:84% It asks each of A and B to send an additional ciphertext, which 00:18:06.490 --> 00:18:12.110 align:middle line:84% consists of each the sum of the private keys, 00:18:12.110 --> 00:18:17.930 align:middle line:84% but again, it's encrypted, so these encrypted messages mean 00:18:17.930 --> 00:18:19.910 align:middle line:84% nothing, they're not interpretable, 00:18:19.910 --> 00:18:25.090 align:middle line:90% but C is now armed with them. 00:18:25.090 --> 00:18:27.690 align:middle line:90% And secrets are maintained here. 00:18:27.690 --> 00:18:31.870 align:middle line:90% So this line has an error. 00:18:31.870 --> 00:18:34.890 align:middle line:90% 00:18:34.890 --> 00:18:37.100 align:middle line:84% And I was sorting through it yesterday. 00:18:37.100 --> 00:18:39.220 align:middle line:84% I could have tried to redo the slide, 00:18:39.220 --> 00:18:42.120 align:middle line:84% but I think the error is kind of instructive. 00:18:42.120 --> 00:18:46.960 align:middle line:84% So this says ctc is the difference 00:18:46.960 --> 00:18:50.320 align:middle line:90% of these original ciphertext. 00:18:50.320 --> 00:18:53.640 align:middle line:84% Actually, they should have a prime on them. 00:18:53.640 --> 00:18:56.040 align:middle line:84% Harkening back to the first application where 00:18:56.040 --> 00:18:59.000 align:middle line:84% the agents added in their own private keys 00:18:59.000 --> 00:19:02.860 align:middle line:84% on top of the ciphertext they received, in which case, 00:19:02.860 --> 00:19:07.440 align:middle line:84% the math is entirely the same, except that these terms are not 00:19:07.440 --> 00:19:08.400 align:middle line:90% there. 00:19:08.400 --> 00:19:10.480 align:middle line:84% And literally, what's going on here 00:19:10.480 --> 00:19:15.400 align:middle line:84% is the third-party code is just doing what 00:19:15.400 --> 00:19:18.120 align:middle line:90% the agents had done anyway. 00:19:18.120 --> 00:19:23.920 align:middle line:84% It receives the ciphertext, it adds on the error terms 00:19:23.920 --> 00:19:28.000 align:middle line:84% and the other parts of the secret key acting for each 00:19:28.000 --> 00:19:33.300 align:middle line:84% party, and takes those ciphertexts and does some, 00:19:33.300 --> 00:19:36.910 align:middle line:84% quote, "algebra" on them to figure out the difference 00:19:36.910 --> 00:19:37.730 align:middle line:90% in the bids. 00:19:37.730 --> 00:19:43.110 align:middle line:90% 00:19:43.110 --> 00:19:49.410 align:middle line:84% So in some sense on this slide, we didn't need the rest of this 00:19:49.410 --> 00:19:54.070 align:middle line:84% if the primes had been put where they were supposed to be, 00:19:54.070 --> 00:19:59.670 align:middle line:84% but what's instructive about this line is 00:19:59.670 --> 00:20:08.310 align:middle line:84% this adding in of representation of the sum of the private keys. 00:20:08.310 --> 00:20:14.070 align:middle line:84% So in more general schemes, which I'm about to describe, 00:20:14.070 --> 00:20:19.510 align:middle line:84% at least the English version, this is the-- 00:20:19.510 --> 00:20:23.830 align:middle line:84% and this is more general than for two agents. 00:20:23.830 --> 00:20:27.590 align:middle line:84% Why don't I just show you the next slide. 00:20:27.590 --> 00:20:33.670 align:middle line:84% So this is generalized MPC where we have more than two agents, 00:20:33.670 --> 00:20:36.420 align:middle line:84% and it goes through the sequence. 00:20:36.420 --> 00:20:40.780 align:middle line:84% Each agent individually generates a key pair as before. 00:20:40.780 --> 00:20:43.820 align:middle line:84% Each key pair has a public encryption key 00:20:43.820 --> 00:20:46.260 align:middle line:90% and a private decryption key. 00:20:46.260 --> 00:20:50.300 align:middle line:84% All agents submit their public keys to the server. 00:20:50.300 --> 00:20:53.540 align:middle line:84% That's common knowledge, that's the a, delta. 00:20:53.540 --> 00:20:55.500 align:middle line:84% The server combines all the agents' 00:20:55.500 --> 00:21:02.020 align:middle line:84% public keys into a single shared joint public key. 00:21:02.020 --> 00:21:06.060 align:middle line:84% This new joint shared public key is distributed from the server 00:21:06.060 --> 00:21:07.900 align:middle line:90% to all the agents. 00:21:07.900 --> 00:21:13.380 align:middle line:84% So we've kind of added these extra steps 1 through 4. 00:21:13.380 --> 00:21:17.200 align:middle line:84% And I misspoke a second ago when I said a, delta. 00:21:17.200 --> 00:21:21.020 align:middle line:84% It's as if they each have public keys, 00:21:21.020 --> 00:21:24.100 align:middle line:84% and then you're adding up the public keys 00:21:24.100 --> 00:21:31.060 align:middle line:84% and sending back now, for future use, a common public key. 00:21:31.060 --> 00:21:33.030 align:middle line:84% So then, with the common public key, 00:21:33.030 --> 00:21:36.210 align:middle line:84% the agents can use it to encrypt their private data, 00:21:36.210 --> 00:21:38.450 align:middle line:90% generating ciphertext. 00:21:38.450 --> 00:21:43.450 align:middle line:84% Each agent sends the ciphertext with its message to the server. 00:21:43.450 --> 00:21:46.570 align:middle line:84% This completely hides the agent's data. 00:21:46.570 --> 00:21:50.410 align:middle line:84% The server runs computations on all the encrypted data, 00:21:50.410 --> 00:21:56.090 align:middle line:84% producing an encrypted result. So that's the FHE part. 00:21:56.090 --> 00:22:00.290 align:middle line:84% All the computations are being done in this encrypted space. 00:22:00.290 --> 00:22:03.850 align:middle line:84% The server sends the encrypted result back to each agent. 00:22:03.850 --> 00:22:07.410 align:middle line:84% Each agent then uses his or her private key 00:22:07.410 --> 00:22:10.130 align:middle line:84% that they generated up there in step 1 00:22:10.130 --> 00:22:13.570 align:middle line:90% to partially decrypt the answer. 00:22:13.570 --> 00:22:17.850 align:middle line:84% After they decrypt it partially, they send their decrypted part 00:22:17.850 --> 00:22:20.210 align:middle line:90% back to the server. 00:22:20.210 --> 00:22:24.130 align:middle line:84% And this is, again, the number of agents without which 00:22:24.130 --> 00:22:26.610 align:middle line:84% partial decryption from all the remaining agents 00:22:26.610 --> 00:22:28.850 align:middle line:84% will still give a completely encrypted result 00:22:28.850 --> 00:22:33.280 align:middle line:84% is a parameter that can be chosen beforehand 00:22:33.280 --> 00:22:35.100 align:middle line:90% by the mechanism designer. 00:22:35.100 --> 00:22:41.240 align:middle line:84% So this is, again, very typical of the computer science style 00:22:41.240 --> 00:22:45.520 align:middle line:84% here, which is to try to put a bound on nefarious 00:22:45.520 --> 00:22:49.760 align:middle line:84% behavior, like how many of these bidders are potentially 00:22:49.760 --> 00:22:51.760 align:middle line:90% colluding with one another. 00:22:51.760 --> 00:22:55.180 align:middle line:84% And then if you have enough agents, 00:22:55.180 --> 00:23:00.480 align:middle line:84% you can basically still keep secrets. 00:23:00.480 --> 00:23:04.160 align:middle line:84% So the final step is the server combines the results of all 00:23:04.160 --> 00:23:06.640 align:middle line:84% these partial decryptions, and it's 00:23:06.640 --> 00:23:09.440 align:middle line:84% able to produce the decrypted result, 00:23:09.440 --> 00:23:12.440 align:middle line:84% and then that's shared with all the agents. 00:23:12.440 --> 00:23:16.880 align:middle line:84% So it is kind of a long sequence. 00:23:16.880 --> 00:23:19.160 align:middle line:84% This works in general, as I have said now, 00:23:19.160 --> 00:23:24.760 align:middle line:84% for more than two agents, and these are typically 00:23:24.760 --> 00:23:31.030 align:middle line:84% the way these MPC schemes work across multiple parties. 00:23:31.030 --> 00:23:34.950 align:middle line:84% There is still a lot of messaging going back and forth. 00:23:34.950 --> 00:23:39.710 align:middle line:84% I mean, in some ways, the spirit of it shouldn't be surprising. 00:23:39.710 --> 00:23:42.670 align:middle line:84% If you remember the encryption lecture from last time 00:23:42.670 --> 00:23:48.730 align:middle line:84% where we went to signatures, that was Alice and Bob, 00:23:48.730 --> 00:23:53.270 align:middle line:84% and Alice is going to send a secret message to Bob, 00:23:53.270 --> 00:23:57.470 align:middle line:84% that Bob has to verify that it's Alex-- or Alice. 00:23:57.470 --> 00:24:00.830 align:middle line:84% So they went back and forth with this at least 00:24:00.830 --> 00:24:04.250 align:middle line:84% twice, sending messages back and forth to each other. 00:24:04.250 --> 00:24:07.270 align:middle line:84% So this is in that spirit, except it's 00:24:07.270 --> 00:24:09.670 align:middle line:84% more than a signature in the sense 00:24:09.670 --> 00:24:12.710 align:middle line:84% that there are more than two agents 00:24:12.710 --> 00:24:17.750 align:middle line:84% and they're actively bidding on something. 00:24:17.750 --> 00:24:19.250 align:middle line:90% OK. 00:24:19.250 --> 00:24:22.370 align:middle line:84% AUDIENCE: So a high-level question. 00:24:22.370 --> 00:24:27.790 align:middle line:84% So in theory price option, in theory, the rule of auctioneer 00:24:27.790 --> 00:24:30.820 align:middle line:84% is just collecting those prices in aggregate 00:24:30.820 --> 00:24:33.820 align:middle line:90% with the successful bidder. 00:24:33.820 --> 00:24:37.180 align:middle line:84% So here, I think, is it the case we just 00:24:37.180 --> 00:24:39.260 align:middle line:84% get rid of this auctioneer so that we 00:24:39.260 --> 00:24:41.900 align:middle line:90% don't need to trust anyone? 00:24:41.900 --> 00:24:45.260 align:middle line:84% But theoretically, the results are essentially 00:24:45.260 --> 00:24:47.800 align:middle line:84% the same with the [INAUDIBLE] price auction? 00:24:47.800 --> 00:24:50.475 align:middle line:90% 00:24:50.475 --> 00:24:52.100 align:middle line:84% ROBERT TOWNSEND: All that was done here 00:24:52.100 --> 00:24:57.420 align:middle line:84% was whatever the incentives are, they've submitted their bids 00:24:57.420 --> 00:24:59.940 align:middle line:84% whether or not it was the true value, 00:24:59.940 --> 00:25:02.940 align:middle line:84% and the example was the highest bid wins. 00:25:02.940 --> 00:25:07.420 align:middle line:84% But you could imagine implementing other rules, 00:25:07.420 --> 00:25:11.420 align:middle line:84% like Vickrey auctions, where the highest 00:25:11.420 --> 00:25:14.700 align:middle line:84% bidder gets to pay the second-highest bid 00:25:14.700 --> 00:25:16.300 align:middle line:90% or something like that. 00:25:16.300 --> 00:25:19.380 align:middle line:84% All of that, if, in fact, we're going to see, 00:25:19.380 --> 00:25:23.420 align:middle line:84% you can rank-order these bids in general. 00:25:23.420 --> 00:25:29.810 align:middle line:84% So there are two ways to try to deal with the increasing 00:25:29.810 --> 00:25:32.370 align:middle line:84% complexity that you get with more than two agents. 00:25:32.370 --> 00:25:36.210 align:middle line:84% The first uses the two-agent case as a building block 00:25:36.210 --> 00:25:39.350 align:middle line:84% and it starts making pairwise comparisons. 00:25:39.350 --> 00:25:41.850 align:middle line:84% For example, you could choose a pseudo-agent 00:25:41.850 --> 00:25:45.330 align:middle line:84% for the ranking operator applied to two agents, 00:25:45.330 --> 00:25:48.750 align:middle line:84% figuring out which of those two has the highest bid, 00:25:48.750 --> 00:25:53.190 align:middle line:84% and then you can do that for all possible pairs of agents, 00:25:53.190 --> 00:25:59.610 align:middle line:84% and from that, you could deduce the overall highest bid. 00:25:59.610 --> 00:26:04.610 align:middle line:84% That gets into lots of pairs depending 00:26:04.610 --> 00:26:06.530 align:middle line:84% on the total number of agents, so that 00:26:06.530 --> 00:26:09.890 align:middle line:90% could be a bit onerous to do. 00:26:09.890 --> 00:26:12.410 align:middle line:84% And the second tries to economize 00:26:12.410 --> 00:26:14.650 align:middle line:84% on the number of comparisons, taking 00:26:14.650 --> 00:26:17.090 align:middle line:84% this N where N is a potentially large number 00:26:17.090 --> 00:26:20.650 align:middle line:84% and subdividing it into subgroups. 00:26:20.650 --> 00:26:25.250 align:middle line:84% So then you can compute the average for each subgroup 00:26:25.250 --> 00:26:29.200 align:middle line:84% just by adding up the bids, essentially, the encrypted bids. 00:26:29.200 --> 00:26:31.220 align:middle line:84% And then you have bids individually, 00:26:31.220 --> 00:26:33.000 align:middle line:84% so you eliminate from the subgroup 00:26:33.000 --> 00:26:36.040 align:middle line:84% all bids that were lower than the average. 00:26:36.040 --> 00:26:38.480 align:middle line:84% And you do that for each subgroup. 00:26:38.480 --> 00:26:47.000 align:middle line:84% And so you reduce the number of potential winners squishing 00:26:47.000 --> 00:26:50.320 align:middle line:84% the dimension of C down, and you do it all over again. 00:26:50.320 --> 00:26:57.440 align:middle line:84% So this is actually just involves less comparisons than-- 00:26:57.440 --> 00:26:59.222 align:middle line:84% AUDIENCE: More generally-- so this 00:26:59.222 --> 00:27:01.180 align:middle line:84% is for auctions, I can see that we can do this, 00:27:01.180 --> 00:27:03.120 align:middle line:84% but for more general mechanisms where 00:27:03.120 --> 00:27:05.880 align:middle line:84% we have more complicated allocation rules as functions 00:27:05.880 --> 00:27:09.840 align:middle line:84% of the types, what can we implement 00:27:09.840 --> 00:27:15.380 align:middle line:84% in a way that doesn't require a principal? 00:27:15.380 --> 00:27:19.790 align:middle line:84% Do we know what the limits are of this approach? 00:27:19.790 --> 00:27:21.540 align:middle line:84% Like, if you have multi-dimensional types, 00:27:21.540 --> 00:27:23.100 align:middle line:84% for instance, you can't order them, 00:27:23.100 --> 00:27:24.960 align:middle line:90% so then what do you do then? 00:27:24.960 --> 00:27:28.190 align:middle line:84% ROBERT TOWNSEND: Yeah, I only have a partial answer. 00:27:28.190 --> 00:27:31.270 align:middle line:84% So it's not completely satisfying, 00:27:31.270 --> 00:27:34.070 align:middle line:84% although I think it is true that what you can do 00:27:34.070 --> 00:27:37.230 align:middle line:90% depends on the context. 00:27:37.230 --> 00:27:41.780 align:middle line:84% What I'm not going to do today is have more than two 00:27:41.780 --> 00:27:45.510 align:middle line:84% or three applications and try to put them 00:27:45.510 --> 00:27:51.110 align:middle line:84% into groups where they share a common feature within a group 00:27:51.110 --> 00:27:53.230 align:middle line:90% and are different across groups. 00:27:53.230 --> 00:27:57.630 align:middle line:90% We are not, unfortunately. 00:27:57.630 --> 00:28:00.630 align:middle line:84% But I will show you a second example, 00:28:00.630 --> 00:28:03.870 align:middle line:84% and you'll see there the ways to reduce 00:28:03.870 --> 00:28:08.750 align:middle line:84% the dimensions are different than they are in this scheme. 00:28:08.750 --> 00:28:09.630 align:middle line:90% OK. 00:28:09.630 --> 00:28:14.750 align:middle line:84% So the second application is of borrowing and lending 00:28:14.750 --> 00:28:18.430 align:middle line:84% with insurance, and I'll give you three instances 00:28:18.430 --> 00:28:20.430 align:middle line:90% of where this comes up. 00:28:20.430 --> 00:28:25.100 align:middle line:84% Kenya, you may not recall from the second lecture, 00:28:25.100 --> 00:28:28.540 align:middle line:84% has M-Pesa, which is telecom agent, 00:28:28.540 --> 00:28:32.320 align:middle line:84% and there are two monies, essentially, in Kenya. 00:28:32.320 --> 00:28:34.840 align:middle line:84% We have the Kenyan shillings, the fiat money, 00:28:34.840 --> 00:28:40.100 align:middle line:84% and we have M-Pesa, which is this e-credit, so to speak, 00:28:40.100 --> 00:28:44.540 align:middle line:84% run by Safaricom, and there are all these dealer agents 00:28:44.540 --> 00:28:49.260 align:middle line:84% out there in Nairobi, near villages, and so on. 00:28:49.260 --> 00:28:55.340 align:middle line:84% And you go in, say, cash in, is to take your shillings 00:28:55.340 --> 00:29:00.980 align:middle line:84% and get credits for your cell phone from Safaricom, 00:29:00.980 --> 00:29:03.580 align:middle line:84% which you can use for buying some stuff 00:29:03.580 --> 00:29:06.760 align:middle line:84% or send back home to the village, 00:29:06.760 --> 00:29:10.400 align:middle line:84% and then the recipient there could cash out, 00:29:10.400 --> 00:29:13.740 align:middle line:84% going to a different agent, and convert the e-credit back 00:29:13.740 --> 00:29:15.740 align:middle line:90% into cash. 00:29:15.740 --> 00:29:18.900 align:middle line:84% So these agents are like dealers. 00:29:18.900 --> 00:29:21.500 align:middle line:84% And in principle, they need to carry inventory 00:29:21.500 --> 00:29:24.750 align:middle line:90% to be able to honor the demands. 00:29:24.750 --> 00:29:28.270 align:middle line:84% It's actually a pretty complicated inventory problem 00:29:28.270 --> 00:29:30.570 align:middle line:84% because they have to have inventory of both the fiat 00:29:30.570 --> 00:29:33.170 align:middle line:90% money and the e-stuff. 00:29:33.170 --> 00:29:37.610 align:middle line:84% The e-stuff is, in principle, transferable 00:29:37.610 --> 00:29:40.910 align:middle line:84% even from another dealer, but the fiat money, 00:29:40.910 --> 00:29:42.710 align:middle line:90% the currency part is not. 00:29:42.710 --> 00:29:45.370 align:middle line:84% You've got to get a hold of the physical currency 00:29:45.370 --> 00:29:48.150 align:middle line:90% to allow the client to back out. 00:29:48.150 --> 00:29:52.850 align:middle line:84% Now it turns out, from Tavneet Suri, 00:29:52.850 --> 00:29:57.650 align:middle line:84% she documented that these agents were informally 00:29:57.650 --> 00:29:58.990 align:middle line:90% helping each other out. 00:29:58.990 --> 00:30:01.250 align:middle line:84% You're running down the street giving 00:30:01.250 --> 00:30:05.490 align:middle line:84% gifts of one object or the other to each other in order 00:30:05.490 --> 00:30:08.570 align:middle line:84% for the dealers to be able to honor, 00:30:08.570 --> 00:30:13.890 align:middle line:84% on a reasonably timely basis, the demands of the clients. 00:30:13.890 --> 00:30:18.810 align:middle line:84% And in Indonesia, something similar is happening, 00:30:18.810 --> 00:30:21.100 align:middle line:90% but it's with commercial banks. 00:30:21.100 --> 00:30:22.600 align:middle line:84% Fortunately, they don't have to have 00:30:22.600 --> 00:30:25.360 align:middle line:84% marble pillars and big buildings, 00:30:25.360 --> 00:30:31.080 align:middle line:84% they can just be in some kiosk with a bank insignia, 00:30:31.080 --> 00:30:33.560 align:middle line:84% but these banks also complain because people 00:30:33.560 --> 00:30:35.480 align:middle line:90% have done surveys-- 00:30:35.480 --> 00:30:38.200 align:middle line:84% maybe the Gates Foundation did this survey. 00:30:38.200 --> 00:30:40.320 align:middle line:84% They're running out of stuff, too. 00:30:40.320 --> 00:30:42.380 align:middle line:84% And they're supposed to rebalance, 00:30:42.380 --> 00:30:43.960 align:middle line:84% but it's kind of difficult if you're 00:30:43.960 --> 00:30:48.080 align:middle line:84% running short to find a willing partner on the other end. 00:30:48.080 --> 00:30:51.800 align:middle line:84% And finally, something I've mentioned, in these New York 00:30:51.800 --> 00:30:54.280 align:middle line:84% markets, you have broker-dealers. 00:30:54.280 --> 00:30:57.760 align:middle line:84% As for repo, basically exchanging 00:30:57.760 --> 00:31:02.600 align:middle line:84% treasuries for liquidity or reserves or the other way 00:31:02.600 --> 00:31:05.680 align:middle line:84% around, and as is well-known, there 00:31:05.680 --> 00:31:08.680 align:middle line:84% are potentially big liquidity problems 00:31:08.680 --> 00:31:11.840 align:middle line:84% that emerge periodically in these New York markets 00:31:11.840 --> 00:31:15.940 align:middle line:84% where people are running out of cash-- the liquidity, pardon. 00:31:15.940 --> 00:31:19.360 align:middle line:84% Without it, the interest rate on the repos 00:31:19.360 --> 00:31:26.510 align:middle line:84% goes way above the policy guidance for market rates. 00:31:26.510 --> 00:31:30.910 align:middle line:84% These are arguably three pretty different setups. 00:31:30.910 --> 00:31:34.070 align:middle line:84% The common element here is they've all 00:31:34.070 --> 00:31:36.470 align:middle line:90% got their balance sheets. 00:31:36.470 --> 00:31:40.590 align:middle line:84% They're trying to mediate trades with clients. 00:31:40.590 --> 00:31:42.950 align:middle line:84% And so the state of their balance sheet 00:31:42.950 --> 00:31:44.950 align:middle line:90% is somewhat random. 00:31:44.950 --> 00:31:48.670 align:middle line:84% And they can be experiencing shortages. 00:31:48.670 --> 00:31:52.950 align:middle line:84% And they're potentially able to make deals, 00:31:52.950 --> 00:31:55.150 align:middle line:84% but now we throw in another aspect 00:31:55.150 --> 00:31:58.310 align:middle line:84% to this, is you may not want to tell the rest of the world 00:31:58.310 --> 00:32:01.950 align:middle line:84% exactly what your balance sheet looks like. 00:32:01.950 --> 00:32:04.190 align:middle line:84% If there is some gift-giving, borrowing, 00:32:04.190 --> 00:32:08.830 align:middle line:84% and lending scheme going on across these dealers, 00:32:08.830 --> 00:32:12.670 align:middle line:84% how do you induce them despite the benefit of sharing 00:32:12.670 --> 00:32:14.950 align:middle line:84% the risk-- it's a risk-sharing problem-- 00:32:14.950 --> 00:32:17.950 align:middle line:84% where the shocks are these shocks to the balance sheets? 00:32:17.950 --> 00:32:22.500 align:middle line:84% How do you assure them that they're not 00:32:22.500 --> 00:32:25.060 align:middle line:84% revealing the state of their balance sheet? 00:32:25.060 --> 00:32:27.620 align:middle line:90% So that's the motivation. 00:32:27.620 --> 00:32:31.140 align:middle line:84% And there's summary here at the beginning. 00:32:31.140 --> 00:32:34.380 align:middle line:84% Ex ante insurance is good, so hopefully that's 00:32:34.380 --> 00:32:36.060 align:middle line:90% kind of compelling. 00:32:36.060 --> 00:32:39.100 align:middle line:84% Everyone loves to smooth, say, especially 00:32:39.100 --> 00:32:42.900 align:middle line:84% against idiosyncratic liquidity shortage shocks. 00:32:42.900 --> 00:32:45.660 align:middle line:84% The next part is probably less obvious. 00:32:45.660 --> 00:32:49.720 align:middle line:84% Revealing the shocks as they occur too quickly, 00:32:49.720 --> 00:32:53.460 align:middle line:84% in other words, can damage beneficial trade. 00:32:53.460 --> 00:32:54.960 align:middle line:90% Why is it less than obvious? 00:32:54.960 --> 00:32:58.180 align:middle line:84% Well, if it's a static problem, then the person who's insured 00:32:58.180 --> 00:33:02.940 align:middle line:84% would basically wait till after the damage 00:33:02.940 --> 00:33:07.620 align:middle line:84% in order to enter into the insurance contract. 00:33:07.620 --> 00:33:12.540 align:middle line:84% And the insurance company knows it, so no insurance is possible. 00:33:12.540 --> 00:33:14.780 align:middle line:90% This has to do with the timing. 00:33:14.780 --> 00:33:20.730 align:middle line:84% Even though a loss has happened, it's beneficial to conceal that 00:33:20.730 --> 00:33:26.010 align:middle line:84% from other agents, so the person with the loss knows that it 00:33:26.010 --> 00:33:28.650 align:middle line:84% happened, but the other ones don't. 00:33:28.650 --> 00:33:31.530 align:middle line:84% And that allows insurance to take place 00:33:31.530 --> 00:33:36.670 align:middle line:84% even over utilizing shocks that have already happened, 00:33:36.670 --> 00:33:38.170 align:middle line:84% and yeah, where we're going is we're 00:33:38.170 --> 00:33:42.410 align:middle line:84% going to want to encrypt these histories. 00:33:42.410 --> 00:33:46.610 align:middle line:84% OK, so let's think about formalizing this as a mechanism 00:33:46.610 --> 00:33:50.010 align:middle line:84% design problem with this concealment, 00:33:50.010 --> 00:33:52.310 align:middle line:90% and, again, we'll simplify it. 00:33:52.310 --> 00:33:55.050 align:middle line:84% So it's an example, there are two agents, 00:33:55.050 --> 00:33:59.930 align:middle line:84% A and B. Each have utility functions subject to privately 00:33:59.930 --> 00:34:01.410 align:middle line:90% observed shocks. 00:34:01.410 --> 00:34:02.990 align:middle line:90% So let me pause on that. 00:34:02.990 --> 00:34:07.010 align:middle line:84% I just jumped from a shock to your endowment, 00:34:07.010 --> 00:34:11.489 align:middle line:84% to your balance sheet, to a shock to your preferences. 00:34:11.489 --> 00:34:15.960 align:middle line:84% But you could well imagine, this works out 00:34:15.960 --> 00:34:19.060 align:middle line:84% for the example I had in mind with the balance sheet shocks 00:34:19.060 --> 00:34:23.100 align:middle line:84% because if your balance sheet is low and you're a concave person, 00:34:23.100 --> 00:34:24.920 align:middle line:90% you're pretty risk-averse. 00:34:24.920 --> 00:34:27.480 align:middle line:84% It's in a reduced form way, as if you're 00:34:27.480 --> 00:34:30.000 align:middle line:84% getting a shock to your preferences that 00:34:30.000 --> 00:34:33.560 align:middle line:90% make you urgent. 00:34:33.560 --> 00:34:36.179 align:middle line:84% Two agents-- there are two periods only, 00:34:36.179 --> 00:34:39.560 align:middle line:84% and this planner, agent A in the first period 00:34:39.560 --> 00:34:44.239 align:middle line:84% could be patient or urgent to consume sending that 00:34:44.239 --> 00:34:46.600 align:middle line:90% a message to the planner. 00:34:46.600 --> 00:34:49.360 align:middle line:84% And I'll go through this in more detail, but you may remember, 00:34:49.360 --> 00:34:51.480 align:middle line:84% we did the revelation principle where, 00:34:51.480 --> 00:34:56.719 align:middle line:84% without loss of generality, we can solve these mechanism design 00:34:56.719 --> 00:34:59.600 align:middle line:84% problems by having the agents truthfully 00:34:59.600 --> 00:35:01.420 align:middle line:90% report what actually happened. 00:35:01.420 --> 00:35:05.720 align:middle line:84% So in this case, agent A would send a truthful report 00:35:05.720 --> 00:35:08.080 align:middle line:90% to the planner. 00:35:08.080 --> 00:35:09.400 align:middle line:90% Uh oh. 00:35:09.400 --> 00:35:11.760 align:middle line:90% OK, so we'll get there. 00:35:11.760 --> 00:35:14.160 align:middle line:84% If the planner is a third party, the planner 00:35:14.160 --> 00:35:17.670 align:middle line:84% now knows this, the state of the balance sheet. 00:35:17.670 --> 00:35:20.850 align:middle line:84% And B does the same, but in the second period. 00:35:20.850 --> 00:35:23.110 align:middle line:84% This is the way, the example is going to work. 00:35:23.110 --> 00:35:26.430 align:middle line:84% First A, and then B. First period, second period. 00:35:26.430 --> 00:35:30.550 align:middle line:84% The planner sees the messages, but makes sure other agents 00:35:30.550 --> 00:35:31.050 align:middle line:90% don't. 00:35:31.050 --> 00:35:35.150 align:middle line:84% So the planner is trusted and committed not to reveal stuff. 00:35:35.150 --> 00:35:37.430 align:middle line:84% And there are incentives to tell the truth 00:35:37.430 --> 00:35:39.110 align:middle line:84% in both periods, and in particular, 00:35:39.110 --> 00:35:41.350 align:middle line:90% in the second period. 00:35:41.350 --> 00:35:44.110 align:middle line:84% This intuition for where we're about to go, 00:35:44.110 --> 00:35:48.830 align:middle line:84% having to do with the dynamics, is that there's only two 00:35:48.830 --> 00:35:52.310 align:middle line:90% periods, there's only one good. 00:35:52.310 --> 00:35:54.590 align:middle line:84% Pretty hard to engineer trade because more 00:35:54.590 --> 00:35:56.830 align:middle line:90% is preferred to less. 00:35:56.830 --> 00:36:00.090 align:middle line:84% So if the transfers were to vary-- say I'm low, 00:36:00.090 --> 00:36:02.390 align:middle line:84% I want stuff, you would always say 00:36:02.390 --> 00:36:04.830 align:middle line:84% that in order to always get stuff, 00:36:04.830 --> 00:36:08.510 align:middle line:84% and that makes trade in the second period very difficult. 00:36:08.510 --> 00:36:13.550 align:middle line:84% So that's what we're going to try to conceal Sorry, 00:36:13.550 --> 00:36:15.670 align:middle line:84% by concealing what happened in the first period, 00:36:15.670 --> 00:36:20.730 align:middle line:84% we will get around this problem that we can't get much insurance 00:36:20.730 --> 00:36:22.490 align:middle line:90% in the second period. 00:36:22.490 --> 00:36:24.570 align:middle line:90% OK. 00:36:24.570 --> 00:36:28.190 align:middle line:84% So this is a more general version of the setup. 00:36:28.190 --> 00:36:30.570 align:middle line:84% It's still two agents and two periods, 00:36:30.570 --> 00:36:33.550 align:middle line:84% but they're each, in principle, experiencing shocks. 00:36:33.550 --> 00:36:34.770 align:middle line:90% In both periods. 00:36:34.770 --> 00:36:36.190 align:middle line:90% They're getting endowments. 00:36:36.190 --> 00:36:41.030 align:middle line:84% The endowments are deterministic and known by both agents. 00:36:41.030 --> 00:36:43.410 align:middle line:84% We're going to exploit that in the sense 00:36:43.410 --> 00:36:46.650 align:middle line:84% that that stuff can be sequestered and put 00:36:46.650 --> 00:36:50.570 align:middle line:84% into collateral, put into escrow. 00:36:50.570 --> 00:36:52.190 align:middle line:84% So they know the size of the pool, 00:36:52.190 --> 00:36:54.650 align:middle line:84% they just don't know their preference shocks. 00:36:54.650 --> 00:37:00.050 align:middle line:84% Each agent I has utility over consumption 00:37:00.050 --> 00:37:03.650 align:middle line:84% in the first state, which is a bit confusingly 00:37:03.650 --> 00:37:08.370 align:middle line:84% labeled 0, and consumption in the second date, 00:37:08.370 --> 00:37:13.600 align:middle line:84% subscript 1, with shock being drawn, 00:37:13.600 --> 00:37:16.840 align:middle line:84% hitting utility in each of those periods. 00:37:16.840 --> 00:37:21.480 align:middle line:84% So with an i on it, this is the consumption path, 00:37:21.480 --> 00:37:26.280 align:middle line:84% although in realized time, would be stochastic path 00:37:26.280 --> 00:37:30.220 align:middle line:84% and is deterministic for any particular draws, 00:37:30.220 --> 00:37:32.780 align:middle line:90% but the draws are random. 00:37:32.780 --> 00:37:36.920 align:middle line:84% In this case, there are two parameter 00:37:36.920 --> 00:37:42.240 align:middle line:84% draws for each agent in period 0 and period 1, 00:37:42.240 --> 00:37:46.840 align:middle line:84% so this 4 tuple is the underlying state 00:37:46.840 --> 00:37:49.360 align:middle line:84% of the preference shocks, and it's being-- 00:37:49.360 --> 00:37:52.620 align:middle line:84% the way it's being drawn is common knowledge to the agents, 00:37:52.620 --> 00:37:55.640 align:middle line:84% but the particular draws are not. 00:37:55.640 --> 00:37:58.380 align:middle line:84% The correlation structure can get pretty complicated. 00:37:58.380 --> 00:38:00.480 align:middle line:90% I'll come back to that. 00:38:00.480 --> 00:38:03.800 align:middle line:84% So we assume there's an insurance provider 00:38:03.800 --> 00:38:09.600 align:middle line:84% as a mediator or planner, collects information 00:38:09.600 --> 00:38:11.790 align:middle line:84% from the agents, decides on how to split 00:38:11.790 --> 00:38:15.870 align:middle line:84% the endowment in each period as a function of what 00:38:15.870 --> 00:38:17.910 align:middle line:90% the agents report. 00:38:17.910 --> 00:38:20.090 align:middle line:84% We're going to do the obvious thing. 00:38:20.090 --> 00:38:22.390 align:middle line:84% We're going to maximize a weighted sum 00:38:22.390 --> 00:38:26.270 align:middle line:84% of the objective functions of the participants subject 00:38:26.270 --> 00:38:28.790 align:middle line:84% to these resource constraints and to 00:38:28.790 --> 00:38:31.110 align:middle line:90% the truth-telling constraints. 00:38:31.110 --> 00:38:34.510 align:middle line:90% So nothing new there. 00:38:34.510 --> 00:38:38.330 align:middle line:84% As I said, the revelation principle rule will apply. 00:38:38.330 --> 00:38:42.790 align:middle line:84% So agents will be sending messages about stuff. 00:38:42.790 --> 00:38:47.290 align:middle line:84% In particular, at date 0, each has a preference shock. 00:38:47.290 --> 00:38:51.190 align:middle line:84% They could be sending that truthful message to the planner. 00:38:51.190 --> 00:38:55.350 align:middle line:84% The state at the second period, due to the correlation structure 00:38:55.350 --> 00:38:58.590 align:middle line:84% of the shocks, is not simply the new shock 00:38:58.590 --> 00:39:03.790 align:middle line:84% that happens at date 1, it's also what happened previously. 00:39:03.790 --> 00:39:06.470 align:middle line:84% That's the underlying true state as far 00:39:06.470 --> 00:39:10.780 align:middle line:84% as the agent is concerned, so there's 00:39:10.780 --> 00:39:16.540 align:middle line:84% values being set for both shocks for each agent I. 00:39:16.540 --> 00:39:19.460 align:middle line:84% So this is a little more general than the example 00:39:19.460 --> 00:39:21.260 align:middle line:90% we're going to go through. 00:39:21.260 --> 00:39:24.100 align:middle line:84% It has the common aspect of having only two periods 00:39:24.100 --> 00:39:27.780 align:middle line:84% and having only two agents, but it allows unlike, 00:39:27.780 --> 00:39:31.940 align:middle line:84% the example, that each agent has shocks in each period. 00:39:31.940 --> 00:39:36.300 align:middle line:84% You could imagine that the planner could send messages back 00:39:36.300 --> 00:39:39.060 align:middle line:84% to the agents about the other guys. 00:39:39.060 --> 00:39:41.660 align:middle line:84% There could be partial revelation. 00:39:41.660 --> 00:39:44.540 align:middle line:84% Here, there's some, quote, "inevitable" 00:39:44.540 --> 00:39:48.760 align:middle line:84% revelation that happens just by virtue of the setup. 00:39:48.760 --> 00:39:51.900 align:middle line:84% People are going to eat at the first date, 00:39:51.900 --> 00:39:56.540 align:middle line:84% so that some of those endowments has to get distributed. 00:39:56.540 --> 00:40:02.683 align:middle line:84% And so you're going to learn something from what you get, 00:40:02.683 --> 00:40:04.100 align:middle line:84% and for that matter, you know what 00:40:04.100 --> 00:40:08.730 align:middle line:84% the other guy gets because you know how it adds up. 00:40:08.730 --> 00:40:15.450 align:middle line:84% So you'll see that that could reveal quite a lot about what 00:40:15.450 --> 00:40:20.410 align:middle line:84% the other agent said and destroy the possibility of trade 00:40:20.410 --> 00:40:23.610 align:middle line:90% in the second period. 00:40:23.610 --> 00:40:25.430 align:middle line:84% So we're going to work on concealing that. 00:40:25.430 --> 00:40:29.890 align:middle line:84% So this, in notation, is the example 00:40:29.890 --> 00:40:35.330 align:middle line:84% where A goes first and at 0 and B goes second at 1. 00:40:35.330 --> 00:40:41.110 align:middle line:84% And if you first look at these utility functions, 00:40:41.110 --> 00:40:43.610 align:middle line:90% they're just power functions. 00:40:43.610 --> 00:40:46.130 align:middle line:90% It's consumption to some power. 00:40:46.130 --> 00:40:50.970 align:middle line:84% Its power is either known, public common knowledge, 00:40:50.970 --> 00:40:53.030 align:middle line:90% or potentially random. 00:40:53.030 --> 00:40:56.690 align:middle line:90% 00:40:56.690 --> 00:41:02.570 align:middle line:84% These lines try to capture that, but in a very clumsy way, 00:41:02.570 --> 00:41:05.850 align:middle line:84% because we're not saying the utility functions are the same 00:41:05.850 --> 00:41:08.760 align:middle line:84% and the realized value of utility 00:41:08.760 --> 00:41:10.800 align:middle line:90% is the same in each period. 00:41:10.800 --> 00:41:13.520 align:middle line:84% This really only meant to say that there's 00:41:13.520 --> 00:41:18.040 align:middle line:84% a common underlying utility form of a utility function, which 00:41:18.040 --> 00:41:21.080 align:middle line:90% is consumption to a power. 00:41:21.080 --> 00:41:26.000 align:middle line:84% OK. a is the one with the unknown theta parameter value. 00:41:26.000 --> 00:41:30.160 align:middle line:84% At date 0, it could be 0.2 or 0.9. 00:41:30.160 --> 00:41:33.120 align:middle line:84% On the other hand, agent A's parameter at date one 00:41:33.120 --> 00:41:36.600 align:middle line:90% is known for sure to be 0.3. 00:41:36.600 --> 00:41:41.200 align:middle line:84% B is in a symmetric position, but not with respect to time. 00:41:41.200 --> 00:41:45.160 align:middle line:84% B's parameter at 0 is known to be 0.9. 00:41:45.160 --> 00:41:48.040 align:middle line:84% Even that's not symmetric because it was 0.3, now 00:41:48.040 --> 00:41:50.880 align:middle line:84% it's 0.9 for the known parameter. 00:41:50.880 --> 00:41:55.120 align:middle line:84% But b is subject to these unknown uncertainty 00:41:55.120 --> 00:42:00.240 align:middle line:84% about the parameter draw, which is, again, either 0.2 or 0.9. 00:42:00.240 --> 00:42:02.020 align:middle line:90% And it's pretty complicated. 00:42:02.020 --> 00:42:04.400 align:middle line:84% The correlation structure is anything 00:42:04.400 --> 00:42:07.350 align:middle line:84% can happen with positive probability. 00:42:07.350 --> 00:42:10.870 align:middle line:84% Any of these parameter draws for agents a 00:42:10.870 --> 00:42:14.850 align:middle line:84% and b at date 0 and 1 is possible. 00:42:14.850 --> 00:42:18.130 align:middle line:84% The deterministic stuff is just that, deterministic, 00:42:18.130 --> 00:42:20.190 align:middle line:90% so it's not random at all. 00:42:20.190 --> 00:42:24.910 align:middle line:84% I'm going to show you a computed numerical example. 00:42:24.910 --> 00:42:28.990 align:middle line:84% I don't know how general it was, and certainly, it's 00:42:28.990 --> 00:42:31.670 align:middle line:84% been on my agenda for quite some time 00:42:31.670 --> 00:42:35.830 align:middle line:84% to come back to this kind of environment 00:42:35.830 --> 00:42:37.790 align:middle line:90% and compute some stuff-- 00:42:37.790 --> 00:42:42.030 align:middle line:84% or deduce some stuff more generally. 00:42:42.030 --> 00:42:45.630 align:middle line:84% So, again, the endowments are known. 00:42:45.630 --> 00:42:47.770 align:middle line:90% 5 for each, it adds up to 10. 00:42:47.770 --> 00:42:52.830 align:middle line:84% There's a discount rate of 0.95, and the lambdas 00:42:52.830 --> 00:42:56.630 align:middle line:84% are going to treat the agents similarly. 00:42:56.630 --> 00:42:59.550 align:middle line:84% So here is-- to be very careful with the header 00:42:59.550 --> 00:43:05.300 align:middle line:84% to this table, it's called fully revealed communication. 00:43:05.300 --> 00:43:09.380 align:middle line:84% That does not mean we got rid of the private information. 00:43:09.380 --> 00:43:14.740 align:middle line:84% It means that these messages that are sent about the shocks 00:43:14.740 --> 00:43:18.700 align:middle line:84% are basically revealed to the other party. 00:43:18.700 --> 00:43:24.380 align:middle line:84% So agent A could be patient or urgent, 00:43:24.380 --> 00:43:26.300 align:middle line:84% and there's going to be trade-offs 00:43:26.300 --> 00:43:32.660 align:middle line:84% that induce agent A to tell the truth about things. 00:43:32.660 --> 00:43:40.540 align:middle line:84% Note that, roughly speaking, when your patient in the first-- 00:43:40.540 --> 00:43:45.140 align:middle line:84% date 0, you get less than when you say you're urgent. 00:43:45.140 --> 00:43:49.820 align:middle line:84% So the allocation is trying to accommodate the urgency. 00:43:49.820 --> 00:43:51.560 align:middle line:84% There's a little bit of a lottery here, 00:43:51.560 --> 00:43:53.720 align:middle line:84% we'll come back to those things in a minute. 00:43:53.720 --> 00:43:59.620 align:middle line:90% 00:43:59.620 --> 00:44:05.870 align:middle line:84% So in this row, as an example of what can happen over time, 00:44:05.870 --> 00:44:15.610 align:middle line:84% agent A is patient expecting to get more in the second period, 00:44:15.610 --> 00:44:20.830 align:middle line:84% and will get 2.5, which is higher than 1.75. 00:44:20.830 --> 00:44:25.390 align:middle line:84% And there's a more complicated trade-off likewise. 00:44:25.390 --> 00:44:27.970 align:middle line:84% When he says urgent, in some sense, 00:44:27.970 --> 00:44:30.330 align:middle line:84% he's going to get less in expectation 00:44:30.330 --> 00:44:31.430 align:middle line:90% in the second period. 00:44:31.430 --> 00:44:35.050 align:middle line:84% So it's incentive-compatible, like the borrowing and lending 00:44:35.050 --> 00:44:38.330 align:middle line:84% example that we went through at one point, 00:44:38.330 --> 00:44:42.330 align:middle line:84% to tell the truth about whether you're patient or urgent. 00:44:42.330 --> 00:44:49.010 align:middle line:84% The thing to focus on here is we're in the first row, 00:44:49.010 --> 00:44:53.370 align:middle line:84% and agent B knows it, so it's very hard 00:44:53.370 --> 00:44:56.090 align:middle line:90% to get any trade going on here. 00:44:56.090 --> 00:45:01.560 align:middle line:84% In fact, the allocation is the same regardless of the parameter 00:45:01.560 --> 00:45:05.640 align:middle line:90% drawer for agent B in period. 00:45:05.640 --> 00:45:07.420 align:middle line:84% There's movement of goods over time, 00:45:07.420 --> 00:45:14.480 align:middle line:84% but not over theta b1, the shock of agent B at date 1. 00:45:14.480 --> 00:45:20.120 align:middle line:84% There is some, quote, "exchange" and insurance going on at day 2, 00:45:20.120 --> 00:45:23.260 align:middle line:84% which is, again, something I said, 00:45:23.260 --> 00:45:25.660 align:middle line:84% but we didn't have notation to back it up, 00:45:25.660 --> 00:45:28.440 align:middle line:90% or a numerical example. 00:45:28.440 --> 00:45:32.080 align:middle line:84% Agent B here-- this is the row-- sorry-- 00:45:32.080 --> 00:45:37.000 align:middle line:84% where agent A said he was urgent. 00:45:37.000 --> 00:45:39.400 align:middle line:90% And now it's agent B's turn. 00:45:39.400 --> 00:45:47.400 align:middle line:84% He could say 0.2 or 0.9, and the allocation is different. 00:45:47.400 --> 00:45:51.200 align:middle line:84% If he's 0.2, he gets 6.25 for sure. 00:45:51.200 --> 00:45:55.400 align:middle line:84% If he were that, he might be tempted to lie about it 00:45:55.400 --> 00:45:59.040 align:middle line:84% and say he's 0.9, and there's a good chance 00:45:59.040 --> 00:46:02.230 align:middle line:84% he will get more of the good that way. 00:46:02.230 --> 00:46:04.150 align:middle line:84% And if this line weren't here, he 00:46:04.150 --> 00:46:10.950 align:middle line:84% would definitely lie and always claim the high incoming number, 00:46:10.950 --> 00:46:13.290 align:middle line:84% which is why this got reduced to no trade. 00:46:13.290 --> 00:46:21.490 align:middle line:84% But here, there's a lottery, 10%, 11% chance of getting 0. 00:46:21.490 --> 00:46:27.630 align:middle line:90% So if he's really-- 00:46:27.630 --> 00:46:33.110 align:middle line:84% a trade-off here is basically to take your-- 00:46:33.110 --> 00:46:37.150 align:middle line:84% not take a chance and get the deterministic allocation 00:46:37.150 --> 00:46:43.310 align:middle line:84% if you're a 0.2 guy, which is a pretty curvature person, 00:46:43.310 --> 00:46:46.730 align:middle line:84% versus claiming you're 0.9, even though you're not, 00:46:46.730 --> 00:46:50.110 align:middle line:84% and being subject to this lottery, that could give you 00:46:50.110 --> 00:46:53.370 align:middle line:84% a pretty awful outcome with 11% probability. 00:46:53.370 --> 00:46:55.950 align:middle line:84% So that lottery is enough to keep 00:46:55.950 --> 00:47:03.700 align:middle line:84% this guy honest and claiming the smaller allocation. 00:47:03.700 --> 00:47:09.300 align:middle line:84% So that's an example of why these lotteries are popping up. 00:47:09.300 --> 00:47:13.100 align:middle line:84% So here's an example where, with fully revealed communication 00:47:13.100 --> 00:47:16.020 align:middle line:84% to the other party, it's damaging in the sense 00:47:16.020 --> 00:47:19.020 align:middle line:84% that we don't get any insurance for agent-- 00:47:19.020 --> 00:47:23.300 align:middle line:84% for either one of them, quote, but particularly for agent B 00:47:23.300 --> 00:47:26.020 align:middle line:90% in this top row. 00:47:26.020 --> 00:47:31.900 align:middle line:84% OK, so if we could conceal the information, we can do better. 00:47:31.900 --> 00:47:37.060 align:middle line:84% And the way that goes is the allocation at 0.2-- 00:47:37.060 --> 00:47:40.380 align:middle line:84% you'll get dizzy if I'm flipping back and forth too much-- 00:47:40.380 --> 00:47:44.700 align:middle line:84% is exactly the same as it was before, but now, 00:47:44.700 --> 00:47:50.740 align:middle line:84% with 3.3% chance, when agent A says he's urgent at 0.9, 00:47:50.740 --> 00:47:53.580 align:middle line:84% the same allocation that happened in the first row 00:47:53.580 --> 00:47:56.020 align:middle line:90% could happen here. 00:47:56.020 --> 00:48:03.990 align:middle line:84% So roughly this-- this only happens 3% of the time, 00:48:03.990 --> 00:48:08.530 align:middle line:84% but this happens-- this row happens as often as agent A 00:48:08.530 --> 00:48:13.610 align:middle line:90% could be patient at date 0. 00:48:13.610 --> 00:48:17.490 align:middle line:84% So just seeing this doesn't tell agent B 00:48:17.490 --> 00:48:24.490 align:middle line:84% in particular which world he or she is in. 00:48:24.490 --> 00:48:28.130 align:middle line:84% When the 1.75, 8.25 happens, it could 00:48:28.130 --> 00:48:32.790 align:middle line:84% be because agent A said that he was 0.2, 00:48:32.790 --> 00:48:35.290 align:middle line:84% but it could happen because agent B-- 00:48:35.290 --> 00:48:39.250 align:middle line:84% sorry, agent A said 0.9, and by luck of the draw, 00:48:39.250 --> 00:48:42.010 align:middle line:90% that same allocation happened. 00:48:42.010 --> 00:48:46.690 align:middle line:84% So note now that we're getting some insurance for agent 00:48:46.690 --> 00:48:50.330 align:middle line:84% B. In particular, B can get more of the consumption 00:48:50.330 --> 00:48:56.240 align:middle line:84% good when he says 0.9 than when he says 0.2. 00:48:56.240 --> 00:49:00.880 align:middle line:84% So we've engineered some beneficial insurance. 00:49:00.880 --> 00:49:04.040 align:middle line:90% How is that happening? 00:49:04.040 --> 00:49:12.040 align:middle line:84% The answer is, well, I saw my allocation, so I could well 00:49:12.040 --> 00:49:15.280 align:middle line:84% be in this row, but it's possible 00:49:15.280 --> 00:49:19.700 align:middle line:84% that I live in the second row and agent B has said point-- 00:49:19.700 --> 00:49:20.780 align:middle line:90% sorry, I did that again. 00:49:20.780 --> 00:49:23.240 align:middle line:90% Agent A has said 0.9. 00:49:23.240 --> 00:49:30.610 align:middle line:84% So if I'm tempted to cheat and say-- 00:49:30.610 --> 00:49:33.140 align:middle line:90% like, he's getting 5.25. 00:49:33.140 --> 00:49:37.800 align:middle line:84% If he says 0.2, why not claim 0.9 and get 8? 00:49:37.800 --> 00:49:42.360 align:middle line:84% And the answer is if he's down here and he says 0.9, 00:49:42.360 --> 00:49:46.760 align:middle line:84% there's a 14% chance he's going to get 0. 00:49:46.760 --> 00:49:49.280 align:middle line:90% So that's the deterrent. 00:49:49.280 --> 00:49:52.600 align:middle line:84% That's enough to make him honest. 00:49:52.600 --> 00:49:55.230 align:middle line:84% These were all solved with linear programs, 00:49:55.230 --> 00:49:59.670 align:middle line:84% with incentive constraints being carefully enumerated and so on. 00:49:59.670 --> 00:50:03.390 align:middle line:84% Well actually, take a deep breath because all of this 00:50:03.390 --> 00:50:08.150 align:middle line:84% was the preamble to here's the economic allocations we want-- 00:50:08.150 --> 00:50:10.790 align:middle line:90% this one. 00:50:10.790 --> 00:50:12.630 align:middle line:84% We weren't so happy with the one where 00:50:12.630 --> 00:50:14.430 align:middle line:90% there was full communication. 00:50:14.430 --> 00:50:16.710 align:middle line:90% We still got this planner. 00:50:16.710 --> 00:50:19.430 align:middle line:84% So how do we get rid of the planner 00:50:19.430 --> 00:50:21.230 align:middle line:84% and yet have all this communication 00:50:21.230 --> 00:50:23.670 align:middle line:84% going on, and in particular, have this kind 00:50:23.670 --> 00:50:26.110 align:middle line:90% of randomization going on? 00:50:26.110 --> 00:50:31.470 align:middle line:84% Because for all the world, when the randomization kicks in, 00:50:31.470 --> 00:50:37.230 align:middle line:84% it kicks in when agent A says 0.9, but in an encrypted world, 00:50:37.230 --> 00:50:39.830 align:middle line:90% how would the code know that? 00:50:39.830 --> 00:50:44.670 align:middle line:84% Because the code is not supposed to know the realized values, 00:50:44.670 --> 00:50:49.470 align:middle line:84% so it's potentially a bit of a challenge. 00:50:49.470 --> 00:50:53.780 align:middle line:84% So we're going to use the encryption scheme that we had 00:50:53.780 --> 00:50:56.660 align:middle line:90% for the auction, same notation. 00:50:56.660 --> 00:51:02.740 align:middle line:84% We'll use the pseudo-agent, the code, to conceal things-- 00:51:02.740 --> 00:51:03.640 align:middle line:90% well, both. 00:51:03.640 --> 00:51:05.100 align:middle line:90% That's the twist. 00:51:05.100 --> 00:51:09.500 align:middle line:84% Both to be in the dark about underlying things, 00:51:09.500 --> 00:51:14.180 align:middle line:84% but also amazingly able to conceal stuff, nevertheless, 00:51:14.180 --> 00:51:17.860 align:middle line:90% from the agents. 00:51:17.860 --> 00:51:20.840 align:middle line:84% So they're going to enter into this risk pooling contract. 00:51:20.840 --> 00:51:23.580 align:middle line:90% 00:51:23.580 --> 00:51:25.860 align:middle line:90% They agree to it. 00:51:25.860 --> 00:51:28.900 align:middle line:84% They put their stuff in escrow, so that's now 00:51:28.900 --> 00:51:33.020 align:middle line:84% accessible by the code, like the balance sheets are sequestered 00:51:33.020 --> 00:51:35.580 align:middle line:90% for transfers, et cetera. 00:51:35.580 --> 00:51:37.660 align:middle line:84% The node, if this is Ethereum, is 00:51:37.660 --> 00:51:41.020 align:middle line:90% the one-- is the contract node. 00:51:41.020 --> 00:51:45.260 align:middle line:84% Agent A is going to send a message as this thing gets 00:51:45.260 --> 00:51:49.860 align:middle line:84% realized about whether he or she is high need of liquidity 00:51:49.860 --> 00:51:54.890 align:middle line:90% or low, urgent or patient. 00:51:54.890 --> 00:52:03.210 align:middle line:84% We'll take the central planner and replace it by this code C. 00:52:03.210 --> 00:52:08.530 align:middle line:84% So this is the big overview of how this thing works. 00:52:08.530 --> 00:52:11.690 align:middle line:84% The most shallow, but useful thing to remember from this 00:52:11.690 --> 00:52:15.410 align:middle line:84% is all these messages going back and forth between agents 00:52:15.410 --> 00:52:18.170 align:middle line:84% A and B, which are encrypted, but also 00:52:18.170 --> 00:52:22.730 align:middle line:84% messages going back from one of the agents after some exchange 00:52:22.730 --> 00:52:24.610 align:middle line:90% back to the code. 00:52:24.610 --> 00:52:29.370 align:middle line:84% So there's both fully homomorphic encryption aspects 00:52:29.370 --> 00:52:31.490 align:middle line:84% in the sense that the code will eventually 00:52:31.490 --> 00:52:34.690 align:middle line:84% act on the encrypted messages received. 00:52:34.690 --> 00:52:38.330 align:middle line:84% It also is going to have these multi-party computation 00:52:38.330 --> 00:52:43.490 align:middle line:84% aspects where the agents are sending messages 00:52:43.490 --> 00:52:46.770 align:middle line:84% back and forth initially before something 00:52:46.770 --> 00:52:48.890 align:middle line:90% gets submitted to the code. 00:52:48.890 --> 00:52:53.600 align:middle line:84% And also-- and I'll show you a bit of this, 00:52:53.600 --> 00:52:57.000 align:middle line:84% you may remember from last time that we-- 00:52:57.000 --> 00:53:04.440 align:middle line:84% with the ElGamal example of cyclic rings, 00:53:04.440 --> 00:53:06.360 align:middle line:84% we were saying certain properties 00:53:06.360 --> 00:53:09.100 align:middle line:84% of the encryption algorithm have to be satisfied, 00:53:09.100 --> 00:53:12.560 align:middle line:84% it has to be distributed, commutative, associative, 00:53:12.560 --> 00:53:17.160 align:middle line:90% and so on, and I'll show you-- 00:53:17.160 --> 00:53:21.760 align:middle line:84% I'm not going to show you every slide because this alone 00:53:21.760 --> 00:53:24.440 align:middle line:84% is going to be hard to remember, but I'll 00:53:24.440 --> 00:53:28.600 align:middle line:84% highlight where these different properties 00:53:28.600 --> 00:53:32.700 align:middle line:84% of the different algebraic properties are entering. 00:53:32.700 --> 00:53:34.180 align:middle line:90% OK, so how does it work? 00:53:34.180 --> 00:53:37.240 align:middle line:84% They've agreed to the contract, but before anything actually 00:53:37.240 --> 00:53:41.640 align:middle line:84% happens after that, agent A, remember, goes first, 00:53:41.640 --> 00:53:46.120 align:middle line:84% is going to send two encrypted values to B, one of them 00:53:46.120 --> 00:53:51.510 align:middle line:84% is going to be the encrypted value of the urgent shock-- 00:53:51.510 --> 00:53:52.970 align:middle line:90% high, h sub A. 00:53:52.970 --> 00:53:57.670 align:middle line:84% And the second one, the other remaining one, 00:53:57.670 --> 00:54:01.070 align:middle line:84% is going to be the encrypted value of the low shock, 00:54:01.070 --> 00:54:05.910 align:middle line:84% l sub A. The key here is the encryption scheme is now 00:54:05.910 --> 00:54:12.470 align:middle line:84% set for hA and lA, but the order in which BA 00:54:12.470 --> 00:54:19.070 align:middle line:84% is sending these encrypted messages to B is not known to B, 00:54:19.070 --> 00:54:22.430 align:middle line:84% and effectively can be determined at random initially 00:54:22.430 --> 00:54:24.135 align:middle line:90% by agent A. 00:54:24.135 --> 00:54:26.510 align:middle line:84% I'm going to encrypt the high value first, then the low-- 00:54:26.510 --> 00:54:27.470 align:middle line:90% no, no, no. 00:54:27.470 --> 00:54:30.350 align:middle line:84% I'm going to encrypt the low value first and then the high. 00:54:30.350 --> 00:54:32.010 align:middle line:90% B does not know that. 00:54:32.010 --> 00:54:36.150 align:middle line:84% So B is in receipt of two encrypted messages, 00:54:36.150 --> 00:54:40.470 align:middle line:84% call the first one m1, the second m2, 00:54:40.470 --> 00:54:43.030 align:middle line:84% but each one is a ciphertext and it 00:54:43.030 --> 00:54:49.300 align:middle line:84% doesn't convey anything about the underlying h sub A or l sub 00:54:49.300 --> 00:54:51.460 align:middle line:90% A. 00:54:51.460 --> 00:54:53.910 align:middle line:84% So he sends 1, so that's the order, 00:54:53.910 --> 00:54:58.340 align:middle line:84% and m1 is the encrypted first number, 00:54:58.340 --> 00:55:02.540 align:middle line:84% M2 is the encrypted second number. 00:55:02.540 --> 00:55:09.980 align:middle line:84% So B here takes those messages and sends it to C. Sorry. 00:55:09.980 --> 00:55:13.540 align:middle line:84% I guess I didn't go through this line. 00:55:13.540 --> 00:55:20.860 align:middle line:84% So A will send something else to B. Note the arrows from A to B. 00:55:20.860 --> 00:55:25.140 align:middle line:84% The other thing that a is sending is not just these-- 00:55:25.140 --> 00:55:28.620 align:middle line:84% some order of these high and low shocks, but also sending 00:55:28.620 --> 00:55:34.340 align:middle line:84% to B an encrypted value of this vector, which is 1, 0 or 0, 00:55:34.340 --> 00:55:40.300 align:middle line:84% 1 depending on the order in which A chose 00:55:40.300 --> 00:55:45.500 align:middle line:90% to send messages m1 and m2 to-- 00:55:45.500 --> 00:55:50.550 align:middle line:84% sorry, the order of the actual ordering of the m1 versus m2. 00:55:50.550 --> 00:55:59.810 align:middle line:84% So for example, if agent A had chosen to send the high value, 00:55:59.810 --> 00:56:04.290 align:middle line:84% hA first, then the encryption would 00:56:04.290 --> 00:56:07.530 align:middle line:90% be the encrypted value of 1, 0. 00:56:07.530 --> 00:56:12.010 align:middle line:84% And if he had chosen to send the low value encrypted first, 00:56:12.010 --> 00:56:14.090 align:middle line:90% he would send 0, 1. 00:56:14.090 --> 00:56:16.610 align:middle line:84% But again, these are encrypted by A, 00:56:16.610 --> 00:56:20.690 align:middle line:84% so B receiving one or the other still 00:56:20.690 --> 00:56:24.930 align:middle line:90% leaves B completely in the dark. 00:56:24.930 --> 00:56:28.750 align:middle line:84% But anyway, B goes along with the algorithm, 00:56:28.750 --> 00:56:32.190 align:middle line:84% and actually then encrypts the encrypted value of A, 00:56:32.190 --> 00:56:34.650 align:middle line:90% so it's like double-encryption. 00:56:34.650 --> 00:56:40.030 align:middle line:84% This is what B receives, and now it's encrypted by B, 00:56:40.030 --> 00:56:45.610 align:middle line:84% and this part finally ends up with code C. 00:56:45.610 --> 00:56:47.980 align:middle line:84% So this is a bit of the MPC part. 00:56:47.980 --> 00:56:52.080 align:middle line:90% 00:56:52.080 --> 00:56:54.960 align:middle line:84% OK, so then what happens in real-time? 00:56:54.960 --> 00:57:01.120 align:middle line:84% Well, some urgent or patient parameter is realized, 00:57:01.120 --> 00:57:05.380 align:middle line:84% agent A is going to send a message about it, 00:57:05.380 --> 00:57:12.920 align:middle line:84% m being that message, the realized value of theta of hA, 00:57:12.920 --> 00:57:18.600 align:middle line:84% or alternatively, lA, encrypts it, and sends it to B. 00:57:18.600 --> 00:57:23.480 align:middle line:84% B now sends something back to A, namely sort 00:57:23.480 --> 00:57:26.720 align:middle line:90% of encrypted null reference. 00:57:26.720 --> 00:57:29.400 align:middle line:90% A encrypts the null reference. 00:57:29.400 --> 00:57:32.160 align:middle line:84% So what happens now is the encrypted value 00:57:32.160 --> 00:57:36.440 align:middle line:84% of A times the encrypted value of-- sorry, B at 0 00:57:36.440 --> 00:57:41.320 align:middle line:84% times the encrypted value of A, and this is the second item 00:57:41.320 --> 00:57:44.750 align:middle line:90% that the code is receiving. 00:57:44.750 --> 00:57:48.150 align:middle line:84% So the code has gotten this and this. 00:57:48.150 --> 00:57:55.950 align:middle line:84% OK, now B sends to A the difference 00:57:55.950 --> 00:58:05.430 align:middle line:84% between A's actual value and the two values that 00:58:05.430 --> 00:58:10.550 align:middle line:90% was sent at date 1 in some-- 00:58:10.550 --> 00:58:13.310 align:middle line:90% sorry, I guess it's step 1-- 00:58:13.310 --> 00:58:14.650 align:middle line:90% in some order. 00:58:14.650 --> 00:58:17.350 align:middle line:90% 00:58:17.350 --> 00:58:26.950 align:middle line:84% So if this were the first message sent at step 1, 00:58:26.950 --> 00:58:32.230 align:middle line:84% then this is the encrypted value of A at m1, that's 00:58:32.230 --> 00:58:37.870 align:middle line:90% what agent a sent to B already. 00:58:37.870 --> 00:58:40.230 align:middle line:90% So B knows the encrypted value. 00:58:40.230 --> 00:58:46.820 align:middle line:84% B also knows the encrypted value here of the actual message 00:58:46.820 --> 00:58:48.540 align:middle line:90% that A is sending. 00:58:48.540 --> 00:58:56.340 align:middle line:84% So the difference here is encrypted, but it's computable. 00:58:56.340 --> 00:59:01.340 align:middle line:84% And then A and B is encrypting that difference 00:59:01.340 --> 00:59:05.380 align:middle line:90% as the first term of a vector. 00:59:05.380 --> 00:59:07.100 align:middle line:84% And the second term of the vector 00:59:07.100 --> 00:59:10.340 align:middle line:84% is the same, except that's the difference 00:59:10.340 --> 00:59:15.700 align:middle line:84% between the actual value and the second message 00:59:15.700 --> 00:59:19.660 align:middle line:90% that was sent at step 1. 00:59:19.660 --> 00:59:27.060 align:middle line:84% So now, this object is coming back to A. A encrypts the pair 00:59:27.060 --> 00:59:31.480 align:middle line:84% and sends it to C. Now no doubt you're completely exhausted. 00:59:31.480 --> 00:59:34.940 align:middle line:90% 00:59:34.940 --> 00:59:40.340 align:middle line:84% So the claim here now is that this level of communication back 00:59:40.340 --> 00:59:43.160 align:middle line:84% and forth between the two parties 00:59:43.160 --> 00:59:46.000 align:middle line:84% reveals nothing to the two parties, 00:59:46.000 --> 00:59:49.640 align:middle line:84% but the code is being armed with enough information 00:59:49.640 --> 00:59:55.960 align:middle line:84% to figure out, effectively, de facto, when to randomize. 00:59:55.960 --> 01:00:02.120 align:middle line:84% To try to provide a little more insight, this step 1 01:00:02.120 --> 01:00:07.280 align:middle line:84% in some order, agent A is encrypting the urgent or patient 01:00:07.280 --> 01:00:10.270 align:middle line:84% parameter value, and you can see the A and delta 01:00:10.270 --> 01:00:13.220 align:middle line:84% z's were messages before in the auction scheme, 01:00:13.220 --> 01:00:16.400 align:middle line:84% now they're claimed values of the-- 01:00:16.400 --> 01:00:19.240 align:middle line:84% and actual values of the actual parameter 01:00:19.240 --> 01:00:21.800 align:middle line:90% clouded up with the noise. 01:00:21.800 --> 01:00:24.800 align:middle line:84% Setting delta equal to 1 for simplicity, 01:00:24.800 --> 01:00:30.880 align:middle line:84% we can see our first example of the encryption being commutative 01:00:30.880 --> 01:00:33.080 align:middle line:84% in the sense of we are able to reverse 01:00:33.080 --> 01:00:40.440 align:middle line:84% the ordering of the encryption from A to B, and then now B 01:00:40.440 --> 01:00:44.470 align:middle line:84% to A. In whatever order it is, we 01:00:44.470 --> 01:00:47.150 align:middle line:84% get the same answer on the right, which 01:00:47.150 --> 01:00:49.350 align:middle line:84% is a bit like the auction scheme, where we're going 01:00:49.350 --> 01:00:54.310 align:middle line:84% to basically add up A times the s's and add up 01:00:54.310 --> 01:00:59.490 align:middle line:90% the errors, leaving the message. 01:00:59.490 --> 01:01:01.890 align:middle line:84% But again, the message is in there, 01:01:01.890 --> 01:01:04.810 align:middle line:84% but it's embedded with all this other encryption, 01:01:04.810 --> 01:01:08.070 align:middle line:90% so B does not no. 01:01:08.070 --> 01:01:09.750 align:middle line:90% Let's see what else. 01:01:09.750 --> 01:01:16.210 align:middle line:84% This is the part where A is encrypting 1, 0 or 0, 1. 01:01:16.210 --> 01:01:21.470 align:middle line:84% 1, 0, for the sake of an example is where the urgent value 01:01:21.470 --> 01:01:22.810 align:middle line:90% was sent first. 01:01:22.810 --> 01:01:27.354 align:middle line:90% 01:01:27.354 --> 01:01:28.930 align:middle line:90% And that's the 1. 01:01:28.930 --> 01:01:34.830 align:middle line:90% And then 0-- so there's a comm-- 01:01:34.830 --> 01:01:38.310 align:middle line:84% effectively a comma here to separate these two elements 01:01:38.310 --> 01:01:44.660 align:middle line:84% where 1, 0 is the key component in each-- 01:01:44.660 --> 01:01:47.820 align:middle line:84% the key part of each one of those components. 01:01:47.820 --> 01:01:54.740 align:middle line:84% But it could have been the other way around where agent A sent 01:01:54.740 --> 01:02:00.580 align:middle line:84% the low value first, and then the high one, and then step 1. 01:02:00.580 --> 01:02:05.460 align:middle line:84% So I guess that brings me to a second thing I want to show you, 01:02:05.460 --> 01:02:10.540 align:middle line:84% which is, we've got all these cases now. 01:02:10.540 --> 01:02:16.220 align:middle line:84% The first has to do with whether that first message, 01:02:16.220 --> 01:02:20.380 align:middle line:84% pre-play message encrypted sent by agent A to B 01:02:20.380 --> 01:02:27.340 align:middle line:84% was the high value, case 1, or case 2, it was the low value. 01:02:27.340 --> 01:02:30.980 align:middle line:84% The second branch is what's going on in the actual mechanism 01:02:30.980 --> 01:02:34.240 align:middle line:84% as it's played out where m is sent, 01:02:34.240 --> 01:02:37.780 align:middle line:84% and it could be the high value or the low value. 01:02:37.780 --> 01:02:43.290 align:middle line:84% So in the event that agent A at step one 01:02:43.290 --> 01:02:47.930 align:middle line:84% sent the high value encrypted and that high value was also 01:02:47.930 --> 01:02:56.225 align:middle line:84% the one realized, then these objects 01:02:56.225 --> 01:02:59.630 align:middle line:84% that were the difference that B was encrypted-- 01:02:59.630 --> 01:03:02.770 align:middle line:84% that B was seeing between the pre-play 01:03:02.770 --> 01:03:09.690 align:middle line:84% and the actual values reduced to this statement, 01:03:09.690 --> 01:03:13.890 align:middle line:84% a pair in the vector encrypt 0, encrypt 1. 01:03:13.890 --> 01:03:19.050 align:middle line:84% Or it could be that it was case 2, case B-- 01:03:19.050 --> 01:03:22.370 align:middle line:84% case 2 is where the low value was encrypted first 01:03:22.370 --> 01:03:24.610 align:middle line:90% and the actual message was low. 01:03:24.610 --> 01:03:31.170 align:middle line:84% So what they have in common is that the ordering was such 01:03:31.170 --> 01:03:35.410 align:middle line:84% that the first encrypted value in the pre-play 01:03:35.410 --> 01:03:39.320 align:middle line:84% is also equal to the actual realized message. 01:03:39.320 --> 01:03:43.320 align:middle line:84% The first and fourth rows here are exactly the same. 01:03:43.320 --> 01:03:47.640 align:middle line:84% So the code is effectively figuring out 01:03:47.640 --> 01:03:53.440 align:middle line:84% whether the actual realized value was sent first or not. 01:03:53.440 --> 01:03:55.680 align:middle line:90% That's a big step forward. 01:03:55.680 --> 01:03:59.960 align:middle line:84% B doesn't know, but the code knows. 01:03:59.960 --> 01:04:03.760 align:middle line:84% And these two values, the second and third row, 01:04:03.760 --> 01:04:10.480 align:middle line:84% are also the same, but that's where the first value was 01:04:10.480 --> 01:04:14.280 align:middle line:84% sent in the pre-play, and the actual realized value 01:04:14.280 --> 01:04:17.120 align:middle line:84% was the second one, so the ordering is the other way 01:04:17.120 --> 01:04:18.000 align:middle line:90% around. 01:04:18.000 --> 01:04:20.560 align:middle line:90% So the code knows the ordering. 01:04:20.560 --> 01:04:21.920 align:middle line:90% Not the message yet. 01:04:21.920 --> 01:04:25.000 align:middle line:90% Just knows the ordering. 01:04:25.000 --> 01:04:29.000 align:middle line:84% So here's a bit of the commutative and distributive 01:04:29.000 --> 01:04:30.160 align:middle line:90% properties. 01:04:30.160 --> 01:04:35.460 align:middle line:84% Basically, the commutative thing is you're exchanging the order-- 01:04:35.460 --> 01:04:37.670 align:middle line:90% I guess I said this before-- 01:04:37.670 --> 01:04:43.390 align:middle line:84% of the encryption operator from B, and then A, to A, and then B. 01:04:43.390 --> 01:04:49.110 align:middle line:84% And here is the distributive thing where you're basically 01:04:49.110 --> 01:04:52.790 align:middle line:84% taking this encrypted value of the pair, 01:04:52.790 --> 01:04:57.670 align:middle line:84% and also, it's the same thing as the encrypted value of each 01:04:57.670 --> 01:05:00.870 align:middle line:90% of the terms individually. 01:05:00.870 --> 01:05:03.150 align:middle line:90% And then this we'll skip. 01:05:03.150 --> 01:05:06.070 align:middle line:84% That has to do with the codes remembering 01:05:06.070 --> 01:05:09.470 align:middle line:84% some of the key things, having to do with the ordering. 01:05:09.470 --> 01:05:11.150 align:middle line:90% This we'll skip. 01:05:11.150 --> 01:05:14.070 align:middle line:90% And finally, we have this line. 01:05:14.070 --> 01:05:16.350 align:middle line:84% And I hope you're happy that I'm sparing 01:05:16.350 --> 01:05:19.270 align:middle line:84% you all the algebra in between because it's already just too 01:05:19.270 --> 01:05:20.590 align:middle line:90% much. 01:05:20.590 --> 01:05:22.870 align:middle line:84% I'm just trying to give you some of the math that's 01:05:22.870 --> 01:05:26.050 align:middle line:84% happening along the way by highlighting it, 01:05:26.050 --> 01:05:29.030 align:middle line:84% although I've kept the slides as they were. 01:05:29.030 --> 01:05:34.860 align:middle line:84% This is encrypt B, encrypt A times 1 of 1 times 01:05:34.860 --> 01:05:40.420 align:middle line:84% the randomized amount, but due to the properties of fully 01:05:40.420 --> 01:05:43.740 align:middle line:84% homomorphic encryption, we could have put a 1 here 01:05:43.740 --> 01:05:44.960 align:middle line:90% and then encrypted it. 01:05:44.960 --> 01:05:49.420 align:middle line:84% The ordering doesn't matter, so that's exactly what we did. 01:05:49.420 --> 01:05:51.700 align:middle line:84% Encrypt B is the same, encrypt A. 01:05:51.700 --> 01:05:55.800 align:middle line:84% But now, not of 1 times the randomized amount, 01:05:55.800 --> 01:05:59.620 align:middle line:84% but encrypted of A 1 times the randomized amount. 01:05:59.620 --> 01:06:06.580 align:middle line:84% And that brings the 0 out here in front, and 0 times 0-- 01:06:06.580 --> 01:06:09.780 align:middle line:84% 0 times something is always 0, so we end up 01:06:09.780 --> 01:06:14.280 align:middle line:84% with a term that only involves the randomized amount. 01:06:14.280 --> 01:06:15.840 align:middle line:84% And it could have gone the other way, 01:06:15.840 --> 01:06:18.680 align:middle line:84% and we get the low liquidity amount. 01:06:18.680 --> 01:06:20.900 align:middle line:84% So that's where the miracle is kind of happening, 01:06:20.900 --> 01:06:23.680 align:middle line:84% where the rabbit's coming out of the hat, 01:06:23.680 --> 01:06:27.140 align:middle line:84% and that the code is actually able to not only get 01:06:27.140 --> 01:06:30.600 align:middle line:84% the deterministic allocation to the agents 01:06:30.600 --> 01:06:35.890 align:middle line:84% when agent A said he was not urgent, but also randomized-- 01:06:35.890 --> 01:06:38.090 align:middle line:84% you have a pseudorandom number generator 01:06:38.090 --> 01:06:41.050 align:middle line:90% and the code is accessing that. 01:06:41.050 --> 01:06:41.710 align:middle line:90% All right. 01:06:41.710 --> 01:06:47.690 align:middle line:84% So these two slides basically try to live up to my claim 01:06:47.690 --> 01:06:50.290 align:middle line:84% that I'm suffering from not really having time 01:06:50.290 --> 01:06:52.770 align:middle line:90% to go into it. 01:06:52.770 --> 01:06:54.390 align:middle line:90% We've got these messages. 01:06:54.390 --> 01:06:57.810 align:middle line:84% We generalize it from more than 2 to, say, 3, 01:06:57.810 --> 01:07:00.090 align:middle line:90% so now it's low, medium, high. 01:07:00.090 --> 01:07:05.330 align:middle line:84% And we have to decide what messages are being sent. 01:07:05.330 --> 01:07:08.530 align:middle line:84% You can do it message by message by message, 01:07:08.530 --> 01:07:12.010 align:middle line:84% or you can actually start creating 01:07:12.010 --> 01:07:17.610 align:middle line:84% more than one pseudo-agent that works on these messages 01:07:17.610 --> 01:07:20.050 align:middle line:90% pairwise. 01:07:20.050 --> 01:07:22.750 align:middle line:84% But in a particular order, c1 is taking low, 01:07:22.750 --> 01:07:28.630 align:middle line:84% medium, c2 is taking medium, high, c3 is taking low and high. 01:07:28.630 --> 01:07:31.570 align:middle line:84% So it's a bit different grouping than we 01:07:31.570 --> 01:07:34.620 align:middle line:90% had in the earlier application. 01:07:34.620 --> 01:07:35.120 align:middle line:90% OK. 01:07:35.120 --> 01:07:39.960 align:middle line:84% The last application is order book matching. 01:07:39.960 --> 01:07:42.980 align:middle line:84% So here, the idea is there are two dealers. 01:07:42.980 --> 01:07:46.400 align:middle line:84% This could be repo, it could be something else. 01:07:46.400 --> 01:07:50.680 align:middle line:84% Any kind of exchange, the guy with the treasuries 01:07:50.680 --> 01:07:54.120 align:middle line:84% is willing to exchange them for money 01:07:54.120 --> 01:07:56.480 align:middle line:84% and is submitting these kinds of, I don't know, 01:07:56.480 --> 01:07:59.240 align:middle line:90% almost like limit orders. 01:07:59.240 --> 01:08:03.660 align:middle line:84% 1 T for 1 M, for 2 T for 2 M. Pointwise orders, 01:08:03.660 --> 01:08:06.000 align:middle line:90% I probably should say, instead. 01:08:06.000 --> 01:08:07.400 align:middle line:90% 3 for 4. 01:08:07.400 --> 01:08:11.720 align:middle line:84% What's the maximum treasuries that could happen depending 01:08:11.720 --> 01:08:16.180 align:middle line:84% on what gets picked by the market matching is 3, 01:08:16.180 --> 01:08:19.200 align:middle line:84% so 3 has to go in escrow, and likewise on this side, 01:08:19.200 --> 01:08:25.080 align:middle line:84% we've got the guy with the money who's 01:08:25.080 --> 01:08:29.359 align:middle line:84% potentially willing to take the treasuries, and in this order, 01:08:29.359 --> 01:08:37.990 align:middle line:84% the maximum vulnerability is 3, so 3 reserves are put in escrow. 01:08:37.990 --> 01:08:43.990 align:middle line:84% And then the code finds the common line here with this 2 01:08:43.990 --> 01:08:48.970 align:middle line:90% for 2 and matches it. 01:08:48.970 --> 01:08:51.590 align:middle line:84% And so that's the way the trades happen. 01:08:51.590 --> 01:08:55.710 align:middle line:84% And without burdening you with the notation, 01:08:55.710 --> 01:09:00.590 align:middle line:90% we can encrypt those messages. 01:09:00.590 --> 01:09:07.830 align:middle line:84% So each of these trades of T for M or M for T is encrypted. 01:09:07.830 --> 01:09:11.310 align:middle line:84% The code knows how to act on these encrypted messages 01:09:11.310 --> 01:09:15.830 align:middle line:84% by doing a comparison operator to find the match. 01:09:15.830 --> 01:09:21.950 align:middle line:84% So the agents don't have to reveal-- 01:09:21.950 --> 01:09:26.830 align:middle line:84% worry about revealing their orders, which 01:09:26.830 --> 01:09:29.810 align:middle line:84% could lead to front-running and so on and so forth 01:09:29.810 --> 01:09:33.700 align:middle line:90% if they were revealed. 01:09:33.700 --> 01:09:36.920 align:middle line:84% And so this is matching with the smart contract, et cetera, 01:09:36.920 --> 01:09:39.060 align:middle line:90% et cetera. 01:09:39.060 --> 01:09:41.710 align:middle line:84% I didn't show you the notation for the encryption, 01:09:41.710 --> 01:09:43.460 align:middle line:84% but I'm sure at this point you're probably 01:09:43.460 --> 01:09:45.300 align:middle line:90% willing to take my word for it. 01:09:45.300 --> 01:09:51.580 align:middle line:84% The other thing just to say is that with these cryptographers 01:09:51.580 --> 01:09:55.820 align:middle line:84% here at MIT and also at the company Visa, 01:09:55.820 --> 01:10:03.900 align:middle line:84% we're working on the ability to run this kind of encryption 01:10:03.900 --> 01:10:04.960 align:middle line:90% on the blockchain. 01:10:04.960 --> 01:10:07.080 align:middle line:90% That is still a limitation. 01:10:07.080 --> 01:10:08.900 align:middle line:84% All the examples I've shown you are 01:10:08.900 --> 01:10:13.940 align:middle line:84% like tier 1, tier 2, layer 1, layer 2, off and on chain. 01:10:13.940 --> 01:10:17.900 align:middle line:84% So the encryption can happen without running into validation 01:10:17.900 --> 01:10:18.960 align:middle line:90% issues and so on. 01:10:18.960 --> 01:10:22.800 align:middle line:84% But if you're on the full blown blockchain with the validation, 01:10:22.800 --> 01:10:26.520 align:middle line:84% then you have to use MPC in clever ways. 01:10:26.520 --> 01:10:29.590 align:middle line:84% There are two applications that do it. 01:10:29.590 --> 01:10:33.730 align:middle line:84% Zama and Sunscreen in particular claim to allow encryption 01:10:33.730 --> 01:10:35.290 align:middle line:84% on the blockchain, and this paper 01:10:35.290 --> 01:10:38.050 align:middle line:84% is evaluating just how effective they 01:10:38.050 --> 01:10:40.790 align:middle line:84% are in terms of the number of multiplication 01:10:40.790 --> 01:10:45.730 align:middle line:84% operations, addition operations, and comparison operations. 01:10:45.730 --> 01:10:48.130 align:middle line:84% So it's something of a mixed picture 01:10:48.130 --> 01:10:52.190 align:middle line:84% that certainly those companies have made real advances, 01:10:52.190 --> 01:10:56.330 align:middle line:84% and I'm pretty confident that in not too 01:10:56.330 --> 01:10:58.130 align:middle line:84% much time in the near-future, we will 01:10:58.130 --> 01:11:02.010 align:middle line:84% have fully operational encryption schemes running 01:11:02.010 --> 01:11:05.510 align:middle line:84% on the blockchain, but we're not quite there yet. 01:11:05.510 --> 01:11:08.650 align:middle line:84% And it's a big problem in practice for Brazil, 01:11:08.650 --> 01:11:15.390 align:middle line:84% for example, with its design of Its wholesale CBDC, 01:11:15.390 --> 01:11:18.290 align:middle line:84% so these things are really needed. 01:11:18.290 --> 01:11:21.530 align:middle line:90% OK, so that's all for today. 01:11:21.530 --> 01:11:23.720 align:middle line:90% Thank you very much. 01:11:23.720 --> 01:11:28.000 align:middle line:90%