WEBVTT 00:00:00.000 --> 00:00:01.931 align:middle line:90% [SQUEAKING] 00:00:01.931 --> 00:00:03.362 align:middle line:90% [RUSTLING] 00:00:03.362 --> 00:00:05.270 align:middle line:90% [CLICKING] 00:00:05.270 --> 00:00:10.760 align:middle line:90% 00:00:10.760 --> 00:00:16.360 align:middle line:84% ROBERT M. TOWNSEND: So let me just say that, shockingly, we 00:00:16.360 --> 00:00:20.540 align:middle line:84% have arrived at lecture 8, which means 00:00:20.540 --> 00:00:25.720 align:middle line:84% we're well more than halfway done with the lectures. 00:00:25.720 --> 00:00:30.200 align:middle line:84% So today is continuing the theme of trying 00:00:30.200 --> 00:00:37.160 align:middle line:84% to bring computer science and economics onto the same page. 00:00:37.160 --> 00:00:40.580 align:middle line:84% And the juxtaposition is everywhere today, 00:00:40.580 --> 00:00:43.800 align:middle line:84% so "Mechanism Design and Incentives" 00:00:43.800 --> 00:00:50.680 align:middle line:84% has to do with the way economists think about trust 00:00:50.680 --> 00:00:56.640 align:middle line:84% versus "Protocols and Notions of Trust" in computer science. 00:00:56.640 --> 00:00:59.590 align:middle line:84% The longer title is "Private Information, 00:00:59.590 --> 00:01:02.750 align:middle line:84% Incentives to Report and Take Actions"-- 00:01:02.750 --> 00:01:08.070 align:middle line:84% as in mechanism design versus illustrative Byzantine Generals 00:01:08.070 --> 00:01:15.030 align:middle line:84% problem that utilizes a different notion of trust 00:01:15.030 --> 00:01:18.030 align:middle line:84% to emphasize the difference between economics and computer 00:01:18.030 --> 00:01:21.490 align:middle line:84% science in the way we think about algorithms, 00:01:21.490 --> 00:01:25.630 align:middle line:84% which is not to say there isn't a middle ground. 00:01:25.630 --> 00:01:30.090 align:middle line:84% I'm trying to avoid a bipolar view, 00:01:30.090 --> 00:01:33.670 align:middle line:84% but that is the way the lectures are laid out. 00:01:33.670 --> 00:01:40.150 align:middle line:84% So the outlined is information constrained allocations. 00:01:40.150 --> 00:01:42.650 align:middle line:84% And I'll do it through an example, 00:01:42.650 --> 00:01:46.190 align:middle line:84% Although the principles generalize. 00:01:46.190 --> 00:01:48.670 align:middle line:84% And we'll think about implementing 00:01:48.670 --> 00:01:53.490 align:middle line:84% this without a planner in the jargon of economics, 00:01:53.490 --> 00:02:00.390 align:middle line:84% rather, using the tools of computer science. 00:02:00.390 --> 00:02:05.910 align:middle line:84% So that helps mitigate the bipolar view of economics 00:02:05.910 --> 00:02:07.530 align:middle line:90% versus computer science. 00:02:07.530 --> 00:02:10.270 align:middle line:84% We will utilize the tools of computer science 00:02:10.270 --> 00:02:14.870 align:middle line:84% very heavily within the mechanism design problem. 00:02:14.870 --> 00:02:18.550 align:middle line:84% And then we'll go on to talk about algorithms for validation 00:02:18.550 --> 00:02:24.150 align:middle line:84% and so on and readdress this difference 00:02:24.150 --> 00:02:28.470 align:middle line:84% by an illustrative paper of Steve Morris 00:02:28.470 --> 00:02:34.830 align:middle line:84% and Hyun Shin on the Byzantine generals problem. 00:02:34.830 --> 00:02:37.190 align:middle line:90% So first half-- 00:02:37.190 --> 00:02:40.830 align:middle line:84% Information Constrained Allocations vis a vis 00:02:40.830 --> 00:02:43.350 align:middle line:90% this insurance example-- 00:02:43.350 --> 00:02:45.390 align:middle line:84% how to implement without a planner using 00:02:45.390 --> 00:02:49.510 align:middle line:90% the tools of computer science. 00:02:49.510 --> 00:02:59.780 align:middle line:84% So to be specific, I will talk about an agrarian economy. 00:02:59.780 --> 00:03:03.860 align:middle line:84% But that said, we can think about this notation 00:03:03.860 --> 00:03:06.900 align:middle line:84% for the same model as applying much more generally 00:03:06.900 --> 00:03:09.980 align:middle line:90% to today's financial markets. 00:03:09.980 --> 00:03:12.260 align:middle line:90% So it's a pure exchange economy. 00:03:12.260 --> 00:03:14.740 align:middle line:90% There's only one period for now. 00:03:14.740 --> 00:03:18.620 align:middle line:84% There's two agents, labeled 1 and 2, 00:03:18.620 --> 00:03:22.140 align:middle line:84% and a K-dimensional vector of endowments. 00:03:22.140 --> 00:03:27.220 align:middle line:84% The endowment of agent 1, the villa, so to speak, 00:03:27.220 --> 00:03:29.980 align:middle line:90% is seen by that agent alone. 00:03:29.980 --> 00:03:32.660 align:middle line:84% So shocks are private to the agent. 00:03:32.660 --> 00:03:35.660 align:middle line:84% And we can parameterize this endowment, which 00:03:35.660 --> 00:03:39.660 align:middle line:84% is e1 for agent 1, and e is endowment 00:03:39.660 --> 00:03:43.380 align:middle line:84% as a function of epsilon by a simpler notation, where 00:03:43.380 --> 00:03:47.220 align:middle line:84% theta is this parameter theta, taking realizations 00:03:47.220 --> 00:03:52.940 align:middle line:84% in some larger set with probabilities p of theta. 00:03:52.940 --> 00:03:54.660 align:middle line:90% So that's for the villa. 00:03:54.660 --> 00:04:00.180 align:middle line:84% And agent 2 is like a central monastery. 00:04:00.180 --> 00:04:03.420 align:middle line:84% Agent 2's endowment for simplicity is public. 00:04:03.420 --> 00:04:05.880 align:middle line:84% For that matter, agent 2 is going to be risk-neutral. 00:04:05.880 --> 00:04:08.580 align:middle line:84% Agent 1 is going to be risk-averse. 00:04:08.580 --> 00:04:12.900 align:middle line:84% And again, we have this K-dimensional vector, 00:04:12.900 --> 00:04:16.300 align:middle line:84% publicly observed vector of, quote, "endowments" 00:04:16.300 --> 00:04:19.040 align:middle line:90% for the monastery. 00:04:19.040 --> 00:04:22.180 align:middle line:90% 00:04:22.180 --> 00:04:26.540 align:middle line:84% So these two agents are going to agree to some rule 00:04:26.540 --> 00:04:30.460 align:middle line:90% for allocating resources-- 00:04:30.460 --> 00:04:36.940 align:middle line:84% some rule f, function f, mapping a message sent from agent one 00:04:36.940 --> 00:04:42.900 align:middle line:84% to agent 2 into positive and negative transfers of each 00:04:42.900 --> 00:04:45.900 align:middle line:84% of the items in this K-dimensional vector. 00:04:45.900 --> 00:04:52.530 align:middle line:84% It will be in the notation as if the villa is paying a tax, as 00:04:52.530 --> 00:04:55.210 align:middle line:84% if the transfer, if positive, is going 00:04:55.210 --> 00:04:56.990 align:middle line:90% from the via to the monastery. 00:04:56.990 --> 00:05:00.070 align:middle line:90% But transfers can be negative. 00:05:00.070 --> 00:05:02.770 align:middle line:84% This is, after all, an insurance example. 00:05:02.770 --> 00:05:05.410 align:middle line:84% The agent has a random endowment, 00:05:05.410 --> 00:05:10.570 align:middle line:84% is risk-averse, and the monastery agent 2 00:05:10.570 --> 00:05:15.270 align:middle line:84% is willing to undertake that insurance. 00:05:15.270 --> 00:05:17.770 align:middle line:84% But the problem will be how to mitigate 00:05:17.770 --> 00:05:23.370 align:middle line:84% the damage caused from the private information if you can. 00:05:23.370 --> 00:05:25.770 align:middle line:84% So they agree to a resource allocation 00:05:25.770 --> 00:05:29.650 align:middle line:90% scheme, which works as follows. 00:05:29.650 --> 00:05:33.730 align:middle line:84% Villa 1, agent 1 waits to see the output vector parameter 00:05:33.730 --> 00:05:40.090 align:middle line:84% theta, then sends a message m to the monastery, 00:05:40.090 --> 00:05:43.050 align:middle line:84% and the allocation would be f of m. 00:05:43.050 --> 00:05:46.890 align:middle line:84% Let's focus on the decision problem of the agent 00:05:46.890 --> 00:05:49.090 align:middle line:90% about what message to send. 00:05:49.090 --> 00:05:54.650 align:middle line:84% So the agent knows theta by now prior to sending the message 00:05:54.650 --> 00:05:59.930 align:middle line:84% and chooses some message m so that the transfer 00:05:59.930 --> 00:06:02.770 align:middle line:84% from the agent to the monastery would be f of m. 00:06:02.770 --> 00:06:08.170 align:middle line:84% So that just subtracts off of output. 00:06:08.170 --> 00:06:12.490 align:middle line:90% So what message to send? 00:06:12.490 --> 00:06:16.850 align:middle line:84% Well, let's suppose there is a unique maximizing message, 00:06:16.850 --> 00:06:19.130 align:middle line:90% and let's put a star on it. 00:06:19.130 --> 00:06:22.890 align:middle line:84% So m star of theta is the actual optimized message 00:06:22.890 --> 00:06:26.330 align:middle line:84% the agent would send given the set of messages 00:06:26.330 --> 00:06:30.650 align:middle line:84% which are possible in the allocation rule f. 00:06:30.650 --> 00:06:35.650 align:middle line:84% So this statement, 83, is a simple statement of maximization 00:06:35.650 --> 00:06:41.290 align:middle line:84% that the chosen message is at least as great in utility 00:06:41.290 --> 00:06:45.930 align:middle line:84% as choosing any other arbitrary message. 00:06:45.930 --> 00:06:47.810 align:middle line:84% In fact, if it were unique, then this 00:06:47.810 --> 00:06:53.520 align:middle line:84% is a strict inequality for any message other than m star-- 00:06:53.520 --> 00:07:00.080 align:middle line:84% so just a statement of the maximum. 00:07:00.080 --> 00:07:04.680 align:middle line:84% And in particular, if we took m on the right-hand side 00:07:04.680 --> 00:07:08.000 align:middle line:84% to be a particular message, any message will do. 00:07:08.000 --> 00:07:10.040 align:middle line:90% 83 still holds. 00:07:10.040 --> 00:07:14.280 align:middle line:84% But let's consider m to be what the agent would 00:07:14.280 --> 00:07:20.080 align:middle line:84% have sent in the counterfactual situation where the theta were 00:07:20.080 --> 00:07:29.320 align:middle line:84% theta tilde rather other than what it really is, namely theta. 00:07:29.320 --> 00:07:36.520 align:middle line:84% So we just substitute this chosen alternative message 00:07:36.520 --> 00:07:40.900 align:middle line:84% m equal m star of theta into equation 83. 00:07:40.900 --> 00:07:43.420 align:middle line:84% And we end up with this equality. 00:07:43.420 --> 00:07:47.180 align:middle line:84% So that inequality is a simple substitution. 00:07:47.180 --> 00:07:51.600 align:middle line:90% 00:07:51.600 --> 00:07:53.700 align:middle line:90% So now we just do some-- 00:07:53.700 --> 00:07:57.400 align:middle line:90% 00:07:57.400 --> 00:07:59.500 align:middle line:84% this is a very broad class of games. 00:07:59.500 --> 00:08:02.600 align:middle line:84% I haven't told you what the set of messages looks like. 00:08:02.600 --> 00:08:09.120 align:middle line:84% I haven't told you what f's, how they're chosen from some domain. 00:08:09.120 --> 00:08:12.900 align:middle line:84% It's a very broad mechanism design problem. 00:08:12.900 --> 00:08:15.760 align:middle line:84% But we can come up with a simpler scheme. 00:08:15.760 --> 00:08:21.040 align:middle line:84% And now I'm about to describe this alternative scheme. 00:08:21.040 --> 00:08:23.560 align:middle line:84% And in it, the message space is now 00:08:23.560 --> 00:08:28.440 align:middle line:84% restricted to the set of possible values of theta. 00:08:28.440 --> 00:08:30.560 align:middle line:84% That doesn't mean that we're going to require 00:08:30.560 --> 00:08:33.000 align:middle line:90% the agent tell the truth. 00:08:33.000 --> 00:08:35.000 align:middle line:90% He just outputs, high. 00:08:35.000 --> 00:08:38.580 align:middle line:84% It could have been low or vice versa. 00:08:38.580 --> 00:08:40.559 align:middle line:90% Lying is perfectly possible. 00:08:40.559 --> 00:08:45.020 align:middle line:84% But he can only announce possible values of theta. 00:08:45.020 --> 00:08:48.790 align:middle line:84% And it's common knowledge what the set of realizations of theta 00:08:48.790 --> 00:08:49.750 align:middle line:90% is. 00:08:49.750 --> 00:08:52.110 align:middle line:90% So that's enforceable. 00:08:52.110 --> 00:08:57.070 align:middle line:90% And we do something with the f. 00:08:57.070 --> 00:09:01.310 align:middle line:84% Namely, we invent a new allocation rule g. 00:09:01.310 --> 00:09:08.870 align:middle line:84% and g logically just maps these announced messages about theta 00:09:08.870 --> 00:09:12.230 align:middle line:90% into an allocation. 00:09:12.230 --> 00:09:18.450 align:middle line:84% So here, we're doing it for this maximizing message 00:09:18.450 --> 00:09:21.790 align:middle line:84% the agent would have sent if his parameter were 00:09:21.790 --> 00:09:28.870 align:middle line:84% theta tilde, which is really a composite function over two 00:09:28.870 --> 00:09:29.370 align:middle line:90% things. 00:09:29.370 --> 00:09:31.510 align:middle line:84% It's over f, the allocation rule, 00:09:31.510 --> 00:09:35.110 align:middle line:84% and over the optimized maximized strategy 00:09:35.110 --> 00:09:38.590 align:middle line:84% the agent would employ in the original game. 00:09:38.590 --> 00:09:41.990 align:middle line:90% And we collapse that down to g. 00:09:41.990 --> 00:09:46.420 align:middle line:84% So now the agent says, I know what 00:09:46.420 --> 00:09:50.200 align:middle line:84% I would have done if I had a certain value theta tilde. 00:09:50.200 --> 00:09:52.400 align:middle line:84% So I'll just let the computer do that for me. 00:09:52.400 --> 00:09:57.340 align:middle line:84% I'll just load in my maximizing strategy and just say, 00:09:57.340 --> 00:09:59.180 align:middle line:90% here's my theta. 00:09:59.180 --> 00:10:02.580 align:middle line:84% Then the m star of theta behind the scenes would be generated, 00:10:02.580 --> 00:10:04.760 align:middle line:84% and it would be mapped under f to g. 00:10:04.760 --> 00:10:08.900 align:middle line:84% We'll just now adopt g as, in the end, 00:10:08.900 --> 00:10:12.460 align:middle line:84% the allocation rule, this alternative allocation 00:10:12.460 --> 00:10:17.700 align:middle line:90% rule in this new mechanism. 00:10:17.700 --> 00:10:22.180 align:middle line:84% Well, again, if you start doing this substitution, 00:10:22.180 --> 00:10:25.440 align:middle line:90% this is now g of theta. 00:10:25.440 --> 00:10:28.300 align:middle line:90% This is g of theta tilde. 00:10:28.300 --> 00:10:32.180 align:middle line:90% So we have this new equation 85. 00:10:32.180 --> 00:10:37.060 align:middle line:84% And so 85 just simply says, if the parameter value were theta 00:10:37.060 --> 00:10:41.740 align:middle line:84% and you said so, that would dominate weekly in utility terms 00:10:41.740 --> 00:10:46.820 align:middle line:84% having theta and announcing something else, theta tilde. 00:10:46.820 --> 00:10:51.220 align:middle line:84% So this looks like a truth-telling constraint. 00:10:51.220 --> 00:10:53.540 align:middle line:84% But that's really very treacherous way 00:10:53.540 --> 00:10:57.400 align:middle line:84% to put it because we're not requiring truth telling. 00:10:57.400 --> 00:11:04.020 align:middle line:84% We're inducing truth telling without loss of generality 00:11:04.020 --> 00:11:07.380 align:middle line:84% as a way to represent the outcome in a game 00:11:07.380 --> 00:11:09.320 align:middle line:84% where there's private information. 00:11:09.320 --> 00:11:14.340 align:middle line:90% 00:11:14.340 --> 00:11:21.740 align:middle line:84% And, of course, if telling the truth is what the agent does, 00:11:21.740 --> 00:11:24.240 align:middle line:84% then the allocation will be g of theta, 00:11:24.240 --> 00:11:26.260 align:middle line:84% which is exactly what would have happened 00:11:26.260 --> 00:11:29.620 align:middle line:84% before under the old allocation rule f 00:11:29.620 --> 00:11:33.100 align:middle line:84% with the optimizing behavior m star. 00:11:33.100 --> 00:11:37.180 align:middle line:84% So we're going to achieve exactly the same outcomes 00:11:37.180 --> 00:11:42.530 align:middle line:84% in this general game with f and capital M as we achieve now. 00:11:42.530 --> 00:11:46.690 align:middle line:84% The thing is we know how to search for optimal mechanisms 00:11:46.690 --> 00:11:50.770 align:middle line:84% now because all we need to do to capture the private information 00:11:50.770 --> 00:11:55.810 align:middle line:84% is impose, without loss of generality, this constraint 85. 00:11:55.810 --> 00:12:00.570 align:middle line:90% 00:12:00.570 --> 00:12:05.410 align:middle line:84% So to find the optimized allocation rule, 00:12:05.410 --> 00:12:07.310 align:middle line:90% we do the usual thing. 00:12:07.310 --> 00:12:11.930 align:middle line:84% We're going to maximize a lambda-weighted sum of the ex 00:12:11.930 --> 00:12:17.650 align:middle line:84% ante expected utilities of the agents subject 00:12:17.650 --> 00:12:19.570 align:middle line:84% not just to the resource constraint, 00:12:19.570 --> 00:12:23.970 align:middle line:84% but to this incentive constraint. 00:12:23.970 --> 00:12:27.050 align:middle line:90% So this is lambda 1 for agent 1. 00:12:27.050 --> 00:12:32.650 align:middle line:84% It's ex-ante, so we're taking expectations over theta 00:12:32.650 --> 00:12:35.530 align:middle line:84% with the associated probabilities. 00:12:35.530 --> 00:12:42.390 align:middle line:84% Again, by our normalization, what agent 1 gives up, 00:12:42.390 --> 00:12:43.830 align:middle line:90% agent 2 gets. 00:12:43.830 --> 00:12:46.610 align:middle line:90% 00:12:46.610 --> 00:12:49.150 align:middle line:84% Well, again, it's easy to lose sight of it. 00:12:49.150 --> 00:12:51.330 align:middle line:90% These could be vectors. 00:12:51.330 --> 00:12:54.850 align:middle line:90% And we've already done 87. 00:12:54.850 --> 00:12:58.610 align:middle line:84% So there are various possible ways to implement this. 00:12:58.610 --> 00:13:01.390 align:middle line:84% You can think of the agent as sending a message. 00:13:01.390 --> 00:13:04.490 align:middle line:84% You can think of them agreeing ex-ante to a list 00:13:04.490 --> 00:13:08.570 align:middle line:84% of possible transfers that solve this problem for each 00:13:08.570 --> 00:13:10.010 align:middle line:90% and every theta. 00:13:10.010 --> 00:13:14.610 align:middle line:84% And then the guy just, here it is. 00:13:14.610 --> 00:13:19.970 align:middle line:84% Here's what I'm transferring today because it's 1 to 1 00:13:19.970 --> 00:13:22.890 align:middle line:90% from the theta to the transfers. 00:13:22.890 --> 00:13:26.010 align:middle line:84% Now, this is where I go back and forth. 00:13:26.010 --> 00:13:28.810 align:middle line:84% If there were only one good, this constraint 00:13:28.810 --> 00:13:32.170 align:middle line:84% could be pretty damaging because there's only one period 00:13:32.170 --> 00:13:33.690 align:middle line:90% and one good. 00:13:33.690 --> 00:13:36.290 align:middle line:90% More is preferred to less. 00:13:36.290 --> 00:13:39.400 align:middle line:84% So you can see this would say, well, g of theta is less than 00:13:39.400 --> 00:13:41.400 align:middle line:90% or equal to g of theta tilde. 00:13:41.400 --> 00:13:45.600 align:middle line:84% But that's true for any theta-theta tilde combination. 00:13:45.600 --> 00:13:48.180 align:middle line:84% So effectively, g must be a constant. 00:13:48.180 --> 00:13:51.040 align:middle line:90% It cannot depend on theta. 00:13:51.040 --> 00:13:54.280 align:middle line:84% And if you're trying to make both better off, 00:13:54.280 --> 00:13:58.640 align:middle line:90% you'll be reduced to autarky. 00:13:58.640 --> 00:14:04.100 align:middle line:84% Now, with more than one good, there's a trade-off among goods. 00:14:04.100 --> 00:14:07.240 align:middle line:84% So this doesn't necessarily reduce to autarky. 00:14:07.240 --> 00:14:11.240 align:middle line:84% Another way to potentially enhance 00:14:11.240 --> 00:14:14.320 align:middle line:84% the set of possible allocations is 00:14:14.320 --> 00:14:17.240 align:middle line:90% to start considering randomness. 00:14:17.240 --> 00:14:21.520 align:middle line:84% And if there's differential risk aversion, 00:14:21.520 --> 00:14:27.440 align:middle line:84% depending on your theta, there's a trade-off between high means 00:14:27.440 --> 00:14:29.300 align:middle line:90% and high variance. 00:14:29.300 --> 00:14:33.160 align:middle line:84% And you can keep the agent away from saying something 00:14:33.160 --> 00:14:38.480 align:middle line:84% under which he would get a transfer on average because it's 00:14:38.480 --> 00:14:40.620 align:middle line:84% also associated with a lot of risk. 00:14:40.620 --> 00:14:47.360 align:middle line:90% 00:14:47.360 --> 00:14:51.180 align:middle line:84% So in general, we'll revert to these lotteries. 00:14:51.180 --> 00:14:54.020 align:middle line:84% Instead of saying, you say theta, and you get a transfer, 00:14:54.020 --> 00:14:56.480 align:middle line:84% it's going to be you say theta, and you 00:14:56.480 --> 00:15:01.080 align:middle line:84% get a transfer with a certain probability pi, 00:15:01.080 --> 00:15:03.840 align:middle line:90% and tau is the transfer. 00:15:03.840 --> 00:15:11.880 align:middle line:84% We take this program 6 and convert it to program 7. 00:15:11.880 --> 00:15:14.120 align:middle line:90% Same thing, essentially. 00:15:14.120 --> 00:15:17.760 align:middle line:84% Maximize weighted sums of utilities. 00:15:17.760 --> 00:15:21.320 align:middle line:84% But now, for theta, we have this lottery index 00:15:21.320 --> 00:15:23.100 align:middle line:90% by theta, pi tau of theta. 00:15:23.100 --> 00:15:27.600 align:middle line:84% And we're summing over, say, a finite, discrete large number 00:15:27.600 --> 00:15:33.270 align:middle line:90% of taus on both sides. 00:15:33.270 --> 00:15:34.610 align:middle line:90% This is give up. 00:15:34.610 --> 00:15:36.030 align:middle line:90% This is get. 00:15:36.030 --> 00:15:40.550 align:middle line:84% This is the new version of the so-called truth-telling 00:15:40.550 --> 00:15:41.210 align:middle line:90% constraint. 00:15:41.210 --> 00:15:43.690 align:middle line:90% Now, I haven't rederived it. 00:15:43.690 --> 00:15:48.110 align:middle line:84% But intuitively, it's not that hard to end up 00:15:48.110 --> 00:15:51.350 align:middle line:84% with this as the logical consequence 00:15:51.350 --> 00:15:55.510 align:middle line:84% of private information when the mechanisms are randomizing 00:15:55.510 --> 00:15:58.130 align:middle line:90% over outcomes. 00:15:58.130 --> 00:16:01.230 align:middle line:84% In my head, when I'm proofreading or writing, 00:16:01.230 --> 00:16:07.030 align:middle line:84% I always go through this exercise of, what 00:16:07.030 --> 00:16:09.110 align:middle line:90% is the actual parameter value? 00:16:09.110 --> 00:16:11.730 align:middle line:90% And what is the counterfactual? 00:16:11.730 --> 00:16:14.950 align:middle line:84% So in this case, theta is the real value. 00:16:14.950 --> 00:16:16.910 align:middle line:90% You say theta. 00:16:16.910 --> 00:16:19.350 align:middle line:90% Theta remains the true value. 00:16:19.350 --> 00:16:21.850 align:middle line:90% But you could say theta tilde. 00:16:21.850 --> 00:16:24.525 align:middle line:90% 00:16:24.525 --> 00:16:25.650 align:middle line:90% STUDENT: I missed the step. 00:16:25.650 --> 00:16:30.170 align:middle line:84% Why did we move to a random mechanism from before? 00:16:30.170 --> 00:16:32.420 align:middle line:84% ROBERT M. TOWNSEND: Well, there's a couple of reasons. 00:16:32.420 --> 00:16:36.660 align:middle line:84% In general, it can allow more trade 00:16:36.660 --> 00:16:39.120 align:middle line:90% than deterministic allocations. 00:16:39.120 --> 00:16:41.980 align:middle line:90% 00:16:41.980 --> 00:16:44.240 align:middle line:84% When there's only one good, there's no trade-off. 00:16:44.240 --> 00:16:45.540 align:middle line:90% More is preferred to less. 00:16:45.540 --> 00:16:48.980 align:middle line:84% With the lottery, you have a mean variance trade-off, 00:16:48.980 --> 00:16:53.620 align:middle line:84% and you can exploit that sometimes. 00:16:53.620 --> 00:16:59.620 align:middle line:84% Another reason is this is quite computable. 00:16:59.620 --> 00:17:05.020 align:middle line:84% This is a linear program because the objects 00:17:05.020 --> 00:17:08.020 align:middle line:90% are these probability numbers. 00:17:08.020 --> 00:17:13.380 align:middle line:84% And they're entering the objective function linearly. 00:17:13.380 --> 00:17:20.579 align:middle line:84% And they're entering the constraints linearly. 00:17:20.579 --> 00:17:24.420 align:middle line:84% I mean, we're so used to thinking of choosing tau 00:17:24.420 --> 00:17:26.240 align:middle line:90% within the utility function. 00:17:26.240 --> 00:17:28.700 align:middle line:84% Now, with the lotteries, we're choosing the weights 00:17:28.700 --> 00:17:30.820 align:middle line:90% on that outcome. 00:17:30.820 --> 00:17:32.480 align:middle line:90% So that's kind of a trick. 00:17:32.480 --> 00:17:35.060 align:middle line:90% 00:17:35.060 --> 00:17:38.300 align:middle line:84% But it does mean when we're stalled out 00:17:38.300 --> 00:17:40.980 align:middle line:84% and we can't characterize the solution 00:17:40.980 --> 00:17:44.420 align:middle line:84% as well as we might like to do analytically, 00:17:44.420 --> 00:17:49.780 align:middle line:84% we can resort to linear code to compute 00:17:49.780 --> 00:17:53.940 align:middle line:84% these information-constrained optimal allocations. 00:17:53.940 --> 00:17:59.900 align:middle line:84% And programs like Gurobi, which is open software, 00:17:59.900 --> 00:18:04.580 align:middle line:84% can handle hundreds of thousands of variables and thousands 00:18:04.580 --> 00:18:08.660 align:middle line:84% of constraints and solve it relatively quickly 00:18:08.660 --> 00:18:11.900 align:middle line:90% on your laptop. 00:18:11.900 --> 00:18:14.430 align:middle line:84% STUDENT: And the W should be a theta? 00:18:14.430 --> 00:18:17.620 align:middle line:84% ROBERT M. TOWNSEND: The W here is this constant endowment 00:18:17.620 --> 00:18:18.580 align:middle line:90% vector of-- 00:18:18.580 --> 00:18:19.982 align:middle line:90% STUDENT: Ah, that's not theta. 00:18:19.982 --> 00:18:20.940 align:middle line:90% ROBERT M. TOWNSEND: No. 00:18:20.940 --> 00:18:22.232 align:middle line:90% STUDENT: So that's [INAUDIBLE]. 00:18:22.232 --> 00:18:23.273 align:middle line:90% ROBERT M. TOWNSEND: Yeah. 00:18:23.273 --> 00:18:24.480 align:middle line:90% This is agent 1 with theta. 00:18:24.480 --> 00:18:26.040 align:middle line:90% This is agent 2 with W. 00:18:26.040 --> 00:18:29.010 align:middle line:90% STUDENT: I see. 00:18:29.010 --> 00:18:32.910 align:middle line:84% ROBERT M. TOWNSEND: And again, I'm not going to do that today. 00:18:32.910 --> 00:18:35.350 align:middle line:84% But you could imagine two active agents, 00:18:35.350 --> 00:18:40.570 align:middle line:84% each with his or her own random outcomes. 00:18:40.570 --> 00:18:42.810 align:middle line:84% So it could still be an agrarian economy 00:18:42.810 --> 00:18:46.730 align:middle line:84% where farmers are growing rice, and they take actions, 00:18:46.730 --> 00:18:50.810 align:middle line:84% and they have randomly determined harvests 00:18:50.810 --> 00:18:52.910 align:middle line:84% as a function of temperature and rainfall. 00:18:52.910 --> 00:18:56.730 align:middle line:84% But it equally applies to financial markets 00:18:56.730 --> 00:18:59.830 align:middle line:90% where they have assets. 00:18:59.830 --> 00:19:02.950 align:middle line:84% And the assets have randomly determined yields. 00:19:02.950 --> 00:19:09.610 align:middle line:84% And somehow, they get to see something 00:19:09.610 --> 00:19:11.550 align:middle line:90% that external agents don't see. 00:19:11.550 --> 00:19:16.970 align:middle line:84% But we could have them announce these unobserved states. 00:19:16.970 --> 00:19:20.370 align:middle line:84% So it applies to high-valued financial markets-- 00:19:20.370 --> 00:19:23.570 align:middle line:84% portfolios of the agents being private and subject 00:19:23.570 --> 00:19:29.010 align:middle line:84% to these unobserved random shocks. 00:19:29.010 --> 00:19:30.210 align:middle line:90% OK. 00:19:30.210 --> 00:19:34.310 align:middle line:84% Now, again, I'm not going to do much about this. 00:19:34.310 --> 00:19:37.370 align:middle line:84% So if there were one good, it's easier 00:19:37.370 --> 00:19:42.930 align:middle line:84% to think about it that way than it's a scalar economy, 00:19:42.930 --> 00:19:46.250 align:middle line:84% and we're talking about insurance. 00:19:46.250 --> 00:19:50.730 align:middle line:84% So the logical target is like a full insurance allocation, 00:19:50.730 --> 00:19:55.650 align:middle line:84% where the agent with the low outcome would like an indemnity 00:19:55.650 --> 00:19:58.010 align:middle line:84% and is willing, in turn, to pay a premium 00:19:58.010 --> 00:20:00.530 align:middle line:90% if his or her output were high. 00:20:00.530 --> 00:20:07.370 align:middle line:90% So what's the incentive to lie? 00:20:07.370 --> 00:20:10.990 align:middle line:84% If you're high, you would be paying a premium. 00:20:10.990 --> 00:20:13.530 align:middle line:84% So you might prefer to get the indemnity. 00:20:13.530 --> 00:20:17.050 align:middle line:84% So the binding incentive constraint on such a problem 00:20:17.050 --> 00:20:21.330 align:middle line:84% would only apply to the high-theta agents who would 00:20:21.330 --> 00:20:23.070 align:middle line:90% prefer not to pay the premium. 00:20:23.070 --> 00:20:26.080 align:middle line:84% And the guy receiving an indemnity 00:20:26.080 --> 00:20:30.240 align:middle line:84% doesn't have any binding constraint. 00:20:30.240 --> 00:20:33.720 align:middle line:84% I mention that because, in general, you 00:20:33.720 --> 00:20:35.880 align:middle line:84% could imagine enhancing the mechanism 00:20:35.880 --> 00:20:39.600 align:middle line:90% to allow pre-transfer displays. 00:20:39.600 --> 00:20:42.280 align:middle line:84% I mean, if you're claiming something about your output 00:20:42.280 --> 00:20:46.520 align:middle line:84% after all, then, in principle, you could show it, 00:20:46.520 --> 00:20:48.480 align:middle line:90% like, show me your cards. 00:20:48.480 --> 00:20:51.200 align:middle line:84% And if your endowment is low, you 00:20:51.200 --> 00:20:54.520 align:middle line:90% can't show stuff you don't have. 00:20:54.520 --> 00:20:56.620 align:middle line:84% In this case, it wouldn't be a worry. 00:20:56.620 --> 00:21:00.520 align:middle line:84% But in general, you could enhance these mechanisms 00:21:00.520 --> 00:21:04.280 align:middle line:90% to allow displays. 00:21:04.280 --> 00:21:07.720 align:middle line:84% So far, it's just been one period with this allocation 00:21:07.720 --> 00:21:11.280 align:middle line:84% scheme-- not so much a fixed rental for the land 00:21:11.280 --> 00:21:16.500 align:middle line:84% as a schedule of what rent to pay, but only one period. 00:21:16.500 --> 00:21:19.040 align:middle line:84% So if there are multiple periods, 00:21:19.040 --> 00:21:21.440 align:middle line:90% we can extend it pretty easily. 00:21:21.440 --> 00:21:26.000 align:middle line:84% We'll talk about day date t, taking on values 1 or 2, 00:21:26.000 --> 00:21:30.140 align:middle line:84% theta sub t being the privately observed endowment of the villa 00:21:30.140 --> 00:21:31.400 align:middle line:90% agent 1. 00:21:31.400 --> 00:21:37.080 align:middle line:84% At date t, W sub t now being endowment of agent 2 00:21:37.080 --> 00:21:41.120 align:middle line:84% allowed to vary with time, but not random otherwise. 00:21:41.120 --> 00:21:46.420 align:middle line:84% And we can have these Markov probabilities on the theta. 00:21:46.420 --> 00:21:48.420 align:middle line:84% What's the probability of the first one? 00:21:48.420 --> 00:21:49.140 align:middle line:90% Theta 1. 00:21:49.140 --> 00:21:51.640 align:middle line:84% What's the probability of the second one 00:21:51.640 --> 00:21:53.480 align:middle line:90% conditioned on the first one? 00:21:53.480 --> 00:22:00.680 align:middle line:84% And write down a little bit more notation, 00:22:00.680 --> 00:22:03.780 align:middle line:84% although it's the same idea as before. 00:22:03.780 --> 00:22:06.680 align:middle line:84% We're going to maximize a weighted sum of utilities 00:22:06.680 --> 00:22:08.080 align:middle line:90% of the agents. 00:22:08.080 --> 00:22:13.400 align:middle line:84% There's just more terms in the utility outcome function 00:22:13.400 --> 00:22:19.000 align:middle line:84% for each agent to capture the first period with the lottery, 00:22:19.000 --> 00:22:24.190 align:middle line:84% and also the second period with the lottery. 00:22:24.190 --> 00:22:25.730 align:middle line:90% It's a lot of notation. 00:22:25.730 --> 00:22:29.110 align:middle line:84% So in the second period, this is the probability 00:22:29.110 --> 00:22:34.590 align:middle line:84% of tau given the realization of theta at date 1 00:22:34.590 --> 00:22:37.790 align:middle line:84% and the realization of theta at date 2. 00:22:37.790 --> 00:22:39.410 align:middle line:90% This is actually date two. 00:22:39.410 --> 00:22:43.950 align:middle line:84% So theta 2 is in agent 1's utility function 00:22:43.950 --> 00:22:47.550 align:middle line:84% by the normalization, quote, "paying out tau." 00:22:47.550 --> 00:22:50.350 align:middle line:84% And then these are the overall probability 00:22:50.350 --> 00:22:53.190 align:middle line:84% of theta 2 given theta 1 times the probability of theta 1 00:22:53.190 --> 00:22:56.530 align:middle line:84% is the joint probability of theta 1 and theta 2. 00:22:56.530 --> 00:23:00.950 align:middle line:84% We discount by beta, although it could be 1. 00:23:00.950 --> 00:23:04.750 align:middle line:90% No harm done for agent 1. 00:23:04.750 --> 00:23:09.910 align:middle line:84% And this is this longer expression for agent 2. 00:23:09.910 --> 00:23:14.470 align:middle line:84% Now, if there's anything interesting in this slightly 00:23:14.470 --> 00:23:19.710 align:middle line:84% enhanced model, it's this guy here 00:23:19.710 --> 00:23:24.750 align:middle line:84% that we've now put a theta 1 into the allocation rule 00:23:24.750 --> 00:23:25.690 align:middle line:90% at date 2. 00:23:25.690 --> 00:23:28.870 align:middle line:90% 00:23:28.870 --> 00:23:32.870 align:middle line:84% And that's going to be very helpful to allow 00:23:32.870 --> 00:23:35.630 align:middle line:90% some gains to trade. 00:23:35.630 --> 00:23:40.230 align:middle line:84% But before I get into that, really, the proof of it 00:23:40.230 --> 00:23:42.650 align:middle line:84% has to do with these incentive constraints. 00:23:42.650 --> 00:23:45.210 align:middle line:90% So it's like a dynamic program. 00:23:45.210 --> 00:23:48.350 align:middle line:90% The world ends at date 2. 00:23:48.350 --> 00:23:50.550 align:middle line:84% So let's figure out what's happening. 00:23:50.550 --> 00:23:53.750 align:middle line:84% Somehow, theta tilde 1 was announced. 00:23:53.750 --> 00:23:59.270 align:middle line:84% Just take it as a given, whatever it was, truth or a lie. 00:23:59.270 --> 00:24:02.350 align:middle line:84% It's indexing the allocation rule. 00:24:02.350 --> 00:24:06.030 align:middle line:84% So now the agent-- remember my routine here. 00:24:06.030 --> 00:24:07.710 align:middle line:90% Theta 2 is the actual. 00:24:07.710 --> 00:24:09.750 align:middle line:90% You could say the actual. 00:24:09.750 --> 00:24:13.390 align:middle line:84% It's still the actual, but you could lie about it and say, 00:24:13.390 --> 00:24:15.150 align:middle line:90% theta tilde 2. 00:24:15.150 --> 00:24:18.820 align:middle line:84% So this ensures you'll weakly tell the truth when 00:24:18.820 --> 00:24:22.140 align:middle line:84% the parameter value-- and this is true for all possible 00:24:22.140 --> 00:24:28.020 align:middle line:84% histories theta tilde 1 and all possible theta 2's. 00:24:28.020 --> 00:24:30.300 align:middle line:84% It says it in the text, but it would be better 00:24:30.300 --> 00:24:33.500 align:middle line:84% to write that out explicitly just to remember. 00:24:33.500 --> 00:24:35.080 align:middle line:90% It's not just one constraint. 00:24:35.080 --> 00:24:39.740 align:middle line:84% It's a whole family of constraints. 00:24:39.740 --> 00:24:41.280 align:middle line:90% And what happens at date 1? 00:24:41.280 --> 00:24:46.060 align:middle line:84% Well, with this, you're sure the agent will, quote, 00:24:46.060 --> 00:24:48.300 align:middle line:84% "tell the truth in the second period." 00:24:48.300 --> 00:24:50.860 align:middle line:84% So now let's take that as a given. 00:24:50.860 --> 00:24:53.500 align:middle line:84% The incentive constraint for date 1 00:24:53.500 --> 00:24:57.380 align:middle line:84% takes as given that when you have theta 2, 00:24:57.380 --> 00:24:58.960 align:middle line:90% you will say theta 2. 00:24:58.960 --> 00:25:01.180 align:middle line:90% That's inherited from 96. 00:25:01.180 --> 00:25:05.580 align:middle line:84% What this is running over is the possible lie 00:25:05.580 --> 00:25:08.660 align:middle line:90% about the parameter at date 1. 00:25:08.660 --> 00:25:10.600 align:middle line:90% Theta 1 is the actual value. 00:25:10.600 --> 00:25:14.660 align:middle line:84% And you should say so rather than theta 1 00:25:14.660 --> 00:25:19.930 align:middle line:84% being the actual value and the villa saying theta tilde 1. 00:25:19.930 --> 00:25:24.770 align:middle line:84% So this is the pair of these constraints' families 00:25:24.770 --> 00:25:28.890 align:middle line:84% is going to ensure you'll tell the truth in both dates. 00:25:28.890 --> 00:25:34.650 align:middle line:84% So what happens if there are no incentive constraints? 00:25:34.650 --> 00:25:44.170 align:middle line:84% Then we're looking at the usual risk-sharing problem. 00:25:44.170 --> 00:25:50.450 align:middle line:84% Agent 1, risk-averse; agent 2, risk-neutral. 00:25:50.450 --> 00:25:52.550 align:middle line:84% We know which way the insurance should flow. 00:25:52.550 --> 00:25:56.410 align:middle line:84% Not only that, we know from the risk-sharing problem 00:25:56.410 --> 00:26:02.610 align:middle line:84% that it decomposes into essentially a static problem. 00:26:02.610 --> 00:26:07.910 align:middle line:84% You just take the level of community resources, 00:26:07.910 --> 00:26:10.330 align:middle line:84% pool them together, and implement 00:26:10.330 --> 00:26:13.970 align:middle line:90% the optimized risk-sharing rule. 00:26:13.970 --> 00:26:18.763 align:middle line:84% The amount there can vary, but the rule does not vary. 00:26:18.763 --> 00:26:20.930 align:middle line:84% And so even though with all these dates, and states, 00:26:20.930 --> 00:26:26.570 align:middle line:84% and everything else, we, without additional constraints, 00:26:26.570 --> 00:26:30.970 align:middle line:84% got essentially static risk-sharing rule. 00:26:30.970 --> 00:26:33.250 align:middle line:90% Will that work here? 00:26:33.250 --> 00:26:37.250 align:middle line:84% No, because of the private information. 00:26:37.250 --> 00:26:40.330 align:middle line:84% Again, if there's only one good, the agent 00:26:40.330 --> 00:26:46.930 align:middle line:84% would always claim theta to be low to get the indemnity. 00:26:46.930 --> 00:26:51.010 align:middle line:90% And it's not rocket science. 00:26:51.010 --> 00:26:53.670 align:middle line:84% Agent 2, the monastery, knows that. 00:26:53.670 --> 00:26:58.910 align:middle line:84% So they could not possibly be trading anything. 00:26:58.910 --> 00:27:02.810 align:middle line:84% So full risk sharing is not feasible. 00:27:02.810 --> 00:27:07.250 align:middle line:84% With the two periods, though, something more than autarky 00:27:07.250 --> 00:27:08.810 align:middle line:90% is possible. 00:27:08.810 --> 00:27:12.470 align:middle line:84% So even though you can't do much at the second date 00:27:12.470 --> 00:27:15.940 align:middle line:84% if there's only one good, effectively it's a constant. 00:27:15.940 --> 00:27:17.640 align:middle line:90% What is that constant? 00:27:17.640 --> 00:27:20.560 align:middle line:84% Well, it could be a bit like borrowing and lending. 00:27:20.560 --> 00:27:24.800 align:middle line:84% When you think about it, the option 00:27:24.800 --> 00:27:28.120 align:middle line:84% is on the table to either borrow or lend at a known interest 00:27:28.120 --> 00:27:29.160 align:middle line:90% rate. 00:27:29.160 --> 00:27:35.660 align:middle line:84% And the person on the other side doesn't know the income, 00:27:35.660 --> 00:27:38.880 align:middle line:84% but lets the agent choose whether to borrow 00:27:38.880 --> 00:27:46.760 align:middle line:84% money or deposit money, say, in the bank with a principal. 00:27:46.760 --> 00:27:50.680 align:middle line:84% So we think about the standard borrowing-and-lending thing. 00:27:50.680 --> 00:27:55.420 align:middle line:84% If your income were low, you're short of resources, 00:27:55.420 --> 00:27:58.020 align:middle line:84% you have a high marginal utility for consumption. 00:27:58.020 --> 00:28:02.000 align:middle line:84% So you would prefer to borrow granted the commitment 00:28:02.000 --> 00:28:03.780 align:middle line:90% to pay back in the next date. 00:28:03.780 --> 00:28:06.600 align:middle line:84% And we're assuming there's full commitment. 00:28:06.600 --> 00:28:10.920 align:middle line:84% You could say your endowment is high, 00:28:10.920 --> 00:28:13.760 align:middle line:90% and you want to be a lender. 00:28:13.760 --> 00:28:15.740 align:middle line:84% But that just goes the wrong way. 00:28:15.740 --> 00:28:19.520 align:middle line:84% You're subtracting resources away when you're short 00:28:19.520 --> 00:28:24.620 align:middle line:84% and getting them when you're well endowed in the next period. 00:28:24.620 --> 00:28:27.480 align:middle line:84% So although we typically don't think about it 00:28:27.480 --> 00:28:31.640 align:middle line:84% that way, borrowing and lending is incentive-compatible, 00:28:31.640 --> 00:28:35.680 align:middle line:90% even with private information. 00:28:35.680 --> 00:28:38.400 align:middle line:90% But is it optimal? 00:28:38.400 --> 00:28:39.240 align:middle line:90% No. 00:28:39.240 --> 00:28:43.760 align:middle line:84% Borrowing and lending is not the optimized solution 00:28:43.760 --> 00:28:45.840 align:middle line:90% to this problem. 00:28:45.840 --> 00:28:47.960 align:middle line:90% Well, why is that? 00:28:47.960 --> 00:28:51.140 align:middle line:84% Well, go through what I was just describing. 00:28:51.140 --> 00:28:54.960 align:middle line:84% Suppose you strictly prefer to borrow when your income is low, 00:28:54.960 --> 00:28:59.040 align:middle line:84% you strictly prefer to lend when your income is high. 00:28:59.040 --> 00:29:03.720 align:middle line:84% So that means the so-called incentive constraints 00:29:03.720 --> 00:29:08.340 align:middle line:84% apply with a strict inequality in the proposed solution. 00:29:08.340 --> 00:29:12.910 align:middle line:84% So you have the full solution with the incentive constraints. 00:29:12.910 --> 00:29:15.570 align:middle line:84% We came up with a feasible allocation, 00:29:15.570 --> 00:29:18.950 align:middle line:90% which is incentive-compatible. 00:29:18.950 --> 00:29:22.990 align:middle line:84% But it has both of the truth-telling constraints 00:29:22.990 --> 00:29:24.750 align:middle line:90% not binding. 00:29:24.750 --> 00:29:28.710 align:middle line:84% You have a strict preference over what you're doing. 00:29:28.710 --> 00:29:31.530 align:middle line:84% And if they're not binding, suppose it were optimal. 00:29:31.530 --> 00:29:34.510 align:middle line:84% That means if that's the optimized solution 00:29:34.510 --> 00:29:38.130 align:middle line:84% without incentive constraints, it should be full insurance. 00:29:38.130 --> 00:29:40.010 align:middle line:84% But full insurance is not feasible. 00:29:40.010 --> 00:29:43.070 align:middle line:84% So it's a little bit of a proof by contradiction that 00:29:43.070 --> 00:29:46.030 align:middle line:84% the optimized solution cannot be the borrowing-and-lending 00:29:46.030 --> 00:29:47.470 align:middle line:90% solution. 00:29:47.470 --> 00:29:49.070 align:middle line:90% What will it be? 00:29:49.070 --> 00:29:56.350 align:middle line:84% It's a hybrid scheme that embeds the risk-sharing aspect 00:29:56.350 --> 00:29:59.590 align:middle line:84% with the intertemporal trade-off. 00:29:59.590 --> 00:30:01.710 align:middle line:84% The intertemporal trade-off is, what 00:30:01.710 --> 00:30:04.110 align:middle line:84% happens at the second date depends 00:30:04.110 --> 00:30:07.630 align:middle line:84% on what happened at the first one, or, at least, 00:30:07.630 --> 00:30:09.950 align:middle line:90% what was said about it. 00:30:09.950 --> 00:30:11.210 align:middle line:90% That's the tie-in. 00:30:11.210 --> 00:30:14.030 align:middle line:84% And that's the reason we're having this theta tilde 1 00:30:14.030 --> 00:30:15.665 align:middle line:90% entering into the-- 00:30:15.665 --> 00:30:16.290 align:middle line:90% STUDENT: Sorry. 00:30:16.290 --> 00:30:17.370 align:middle line:90% I didn't understand why. 00:30:17.370 --> 00:30:20.190 align:middle line:84% Why are the incentive constraints strict 00:30:20.190 --> 00:30:22.210 align:middle line:84% when we do the borrowing and lending? 00:30:22.210 --> 00:30:25.997 align:middle line:84% Why do they have to be strict in that case? 00:30:25.997 --> 00:30:28.330 align:middle line:84% ROBERT M. TOWNSEND: It's more, what if they were strict? 00:30:28.330 --> 00:30:31.105 align:middle line:90% 00:30:31.105 --> 00:30:33.730 align:middle line:84% STUDENT: So I agree that if they were strict, it's not optimal. 00:30:33.730 --> 00:30:36.030 align:middle line:84% But why was it true that whenever 00:30:36.030 --> 00:30:38.790 align:middle line:84% we implement a borrowing and lending, they have to have-- 00:30:38.790 --> 00:30:40.290 align:middle line:84% ROBERT M. TOWNSEND: Strictly concave 00:30:40.290 --> 00:30:45.810 align:middle line:84% utility and the endowment being a scalar, being low or high, 00:30:45.810 --> 00:30:47.830 align:middle line:84% so the marginal utility of consumption 00:30:47.830 --> 00:30:51.530 align:middle line:90% is high when your income is low. 00:30:51.530 --> 00:30:55.310 align:middle line:84% So you'd like to get something incoming. 00:30:55.310 --> 00:30:58.250 align:middle line:84% Well, again, what is the meaning of it? 00:30:58.250 --> 00:31:00.810 align:middle line:84% It means if we're trying to implement, 00:31:00.810 --> 00:31:04.630 align:middle line:84% at least in this environment, an allocation mechanism that 00:31:04.630 --> 00:31:08.140 align:middle line:84% respects private information, we would expect 00:31:08.140 --> 00:31:10.040 align:middle line:90% it to not be pure credit. 00:31:10.040 --> 00:31:14.060 align:middle line:84% We would expect it not to be pure insurance either. 00:31:14.060 --> 00:31:16.480 align:middle line:84% It would be a financial contract, 00:31:16.480 --> 00:31:20.940 align:middle line:84% which is like a hybrid blend of credit and insurance. 00:31:20.940 --> 00:31:24.100 align:middle line:84% And we see those kinds of things in practice. 00:31:24.100 --> 00:31:27.300 align:middle line:84% We see flexible loans, for example, 00:31:27.300 --> 00:31:33.860 align:middle line:84% where it may be possible to defer repayment, 00:31:33.860 --> 00:31:40.100 align:middle line:84% depending on what is announced by the client, for example. 00:31:40.100 --> 00:31:44.260 align:middle line:84% On the other hand, it would probably be a bad idea 00:31:44.260 --> 00:31:46.380 align:middle line:84% to separate the insurance company and say, 00:31:46.380 --> 00:31:49.260 align:middle line:84% only insurance companies can offer that stuff 00:31:49.260 --> 00:31:51.260 align:middle line:84% from the borrowing and lending and say 00:31:51.260 --> 00:31:54.300 align:middle line:84% that only banks can do it because it's 00:31:54.300 --> 00:31:57.380 align:middle line:84% one agent with an underlying decision problem. 00:31:57.380 --> 00:32:01.940 align:middle line:84% And those two pieces really need to be coupled together 00:32:01.940 --> 00:32:05.610 align:middle line:90% in a pretty careful way. 00:32:05.610 --> 00:32:09.130 align:middle line:84% Otherwise, one or the other of those parties could-- 00:32:09.130 --> 00:32:11.890 align:middle line:84% the insurance company always able to get a payoff 00:32:11.890 --> 00:32:14.810 align:middle line:84% to pay off the loan, then the lending company 00:32:14.810 --> 00:32:16.490 align:middle line:90% is going to go bankrupt. 00:32:16.490 --> 00:32:17.730 align:middle line:90% OK. 00:32:17.730 --> 00:32:20.730 align:middle line:84% Implementation without the planner-- 00:32:20.730 --> 00:32:26.210 align:middle line:84% well, the planner is a reference to the maximization problem. 00:32:26.210 --> 00:32:31.850 align:middle line:84% In economics, we refer to these things as planning problems. 00:32:31.850 --> 00:32:40.890 align:middle line:84% But it does conjure up a third party implementing the thing. 00:32:40.890 --> 00:32:42.950 align:middle line:84% We really don't need a third party. 00:32:42.950 --> 00:32:46.370 align:middle line:90% We don't need a trusted planner. 00:32:46.370 --> 00:32:56.190 align:middle line:84% The information-constrained allocation rule is a code. 00:32:56.190 --> 00:32:58.230 align:middle line:84% You can call it, say, a smart contract. 00:32:58.230 --> 00:33:00.250 align:middle line:84% I'll come back to that in a minute. 00:33:00.250 --> 00:33:03.710 align:middle line:84% And the agents enter into it voluntarily, 00:33:03.710 --> 00:33:06.330 align:middle line:84% having understood how the code works. 00:33:06.330 --> 00:33:07.810 align:middle line:90% They hash it up. 00:33:07.810 --> 00:33:11.330 align:middle line:84% We'll come back to that next time we talk about encryption. 00:33:11.330 --> 00:33:13.930 align:middle line:84% And so there's a public display of the commitment 00:33:13.930 --> 00:33:15.810 align:middle line:90% to carry out the plan. 00:33:15.810 --> 00:33:18.010 align:middle line:90% This is what we agree to. 00:33:18.010 --> 00:33:20.490 align:middle line:84% Hopefully, some judge would be persuaded 00:33:20.490 --> 00:33:22.650 align:middle line:90% that it was all voluntary. 00:33:22.650 --> 00:33:24.250 align:middle line:84% After the fact, you could imagine 00:33:24.250 --> 00:33:27.050 align:middle line:84% one or the other of these guys complaining, like, oh, no, I 00:33:27.050 --> 00:33:28.190 align:middle line:90% didn't really mean it. 00:33:28.190 --> 00:33:33.290 align:middle line:84% I don't want to have to pay, like the trade fails 00:33:33.290 --> 00:33:34.690 align:middle line:90% we talked about. 00:33:34.690 --> 00:33:38.610 align:middle line:84% But again, it would be clear that they had agreed to it. 00:33:38.610 --> 00:33:42.130 align:middle line:84% In terms of where the resource is coming from, 00:33:42.130 --> 00:33:44.490 align:middle line:84% this depends a bit on the context, 00:33:44.490 --> 00:33:49.330 align:middle line:84% but you can imagine calculating from the smart contract 00:33:49.330 --> 00:33:54.570 align:middle line:84% the maximum amount that would be required to be paid out. 00:33:54.570 --> 00:33:56.570 align:middle line:84% Not that it necessarily will be, that it 00:33:56.570 --> 00:34:00.230 align:middle line:84% could be run over positive, negative, 00:34:00.230 --> 00:34:02.120 align:middle line:84% what's the worst case scenario for me? 00:34:02.120 --> 00:34:04.080 align:middle line:90% That goes into escrow. 00:34:04.080 --> 00:34:05.442 align:middle line:90% So now that's tied up. 00:34:05.442 --> 00:34:06.900 align:middle line:84% You don't have any control over it. 00:34:06.900 --> 00:34:10.040 align:middle line:84% If you agree to it, before this thing even runs, 00:34:10.040 --> 00:34:17.040 align:middle line:84% they put stuff in escrow in a way that guarantees performance. 00:34:17.040 --> 00:34:21.800 align:middle line:84% So that handles the limited-commitment problem. 00:34:21.800 --> 00:34:25.679 align:middle line:84% And again, if you're a little leery 00:34:25.679 --> 00:34:29.440 align:middle line:84% about making all these messages and having them recorded 00:34:29.440 --> 00:34:31.880 align:middle line:84% on the ledger and so on and so forth, 00:34:31.880 --> 00:34:34.219 align:middle line:84% then we can resort to encryption. 00:34:34.219 --> 00:34:37.900 align:middle line:84% And I will talk about that next time. 00:34:37.900 --> 00:34:41.300 align:middle line:84% So these messages can be kept private. 00:34:41.300 --> 00:34:43.719 align:middle line:84% The key part of the encryption is 00:34:43.719 --> 00:34:46.460 align:middle line:84% that the code can operate on encrypted messages. 00:34:46.460 --> 00:34:49.639 align:middle line:84% It doesn't need to see the actual numbers. 00:34:49.639 --> 00:34:52.000 align:middle line:90% It will do the right thing. 00:34:52.000 --> 00:34:55.020 align:middle line:84% And where are all these two periods or more? 00:34:55.020 --> 00:34:56.840 align:middle line:84% There's a history here of messages, 00:34:56.840 --> 00:35:00.780 align:middle line:84% which is key to the optimized allocation rule. 00:35:00.780 --> 00:35:04.220 align:middle line:84% So those messages are also recorded. 00:35:04.220 --> 00:35:05.540 align:middle line:90% They're part of the database. 00:35:05.540 --> 00:35:10.200 align:middle line:84% We talked about the history of transactions on Bitcoin 00:35:10.200 --> 00:35:14.880 align:middle line:84% as squirreled away in these Merkle tree archives of data. 00:35:14.880 --> 00:35:16.520 align:middle line:84% In this case, you would also want 00:35:16.520 --> 00:35:19.960 align:middle line:84% to be storing the history of messages 00:35:19.960 --> 00:35:23.840 align:middle line:84% securely with the hashes and so on. 00:35:23.840 --> 00:35:29.720 align:middle line:84% And finally, a bit about layer 1 and layer 2-- 00:35:29.720 --> 00:35:33.040 align:middle line:84% when we think about Ethereum, it reads 00:35:33.040 --> 00:35:37.880 align:middle line:84% as if anytime the code as a node is 00:35:37.880 --> 00:35:41.400 align:middle line:84% going to proceed with a transaction, 00:35:41.400 --> 00:35:46.800 align:middle line:84% that it has to be validated by the community. 00:35:46.800 --> 00:35:50.160 align:middle line:84% Well, here, what I want to do is distinguish 00:35:50.160 --> 00:35:54.900 align:middle line:84% being validated and run on all the EVMs of all the nodes. 00:35:54.900 --> 00:35:57.590 align:middle line:84% Yes, they've all agreed to the code, 00:35:57.590 --> 00:36:00.430 align:middle line:84% and it runs on everyone's computer. 00:36:00.430 --> 00:36:07.710 align:middle line:84% But there is no need to be executing the mechanism step 00:36:07.710 --> 00:36:11.550 align:middle line:84% by step, line by line, over time,et cetera, 00:36:11.550 --> 00:36:14.630 align:middle line:84% and throwing that out for validation on the premise that 00:36:14.630 --> 00:36:17.230 align:middle line:84% they know what they've agreed to, and they understand how it 00:36:17.230 --> 00:36:18.910 align:middle line:90% operates, and so on. 00:36:18.910 --> 00:36:21.590 align:middle line:84% So you end up with diagrams like this, where 00:36:21.590 --> 00:36:24.630 align:middle line:90% the smart contract is here. 00:36:24.630 --> 00:36:29.270 align:middle line:84% And these agents-- in this case, two of them sending messages 00:36:29.270 --> 00:36:33.430 align:middle line:84% from the permitted message spaces about underlying 00:36:33.430 --> 00:36:36.450 align:middle line:84% unobserved objects that enter into the smart contract. 00:36:36.450 --> 00:36:39.370 align:middle line:84% The smart contract is, for example, 00:36:39.370 --> 00:36:42.590 align:middle line:84% the one we derived just now in that economy. 00:36:42.590 --> 00:36:48.190 align:middle line:84% And the messages lead to obligations 00:36:48.190 --> 00:36:53.310 align:middle line:90% to transfer or receive money. 00:36:53.310 --> 00:36:55.290 align:middle line:90% So we need the ledgers. 00:36:55.290 --> 00:36:57.690 align:middle line:90% But this one got deleted. 00:36:57.690 --> 00:36:58.610 align:middle line:90% Here's the ledger. 00:36:58.610 --> 00:37:00.130 align:middle line:84% There's the balance sheet up there. 00:37:00.130 --> 00:37:05.910 align:middle line:84% So they all have their balance sheets on Ethereum. 00:37:05.910 --> 00:37:11.630 align:middle line:84% And at the end, when the mechanism is executed, 00:37:11.630 --> 00:37:15.110 align:middle line:84% they're making transfers across the balances 00:37:15.110 --> 00:37:18.430 align:middle line:84% consistent with the smart contract. 00:37:18.430 --> 00:37:22.590 align:middle line:90% This is called layer 2 because-- 00:37:22.590 --> 00:37:24.990 align:middle line:84% again, I'm repeating myself-- it's not 00:37:24.990 --> 00:37:28.430 align:middle line:84% all being done in real time on Ethereum 00:37:28.430 --> 00:37:32.610 align:middle line:84% with ether being used up for the validation. 00:37:32.610 --> 00:37:36.830 align:middle line:84% This is an amusing typo, actually 00:37:36.830 --> 00:37:39.790 align:middle line:84% worse because it was deliberate on my part. 00:37:39.790 --> 00:37:44.110 align:middle line:84% This should say off-chain in the pink. 00:37:44.110 --> 00:37:48.110 align:middle line:84% And below it in the black and white should be on-chain-- 00:37:48.110 --> 00:37:55.660 align:middle line:84% the chain referring to the ledgers and the blockchain. 00:37:55.660 --> 00:37:59.500 align:middle line:84% Whereas the contract is external, 00:37:59.500 --> 00:38:03.700 align:middle line:84% being run effectively without the validation. 00:38:03.700 --> 00:38:07.820 align:middle line:84% And I just assume that the center of the Earth 00:38:07.820 --> 00:38:09.240 align:middle line:90% was the smart contract. 00:38:09.240 --> 00:38:11.300 align:middle line:84% So it should be on-chain, but that's not 00:38:11.300 --> 00:38:16.900 align:middle line:84% the right nomenclature for this problem. 00:38:16.900 --> 00:38:19.300 align:middle line:90% OK. 00:38:19.300 --> 00:38:20.080 align:middle line:90% All right. 00:38:20.080 --> 00:38:25.740 align:middle line:84% So let's come to protocols and notions of trust. 00:38:25.740 --> 00:38:29.300 align:middle line:84% First, a look at the validation algorithms 00:38:29.300 --> 00:38:35.740 align:middle line:84% in Ethereum, and Bitcoin, and others, and then, finally, 00:38:35.740 --> 00:38:39.740 align:middle line:84% a tension between following a protocol 00:38:39.740 --> 00:38:44.700 align:middle line:84% as in computer science versus incentives in the mechanism 00:38:44.700 --> 00:38:45.680 align:middle line:90% design problem. 00:38:45.680 --> 00:38:51.460 align:middle line:84% So for alternative protocols, we have mentioned Bitcoin, 00:38:51.460 --> 00:38:55.940 align:middle line:84% and we will come back to Bitcoin again next time. 00:38:55.940 --> 00:38:58.940 align:middle line:90% Bitcoin uses up electricity. 00:38:58.940 --> 00:39:03.540 align:middle line:90% And it's not fast either. 00:39:03.540 --> 00:39:06.260 align:middle line:90% Why? 00:39:06.260 --> 00:39:14.060 align:middle line:84% Essentially, the idea is that whoever solves the cryptographic 00:39:14.060 --> 00:39:18.700 align:middle line:84% puzzle the first is the one to, quote, "validate" 00:39:18.700 --> 00:39:23.140 align:middle line:84% the batch of transactions that that's up for validation. 00:39:23.140 --> 00:39:26.440 align:middle line:84% But it's random who's going to solve it first 00:39:26.440 --> 00:39:29.540 align:middle line:84% because you can only solve it with trial and error. 00:39:29.540 --> 00:39:32.060 align:middle line:90% So most people are honest. 00:39:32.060 --> 00:39:36.580 align:middle line:84% So what are the odds that a randomly chosen validator 00:39:36.580 --> 00:39:40.560 align:middle line:84% will be one of the nefarious evil nodes? 00:39:40.560 --> 00:39:46.280 align:middle line:84% So that's the intuitive logic of the Bitcoin validation, 00:39:46.280 --> 00:39:49.740 align:middle line:84% but it is using computers, as you all know, 00:39:49.740 --> 00:39:56.690 align:middle line:90% to solve these puzzles. 00:39:56.690 --> 00:40:03.050 align:middle line:84% There are other algorithms that are faster and less costly. 00:40:03.050 --> 00:40:08.970 align:middle line:84% So we have Proof of Work is the way people refer to Bitcoin. 00:40:08.970 --> 00:40:12.330 align:middle line:84% We have Byzantine Fault-Tolerant, BFT, 00:40:12.330 --> 00:40:16.450 align:middle line:84% algorithms that can also reach consensus, 00:40:16.450 --> 00:40:20.050 align:middle line:84% even if there are adversarial nodes 00:40:20.050 --> 00:40:23.730 align:middle line:84% or if nodes drop from the network. 00:40:23.730 --> 00:40:27.970 align:middle line:84% And note, nefarious and faulty computers 00:40:27.970 --> 00:40:30.770 align:middle line:84% are being used synonymously here. 00:40:30.770 --> 00:40:34.410 align:middle line:84% The spirit of this is parallel computing, 00:40:34.410 --> 00:40:36.870 align:middle line:84% where you have multiple computers running, 00:40:36.870 --> 00:40:39.650 align:middle line:84% but some of them could malfunction. 00:40:39.650 --> 00:40:42.210 align:middle line:84% So how many computers do you need? 00:40:42.210 --> 00:40:47.370 align:middle line:84% If you're willing to say what fraction of them can fail, 00:40:47.370 --> 00:40:54.200 align:middle line:84% then you need, in this case, for the practical Byzantine 00:40:54.200 --> 00:40:58.120 align:middle line:84% Fault-Tolerant algorithms, you need 00:40:58.120 --> 00:41:02.560 align:middle line:84% the number of failing nodes times 3 plus 1 replicates 00:41:02.560 --> 00:41:06.640 align:middle line:84% to actually know what the truth of the outcome 00:41:06.640 --> 00:41:12.000 align:middle line:84% is by comparing the array of answers. 00:41:12.000 --> 00:41:17.740 align:middle line:84% This algorithm also chooses a leader in a round-robin fashion. 00:41:17.740 --> 00:41:21.300 align:middle line:84% So you have of chosen one who takes the lead, 00:41:21.300 --> 00:41:24.400 align:middle line:84% but it'll be a different person next time around. 00:41:24.400 --> 00:41:27.940 align:middle line:84% And those guys are chosen from a membership list. 00:41:27.940 --> 00:41:31.280 align:middle line:84% So this could be more of a closed rather than open, 00:41:31.280 --> 00:41:34.160 align:middle line:90% public validation. 00:41:34.160 --> 00:41:37.000 align:middle line:84% You could use it within a company, for example. 00:41:37.000 --> 00:41:41.000 align:middle line:84% An extreme version-- I don't think it's in the slides-- 00:41:41.000 --> 00:41:43.220 align:middle line:90% I find amusing. 00:41:43.220 --> 00:41:45.920 align:middle line:90% It's called proof of authority. 00:41:45.920 --> 00:41:49.520 align:middle line:84% So there's one guy approving everything. 00:41:49.520 --> 00:41:50.860 align:middle line:90% Could be a central bank. 00:41:50.860 --> 00:41:53.520 align:middle line:90% 00:41:53.520 --> 00:41:59.120 align:middle line:84% And so whether or not validation is really time-consuming 00:41:59.120 --> 00:42:03.160 align:middle line:84% and a barrier really depends on the particular validation 00:42:03.160 --> 00:42:05.360 align:middle line:90% algorithm that you're using. 00:42:05.360 --> 00:42:09.040 align:middle line:84% Proof of Stake is another one where the validators 00:42:09.040 --> 00:42:11.720 align:middle line:90% are chosen at random. 00:42:11.720 --> 00:42:14.200 align:middle line:84% And then that's followed by voting. 00:42:14.200 --> 00:42:17.720 align:middle line:84% But if you hold more coins, you have a bigger stake 00:42:17.720 --> 00:42:21.480 align:middle line:84% in the outcome, so you get a bigger vote. 00:42:21.480 --> 00:42:24.400 align:middle line:84% And finally, another one is the one 00:42:24.400 --> 00:42:28.460 align:middle line:84% developed by Ripple and Stellar, Federated Byzantine Agreement. 00:42:28.460 --> 00:42:29.860 align:middle line:84% They used to be the same company. 00:42:29.860 --> 00:42:32.060 align:middle line:90% They kind of split up. 00:42:32.060 --> 00:42:33.460 align:middle line:90% One is not for profit. 00:42:33.460 --> 00:42:36.960 align:middle line:90% The other is profit-oriented. 00:42:36.960 --> 00:42:40.480 align:middle line:84% Mazieres worked for Stellar at Stanford. 00:42:40.480 --> 00:42:43.880 align:middle line:84% He created this Federated Byzantine Agreement. 00:42:43.880 --> 00:42:46.990 align:middle line:84% So this is interesting in terms of trust. 00:42:46.990 --> 00:42:52.530 align:middle line:84% Each node decides lists the other nodes that it trusts, 00:42:52.530 --> 00:42:55.070 align:middle line:90% not necessarily all of them-- 00:42:55.070 --> 00:42:59.020 align:middle line:84% the neighbors, business associates, other companies, 00:42:59.020 --> 00:43:00.310 align:middle line:90% et cetera. 00:43:00.310 --> 00:43:04.310 align:middle line:84% And that's called, for that node, a quorum slice. 00:43:04.310 --> 00:43:07.810 align:middle line:84% And the overall quorum, which means you can go ahead, 00:43:07.810 --> 00:43:12.830 align:middle line:84% it's official has to do with the way these slices overlap. 00:43:12.830 --> 00:43:15.430 align:middle line:84% So if there's not much trust in the system, 00:43:15.430 --> 00:43:18.830 align:middle line:84% then this algorithm actually doesn't execute very much. 00:43:18.830 --> 00:43:20.810 align:middle line:90% But it can be very powerful. 00:43:20.810 --> 00:43:22.590 align:middle line:84% So yeah, the whole goal here is to be 00:43:22.590 --> 00:43:27.070 align:middle line:84% able to execute stuff quickly for large-scale problems 00:43:27.070 --> 00:43:33.670 align:middle line:84% where there is a lack of trust in the outcome. 00:43:33.670 --> 00:43:39.790 align:middle line:84% Now, I must say, editorialize a bit-- 00:43:39.790 --> 00:43:42.950 align:middle line:84% and this is a preview of coming attractions-- 00:43:42.950 --> 00:43:45.350 align:middle line:84% the very first thing that economists 00:43:45.350 --> 00:43:49.030 align:middle line:84% got interested in with respect to Bitcoin 00:43:49.030 --> 00:43:54.390 align:middle line:84% was whether Satoshi's algorithm was really 00:43:54.390 --> 00:43:59.870 align:middle line:84% going to constitute a Nash equilibrium. 00:43:59.870 --> 00:44:06.510 align:middle line:84% And what I mean by that is the number of miners 00:44:06.510 --> 00:44:12.430 align:middle line:84% has often been very few, very, very concentrated. 00:44:12.430 --> 00:44:16.890 align:middle line:84% Not only that, they tend to do-- they handle the risk. 00:44:16.890 --> 00:44:20.790 align:middle line:84% Only one wins right and gets more Bitcoin. 00:44:20.790 --> 00:44:24.650 align:middle line:84% So they've entered into syndicates that pool the risk, 00:44:24.650 --> 00:44:28.510 align:middle line:90% so they can share the rewards. 00:44:28.510 --> 00:44:32.230 align:middle line:84% But like Adam Smith said, when two or more 00:44:32.230 --> 00:44:38.230 align:middle line:84% gather together, beware of the outcome. 00:44:38.230 --> 00:44:42.100 align:middle line:84% So I'm just picking up a bit on this tension. 00:44:42.100 --> 00:44:45.220 align:middle line:84% Economists naturally got involved 00:44:45.220 --> 00:44:51.180 align:middle line:84% in the incentives associated with the validation algorithm, 00:44:51.180 --> 00:44:53.640 align:middle line:84% not necessarily to just critique it, 00:44:53.640 --> 00:44:58.980 align:middle line:84% but potentially to make it more robust. 00:44:58.980 --> 00:45:01.340 align:middle line:84% I mean, that said, to my knowledge, 00:45:01.340 --> 00:45:09.380 align:middle line:84% the Bitcoin algorithm has never failed, even though-- 00:45:09.380 --> 00:45:14.700 align:middle line:90% well, let me take that back. 00:45:14.700 --> 00:45:16.940 align:middle line:90% None of this is on the slides. 00:45:16.940 --> 00:45:23.360 align:middle line:84% There is this notion that you can prioritize validation. 00:45:23.360 --> 00:45:27.860 align:middle line:90% 00:45:27.860 --> 00:45:34.780 align:middle line:84% Pay value to a validator to prioritize the block 00:45:34.780 --> 00:45:38.380 align:middle line:90% that you're submitting. 00:45:38.380 --> 00:45:44.220 align:middle line:84% And again, you could imagine that might not be the best idea. 00:45:44.220 --> 00:45:49.620 align:middle line:90% It's like bribing a validator. 00:45:49.620 --> 00:45:51.780 align:middle line:90% But so on it goes. 00:45:51.780 --> 00:45:53.700 align:middle line:84% So let's just think about a little more 00:45:53.700 --> 00:45:58.500 align:middle line:84% formally the incentives to follow an algorithm, 00:45:58.500 --> 00:46:02.700 align:middle line:84% combining the incentives of mechanism design and game 00:46:02.700 --> 00:46:07.432 align:middle line:84% theory in the context of implementing an algorithm. 00:46:07.432 --> 00:46:09.140 align:middle line:84% And we're going to do this in the context 00:46:09.140 --> 00:46:12.180 align:middle line:84% of the Byzantine Generals Problem. 00:46:12.180 --> 00:46:15.300 align:middle line:90% So this is overview slide. 00:46:15.300 --> 00:46:17.380 align:middle line:90% This is a classic problem. 00:46:17.380 --> 00:46:20.020 align:middle line:84% I don't know why it's called Byzantine, 00:46:20.020 --> 00:46:23.700 align:middle line:84% but that's the reference to it-- coordinating a successful attack 00:46:23.700 --> 00:46:24.640 align:middle line:90% on an enemy. 00:46:24.640 --> 00:46:27.200 align:middle line:84% The enemy may or may not be prepared. 00:46:27.200 --> 00:46:31.980 align:middle line:84% A coordinated attack will be successful if it is coordinated 00:46:31.980 --> 00:46:36.980 align:middle line:84% and both generals are attacking, and if the enemy is unprepared. 00:46:36.980 --> 00:46:42.330 align:middle line:84% But the attack fails if only one general is doing the attacking. 00:46:42.330 --> 00:46:47.130 align:middle line:84% And it requires, for success, both generals to attack. 00:46:47.130 --> 00:46:51.090 align:middle line:84% One is better informed than the other, so the first general 00:46:51.090 --> 00:46:54.890 align:middle line:84% can send messages to the second about what 00:46:54.890 --> 00:46:58.370 align:middle line:84% he knows about the outcome, the likelihood 00:46:58.370 --> 00:47:00.210 align:middle line:90% that the enemy is prepared. 00:47:00.210 --> 00:47:01.290 align:middle line:90% But here's the catch. 00:47:01.290 --> 00:47:03.930 align:middle line:90% These messages are noisy. 00:47:03.930 --> 00:47:07.250 align:middle line:84% They don't arrive with probability 1. 00:47:07.250 --> 00:47:12.730 align:middle line:84% Rubenstein has an equally famous article called "The Email 00:47:12.730 --> 00:47:18.910 align:middle line:84% Problem," which is closely related. 00:47:18.910 --> 00:47:21.570 align:middle line:90% So Morris and Shin-- 00:47:21.570 --> 00:47:23.770 align:middle line:84% and I'll show you this in the slides-- 00:47:23.770 --> 00:47:27.090 align:middle line:84% show that the strategic maximizing behavior 00:47:27.090 --> 00:47:31.210 align:middle line:84% in an explicit information game without commitment 00:47:31.210 --> 00:47:37.560 align:middle line:84% is inconsistent with the naturally prescribed protocol. 00:47:37.560 --> 00:47:40.440 align:middle line:84% And I'll go through that protocol. 00:47:40.440 --> 00:47:45.960 align:middle line:84% But there is an alternative protocol with commitment-- 00:47:45.960 --> 00:47:47.840 align:middle line:84% in some sense, this slide is premature 00:47:47.840 --> 00:47:50.480 align:middle line:84% because I haven't laid out all the notation-- 00:47:50.480 --> 00:47:53.640 align:middle line:84% prevents the second general from trying 00:47:53.640 --> 00:47:56.480 align:middle line:90% to confirm an incoming message. 00:47:56.480 --> 00:47:59.640 align:middle line:84% So the message from the first to the second did arrive. 00:47:59.640 --> 00:48:01.220 align:middle line:90% The enemy is unprepared. 00:48:01.220 --> 00:48:03.560 align:middle line:90% The attack can be successful. 00:48:03.560 --> 00:48:07.160 align:middle line:84% But to validate the message, the second general 00:48:07.160 --> 00:48:10.180 align:middle line:84% is supposed to send a return message back. 00:48:10.180 --> 00:48:12.300 align:middle line:84% So the first general knows the second one got it, 00:48:12.300 --> 00:48:14.620 align:middle line:84% and they can coordinate on the attack. 00:48:14.620 --> 00:48:16.280 align:middle line:90% It's very intuitive. 00:48:16.280 --> 00:48:20.560 align:middle line:84% The counterintuitive-- the twin problem 00:48:20.560 --> 00:48:25.880 align:middle line:84% here is going to be that the intuitive message-and-action 00:48:25.880 --> 00:48:32.640 align:middle line:84% protocol is not consistent with rational maximizing behavior 00:48:32.640 --> 00:48:34.480 align:middle line:90% on the part of the generals. 00:48:34.480 --> 00:48:38.160 align:middle line:84% And equally counterintuitive, you 00:48:38.160 --> 00:48:41.080 align:middle line:84% want to shut down some of the messages 00:48:41.080 --> 00:48:44.040 align:middle line:84% in order to get something that works almost all 00:48:44.040 --> 00:48:52.000 align:middle line:84% the time and works well, namely this confirmation message. 00:48:52.000 --> 00:48:56.200 align:middle line:84% Imagine you're two divisions of an army, 00:48:56.200 --> 00:48:57.860 align:middle line:90% each commanded by a general. 00:48:57.860 --> 00:49:01.120 align:middle line:84% They're on these hilltops, looking into the valley. 00:49:01.120 --> 00:49:03.560 align:middle line:84% And the enemy is below in the valley. 00:49:03.560 --> 00:49:05.560 align:middle line:84% The commanding general of the first division 00:49:05.560 --> 00:49:08.520 align:middle line:84% has a highly accurate intelligence report 00:49:08.520 --> 00:49:12.300 align:middle line:84% informing him of the state of the readiness of the enemy. 00:49:12.300 --> 00:49:14.680 align:middle line:84% It's clear that if the enemy is unprepared 00:49:14.680 --> 00:49:18.800 align:middle line:84% and both divisions attack at dawn, they will win the battle. 00:49:18.800 --> 00:49:23.320 align:middle line:84% But if the enemy is prepared or only one general attacks, 00:49:23.320 --> 00:49:25.720 align:middle line:90% the venture will fail. 00:49:25.720 --> 00:49:27.480 align:middle line:84% First-division general is informed 00:49:27.480 --> 00:49:29.320 align:middle line:90% the enemy is unprepared. 00:49:29.320 --> 00:49:32.910 align:middle line:84% If that happens, he has a signal indicating 00:49:32.910 --> 00:49:35.550 align:middle line:84% it's very likely the enemy is unprepared. 00:49:35.550 --> 00:49:39.710 align:middle line:84% He will want to try to coordinate a successful attack. 00:49:39.710 --> 00:49:41.750 align:middle line:84% But these generals can only communicate 00:49:41.750 --> 00:49:47.410 align:middle line:84% by messengers in this picturesque paragraph here. 00:49:47.410 --> 00:49:51.470 align:middle line:84% And unfortunately, the messenger may get lost or, worse yet, 00:49:51.470 --> 00:49:54.510 align:middle line:84% be captured by the enemy, meaning 00:49:54.510 --> 00:49:56.110 align:middle line:90% the message does not arrive. 00:49:56.110 --> 00:49:58.830 align:middle line:90% 00:49:58.830 --> 00:49:59.330 align:middle line:90% OK. 00:49:59.330 --> 00:50:02.510 align:middle line:84% So suppose delta is this probability 00:50:02.510 --> 00:50:05.750 align:middle line:90% the enemy is prepared. 00:50:05.750 --> 00:50:08.070 align:middle line:84% And 1 minus delta is the probability 00:50:08.070 --> 00:50:11.070 align:middle line:90% the enemy is unprepared. 00:50:11.070 --> 00:50:15.150 align:middle line:84% The first general has this signal. 00:50:15.150 --> 00:50:21.270 align:middle line:84% He knows which event we're in, the delta or the 1-minus-delta 00:50:21.270 --> 00:50:21.770 align:middle line:90% branch. 00:50:21.770 --> 00:50:24.630 align:middle line:84% Now, that doesn't mean that he knows for sure the enemy is 00:50:24.630 --> 00:50:25.370 align:middle line:90% unprepared. 00:50:25.370 --> 00:50:27.750 align:middle line:84% He just, in one case, thinks it's 00:50:27.750 --> 00:50:30.230 align:middle line:90% likely the enemy is unprepared. 00:50:30.230 --> 00:50:35.350 align:middle line:84% And the other case, it's likely the enemy is prepared. 00:50:35.350 --> 00:50:39.950 align:middle line:84% And the first general, knowing which contingency it is, 00:50:39.950 --> 00:50:42.050 align:middle line:90% the second general does not. 00:50:42.050 --> 00:50:46.010 align:middle line:84% And if the first were to send a message to the second one, 00:50:46.010 --> 00:50:48.810 align:middle line:84% that could get lost with probability epsilon. 00:50:48.810 --> 00:50:52.230 align:middle line:84% So we're going to assume the messages are almost surely going 00:50:52.230 --> 00:50:56.010 align:middle line:84% to arrive, but not with probability 1. 00:50:56.010 --> 00:50:58.710 align:middle line:90% The epsilon is a small number. 00:50:58.710 --> 00:51:00.550 align:middle line:90% It's smaller than delta. 00:51:00.550 --> 00:51:03.430 align:middle line:84% And let's assume there's no limit to the number of messages 00:51:03.430 --> 00:51:05.710 align:middle line:90% that can go back and forth. 00:51:05.710 --> 00:51:09.710 align:middle line:84% Although I think it's Borel-Cantelli lemma tells us, 00:51:09.710 --> 00:51:12.550 align:middle line:84% with probability 1, some message is going 00:51:12.550 --> 00:51:15.990 align:middle line:90% to get lost at some point. 00:51:15.990 --> 00:51:19.830 align:middle line:84% So here's the naive message protocol. 00:51:19.830 --> 00:51:24.130 align:middle line:84% General 1 receives a signal, sends the message 00:51:24.130 --> 00:51:26.230 align:middle line:90% if the enemy is unprepared. 00:51:26.230 --> 00:51:30.760 align:middle line:84% General 2 may or may not get the message. 00:51:30.760 --> 00:51:34.380 align:middle line:84% However, if received, the general 2 00:51:34.380 --> 00:51:37.820 align:middle line:84% replies back with a confirmation message. 00:51:37.820 --> 00:51:42.580 align:middle line:84% And so on it goes means that if the confirmation is received, 00:51:42.580 --> 00:51:45.840 align:middle line:84% then the first general sends a message back to say, 00:51:45.840 --> 00:51:50.420 align:middle line:84% I know that you know that we're ready to go. 00:51:50.420 --> 00:51:55.880 align:middle line:84% And that message could get lost, or this could go on for several. 00:51:55.880 --> 00:51:59.020 align:middle line:90% 00:51:59.020 --> 00:52:01.540 align:middle line:90% Iterations, this back and forth. 00:52:01.540 --> 00:52:09.140 align:middle line:84% So Steve and Hyun have a table indexed by n and m, 00:52:09.140 --> 00:52:13.660 align:middle line:84% where n refers to the first general has up to that point 00:52:13.660 --> 00:52:15.200 align:middle line:90% sent n messages. 00:52:15.200 --> 00:52:19.740 align:middle line:84% The second general has sent m messages. 00:52:19.740 --> 00:52:24.340 align:middle line:84% So if the enemy is prepared with probability delta 00:52:24.340 --> 00:52:26.900 align:middle line:84% and the first general knows it, then 00:52:26.900 --> 00:52:31.340 align:middle line:84% under what I was just describing, no message is sent. 00:52:31.340 --> 00:52:33.400 align:middle line:90% There's nothing to coordinate. 00:52:33.400 --> 00:52:36.540 align:middle line:84% We don't want the attack to happen. 00:52:36.540 --> 00:52:39.580 align:middle line:84% So neither is sending a message-- 00:52:39.580 --> 00:52:41.300 align:middle line:90% 0, 0. 00:52:41.300 --> 00:52:43.540 align:middle line:84% But for the rest of these three lines 00:52:43.540 --> 00:52:46.220 align:middle line:84% here, 1 minus delta is the probability 00:52:46.220 --> 00:52:51.460 align:middle line:90% the enemy is not prepared. 00:52:51.460 --> 00:52:53.860 align:middle line:84% And general 1 sends message, but it 00:52:53.860 --> 00:52:59.380 align:middle line:84% could fail to arrive with probability epsilon. 00:52:59.380 --> 00:53:06.040 align:middle line:84% Or it does arrive with probability 1 minus epsilon. 00:53:06.040 --> 00:53:09.900 align:middle line:84% The confirmation message is sent back from 2 to 1. 00:53:09.900 --> 00:53:14.780 align:middle line:84% So in this case, they both sent a message. 00:53:14.780 --> 00:53:18.060 align:middle line:84% And that happens with this probability. 00:53:18.060 --> 00:53:20.040 align:middle line:84% Hopefully, you're getting the idea here. 00:53:20.040 --> 00:53:23.360 align:middle line:84% Now the confirm the confirm message, 00:53:23.360 --> 00:53:25.300 align:middle line:90% but that could get lost. 00:53:25.300 --> 00:53:28.930 align:middle line:84% The 1 minus epsilon squared refers to all the 00:53:28.930 --> 00:53:33.290 align:middle line:84% successfully transmitted and received messages up 00:53:33.290 --> 00:53:35.010 align:middle line:90% to a certain point. 00:53:35.010 --> 00:53:40.690 align:middle line:84% And then the epsilon refers to a potential point of failure. 00:53:40.690 --> 00:53:44.250 align:middle line:84% So let's suppose that attacking when the enemy is prepared 00:53:44.250 --> 00:53:49.970 align:middle line:84% is a disaster, a large negative number, m minus m, 00:53:49.970 --> 00:53:55.010 align:middle line:84% and that they both have a payoff of 0 if they're not attacking. 00:53:55.010 --> 00:54:00.050 align:middle line:84% And they have a payoff of 1 if the attack is successful. 00:54:00.050 --> 00:54:05.030 align:middle line:84% So they are, after all, just brigades in a common army. 00:54:05.030 --> 00:54:08.370 align:middle line:84% And the social objective here is to defeat the enemy. 00:54:08.370 --> 00:54:13.550 align:middle line:84% So they both lose minus m if the attack fails. 00:54:13.550 --> 00:54:16.490 align:middle line:84% For whatever reason, they both lose. 00:54:16.490 --> 00:54:21.130 align:middle line:84% I'll come back to that slight modification momentarily. 00:54:21.130 --> 00:54:24.530 align:middle line:84% So the theorem is if the communication system 00:54:24.530 --> 00:54:30.450 align:middle line:84% is sufficiently reliable, then the optimal action 00:54:30.450 --> 00:54:33.530 align:middle line:84% profile I'm about to tell you has 00:54:33.530 --> 00:54:37.450 align:middle line:84% a coordinated attack happening almost always when the enemy is 00:54:37.450 --> 00:54:38.270 align:middle line:90% unprepared. 00:54:38.270 --> 00:54:43.890 align:middle line:84% So it has very, very good characteristics. 00:54:43.890 --> 00:54:47.650 align:middle line:84% There's a lot of ifs in this statement. 00:54:47.650 --> 00:54:51.690 align:middle line:84% And if the communication means epsilon is small, 00:54:51.690 --> 00:54:57.130 align:middle line:84% and what is this optimal action profile? 00:54:57.130 --> 00:55:01.490 align:middle line:84% So the optimal action profile uses the naive communication 00:55:01.490 --> 00:55:05.890 align:middle line:84% protocol of this back-and-forth messaging system, 00:55:05.890 --> 00:55:09.050 align:middle line:84% would have the first general attacking-- 00:55:09.050 --> 00:55:10.970 align:middle line:90% this is the action-- 00:55:10.970 --> 00:55:13.890 align:middle line:84% whenever the enemy is unprepared, 00:55:13.890 --> 00:55:16.810 align:middle line:84% even if he has not received a confirmation message 00:55:16.810 --> 00:55:19.370 align:middle line:90% from the second general. 00:55:19.370 --> 00:55:23.120 align:middle line:84% And as for the action of the second general, 00:55:23.120 --> 00:55:26.240 align:middle line:84% he attacks, even if he received only one message 00:55:26.240 --> 00:55:28.120 align:middle line:90% from the first general. 00:55:28.120 --> 00:55:30.800 align:middle line:84% He doesn't wait for any reconfirmation 00:55:30.800 --> 00:55:35.960 align:middle line:84% of his own message back to the first one to arrive back to him. 00:55:35.960 --> 00:55:38.360 align:middle line:84% So in this case, the coordinated attack 00:55:38.360 --> 00:55:42.280 align:middle line:84% does occur with overall probability associated 00:55:42.280 --> 00:55:46.840 align:middle line:84% with the enemy being unprepared and that this message 00:55:46.840 --> 00:55:49.220 align:middle line:84% from the first to the second general arrives. 00:55:49.220 --> 00:55:53.440 align:middle line:84% Remember the action of the second general here. 00:55:53.440 --> 00:55:56.800 align:middle line:84% He attacks when he has received the message 00:55:56.800 --> 00:55:59.620 align:middle line:90% from the first-division general. 00:55:59.620 --> 00:56:04.800 align:middle line:84% Even if the first guy is attacking, 00:56:04.800 --> 00:56:09.440 align:middle line:84% the second needs the message from the first one. 00:56:09.440 --> 00:56:16.560 align:middle line:84% So just a footnote, as it were, in Morris and Shin's paper 00:56:16.560 --> 00:56:19.320 align:middle line:90% is a simple proof. 00:56:19.320 --> 00:56:24.430 align:middle line:84% The optimal action protocol is what I read out just now. 00:56:24.430 --> 00:56:28.030 align:middle line:84% And this is a bit tedious, but what the overview of it 00:56:28.030 --> 00:56:32.350 align:middle line:84% is considering two nearby strategies. 00:56:32.350 --> 00:56:34.550 align:middle line:84% One, the first-division general attacks 00:56:34.550 --> 00:56:36.830 align:middle line:84% whenever the enemy is unprepared, 00:56:36.830 --> 00:56:40.870 align:middle line:84% and the second general attacks always. 00:56:40.870 --> 00:56:44.910 align:middle line:84% And these would be the payoffs because the enemy could 00:56:44.910 --> 00:56:47.850 align:middle line:84% be prepared-- in which case, they both suffer minus m. 00:56:47.850 --> 00:56:51.310 align:middle line:84% But by chance, the enemy is not prepared 00:56:51.310 --> 00:56:55.510 align:middle line:84% and they're both attacking, so that's a payoff. 00:56:55.510 --> 00:56:57.750 align:middle line:84% You do a little more algebra on that. 00:56:57.750 --> 00:57:04.710 align:middle line:84% The next line is what we claim, namely the first general attacks 00:57:04.710 --> 00:57:09.210 align:middle line:84% whenever the enemy is prepared, sends a message to the second. 00:57:09.210 --> 00:57:10.870 align:middle line:84% The second-division general attacks 00:57:10.870 --> 00:57:13.830 align:middle line:84% if he has received that one message, 00:57:13.830 --> 00:57:16.090 align:middle line:84% and that has this expected payoff. 00:57:16.090 --> 00:57:19.110 align:middle line:84% The third neighbor on the other side 00:57:19.110 --> 00:57:23.650 align:middle line:84% is each general attacks if he's received at least one message, 00:57:23.650 --> 00:57:25.390 align:middle line:84% which means that the first general has 00:57:25.390 --> 00:57:29.510 align:middle line:84% to get a confirmation back from the second one. 00:57:29.510 --> 00:57:32.150 align:middle line:84% And again, you're just multiplying probabilities 00:57:32.150 --> 00:57:33.170 align:middle line:90% by outcomes. 00:57:33.170 --> 00:57:38.250 align:middle line:84% So I've reconfirmed this umpteen times. 00:57:38.250 --> 00:57:44.030 align:middle line:90% 00:57:44.030 --> 00:57:46.470 align:middle line:90% I'll resist the temptation. 00:57:46.470 --> 00:57:49.910 align:middle line:84% I even wrote out more explicitly the algebra 00:57:49.910 --> 00:57:51.730 align:middle line:90% underlying the third strategy. 00:57:51.730 --> 00:57:56.070 align:middle line:84% So it turns out, when epsilon is small and m is large, 00:57:56.070 --> 00:57:59.370 align:middle line:84% the second strategy dominates the near neighbors, 00:57:59.370 --> 00:58:01.910 align:middle line:84% and it will dominate every other possible strategy 00:58:01.910 --> 00:58:03.370 align:middle line:90% that you could come up with. 00:58:03.370 --> 00:58:05.950 align:middle line:90% 00:58:05.950 --> 00:58:09.870 align:middle line:90% So it gets us what we want. 00:58:09.870 --> 00:58:14.230 align:middle line:84% But the remaining difficulty is this optimal action protocol 00:58:14.230 --> 00:58:17.780 align:middle line:84% is sensitive to strategic concerns. 00:58:17.780 --> 00:58:21.400 align:middle line:84% It works as long as the generals follow it. 00:58:21.400 --> 00:58:23.040 align:middle line:90% Now, you see the spirit of this. 00:58:23.040 --> 00:58:27.180 align:middle line:84% We already went through these validation program protocols 00:58:27.180 --> 00:58:30.560 align:middle line:90% for the blockchains, right? 00:58:30.560 --> 00:58:35.080 align:middle line:84% And it's assumed that people will follow those protocols. 00:58:35.080 --> 00:58:37.940 align:middle line:84% So here, the analogy is the generals 00:58:37.940 --> 00:58:41.700 align:middle line:84% are going to follow this optimal action protocol, maybe. 00:58:41.700 --> 00:58:44.100 align:middle line:90% But would they want to? 00:58:44.100 --> 00:58:47.140 align:middle line:90% Is it in their self-interest? 00:58:47.140 --> 00:58:49.100 align:middle line:90% It's a cute line here. 00:58:49.100 --> 00:58:52.200 align:middle line:84% "Perhaps battle orders instruct them to follow the protocol, 00:58:52.200 --> 00:58:55.420 align:middle line:84% and generals always follow battle orders." 00:58:55.420 --> 00:58:57.940 align:middle line:84% But anyway, suppose the first-division general 00:58:57.940 --> 00:59:01.980 align:middle line:84% knows the enemy is unprepared, sends a message to the second, 00:59:01.980 --> 00:59:04.780 align:middle line:84% but does not receive a confirmation. 00:59:04.780 --> 00:59:07.360 align:middle line:84% Then he believes, with a certain probability, 00:59:07.360 --> 00:59:10.260 align:middle line:84% that his own message never got there. 00:59:10.260 --> 00:59:14.360 align:middle line:84% And since it didn't, under the optimal-action profile, 00:59:14.360 --> 00:59:17.380 align:middle line:84% the second general is not attacking. 00:59:17.380 --> 00:59:20.620 align:middle line:84% Now, where is this number coming from? 00:59:20.620 --> 00:59:24.520 align:middle line:84% So we're going to do a Bayesian thing here. 00:59:24.520 --> 00:59:30.240 align:middle line:84% What is the probability that this message never got there? 00:59:30.240 --> 00:59:31.820 align:middle line:90% But it could have gotten there. 00:59:31.820 --> 00:59:36.060 align:middle line:84% So we do the weighted average-- this probability 00:59:36.060 --> 00:59:38.380 align:middle line:84% that it doesn't get there, again, 00:59:38.380 --> 00:59:41.820 align:middle line:84% repeated in the denominator and the other event 00:59:41.820 --> 00:59:45.500 align:middle line:84% that it did get there, and the second general sent back 00:59:45.500 --> 00:59:46.940 align:middle line:90% a confirmation. 00:59:46.940 --> 00:59:48.820 align:middle line:84% The reason the first one is in the dark 00:59:48.820 --> 00:59:51.380 align:middle line:84% is that he never got confirmation. 00:59:51.380 --> 00:59:55.660 align:middle line:84% So this is the way to assess this probability 00:59:55.660 --> 00:59:59.220 align:middle line:84% that the second general never got the message. 00:59:59.220 --> 01:00:02.780 align:middle line:90% And that's greater than 1/2. 01:00:02.780 --> 01:00:08.660 align:middle line:84% So the point is, thinking about that in his head, 01:00:08.660 --> 01:00:12.300 align:middle line:84% the first general could decide, I'm not going to venture 01:00:12.300 --> 01:00:16.310 align:middle line:84% an attack because with probability greater than 1/2, 01:00:16.310 --> 01:00:18.230 align:middle line:84% the other general is not attacking. 01:00:18.230 --> 01:00:21.330 align:middle line:90% 01:00:21.330 --> 01:00:25.890 align:middle line:84% So then we just formalize the game 01:00:25.890 --> 01:00:29.890 align:middle line:84% with a small modification of the environment. 01:00:29.890 --> 01:00:31.970 align:middle line:90% There's two tables here. 01:00:31.970 --> 01:00:35.410 align:middle line:84% This is the payoff structure if the enemy is prepared. 01:00:35.410 --> 01:00:38.970 align:middle line:84% This is the table structure when the enemy is unprepared-- well, 01:00:38.970 --> 01:00:43.090 align:middle line:84% with these probabilities, delta and 1 minus delta. 01:00:43.090 --> 01:00:44.730 align:middle line:84% And then there's a two-player game 01:00:44.730 --> 01:00:49.310 align:middle line:84% here with two actions each-- to attack or not attack. 01:00:49.310 --> 01:00:51.550 align:middle line:84% If they both attack and the enemy is prepared, 01:00:51.550 --> 01:00:56.330 align:middle line:84% they both get minus m if the enemy is prepared, 01:00:56.330 --> 01:00:59.530 align:middle line:84% or minus m for the general that's attacking 01:00:59.530 --> 01:01:03.410 align:middle line:84% and 0 for the other one that is That's the difference. 01:01:03.410 --> 01:01:06.010 align:middle line:90% Before, they both suffered here. 01:01:06.010 --> 01:01:09.930 align:middle line:84% If you don't attack, you're actually better off with 0 01:01:09.930 --> 01:01:11.490 align:middle line:90% rather than minus m. 01:01:11.490 --> 01:01:15.010 align:middle line:84% Of course, if they don't attack, they both get 0. 01:01:15.010 --> 01:01:18.850 align:middle line:84% That's the case, unlikely, but possible that the enemy is 01:01:18.850 --> 01:01:19.770 align:middle line:90% prepared. 01:01:19.770 --> 01:01:22.110 align:middle line:84% And this is a case that the enemy is unprepared. 01:01:22.110 --> 01:01:25.870 align:middle line:84% So now when they both attack, it's a good thing. 01:01:25.870 --> 01:01:28.610 align:middle line:84% You have these off-diagonal elements, 01:01:28.610 --> 01:01:32.090 align:middle line:84% where one suffers if he attacks and the other one doesn't. 01:01:32.090 --> 01:01:34.710 align:middle line:84% And again, if they both don't attack, 01:01:34.710 --> 01:01:37.470 align:middle line:84% then you get this neutral 0, 0 outcome. 01:01:37.470 --> 01:01:40.930 align:middle line:90% 01:01:40.930 --> 01:01:46.610 align:middle line:84% So in the strategic, meaning they got stuff 01:01:46.610 --> 01:01:50.210 align:middle line:84% going on in their head and deciding whether or not 01:01:50.210 --> 01:01:53.290 align:middle line:84% to do these actions-- in the strategic coordinated attack 01:01:53.290 --> 01:01:57.990 align:middle line:84% problem with the naive communication protocol, 01:01:57.990 --> 01:02:01.130 align:middle line:84% it turns out, both generals never 01:02:01.130 --> 01:02:07.250 align:middle line:84% attack if the communication system is sufficiently reliable. 01:02:07.250 --> 01:02:10.440 align:middle line:90% So this is a disaster. 01:02:10.440 --> 01:02:13.320 align:middle line:84% It is a surprising conclusion if you're not 01:02:13.320 --> 01:02:17.600 align:middle line:84% familiar with global games in the sense 01:02:17.600 --> 01:02:20.020 align:middle line:84% that epsilon can be very, very small. 01:02:20.020 --> 01:02:23.400 align:middle line:84% So almost surely, these messages are arriving. 01:02:23.400 --> 01:02:26.400 align:middle line:84% There's a relatively big gain of coordinating 01:02:26.400 --> 01:02:30.760 align:middle line:84% a successful attack, a small chance that it will go wrong. 01:02:30.760 --> 01:02:33.080 align:middle line:84% And nevertheless, when they're sending these messages 01:02:33.080 --> 01:02:36.480 align:middle line:84% back and forth in thinking about what 01:02:36.480 --> 01:02:39.680 align:middle line:84% is the likelihood of the other player 01:02:39.680 --> 01:02:45.560 align:middle line:84% being in a certain situation or not, the probability-- 01:02:45.560 --> 01:02:49.120 align:middle line:84% well, we'll look at this line here. 01:02:49.120 --> 01:02:54.120 align:middle line:84% Suppose the second general never receives a message. 01:02:54.120 --> 01:03:01.120 align:middle line:84% The second believes that the enemy is prepared, delta. 01:03:01.120 --> 01:03:04.540 align:middle line:84% But it could be the enemy is not prepared. 01:03:04.540 --> 01:03:08.320 align:middle line:84% So the overall probability is delta, the enemy is unprepared. 01:03:08.320 --> 01:03:11.870 align:middle line:84% With 1 minus delta, the enemy is prepared. 01:03:11.870 --> 01:03:14.190 align:middle line:84% And this second general in question 01:03:14.190 --> 01:03:16.110 align:middle line:90% here never got the message. 01:03:16.110 --> 01:03:20.870 align:middle line:84% So this number is, again, greater than 1/2. 01:03:20.870 --> 01:03:25.670 align:middle line:84% So if second general could feel that way 01:03:25.670 --> 01:03:29.270 align:middle line:84% not receiving the message, whatever the first general is 01:03:29.270 --> 01:03:32.310 align:middle line:84% doing, the second guy isn't going to attack. 01:03:32.310 --> 01:03:36.470 align:middle line:84% And then knowing that, the first general likely 01:03:36.470 --> 01:03:38.870 align:middle line:84% would be confused about the reason 01:03:38.870 --> 01:03:44.390 align:middle line:84% he wasn't receiving the message from the second one. 01:03:44.390 --> 01:03:46.310 align:middle line:90% It's the same. 01:03:46.310 --> 01:03:48.730 align:middle line:84% The algebra changes to protect the innocent, 01:03:48.730 --> 01:03:51.510 align:middle line:84% but it's the same message every time here. 01:03:51.510 --> 01:03:54.470 align:middle line:84% The first general in this case believes 01:03:54.470 --> 01:03:58.430 align:middle line:84% that the enemy is unprepared, and the message 01:03:58.430 --> 01:04:01.850 align:middle line:84% could be lost, versus the enemy is unprepared. 01:04:01.850 --> 01:04:05.630 align:middle line:84% The message was received, but he didn't get the confirmation. 01:04:05.630 --> 01:04:08.450 align:middle line:84% And that's a number greater than 1/2. 01:04:08.450 --> 01:04:10.230 align:middle line:84% Well, it turns out, you can just keep 01:04:10.230 --> 01:04:16.150 align:middle line:84% going, which is my reference to global games. 01:04:16.150 --> 01:04:20.510 align:middle line:84% And that's no matter how many iterations you do. 01:04:20.510 --> 01:04:21.650 align:middle line:90% And again, the irony. 01:04:21.650 --> 01:04:24.170 align:middle line:84% No matter how many messages are exchanged, 01:04:24.170 --> 01:04:29.470 align:middle line:84% which seems to confirm that the enemy is unprepared, 01:04:29.470 --> 01:04:34.870 align:middle line:84% it's always a probability greater than 1/2 that something 01:04:34.870 --> 01:04:39.670 align:middle line:84% isn't quite right, and you don't execute the attack. 01:04:39.670 --> 01:04:45.070 align:middle line:84% STUDENT: So if you get back to validation questions 01:04:45.070 --> 01:04:47.990 align:middle line:84% here, if the second general didn't 01:04:47.990 --> 01:04:51.773 align:middle line:84% have a messaging technology and that was common knowledge, 01:04:51.773 --> 01:04:53.190 align:middle line:84% then you wouldn't have that issue? 01:04:53.190 --> 01:04:55.482 align:middle line:84% ROBERT M. TOWNSEND: That's the conclusion of the paper. 01:04:55.482 --> 01:04:56.790 align:middle line:90% STUDENT: Right. 01:04:56.790 --> 01:05:03.023 align:middle line:84% So for validation, it means you don't want to validate too much. 01:05:03.023 --> 01:05:04.690 align:middle line:84% ROBERT M. TOWNSEND: In this case, right. 01:05:04.690 --> 01:05:08.660 align:middle line:90% 01:05:08.660 --> 01:05:11.780 align:middle line:84% Either, you don't give the guy the ability 01:05:11.780 --> 01:05:17.220 align:middle line:84% to respond, like, a one-way microphone or something, 01:05:17.220 --> 01:05:22.340 align:middle line:84% or if he has it, then you need some other commitment 01:05:22.340 --> 01:05:27.820 align:middle line:84% to prevent him from sending a validation confirmation 01:05:27.820 --> 01:05:31.540 align:middle line:84% message because if the first general gets it in his head 01:05:31.540 --> 01:05:36.300 align:middle line:84% that despite the agreement, the guy is going to play it safe 01:05:36.300 --> 01:05:40.180 align:middle line:84% and send me a message, then he goes through this deep think. 01:05:40.180 --> 01:05:43.020 align:middle line:90% 01:05:43.020 --> 01:05:47.340 align:middle line:84% So with commitment to not respond to a message 01:05:47.340 --> 01:05:49.340 align:middle line:84% or, better yet, in the technology 01:05:49.340 --> 01:05:51.880 align:middle line:84% to never get the message, that worked. 01:05:51.880 --> 01:05:53.020 align:middle line:90% That does. 01:05:53.020 --> 01:05:56.700 align:middle line:84% But anyway, the main message here 01:05:56.700 --> 01:06:01.700 align:middle line:84% is we need to consider the incentives to follow a protocol. 01:06:01.700 --> 01:06:03.940 align:middle line:84% You can't just announce a protocol 01:06:03.940 --> 01:06:07.700 align:middle line:84% with good characteristics and necessarily assume 01:06:07.700 --> 01:06:12.740 align:middle line:84% that the validators are going to follow it, which, 01:06:12.740 --> 01:06:18.220 align:middle line:84% again, is economists' first reaction to the Bitcoin 01:06:18.220 --> 01:06:20.100 align:middle line:90% validation. 01:06:20.100 --> 01:06:22.320 align:middle line:84% Well, maybe the miners will do something else. 01:06:22.320 --> 01:06:23.700 align:middle line:90% Maybe they'll collude. 01:06:23.700 --> 01:06:28.940 align:middle line:84% Other things other than following the prescribed Satoshi 01:06:28.940 --> 01:06:31.540 align:middle line:84% protocol could potentially happen. 01:06:31.540 --> 01:06:35.860 align:middle line:84% And we either have to rule it out or criticize the algorithm. 01:06:35.860 --> 01:06:38.900 align:middle line:90% 01:06:38.900 --> 01:06:44.820 align:middle line:84% In mechanism design language, we have the information protocols. 01:06:44.820 --> 01:06:47.640 align:middle line:84% Simple or otherwise is one aspect to it. 01:06:47.640 --> 01:06:51.640 align:middle line:84% We have the mechanism design aspect, 01:06:51.640 --> 01:06:55.820 align:middle line:84% which is relying on messages to implement allocation rules. 01:06:55.820 --> 01:07:01.300 align:middle line:84% That combines information design with mechanism design 01:07:01.300 --> 01:07:04.650 align:middle line:84% and, in this case, both are being used. 01:07:04.650 --> 01:07:07.190 align:middle line:90% So what can I say? 01:07:07.190 --> 01:07:12.890 align:middle line:84% So I think this difference in the word "trust" 01:07:12.890 --> 01:07:18.490 align:middle line:84% across economics versus across computer science is an important 01:07:18.490 --> 01:07:20.370 align:middle line:90% substantive difference. 01:07:20.370 --> 01:07:23.010 align:middle line:84% That doesn't mean that one side is going 01:07:23.010 --> 01:07:24.990 align:middle line:90% to be convinced by the other. 01:07:24.990 --> 01:07:28.250 align:middle line:90% 01:07:28.250 --> 01:07:32.090 align:middle line:84% But when you're thinking about implementing mechanisms 01:07:32.090 --> 01:07:35.230 align:middle line:84% on the blockchain, it really matters. 01:07:35.230 --> 01:07:38.330 align:middle line:90% 01:07:38.330 --> 01:07:42.530 align:middle line:84% On the one hand, you could say the sacred sauce 01:07:42.530 --> 01:07:46.170 align:middle line:84% of the blockchain is that we no longer rely 01:07:46.170 --> 01:07:52.290 align:middle line:84% on trusted third parties to do the validation. 01:07:52.290 --> 01:07:55.090 align:middle line:84% In the case of Bitcoin as a community currency, not 01:07:55.090 --> 01:07:57.770 align:middle line:84% the central bank to provide the currency, 01:07:57.770 --> 01:08:02.530 align:middle line:84% we're going to do it in this larger community 01:08:02.530 --> 01:08:07.890 align:middle line:90% of mostly well-intended people. 01:08:07.890 --> 01:08:11.130 align:middle line:90% So when people refer-- 01:08:11.130 --> 01:08:13.970 align:middle line:84% and this is a substantive difference. 01:08:13.970 --> 01:08:17.450 align:middle line:84% When they say blockchain, many people 01:08:17.450 --> 01:08:21.410 align:middle line:84% assume that comes with the validation algorithm, 01:08:21.410 --> 01:08:24.130 align:middle line:90% that that has to be used. 01:08:24.130 --> 01:08:27.010 align:middle line:84% And if it's not being used, and it's not really 01:08:27.010 --> 01:08:33.170 align:middle line:84% a decentralized system, then it's not really the blockchain. 01:08:33.170 --> 01:08:38.529 align:middle line:84% My point of view is let's break these things down into pieces. 01:08:38.529 --> 01:08:43.810 align:middle line:84% And the smart-contract part can utilize tools of computer 01:08:43.810 --> 01:08:46.980 align:middle line:90% science, especially if you-- 01:08:46.980 --> 01:08:52.050 align:middle line:84% even if you drop the validation part for how the code works, 01:08:52.050 --> 01:08:55.930 align:middle line:84% you still have incentives within layer 2 01:08:55.930 --> 01:08:59.500 align:middle line:84% that are enhanced by the tools of computer science. 01:08:59.500 --> 01:09:03.800 align:middle line:84% So we should understand all these components in isolation 01:09:03.800 --> 01:09:09.319 align:middle line:84% in terms of what they can do, understand distributed ledgers, 01:09:09.319 --> 01:09:16.279 align:middle line:84% understand smart contracts, understand encryption, and think 01:09:16.279 --> 01:09:20.840 align:middle line:84% about what we want as a matter of choice. 01:09:20.840 --> 01:09:25.600 align:middle line:84% But likewise, just speaking personally, 01:09:25.600 --> 01:09:28.080 align:middle line:84% I'm fine with the notion that you can 01:09:28.080 --> 01:09:30.220 align:middle line:90% rely on trusted third parties. 01:09:30.220 --> 01:09:35.700 align:middle line:84% It's up to the participants to decide what to trust or not. 01:09:35.700 --> 01:09:42.560 align:middle line:84% Where's all this data that's being generated? 01:09:42.560 --> 01:09:45.479 align:middle line:90% It's Amazon, Google. 01:09:45.479 --> 01:09:49.000 align:middle line:84% And it's not like this vast competitive industry of data 01:09:49.000 --> 01:09:50.700 align:middle line:90% storage is going on out there. 01:09:50.700 --> 01:09:54.520 align:middle line:90% So most people are fine with it. 01:09:54.520 --> 01:09:58.240 align:middle line:84% There's usually an element of trust somewhere in the system. 01:09:58.240 --> 01:10:01.920 align:middle line:84% It's not like it's terrible if that remains. 01:10:01.920 --> 01:10:07.280 align:middle line:84% It's more like delineating where it is and deciding if it's OK 01:10:07.280 --> 01:10:09.340 align:middle line:84% or if there's a way to do better. 01:10:09.340 --> 01:10:13.670 align:middle line:90% 01:10:13.670 --> 01:10:17.120 align:middle line:84% So next time, we'll go through the cryptography, 01:10:17.120 --> 01:10:24.880 align:middle line:84% encrypting these messages and in the context of mechanism design. 01:10:24.880 --> 01:10:28.560 align:middle line:84% And I'll try to strike a balance between providing you 01:10:28.560 --> 01:10:35.680 align:middle line:84% with specific concrete examples of encryption methods. 01:10:35.680 --> 01:10:39.800 align:middle line:84% And at the same time, I really can't cover the whole-- 01:10:39.800 --> 01:10:41.900 align:middle line:84% or even understand the whole field. 01:10:41.900 --> 01:10:46.120 align:middle line:84% So I'll give you some references at the end of the lecture 01:10:46.120 --> 01:10:47.540 align:middle line:90% next time for further reading. 01:10:47.540 --> 01:10:50.470 align:middle line:90% OK, thank you so much. 01:10:50.470 --> 01:10:56.000 align:middle line:90%