WEBVTT 00:00:00.000 --> 00:00:02.425 align:middle line:90% [SQUEAKING] 00:00:02.425 --> 00:00:04.365 align:middle line:90% [RUSTLING] 00:00:04.365 --> 00:00:07.760 align:middle line:90% [CLICKING] 00:00:07.760 --> 00:00:12.378 align:middle line:90% 00:00:12.378 --> 00:00:13.920 align:middle line:84% YAEL KALAI: Before we go to the test, 00:00:13.920 --> 00:00:18.720 align:middle line:84% I just want to point out this PCP is nonadaptive. 00:00:18.720 --> 00:00:21.660 align:middle line:84% What are the queries of the verifier? 00:00:21.660 --> 00:00:28.170 align:middle line:84% He behaves like a verifier of the GKR or, in other words, 00:00:28.170 --> 00:00:29.670 align:middle line:90% a verifier for sum-check. 00:00:29.670 --> 00:00:32.280 align:middle line:84% And sum-check is a public coin protocol. 00:00:32.280 --> 00:00:34.500 align:middle line:84% So the messages don't depend on anything. 00:00:34.500 --> 00:00:38.220 align:middle line:84% You just choose some randomness, and that defines the queries. 00:00:38.220 --> 00:00:42.950 align:middle line:84% So it is a nonadaptive-- the questions you ask 00:00:42.950 --> 00:00:45.570 align:middle line:84% don't depend on the answers you get. 00:00:45.570 --> 00:00:48.450 align:middle line:84% This is because the sum-check is public coin 00:00:48.450 --> 00:00:50.460 align:middle line:90% so that we do get nonadaptive. 00:00:50.460 --> 00:00:52.670 align:middle line:84% And as we said, though, we do need 00:00:52.670 --> 00:00:56.390 align:middle line:84% to check that the witness sitting in the PCP 00:00:56.390 --> 00:00:57.750 align:middle line:90% is of low degree. 00:00:57.750 --> 00:00:59.853 align:middle line:90% So let me just do that quickly. 00:00:59.853 --> 00:01:02.950 align:middle line:90% 00:01:02.950 --> 00:01:06.440 align:middle line:90% So how do we check it? 00:01:06.440 --> 00:01:11.350 align:middle line:84% So the prover, what he does, there's the H to the m. 00:01:11.350 --> 00:01:15.226 align:middle line:84% He should put some witness here, 0, 1, 0, 2-- 00:01:15.226 --> 00:01:19.540 align:middle line:90% w0, w1, w2, and so on. 00:01:19.540 --> 00:01:23.180 align:middle line:90% So all the up to wm-- 00:01:23.180 --> 00:01:27.130 align:middle line:90% m is up to-- 00:01:27.130 --> 00:01:29.270 align:middle line:84% let me call the number of bits in the witness s. 00:01:29.270 --> 00:01:34.810 align:middle line:84% We'll just have a lot of 0's appendage just so-- 00:01:34.810 --> 00:01:38.300 align:middle line:84% because m mistaken to be log s, so not to confuse. 00:01:38.300 --> 00:01:41.720 align:middle line:84% And now he's giving kind of he takes the extension. 00:01:41.720 --> 00:01:43.990 align:middle line:90% So this is f to the m. 00:01:43.990 --> 00:01:45.678 align:middle line:90% And this should be-- 00:01:45.678 --> 00:01:46.970 align:middle line:90% this is just what it should be. 00:01:46.970 --> 00:01:48.178 align:middle line:90% This is what the prover does. 00:01:48.178 --> 00:01:50.590 align:middle line:84% This is the low-degree extension of H 00:01:50.590 --> 00:01:56.320 align:middle line:84% to the m, which should be of degree H minus 1 00:01:56.320 --> 00:01:57.636 align:middle line:90% in each coordinate. 00:01:57.636 --> 00:02:04.180 align:middle line:90% 00:02:04.180 --> 00:02:06.040 align:middle line:90% And I want to check that. 00:02:06.040 --> 00:02:08.539 align:middle line:90% Now here's the sad truth. 00:02:08.539 --> 00:02:10.220 align:middle line:90% I can't actually check this. 00:02:10.220 --> 00:02:13.900 align:middle line:84% This thing is low degree with degree H 00:02:13.900 --> 00:02:15.140 align:middle line:90% minus 1 in each coordinate. 00:02:15.140 --> 00:02:19.420 align:middle line:84% I can't check it because maybe it is, but here, he 00:02:19.420 --> 00:02:21.610 align:middle line:90% put something bad. 00:02:21.610 --> 00:02:22.910 align:middle line:90% I can't check it. 00:02:22.910 --> 00:02:24.400 align:middle line:90% I mean, I'm not good. 00:02:24.400 --> 00:02:27.650 align:middle line:90% The verifier has small queries. 00:02:27.650 --> 00:02:29.840 align:middle line:84% So he can't actually check that this is low degree. 00:02:29.840 --> 00:02:32.060 align:middle line:90% That's impossible. 00:02:32.060 --> 00:02:33.200 align:middle line:90% So what does he do? 00:02:33.200 --> 00:02:34.670 align:middle line:90% What does he do instead? 00:02:34.670 --> 00:02:38.680 align:middle line:84% He's going to check that it's close to low degree. 00:02:38.680 --> 00:02:40.100 align:middle line:90% So here's the guarantee. 00:02:40.100 --> 00:02:43.960 align:middle line:84% The guarantee we want is to say that I'm going to check. 00:02:43.960 --> 00:02:45.430 align:middle line:90% I'm going to do a test. 00:02:45.430 --> 00:02:48.190 align:middle line:84% And if the test passes the guarantee 00:02:48.190 --> 00:02:51.950 align:middle line:84% I want, not that this is low degree, but it's close. 00:02:51.950 --> 00:02:55.200 align:middle line:84% There's another polynomial of low degree 00:02:55.200 --> 00:02:59.770 align:middle line:84% that agrees with this on most points. 00:02:59.770 --> 00:03:08.610 align:middle line:84% So we have a low degree test is a check. 00:03:08.610 --> 00:03:10.900 align:middle line:84% At the end of the check, what the verifier-- 00:03:10.900 --> 00:03:15.840 align:middle line:84% the guarantee the verifier has is the guarantee we want is that 00:03:15.840 --> 00:03:28.800 align:middle line:84% with high probability, there exists a low degree polynomial, 00:03:28.800 --> 00:03:32.880 align:middle line:90% W tilde such that-- 00:03:32.880 --> 00:03:45.300 align:middle line:84% W tilde such that for most z or the probability of a random z 00:03:45.300 --> 00:03:57.550 align:middle line:84% that Wz equals is greater than 1 minus epsilon for some epsilon. 00:03:57.550 --> 00:03:59.580 align:middle line:84% That's what we want to check for most. 00:03:59.580 --> 00:04:04.260 align:middle line:84% Now if we got this check, if we succeeded in this, 00:04:04.260 --> 00:04:09.430 align:middle line:84% if we succeeded in this check, then now what we know is that-- 00:04:09.430 --> 00:04:13.350 align:middle line:84% let's think in our head that this is-- he put this up there. 00:04:13.350 --> 00:04:15.100 align:middle line:90% Yeah, he put this. 00:04:15.100 --> 00:04:16.360 align:middle line:90% But they're so close. 00:04:16.360 --> 00:04:18.279 align:middle line:84% Let's pretend he put this up there. 00:04:18.279 --> 00:04:20.430 align:middle line:84% Anyway, the probability that we'll ask 00:04:20.430 --> 00:04:24.000 align:middle line:84% and a z for which they're different is only epsilon. 00:04:24.000 --> 00:04:25.660 align:middle line:90% Mostly, they agree. 00:04:25.660 --> 00:04:32.400 align:middle line:84% So all we need is to verify that there's-- 00:04:32.400 --> 00:04:37.800 align:middle line:84% because we check V0 and a random z at the end, most likely, 00:04:37.800 --> 00:04:40.290 align:middle line:84% it's the z's for which they agree. 00:04:40.290 --> 00:04:43.270 align:middle line:84% So all we need to check is that they agree almost everywhere. 00:04:43.270 --> 00:04:44.970 align:middle line:84% The fact that there are few locations 00:04:44.970 --> 00:04:46.060 align:middle line:90% that they don't agree-- 00:04:46.060 --> 00:04:47.310 align:middle line:84% A, there's nothing I can do about it 00:04:47.310 --> 00:04:49.727 align:middle line:84% because if I don't query them, I don't know if they exist. 00:04:49.727 --> 00:04:52.050 align:middle line:84% I don't know what's sitting there. 00:04:52.050 --> 00:04:53.930 align:middle line:84% But, actually, I don't care that much 00:04:53.930 --> 00:04:55.180 align:middle line:90% because they're not going to-- 00:04:55.180 --> 00:04:58.670 align:middle line:84% I'm not going to query them anyway with high probability. 00:04:58.670 --> 00:05:01.070 align:middle line:84% So really, all I want to say is that there 00:05:01.070 --> 00:05:03.650 align:middle line:84% exists a w tilde that is low degree 00:05:03.650 --> 00:05:06.080 align:middle line:84% and agrees with high probability. 00:05:06.080 --> 00:05:07.520 align:middle line:90% How do I do that? 00:05:07.520 --> 00:05:12.470 align:middle line:84% How do I check that this W, that this V-- 00:05:12.470 --> 00:05:17.810 align:middle line:90% completely malicious V0 tilde-- 00:05:17.810 --> 00:05:20.040 align:middle line:84% behaves close at least-- as I said, 00:05:20.040 --> 00:05:22.380 align:middle line:84% we can't assume it's totally, but close to low degree-- 00:05:22.380 --> 00:05:26.630 align:middle line:84% agrees with the low degree polynomial in many places. 00:05:26.630 --> 00:05:27.215 align:middle line:90% Yeah? 00:05:27.215 --> 00:05:29.690 align:middle line:90% STUDENT: [INAUDIBLE] 00:05:29.690 --> 00:05:31.610 align:middle line:90% 00:05:31.610 --> 00:05:32.790 align:middle line:90% YAEL KALAI: Exactly. 00:05:32.790 --> 00:05:33.630 align:middle line:90% Exactly. 00:05:33.630 --> 00:05:35.160 align:middle line:90% Let's check on some random. 00:05:35.160 --> 00:05:37.332 align:middle line:90% Let's do a random sample. 00:05:37.332 --> 00:05:40.040 align:middle line:84% The way it's done-- so there are many low degree tests out there, 00:05:40.040 --> 00:05:41.120 align:middle line:90% by the way. 00:05:41.120 --> 00:05:43.890 align:middle line:84% But one kind of common one is the following. 00:05:43.890 --> 00:05:48.740 align:middle line:84% I'm going to take a random line in f to the m, 00:05:48.740 --> 00:05:53.090 align:middle line:90% and I'm going to check-- 00:05:53.090 --> 00:05:56.240 align:middle line:84% I'm going to ask, open this random line. 00:05:56.240 --> 00:06:04.830 align:middle line:84% Now this random line should be of degree m times H minus 1. 00:06:04.830 --> 00:06:07.100 align:middle line:90% That's what it should be. 00:06:07.100 --> 00:06:08.190 align:middle line:90% I'm going to check that. 00:06:08.190 --> 00:06:09.210 align:middle line:90% That's the degree. 00:06:09.210 --> 00:06:12.110 align:middle line:84% If it's not the degree I reject, then 00:06:12.110 --> 00:06:15.690 align:middle line:90% you're immediately rejected. 00:06:15.690 --> 00:06:20.930 align:middle line:84% So now what I know is that, on a random line, 00:06:20.930 --> 00:06:25.500 align:middle line:84% you agree with the low degree polynomial 00:06:25.500 --> 00:06:27.380 align:middle line:84% because, otherwise, you're rejected. 00:06:27.380 --> 00:06:31.130 align:middle line:84% Now one needs to argue that because you agree 00:06:31.130 --> 00:06:33.420 align:middle line:84% on a random line with a low degree polynomial, 00:06:33.420 --> 00:06:35.962 align:middle line:84% why does that mean that you're actually close to a low degree 00:06:35.962 --> 00:06:39.355 align:middle line:90% polynomial all around? 00:06:39.355 --> 00:06:40.230 align:middle line:90% But this is the test. 00:06:40.230 --> 00:06:44.090 align:middle line:84% This is really one of the low degree tests that's out there. 00:06:44.090 --> 00:06:46.010 align:middle line:90% So this is sitting in the PCP. 00:06:46.010 --> 00:06:51.280 align:middle line:84% The verifier will choose a random line, and he will test-- 00:06:51.280 --> 00:06:56.230 align:middle line:84% you can even test m times H, random points on this line. 00:06:56.230 --> 00:07:00.650 align:middle line:84% He'll take m times-- or you can test this plus 1. 00:07:00.650 --> 00:07:03.870 align:middle line:84% It doesn't really matter, depending on the soundness 00:07:03.870 --> 00:07:04.370 align:middle line:90% you want. 00:07:04.370 --> 00:07:06.910 align:middle line:84% But you can even take this plus 1. 00:07:06.910 --> 00:07:13.400 align:middle line:84% This defines polynomial of low degree of this degree. 00:07:13.400 --> 00:07:17.200 align:middle line:84% And now you check that the additional point agrees with it. 00:07:17.200 --> 00:07:20.240 align:middle line:84% Or, if you want, you can ask the entire f is only anyway, 00:07:20.240 --> 00:07:21.380 align:middle line:90% only polylog s bit. 00:07:21.380 --> 00:07:23.380 align:middle line:84% So you can just read the entire thing 00:07:23.380 --> 00:07:27.460 align:middle line:84% and see that, by interpolation, that it's a low degree 00:07:27.460 --> 00:07:31.240 align:middle line:84% polynomial, and if it's not, you reject. 00:07:31.240 --> 00:07:35.060 align:middle line:84% And then one needs to check, though. 00:07:35.060 --> 00:07:38.230 align:middle line:84% So a random line agrees with a low degree polynomial. 00:07:38.230 --> 00:07:41.140 align:middle line:84% Why does it imply that everything agrees 00:07:41.140 --> 00:07:42.940 align:middle line:90% with the low degree polynomial? 00:07:42.940 --> 00:07:48.040 align:middle line:84% That's a leap-- or with high probability. 00:07:48.040 --> 00:07:52.580 align:middle line:84% So I have a good homework problem around that. 00:07:52.580 --> 00:07:55.885 align:middle line:90% So let's leave that alone. 00:07:55.885 --> 00:07:58.540 align:middle line:90% I have a lot of this-- 00:07:58.540 --> 00:08:02.200 align:middle line:84% I have a lot of good homework problems today, 00:08:02.200 --> 00:08:05.890 align:middle line:84% which is nice because it summarizes all the information 00:08:05.890 --> 00:08:07.125 align:middle line:90% theory part of the class. 00:08:07.125 --> 00:08:09.650 align:middle line:90% 00:08:09.650 --> 00:08:12.195 align:middle line:90% Any questions before we proceed? 00:08:12.195 --> 00:08:14.770 align:middle line:90% 00:08:14.770 --> 00:08:15.610 align:middle line:90% Yeah? 00:08:15.610 --> 00:08:17.380 align:middle line:84% STUDENT: So is there some argument 00:08:17.380 --> 00:08:19.870 align:middle line:84% here that if the polynomial is low degree, then 00:08:19.870 --> 00:08:22.935 align:middle line:84% it corresponds to some weakness in this, like, PCP? 00:08:22.935 --> 00:08:25.535 align:middle line:90% 00:08:25.535 --> 00:08:27.160 align:middle line:84% YAEL KALAI: So if the argument-- if you 00:08:27.160 --> 00:08:31.130 align:middle line:84% can argue that this is close to low degree, 00:08:31.130 --> 00:08:34.220 align:middle line:84% then take the actual low degree that it's close to. 00:08:34.220 --> 00:08:36.490 align:middle line:90% Now this defines a witness. 00:08:36.490 --> 00:08:37.990 align:middle line:84% STUDENT: Oh, by evaluating on each-- 00:08:37.990 --> 00:08:39.010 align:middle line:90% I see. 00:08:39.010 --> 00:08:40.960 align:middle line:84% YAEL KALAI: Yeah, and now this is 00:08:40.960 --> 00:08:43.460 align:middle line:84% going to be the witness that you violated on, exactly. 00:08:43.460 --> 00:08:45.385 align:middle line:90% Exactly. 00:08:45.385 --> 00:08:45.885 align:middle line:90% Great. 00:08:45.885 --> 00:08:48.990 align:middle line:90% 00:08:48.990 --> 00:08:49.510 align:middle line:90% Yeah? 00:08:49.510 --> 00:08:51.010 align:middle line:84% STUDENT: [INAUDIBLE] we don't really 00:08:51.010 --> 00:09:01.630 align:middle line:84% need to do a [INAUDIBLE] circuit because if the [INAUDIBLE], 00:09:01.630 --> 00:09:04.590 align:middle line:84% and you can just do a single subtract to do it. 00:09:04.590 --> 00:09:06.660 align:middle line:84% YAEL KALAI: To do the AND, you're saying? 00:09:06.660 --> 00:09:08.160 align:middle line:84% STUDENT: Yes, some kind of things 00:09:08.160 --> 00:09:10.855 align:middle line:84% right there because we don't need to subtract 00:09:10.855 --> 00:09:12.030 align:middle line:90% the first [INAUDIBLE]. 00:09:12.030 --> 00:09:14.697 align:middle line:84% YAEL KALAI: Yeah, so what you're saying is-- what you're saying, 00:09:14.697 --> 00:09:17.430 align:middle line:84% look, there may be ways to do optimizations here. 00:09:17.430 --> 00:09:20.080 align:middle line:84% The way I showed you is very kind of generic. 00:09:20.080 --> 00:09:25.710 align:middle line:84% It said, well, this is low depth. 00:09:25.710 --> 00:09:26.400 align:middle line:90% Now I say wait. 00:09:26.400 --> 00:09:27.400 align:middle line:90% It's not just low depth. 00:09:27.400 --> 00:09:29.290 align:middle line:84% Look, it's a very specific circuit. 00:09:29.290 --> 00:09:33.450 align:middle line:84% It's one big AND with three ORs, and maybe you 00:09:33.450 --> 00:09:35.020 align:middle line:90% can do it much better. 00:09:35.020 --> 00:09:37.630 align:middle line:84% So let me say you're 100% correct. 00:09:37.630 --> 00:09:40.120 align:middle line:84% There's a lot of optimizations on GKR. 00:09:40.120 --> 00:09:43.317 align:middle line:84% I kind of showed you just kind of a feasibility result. 00:09:43.317 --> 00:09:44.900 align:middle line:84% But, as I said, these things are used, 00:09:44.900 --> 00:09:49.950 align:middle line:84% and they're not used as I showed it because they're optimized. 00:09:49.950 --> 00:09:52.430 align:middle line:84% So there's a lot of optimizations that they do, 00:09:52.430 --> 00:09:55.170 align:middle line:84% and a lot on the circuit level, as you say. 00:09:55.170 --> 00:09:58.740 align:middle line:84% What's the best way to arithmetize the circuit? 00:09:58.740 --> 00:10:02.780 align:middle line:84% No, we don't want to just maybe open it to just random-- 00:10:02.780 --> 00:10:04.350 align:middle line:90% degree 2, degree 2, degree 2. 00:10:04.350 --> 00:10:06.902 align:middle line:84% Maybe we don't want to do exactly the go doc. 00:10:06.902 --> 00:10:08.360 align:middle line:84% Maybe we want to do something else. 00:10:08.360 --> 00:10:12.140 align:middle line:84% How to generate the circuit to make 00:10:12.140 --> 00:10:14.210 align:middle line:84% it the most efficient possible-- there's 00:10:14.210 --> 00:10:17.030 align:middle line:84% a lot of optimizations on that part. 00:10:17.030 --> 00:10:18.750 align:middle line:90% So yeah, I showed you. 00:10:18.750 --> 00:10:21.380 align:middle line:84% And, as I said today, you can use GKR to be like-- 00:10:21.380 --> 00:10:23.383 align:middle line:84% the GKR protocol can be linear time prover. 00:10:23.383 --> 00:10:25.550 align:middle line:84% They manage to get to-- actually, I don't actually-- 00:10:25.550 --> 00:10:30.000 align:middle line:84% I know how they got to quasi linear. 00:10:30.000 --> 00:10:31.580 align:middle line:84% The linear is actually a new work 00:10:31.580 --> 00:10:33.500 align:middle line:84% that I didn't yet have time to dive into. 00:10:33.500 --> 00:10:36.680 align:middle line:84% But, apparently, they have really nice optimizations 00:10:36.680 --> 00:10:37.320 align:middle line:90% that they use. 00:10:37.320 --> 00:10:39.300 align:middle line:84% And most of them, I think, is exactly-- 00:10:39.300 --> 00:10:44.660 align:middle line:84% and the circuit level around ideas that you mentioned. 00:10:44.660 --> 00:10:45.390 align:middle line:90% Great. 00:10:45.390 --> 00:10:48.680 align:middle line:90% So any other questions? 00:10:48.680 --> 00:10:53.130 align:middle line:84% You guys have great great questions, so this is fantastic. 00:10:53.130 --> 00:10:56.040 align:middle line:84% So I want to say a few things that I didn't talk about. 00:10:56.040 --> 00:10:58.700 align:middle line:84% Maybe they'll show up in the homework. 00:10:58.700 --> 00:10:59.990 align:middle line:90% Maybe not. 00:10:59.990 --> 00:11:03.860 align:middle line:84% And it's related to questions that people asked, 00:11:03.860 --> 00:11:05.490 align:middle line:90% that Leo asked and others. 00:11:05.490 --> 00:11:10.580 align:middle line:90% So, first of all, I said-- 00:11:10.580 --> 00:11:12.920 align:middle line:90% I showed poly log. 00:11:12.920 --> 00:11:15.960 align:middle line:84% I said we can go all the way down to 3. 00:11:15.960 --> 00:11:18.090 align:middle line:84% Let me just mention, 3 is the best we can do. 00:11:18.090 --> 00:11:21.140 align:middle line:90% We cannot go below 3. 00:11:21.140 --> 00:11:23.960 align:middle line:84% From poly log n, you can do kind of log log n. 00:11:23.960 --> 00:11:28.740 align:middle line:84% Using recursion, you can do PCP on the poly log n queries. 00:11:28.740 --> 00:11:29.790 align:middle line:90% You can recurse. 00:11:29.790 --> 00:11:33.500 align:middle line:84% And then, from the log log n to 3, you can do-- 00:11:33.500 --> 00:11:35.520 align:middle line:84% there are these exponential-sized proofs. 00:11:35.520 --> 00:11:38.270 align:middle line:84% But to take a log log n and make it-- 00:11:38.270 --> 00:11:40.910 align:middle line:84% there's exponential-sized PCP with only three queries. 00:11:40.910 --> 00:11:43.450 align:middle line:84% So you apply an exponential-sized PCP 00:11:43.450 --> 00:11:45.530 align:middle line:90% to this log log n sized PCP. 00:11:45.530 --> 00:11:51.100 align:middle line:84% They have all these cool tricks, and they manage to get to 3. 00:11:51.100 --> 00:11:53.360 align:middle line:90% Three bits. 00:11:53.360 --> 00:11:54.320 align:middle line:90% Three bits. 00:11:54.320 --> 00:11:55.760 align:middle line:90% Can you go to two bits? 00:11:55.760 --> 00:11:56.470 align:middle line:90% No. 00:11:56.470 --> 00:11:57.085 align:middle line:90% Yeah? 00:11:57.085 --> 00:11:59.210 align:middle line:84% STUDENT: Is that only for soundness half, like if-- 00:11:59.210 --> 00:11:59.835 align:middle line:90% YAEL KALAI: No. 00:11:59.835 --> 00:12:00.860 align:middle line:90% Any constant soundness. 00:12:00.860 --> 00:12:01.360 align:middle line:90% No-- 00:12:01.360 --> 00:12:05.890 align:middle line:84% STUDENT: What about for negligible soundness? 00:12:05.890 --> 00:12:08.080 align:middle line:84% YAEL KALAI: No, constant soundness. 00:12:08.080 --> 00:12:11.200 align:middle line:90% Constant soundness. 00:12:11.200 --> 00:12:15.520 align:middle line:84% For constant soundness, we can get 3. 00:12:15.520 --> 00:12:18.310 align:middle line:84% The constant, I think, is better than half, but whatever. 00:12:18.310 --> 00:12:20.420 align:middle line:90% But you can get 3. 00:12:20.420 --> 00:12:23.185 align:middle line:84% And can you get constant soundness for 2? 00:12:23.185 --> 00:12:23.685 align:middle line:90% No. 00:12:23.685 --> 00:12:26.260 align:middle line:90% 00:12:26.260 --> 00:12:28.330 align:middle line:90% No, I think you just can't. 00:12:28.330 --> 00:12:30.680 align:middle line:90% So I don't want to get-- 00:12:30.680 --> 00:12:31.880 align:middle line:90% yeah, I don't want to get-- 00:12:31.880 --> 00:12:32.960 align:middle line:90% and can you get 1? 00:12:32.960 --> 00:12:33.880 align:middle line:90% Definitely not. 00:12:33.880 --> 00:12:34.820 align:middle line:90% So can you get 2? 00:12:34.820 --> 00:12:35.470 align:middle line:90% No. 00:12:35.470 --> 00:12:39.400 align:middle line:84% However, you can get 2 if you make 00:12:39.400 --> 00:12:42.320 align:middle line:84% each the answer to each query like a block. 00:12:42.320 --> 00:12:46.120 align:middle line:84% So if you want two queries where each query gives you an answer 00:12:46.120 --> 00:12:48.830 align:middle line:90% bit, you cannot have PCP. 00:12:48.830 --> 00:12:51.440 align:middle line:84% And the reason actually-- intuitively, 00:12:51.440 --> 00:12:56.140 align:middle line:84% the reason you cannot have a PCP is because two SAT is easy. 00:12:56.140 --> 00:13:00.700 align:middle line:84% If you have only two kind of queries, 00:13:00.700 --> 00:13:03.710 align:middle line:84% intuitively, the reason why it's because two SAT is easy. 00:13:03.710 --> 00:13:04.710 align:middle line:90% I don't want to go into. 00:13:04.710 --> 00:13:07.390 align:middle line:84% Maybe it can be homework, so let's leave that. 00:13:07.390 --> 00:13:12.400 align:middle line:84% But what you can have-- and we do have-- 00:13:12.400 --> 00:13:13.420 align:middle line:90% it's not just do-- 00:13:13.420 --> 00:13:17.300 align:middle line:84% we do have PCPs that have only two queries, 00:13:17.300 --> 00:13:20.530 align:middle line:90% but the answers are large. 00:13:20.530 --> 00:13:22.780 align:middle line:84% I mean, OK, you can have one query if the answer is 00:13:22.780 --> 00:13:23.900 align:middle line:90% the size of the witness. 00:13:23.900 --> 00:13:24.950 align:middle line:90% OK, that's easy. 00:13:24.950 --> 00:13:28.210 align:middle line:84% But we can have two queries where the size of each answer 00:13:28.210 --> 00:13:30.670 align:middle line:90% is poly log. 00:13:30.670 --> 00:13:32.680 align:middle line:90% OK, but not one. 00:13:32.680 --> 00:13:35.520 align:middle line:90% Or constant for all I know. 00:13:35.520 --> 00:13:37.380 align:middle line:84% So maybe, we'll do some homework kind of 00:13:37.380 --> 00:13:40.420 align:middle line:84% to get intuitions around these things. 00:13:40.420 --> 00:13:40.920 align:middle line:90% Yeah. 00:13:40.920 --> 00:13:42.295 align:middle line:84% AUDIENCE: Actually, I think we do 00:13:42.295 --> 00:13:45.300 align:middle line:84% have to be qualitative if we're allowed 00:13:45.300 --> 00:13:48.100 align:middle line:90% to have imperfect completeness. 00:13:48.100 --> 00:13:48.600 align:middle line:90% [INAUDIBLE] 00:13:48.600 --> 00:13:51.990 align:middle line:84% YAEL KALAI: Oh, if you allow to have imperfect completeness, 00:13:51.990 --> 00:13:55.180 align:middle line:90% then you're right. 00:13:55.180 --> 00:13:55.680 align:middle line:90% Sorry. 00:13:55.680 --> 00:13:58.000 align:middle line:84% Everything I'm saying is for perfect completeness. 00:13:58.000 --> 00:14:04.050 align:middle line:84% Once you allow to reduce completeness to 1 minus epsilon, 00:14:04.050 --> 00:14:05.020 align:middle line:90% things change. 00:14:05.020 --> 00:14:11.580 align:middle line:84% So what do we know, yeah, with two-- 00:14:11.580 --> 00:14:12.250 align:middle line:90% if you have. 00:14:12.250 --> 00:14:14.760 align:middle line:84% Yeah I'm not I don't remember off the top of my head 00:14:14.760 --> 00:14:16.600 align:middle line:90% what's two. 00:14:16.600 --> 00:14:17.650 align:middle line:90% But what's the soundness. 00:14:17.650 --> 00:14:19.420 align:middle line:90% Two queries, constant soundness. 00:14:19.420 --> 00:14:19.920 align:middle line:90% 2 bits. 00:14:19.920 --> 00:14:20.760 align:middle line:90% AUDIENCE: One third, two third. 00:14:20.760 --> 00:14:21.850 align:middle line:84% YAEL KALAI: One third, two third. 00:14:21.850 --> 00:14:22.290 align:middle line:90% OK. 00:14:22.290 --> 00:14:22.790 align:middle line:90% OK. 00:14:22.790 --> 00:14:23.790 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:14:23.790 --> 00:14:24.480 align:middle line:84% YAEL KALAI: Yeah, yeah, yeah, yeah. 00:14:24.480 --> 00:14:25.058 align:middle line:90% OK, yeah. 00:14:25.058 --> 00:14:25.600 align:middle line:90% You're right. 00:14:25.600 --> 00:14:26.400 align:middle line:90% So here, I'm assuming-- yeah. 00:14:26.400 --> 00:14:26.942 align:middle line:90% You're right. 00:14:26.942 --> 00:14:27.820 align:middle line:90% Yeah, good point. 00:14:27.820 --> 00:14:28.360 align:middle line:90% Thank you. 00:14:28.360 --> 00:14:31.830 align:middle line:84% Yeah, so if you're willing to relax completeness, 00:14:31.830 --> 00:14:33.210 align:middle line:90% we can get 2. 00:14:33.210 --> 00:14:35.410 align:middle line:84% But perfect completeness, you can't. 00:14:35.410 --> 00:14:36.120 align:middle line:90% Yeah. 00:14:36.120 --> 00:14:36.745 align:middle line:90% AUDIENCE: Wait. 00:14:36.745 --> 00:14:39.540 align:middle line:84% When you say, "blocks," and when there are two blocks is 00:14:39.540 --> 00:14:41.540 align:middle line:84% possible, are you talking about contiguous bits, 00:14:41.540 --> 00:14:42.270 align:middle line:90% blocks [INAUDIBLE]. 00:14:42.270 --> 00:14:42.580 align:middle line:90% YAEL KALAI: Yeah. 00:14:42.580 --> 00:14:43.080 align:middle line:90% So yeah. 00:14:43.080 --> 00:14:46.710 align:middle line:84% Think about it-- each query you read-- so the PCP consists 00:14:46.710 --> 00:14:48.910 align:middle line:90% of instead of bit, bit, bit. 00:14:48.910 --> 00:14:52.660 align:middle line:84% Think about it like a word, a word, a word, a word. 00:14:52.660 --> 00:14:55.300 align:middle line:84% And each word is poly log and bits for example. 00:14:55.300 --> 00:14:57.130 align:middle line:84% And now, you can read only two words. 00:14:57.130 --> 00:15:01.110 align:middle line:84% So you can say I want to read word i and word j. 00:15:01.110 --> 00:15:02.422 align:middle line:90% AUDIENCE: OK. 00:15:02.422 --> 00:15:03.130 align:middle line:90% YAEL KALAI: Yeah. 00:15:03.130 --> 00:15:04.480 align:middle line:90% Yes. 00:15:04.480 --> 00:15:06.480 align:middle line:84% AUDIENCE: Don't we not have perfect completeness 00:15:06.480 --> 00:15:08.483 align:middle line:84% right now because of the low-degree test that 00:15:08.483 --> 00:15:09.150 align:middle line:90% has [INAUDIBLE]? 00:15:09.150 --> 00:15:10.270 align:middle line:90% YAEL KALAI: OK, good. 00:15:10.270 --> 00:15:10.770 align:middle line:90% No. 00:15:10.770 --> 00:15:12.490 align:middle line:90% So good question. 00:15:12.490 --> 00:15:14.980 align:middle line:84% So the question is, now, do we have perfect completeness? 00:15:14.980 --> 00:15:17.967 align:middle line:84% And the answer is yes, because if you're honest-- 00:15:17.967 --> 00:15:19.800 align:middle line:84% perfect completeness means if you're honest, 00:15:19.800 --> 00:15:21.430 align:middle line:84% you'll be accepted with probability 1. 00:15:21.430 --> 00:15:23.250 align:middle line:84% So if you're honest, you are going 00:15:23.250 --> 00:15:26.670 align:middle line:84% to give w tilde, which is the low-degree extension 00:15:26.670 --> 00:15:27.760 align:middle line:90% of your witness. 00:15:27.760 --> 00:15:30.900 align:middle line:84% And when I take a random line, it's going to be of low degree. 00:15:30.900 --> 00:15:31.540 align:middle line:90% For sure. 00:15:31.540 --> 00:15:33.350 align:middle line:90% Everything is low degree. 00:15:33.350 --> 00:15:35.840 align:middle line:90% If you're malicious, then-- 00:15:35.840 --> 00:15:37.947 align:middle line:84% AUDIENCE: So the soundness is [INAUDIBLE]. 00:15:37.947 --> 00:15:39.030 align:middle line:90% YAEL KALAI: The soundness. 00:15:39.030 --> 00:15:39.440 align:middle line:90% Exactly. 00:15:39.440 --> 00:15:40.470 align:middle line:90% You lose-- you're right. 00:15:40.470 --> 00:15:41.010 align:middle line:90% Good point. 00:15:41.010 --> 00:15:43.568 align:middle line:84% What you mentioned is you say, because we do the low degree. 00:15:43.568 --> 00:15:45.110 align:middle line:84% We lose a little bit in the soundness 00:15:45.110 --> 00:15:47.992 align:middle line:84% because maybe you're a little malicious 00:15:47.992 --> 00:15:48.950 align:middle line:90% and we don't catch you. 00:15:48.950 --> 00:15:50.900 align:middle line:90% Or and that goes, yeah. 00:15:50.900 --> 00:15:54.410 align:middle line:84% So you need to make the soundness a little bigger so 00:15:54.410 --> 00:15:56.338 align:middle line:84% that you can eat up what you lose 00:15:56.338 --> 00:15:57.630 align:middle line:90% a little bit in the low degree. 00:15:57.630 --> 00:15:58.205 align:middle line:90% Yeah, yeah. 00:15:58.205 --> 00:15:58.830 align:middle line:90% Great question. 00:15:58.830 --> 00:15:59.390 align:middle line:90% Yeah. 00:15:59.390 --> 00:16:00.410 align:middle line:84% AUDIENCE: When you're doing the protocol 00:16:00.410 --> 00:16:02.840 align:middle line:84% to bring the standards down, can you just use the same tools 00:16:02.840 --> 00:16:04.320 align:middle line:84% and just check the different randomness? 00:16:04.320 --> 00:16:05.040 align:middle line:90% YAEL KALAI: Yeah, yeah, yeah. 00:16:05.040 --> 00:16:05.540 align:middle line:90% Good. 00:16:05.540 --> 00:16:07.490 align:middle line:84% So the question is when you repeat, 00:16:07.490 --> 00:16:08.780 align:middle line:90% so let's say you're not happy. 00:16:08.780 --> 00:16:10.080 align:middle line:90% We have soundness half. 00:16:10.080 --> 00:16:11.100 align:middle line:90% We're not happy. 00:16:11.100 --> 00:16:11.940 align:middle line:90% What do you do? 00:16:11.940 --> 00:16:14.510 align:middle line:84% You need to actually repeat the entire PCP 00:16:14.510 --> 00:16:19.400 align:middle line:84% or-- no you don't because the prover will just give you 00:16:19.400 --> 00:16:20.640 align:middle line:90% the same PCP over and over. 00:16:20.640 --> 00:16:21.150 align:middle line:90% So no. 00:16:21.150 --> 00:16:22.140 align:middle line:90% You keep the same PCP. 00:16:22.140 --> 00:16:26.090 align:middle line:84% All you do is you run the verifier, the PCP verifier, 00:16:26.090 --> 00:16:29.370 align:middle line:84% fresh with fresh randomness more times. 00:16:29.370 --> 00:16:30.870 align:middle line:84% So if you have soundness happen, you 00:16:30.870 --> 00:16:33.340 align:middle line:84% want to have soundness 1 over 2 to the k, 00:16:33.340 --> 00:16:37.940 align:middle line:84% what you do is you run the PCP verifier k times. 00:16:37.940 --> 00:16:39.950 align:middle line:84% So it generates one set of queries, 00:16:39.950 --> 00:16:42.250 align:middle line:84% you run them fresh again, another set of queries, fresh 00:16:42.250 --> 00:16:42.770 align:middle line:90% again. 00:16:42.770 --> 00:16:46.960 align:middle line:84% Each time is going to be rejected, probably half, 00:16:46.960 --> 00:16:48.410 align:middle line:90% independently of the other time. 00:16:48.410 --> 00:16:52.910 align:middle line:84% So you just get that is rejected. 00:16:52.910 --> 00:16:56.470 align:middle line:84% He's accepted probability 1 over 2 to the k. 00:16:56.470 --> 00:16:57.250 align:middle line:90% Yeah. 00:16:57.250 --> 00:16:59.630 align:middle line:84% So just the verifiers needs to repeat. 00:16:59.630 --> 00:17:02.350 align:middle line:84% The prover is not involved in this. 00:17:02.350 --> 00:17:04.004 align:middle line:90% Great question, guys. 00:17:04.004 --> 00:17:06.112 align:middle line:90% Any other questions? 00:17:06.112 --> 00:17:08.445 align:middle line:84% AUDIENCE: What's the reference for this two-query thing? 00:17:08.445 --> 00:17:10.990 align:middle line:90% 00:17:10.990 --> 00:17:13.254 align:middle line:90% YAEL KALAI: I can put it in-- 00:17:13.254 --> 00:17:14.410 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:17:14.410 --> 00:17:19.839 align:middle line:84% YAEL KALAI: Yeah, I can put it in Canvas, in the website. 00:17:19.839 --> 00:17:22.140 align:middle line:84% OK, if I don't remember, remind me. 00:17:22.140 --> 00:17:22.640 align:middle line:90% OK. 00:17:22.640 --> 00:17:25.930 align:middle line:84% So before we move to crypto, I just want 00:17:25.930 --> 00:17:28.810 align:middle line:84% to wrap up kind of the information theory part 00:17:28.810 --> 00:17:34.180 align:middle line:84% and say that in some sense, I taught you almost 00:17:34.180 --> 00:17:36.640 align:middle line:90% like, OK, so what's missing? 00:17:36.640 --> 00:17:39.230 align:middle line:84% What did you not get a chance to see? 00:17:39.230 --> 00:17:41.355 align:middle line:84% You didn't get a chance to see the three query. 00:17:41.355 --> 00:17:42.730 align:middle line:84% So you didn't get a chance to see 00:17:42.730 --> 00:17:46.240 align:middle line:84% the recursion, and the Hadamard, and this nice way to getting 00:17:46.240 --> 00:17:48.400 align:middle line:90% three PCPs. 00:17:48.400 --> 00:17:54.370 align:middle line:84% There's another beautiful, beautiful result by Reingold, 00:17:54.370 --> 00:17:59.620 align:middle line:84% and Rothblum, and Rothblum from 2018. 00:17:59.620 --> 00:18:00.240 align:middle line:90% '16? 00:18:00.240 --> 00:18:00.740 align:middle line:90% '18? 00:18:00.740 --> 00:18:00.970 align:middle line:90% Yeah. 00:18:00.970 --> 00:18:02.780 align:middle line:84% AUDIENCE: [INAUDIBLE] '16, but now when you look at it, 00:18:02.780 --> 00:18:04.300 align:middle line:90% it says '18 because they-- 00:18:04.300 --> 00:18:05.710 align:middle line:90% the [INAUDIBLE]. 00:18:05.710 --> 00:18:06.680 align:middle line:90% YAEL KALAI: Yeah, OK. 00:18:06.680 --> 00:18:08.140 align:middle line:90% Well, it started in '16. 00:18:08.140 --> 00:18:10.420 align:middle line:90% And since then, there's work. 00:18:10.420 --> 00:18:12.500 align:middle line:84% But essentially, here's the question. 00:18:12.500 --> 00:18:15.850 align:middle line:84% This is kind of a question that's still missing. 00:18:15.850 --> 00:18:18.560 align:middle line:90% And here's the question. 00:18:18.560 --> 00:18:24.970 align:middle line:84% The question is, we have efficient, doubly-efficient 00:18:24.970 --> 00:18:27.810 align:middle line:90% protocol for bounded depth. 00:18:27.810 --> 00:18:30.030 align:middle line:84% Can we construct doubly-efficient protocol 00:18:30.030 --> 00:18:31.930 align:middle line:90% for bounded space? 00:18:31.930 --> 00:18:33.250 align:middle line:90% Now, look. 00:18:33.250 --> 00:18:36.360 align:middle line:84% We know that we cannot hope to have doubly efficient, 00:18:36.360 --> 00:18:40.360 align:middle line:84% or not doubly efficient for that matter, for more than p space. 00:18:40.360 --> 00:18:43.200 align:middle line:90% We know that ip equals p space. 00:18:43.200 --> 00:18:47.920 align:middle line:84% So you can't have interactive proof 00:18:47.920 --> 00:18:52.480 align:middle line:84% be the prover efficient or not efficient for more than p space. 00:18:52.480 --> 00:18:54.520 align:middle line:90% OK, so we're stuck with p space. 00:18:54.520 --> 00:18:55.870 align:middle line:90% Now, you can exchange. 00:18:55.870 --> 00:18:57.430 align:middle line:90% You can go from depth to space. 00:18:57.430 --> 00:18:59.310 align:middle line:84% Actually, there's a way to convert depth 00:18:59.310 --> 00:19:00.850 align:middle line:90% to space and vice versa. 00:19:00.850 --> 00:19:03.010 align:middle line:84% But it doesn't preserve efficiency. 00:19:03.010 --> 00:19:06.678 align:middle line:84% So you can go from bounded depth to bounded space. 00:19:06.678 --> 00:19:08.220 align:middle line:84% Now, you must go because I showed you 00:19:08.220 --> 00:19:10.770 align:middle line:84% a double-efficient double rooted bounded space if it required 00:19:10.770 --> 00:19:13.320 align:middle line:84% more than poly space, something in the world 00:19:13.320 --> 00:19:16.290 align:middle line:84% would go wrong because we know ip equals p space. 00:19:16.290 --> 00:19:18.570 align:middle line:90% So the point is we do know. 00:19:18.570 --> 00:19:22.800 align:middle line:84% We can convert a bounded-depth computation 00:19:22.800 --> 00:19:25.170 align:middle line:90% to a bounded-space computation. 00:19:25.170 --> 00:19:29.520 align:middle line:84% But this conversion doesn't respect 00:19:29.520 --> 00:19:31.270 align:middle line:90% the efficiency of the circuit. 00:19:31.270 --> 00:19:33.930 align:middle line:84% So if you take a bounded-depth circuit 00:19:33.930 --> 00:19:37.150 align:middle line:84% and convert it to a bounded-space circuit, 00:19:37.150 --> 00:19:40.420 align:middle line:84% the bounded-space circuit, or bounded-space computation, 00:19:40.420 --> 00:19:43.110 align:middle line:84% I should say the bounded-space computation now 00:19:43.110 --> 00:19:45.010 align:middle line:90% will just be very, very long. 00:19:45.010 --> 00:19:48.570 align:middle line:84% Even if the bounded-depth circuit, let's say, 00:19:48.570 --> 00:19:53.700 align:middle line:84% was only size s polynomial, the bounded-space computation 00:19:53.700 --> 00:19:55.740 align:middle line:90% can be exponential. 00:19:55.740 --> 00:19:58.755 align:middle line:84% OK, so it doesn't respect kind of the efficiency 00:19:58.755 --> 00:20:00.630 align:middle line:84% of the computation when you do the transition 00:20:00.630 --> 00:20:04.150 align:middle line:84% from bounded depth to bounded space, or vice versa. 00:20:04.150 --> 00:20:05.910 align:middle line:90% So now, there's a question. 00:20:05.910 --> 00:20:08.970 align:middle line:84% Can you do-- let's say you have a bounded-space computation, not 00:20:08.970 --> 00:20:10.050 align:middle line:90% a bounded depth. 00:20:10.050 --> 00:20:13.230 align:middle line:84% Yeah, you can convert a bounded depth and pay a price. 00:20:13.230 --> 00:20:16.410 align:middle line:90% But you don't want to. 00:20:16.410 --> 00:20:20.170 align:middle line:84% Can you do a bounded-space computation, 00:20:20.170 --> 00:20:23.000 align:middle line:90% make it doubly efficient? 00:20:23.000 --> 00:20:26.210 align:middle line:90% OK, so here is kind of a goal. 00:20:26.210 --> 00:20:31.070 align:middle line:84% And those who've been working with me for a while maybe 00:20:31.070 --> 00:20:34.450 align:middle line:84% traumatized by this goal because I tormented them. 00:20:34.450 --> 00:20:38.540 align:middle line:90% 00:20:38.540 --> 00:20:42.120 align:middle line:84% I think this is one of the most interesting problems out there. 00:20:42.120 --> 00:20:44.790 align:middle line:84% It's really frustrating to me that there's no solution. 00:20:44.790 --> 00:20:46.590 align:middle line:84% I'll give you an incentive in a second. 00:20:46.590 --> 00:20:47.695 align:middle line:90% But here's the-- 00:20:47.695 --> 00:20:50.270 align:middle line:90% 00:20:50.270 --> 00:20:51.725 align:middle line:90% OK. 00:20:51.725 --> 00:20:53.490 align:middle line:90% So here's my question. 00:20:53.490 --> 00:21:08.300 align:middle line:84% If you have any time T space S computation, t of n, s of n. 00:21:08.300 --> 00:21:09.390 align:middle line:90% Here's the goal. 00:21:09.390 --> 00:21:18.680 align:middle line:84% Goal, we want an interactive proof such 00:21:18.680 --> 00:21:25.410 align:middle line:84% that prover runtime is efficient, poly t. 00:21:25.410 --> 00:21:28.430 align:middle line:90% 00:21:28.430 --> 00:21:35.320 align:middle line:84% We want verifier runtime, or-- let's count, OK, verify runtime. 00:21:35.320 --> 00:21:37.320 align:middle line:84% Well, the poor guy has to read the input length. 00:21:37.320 --> 00:21:43.520 align:middle line:84% So x plus times I'll be nice with you, times whatever. 00:21:43.520 --> 00:21:45.680 align:middle line:90% It can be even poly. 00:21:45.680 --> 00:21:48.330 align:middle line:84% I'm happy even with poly if you want to put poly here. 00:21:48.330 --> 00:21:54.230 align:middle line:84% I'll be generous-- times poly and the space, 00:21:54.230 --> 00:21:55.280 align:middle line:90% not depending on T. 00:21:55.280 --> 00:21:59.420 align:middle line:84% So he can read the input and run times the space. 00:21:59.420 --> 00:22:01.820 align:middle line:84% And usually, we want the complex, the communication 00:22:01.820 --> 00:22:05.330 align:middle line:84% complexity, to grow only like poly space. 00:22:05.330 --> 00:22:07.290 align:middle line:84% But if you want to put x in there, fine. 00:22:07.290 --> 00:22:09.380 align:middle line:90% Be my guest. 00:22:09.380 --> 00:22:11.270 align:middle line:90% This is what we want. 00:22:11.270 --> 00:22:12.860 align:middle line:90% This is open. 00:22:12.860 --> 00:22:17.195 align:middle line:84% So we want a doubly-efficient interactive proof for p space. 00:22:17.195 --> 00:22:21.440 align:middle line:84% Let me tell you what Reingold and the Rothblum brothers did. 00:22:21.440 --> 00:22:22.970 align:middle line:90% They almost did this. 00:22:22.970 --> 00:22:26.470 align:middle line:90% But here's this annoying part. 00:22:26.470 --> 00:22:31.210 align:middle line:84% The verifier runtime and the communication complexity 00:22:31.210 --> 00:22:39.370 align:middle line:84% is S, great, but times T to the epsilon. 00:22:39.370 --> 00:22:41.200 align:middle line:84% And this epsilon has to be a constant 00:22:41.200 --> 00:22:43.210 align:middle line:84% because the communication complexity grows 00:22:43.210 --> 00:22:48.082 align:middle line:84% with 2 to the something, o tilde, I think 1 over epsilon, 00:22:48.082 --> 00:22:49.040 align:middle line:90% or something like that. 00:22:49.040 --> 00:22:52.430 align:middle line:84% So there's exponential growth in epsilon. 00:22:52.430 --> 00:22:57.130 align:middle line:84% So you can't take-- you can maybe take epsilon, like, 00:22:57.130 --> 00:23:02.770 align:middle line:84% 1 over log, log, or log, log and like log, log, log n over log-- 00:23:02.770 --> 00:23:04.780 align:middle line:90% 1 over log, log n. 00:23:04.780 --> 00:23:06.140 align:middle line:90% Think of it as constant. 00:23:06.140 --> 00:23:08.090 align:middle line:84% You don't really gain by trying some constant. 00:23:08.090 --> 00:23:09.350 align:middle line:90% It's not giving you much. 00:23:09.350 --> 00:23:12.830 align:middle line:84% So they present the result as epsilon being a constant. 00:23:12.830 --> 00:23:14.530 align:middle line:84% So this is really annoying because now 00:23:14.530 --> 00:23:16.820 align:middle line:84% the verifier, if T is polynomial, is super polynomial, 00:23:16.820 --> 00:23:18.730 align:middle line:84% the verifier is not even efficient. 00:23:18.730 --> 00:23:22.600 align:middle line:84% So this is really for p, actually. 00:23:22.600 --> 00:23:26.950 align:middle line:84% I want to get rid of this and do for big T. OK, 00:23:26.950 --> 00:23:28.810 align:middle line:90% this is still an open question. 00:23:28.810 --> 00:23:30.850 align:middle line:90% OK, now, I need now OK. 00:23:30.850 --> 00:23:34.490 align:middle line:84% I'm begging you guys, a plea for the smart, 00:23:34.490 --> 00:23:37.720 align:middle line:84% all you smart MIT students, or Harvard, 00:23:37.720 --> 00:23:40.540 align:middle line:84% or at BU, or Northeastern, or whoever you are. 00:23:40.540 --> 00:23:42.080 align:middle line:90% This is a personal favor. 00:23:42.080 --> 00:23:44.540 align:middle line:90% Can someone please solve this? 00:23:44.540 --> 00:23:47.170 align:middle line:84% And I know I need to give you guys incentive. 00:23:47.170 --> 00:23:54.430 align:middle line:84% So beyond probably I don't know, like a ACM PhD award 00:23:54.430 --> 00:23:58.400 align:middle line:90% or whatever, that's nothing. 00:23:58.400 --> 00:24:01.310 align:middle line:84% But I'm willing to give you a $500 prize. 00:24:01.310 --> 00:24:03.496 align:middle line:90% AUDIENCE: Whoa. 00:24:03.496 --> 00:24:04.720 align:middle line:90% YAEL KALAI: So-- 00:24:04.720 --> 00:24:07.383 align:middle line:84% AUDIENCE: You're outbidding [INAUDIBLE]. 00:24:07.383 --> 00:24:09.550 align:middle line:84% YAEL KALAI: That didn't give a prize on this, right? 00:24:09.550 --> 00:24:11.425 align:middle line:84% He gave like a fake cheap prize or something. 00:24:11.425 --> 00:24:14.615 align:middle line:90% AUDIENCE: But it was, like, $15. 00:24:14.615 --> 00:24:15.240 align:middle line:90% YAEL KALAI: OK. 00:24:15.240 --> 00:24:17.730 align:middle line:84% AUDIENCE: He was a good [INAUDIBLE]. 00:24:17.730 --> 00:24:20.160 align:middle line:90% YAEL KALAI: OK, so this. 00:24:20.160 --> 00:24:22.703 align:middle line:90% You get rid of the T, do this. 00:24:22.703 --> 00:24:23.620 align:middle line:90% You can take pictures. 00:24:23.620 --> 00:24:25.328 align:middle line:84% So you can actually work on this, please. 00:24:25.328 --> 00:24:27.600 align:middle line:90% OK. 00:24:27.600 --> 00:24:29.260 align:middle line:90% Let's move on. 00:24:29.260 --> 00:24:32.490 align:middle line:84% OK, so this essentially concludes 00:24:32.490 --> 00:24:34.530 align:middle line:90% the unit on information theory. 00:24:34.530 --> 00:24:36.990 align:middle line:84% OK, there's another proof system that I 00:24:36.990 --> 00:24:40.620 align:middle line:84% didn't talk about, which is a multi-prover interactive proofs. 00:24:40.620 --> 00:24:42.300 align:middle line:84% The reason I didn't talk about them 00:24:42.300 --> 00:24:44.100 align:middle line:84% is because they're really equivalent 00:24:44.100 --> 00:24:45.880 align:middle line:84% to probabilistically-checkable proofs. 00:24:45.880 --> 00:24:47.770 align:middle line:90% They're not much different. 00:24:47.770 --> 00:24:50.668 align:middle line:84% Maybe I'll put something along these lines in the homework. 00:24:50.668 --> 00:24:51.210 align:middle line:90% I don't know. 00:24:51.210 --> 00:24:52.252 align:middle line:90% I need to think about it. 00:24:52.252 --> 00:24:55.060 align:middle line:84% But that's another thing we did not cover. 00:24:55.060 --> 00:24:58.240 align:middle line:84% But the really, an equivalent thing to PCP. 00:24:58.240 --> 00:25:00.540 align:middle line:84% But it's another proof model that was 00:25:00.540 --> 00:25:02.700 align:middle line:90% considered in the literature. 00:25:02.700 --> 00:25:07.570 align:middle line:84% OK, so that concludes information theory. 00:25:07.570 --> 00:25:08.500 align:middle line:90% So that's all we know. 00:25:08.500 --> 00:25:10.650 align:middle line:90% We're stuck with p space. 00:25:10.650 --> 00:25:13.880 align:middle line:90% Actually, we don't even-- 00:25:13.880 --> 00:25:17.070 align:middle line:84% and we can get a very efficient verification. 00:25:17.070 --> 00:25:19.260 align:middle line:84% But then, we have a very long proof like the PCP. 00:25:19.260 --> 00:25:22.800 align:middle line:84% You can verify things super efficiently, like fantastic. 00:25:22.800 --> 00:25:27.930 align:middle line:84% But you need to write somewhere this gigantic PCP proof. 00:25:27.930 --> 00:25:28.980 align:middle line:90% That's the PCP. 00:25:28.980 --> 00:25:34.805 align:middle line:84% And note, it's very important that the verifier, 00:25:34.805 --> 00:25:36.390 align:middle line:90% that this PCP is written. 00:25:36.390 --> 00:25:38.270 align:middle line:84% If the PCP is not written somewhere, 00:25:38.270 --> 00:25:40.970 align:middle line:84% and he's talking with the prover and telling him, look, 00:25:40.970 --> 00:25:43.230 align:middle line:84% I know you have a PCP written there somewhere, 00:25:43.230 --> 00:25:46.490 align:middle line:84% can you give me locations i, j and k, a cheating prover 00:25:46.490 --> 00:25:49.730 align:middle line:84% will choose the locations based on i, j, and k 00:25:49.730 --> 00:25:54.080 align:middle line:84% And then for i, j, k, he'll put in location i 0, 00:25:54.080 --> 00:25:56.460 align:middle line:84% and maybe for i and j prime k prime, 00:25:56.460 --> 00:25:58.440 align:middle line:84% he will then put location i 1, and cheat. 00:25:58.440 --> 00:26:02.460 align:middle line:84% So it's very important that the PCP is written. 00:26:02.460 --> 00:26:06.150 align:middle line:84% And now when you ask query i, it's what's written there. 00:26:06.150 --> 00:26:10.160 align:middle line:84% The answer cannot depend on query j or query k. 00:26:10.160 --> 00:26:12.630 align:middle line:84% So it seems like it's a very nice model. 00:26:12.630 --> 00:26:13.260 align:middle line:90% It's fantastic. 00:26:13.260 --> 00:26:16.160 align:middle line:84% But where is this huge thing going to be written? 00:26:16.160 --> 00:26:18.530 align:middle line:90% OK, so if we want-- 00:26:18.530 --> 00:26:21.060 align:middle line:84% at the end of the day, here's our goal really. 00:26:21.060 --> 00:26:25.370 align:middle line:84% What we're after really is to take an actual proof, 00:26:25.370 --> 00:26:28.580 align:middle line:90% like a witness, and shrink it. 00:26:28.580 --> 00:26:29.400 align:middle line:90% It's big. 00:26:29.400 --> 00:26:30.230 align:middle line:90% I don't like big. 00:26:30.230 --> 00:26:31.080 align:middle line:90% Shrink. 00:26:31.080 --> 00:26:31.890 align:middle line:90% Make it small. 00:26:31.890 --> 00:26:32.390 align:middle line:90% Here. 00:26:32.390 --> 00:26:33.450 align:middle line:90% Now, it's smaller. 00:26:33.450 --> 00:26:35.370 align:middle line:90% Now, of course, we can't do it. 00:26:35.370 --> 00:26:36.540 align:middle line:90% So or can do it. 00:26:36.540 --> 00:26:38.055 align:middle line:84% So now we start changing the model 00:26:38.055 --> 00:26:39.180 align:middle line:90% and say, OK, you know what? 00:26:39.180 --> 00:26:41.130 align:middle line:90% Let's try interactive. 00:26:41.130 --> 00:26:42.120 align:middle line:90% You know what? 00:26:42.120 --> 00:26:44.481 align:middle line:90% Let's try PCP. 00:26:44.481 --> 00:26:45.960 align:middle line:90% All these are very nice. 00:26:45.960 --> 00:26:50.400 align:middle line:84% But they all have really strong problems. 00:26:50.400 --> 00:26:53.640 align:middle line:84% OK, like the interactive proof one, it's very, very specific. 00:26:53.640 --> 00:26:55.150 align:middle line:90% It's an interactive proof. 00:26:55.150 --> 00:26:56.460 align:middle line:90% I can talk to Tina. 00:26:56.460 --> 00:26:57.330 align:middle line:90% I can talk to Sue. 00:26:57.330 --> 00:26:58.080 align:middle line:90% I can talk to Leo. 00:26:58.080 --> 00:27:00.840 align:middle line:90% But it's per person. 00:27:00.840 --> 00:27:04.040 align:middle line:84% What if I want to give a proof to the world? 00:27:04.040 --> 00:27:05.840 align:middle line:90% I can't do an interactive proof. 00:27:05.840 --> 00:27:09.670 align:middle line:84% I want to prove some of my proof. 00:27:09.670 --> 00:27:11.150 align:middle line:90% OK, now I can do PCP. 00:27:11.150 --> 00:27:13.190 align:middle line:84% I can post that, but it's really big. 00:27:13.190 --> 00:27:15.790 align:middle line:84% So if I want to make it succinct, I can't. 00:27:15.790 --> 00:27:20.770 align:middle line:84% So I want to be able, again, my goal, to take a proof 00:27:20.770 --> 00:27:24.280 align:middle line:84% and just shrink it and put it somewhere. 00:27:24.280 --> 00:27:29.380 align:middle line:84% Now, of course, you're like, OK, it's nice. 00:27:29.380 --> 00:27:31.520 align:middle line:90% It's good that you have desires. 00:27:31.520 --> 00:27:34.100 align:middle line:90% Well, it's good that you want. 00:27:34.100 --> 00:27:36.550 align:middle line:84% But actually, what's really interesting is 00:27:36.550 --> 00:27:38.570 align:middle line:84% that using the magic of cryptography, 00:27:38.570 --> 00:27:39.920 align:middle line:90% we can get these things. 00:27:39.920 --> 00:27:41.680 align:middle line:84% So now, what I'm going to do next 00:27:41.680 --> 00:27:44.620 align:middle line:84% is we're going to dive into the world of cryptography 00:27:44.620 --> 00:27:47.020 align:middle line:84% and see how we can use cryptography 00:27:47.020 --> 00:27:50.200 align:middle line:84% to get towards kind of these succinct, 00:27:50.200 --> 00:27:51.195 align:middle line:90% non-interactive proofs. 00:27:51.195 --> 00:28:03.250 align:middle line:90% 00:28:03.250 --> 00:28:04.430 align:middle line:90% OK, so let's start. 00:28:04.430 --> 00:28:08.170 align:middle line:84% So the first way we're going to change the proof model 00:28:08.170 --> 00:28:11.830 align:middle line:84% is to say to consider what we call 00:28:11.830 --> 00:28:15.130 align:middle line:84% computationally-sound proofs, also known 00:28:15.130 --> 00:28:17.180 align:middle line:90% in the literature as arguments. 00:28:17.180 --> 00:28:19.360 align:middle line:90% So let me explain. 00:28:19.360 --> 00:28:23.098 align:middle line:84% So instead of talking about statistical proofs, which 00:28:23.098 --> 00:28:24.640 align:middle line:84% is what we talked about so far, we're 00:28:24.640 --> 00:28:34.103 align:middle line:84% going to think about computationally-sound proofs. 00:28:34.103 --> 00:28:38.320 align:middle line:90% 00:28:38.320 --> 00:28:40.790 align:middle line:84% OK, so what is a computationally-sound proof? 00:28:40.790 --> 00:28:45.400 align:middle line:84% It's a proof that has a much weaker guarantee, soundness 00:28:45.400 --> 00:28:47.090 align:middle line:84% guarantees, than the standard one. 00:28:47.090 --> 00:28:49.568 align:middle line:90% So the completeness is the same. 00:28:49.568 --> 00:28:50.860 align:middle line:90% It's a proof you want to prove. 00:28:50.860 --> 00:28:53.060 align:middle line:84% If something is true, you succeed. 00:28:53.060 --> 00:28:56.843 align:middle line:84% But that soundness proof, so this is also called an argument. 00:28:56.843 --> 00:28:59.470 align:middle line:90% 00:28:59.470 --> 00:29:05.620 align:middle line:84% So the difference between a actual proof and an argument 00:29:05.620 --> 00:29:07.000 align:middle line:90% is in soundness. 00:29:07.000 --> 00:29:09.490 align:middle line:84% That's the only difference, the soundness condition. 00:29:09.490 --> 00:29:13.530 align:middle line:84% So let me just tell you what the soundness condition is here. 00:29:13.530 --> 00:29:16.780 align:middle line:84% So it's a computational soundness condition. 00:29:16.780 --> 00:29:24.030 align:middle line:90% 00:29:24.030 --> 00:29:30.480 align:middle line:84% And what it says is that, so let's say 00:29:30.480 --> 00:29:38.160 align:middle line:84% for some language L, what it says 00:29:38.160 --> 00:29:47.040 align:middle line:84% is that for any computationally-bounded, 00:29:47.040 --> 00:29:49.100 align:middle line:90% only if the prover is bounded. 00:29:49.100 --> 00:29:52.540 align:middle line:90% 00:29:52.540 --> 00:29:55.420 align:middle line:84% If you know that the prover is bound, 00:29:55.420 --> 00:30:01.150 align:middle line:84% resources are bounded, its computationally-bounded runtime. 00:30:01.150 --> 00:30:05.400 align:middle line:84% So only for a prover that's runtime is bounded, 00:30:05.400 --> 00:30:13.170 align:middle line:84% and for every x not in the language, the probability that p 00:30:13.170 --> 00:30:20.340 align:middle line:84% star, and v, and x that the verifier accepts is small. 00:30:20.340 --> 00:30:21.790 align:middle line:90% OK, let's say negligible. 00:30:21.790 --> 00:30:23.130 align:middle line:90% OK, smaller than half. 00:30:23.130 --> 00:30:25.050 align:middle line:90% Whatever. 00:30:25.050 --> 00:30:29.760 align:middle line:84% Usually in the language of arguments, 00:30:29.760 --> 00:30:33.370 align:middle line:84% we convert this constant to negligible and non-negligible. 00:30:33.370 --> 00:30:34.890 align:middle line:84% We'll talk about that in a minute. 00:30:34.890 --> 00:30:37.090 align:middle line:90% But now, we say, you know what? 00:30:37.090 --> 00:30:39.400 align:middle line:84% How do we get around all these negative results? 00:30:39.400 --> 00:30:41.670 align:middle line:84% So the idea, we say, you know what? 00:30:41.670 --> 00:30:46.980 align:middle line:84% Actually, why do we care that there exists a time 2 00:30:46.980 --> 00:30:50.490 align:middle line:84% to the 1,000 prover that can cheat? 00:30:50.490 --> 00:30:52.800 align:middle line:90% Nobody can run at that time. 00:30:52.800 --> 00:30:55.380 align:middle line:84% OK, there's not enough molecules in the universe. 00:30:55.380 --> 00:30:59.350 align:middle line:84% Like, there's no-- so these things, they don't exist. 00:30:59.350 --> 00:31:00.400 align:middle line:90% So why do we care? 00:31:00.400 --> 00:31:04.973 align:middle line:84% Let's only consider provers that run in bounded time. 00:31:04.973 --> 00:31:06.390 align:middle line:84% Now, you can say, what is bounded? 00:31:06.390 --> 00:31:07.370 align:middle line:90% We'll talk about that. 00:31:07.370 --> 00:31:08.597 align:middle line:90% Is bounded, what? 00:31:08.597 --> 00:31:09.680 align:middle line:90% There's an input length n? 00:31:09.680 --> 00:31:11.750 align:middle line:90% Is n and n cubed? 00:31:11.750 --> 00:31:12.510 align:middle line:90% 2 to the n? 00:31:12.510 --> 00:31:13.290 align:middle line:90% What's the bound? 00:31:13.290 --> 00:31:16.530 align:middle line:84% So yeah, each-- we'll talk how we bound it. 00:31:16.530 --> 00:31:19.380 align:middle line:84% But the first idea, let's bound his runtime. 00:31:19.380 --> 00:31:23.460 align:middle line:84% Let's consider a prover that is runtime we know is bounded. 00:31:23.460 --> 00:31:26.540 align:middle line:84% Now, let's try to argue soundness only 00:31:26.540 --> 00:31:28.405 align:middle line:90% against such provers. 00:31:28.405 --> 00:31:30.270 align:middle line:84% OK, so you take the bound to be something 00:31:30.270 --> 00:31:31.520 align:middle line:90% that you believe is realistic. 00:31:31.520 --> 00:31:32.963 align:middle line:90% Yes. 00:31:32.963 --> 00:31:34.880 align:middle line:84% AUDIENCE: Do we have some distribution over x? 00:31:34.880 --> 00:31:35.570 align:middle line:90% Or literally-- 00:31:35.570 --> 00:31:36.195 align:middle line:90% YAEL KALAI: No. 00:31:36.195 --> 00:31:36.910 align:middle line:90% For any x. 00:31:36.910 --> 00:31:37.410 align:middle line:90% So yeah. 00:31:37.410 --> 00:31:38.550 align:middle line:84% So the question is, just distribution? 00:31:38.550 --> 00:31:39.050 align:middle line:90% No. 00:31:39.050 --> 00:31:42.020 align:middle line:84% I still want to say, look, I don't 00:31:42.020 --> 00:31:44.280 align:middle line:84% want to say that you can cheat on any x. 00:31:44.280 --> 00:31:46.857 align:middle line:84% So look, I want the same guarantee. 00:31:46.857 --> 00:31:48.690 align:middle line:84% I want to have the same soundness guarantee. 00:31:48.690 --> 00:31:51.980 align:middle line:84% Say, look, nobody can convince you of any false statement. 00:31:51.980 --> 00:31:55.760 align:middle line:84% AUDIENCE: But couldn't your prover just, like, memorize 00:31:55.760 --> 00:31:58.925 align:middle line:90% the proof of some easy x? 00:31:58.925 --> 00:31:59.550 align:middle line:90% YAEL KALAI: OK. 00:31:59.550 --> 00:31:59.697 align:middle line:90% Good. 00:31:59.697 --> 00:31:59.845 align:middle line:90% Good. 00:31:59.845 --> 00:32:00.580 align:middle line:90% Good. 00:32:00.580 --> 00:32:01.080 align:middle line:90% Right. 00:32:01.080 --> 00:32:02.800 align:middle line:90% So you're saying, wait. 00:32:02.800 --> 00:32:03.620 align:middle line:90% What do you mean? 00:32:03.620 --> 00:32:06.730 align:middle line:84% If you have an x, you take a proof, and you put it there. 00:32:06.730 --> 00:32:09.500 align:middle line:90% I'm defining here-- yeah, so OK. 00:32:09.500 --> 00:32:15.375 align:middle line:84% So what you're saying is, you can't have this non-interactive. 00:32:15.375 --> 00:32:17.500 align:middle line:84% You're saying, if you want a non-interactive proof, 00:32:17.500 --> 00:32:19.280 align:middle line:84% this is impossible, even computationally. 00:32:19.280 --> 00:32:19.780 align:middle line:90% Why? 00:32:19.780 --> 00:32:21.260 align:middle line:90% I'm a cheating prover. 00:32:21.260 --> 00:32:24.260 align:middle line:84% I'm going to have one bad x, x on the language, 00:32:24.260 --> 00:32:26.350 align:middle line:84% I'm going to hardwire one bad proof 00:32:26.350 --> 00:32:27.530 align:middle line:90% because we assume it exists. 00:32:27.530 --> 00:32:28.520 align:middle line:90% It's just hard to find. 00:32:28.520 --> 00:32:29.050 align:middle line:90% Fine. 00:32:29.050 --> 00:32:29.690 align:middle line:90% It's one. 00:32:29.690 --> 00:32:32.250 align:middle line:84% So I can kind of think of a non-uniform model. 00:32:32.250 --> 00:32:36.080 align:middle line:84% I'm going to hardwire it, and now I'm going to give it. 00:32:36.080 --> 00:32:36.920 align:middle line:90% You're right. 00:32:36.920 --> 00:32:41.200 align:middle line:84% We do not have non-interactive proofs, 00:32:41.200 --> 00:32:42.620 align:middle line:90% computationally-sound proofs. 00:32:42.620 --> 00:32:44.090 align:middle line:90% But we almost do. 00:32:44.090 --> 00:32:45.190 align:middle line:90% Almost. 00:32:45.190 --> 00:32:47.465 align:middle line:84% So we'll talk about what I mean by almost. 00:32:47.465 --> 00:32:47.965 align:middle line:90% Yes. 00:32:47.965 --> 00:32:50.270 align:middle line:84% AUDIENCE: Is that one random [INAUDIBLE]? 00:32:50.270 --> 00:32:51.710 align:middle line:90% YAEL KALAI: Yeah, exactly. 00:32:51.710 --> 00:32:52.340 align:middle line:90% We, OK. 00:32:52.340 --> 00:32:55.270 align:middle line:84% So I'll jump ahead and say, the way 00:32:55.270 --> 00:32:57.843 align:middle line:84% we have it is we assume some common random string, 00:32:57.843 --> 00:32:58.760 align:middle line:90% some common reference. 00:32:58.760 --> 00:33:01.930 align:middle line:84% Let's say we all agree there is some hash function. 00:33:01.930 --> 00:33:03.760 align:middle line:84% And we're going to use this hash function 00:33:03.760 --> 00:33:05.980 align:middle line:90% when we construct the proofs. 00:33:05.980 --> 00:33:08.860 align:middle line:84% And now, we're going to argue the only way you can cheat 00:33:08.860 --> 00:33:11.110 align:middle line:90% is by breaking this function. 00:33:11.110 --> 00:33:17.030 align:middle line:84% So we are going to at the end get exactly what we want. 00:33:17.030 --> 00:33:18.530 align:middle line:84% So this is kind of jumping ahead. 00:33:18.530 --> 00:33:21.340 align:middle line:84% We will actually be able to construct these succinct 00:33:21.340 --> 00:33:24.680 align:middle line:90% proofs and non-interactive. 00:33:24.680 --> 00:33:27.670 align:middle line:84% However, we assume that both the verifier and the prover 00:33:27.670 --> 00:33:30.340 align:middle line:84% kind of agree on some common reference string 00:33:30.340 --> 00:33:31.645 align:middle line:90% that both agree. 00:33:31.645 --> 00:33:32.750 align:middle line:90% It's universal. 00:33:32.750 --> 00:33:34.090 align:middle line:90% It doesn't depend on x. 00:33:34.090 --> 00:33:35.090 align:middle line:90% It's some hash function. 00:33:35.090 --> 00:33:37.900 align:middle line:84% And we all agree it's same as chapter 56, whatever 00:33:37.900 --> 00:33:39.745 align:middle line:84% any kind of hard for those who do 00:33:39.745 --> 00:33:41.620 align:middle line:84% cryptography and are familiar with these kind 00:33:41.620 --> 00:33:42.985 align:middle line:90% of off-the-shelf hash functions. 00:33:42.985 --> 00:33:44.360 align:middle line:84% For those who don't, don't worry. 00:33:44.360 --> 00:33:44.620 align:middle line:90% Whatever. 00:33:44.620 --> 00:33:46.250 align:middle line:84% We agree on some reference string. 00:33:46.250 --> 00:33:49.870 align:middle line:84% And now, we're going to argue that if a cheating prover can 00:33:49.870 --> 00:33:52.940 align:middle line:84% come up with x not in the language, and a false proof, 00:33:52.940 --> 00:33:57.870 align:middle line:84% it means he broke something about the common reference 00:33:57.870 --> 00:33:58.770 align:middle line:90% string. 00:33:58.770 --> 00:34:00.960 align:middle line:90% So this kind of-- 00:34:00.960 --> 00:34:02.500 align:middle line:90% the idea is why-- 00:34:02.500 --> 00:34:04.150 align:middle line:90% so I already said it actually. 00:34:04.150 --> 00:34:06.580 align:middle line:84% But when you first think about it, you want to say, look. 00:34:06.580 --> 00:34:12.840 align:middle line:84% I want to get around the fact that ip is only p space, all 00:34:12.840 --> 00:34:14.350 align:middle line:90% these kind of barriers. 00:34:14.350 --> 00:34:17.020 align:middle line:84% I want to be able to construct these succinct proofs. 00:34:17.020 --> 00:34:18.219 align:middle line:90% Now, we know we can't. 00:34:18.219 --> 00:34:19.810 align:middle line:90% So we need to change the model. 00:34:19.810 --> 00:34:24.020 align:middle line:84% And one way we say no, let's consider bounded provers. 00:34:24.020 --> 00:34:24.520 align:middle line:90% Why not? 00:34:24.520 --> 00:34:27.460 align:middle line:84% Let's assume my prover runs in time less than 2 to the 500. 00:34:27.460 --> 00:34:28.835 align:middle line:90% Would anybody object? 00:34:28.835 --> 00:34:31.210 align:middle line:84% Is there any proof of the runtime more than 2 to the 500? 00:34:31.210 --> 00:34:31.710 align:middle line:90% No. 00:34:31.710 --> 00:34:32.260 align:middle line:90% So fine. 00:34:32.260 --> 00:34:33.659 align:middle line:90% We didn't lose anything. 00:34:33.659 --> 00:34:36.280 align:middle line:84% The question is, what did we gain? 00:34:36.280 --> 00:34:37.179 align:middle line:90% Is it easier? 00:34:37.179 --> 00:34:40.420 align:middle line:84% OK, we said the prover has to run time most 2 to the 500. 00:34:40.420 --> 00:34:43.679 align:middle line:90% So what-- how do we use that? 00:34:43.679 --> 00:34:45.630 align:middle line:84% And the reason we use that, the way 00:34:45.630 --> 00:34:47.350 align:middle line:84% we use that is using cryptography. 00:34:47.350 --> 00:34:50.280 align:middle line:84% Now, we can say our prover cannot break a cryptographic 00:34:50.280 --> 00:34:51.100 align:middle line:90% assumption. 00:34:51.100 --> 00:34:53.620 align:middle line:84% So we add some cryptographic assumption to our proofs. 00:34:53.620 --> 00:34:55.739 align:middle line:84% And we can assume that the prover can break it. 00:34:55.739 --> 00:34:57.510 align:middle line:90% Now, whoo. 00:34:57.510 --> 00:35:03.300 align:middle line:84% Like, a whole new world opened up to us, and which we can use. 00:35:03.300 --> 00:35:03.850 align:middle line:90% OK? 00:35:03.850 --> 00:35:10.240 align:middle line:84% So what I'm going to show you next is actually how to use-- 00:35:10.240 --> 00:35:12.330 align:middle line:90% so here is a theorem. 00:35:12.330 --> 00:35:16.630 align:middle line:84% I'm first going to show an interactive protocol. 00:35:16.630 --> 00:35:18.478 align:middle line:84% Still interactive, but very strong. 00:35:18.478 --> 00:35:20.020 align:middle line:84% So here's what I'm going to show you. 00:35:20.020 --> 00:35:34.980 align:middle line:84% This is a theorem due to a Kilian and Micali 92 and 94, 00:35:34.980 --> 00:35:38.670 align:middle line:84% which are really the kind of results that kind of laid 00:35:38.670 --> 00:35:41.280 align:middle line:90% the foundation for this field. 00:35:41.280 --> 00:35:43.390 align:middle line:84% And what they showed is the following. 00:35:43.390 --> 00:35:49.303 align:middle line:84% They showed how to take any PCP and some little cryptographic 00:35:49.303 --> 00:35:50.970 align:middle line:84% tool called the collision-resistant hash 00:35:50.970 --> 00:35:54.560 align:middle line:84% function, I'll define what that is, and take these two 00:35:54.560 --> 00:35:58.310 align:middle line:84% and construct a succinct four-message, so not 00:35:58.310 --> 00:36:02.610 align:middle line:84% non-interactive, four-message argument. 00:36:02.610 --> 00:36:04.410 align:middle line:90% So computationally-sound proof. 00:36:04.410 --> 00:36:06.920 align:middle line:84% So essentially, what they show is, 00:36:06.920 --> 00:36:12.110 align:middle line:84% give me this long PCP that can be efficiently checked. 00:36:12.110 --> 00:36:16.470 align:middle line:84% I'm going to use cryptography to kind of shrink this PCP, 00:36:16.470 --> 00:36:22.170 align:middle line:84% put it in a little box, send it to the verifier, 00:36:22.170 --> 00:36:25.340 align:middle line:84% and then convince the verifier that's what in this box 00:36:25.340 --> 00:36:26.700 align:middle line:90% is an accepting proof. 00:36:26.700 --> 00:36:31.310 align:middle line:84% So they use cryptography together with PCP 00:36:31.310 --> 00:36:40.100 align:middle line:84% to construct with the following, assuming 00:36:40.100 --> 00:36:42.020 align:middle line:84% collision-resistant hash function, 00:36:42.020 --> 00:36:46.050 align:middle line:84% I'll define in a minute, a cryptographic primitive. 00:36:46.050 --> 00:36:54.500 align:middle line:90% 00:36:54.500 --> 00:37:08.705 align:middle line:84% For any language in NP, there exists a four-message argument 00:37:08.705 --> 00:37:09.205 align:middle line:90% system. 00:37:09.205 --> 00:37:13.070 align:middle line:90% 00:37:13.070 --> 00:37:17.270 align:middle line:84% OK, now let me define the argument system more formally, 00:37:17.270 --> 00:37:19.970 align:middle line:84% because here was just kind of a bit-- 00:37:19.970 --> 00:37:21.030 align:middle line:90% And now, I'm-- 00:37:21.030 --> 00:37:24.410 align:middle line:90% 00:37:24.410 --> 00:37:25.302 align:middle line:90% OK. 00:37:25.302 --> 00:37:36.200 align:middle line:84% So when we talk about-- once we use cryptography, 00:37:36.200 --> 00:37:38.870 align:middle line:84% when cryptography comes along, then we 00:37:38.870 --> 00:37:40.770 align:middle line:84% use some cryptographic primitives. 00:37:40.770 --> 00:37:42.950 align:middle line:84% And these cryptographic primitives 00:37:42.950 --> 00:37:46.020 align:middle line:84% have some security parameter associated with them. 00:37:46.020 --> 00:37:52.060 align:middle line:84% The security parameter intuitively tells you how much-- 00:37:52.060 --> 00:37:59.770 align:middle line:84% so when I say I want, let's say, 100 bits of security, 00:37:59.770 --> 00:38:02.470 align:middle line:84% we usually in cryptography, essentially what we mean 00:38:02.470 --> 00:38:05.860 align:middle line:84% as a prover that runs in time 2 to the 100 cannot break 00:38:05.860 --> 00:38:06.940 align:middle line:90% the scheme. 00:38:06.940 --> 00:38:09.710 align:middle line:84% Or in time depends on the security, 00:38:09.710 --> 00:38:10.820 align:middle line:90% cannot break the scheme. 00:38:10.820 --> 00:38:14.260 align:middle line:84% So whereas statistically, we say when we say, 00:38:14.260 --> 00:38:17.900 align:middle line:84% we want a, I don't know, security epsilon, 00:38:17.900 --> 00:38:19.568 align:middle line:84% we say probability of breaking, any-- 00:38:19.568 --> 00:38:21.110 align:middle line:84% you can have whatever power you want. 00:38:21.110 --> 00:38:23.050 align:middle line:90% But the probability is epsilon. 00:38:23.050 --> 00:38:25.870 align:middle line:84% Once we're in crypto land, usually the security 00:38:25.870 --> 00:38:27.730 align:middle line:90% talks about the runtime. 00:38:27.730 --> 00:38:33.860 align:middle line:84% Like, what is the bound you place on the prover's runtime? 00:38:33.860 --> 00:38:36.910 align:middle line:84% And usually, we think of the soundness as negligible. 00:38:36.910 --> 00:38:41.410 align:middle line:84% OK, so negligible meaning smaller than any polynomial. 00:38:41.410 --> 00:38:43.430 align:middle line:90% I'll explain in more detail. 00:38:43.430 --> 00:38:46.330 align:middle line:84% But so when we talk about a cryptographic primitive, 00:38:46.330 --> 00:38:48.680 align:middle line:84% it's associated with the security perimeter. 00:38:48.680 --> 00:38:52.460 align:middle line:84% And we don't-- in practice, when they write things, they write, 00:38:52.460 --> 00:38:55.790 align:middle line:84% usually they just set security perimeter to be 128 bits, 00:38:55.790 --> 00:38:57.010 align:middle line:90% 256 bits. 00:38:57.010 --> 00:38:58.010 align:middle line:90% They set a number. 00:38:58.010 --> 00:39:00.800 align:middle line:84% But here, we're in complexity land. 00:39:00.800 --> 00:39:02.900 align:middle line:90% So we have a parameter, lambda. 00:39:02.900 --> 00:39:04.460 align:middle line:90% That's the security parameter. 00:39:04.460 --> 00:39:06.290 align:middle line:90% And we keep it as a parameter. 00:39:06.290 --> 00:39:10.100 align:middle line:84% And in real world, the people set it to their heart's desire. 00:39:10.100 --> 00:39:14.616 align:middle line:84% But we're going to think of it as a parameter here. 00:39:14.616 --> 00:39:16.360 align:middle line:90% OK, so here's the guarantee. 00:39:16.360 --> 00:39:19.900 align:middle line:90% 00:39:19.900 --> 00:39:23.438 align:middle line:84% OK, so this four-message argument system, 00:39:23.438 --> 00:39:25.230 align:middle line:84% let me start with the complexity, actually. 00:39:25.230 --> 00:39:30.130 align:middle line:90% 00:39:30.130 --> 00:39:40.720 align:middle line:84% The proof of runtime will be poly N, the instance length, 00:39:40.720 --> 00:39:43.010 align:middle line:90% and lambda security parameter. 00:39:43.010 --> 00:39:51.540 align:middle line:90% 00:39:51.540 --> 00:40:01.830 align:middle line:84% And v, runtime, is going to be only polling security parameter. 00:40:01.830 --> 00:40:08.960 align:middle line:84% And also in our case, also in the plus, VPCP runtime. 00:40:08.960 --> 00:40:12.030 align:middle line:90% 00:40:12.030 --> 00:40:14.370 align:middle line:84% So of course, he needs to read the input, 00:40:14.370 --> 00:40:16.775 align:middle line:84% and he needs behave like a PCP verifier. 00:40:16.775 --> 00:40:18.400 align:middle line:84% But the PCP verifier is very efficient. 00:40:18.400 --> 00:40:19.630 align:middle line:90% The problem is the Oracle. 00:40:19.630 --> 00:40:20.680 align:middle line:90% So now, there's Oracle. 00:40:20.680 --> 00:40:24.000 align:middle line:84% But his runtime is like the runtime of the PCP verifier, 00:40:24.000 --> 00:40:33.240 align:middle line:90% so which uses some PCP. 00:40:33.240 --> 00:40:37.080 align:middle line:84% And you can think of the PCP I just showed you, poly log n, 00:40:37.080 --> 00:40:38.910 align:middle line:90% poly log n. 00:40:38.910 --> 00:40:40.140 align:middle line:90% So we use some PCP. 00:40:40.140 --> 00:40:41.770 align:middle line:90% So that's the complexity. 00:40:41.770 --> 00:40:43.150 align:middle line:90% It's four messages. 00:40:43.150 --> 00:40:45.080 align:middle line:90% The prover runtime is efficient. 00:40:45.080 --> 00:40:47.510 align:middle line:90% And poly of course and in it. 00:40:47.510 --> 00:40:49.255 align:middle line:84% And the verifier is very efficient. 00:40:49.255 --> 00:40:52.320 align:middle line:84% AUDIENCE: So [INAUDIBLE] given the PCP or something? 00:40:52.320 --> 00:40:53.570 align:middle line:90% YAEL KALAI: Oh, Oh, Oh, sorry. 00:40:53.570 --> 00:40:59.730 align:middle line:84% P. Yeah, OK. sorry P given x and w and the witness. 00:40:59.730 --> 00:41:00.810 align:middle line:90% Yeah, thank, you. 00:41:00.810 --> 00:41:04.670 align:middle line:84% The prover is given x and the witness in the language. 00:41:04.670 --> 00:41:06.630 align:middle line:90% And he's going to be efficient. 00:41:06.630 --> 00:41:10.370 align:middle line:84% He's going to run in time n and lambda. 00:41:10.370 --> 00:41:13.240 align:middle line:84% Let me just mention, OK I mentioned that in a second 00:41:13.240 --> 00:41:13.740 align:middle line:90% actually. 00:41:13.740 --> 00:41:19.610 align:middle line:90% So the completeness is 2 00:41:19.610 --> 00:41:25.233 align:middle line:84% It just says that for every X, and L, and witness. 00:41:25.233 --> 00:41:28.610 align:middle line:90% 00:41:28.610 --> 00:41:35.840 align:middle line:84% W, the probability that P with witness W and V, both of them 00:41:35.840 --> 00:41:38.510 align:middle line:84% have X. And security parameter, there 00:41:38.510 --> 00:41:41.450 align:middle line:84% are some security parameters involved. 00:41:41.450 --> 00:41:45.680 align:middle line:84% The probability that the verifier outputs 1 is 1. 00:41:45.680 --> 00:41:48.398 align:middle line:84% So the verifier always accepts if you're honest. 00:41:48.398 --> 00:41:50.690 align:middle line:84% If the prover is honest, he has a witness corresponding 00:41:50.690 --> 00:41:54.890 align:middle line:84% to x with any security parameter he accepts. 00:41:54.890 --> 00:42:00.086 align:middle line:84% OK, actually, almost, it's assuming-- 00:42:00.086 --> 00:42:08.030 align:middle line:90% 00:42:08.030 --> 00:42:08.630 align:middle line:90% no. 00:42:08.630 --> 00:42:10.825 align:middle line:90% It accepts. 00:42:10.825 --> 00:42:11.900 align:middle line:90% No ifs and buts. 00:42:11.900 --> 00:42:16.310 align:middle line:90% OK, what about the soundness? 00:42:16.310 --> 00:42:29.135 align:middle line:84% Soundness says that for any p star of size, 00:42:29.135 --> 00:42:32.240 align:middle line:84% now, you can say, for instance, if size poly lambda, poly 00:42:32.240 --> 00:42:37.280 align:middle line:84% in the security parameter, then you can say, 00:42:37.280 --> 00:42:41.680 align:middle line:84% let's say that for every x not in the language, 00:42:41.680 --> 00:42:45.390 align:middle line:84% the probability that p star-- now, 00:42:45.390 --> 00:42:47.140 align:middle line:84% he doesn't have a witness because it's not 00:42:47.140 --> 00:42:48.020 align:middle line:90% in the language. 00:42:48.020 --> 00:42:48.860 align:middle line:90% This is a cheater. 00:42:48.860 --> 00:42:51.940 align:middle line:84% I want to say for any p star that tries to cheat. 00:42:51.940 --> 00:42:53.240 align:middle line:90% But he's bounded. 00:42:53.240 --> 00:42:54.730 align:middle line:90% He's poly lambda. 00:42:54.730 --> 00:42:59.080 align:middle line:84% And for every x not in the language, 00:42:59.080 --> 00:43:08.350 align:middle line:84% the probability and x in lambda that the verifier outputs 1 00:43:08.350 --> 00:43:09.680 align:middle line:90% is very small. 00:43:09.680 --> 00:43:14.440 align:middle line:90% It's negligible in lambda. 00:43:14.440 --> 00:43:17.050 align:middle line:84% And negligible in lambda is just a way 00:43:17.050 --> 00:43:21.980 align:middle line:84% to say it vanishes faster than 1 over poly for any poly. 00:43:21.980 --> 00:43:29.440 align:middle line:84% OK, this just means that for any poly p, 00:43:29.440 --> 00:43:36.190 align:middle line:84% there exists some lambda star such that for any lambda bigger 00:43:36.190 --> 00:43:47.200 align:middle line:84% than lambda star, p lambda, the negligible, 00:43:47.200 --> 00:43:51.010 align:middle line:90% is smaller than 1 over p lambda. 00:43:51.010 --> 00:43:54.830 align:middle line:84% So it vanishes faster than any poly 00:43:54.830 --> 00:43:57.750 align:middle line:90% if you go above some constant. 00:43:57.750 --> 00:43:58.250 align:middle line:90% OK? 00:43:58.250 --> 00:44:02.750 align:middle line:84% So the neg 0 it vanishes quicker than 1 over poly for any poly. 00:44:02.750 --> 00:44:04.250 align:middle line:84% That's the definition of negligible. 00:44:04.250 --> 00:44:04.690 align:middle line:90% Yeah. 00:44:04.690 --> 00:44:06.230 align:middle line:84% AUDIENCE: Interested in for what size means. 00:44:06.230 --> 00:44:08.230 align:middle line:84% So we're assuming all these things are circuits? 00:44:08.230 --> 00:44:10.590 align:middle line:90% 00:44:10.590 --> 00:44:11.290 align:middle line:90% YAEL KALAI: OK. 00:44:11.290 --> 00:44:11.500 align:middle line:90% Yeah. 00:44:11.500 --> 00:44:11.620 align:middle line:90% Yeah. 00:44:11.620 --> 00:44:11.770 align:middle line:90% Yeah. 00:44:11.770 --> 00:44:12.295 align:middle line:90% OK, good. 00:44:12.295 --> 00:44:12.400 align:middle line:90% Good. 00:44:12.400 --> 00:44:12.505 align:middle line:90% Good. 00:44:12.505 --> 00:44:12.610 align:middle line:90% Good. 00:44:12.610 --> 00:44:13.110 align:middle line:90% OK. 00:44:13.110 --> 00:44:15.740 align:middle line:84% Yeah, we're thinking of-- usually in cryptography, 00:44:15.740 --> 00:44:19.180 align:middle line:84% we always allow our adversaries to be non-uniform, 00:44:19.180 --> 00:44:20.660 align:middle line:90% because they may get advice. 00:44:20.660 --> 00:44:24.080 align:middle line:84% So usually, we model them as polynomial size circuits. 00:44:24.080 --> 00:44:29.060 align:middle line:84% This is opposed to saying p star that runs in time poly lambda. 00:44:29.060 --> 00:44:31.460 align:middle line:90% So we say has size poly lambda. 00:44:31.460 --> 00:44:34.240 align:middle line:84% It's just to say he has-- it's another word say, 00:44:34.240 --> 00:44:38.615 align:middle line:84% he runs in time poly lambda, but he may have advice. 00:44:38.615 --> 00:44:41.290 align:middle line:84% We allow him to have some kind of fixed advice. 00:44:41.290 --> 00:44:42.720 align:middle line:90% That's what we say size. 00:44:42.720 --> 00:44:43.875 align:middle line:90% Yeah. 00:44:43.875 --> 00:44:44.500 align:middle line:90% Great question. 00:44:44.500 --> 00:44:45.270 align:middle line:90% Yes. 00:44:45.270 --> 00:44:49.320 align:middle line:84% AUDIENCE: But if lambda is less than the size of x, how 00:44:49.320 --> 00:44:52.055 align:middle line:90% do you even fit in the x bits? 00:44:52.055 --> 00:44:54.582 align:middle line:90% 00:44:54.582 --> 00:44:55.290 align:middle line:90% YAEL KALAI: Good. 00:44:55.290 --> 00:44:57.120 align:middle line:90% OK, so OK. 00:44:57.120 --> 00:44:59.100 align:middle line:90% The problem is actually, yeah. 00:44:59.100 --> 00:45:01.800 align:middle line:90% The problem is we don't-- 00:45:01.800 --> 00:45:04.350 align:middle line:90% OK, what you're saying is, look. 00:45:04.350 --> 00:45:07.470 align:middle line:84% So that's why I have my red pen coming up, my red chalk. 00:45:07.470 --> 00:45:10.590 align:middle line:84% You're saying, if x is smaller than, let's say, lambda 00:45:10.590 --> 00:45:13.410 align:middle line:84% to the epsilon, if x is of size epsilon 00:45:13.410 --> 00:45:16.170 align:middle line:84% we allow p star to be of size poly. 00:45:16.170 --> 00:45:18.350 align:middle line:84% So what you're saying is I'm saying, wow. 00:45:18.350 --> 00:45:18.850 align:middle line:90% Wait. 00:45:18.850 --> 00:45:19.750 align:middle line:90% That's weird. 00:45:19.750 --> 00:45:23.380 align:middle line:84% You're not even allowing that if lambda is smaller than x, 00:45:23.380 --> 00:45:26.160 align:middle line:90% p star can't even read x. 00:45:26.160 --> 00:45:27.300 align:middle line:90% He can't even read it. 00:45:27.300 --> 00:45:29.700 align:middle line:90% His runtime is less than x. 00:45:29.700 --> 00:45:34.080 align:middle line:84% True if x is bigger than poly lambda, any poly lambda. 00:45:34.080 --> 00:45:37.150 align:middle line:84% That's first, because he can't run in any time. 00:45:37.150 --> 00:45:40.890 align:middle line:84% We allow p star to runs in time any poly lambda. 00:45:40.890 --> 00:45:46.350 align:middle line:84% So x can be of size any kind of if you take a sequence of x's 00:45:46.350 --> 00:45:48.660 align:middle line:84% that are each of size kind of for any lambda, if you 00:45:48.660 --> 00:45:50.740 align:middle line:84% have x sub la-- so I'm a cheating prover. 00:45:50.740 --> 00:45:53.820 align:middle line:84% And for any lambda, I have x sub lambda 00:45:53.820 --> 00:45:55.150 align:middle line:90% that I'm going to cheat on. 00:45:55.150 --> 00:45:57.150 align:middle line:84% And as long as these x sub lambda 00:45:57.150 --> 00:46:01.350 align:middle line:84% are at most lambda to the 100, I can run time lambda to the 100 00:46:01.350 --> 00:46:02.190 align:middle line:90% here. 00:46:02.190 --> 00:46:04.410 align:middle line:84% This is theory land, so I can do that. 00:46:04.410 --> 00:46:07.110 align:middle line:84% But sometimes, we want to actually 00:46:07.110 --> 00:46:11.520 align:middle line:84% have communication complexity, which is, like, poly log n. 00:46:11.520 --> 00:46:14.590 align:middle line:84% So now the security parameter needs to be poly log n. 00:46:14.590 --> 00:46:16.920 align:middle line:90% And now, you can't even read. 00:46:16.920 --> 00:46:25.980 align:middle line:84% So the reason I wrote size poly lambda is because this 00:46:25.980 --> 00:46:28.560 align:middle line:90% will allow us to have-- 00:46:28.560 --> 00:46:31.920 align:middle line:84% so the communication grows polynomial with lambda. 00:46:31.920 --> 00:46:35.970 align:middle line:84% If I allow the prover to run at most poly lambda, 00:46:35.970 --> 00:46:40.050 align:middle line:90% it will allow me to rely the-- 00:46:40.050 --> 00:46:42.815 align:middle line:84% I can assume that my cryptography, 00:46:42.815 --> 00:46:44.690 align:middle line:84% whatever I use here, collision-resistant hash 00:46:44.690 --> 00:46:47.630 align:middle line:84% function, or one-way function, whatever cryptographic 00:46:47.630 --> 00:46:52.650 align:middle line:84% assumption I use, the assumption is a polynomial time, 00:46:52.650 --> 00:46:55.850 align:middle line:84% a polynomial size, cheater cannot break it. 00:46:55.850 --> 00:46:58.740 align:middle line:84% But I can let me strengthen the assumption. 00:46:58.740 --> 00:46:59.940 align:middle line:90% I'm going to say that it-- 00:46:59.940 --> 00:47:03.200 align:middle line:90% 00:47:03.200 --> 00:47:07.430 align:middle line:84% so I'm going to say for every p star of size 2 to the lambda 00:47:07.430 --> 00:47:12.050 align:middle line:84% to the o of 1, as long as your running time at most 2 00:47:12.050 --> 00:47:19.380 align:middle line:84% to the lambda to epsilon to find some epsilon, you can't break. 00:47:19.380 --> 00:47:28.970 align:middle line:84% Now, x can be like a poly log n lambda. 00:47:28.970 --> 00:47:34.520 align:middle line:84% The thing is now, I'm assuming that a p star that runs in time, 00:47:34.520 --> 00:47:37.622 align:middle line:84% this cannot break my cryptography with security 00:47:37.622 --> 00:47:38.330 align:middle line:90% parameter lambda. 00:47:38.330 --> 00:47:40.240 align:middle line:90% It's a stronger assumption. 00:47:40.240 --> 00:47:44.300 align:middle line:84% So there is a delicate issue here with soundness, 00:47:44.300 --> 00:47:47.890 align:middle line:84% which I glossed over in the definition above, where I said, 00:47:47.890 --> 00:47:49.930 align:middle line:90% computationally bounded. 00:47:49.930 --> 00:47:51.380 align:middle line:90% Well, what's the bound? 00:47:51.380 --> 00:47:56.920 align:middle line:84% So again, the reason these computationally-sound proofs 00:47:56.920 --> 00:48:00.230 align:middle line:84% are useful is because then, we can use cryptography. 00:48:00.230 --> 00:48:02.050 align:middle line:84% So now, we say, let's use cryptography 00:48:02.050 --> 00:48:03.170 align:middle line:90% in our proof system. 00:48:03.170 --> 00:48:04.900 align:middle line:84% When we use cryptography, there's 00:48:04.900 --> 00:48:06.800 align:middle line:90% a security parameter, lambda. 00:48:06.800 --> 00:48:11.570 align:middle line:84% Now, typically, we assume that, so now, we want to say, 00:48:11.570 --> 00:48:13.040 align:middle line:84% our cryptography cannot be broken. 00:48:13.040 --> 00:48:14.830 align:middle line:84% And therefore, our scheme is secure. 00:48:14.830 --> 00:48:17.440 align:middle line:84% OK, cannot be broken in what time? 00:48:17.440 --> 00:48:19.360 align:middle line:84% So typically, we would like to say, 00:48:19.360 --> 00:48:21.230 align:middle line:84% oh in time poly lambda cannot be broken. 00:48:21.230 --> 00:48:22.730 align:middle line:84% That's kind of our polynomial assumption. 00:48:22.730 --> 00:48:24.897 align:middle line:84% That's kind of what we think of standard assumptions 00:48:24.897 --> 00:48:28.120 align:middle line:84% in cryptography, that some assumption with security 00:48:28.120 --> 00:48:30.650 align:middle line:84% parameter lambda cannot be broken time poly lambda. 00:48:30.650 --> 00:48:34.570 align:middle line:84% We call that a polynomial assumption. 00:48:34.570 --> 00:48:36.250 align:middle line:90% This is what we want. 00:48:36.250 --> 00:48:40.450 align:middle line:84% But then, you're right to say, well, it's weird, because then, 00:48:40.450 --> 00:48:44.440 align:middle line:84% if you want to think of lambda as being, like, poly log n, 00:48:44.440 --> 00:48:46.940 align:middle line:84% if you want, then they want succinct proofs. 00:48:46.940 --> 00:48:49.190 align:middle line:84% So let's say we have x of size n. 00:48:49.190 --> 00:48:51.580 align:middle line:84% And suppose we want the succinct to be like poly log n, 00:48:51.580 --> 00:48:53.500 align:middle line:90% like in GKR. 00:48:53.500 --> 00:48:58.430 align:middle line:84% So now, lambda needs to be of size poly log n in a sense. 00:48:58.430 --> 00:49:02.380 align:middle line:84% So it's like, wait, the cheating prover can't even read x. 00:49:02.380 --> 00:49:04.990 align:middle line:90% What a weird kind of-- 00:49:04.990 --> 00:49:09.420 align:middle line:84% so I'm-- the honest prover runs in time more than the cheating 00:49:09.420 --> 00:49:09.920 align:middle line:90% prover? 00:49:09.920 --> 00:49:11.650 align:middle line:90% That's bizarre. 00:49:11.650 --> 00:49:16.160 align:middle line:84% So the answer is, OK, so the answer is look. 00:49:16.160 --> 00:49:20.950 align:middle line:90% 00:49:20.950 --> 00:49:25.360 align:middle line:84% It depends on how much risk you're willing to take. 00:49:25.360 --> 00:49:27.120 align:middle line:90% What do I mean, how much risk? 00:49:27.120 --> 00:49:30.250 align:middle line:84% If you want to say, look, I'm very, very conservative. 00:49:30.250 --> 00:49:33.480 align:middle line:90% I'm not willing to assume-- 00:49:33.480 --> 00:49:35.830 align:middle line:84% my trust in cryptography is very limited, 00:49:35.830 --> 00:49:38.880 align:middle line:84% and I'm only willing to assume if I use a lambda bit 00:49:38.880 --> 00:49:42.360 align:middle line:84% of security, I want my assumption is that a poly lambda 00:49:42.360 --> 00:49:43.322 align:middle line:90% cannot break it. 00:49:43.322 --> 00:49:45.780 align:middle line:84% I don't want to assume that a 2-to-the-lambda person cannot 00:49:45.780 --> 00:49:46.990 align:middle line:84% break it, 2 to the lambda to the epsilon. 00:49:46.990 --> 00:49:47.890 align:middle line:90% No, maybe he can. 00:49:47.890 --> 00:49:49.980 align:middle line:90% I don't trust that assumption. 00:49:49.980 --> 00:49:53.160 align:middle line:84% That's all I'm willing to assume. 00:49:53.160 --> 00:49:55.830 align:middle line:90% Now, but here's the thing. 00:49:55.830 --> 00:49:57.960 align:middle line:84% Once you bound the cheating prover 00:49:57.960 --> 00:50:00.450 align:middle line:84% to be poly lambda, essentially, what we're saying 00:50:00.450 --> 00:50:04.110 align:middle line:84% is that in the world, there's no way you can 00:50:04.110 --> 00:50:05.530 align:middle line:90% run time more than poly lambda. 00:50:05.530 --> 00:50:09.205 align:middle line:84% If you can, then this has no meaning in a sense. 00:50:09.205 --> 00:50:10.330 align:middle line:90% So now, we're saying, look. 00:50:10.330 --> 00:50:13.510 align:middle line:84% In this world, you can't run more than this time. 00:50:13.510 --> 00:50:15.060 align:middle line:90% Whatever it is, this, this. 00:50:15.060 --> 00:50:17.460 align:middle line:84% Otherwise, this computationally bounded 00:50:17.460 --> 00:50:19.020 align:middle line:90% is, like, a bit meaningless. 00:50:19.020 --> 00:50:22.000 align:middle line:84% So if that's all the time you can run in, 00:50:22.000 --> 00:50:24.090 align:middle line:84% the x's are-- can't be bigger than that, 00:50:24.090 --> 00:50:26.560 align:middle line:84% in a sense, because nobody can run at that time. 00:50:26.560 --> 00:50:27.773 align:middle line:90% Nobody can read that x. 00:50:27.773 --> 00:50:30.190 align:middle line:84% So essentially, what you're saying is you're saying, look. 00:50:30.190 --> 00:50:31.898 align:middle line:84% I'm telling you, I want a cheating prover 00:50:31.898 --> 00:50:34.330 align:middle line:84% that runs in time at most 2 to the 500. 00:50:34.330 --> 00:50:36.780 align:middle line:84% You're saying, well, what if there's an input of length 2 00:50:36.780 --> 00:50:38.130 align:middle line:90% to the 1,000? 00:50:38.130 --> 00:50:39.250 align:middle line:90% OK, look. 00:50:39.250 --> 00:50:39.790 align:middle line:90% Whatever. 00:50:39.790 --> 00:50:42.420 align:middle line:84% He still can run a time when most 2 to the 500. 00:50:42.420 --> 00:50:44.770 align:middle line:84% The fact that I'm not going to give him more runtime, 00:50:44.770 --> 00:50:46.190 align:middle line:90% it's ridiculous. 00:50:46.190 --> 00:50:47.970 align:middle line:84% I still want to say, for every x. 00:50:47.970 --> 00:50:50.910 align:middle line:84% But I don't want to give now the prover more runtime. 00:50:50.910 --> 00:50:51.510 align:middle line:90% No. 00:50:51.510 --> 00:50:55.020 align:middle line:84% In this world, provers run in time at most some security. 00:50:55.020 --> 00:50:58.140 align:middle line:84% This is about the world, about the security of the world. 00:50:58.140 --> 00:51:01.890 align:middle line:84% I give a bound on what I think is a reasonable runtime 00:51:01.890 --> 00:51:05.460 align:middle line:90% of real-world adversaries. 00:51:05.460 --> 00:51:07.450 align:middle line:90% Nobody can run in more time. 00:51:07.450 --> 00:51:10.860 align:middle line:84% OK, now you're saying, well, it's weird. 00:51:10.860 --> 00:51:12.590 align:middle line:84% You're giving him less time than-- 00:51:12.590 --> 00:51:15.578 align:middle line:84% what if for an x that is size 2 to the 1,000, 00:51:15.578 --> 00:51:18.120 align:middle line:84% that honest prover, well, there is no honest prover that will 00:51:18.120 --> 00:51:22.200 align:middle line:84% prove something about x of size 2 the 1,000. 00:51:22.200 --> 00:51:25.370 align:middle line:84% So anyway we bound, and even if they're, 00:51:25.370 --> 00:51:27.900 align:middle line:84% like, x's that are bigger than this, 00:51:27.900 --> 00:51:30.140 align:middle line:84% yeah, our pool can't run in time bigger than this. 00:51:30.140 --> 00:51:34.100 align:middle line:84% Still, our poor guy needs to prove something about x that he 00:51:34.100 --> 00:51:34.950 align:middle line:90% cannot even read. 00:51:34.950 --> 00:51:35.540 align:middle line:90% Fine. 00:51:35.540 --> 00:51:38.490 align:middle line:84% The point is, in our world, these are our adversaries. 00:51:38.490 --> 00:51:41.900 align:middle line:84% That's how we should think of it. 00:51:41.900 --> 00:51:43.700 align:middle line:90% OK. 00:51:43.700 --> 00:51:44.810 align:middle line:90% Yeah. 00:51:44.810 --> 00:51:47.240 align:middle line:84% AUDIENCE: So the reason we're giving the honest prover 00:51:47.240 --> 00:51:48.698 align:middle line:84% this extra poly of n, is that we're 00:51:48.698 --> 00:51:51.073 align:middle line:84% assuming that they have to do something with the witness? 00:51:51.073 --> 00:51:51.680 align:middle line:90% Is that the-- 00:51:51.680 --> 00:51:52.513 align:middle line:90% YAEL KALAI: Exactly. 00:51:52.513 --> 00:51:55.530 align:middle line:84% So the prover, the honest prover, of course, 00:51:55.530 --> 00:51:56.810 align:middle line:90% he needs to read the witness. 00:51:56.810 --> 00:51:58.650 align:middle line:84% Essentially, he needs to look at the input, 00:51:58.650 --> 00:52:00.620 align:middle line:84% he needs to read the witness, he'll need to generate a PCP, 00:52:00.620 --> 00:52:01.170 align:middle line:90% or whatever. 00:52:01.170 --> 00:52:02.280 align:middle line:90% He needs to do something. 00:52:02.280 --> 00:52:05.370 align:middle line:84% So the honest prover, of course, he needs to run in time. 00:52:05.370 --> 00:52:06.990 align:middle line:90% That depends on x. 00:52:06.990 --> 00:52:08.820 align:middle line:84% But the point is you should think, OK, 00:52:08.820 --> 00:52:12.140 align:middle line:84% what if honest prover works with x and that is the size 2 00:52:12.140 --> 00:52:13.140 align:middle line:90% to the 1,000. 00:52:13.140 --> 00:52:14.640 align:middle line:90% Yeah, but it doesn't exist. 00:52:14.640 --> 00:52:15.270 align:middle line:90% It's a theory. 00:52:15.270 --> 00:52:17.350 align:middle line:90% It's a mental experiment. 00:52:17.350 --> 00:52:18.840 align:middle line:90% We don't have these things. 00:52:18.840 --> 00:52:19.400 align:middle line:90% But yeah. 00:52:19.400 --> 00:52:20.268 align:middle line:90% He would run. 00:52:20.268 --> 00:52:21.810 align:middle line:84% And now, you're saying our adversary? 00:52:21.810 --> 00:52:23.690 align:middle line:84% No, he can't run because our adversaries 00:52:23.690 --> 00:52:24.750 align:middle line:90% don't have that power. 00:52:24.750 --> 00:52:26.060 align:middle line:90% Nor do our honest prover. 00:52:26.060 --> 00:52:29.660 align:middle line:90% They don't exist for that sizes. 00:52:29.660 --> 00:52:30.450 align:middle line:90% Yeah. 00:52:30.450 --> 00:52:32.630 align:middle line:84% AUDIENCE: [INAUDIBLE] so before, when 00:52:32.630 --> 00:52:35.930 align:middle line:84% we were talking about the information theoretic, ips, 00:52:35.930 --> 00:52:39.380 align:middle line:84% and the soundness, I mentioned that as long as the soundness is 00:52:39.380 --> 00:52:41.957 align:middle line:84% less than a half or something, you can just repeat it over 00:52:41.957 --> 00:52:43.790 align:middle line:84% and over to get better and better soundness. 00:52:43.790 --> 00:52:44.090 align:middle line:90% YAEL KALAI: Yeah. 00:52:44.090 --> 00:52:44.570 align:middle line:90% And your-- 00:52:44.570 --> 00:52:45.290 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:52:45.290 --> 00:52:45.630 align:middle line:90% YAEL KALAI: Good. 00:52:45.630 --> 00:52:46.130 align:middle line:90% Yes. 00:52:46.130 --> 00:52:48.720 align:middle line:90% So Yes. 00:52:48.720 --> 00:52:50.130 align:middle line:90% The same applies here. 00:52:50.130 --> 00:52:57.530 align:middle line:84% So you can ask in a sense, why is here-- so OK. 00:52:57.530 --> 00:52:58.970 align:middle line:90% Let me-- it's yes. 00:52:58.970 --> 00:53:00.845 align:middle line:90% But we need to be careful. 00:53:00.845 --> 00:53:05.024 align:middle line:90% 00:53:05.024 --> 00:53:09.020 align:middle line:84% In a interactive argument, you can-- if the soundness here 00:53:09.020 --> 00:53:11.780 align:middle line:84% is only half, you can reduce soundness 00:53:11.780 --> 00:53:14.430 align:middle line:90% by repetition exponentially. 00:53:14.430 --> 00:53:18.440 align:middle line:84% However, you will need to do it sequentially. 00:53:18.440 --> 00:53:21.970 align:middle line:84% OK, so you'll need to do one interactive protocol 00:53:21.970 --> 00:53:24.890 align:middle line:84% after the other after the other after the other. 00:53:24.890 --> 00:53:29.680 align:middle line:84% Actually, it was a open question for a while was 00:53:29.680 --> 00:53:31.300 align:middle line:84% if you have an interactive argument, 00:53:31.300 --> 00:53:33.550 align:middle line:84% and you just-- because people don't like-- people care 00:53:33.550 --> 00:53:34.910 align:middle line:90% about round complexity. 00:53:34.910 --> 00:53:38.090 align:middle line:84% They don't like protocols that take a gazillion rounds. 00:53:38.090 --> 00:53:40.870 align:middle line:84% So they say, well, why don't you repeat interactive-- 00:53:40.870 --> 00:53:43.930 align:middle line:84% if you take an interactive proof and you repeat it 00:53:43.930 --> 00:53:46.540 align:middle line:84% in parallel many times with fresh randomness, everything 00:53:46.540 --> 00:53:50.020 align:middle line:84% fresh, just independently, but in parallel, the soundness go 00:53:50.020 --> 00:53:53.000 align:middle line:84% down exponentially like you want. 00:53:53.000 --> 00:53:56.170 align:middle line:84% Now, you can say, does the same thing hold for argument? 00:53:56.170 --> 00:53:59.720 align:middle line:84% So this was actually an open problem for a while. 00:53:59.720 --> 00:54:02.630 align:middle line:84% And then at some point-- it was a long time ago. 00:54:02.630 --> 00:54:07.930 align:middle line:84% It was when [Name] was a postdoc, probably 15 years ago. 00:54:07.930 --> 00:54:12.680 align:middle line:84% He actually gave an example of, oh, sorry. 00:54:12.680 --> 00:54:13.250 align:middle line:90% No, no, no. 00:54:13.250 --> 00:54:14.390 align:middle line:90% There was-- sorry. 00:54:14.390 --> 00:54:16.490 align:middle line:90% So there was an example. 00:54:16.490 --> 00:54:18.898 align:middle line:90% I'm messing up the-- 00:54:18.898 --> 00:54:21.650 align:middle line:84% Baioumy, Meo, and two other people. 00:54:21.650 --> 00:54:22.700 align:middle line:90% I don't remember now. 00:54:22.700 --> 00:54:24.260 align:middle line:90% They showed actually, no. 00:54:24.260 --> 00:54:28.780 align:middle line:84% There is an example of an interactive argument 00:54:28.780 --> 00:54:30.620 align:middle line:84% that if you repeat it in parallel, 00:54:30.620 --> 00:54:32.900 align:middle line:84% soundness doesn't go down at all. 00:54:32.900 --> 00:54:35.485 align:middle line:84% So you have to repeat it sequentially. 00:54:35.485 --> 00:54:38.890 align:middle line:84% So when you repeat interactive arguments in parallel, 00:54:38.890 --> 00:54:43.885 align:middle line:84% the crypto doesn't work in parallel as-- 00:54:43.885 --> 00:54:44.928 align:middle line:90% it's not really true. 00:54:44.928 --> 00:54:46.720 align:middle line:84% It's like, they're contrived examples where 00:54:46.720 --> 00:54:49.870 align:middle line:84% you can show that the crypto soundness doesn't 00:54:49.870 --> 00:54:51.425 align:middle line:90% reduce like you would hope. 00:54:51.425 --> 00:54:53.300 align:middle line:84% And therefore, the soundness doesn't go down. 00:54:53.300 --> 00:54:56.170 align:middle line:84% Now, the examples that we have are pretty contrived. 00:54:56.170 --> 00:54:56.720 align:middle line:90% OK? 00:54:56.720 --> 00:54:59.230 align:middle line:84% It's not like, but there's no-- definitely, it's 00:54:59.230 --> 00:55:00.110 align:middle line:90% not true in general. 00:55:00.110 --> 00:55:02.818 align:middle line:84% It's not true in general that if you take an interactive argument 00:55:02.818 --> 00:55:05.420 align:middle line:84% and you repeat it in parallel with fresh randomness, 00:55:05.420 --> 00:55:07.520 align:middle line:84% many times, soundness does not go down. 00:55:07.520 --> 00:55:11.140 align:middle line:84% Even though if [Tak?] showed that there is a way to repeat it 00:55:11.140 --> 00:55:13.640 align:middle line:84% in parallel, but you need to be a little clever. 00:55:13.640 --> 00:55:17.430 align:middle line:84% Don't just repeat-- a very weird trick he had of, 00:55:17.430 --> 00:55:19.590 align:middle line:84% with some probability, you abort. 00:55:19.590 --> 00:55:21.010 align:middle line:84% The verifier says, you know what-- 00:55:21.010 --> 00:55:23.080 align:middle line:84% I don't want to continue in this. 00:55:23.080 --> 00:55:24.225 align:middle line:90% Just a weird abort. 00:55:24.225 --> 00:55:25.600 align:middle line:84% He added a weird abort condition, 00:55:25.600 --> 00:55:29.830 align:middle line:84% and then all of a sudden, things kind of the soundness vanished. 00:55:29.830 --> 00:55:32.170 align:middle line:90% So OK. 00:55:32.170 --> 00:55:33.910 align:middle line:84% So I guess my answer to your question. 00:55:33.910 --> 00:55:36.130 align:middle line:84% If you repeat it in sequentially, yes. 00:55:36.130 --> 00:55:38.860 align:middle line:84% Air goes down exponentially exactly like we would hope. 00:55:38.860 --> 00:55:42.400 align:middle line:84% It goes from s to s to the k if you repeat it k times. 00:55:42.400 --> 00:55:45.040 align:middle line:84% If you repeat it in parallel naively, 00:55:45.040 --> 00:55:47.110 align:middle line:90% no in their counterexamples. 00:55:47.110 --> 00:55:51.280 align:middle line:84% Yet, there are ways to repeat in parallel a little less naively 00:55:51.280 --> 00:55:56.200 align:middle line:84% with some abort kind of thing that then it does go down. 00:55:56.200 --> 00:55:59.398 align:middle line:84% So I guess the short answer, it's complicated. 00:55:59.398 --> 00:55:59.940 align:middle line:90% AUDIENCE: OK. 00:55:59.940 --> 00:56:00.570 align:middle line:90% Thank you. 00:56:00.570 --> 00:56:01.570 align:middle line:90% YAEL KALAI: OK, great. 00:56:01.570 --> 00:56:04.110 align:middle line:84% But typically, we just write negligible 00:56:04.110 --> 00:56:05.230 align:middle line:90% because of this issue. 00:56:05.230 --> 00:56:09.570 align:middle line:84% It's like we like to just, we like 00:56:09.570 --> 00:56:11.820 align:middle line:84% to write-- when we talk in cryptography, we usually we 00:56:11.820 --> 00:56:15.000 align:middle line:84% write, 1 minus negligible, or 1 for completeness, 00:56:15.000 --> 00:56:19.310 align:middle line:84% and then negligible for soundness. 00:56:19.310 --> 00:56:24.750 align:middle line:90% OK, so this is the theorem. 00:56:24.750 --> 00:56:26.270 align:middle line:90% Any questions about-- 00:56:26.270 --> 00:56:31.010 align:middle line:84% I need to define what a collision-resistant hash 00:56:31.010 --> 00:56:31.950 align:middle line:90% function is. 00:56:31.950 --> 00:56:36.620 align:middle line:84% But any questions before I define? 00:56:36.620 --> 00:56:40.370 align:middle line:84% OK, so by the way, just so I know who I'm talking to, 00:56:40.370 --> 00:56:43.850 align:middle line:84% how many people know what a collision-resistant hash 00:56:43.850 --> 00:56:46.730 align:middle line:90% function is? 00:56:46.730 --> 00:56:48.012 align:middle line:90% OK, a lot. 00:56:48.012 --> 00:56:51.860 align:middle line:90% But it's actually not important. 00:56:51.860 --> 00:56:53.875 align:middle line:90% And I'll define it in a minute. 00:56:53.875 --> 00:56:58.550 align:middle line:90% 00:56:58.550 --> 00:57:01.268 align:middle line:90% OK. 00:57:01.268 --> 00:57:05.480 align:middle line:90% So let me just define. 00:57:05.480 --> 00:57:18.050 align:middle line:84% So a collision-resistant hash family, 00:57:18.050 --> 00:57:22.580 align:middle line:84% it's actually a family, it's not a function, h, 00:57:22.580 --> 00:57:24.676 align:middle line:90% consists of two algorithms. 00:57:24.676 --> 00:57:31.790 align:middle line:90% 00:57:31.790 --> 00:57:36.740 align:middle line:84% OK, first is Gen. Gen is an algorithm that generates 00:57:36.740 --> 00:57:38.250 align:middle line:90% a key to the hash function. 00:57:38.250 --> 00:57:40.860 align:middle line:90% So Gen takes his input. 00:57:40.860 --> 00:57:45.200 align:middle line:84% So Gen is a PPT, probabilistic polynomial time algorithm. 00:57:45.200 --> 00:57:53.790 align:middle line:84% It takes as input 1 to the security parameter. 00:57:53.790 --> 00:57:56.720 align:middle line:84% So in crypto, we have this hack that we 00:57:56.720 --> 00:58:00.320 align:middle line:84% assume our algorithms take as input 1 to the security 00:58:00.320 --> 00:58:03.788 align:middle line:84% parameter instead of security parameter, which is it's 00:58:03.788 --> 00:58:06.080 align:middle line:84% a bit like I feel like a moron saying 1 to the security 00:58:06.080 --> 00:58:06.630 align:middle line:90% parameter. 00:58:06.630 --> 00:58:07.910 align:middle line:84% The only reason we write it this way 00:58:07.910 --> 00:58:09.743 align:middle line:84% is because we want to think of our algorithm 00:58:09.743 --> 00:58:11.020 align:middle line:90% as efficient poly time. 00:58:11.020 --> 00:58:12.640 align:middle line:90% And poly is in the input. 00:58:12.640 --> 00:58:15.760 align:middle line:84% And all our algorithms run in time poly 00:58:15.760 --> 00:58:17.270 align:middle line:90% in the security parameter. 00:58:17.270 --> 00:58:20.720 align:middle line:84% So to say that our algorithms are efficient, our poly time, 00:58:20.720 --> 00:58:23.600 align:middle line:84% we always write the security parameter in unary 00:58:23.600 --> 00:58:24.650 align:middle line:90% because that's the input. 00:58:24.650 --> 00:58:29.500 align:middle line:84% So it's just kind of a hack to make the theory kind of nice. 00:58:29.500 --> 00:58:30.200 align:middle line:90% OK? 00:58:30.200 --> 00:58:35.080 align:middle line:90% And it outputs a hash key. 00:58:35.080 --> 00:58:37.930 align:middle line:84% So this hash key is a size poly lambda. 00:58:37.930 --> 00:58:40.760 align:middle line:84% Yeah, because this algorithm is polynomial, 00:58:40.760 --> 00:58:42.310 align:middle line:84% it takes an input lambda in unary. 00:58:42.310 --> 00:58:47.060 align:middle line:84% So it can output something only a size poly lambda. 00:58:47.060 --> 00:58:49.420 align:middle line:84% And then there's the eval algorithm. 00:58:49.420 --> 00:58:52.360 align:middle line:84% And the eval algorithm takes as input-- 00:58:52.360 --> 00:59:06.520 align:middle line:84% it's a poly time algorithm that takes as input hash key and x, 00:59:06.520 --> 00:59:08.190 align:middle line:90% any x, in 01 star. 00:59:08.190 --> 00:59:11.860 align:middle line:90% 00:59:11.860 --> 00:59:14.530 align:middle line:84% And it outputs, you can also restrict. 00:59:14.530 --> 00:59:19.160 align:middle line:84% You can restrict the x to be, let's say, you can restrict it. 00:59:19.160 --> 00:59:20.950 align:middle line:90% But let's think of any input. 00:59:20.950 --> 00:59:31.300 align:middle line:84% And outputs a value v in 01 to the lambda. 00:59:31.300 --> 00:59:32.255 align:middle line:90% OK, what's important? 00:59:32.255 --> 00:59:33.880 align:middle line:84% The way hash functions are used, what's 00:59:33.880 --> 00:59:36.260 align:middle line:84% important about hash functions is that they're shrinking. 00:59:36.260 --> 00:59:39.430 align:middle line:84% So you can think it takes an input any x, 00:59:39.430 --> 00:59:42.460 align:middle line:84% you can think of that it takes as input like something 00:59:42.460 --> 00:59:45.200 align:middle line:84% of size 2 lambda, like takes 2 lambda 2 lambda. 00:59:45.200 --> 00:59:47.450 align:middle line:84% You can even think lambda plus 1 2 lambda if you want. 00:59:47.450 --> 00:59:51.520 align:middle line:84% But so there's many ways people define it. 00:59:51.520 --> 00:59:54.040 align:middle line:90% Let me go with star any input. 00:59:54.040 --> 01:00:00.850 align:middle line:84% OK, and now, the security says that a polynomial time, 01:00:00.850 --> 01:00:07.770 align:middle line:84% or a poly size algorithm that is given a hash key should not 01:00:07.770 --> 01:00:12.400 align:middle line:84% be able to find two different x's that hash to the same value. 01:00:12.400 --> 01:00:13.750 align:middle line:90% That's the assumption. 01:00:13.750 --> 01:00:14.533 align:middle line:90% Yeah. 01:00:14.533 --> 01:00:16.450 align:middle line:84% AUDIENCE: Can the hash key be an empty string? 01:00:16.450 --> 01:00:18.090 align:middle line:90% YAEL KALAI: What? 01:00:18.090 --> 01:00:20.350 align:middle line:84% AUDIENCE: The hash key, can it be empty string? 01:00:20.350 --> 01:00:22.170 align:middle line:84% YAEL KALAI: It can be the empty string. 01:00:22.170 --> 01:00:23.920 align:middle line:84% But then, there's no-- it won't be secure. 01:00:23.920 --> 01:00:24.970 align:middle line:90% And I'll explain why. 01:00:24.970 --> 01:00:27.365 align:middle line:90% So it's a good question. 01:00:27.365 --> 01:00:28.240 align:middle line:90% It's a good question. 01:00:28.240 --> 01:00:30.115 align:middle line:84% The question, do we really need the hash key? 01:00:30.115 --> 01:00:32.250 align:middle line:90% Or can we just make that empty? 01:00:32.250 --> 01:00:38.250 align:middle line:84% So the answer is a bit-- it's again, it's a modeling answer. 01:00:38.250 --> 01:00:39.467 align:middle line:90% But I'll get to it. 01:00:39.467 --> 01:00:41.050 align:middle line:84% I'll answer your question in a second. 01:00:41.050 --> 01:00:43.330 align:middle line:90% Let me just write the security. 01:00:43.330 --> 01:00:47.610 align:middle line:84% And then we'll talk about it because it is a great question. 01:00:47.610 --> 01:00:54.150 align:middle line:84% OK, the security, the collision-resistant requirement, 01:00:54.150 --> 01:01:02.280 align:middle line:84% says that for any poly lambda size adversary 01:01:02.280 --> 01:01:11.220 align:middle line:84% A, the probability that A, given hash key, where hash key is 01:01:11.220 --> 01:01:19.530 align:middle line:84% chosen by Gen, the probability that it outputs x and x 01:01:19.530 --> 01:01:30.180 align:middle line:84% prime such that x is different, not the same, and eval 01:01:30.180 --> 01:01:36.540 align:middle line:84% of hash key and x is equal to eval of hash key and x 01:01:36.540 --> 01:01:41.340 align:middle line:90% prime is negligible. 01:01:41.340 --> 01:01:52.800 align:middle line:84% So for every poly size A, there exists a negligible function mu 01:01:52.800 --> 01:02:05.000 align:middle line:84% such that for every lambda security parameter, 01:02:05.000 --> 01:02:08.750 align:middle line:90% so maybe I'll write it better. 01:02:08.750 --> 01:02:10.420 align:middle line:90% For any poly size. 01:02:10.420 --> 01:02:13.430 align:middle line:90% 01:02:13.430 --> 01:02:17.250 align:middle line:84% For any poly size A, there exists some negative function. 01:02:17.250 --> 01:02:22.580 align:middle line:84% So a function that vanishes faster than any polynomial such 01:02:22.580 --> 01:02:28.460 align:middle line:84% that for any security parameter, if you generate a hash key using 01:02:28.460 --> 01:02:31.890 align:middle line:84% the security parameter, you give the adversary the hash key, 01:02:31.890 --> 01:02:35.690 align:middle line:84% his goal is to output two different inputs that 01:02:35.690 --> 01:02:37.110 align:middle line:90% hash to the same value. 01:02:37.110 --> 01:02:39.260 align:middle line:84% The probability that he does this 01:02:39.260 --> 01:02:44.780 align:middle line:90% is at most negligible in lambda. 01:02:44.780 --> 01:02:49.910 align:middle line:84% So as lambda grows big, this becomes tiny. 01:02:49.910 --> 01:02:50.510 align:middle line:90% Yeah. 01:02:50.510 --> 01:02:53.180 align:middle line:84% AUDIENCE: Is A's size meant to be polynomial in the hash key? 01:02:53.180 --> 01:02:53.660 align:middle line:90% YAEL KALAI: Good. 01:02:53.660 --> 01:02:54.060 align:middle line:90% Yes. 01:02:54.060 --> 01:02:54.450 align:middle line:90% Exactly. 01:02:54.450 --> 01:02:56.275 align:middle line:84% When I say poly size, I mean poly in the input. 01:02:56.275 --> 01:02:56.610 align:middle line:90% AUDIENCE: OK. 01:02:56.610 --> 01:02:57.735 align:middle line:90% YAEL KALAI: So poly lambda. 01:02:57.735 --> 01:02:58.580 align:middle line:90% AUDIENCE: OK. 01:02:58.580 --> 01:03:02.290 align:middle line:84% YAEL KALAI: OK, that's the definition. 01:03:02.290 --> 01:03:06.880 align:middle line:84% Now I want to first answer your question, which is, do we really 01:03:06.880 --> 01:03:07.610 align:middle line:90% need a hash key? 01:03:07.610 --> 01:03:09.910 align:middle line:84% Can we just tell him, this is the security parameter? 01:03:09.910 --> 01:03:11.300 align:middle line:90% Why do we need a hash key? 01:03:11.300 --> 01:03:13.850 align:middle line:84% And the answer is, actually, we don't-- 01:03:13.850 --> 01:03:14.750 align:middle line:90% it's interesting. 01:03:14.750 --> 01:03:16.400 align:middle line:90% We don't quite need a hash key. 01:03:16.400 --> 01:03:20.740 align:middle line:84% And actually, the hash functions we use in practice 01:03:20.740 --> 01:03:23.510 align:middle line:84% don't have a hash key in a sense. 01:03:23.510 --> 01:03:25.090 align:middle line:90% Well, they're fixed. 01:03:25.090 --> 01:03:26.750 align:middle line:84% OK, practice is a different story. 01:03:26.750 --> 01:03:32.110 align:middle line:84% But the reason why we have a hash key is we allow-- 01:03:32.110 --> 01:03:33.550 align:middle line:90% it's a question of modeling. 01:03:33.550 --> 01:03:34.940 align:middle line:90% Who is our adversary? 01:03:34.940 --> 01:03:37.700 align:middle line:84% What kind of adversaries are we thinking about? 01:03:37.700 --> 01:03:39.760 align:middle line:84% If we think about adversaries that 01:03:39.760 --> 01:03:44.380 align:middle line:84% are poly size, that are circuits, or Turing machines 01:03:44.380 --> 01:03:48.860 align:middle line:84% that have some non-uniform advice, then what 01:03:48.860 --> 01:03:51.430 align:middle line:84% if the adversary just has in his belly, somehow, 01:03:51.430 --> 01:03:53.560 align:middle line:84% someone gave him advice, x and x prime 01:03:53.560 --> 01:03:56.500 align:middle line:84% that are different and hash to the same value? 01:03:56.500 --> 01:03:59.047 align:middle line:84% Someone gave him two x's that hash to the same value. 01:03:59.047 --> 01:04:00.380 align:middle line:90% Then, he'll just [INAUDIBLE] it. 01:04:00.380 --> 01:04:02.110 align:middle line:90% Of course he has collisions. 01:04:02.110 --> 01:04:04.400 align:middle line:84% I mean, collisions exist by pigeonhole principle. 01:04:04.400 --> 01:04:05.320 align:middle line:90% I mean, huge, yeah? 01:04:05.320 --> 01:04:06.640 align:middle line:90% It goes to small. 01:04:06.640 --> 01:04:08.020 align:middle line:90% These exist. 01:04:08.020 --> 01:04:09.950 align:middle line:84% We want to say they're hard to find. 01:04:09.950 --> 01:04:13.393 align:middle line:84% But if we think of a non-uniform adversary that has advice, 01:04:13.393 --> 01:04:15.560 align:middle line:84% he may have this as advice and then he'll output it. 01:04:15.560 --> 01:04:18.050 align:middle line:84% So if we think of a non-uniform model, 01:04:18.050 --> 01:04:19.990 align:middle line:90% then we have to have a hash key. 01:04:19.990 --> 01:04:22.670 align:middle line:84% Another option is to think of a uniform model. 01:04:22.670 --> 01:04:25.490 align:middle line:84% Let's think of A not as poly sized, poly time. 01:04:25.490 --> 01:04:27.220 align:middle line:90% He's uniform. 01:04:27.220 --> 01:04:30.310 align:middle line:84% Then we don't need to have a hash key. 01:04:30.310 --> 01:04:33.880 align:middle line:84% We just, because we can assume that small axes don't collide 01:04:33.880 --> 01:04:38.440 align:middle line:84% because we'll just make the hash function so they won't collide. 01:04:38.440 --> 01:04:41.200 align:middle line:84% And then big ones, you can't hold in your belly 01:04:41.200 --> 01:04:42.957 align:middle line:90% because you're bounded. 01:04:42.957 --> 01:04:44.090 align:middle line:90% You're uniform. 01:04:44.090 --> 01:04:47.290 align:middle line:84% You have only constant sizes kind of your constant size 01:04:47.290 --> 01:04:50.000 align:middle line:90% description. 01:04:50.000 --> 01:04:53.530 align:middle line:84% So actually, there have been works 01:04:53.530 --> 01:04:57.690 align:middle line:84% in the literature in the theoretical cryptography 01:04:57.690 --> 01:05:02.620 align:middle line:84% literature that talk about hash functions with no keys. 01:05:02.620 --> 01:05:06.660 align:middle line:84% But then, they need to talk about uniform adversaries. 01:05:06.660 --> 01:05:10.540 align:middle line:84% And this is something that is considered and talked about. 01:05:10.540 --> 01:05:15.430 align:middle line:84% But the most standard is to talk about non-uniform adversaries. 01:05:15.430 --> 01:05:17.700 align:middle line:90% And then, we need to have keys. 01:05:17.700 --> 01:05:18.990 align:middle line:90% Yeah? 01:05:18.990 --> 01:05:20.970 align:middle line:90% OK. 01:05:20.970 --> 01:05:23.927 align:middle line:90% Any questions? 01:05:23.927 --> 01:05:24.427 align:middle line:90% OK. 01:05:24.427 --> 01:05:27.850 align:middle line:84% So oh, our time's up in five minutes. 01:05:27.850 --> 01:05:30.430 align:middle line:90% So good. 01:05:30.430 --> 01:05:36.190 align:middle line:84% So now, what I want to do is I want to prove this theorem 01:05:36.190 --> 01:05:39.660 align:middle line:84% and I want to give you a construction of a hash function 01:05:39.660 --> 01:05:40.690 align:middle line:90% that we use. 01:05:40.690 --> 01:05:43.950 align:middle line:84% Now, let me tell you, actually, we use a hash function 01:05:43.950 --> 01:05:45.700 align:middle line:90% with an additional property. 01:05:45.700 --> 01:05:47.670 align:middle line:84% For this theorem, we use a hash function 01:05:47.670 --> 01:05:49.030 align:middle line:90% with an additional property. 01:05:49.030 --> 01:05:52.500 align:middle line:84% We don't need to assume it because we can construct it 01:05:52.500 --> 01:05:54.100 align:middle line:90% from a hash function. 01:05:54.100 --> 01:05:56.580 align:middle line:84% So that's why I didn't write it as an assumption, 01:05:56.580 --> 01:05:57.880 align:middle line:90% because I can construct it. 01:05:57.880 --> 01:06:03.990 align:middle line:84% But really, the primitive we need for the theorem is we 01:06:03.990 --> 01:06:06.735 align:middle line:90% want an additional-- 01:06:06.735 --> 01:06:10.895 align:middle line:84% we want a hash function with what we call local opening. 01:06:10.895 --> 01:06:12.270 align:middle line:84% What do we mean by local opening? 01:06:12.270 --> 01:06:14.980 align:middle line:84% Here, a hash function, we say, look. 01:06:14.980 --> 01:06:19.200 align:middle line:84% There's an eval that takes a hash key x, output a value. 01:06:19.200 --> 01:06:21.970 align:middle line:84% Now, if you want to check, I'll give you-- 01:06:21.970 --> 01:06:23.470 align:middle line:90% let's say I hashed a value. 01:06:23.470 --> 01:06:25.900 align:middle line:84% I told you, here's v. Now, you're saying, 01:06:25.900 --> 01:06:27.660 align:middle line:84% OK, I want to know what you committed to. 01:06:27.660 --> 01:06:27.870 align:middle line:90% Fine. 01:06:27.870 --> 01:06:28.920 align:middle line:90% I can give you my x. 01:06:28.920 --> 01:06:31.962 align:middle line:90% And what you hash-- sorry. 01:06:31.962 --> 01:06:32.920 align:middle line:90% Which value you hashed? 01:06:32.920 --> 01:06:33.795 align:middle line:90% I'm like, no problem. 01:06:33.795 --> 01:06:36.180 align:middle line:90% Here's my x, and you can check. 01:06:36.180 --> 01:06:38.580 align:middle line:84% But what I really want for this theorem, 01:06:38.580 --> 01:06:41.910 align:middle line:84% and it's something I want from, this is a common primitive 01:06:41.910 --> 01:06:44.530 align:middle line:84% that we need in many applications, is I want to say, 01:06:44.530 --> 01:06:45.360 align:middle line:90% OK, I hashed-- 01:06:45.360 --> 01:06:46.480 align:middle line:90% I took a hash function. 01:06:46.480 --> 01:06:48.690 align:middle line:90% I hashed a value. 01:06:48.690 --> 01:06:51.100 align:middle line:84% I want to argue, look, I hashed a value. 01:06:51.100 --> 01:06:52.900 align:middle line:84% I don't want to give you my entire value. 01:06:52.900 --> 01:06:53.500 align:middle line:90% It's too big. 01:06:53.500 --> 01:06:54.792 align:middle line:90% You guys are not the verifiers. 01:06:54.792 --> 01:06:57.450 align:middle line:84% You can't even read everything I wrote in my-- 01:06:57.450 --> 01:06:58.890 align:middle line:90% I can't give you what I hashed. 01:06:58.890 --> 01:06:59.640 align:middle line:90% It's too big. 01:06:59.640 --> 01:07:01.110 align:middle line:90% I want to open one bit. 01:07:01.110 --> 01:07:03.660 align:middle line:84% I'm going to tell you, look, I hashed a value. 01:07:03.660 --> 01:07:09.530 align:middle line:84% But the ith bit of the value I hashed is 0. 01:07:09.530 --> 01:07:10.263 align:middle line:90% How do I know? 01:07:10.263 --> 01:07:11.430 align:middle line:90% How do you know that it's 0? 01:07:11.430 --> 01:07:12.780 align:middle line:90% Oh, I'm going to convince you. 01:07:12.780 --> 01:07:18.140 align:middle line:84% I can kind of give kind of a local opening to this x. 01:07:18.140 --> 01:07:19.800 align:middle line:90% This is what I want. 01:07:19.800 --> 01:07:22.980 align:middle line:84% So what I defined here is just a hash function. 01:07:22.980 --> 01:07:25.680 align:middle line:84% But then, I can define another primitive, 01:07:25.680 --> 01:07:28.143 align:middle line:84% which is a hash function with local opening. 01:07:28.143 --> 01:07:33.710 align:middle line:90% 01:07:33.710 --> 01:07:36.430 align:middle line:84% And that's what we actually need for the theorem. 01:07:36.430 --> 01:07:51.560 align:middle line:90% 01:07:51.560 --> 01:07:54.050 align:middle line:84% So a hash function with local opening 01:07:54.050 --> 01:07:57.860 align:middle line:84% has two additional algorithms corresponding to it. 01:07:57.860 --> 01:08:01.565 align:middle line:84% There is an open algorithm, which allows you kind of 01:08:01.565 --> 01:08:04.670 align:middle line:84% to open to show kind of a, essentially give you 01:08:04.670 --> 01:08:07.430 align:middle line:84% a little proof that the ith bit of what I hashed 01:08:07.430 --> 01:08:08.670 align:middle line:90% is a certain value. 01:08:08.670 --> 01:08:13.100 align:middle line:84% And then there's a verify algorithm that verifies it. 01:08:13.100 --> 01:08:16.220 align:middle line:84% OK, since we have only two minutes, I think I'll skip-- 01:08:16.220 --> 01:08:18.930 align:middle line:84% next time, I'll show you the local opening. 01:08:18.930 --> 01:08:23.703 align:middle line:84% But maybe I'll just tell you one minute of the idea behind-- 01:08:23.703 --> 01:08:29.600 align:middle line:90% 01:08:29.600 --> 01:08:31.080 align:middle line:90% is my theorem hiding somewhere? 01:08:31.080 --> 01:08:33.170 align:middle line:90% Maybe here? 01:08:33.170 --> 01:08:33.840 align:middle line:90% Oh yeah. 01:08:33.840 --> 01:08:34.340 align:middle line:90% Sorry. 01:08:34.340 --> 01:08:35.090 align:middle line:90% It's the opposite. 01:08:35.090 --> 01:08:36.779 align:middle line:90% OK, behind this theorem. 01:08:36.779 --> 01:08:40.910 align:middle line:84% So the idea is what I want to do is 01:08:40.910 --> 01:08:43.529 align:middle line:84% the idea at a high level, what they do, 01:08:43.529 --> 01:08:47.160 align:middle line:84% they take, the prover will take this ginormous PCP. 01:08:47.160 --> 01:08:48.660 align:middle line:84% He wants to give it to the verifier, 01:08:48.660 --> 01:08:50.189 align:middle line:90% but the verifier can't hold it. 01:08:50.189 --> 01:08:51.649 align:middle line:90% So what are you going to do? 01:08:51.649 --> 01:08:54.821 align:middle line:84% He's going to give him a hash of this PCP. 01:08:54.821 --> 01:08:56.779 align:middle line:84% Take this PCP and just give him the hash value. 01:08:56.779 --> 01:08:57.910 align:middle line:90% Just slam the bits. 01:08:57.910 --> 01:09:01.399 align:middle line:84% Now the verifier has this hash value. 01:09:01.399 --> 01:09:05.960 align:middle line:84% Now, in some sense, now, the prover-- 01:09:05.960 --> 01:09:07.540 align:middle line:84% now, the hash value, now the verifier 01:09:07.540 --> 01:09:09.950 align:middle line:84% is going to tell him, OK, thank you very much. 01:09:09.950 --> 01:09:13.310 align:middle line:84% I'm going to behave as a PCP verifier. 01:09:13.310 --> 01:09:16.340 align:middle line:84% So I'm going to generate randomness, 01:09:16.340 --> 01:09:21.020 align:middle line:84% ask to look at locations i1, i2, up to il in your PCP. 01:09:21.020 --> 01:09:22.109 align:middle line:90% Give me an opening. 01:09:22.109 --> 01:09:22.609 align:middle line:90% Show me. 01:09:22.609 --> 01:09:23.740 align:middle line:90% Show open-- 01:09:23.740 --> 01:09:24.950 align:middle line:90% Don't give me the entire PCP. 01:09:24.950 --> 01:09:26.120 align:middle line:90% I can't hold it. 01:09:26.120 --> 01:09:29.410 align:middle line:84% Give me only location i1, i2, up to il. 01:09:29.410 --> 01:09:32.300 align:middle line:84% Now, the prover-- once again, here, no problem. 01:09:32.300 --> 01:09:33.970 align:middle line:90% It's b1, b2, up to bl. 01:09:33.970 --> 01:09:36.220 align:middle line:84% But the verifier needs to be-- how does he 01:09:36.220 --> 01:09:39.290 align:middle line:84% know that it's indeed the opening of the hash? 01:09:39.290 --> 01:09:42.770 align:middle line:84% So we're going to use a hash function that you can open. 01:09:42.770 --> 01:09:45.170 align:middle line:84% So he's going to give him the bits with openings. 01:09:45.170 --> 01:09:45.670 align:middle line:90% See? 01:09:45.670 --> 01:09:47.740 align:middle line:84% Here's an opening, or a little proof, 01:09:47.740 --> 01:09:52.790 align:middle line:84% that in location i1 is sitting b1, location I2, 01:09:52.790 --> 01:09:55.210 align:middle line:84% I have B2, and so on and so forth. 01:09:55.210 --> 01:09:57.227 align:middle line:84% And then the verifier is just going 01:09:57.227 --> 01:09:58.810 align:middle line:84% to check the opening that they're good 01:09:58.810 --> 01:10:02.170 align:middle line:84% and accept if the PCP verifier accepts. 01:10:02.170 --> 01:10:04.720 align:middle line:84% So essentially, all the idea, you 01:10:04.720 --> 01:10:11.590 align:middle line:84% combine this PCP with kind of this cryptography technology 01:10:11.590 --> 01:10:14.770 align:middle line:84% that kind of smushes this PCP into a small thing, 01:10:14.770 --> 01:10:17.980 align:middle line:84% and allows you to kind of look kind of only at-- 01:10:17.980 --> 01:10:21.070 align:middle line:84% allows the prover, in a sense, to look 01:10:21.070 --> 01:10:23.530 align:middle line:84% only at specific locations computationally. 01:10:23.530 --> 01:10:25.030 align:middle line:84% Like, you can give him little proofs 01:10:25.030 --> 01:10:28.630 align:middle line:90% that open specific locations. 01:10:28.630 --> 01:10:29.427 align:middle line:90% And that's it. 01:10:29.427 --> 01:10:30.260 align:middle line:90% That's what you get. 01:10:30.260 --> 01:10:34.640 align:middle line:84% So next time, we're going to define the local opening, 01:10:34.640 --> 01:10:39.760 align:middle line:84% we're going to see the interactive argument in detail, 01:10:39.760 --> 01:10:43.450 align:middle line:84% and prove that it satisfies the guarantees written here. 01:10:43.450 --> 01:10:45.260 align:middle line:84% OK, so we'll see you next Friday. 01:10:45.260 --> 01:10:46.810 align:middle line:90% Thanks. 01:10:46.810 --> 01:10:48.000 align:middle line:90%