WEBVTT 00:00:00.000 --> 00:00:02.425 align:middle line:90% [SQUEAKING] 00:00:02.425 --> 00:00:04.850 align:middle line:90% [RUSTLING] 00:00:04.850 --> 00:00:12.930 align:middle line:90% [CLICKING] 00:00:12.930 --> 00:00:16.420 align:middle line:84% YAEL KALAI: So last week was crypto day, 00:00:16.420 --> 00:00:17.560 align:middle line:90% so I didn't get to see you. 00:00:17.560 --> 00:00:21.210 align:middle line:84% So let's do a quick kind of recap of where we were 00:00:21.210 --> 00:00:22.820 align:middle line:90% and where we're heading to. 00:00:22.820 --> 00:00:27.030 align:middle line:84% So last time I saw you, at least in this room, 00:00:27.030 --> 00:00:29.580 align:middle line:84% was two weeks ago, where we talked 00:00:29.580 --> 00:00:34.860 align:middle line:84% about how to use the GKR protocol to construct 00:00:34.860 --> 00:00:37.380 align:middle line:84% what's called a PCP, a Probabilistically Checkable 00:00:37.380 --> 00:00:37.932 align:middle line:90% Proof. 00:00:37.932 --> 00:00:39.890 align:middle line:84% And what's a probabilistically checkable proof? 00:00:39.890 --> 00:00:44.410 align:middle line:84% The idea is, take a proof-- so take any NP language, let's say, 00:00:44.410 --> 00:00:46.960 align:middle line:84% that has a proof, like, let's say, 3-SAT-- 00:00:46.960 --> 00:00:50.580 align:middle line:84% you take a witness or a proof, so a satisfying assignment, 00:00:50.580 --> 00:00:52.950 align:middle line:90% and you actually make it longer. 00:00:52.950 --> 00:00:54.582 align:middle line:90% OK, so you don't shrink it. 00:00:54.582 --> 00:00:55.540 align:middle line:90% You actually extend it. 00:00:55.540 --> 00:00:56.350 align:middle line:90% It's bigger. 00:00:56.350 --> 00:01:04.260 align:middle line:84% But now, to verify it, you don't need to read the entire proof. 00:01:04.260 --> 00:01:07.140 align:middle line:84% What you need to do is just read a few locations in this proof 00:01:07.140 --> 00:01:10.060 align:middle line:84% so you can-- even though the proof actually became longer, 00:01:10.060 --> 00:01:12.570 align:middle line:84% you can verify it much more efficiently 00:01:12.570 --> 00:01:14.520 align:middle line:90% by reading just a few locations. 00:01:14.520 --> 00:01:16.540 align:middle line:84% And we actually showed how to construct it, 00:01:16.540 --> 00:01:17.670 align:middle line:90% How do you get a PCP? 00:01:17.670 --> 00:01:22.030 align:middle line:84% And the idea of how to get a PCP, the idea was, well, 00:01:22.030 --> 00:01:24.000 align:middle line:84% let's look at the GKR protocol for 3-SAT-- 00:01:24.000 --> 00:01:26.785 align:middle line:90% so let's do a PCP for NP. 00:01:26.785 --> 00:01:27.285 align:middle line:90% OK. 00:01:27.285 --> 00:01:29.580 align:middle line:84% So any NP, you can convert it to a 3-SAT. 00:01:29.580 --> 00:01:32.790 align:middle line:84% You know 3-SAT is NP complete, so convert whatever you want 00:01:32.790 --> 00:01:34.930 align:middle line:90% to prove into a 3-SAT formula. 00:01:34.930 --> 00:01:36.220 align:middle line:90% Now you have a witness. 00:01:36.220 --> 00:01:37.540 align:middle line:90% Now what do you do? 00:01:37.540 --> 00:01:39.750 align:middle line:90% You want to generate a PCP. 00:01:39.750 --> 00:01:42.390 align:middle line:84% What you do is you pretend you're 00:01:42.390 --> 00:01:46.890 align:middle line:84% a GKR prover that has this witness, the satisfying 00:01:46.890 --> 00:01:51.450 align:middle line:84% assignment, and want to convince the verifier that this 00:01:51.450 --> 00:01:52.750 align:middle line:90% is a valid witness. 00:01:52.750 --> 00:01:55.420 align:middle line:84% So what do I mean by run the GKR protocol? 00:01:55.420 --> 00:01:57.210 align:middle line:90% What I mean is-- 00:01:57.210 --> 00:01:58.240 align:middle line:90% let's look at this. 00:01:58.240 --> 00:02:03.610 align:middle line:84% So given phi, let's say, a 3-SAT instance, what you do, 00:02:03.610 --> 00:02:06.790 align:middle line:84% you look at the circuit C sub phi, 00:02:06.790 --> 00:02:10.300 align:middle line:84% that takes as input a satisfying assignment, an assignment, 00:02:10.300 --> 00:02:13.550 align:middle line:84% and outputs 0 or 1 whether it's satisfying or not. 00:02:13.550 --> 00:02:16.190 align:middle line:84% This is a very low-depth circuit. 00:02:16.190 --> 00:02:18.610 align:middle line:84% It's just as kind of a bunch of checks 00:02:18.610 --> 00:02:21.760 align:middle line:84% and adds the local checks, and adds them all together. 00:02:21.760 --> 00:02:24.910 align:middle line:90% And now what we do is-- 00:02:24.910 --> 00:02:27.770 align:middle line:84% how do you generate the PCP given this witness, 00:02:27.770 --> 00:02:31.100 align:middle line:90% given this witness for phi? 00:02:31.100 --> 00:02:34.900 align:middle line:84% What you do is you run in your head 00:02:34.900 --> 00:02:37.160 align:middle line:84% the GKR protocol for the circuit. 00:02:37.160 --> 00:02:40.150 align:middle line:84% So remember, the GKR protocol is a protocol that proves that 00:02:40.150 --> 00:02:41.840 align:middle line:90% a low-depth circuit-- 00:02:41.840 --> 00:02:43.870 align:middle line:90% that an input is-- 00:02:43.870 --> 00:02:46.130 align:middle line:90% that a given input-- 00:02:46.130 --> 00:02:48.860 align:middle line:84% even though it's weird, the verifier doesn't know the input, 00:02:48.860 --> 00:02:52.310 align:middle line:84% so it's kind of weird to think of GKR in this context. 00:02:52.310 --> 00:02:55.670 align:middle line:84% GKR, the context of GKR was there's an input, 00:02:55.670 --> 00:02:58.280 align:middle line:84% everybody knows the input, the prover and the verifier, 00:02:58.280 --> 00:03:01.840 align:middle line:84% but the circuit is large and the prover 00:03:01.840 --> 00:03:05.880 align:middle line:84% wants to convince the verifier that the output is something. 00:03:05.880 --> 00:03:07.570 align:middle line:90% Here, it's kind of weird. 00:03:07.570 --> 00:03:10.910 align:middle line:84% The input is more or less as large as the circuit, OK, 00:03:10.910 --> 00:03:14.430 align:middle line:84% because checking if a witness is satisfying the assignment is 00:03:14.430 --> 00:03:16.800 align:middle line:90% valid for a 3-CNF. 00:03:16.800 --> 00:03:19.740 align:middle line:84% The 3-CNF is-- the circuit here is almost the same size 00:03:19.740 --> 00:03:21.460 align:middle line:90% as the witness. 00:03:21.460 --> 00:03:25.900 align:middle line:84% And so it seems like using GKR here is very weird. 00:03:25.900 --> 00:03:27.810 align:middle line:84% It doesn't seem like the right application. 00:03:27.810 --> 00:03:31.750 align:middle line:84% And in particular, the verifier doesn't even have the input, 00:03:31.750 --> 00:03:33.090 align:middle line:90% so how can you use GKR? 00:03:33.090 --> 00:03:37.380 align:middle line:84% That seems very counterintuitive. 00:03:37.380 --> 00:03:40.500 align:middle line:84% So the idea is, no, let's pretend that he does 00:03:40.500 --> 00:03:41.220 align:middle line:90% have the witness. 00:03:41.220 --> 00:03:42.470 align:middle line:90% And what do you mean, pretend? 00:03:42.470 --> 00:03:44.380 align:middle line:84% Oh, don't worry, we'll give it to him. 00:03:44.380 --> 00:03:47.320 align:middle line:84% So in the PCP, we'll write the witness. 00:03:47.320 --> 00:03:49.090 align:middle line:84% Not only we'll write the witness, 00:03:49.090 --> 00:03:51.340 align:middle line:84% we're going to actually write the low-degree extension 00:03:51.340 --> 00:03:52.780 align:middle line:90% of the witness in the PCP. 00:03:52.780 --> 00:03:54.560 align:middle line:90% OK, so what is your big proof? 00:03:54.560 --> 00:03:56.310 align:middle line:84% It first contains the low-degree extension 00:03:56.310 --> 00:03:58.390 align:middle line:90% of the witness sitting there. 00:03:58.390 --> 00:04:03.300 align:middle line:84% Then, now think of the GKR protocol. 00:04:03.300 --> 00:04:06.820 align:middle line:84% For each and every kind of question of the verifier, 00:04:06.820 --> 00:04:09.090 align:middle line:90% the prover has an answer. 00:04:09.090 --> 00:04:10.560 align:middle line:90% Write it down in the PCP. 00:04:10.560 --> 00:04:14.560 align:middle line:84% So in the PCP, write, if the first message of the verifier-- 00:04:14.560 --> 00:04:17.190 align:middle line:84% you know, the first message is a bunch of-- well, 00:04:17.190 --> 00:04:19.050 align:middle line:84% first, the approval goes first, so you send 00:04:19.050 --> 00:04:20.890 align:middle line:90% your univariate polynomial. 00:04:20.890 --> 00:04:23.380 align:middle line:84% Then the verifier sends a field element. 00:04:23.380 --> 00:04:26.170 align:middle line:84% Now we say, well, if the field element was 1, here's my answer. 00:04:26.170 --> 00:04:27.870 align:middle line:84% If the field element was 2, here's my answer. 00:04:27.870 --> 00:04:29.620 align:middle line:84% For each and every possible field element, 00:04:29.620 --> 00:04:30.735 align:middle line:90% you say the answer. 00:04:30.735 --> 00:04:31.235 align:middle line:90% OK. 00:04:31.235 --> 00:04:33.485 align:middle line:84% Now, if there's only polylog number of field elements, 00:04:33.485 --> 00:04:34.440 align:middle line:90% it's not so bad. 00:04:34.440 --> 00:04:35.050 align:middle line:90% OK. 00:04:35.050 --> 00:04:36.820 align:middle line:90% Then you give them the answer. 00:04:36.820 --> 00:04:40.290 align:middle line:84% Now the prover sends another field element. 00:04:40.290 --> 00:04:44.470 align:middle line:84% Now you say, for any possible next message, 00:04:44.470 --> 00:04:46.580 align:middle line:90% here's my answer, and so on. 00:04:46.580 --> 00:04:48.660 align:middle line:84% So, essentially, you kind of open up this GKR. 00:04:48.660 --> 00:04:50.460 align:middle line:90% It's a gigantic tree. 00:04:50.460 --> 00:04:52.540 align:middle line:84% Now, first, you say, wait, this is huge. 00:04:52.540 --> 00:04:54.990 align:middle line:90% Like, it's exponential. 00:04:54.990 --> 00:04:57.420 align:middle line:84% But actually, GKR has a very nice property 00:04:57.420 --> 00:05:01.410 align:middle line:84% that the prover's messages actually 00:05:01.410 --> 00:05:09.350 align:middle line:84% only depend on the last very few messages of the verifier. 00:05:09.350 --> 00:05:13.440 align:middle line:84% So if you remember the GKR, it's a bunch of sum-checks protocol. 00:05:13.440 --> 00:05:16.030 align:middle line:84% It's, like, just a sequence of sum checks, 00:05:16.030 --> 00:05:18.900 align:middle line:84% and the prover's message depends only 00:05:18.900 --> 00:05:21.510 align:middle line:84% on the messages in the last sum check. 00:05:21.510 --> 00:05:23.820 align:middle line:84% So it's kind of very few, and kind of 00:05:23.820 --> 00:05:26.590 align:middle line:84% where you start with, it's very few messages. 00:05:26.590 --> 00:05:31.120 align:middle line:84% So to be a little more precise, in GKR, 00:05:31.120 --> 00:05:42.350 align:middle line:84% each prover message depends on the last kind of-- 00:05:42.350 --> 00:05:51.620 align:middle line:84% what it is, it was "log n over log log n" messages from V, 00:05:51.620 --> 00:05:52.570 align:middle line:90% from the verifier. 00:05:52.570 --> 00:05:56.948 align:middle line:90% 00:05:56.948 --> 00:05:58.740 align:middle line:84% Well, this is like the number of variables. 00:05:58.740 --> 00:06:00.250 align:middle line:84% If you remember, when we did GKR, 00:06:00.250 --> 00:06:04.610 align:middle line:84% it was a bunch of sum checks, and each sum check was over m 00:06:04.610 --> 00:06:06.360 align:middle line:90% or 3m variables. 00:06:06.360 --> 00:06:08.170 align:middle line:90% This is the m. 00:06:08.170 --> 00:06:13.320 align:middle line:90% And the field is polylog n. 00:06:13.320 --> 00:06:14.980 align:middle line:84% And here is the size of the circuit. 00:06:14.980 --> 00:06:17.950 align:middle line:84% So think of it as, the size of the witness, 00:06:17.950 --> 00:06:20.710 align:middle line:84% the size of the 3-CNF, it's all up to polynomial factors. 00:06:20.710 --> 00:06:23.330 align:middle line:90% It doesn't matter. 00:06:23.330 --> 00:06:26.600 align:middle line:84% And so now, OK, you need to depend 00:06:26.600 --> 00:06:29.790 align:middle line:84% on all these messages from the verifier, 00:06:29.790 --> 00:06:31.820 align:middle line:84% but there's only that many each time. 00:06:31.820 --> 00:06:35.310 align:middle line:84% And if you look, this to the power of this is only poly. 00:06:35.310 --> 00:06:37.780 align:middle line:84% That's exactly how we chose H and n so it would be poly. 00:06:37.780 --> 00:06:40.280 align:middle line:84% That's why we chose this weird setting of parameters and not 00:06:40.280 --> 00:06:42.930 align:middle line:90% just 2n and log n. 00:06:42.930 --> 00:06:46.010 align:middle line:84% But the point is, because GKR has 00:06:46.010 --> 00:06:50.070 align:middle line:84% this kind of memoryless property of the prover, 00:06:50.070 --> 00:06:54.760 align:middle line:84% you can expand all the GKR into a big proof of size poly n. 00:06:54.760 --> 00:06:56.570 align:middle line:90% Now what does the verifier do? 00:06:56.570 --> 00:07:01.180 align:middle line:84% The verifier simply-- so that's what the PCP is. 00:07:01.180 --> 00:07:05.266 align:middle line:84% The PCP, you write for every possible kind of-- 00:07:05.266 --> 00:07:08.470 align:middle line:84% you write all the possible answers of the provers 00:07:08.470 --> 00:07:11.230 align:middle line:84% and the low-degree extension of your witness. 00:07:11.230 --> 00:07:13.090 align:middle line:90% That's what the PCP is. 00:07:13.090 --> 00:07:15.280 align:middle line:90% How do you verify this PCP? 00:07:15.280 --> 00:07:17.900 align:middle line:84% Well, you pretend you're a GKR proof verifier. 00:07:17.900 --> 00:07:20.910 align:middle line:84% You say, OK, let me see your first question, thank you. 00:07:20.910 --> 00:07:22.720 align:middle line:84% Now you're saying, I'm going to choose a random field element. 00:07:22.720 --> 00:07:24.090 align:middle line:84% And I'm going to look at the answer corresponding 00:07:24.090 --> 00:07:25.990 align:middle line:84% to this field element, and then I'm 00:07:25.990 --> 00:07:28.570 align:middle line:84% going to choose my next random field element. 00:07:28.570 --> 00:07:32.620 align:middle line:84% And you just go through this kind of tree 00:07:32.620 --> 00:07:35.890 align:middle line:84% randomly and make sure-- and at the end, you need to verify. 00:07:35.890 --> 00:07:40.010 align:middle line:84% If you remember, in GKR, at the end, you need to verify. 00:07:40.010 --> 00:07:43.173 align:middle line:84% To verify, you need to check your input and a random point 00:07:43.173 --> 00:07:44.340 align:middle line:90% in the low-degree extension. 00:07:44.340 --> 00:07:45.560 align:middle line:90% This is how GKR works. 00:07:45.560 --> 00:07:51.250 align:middle line:84% Well, you have the low-degree extension sitting there 00:07:51.250 --> 00:07:55.750 align:middle line:84% as part of your PCP, so you check that. 00:07:55.750 --> 00:07:59.150 align:middle line:84% OK, that's basically it, except there's one component that we're 00:07:59.150 --> 00:07:59.650 align:middle line:90% missing. 00:07:59.650 --> 00:08:02.750 align:middle line:84% And that's going to appear in your pset, which, by the way, 00:08:02.750 --> 00:08:05.026 align:middle line:90% is going to be out this weekend. 00:08:05.026 --> 00:08:07.960 align:middle line:84% OK, so this weekend, the pset is going to be out. 00:08:07.960 --> 00:08:11.333 align:middle line:84% Originally, the due date was after Thanksgiving. 00:08:11.333 --> 00:08:13.000 align:middle line:84% I'll move it to before, just to give you 00:08:13.000 --> 00:08:15.550 align:middle line:84% an incentive to not take it with you on your break. 00:08:15.550 --> 00:08:17.680 align:middle line:84% If anybody needs an extension, just let me know. 00:08:17.680 --> 00:08:18.180 align:middle line:90% OK. 00:08:18.180 --> 00:08:20.210 align:middle line:90% So you'll have almost a month? 00:08:20.210 --> 00:08:21.345 align:middle line:90% No, not quite, but close. 00:08:21.345 --> 00:08:21.845 align:middle line:90% OK. 00:08:21.845 --> 00:08:24.510 align:middle line:84% But if you need an extension, just let me know. 00:08:24.510 --> 00:08:27.070 align:middle line:90% This is very arbitrary. 00:08:27.070 --> 00:08:29.230 align:middle line:90% OK. 00:08:29.230 --> 00:08:29.780 align:middle line:90% OK. 00:08:29.780 --> 00:08:34.090 align:middle line:90% So what's the problem? 00:08:34.090 --> 00:08:38.809 align:middle line:84% The problem is, so if indeed the-- 00:08:38.809 --> 00:08:40.049 align:middle line:90% so what about soundness? 00:08:40.049 --> 00:08:40.549 align:middle line:90% OK. 00:08:40.549 --> 00:08:43.020 align:middle line:84% Soundness seems like it should follow from just GKR. 00:08:43.020 --> 00:08:43.520 align:middle line:90% OK. 00:08:43.520 --> 00:08:46.460 align:middle line:84% You're interacting with a prover, a GKR prover, 00:08:46.460 --> 00:08:48.710 align:middle line:84% and some should just follow from the GKR, 00:08:48.710 --> 00:08:51.420 align:middle line:84% except that there's one point here 00:08:51.420 --> 00:08:54.830 align:middle line:84% which is, What if the PCP prover doesn't give you 00:08:54.830 --> 00:08:56.700 align:middle line:84% a low-degree extension of some input? 00:08:56.700 --> 00:08:59.570 align:middle line:84% So if he gave you a low-degree extension of an input, 00:08:59.570 --> 00:09:04.092 align:middle line:84% and this input did not evaluate to 1-- namely, 00:09:04.092 --> 00:09:05.550 align:middle line:84% if he's not satisfying assignment-- 00:09:05.550 --> 00:09:07.250 align:middle line:84% then this input is not a valid witness, 00:09:07.250 --> 00:09:08.730 align:middle line:90% because one does not exist. 00:09:08.730 --> 00:09:12.980 align:middle line:84% In that case, of course, the soundness 00:09:12.980 --> 00:09:15.810 align:middle line:84% would really follow from GKR soundness. 00:09:15.810 --> 00:09:17.340 align:middle line:84% However, one needs to think, there 00:09:17.340 --> 00:09:21.180 align:middle line:84% may be a malicious prover who doesn't give you 00:09:21.180 --> 00:09:23.940 align:middle line:84% here a low-degree extension of some W. 00:09:23.940 --> 00:09:27.000 align:middle line:84% So what he should give you-- a low-degree extension of W, 00:09:27.000 --> 00:09:31.740 align:middle line:84% it means, like, some W goes from F to the m to F, 00:09:31.740 --> 00:09:34.720 align:middle line:84% and it's of degree H minus 1 in each variable. 00:09:34.720 --> 00:09:37.300 align:middle line:84% OK, if it's of degree h minus 1 in each variable, 00:09:37.300 --> 00:09:40.005 align:middle line:84% then it extends, it's a low-degree extension of kind 00:09:40.005 --> 00:09:42.900 align:middle line:90% of the W sitting kind of in-- 00:09:42.900 --> 00:09:46.860 align:middle line:84% so then W is just W sitting on H to the m. 00:09:46.860 --> 00:09:50.500 align:middle line:84% That's kind of the little cube where W is sitting. 00:09:50.500 --> 00:09:55.340 align:middle line:84% If, indeed, he gave you a low-degree extension of some W, 00:09:55.340 --> 00:09:56.340 align:middle line:90% then you're good. 00:09:56.340 --> 00:09:59.690 align:middle line:84% If this W that he gives you is of degree H minus 1 00:09:59.690 --> 00:10:01.320 align:middle line:84% in each variable, then you're good. 00:10:01.320 --> 00:10:04.560 align:middle line:90% But what if it's high degree? 00:10:04.560 --> 00:10:06.140 align:middle line:90% What if this W-- 00:10:06.140 --> 00:10:10.355 align:middle line:84% what if he gives you some W star which is very high degree? 00:10:10.355 --> 00:10:13.260 align:middle line:90% 00:10:13.260 --> 00:10:14.210 align:middle line:90% Then is it sound? 00:10:14.210 --> 00:10:16.820 align:middle line:90% 00:10:16.820 --> 00:10:19.610 align:middle line:84% So in the homework, you'll have exactly this. 00:10:19.610 --> 00:10:22.850 align:middle line:84% Actually, it's not sound, and you'll have to find, 00:10:22.850 --> 00:10:24.440 align:middle line:90% actually, an attack. 00:10:24.440 --> 00:10:27.210 align:middle line:84% And then there's a way to make sure. 00:10:27.210 --> 00:10:29.730 align:middle line:84% So now what the verifier needs to do in addition 00:10:29.730 --> 00:10:32.040 align:middle line:84% is to do what is called a low-degree test. 00:10:32.040 --> 00:10:37.880 align:middle line:84% It's a test that verifies that this W star has low degree. 00:10:37.880 --> 00:10:39.980 align:middle line:84% OK, so this is what the homework assignment, 00:10:39.980 --> 00:10:43.060 align:middle line:84% or one part of the homework assignment, is about. 00:10:43.060 --> 00:10:43.560 align:middle line:90% OK. 00:10:43.560 --> 00:10:45.720 align:middle line:84% But this is-- imagine we're making sure 00:10:45.720 --> 00:10:47.970 align:middle line:84% that this is-- actually, the verifier can't make sure 00:10:47.970 --> 00:10:51.210 align:middle line:84% it's low degree, but it can make sure it's close to a low degree. 00:10:51.210 --> 00:10:54.675 align:middle line:84% So it agrees with some low-degree W 00:10:54.675 --> 00:10:57.730 align:middle line:84% on, like, 1 minus epsilon fraction of the points. 00:10:57.730 --> 00:11:00.160 align:middle line:84% So you can test that it's very close to low degree. 00:11:00.160 --> 00:11:02.535 align:middle line:84% If it's very close to low degree, then, most likely, 00:11:02.535 --> 00:11:04.660 align:middle line:84% wherever you'll ask-- because you'll ask randomly-- 00:11:04.660 --> 00:11:06.480 align:middle line:84% it agrees with kind of the low degree, 00:11:06.480 --> 00:11:09.660 align:middle line:84% and therefore, that's kind of the idea. 00:11:09.660 --> 00:11:10.620 align:middle line:90% OK. 00:11:10.620 --> 00:11:14.522 align:middle line:84% But this is the PCP, and the verification just 00:11:14.522 --> 00:11:15.480 align:middle line:90% adds a low-degree test. 00:11:15.480 --> 00:11:18.390 align:middle line:84% And we'll expand on that in the pset. 00:11:18.390 --> 00:11:19.536 align:middle line:90% OK. 00:11:19.536 --> 00:11:22.990 align:middle line:84% So that's kind of what we did most of the class, 00:11:22.990 --> 00:11:25.390 align:middle line:84% and then at the end, we talked about-- 00:11:25.390 --> 00:11:29.320 align:middle line:84% OK, so now we have a gigantic PCP. 00:11:29.320 --> 00:11:30.430 align:middle line:90% It's very large. 00:11:30.430 --> 00:11:33.660 align:middle line:84% But you can verify it by looking at very few locations, which 00:11:33.660 --> 00:11:34.390 align:middle line:90% is nice. 00:11:34.390 --> 00:11:35.460 align:middle line:90% How many locations? 00:11:35.460 --> 00:11:39.360 align:middle line:84% Like the communication complexity of the GKR, 00:11:39.360 --> 00:11:45.390 align:middle line:84% which on circuits of depth log n or order log n-- which is, 00:11:45.390 --> 00:11:47.220 align:middle line:90% for example, 3-SAT-- 00:11:47.220 --> 00:11:50.290 align:middle line:84% then the communication complexity is polylog n. 00:11:50.290 --> 00:11:52.470 align:middle line:84% So you can verify this by reading 00:11:52.470 --> 00:11:56.650 align:middle line:84% only polylog-n locations, as opposed to n locations, 00:11:56.650 --> 00:11:59.490 align:middle line:84% so it's, like, an exponential improvement. 00:11:59.490 --> 00:12:01.830 align:middle line:84% But again, you have this gigantic PCP. 00:12:01.830 --> 00:12:05.340 align:middle line:84% And now the question is, OK, but who's going to-- note, 00:12:05.340 --> 00:12:08.910 align:middle line:84% here's something to just make sure you understand. 00:12:08.910 --> 00:12:12.810 align:middle line:84% It's very important that this PCP is kind of 00:12:12.810 --> 00:12:16.650 align:middle line:90% given to the verifier before-- 00:12:16.650 --> 00:12:19.660 align:middle line:84% if the verifier-- so, OK, the PCP is very large. 00:12:19.660 --> 00:12:23.410 align:middle line:84% Now, one can say, OK, don't send the PCP. 00:12:23.410 --> 00:12:25.090 align:middle line:84% I'll tell you what my queries are. 00:12:25.090 --> 00:12:28.180 align:middle line:84% Just give me the answers to my queries instead of sending me-- 00:12:28.180 --> 00:12:30.670 align:middle line:84% anyway, I'm not going to read them, so why send it over? 00:12:30.670 --> 00:12:32.640 align:middle line:84% Just send me the answers to my queries. 00:12:32.640 --> 00:12:34.680 align:middle line:90% That will not be sound. 00:12:34.680 --> 00:12:39.670 align:middle line:84% If the verifier, if the prover gets to choose the answers based 00:12:39.670 --> 00:12:41.860 align:middle line:84% on all the queries that he sees, soundness 00:12:41.860 --> 00:12:44.880 align:middle line:90% breaks down completely. 00:12:44.880 --> 00:12:45.380 align:middle line:90% OK. 00:12:45.380 --> 00:12:47.690 align:middle line:84% And so it's very important that he first 00:12:47.690 --> 00:12:51.825 align:middle line:84% tells you what the PCP is and then you query it. 00:12:51.825 --> 00:12:52.325 align:middle line:90% OK. 00:12:52.325 --> 00:12:56.840 align:middle line:84% In particular, the damaging-- the way the cheating prover can 00:12:56.840 --> 00:12:59.490 align:middle line:90% cheat is by-- 00:12:59.490 --> 00:13:04.370 align:middle line:84% you know, when you tell him, give me the PCP in location i, 00:13:04.370 --> 00:13:06.693 align:middle line:84% if you ask for it together with location j, 00:13:06.693 --> 00:13:07.860 align:middle line:90% it will give you one answer. 00:13:07.860 --> 00:13:09.600 align:middle line:84% But if you ask it for location j prime, 00:13:09.600 --> 00:13:10.933 align:middle line:90% it will give you another answer. 00:13:10.933 --> 00:13:12.463 align:middle line:90% That's how it can cheat. 00:13:12.463 --> 00:13:14.130 align:middle line:84% But if he needs to fix it ahead of time, 00:13:14.130 --> 00:13:15.520 align:middle line:90% then, no, it's one answer-- 00:13:15.520 --> 00:13:18.090 align:middle line:84% doesn't matter the other locations you ask-- 00:13:18.090 --> 00:13:21.530 align:middle line:84% and that's what makes this sound. 00:13:21.530 --> 00:13:22.030 align:middle line:90% OK. 00:13:22.030 --> 00:13:24.670 align:middle line:84% And you can actually go back to GKR and see, 00:13:24.670 --> 00:13:27.490 align:middle line:84% if you use this PCP with GKR, where you give the queries ahead 00:13:27.490 --> 00:13:30.230 align:middle line:84% of time, you give the sum-check queries all ahead of time, 00:13:30.230 --> 00:13:32.210 align:middle line:84% everything breaks down completely. 00:13:32.210 --> 00:13:32.710 align:middle line:90% OK. 00:13:32.710 --> 00:13:34.420 align:middle line:84% So it's very important that you first 00:13:34.420 --> 00:13:36.160 align:middle line:90% commit it to this entire PCP. 00:13:36.160 --> 00:13:38.800 align:middle line:84% And then one can ask, well, if you 00:13:38.800 --> 00:13:42.500 align:middle line:84% give this-- how does the-- so the entire thing says, look, 00:13:42.500 --> 00:13:44.420 align:middle line:90% the verifier is a weak device. 00:13:44.420 --> 00:13:45.290 align:middle line:90% That's the idea. 00:13:45.290 --> 00:13:45.820 align:middle line:90% He's weak. 00:13:45.820 --> 00:13:47.320 align:middle line:90% He cannot do the computation. 00:13:47.320 --> 00:13:50.340 align:middle line:84% How can we store this gigantic PCP? 00:13:50.340 --> 00:13:52.270 align:middle line:84% So it seems like, well, that's very nice, 00:13:52.270 --> 00:13:54.690 align:middle line:90% but how do we use this thing? 00:13:54.690 --> 00:13:57.102 align:middle line:84% And the way we use this thing, the way it's used today-- 00:13:57.102 --> 00:13:59.310 align:middle line:84% these things are used today, and the way they're used 00:13:59.310 --> 00:14:00.630 align:middle line:90% is using cryptography. 00:14:00.630 --> 00:14:03.510 align:middle line:84% So what we do, we use cryptography 00:14:03.510 --> 00:14:07.420 align:middle line:84% to take this gigantic proof and squish it. 00:14:07.420 --> 00:14:07.920 align:middle line:90% OK. 00:14:07.920 --> 00:14:10.830 align:middle line:84% And this is used using what's called collision resistant hash 00:14:10.830 --> 00:14:11.970 align:middle line:90% functions. 00:14:11.970 --> 00:14:14.130 align:middle line:84% So this is what we're going to kind of-- we're 00:14:14.130 --> 00:14:15.917 align:middle line:90% going to talk about today. 00:14:15.917 --> 00:14:18.250 align:middle line:84% We started last time, but we're going to continue today. 00:14:18.250 --> 00:14:20.910 align:middle line:84% But before we go into how we squish it and make 00:14:20.910 --> 00:14:24.412 align:middle line:84% kind of everything succinct, let me first-- 00:14:24.412 --> 00:14:28.290 align:middle line:84% once we use cryptography, we can no longer 00:14:28.290 --> 00:14:32.520 align:middle line:84% get soundness against any all-bounded kind of cheating 00:14:32.520 --> 00:14:36.600 align:middle line:84% prover, because cryptography can be broken 00:14:36.600 --> 00:14:40.300 align:middle line:90% by all-powerful adversaries. 00:14:40.300 --> 00:14:43.470 align:middle line:84% Cryptography assumes the adversary is not strong enough 00:14:43.470 --> 00:14:45.955 align:middle line:84% to break our assumptions-- for example, 00:14:45.955 --> 00:14:47.830 align:middle line:84% the collisions and hash function that we saw, 00:14:47.830 --> 00:14:49.440 align:middle line:90% and we'll review it in a second. 00:14:49.440 --> 00:14:52.090 align:middle line:84% So now, when we talk about proof systems, 00:14:52.090 --> 00:14:56.830 align:middle line:84% we need to relax the notion of what we mean by a proof system. 00:14:56.830 --> 00:14:58.610 align:middle line:84% By the way, who's scribing today? 00:14:58.610 --> 00:14:59.110 align:middle line:90% Ah. 00:14:59.110 --> 00:15:00.940 align:middle line:90% OK, great. 00:15:00.940 --> 00:15:04.150 align:middle line:84% We need to relax the notion of what we mean by a proof system 00:15:04.150 --> 00:15:07.090 align:middle line:84% to what's called a computationally sound proof 00:15:07.090 --> 00:15:07.730 align:middle line:90% system. 00:15:07.730 --> 00:15:10.900 align:middle line:84% Namely, you cannot cheat, assuming you're polynomially 00:15:10.900 --> 00:15:11.630 align:middle line:90% bounded. 00:15:11.630 --> 00:15:14.000 align:middle line:84% If you're all powerful, you can break my crypto-- 00:15:14.000 --> 00:15:15.140 align:middle line:90% no guarantees. 00:15:15.140 --> 00:15:17.840 align:middle line:84% But as long as you cannot break my crypto, you cannot cheat. 00:15:17.840 --> 00:15:19.340 align:middle line:90% So I just wrote it here. 00:15:19.340 --> 00:15:21.130 align:middle line:90% This is copied from last time. 00:15:21.130 --> 00:15:24.310 align:middle line:84% So instead of interactive proof, we called it an interactive 00:15:24.310 --> 00:15:27.640 align:middle line:84% argument, and we say that an interactive argument for some 00:15:27.640 --> 00:15:29.792 align:middle line:84% language L-- think of it, let's say, NP language, 00:15:29.792 --> 00:15:31.750 align:middle line:84% but whatever language you want to think about-- 00:15:31.750 --> 00:15:35.260 align:middle line:84% is a protocol between a proof and a verifier. 00:15:35.260 --> 00:15:36.880 align:middle line:90% The completeness is the usual. 00:15:36.880 --> 00:15:39.960 align:middle line:84% Namely, if x is in the language, then you'll 00:15:39.960 --> 00:15:41.685 align:middle line:84% convince the verifier with probability 1. 00:15:41.685 --> 00:15:42.185 align:middle line:90% OK. 00:15:42.185 --> 00:15:45.870 align:middle line:84% And if it's an NP and you know a witness, you're also efficient. 00:15:45.870 --> 00:15:46.670 align:middle line:90% OK. 00:15:46.670 --> 00:15:49.290 align:middle line:84% The soundness, that's where the change is. 00:15:49.290 --> 00:15:51.930 align:middle line:84% Instead of soundness, you get some computational version 00:15:51.930 --> 00:15:54.240 align:middle line:84% of soundness, and the computational version 00:15:54.240 --> 00:15:56.220 align:middle line:90% of soundness says the following. 00:15:56.220 --> 00:15:59.520 align:middle line:84% It says there's some parameter, a security parameter-- when 00:15:59.520 --> 00:16:01.020 align:middle line:84% you're talking cryptography, there's 00:16:01.020 --> 00:16:03.930 align:middle line:84% always a security parameter-- which kind of says, 00:16:03.930 --> 00:16:09.270 align:middle line:84% How much time do we believe real-world adversaries can 00:16:09.270 --> 00:16:10.170 align:middle line:90% run in? 00:16:10.170 --> 00:16:11.550 align:middle line:90% OK. 00:16:11.550 --> 00:16:18.128 align:middle line:84% So what the soundness says, that any real-world cheating prover-- 00:16:18.128 --> 00:16:20.670 align:middle line:84% real-world meaning it runs in time polynomial in the security 00:16:20.670 --> 00:16:21.665 align:middle line:90% parameter. 00:16:21.665 --> 00:16:25.290 align:middle line:84% So we're going to denote the security parameter by lambda 00:16:25.290 --> 00:16:27.280 align:middle line:90% throughout this class. 00:16:27.280 --> 00:16:29.850 align:middle line:84% Sometimes they call it by n, and sometimes k. 00:16:29.850 --> 00:16:31.450 align:middle line:84% Here, n is going to be input size, 00:16:31.450 --> 00:16:34.480 align:middle line:84% so I don't want to-- so we're just going to use lambda. 00:16:34.480 --> 00:16:38.230 align:middle line:84% So for any P star of size polynomial in the security 00:16:38.230 --> 00:16:42.840 align:middle line:84% parameter, he can win only with negligible probability. 00:16:42.840 --> 00:16:45.780 align:middle line:84% Namely, there exists a negligible function mu-- again, 00:16:45.780 --> 00:16:49.910 align:middle line:84% negligible means it's smaller than any inverse polynomial-- 00:16:49.910 --> 00:16:53.000 align:middle line:84% such that no matter which security parameter 00:16:53.000 --> 00:16:54.740 align:middle line:90% you use, and any x-- 00:16:54.740 --> 00:16:56.970 align:middle line:90% so think about the P star. 00:16:56.970 --> 00:16:58.770 align:middle line:84% He's polynomial in the security parameter. 00:16:58.770 --> 00:17:01.790 align:middle line:90% He chooses an x adversarially. 00:17:01.790 --> 00:17:04.579 align:middle line:84% The probability-- or, an x is chosen, OK. 00:17:04.579 --> 00:17:05.329 align:middle line:90% It exists. 00:17:05.329 --> 00:17:09.268 align:middle line:84% For any x, the probability that he convinces-- now, 00:17:09.268 --> 00:17:11.310 align:middle line:84% the protocol dependent on the security parameter, 00:17:11.310 --> 00:17:13.730 align:middle line:84% so the verifier, may choose, like, a hash function, 00:17:13.730 --> 00:17:15.630 align:middle line:84% according to the security parameter. 00:17:15.630 --> 00:17:17.550 align:middle line:84% So everybody knows the security parameter. 00:17:17.550 --> 00:17:20.730 align:middle line:84% Everyone runs in time polynomial in the security parameter. 00:17:20.730 --> 00:17:23.420 align:middle line:84% And that's why we give it as input, the security parameter, 00:17:23.420 --> 00:17:25.190 align:middle line:90% in unary. 00:17:25.190 --> 00:17:30.170 align:middle line:84% So an input x and security parameter-- there's a protocol, 00:17:30.170 --> 00:17:33.320 align:middle line:84% and the probability that this cheating prover convinces 00:17:33.320 --> 00:17:38.340 align:middle line:84% the verifier to accept is this negligible function mu. 00:17:38.340 --> 00:17:38.920 align:middle line:90% OK. 00:17:38.920 --> 00:17:43.830 align:middle line:84% So again, we offer soundness only for poly-lambda cheating 00:17:43.830 --> 00:17:44.420 align:middle line:90% provers. 00:17:44.420 --> 00:17:44.920 align:middle line:90% OK. 00:17:44.920 --> 00:17:46.878 align:middle line:84% So now you should think of the cheating provers 00:17:46.878 --> 00:17:49.630 align:middle line:84% as like a family of provers, one for every lambda. 00:17:49.630 --> 00:17:50.130 align:middle line:90% OK. 00:17:50.130 --> 00:17:52.210 align:middle line:84% It's like a friendly security parameter. 00:17:52.210 --> 00:17:54.190 align:middle line:84% You're allowed to give a cheating prover. 00:17:54.190 --> 00:17:58.896 align:middle line:84% But they all, let's say, run in time at most lambda to the 10, 00:17:58.896 --> 00:18:00.580 align:middle line:90% OK, so polynomial in lambda. 00:18:00.580 --> 00:18:03.830 align:middle line:90% 00:18:03.830 --> 00:18:07.294 align:middle line:84% Any questions about the review before we go on to the new-- 00:18:07.294 --> 00:18:08.590 align:middle line:90% to today? 00:18:08.590 --> 00:18:11.230 align:middle line:90% 00:18:11.230 --> 00:18:11.892 align:middle line:90% Yeah? 00:18:11.892 --> 00:18:13.600 align:middle line:84% AUDIENCE: Just, again, so here, the proof 00:18:13.600 --> 00:18:16.945 align:middle line:84% is not showing you, like, hide the witness or x [INAUDIBLE]? 00:18:16.945 --> 00:18:17.570 align:middle line:90% YAEL KALAI: No. 00:18:17.570 --> 00:18:18.150 align:middle line:90% No, no, no. 00:18:18.150 --> 00:18:18.470 align:middle line:90% Good, good, good. 00:18:18.470 --> 00:18:20.428 align:middle line:84% So, two things-- first of all, we're not at all 00:18:20.428 --> 00:18:21.580 align:middle line:90% talking about hiding. 00:18:21.580 --> 00:18:25.147 align:middle line:84% If we didn't want succinctness, you 00:18:25.147 --> 00:18:27.230 align:middle line:84% can tell the proof will just give you the witness. 00:18:27.230 --> 00:18:27.770 align:middle line:90% Here you go. 00:18:27.770 --> 00:18:28.730 align:middle line:90% Check on your own. 00:18:28.730 --> 00:18:32.855 align:middle line:84% OK, but we'll want another property 00:18:32.855 --> 00:18:34.480 align:middle line:84% from these interactive arguments, which 00:18:34.480 --> 00:18:38.590 align:middle line:84% is succinctness, yeah, succinctness or-- 00:18:38.590 --> 00:18:41.140 align:middle line:84% yeah, exactly, for NP, for example. 00:18:41.140 --> 00:18:42.893 align:middle line:90% And-- yeah? 00:18:42.893 --> 00:18:45.310 align:middle line:84% AUDIENCE: So 3-SAT, I take it that means Boolean formulas? 00:18:45.310 --> 00:18:46.393 align:middle line:90% YAEL KALAI: Yeah, exactly. 00:18:46.393 --> 00:18:48.220 align:middle line:84% 3-SAT is just-- think of it, it's-- 00:18:48.220 --> 00:18:52.190 align:middle line:90% exactly, just three CNFs. 00:18:52.190 --> 00:18:54.310 align:middle line:90% It's the AND of a bunch of-- 00:18:54.310 --> 00:18:55.760 align:middle line:90% of a bunch of clauses. 00:18:55.760 --> 00:19:01.314 align:middle line:84% Each one is like, xi1 OR xi2 OR not xi3. 00:19:01.314 --> 00:19:04.620 align:middle line:84% AUDIENCE: And do you get it with a small enough depth? 00:19:04.620 --> 00:19:08.460 align:middle line:84% YAEL KALAI: Yeah, so any 3-CNF, any 3-CNF is of the form, like, 00:19:08.460 --> 00:19:16.280 align:middle line:84% clause 1 AND clause 2 AND clause n, let's say. 00:19:16.280 --> 00:19:21.080 align:middle line:84% You can get a Boolean formula with fan-in 2 of size order 00:19:21.080 --> 00:19:27.090 align:middle line:84% log m, because you just do kind of the AND, AND, you know, 00:19:27.090 --> 00:19:28.080 align:middle line:90% all the ANDs. 00:19:28.080 --> 00:19:30.670 align:middle line:84% And then you have these little literals at the bottom, 00:19:30.670 --> 00:19:32.410 align:middle line:90% and each one is constant size. 00:19:32.410 --> 00:19:33.160 align:middle line:90% It just depends. 00:19:33.160 --> 00:19:35.610 align:middle line:90% Each clause is constant size. 00:19:35.610 --> 00:19:43.230 align:middle line:90% So it's really a log-m circuit. 00:19:43.230 --> 00:19:47.160 align:middle line:84% OK, so you can take any 3-SAT, which is just an AND of a bunch 00:19:47.160 --> 00:19:51.840 align:middle line:84% of literals, and write it as a log-depth circuit. 00:19:51.840 --> 00:19:56.260 align:middle line:84% AUDIENCE: So can you go directly to some j 00:19:56.260 --> 00:20:00.810 align:middle line:84% and do the PCP over some j by doing the parameterization 00:20:00.810 --> 00:20:02.945 align:middle line:90% instead going through GKR? 00:20:02.945 --> 00:20:03.570 align:middle line:90% YAEL KALAI: OK. 00:20:03.570 --> 00:20:06.300 align:middle line:84% To get a PCP, I need to go-- the way 00:20:06.300 --> 00:20:08.780 align:middle line:84% I construct the PCP is by going through GKR. 00:20:08.780 --> 00:20:11.910 align:middle line:84% I do a GKR on this kind of circuit, 00:20:11.910 --> 00:20:15.540 align:middle line:84% I open up all the possible provers' messages, 00:20:15.540 --> 00:20:18.300 align:middle line:84% and that's what constitutes the PCP, in addition 00:20:18.300 --> 00:20:20.020 align:middle line:84% to the low-degree extension of the input. 00:20:20.020 --> 00:20:21.910 align:middle line:90% That's going to be the PCP. 00:20:21.910 --> 00:20:24.130 align:middle line:84% And the verifier just kind of verifies, 00:20:24.130 --> 00:20:30.350 align:middle line:84% behaves like the verifier, and checks that the witness he gets, 00:20:30.350 --> 00:20:34.000 align:middle line:84% the extended witness, is of low degree. 00:20:34.000 --> 00:20:35.560 align:middle line:90% Like, it does a low-degree test. 00:20:35.560 --> 00:20:37.310 align:middle line:84% The low-degree test, we didn't talk about, 00:20:37.310 --> 00:20:40.000 align:middle line:84% but it's going to be in the homework. 00:20:40.000 --> 00:20:42.010 align:middle line:90% So that's how the PCP works. 00:20:42.010 --> 00:20:44.620 align:middle line:84% And now I'm kind of talking about how 00:20:44.620 --> 00:20:49.300 align:middle line:84% you use this long PCP together with cryptography to get 00:20:49.300 --> 00:20:50.760 align:middle line:90% these succinct arguments. 00:20:50.760 --> 00:20:52.270 align:middle line:84% That's kind of the next step, How 00:20:52.270 --> 00:20:55.640 align:middle line:84% do you use cryptography to just have a fully succinct protocol? 00:20:55.640 --> 00:20:57.700 align:middle line:84% Let's say, for NP, we want a protocol 00:20:57.700 --> 00:20:59.416 align:middle line:90% that has polylog communication. 00:20:59.416 --> 00:21:02.370 align:middle line:84% OK, so you have an instance of length n, 00:21:02.370 --> 00:21:04.350 align:middle line:84% and the prover wants to prove to the verifier 00:21:04.350 --> 00:21:05.767 align:middle line:84% that x is in the language, and you 00:21:05.767 --> 00:21:10.090 align:middle line:84% want the communication to be only polylog n, for example. 00:21:10.090 --> 00:21:11.280 align:middle line:90% OK. 00:21:11.280 --> 00:21:14.740 align:middle line:84% OK, one thing I do-- oh, did you have a question? 00:21:14.740 --> 00:21:16.855 align:middle line:84% AUDIENCE: Is there just a quick-- 00:21:16.855 --> 00:21:20.260 align:middle line:84% [INAUDIBLE] is the interactive protocol necessary? 00:21:20.260 --> 00:21:23.830 align:middle line:84% Because in the traditional complexity series, PCP, 00:21:23.830 --> 00:21:26.350 align:middle line:84% probability has to be written down in advance, 00:21:26.350 --> 00:21:29.355 align:middle line:84% and it cannot be adapted [INAUDIBLE]. 00:21:29.355 --> 00:21:30.105 align:middle line:90% YAEL KALAI: Right. 00:21:30.105 --> 00:21:30.360 align:middle line:90% Right. 00:21:30.360 --> 00:21:32.080 align:middle line:84% AUDIENCE: So is the whole point of the protocol trying 00:21:32.080 --> 00:21:34.848 align:middle line:84% to fix some problem in a sense, where you're not forcing 00:21:34.848 --> 00:21:35.890 align:middle line:90% the prover to commit to-- 00:21:35.890 --> 00:21:36.550 align:middle line:90% YAEL KALAI: Exactly. 00:21:36.550 --> 00:21:36.960 align:middle line:90% Exactly. 00:21:36.960 --> 00:21:37.370 align:middle line:90% AUDIENCE: OK. 00:21:37.370 --> 00:21:38.620 align:middle line:90% YAEL KALAI: That's exactly it. 00:21:38.620 --> 00:21:39.880 align:middle line:90% That's exactly it. 00:21:39.880 --> 00:21:40.870 align:middle line:90% Exactly. 00:21:40.870 --> 00:21:45.220 align:middle line:84% One thing I do want to say, note that I asked for the cheating 00:21:45.220 --> 00:21:48.220 align:middle line:84% prover to be polynomial in lambda, 00:21:48.220 --> 00:21:51.995 align:middle line:84% OK, because that's what my assumptions usually look like. 00:21:51.995 --> 00:21:53.870 align:middle line:84% I want to say-- if I use collision resistant, 00:21:53.870 --> 00:21:57.160 align:middle line:84% I want to say, well, I used some collision-resistant function 00:21:57.160 --> 00:21:58.850 align:middle line:90% with security parameter lambda. 00:21:58.850 --> 00:22:02.050 align:middle line:84% It says that my assumption is that a poly-lambda-sized circuit 00:22:02.050 --> 00:22:03.080 align:middle line:90% cannot find collisions. 00:22:03.080 --> 00:22:03.580 align:middle line:90% OK. 00:22:03.580 --> 00:22:05.470 align:middle line:84% My cryptographic assumption usually 00:22:05.470 --> 00:22:10.530 align:middle line:84% assumes that they are hard to break against adversaries 00:22:10.530 --> 00:22:12.610 align:middle line:90% that run in time poly lambda. 00:22:12.610 --> 00:22:16.150 align:middle line:84% But this may seem very weird and very weak. 00:22:16.150 --> 00:22:16.960 align:middle line:90% Why? 00:22:16.960 --> 00:22:19.030 align:middle line:84% Because, you know, our goal is to come up 00:22:19.030 --> 00:22:21.940 align:middle line:84% with succinct arguments, OK, succinct. 00:22:21.940 --> 00:22:24.880 align:middle line:84% In particular, one example to keep in mind 00:22:24.880 --> 00:22:27.320 align:middle line:84% is let's say the input n can be really huge, 00:22:27.320 --> 00:22:30.260 align:middle line:84% but I want the communication complexity to be polylog n. 00:22:30.260 --> 00:22:33.946 align:middle line:84% So think of lambda as being like polylog n. 00:22:33.946 --> 00:22:36.660 align:middle line:84% OK, everything's going to go with the security parameter, 00:22:36.660 --> 00:22:40.510 align:middle line:84% but let's take the security parameter to be polylog n. 00:22:40.510 --> 00:22:41.750 align:middle line:90% Now it seems weird. 00:22:41.750 --> 00:22:42.890 align:middle line:90% You're like, Wait, really? 00:22:42.890 --> 00:22:50.140 align:middle line:84% So the cheating prover, if the instance is of length n 00:22:50.140 --> 00:22:54.070 align:middle line:84% and the security parameter's of length polylog n, the cheating 00:22:54.070 --> 00:22:55.870 align:middle line:84% prover, we're not even giving him 00:22:55.870 --> 00:22:59.590 align:middle line:84% the opportunity to read the input, 00:22:59.590 --> 00:23:02.798 align:middle line:90% so it's a very weak guarantee. 00:23:02.798 --> 00:23:04.340 align:middle line:84% So what does this guarantee tell you? 00:23:04.340 --> 00:23:07.630 align:middle line:84% Let's say I want you to prove to me that a given 00:23:07.630 --> 00:23:10.030 align:middle line:90% x is in the language. 00:23:10.030 --> 00:23:12.280 align:middle line:84% And my only guarantee is, if you run 00:23:12.280 --> 00:23:14.680 align:middle line:84% in time that's only polylogarithmic in n, 00:23:14.680 --> 00:23:16.610 align:middle line:90% you can't cheat. 00:23:16.610 --> 00:23:17.360 align:middle line:90% OK. 00:23:17.360 --> 00:23:19.070 align:middle line:90% But what if you run in time n? 00:23:19.070 --> 00:23:22.730 align:middle line:90% 00:23:22.730 --> 00:23:26.750 align:middle line:84% So that seems like a problem, especially if-- look, 00:23:26.750 --> 00:23:31.130 align:middle line:84% if n is too big for anyone to read, then in some sense, why-- 00:23:31.130 --> 00:23:32.820 align:middle line:90% nobody's going to use it anyway. 00:23:32.820 --> 00:23:34.590 align:middle line:90% And if n is-- 00:23:34.590 --> 00:23:37.170 align:middle line:84% we're able to read it, if I'm able to read it, 00:23:37.170 --> 00:23:40.477 align:middle line:84% then you have the time to run in that time, so you run in time n. 00:23:40.477 --> 00:23:42.560 align:middle line:84% I'm not going to assume you run in time polylog n. 00:23:42.560 --> 00:23:45.040 align:middle line:90% So this seems very weird. 00:23:45.040 --> 00:23:46.750 align:middle line:84% You should not be happy at this point. 00:23:46.750 --> 00:23:48.750 align:middle line:84% You should be like, wait, something is going on. 00:23:48.750 --> 00:23:49.958 align:middle line:90% I don't like this definition. 00:23:49.958 --> 00:23:50.960 align:middle line:90% It's meaningless. 00:23:50.960 --> 00:23:54.600 align:middle line:84% Like, look, if you don't want succinctness, 00:23:54.600 --> 00:23:58.320 align:middle line:84% you can make lambda be size of n and then you're happy. 00:23:58.320 --> 00:24:03.480 align:middle line:84% If lambda is of size x, the instance size, then you can say, 00:24:03.480 --> 00:24:05.330 align:middle line:84% yeah, the instance size is some n. 00:24:05.330 --> 00:24:07.460 align:middle line:90% I allow my real-- 00:24:07.460 --> 00:24:10.020 align:middle line:84% my honest prover runs in time poly n. 00:24:10.020 --> 00:24:12.290 align:middle line:84% I allow my malicious prover to run in time poly n, 00:24:12.290 --> 00:24:14.320 align:middle line:90% and that makes sense to me. 00:24:14.320 --> 00:24:16.070 align:middle line:84% But now I'm saying, no, the honest prover, 00:24:16.070 --> 00:24:17.330 align:middle line:90% he can actually run in time n. 00:24:17.330 --> 00:24:18.770 align:middle line:90% The malicious cannot. 00:24:18.770 --> 00:24:23.140 align:middle line:84% Like, no, the malicious has more power than the honest. 00:24:23.140 --> 00:24:29.250 align:middle line:84% So it's really a weak guarantee, that kind of-- 00:24:29.250 --> 00:24:31.737 align:middle line:84% especially if we want to take the security parameter, 00:24:31.737 --> 00:24:33.570 align:middle line:84% the idea is we're going to take the security 00:24:33.570 --> 00:24:37.600 align:middle line:84% parameter really small, OK, really, really small. 00:24:37.600 --> 00:24:40.010 align:middle line:84% But if we take the security parameter so small, 00:24:40.010 --> 00:24:42.550 align:middle line:84% we should give the adversary more power 00:24:42.550 --> 00:24:45.220 align:middle line:84% than calling the security parameter, because it just 00:24:45.220 --> 00:24:46.930 align:middle line:90% doesn't meet real life-- 00:24:46.930 --> 00:24:48.760 align:middle line:84% the idea is to-- the idea of this 00:24:48.760 --> 00:24:50.600 align:middle line:84% is to kind of capture a real-life setting, 00:24:50.600 --> 00:24:53.280 align:middle line:84% not to make a model that makes no sense. 00:24:53.280 --> 00:24:56.280 align:middle line:84% So if we take lambda to be very, very small, 00:24:56.280 --> 00:24:58.492 align:middle line:84% then actually the real-world adversary 00:24:58.492 --> 00:25:00.075 align:middle line:84% can run in time more than poly lambda. 00:25:00.075 --> 00:25:04.490 align:middle line:84% It can run in time poly n, so it doesn't capture-- 00:25:04.490 --> 00:25:05.450 align:middle line:90% yeah? 00:25:05.450 --> 00:25:07.110 align:middle line:84% AUDIENCE: If P star's the circuit, 00:25:07.110 --> 00:25:09.740 align:middle line:84% how do we even think of plugging in a variable length 00:25:09.740 --> 00:25:12.072 align:middle line:90% back into a [INAUDIBLE]? 00:25:12.072 --> 00:25:13.530 align:middle line:84% YAEL KALAI: They can't even read x. 00:25:13.530 --> 00:25:14.990 align:middle line:90% You're right. 00:25:14.990 --> 00:25:16.470 align:middle line:90% Yeah, for example. 00:25:16.470 --> 00:25:18.530 align:middle line:84% AUDIENCE: [INAUDIBLE] not even [INAUDIBLE]. 00:25:18.530 --> 00:25:20.420 align:middle line:84% YAEL KALAI: So you can say, oh, P star can't read x. 00:25:20.420 --> 00:25:20.962 align:middle line:90% You're right. 00:25:20.962 --> 00:25:21.930 align:middle line:90% They can't read x. 00:25:21.930 --> 00:25:25.910 align:middle line:84% It's a circuit, and, yeah, it can't read x. 00:25:25.910 --> 00:25:26.915 align:middle line:90% This is a big problem. 00:25:26.915 --> 00:25:27.415 align:middle line:90% OK. 00:25:27.415 --> 00:25:32.400 align:middle line:84% So the way I defined it really doesn't make much sense. 00:25:32.400 --> 00:25:33.145 align:middle line:90% Yeah? 00:25:33.145 --> 00:25:34.770 align:middle line:84% AUDIENCE: Just to make sure, why did we 00:25:34.770 --> 00:25:36.502 align:middle line:90% need lambda to be polylog n? 00:25:36.502 --> 00:25:38.960 align:middle line:84% Is it so that the resulting interaction is succinct enough? 00:25:38.960 --> 00:25:39.990 align:middle line:90% YAEL KALAI: Exactly. 00:25:39.990 --> 00:25:40.890 align:middle line:90% So, great question. 00:25:40.890 --> 00:25:43.920 align:middle line:84% The question is, Why do we need it to be polylog n? 00:25:43.920 --> 00:25:46.890 align:middle line:84% So I think where maybe you're going to-- you know what, let's 00:25:46.890 --> 00:25:50.500 align:middle line:84% make lambda n to the epsilon, for a content epsilon, 00:25:50.500 --> 00:25:53.840 align:middle line:90% n to the 0.001. 00:25:53.840 --> 00:26:01.190 align:middle line:84% Then we say, look, the original proof grows with lambda, which 00:26:01.190 --> 00:26:07.490 align:middle line:84% is n to the power of 0.001, which is much smaller than n, 00:26:07.490 --> 00:26:08.670 align:middle line:90% so we're still happy. 00:26:08.670 --> 00:26:10.490 align:middle line:84% But the cheating prover can run time 00:26:10.490 --> 00:26:16.020 align:middle line:84% any poly, any polynomial in it, so it's poly n So that's good. 00:26:16.020 --> 00:26:18.635 align:middle line:84% You're right, and that's a good setting to think about. 00:26:18.635 --> 00:26:20.010 align:middle line:84% In that case, there is no issues. 00:26:20.010 --> 00:26:21.468 align:middle line:84% So one thing which you're saying is 00:26:21.468 --> 00:26:23.910 align:middle line:84% you're saying, let me fix all your problems. 00:26:23.910 --> 00:26:26.360 align:middle line:90% Just take lambda to be-- 00:26:26.360 --> 00:26:32.390 align:middle line:84% think of it as n to the 0.01 and you're done, or n to the epsilon 00:26:32.390 --> 00:26:33.730 align:middle line:90% and you're done. 00:26:33.730 --> 00:26:35.548 align:middle line:84% OK, if you think about n to the epsilon, 00:26:35.548 --> 00:26:36.840 align:middle line:90% everything kind of makes sense. 00:26:36.840 --> 00:26:38.970 align:middle line:84% You allow the cheating prover to run time poly n, 00:26:38.970 --> 00:26:42.030 align:middle line:84% the instance is n, and we're good. 00:26:42.030 --> 00:26:42.780 align:middle line:90% OK. 00:26:42.780 --> 00:26:45.250 align:middle line:84% So that's one way to think about it. 00:26:45.250 --> 00:26:47.890 align:middle line:84% So usually, the way we think about it, we say, for any n, 00:26:47.890 --> 00:26:50.370 align:middle line:84% we choose a security parameter that depends on n. 00:26:50.370 --> 00:26:52.480 align:middle line:90% OK, that's usually how we do it. 00:26:52.480 --> 00:26:55.720 align:middle line:84% We have an n, and now we say, OK, which security do we use? 00:26:55.720 --> 00:26:57.570 align:middle line:90% It's kind of a function of n. 00:26:57.570 --> 00:26:58.487 align:middle line:90% So that's one example. 00:26:58.487 --> 00:27:00.237 align:middle line:84% Choose that to be perfect, and then you've 00:27:00.237 --> 00:27:01.290 align:middle line:90% solved all the problems. 00:27:01.290 --> 00:27:03.940 align:middle line:84% But what if I want more succinctness than that? 00:27:03.940 --> 00:27:08.190 align:middle line:84% Maybe n to the 0.01 is not-- it's OK, but I want better. 00:27:08.190 --> 00:27:10.200 align:middle line:90% I want polylog n. 00:27:10.200 --> 00:27:12.670 align:middle line:90% So what if my lambda-- 00:27:12.670 --> 00:27:15.160 align:middle line:84% that's one option, but another option is polylog n. 00:27:15.160 --> 00:27:17.850 align:middle line:90% That's even more succinct. 00:27:17.850 --> 00:27:19.318 align:middle line:90% So that's what I want. 00:27:19.318 --> 00:27:21.360 align:middle line:84% Now you're saying, well, if that's what you want, 00:27:21.360 --> 00:27:23.830 align:middle line:84% you've got a definition that makes no sense. 00:27:23.830 --> 00:27:25.290 align:middle line:90% And you're right. 00:27:25.290 --> 00:27:28.980 align:middle line:84% But then what I can do is strengthen the definition. 00:27:28.980 --> 00:27:30.910 align:middle line:84% So how do I strengthen the definition? 00:27:30.910 --> 00:27:34.410 align:middle line:84% I'm going to say, you know what, poly is one option, 00:27:34.410 --> 00:27:38.850 align:middle line:84% but let me actually assume, make a stronger 00:27:38.850 --> 00:27:40.330 align:middle line:90% cryptographic assumption. 00:27:40.330 --> 00:27:43.470 align:middle line:84% I'm going to assume some lambda the same for any adversary that 00:27:43.470 --> 00:27:44.980 align:middle line:90% runs-- 00:27:44.980 --> 00:27:52.090 align:middle line:84% for any P star that executes a circuit not of size poly lambda 00:27:52.090 --> 00:27:56.540 align:middle line:84% but of size 2 to the lambda to the epsilon. 00:27:56.540 --> 00:27:58.610 align:middle line:84% I'm going to allow my adversary to run in time 2 00:27:58.610 --> 00:28:03.450 align:middle line:84% to the lambda to the epsilon, more than poly. 00:28:03.450 --> 00:28:05.480 align:middle line:90% Now it's a stronger assumption. 00:28:05.480 --> 00:28:09.390 align:middle line:84% So now I want to say, an adversary that runs in time 2-- 00:28:09.390 --> 00:28:14.180 align:middle line:84% or of size 2 to the lambda to the epsilon cannot break my hash 00:28:14.180 --> 00:28:14.680 align:middle line:90% function. 00:28:14.680 --> 00:28:16.000 align:middle line:90% He cannot find collisions. 00:28:16.000 --> 00:28:17.790 align:middle line:90% It's a stronger assumption. 00:28:17.790 --> 00:28:21.060 align:middle line:90% But now this makes sense. 00:28:21.060 --> 00:28:24.030 align:middle line:84% So I can take lambda very, very small, but I'm saying, 00:28:24.030 --> 00:28:28.350 align:middle line:84% even if the adversary runs in time that's much bigger than 00:28:28.350 --> 00:28:30.690 align:middle line:84% lambda, that's actually 2 to the lambda to the epsilon, 00:28:30.690 --> 00:28:34.460 align:middle line:90% even he cannot break my crypto. 00:28:34.460 --> 00:28:38.390 align:middle line:84% And that's why, when we talk about succinct proofs, most 00:28:38.390 --> 00:28:41.060 align:middle line:84% often, we talk about this kind of assumption. 00:28:41.060 --> 00:28:44.360 align:middle line:84% Subexponential assumptions come up a lot, 00:28:44.360 --> 00:28:46.340 align:middle line:90% and we'll see that, actually. 00:28:46.340 --> 00:28:51.180 align:middle line:84% But often, if we want to implement, 00:28:51.180 --> 00:28:53.630 align:middle line:84% so if we want to implement, if we 00:28:53.630 --> 00:28:55.710 align:middle line:84% want to take lambda to be polylog n, 00:28:55.710 --> 00:28:58.280 align:middle line:90% it makes sense to require-- 00:28:58.280 --> 00:29:03.770 align:middle line:84% for the soundness to make sense, to correspond 00:29:03.770 --> 00:29:06.260 align:middle line:84% to real-world applications, it makes sense 00:29:06.260 --> 00:29:08.990 align:middle line:84% to require subexponential assumptions 00:29:08.990 --> 00:29:12.570 align:middle line:90% of our underlying cryptography. 00:29:12.570 --> 00:29:15.570 align:middle line:84% OK, so just to kind of close these parentheses, 00:29:15.570 --> 00:29:19.320 align:middle line:84% one can talk about poly-size cheating provers. 00:29:19.320 --> 00:29:21.600 align:middle line:84% It will give you a more standard assumption. 00:29:21.600 --> 00:29:23.330 align:middle line:84% But the soundness guarantee you get 00:29:23.330 --> 00:29:24.950 align:middle line:84% may not be strong enough, depending 00:29:24.950 --> 00:29:28.800 align:middle line:84% on how security parameter relates to the input size. 00:29:28.800 --> 00:29:31.310 align:middle line:84% If you want lambda to be very, very-- the security 00:29:31.310 --> 00:29:33.110 align:middle line:84% parameter to be very, very small, 00:29:33.110 --> 00:29:37.910 align:middle line:84% and yet you want to offer security against adversaries 00:29:37.910 --> 00:29:40.070 align:middle line:84% that runtime poly n, then you will 00:29:40.070 --> 00:29:41.895 align:middle line:84% need to make your assumptions stronger. 00:29:41.895 --> 00:29:44.440 align:middle line:90% 00:29:44.440 --> 00:29:45.190 align:middle line:90% OK. 00:29:45.190 --> 00:29:49.690 align:middle line:84% But this is kind of a design choice. 00:29:49.690 --> 00:29:50.290 align:middle line:90% OK. 00:29:50.290 --> 00:29:52.240 align:middle line:84% For now, I'm just going to think of, 00:29:52.240 --> 00:29:57.220 align:middle line:84% for any given P star of size poly lambda or more, whatever 00:29:57.220 --> 00:29:59.570 align:middle line:84% we choose here, that corresponds to the assumption. 00:29:59.570 --> 00:30:00.070 align:middle line:90% OK. 00:30:00.070 --> 00:30:03.160 align:middle line:84% So if we have T secure assumption, then 00:30:03.160 --> 00:30:05.200 align:middle line:90% for any T size-- 00:30:05.200 --> 00:30:07.320 align:middle line:84% so in general, more generally, you 00:30:07.320 --> 00:30:13.420 align:middle line:84% can replace this by T of lambda, right, any T. It can be poly. 00:30:13.420 --> 00:30:15.380 align:middle line:90% It can be subexponential. 00:30:15.380 --> 00:30:17.170 align:middle line:90% It can be whatever. 00:30:17.170 --> 00:30:17.670 align:middle line:90% OK. 00:30:17.670 --> 00:30:20.730 align:middle line:84% And then we choose the T, and now the T kind of governs 00:30:20.730 --> 00:30:21.430 align:middle line:90% the application. 00:30:21.430 --> 00:30:24.400 align:middle line:84% But once you have a T, now we can just prove it using math. 00:30:24.400 --> 00:30:26.310 align:middle line:84% We don't need to think about it anymore. 00:30:26.310 --> 00:30:26.920 align:middle line:90% OK. 00:30:26.920 --> 00:30:33.280 align:middle line:84% So that's kind of how lambda relates to n 00:30:33.280 --> 00:30:36.405 align:middle line:84% and how the strength of the assumption relates to n. 00:30:36.405 --> 00:30:38.930 align:middle line:90% 00:30:38.930 --> 00:30:39.430 align:middle line:90% OK. 00:30:39.430 --> 00:30:41.310 align:middle line:90% Any questions about that? 00:30:41.310 --> 00:30:44.410 align:middle line:90% 00:30:44.410 --> 00:30:44.910 align:middle line:90% OK. 00:30:44.910 --> 00:30:49.010 align:middle line:84% So now let's go ahead with how we use it. 00:30:49.010 --> 00:30:50.020 align:middle line:90% So that's what we want. 00:30:50.020 --> 00:30:53.420 align:middle line:84% I want to come up with a succinct, interactive argument 00:30:53.420 --> 00:30:55.190 align:middle line:90% for all of NP. 00:30:55.190 --> 00:30:55.690 align:middle line:90% OK. 00:30:55.690 --> 00:30:59.310 align:middle line:84% I want to show how I can take any NP language-- 00:30:59.310 --> 00:31:00.660 align:middle line:90% and let's think of 3-SAT. 00:31:00.660 --> 00:31:01.160 align:middle line:90% Why not? 00:31:01.160 --> 00:31:02.500 align:middle line:90% It's complete. 00:31:02.500 --> 00:31:09.920 align:middle line:84% I want to prove to you that a 3-CNF formula is satisfiable. 00:31:09.920 --> 00:31:12.370 align:middle line:90% I have a witness of length n. 00:31:12.370 --> 00:31:16.390 align:middle line:84% I want to prove to you that it's satisfiable. 00:31:16.390 --> 00:31:17.910 align:middle line:84% But with the communication, I want 00:31:17.910 --> 00:31:20.610 align:middle line:90% it to grow only with lambda. 00:31:20.610 --> 00:31:22.230 align:middle line:90% OK, lambda can be polylog n. 00:31:22.230 --> 00:31:23.245 align:middle line:90% I don't even want to-- 00:31:23.245 --> 00:31:25.390 align:middle line:84% don't go now to the choice of how we chose the lambda. 00:31:25.390 --> 00:31:27.182 align:middle line:84% But now I have a security parameter lambda, 00:31:27.182 --> 00:31:30.320 align:middle line:84% I want the communication to only go with the security parameter, 00:31:30.320 --> 00:31:32.630 align:middle line:90% not with n. 00:31:32.630 --> 00:31:33.360 align:middle line:90% OK. 00:31:33.360 --> 00:31:35.630 align:middle line:90% So how do I do it? 00:31:35.630 --> 00:31:39.350 align:middle line:84% So the idea is, well, I'll use my PCP. 00:31:39.350 --> 00:31:41.180 align:middle line:90% I have my PCP. 00:31:41.180 --> 00:31:45.860 align:middle line:84% I'm going to use crypto to squeeze it. 00:31:45.860 --> 00:31:47.290 align:middle line:84% How do I use crypto to squeeze it? 00:31:47.290 --> 00:31:49.040 align:middle line:84% It's exactly what collision-resistant hash 00:31:49.040 --> 00:31:49.850 align:middle line:90% functions do. 00:31:49.850 --> 00:31:54.310 align:middle line:84% They take a big thing and they squish them down. 00:31:54.310 --> 00:31:56.110 align:middle line:84% So now I'll take I'll take my PCP, 00:31:56.110 --> 00:31:58.380 align:middle line:84% the prover will take his PCP, he will squish it 00:31:58.380 --> 00:32:02.010 align:middle line:84% down using a collision resistant hash function. 00:32:02.010 --> 00:32:02.635 align:middle line:90% OK. 00:32:02.635 --> 00:32:04.260 align:middle line:84% So he gives the verifier-- here you go. 00:32:04.260 --> 00:32:08.040 align:middle line:84% Here's a-- like, a squished, like a digest of this PCP. 00:32:08.040 --> 00:32:09.480 align:middle line:90% The verifier takes this thing. 00:32:09.480 --> 00:32:10.590 align:middle line:90% It has no meaning. 00:32:10.590 --> 00:32:11.670 align:middle line:90% So what does he do? 00:32:11.670 --> 00:32:14.620 align:middle line:84% Now he says to the prover, OK, yeah, thank you very much, 00:32:14.620 --> 00:32:17.800 align:middle line:84% but I want to see the PCP on a few locations. 00:32:17.800 --> 00:32:21.720 align:middle line:90% So now what can the prover do? 00:32:21.720 --> 00:32:23.190 align:middle line:90% The prover can't-- 00:32:23.190 --> 00:32:27.390 align:middle line:84% OK, so collision-resistant hash function, as is, 00:32:27.390 --> 00:32:32.460 align:middle line:84% it's a way to kind of compress in a way that you can't-- 00:32:32.460 --> 00:32:34.680 align:middle line:84% you're kind of committed, because you 00:32:34.680 --> 00:32:36.040 align:middle line:90% can't find collisions later. 00:32:36.040 --> 00:32:37.770 align:middle line:90% So you can't open-- 00:32:37.770 --> 00:32:43.000 align:middle line:84% after you gave the hash value, you can't open to x and x prime. 00:32:43.000 --> 00:32:44.730 align:middle line:84% You can't give x and x prime that both 00:32:44.730 --> 00:32:47.370 align:middle line:90% hash to the same value. 00:32:47.370 --> 00:32:50.280 align:middle line:84% But I don't want you to give-- you can't give me-- now 00:32:50.280 --> 00:32:51.490 align:middle line:90% you're hashing an entire PCP. 00:32:51.490 --> 00:32:52.890 align:middle line:90% The PCP is big. 00:32:52.890 --> 00:32:54.540 align:middle line:90% You can't just-- 00:32:54.540 --> 00:32:56.940 align:middle line:84% I never want you to give me-- me, the verifier, 00:32:56.940 --> 00:32:58.670 align:middle line:90% I never want to receive the PCP. 00:32:58.670 --> 00:32:59.940 align:middle line:90% I can't even hold it. 00:32:59.940 --> 00:33:03.980 align:middle line:84% I want to receive a few bits of the input. 00:33:03.980 --> 00:33:06.740 align:middle line:84% So what we need is a collision-resistant hash 00:33:06.740 --> 00:33:10.900 align:middle line:84% that has a special property that you can open bit by bit. 00:33:10.900 --> 00:33:14.820 align:middle line:84% So instead of giving me the entire input, 00:33:14.820 --> 00:33:17.820 align:middle line:84% the entire preimage of the hash value, 00:33:17.820 --> 00:33:20.480 align:middle line:84% I want you just to give me a few bits here, a few bits here, 00:33:20.480 --> 00:33:24.250 align:middle line:84% and a few bits here, and prove to me that they correspond 00:33:24.250 --> 00:33:29.070 align:middle line:90% to the input you hashed. 00:33:29.070 --> 00:33:31.770 align:middle line:84% So now I'm going to define this primitive. 00:33:31.770 --> 00:33:33.270 align:middle line:84% Once I have this, we're going to see 00:33:33.270 --> 00:33:35.010 align:middle line:84% it's going to be very easy to come up 00:33:35.010 --> 00:33:37.590 align:middle line:84% with the actual interactive argument. 00:33:37.590 --> 00:33:38.100 align:middle line:90% OK. 00:33:38.100 --> 00:33:42.150 align:middle line:84% So the primitive is what's called 00:33:42.150 --> 00:33:45.460 align:middle line:84% a collision-resistant hash with local opening. 00:33:45.460 --> 00:33:46.510 align:middle line:90% Let me define it. 00:33:46.510 --> 00:33:49.290 align:middle line:84% So we're going to have a collision-resistant hash 00:33:49.290 --> 00:33:58.880 align:middle line:84% function with local opening, and this 00:33:58.880 --> 00:34:00.970 align:middle line:90% consists of five algorithms. 00:34:00.970 --> 00:34:05.180 align:middle line:84% The first one is-- the first two are Gen and Eval. 00:34:05.180 --> 00:34:08.300 align:middle line:84% These are exactly-- these two algorithms 00:34:08.300 --> 00:34:10.219 align:middle line:84% is what defines collision-resistant hash 00:34:10.219 --> 00:34:10.830 align:middle line:90% function. 00:34:10.830 --> 00:34:11.989 align:middle line:90% So this, we saw last time. 00:34:11.989 --> 00:34:14.210 align:middle line:84% I'll just repeat, just to recall, 00:34:14.210 --> 00:34:18.860 align:middle line:84% Gen takes as input a 1 to the lambda, the security parameter, 00:34:18.860 --> 00:34:22.880 align:middle line:90% and outputs hash key. 00:34:22.880 --> 00:34:24.710 align:middle line:90% So this is some key. 00:34:24.710 --> 00:34:28.820 align:middle line:84% Eval takes as input hash key and any input 00:34:28.820 --> 00:34:35.230 align:middle line:84% x from 0, 1 star, anything, OK, any string of any length, 00:34:35.230 --> 00:34:42.440 align:middle line:90% and it outputs a hash value. 00:34:42.440 --> 00:34:46.860 align:middle line:84% We'll denote it V. And that's fixed at 0, 1 to the lambda. 00:34:46.860 --> 00:34:49.110 align:middle line:84% I call it sometimes delta and sometimes lambda, right? 00:34:49.110 --> 00:34:50.030 align:middle line:90% Sorry. 00:34:50.030 --> 00:34:51.170 align:middle line:90% It's lambda. 00:34:51.170 --> 00:34:55.239 align:middle line:84% You output a hash of a fixed size, which 00:34:55.239 --> 00:34:56.989 align:middle line:84% means you can take very, very long things, 00:34:56.989 --> 00:35:02.450 align:middle line:84% and you digest them down to a value of size lambda. 00:35:02.450 --> 00:35:05.795 align:middle line:84% OK, so it takes an input of arbitrary size. 00:35:05.795 --> 00:35:07.020 align:middle line:90% It can be huge. 00:35:07.020 --> 00:35:09.870 align:middle line:84% It can be 2 lambda, 4 lambda, tons, huge, 00:35:09.870 --> 00:35:14.370 align:middle line:84% and it digests down to a string of length lambda. 00:35:14.370 --> 00:35:15.130 align:middle line:90% OK. 00:35:15.130 --> 00:35:18.050 align:middle line:84% Now there's two more algorithms-- two or three? 00:35:18.050 --> 00:35:18.550 align:middle line:90% OK. 00:35:18.550 --> 00:35:20.360 align:middle line:84% So now there's an algorithm called Open. 00:35:20.360 --> 00:35:22.950 align:middle line:90% 00:35:22.950 --> 00:35:24.310 align:middle line:90% Open, I just want to make sure-- 00:35:24.310 --> 00:35:26.352 align:middle line:84% I want it to tell me-- don't give me the entire-- 00:35:26.352 --> 00:35:29.490 align:middle line:84% I want to-- so these just digest. 00:35:29.490 --> 00:35:30.700 align:middle line:90% It has no meaning. 00:35:30.700 --> 00:35:33.300 align:middle line:84% I want to tell you now I want the i-th bit of x. 00:35:33.300 --> 00:35:35.220 align:middle line:84% Don't give me all of x, what you hashed. 00:35:35.220 --> 00:35:36.010 align:middle line:90% I can't hold it. 00:35:36.010 --> 00:35:37.590 align:middle line:90% I just want the i-th bit. 00:35:37.590 --> 00:35:39.920 align:middle line:90% So, Open, so what do you do? 00:35:39.920 --> 00:35:40.420 align:middle line:90% You open. 00:35:40.420 --> 00:35:41.260 align:middle line:90% How do you open? 00:35:41.260 --> 00:35:42.930 align:middle line:90% You have the hash key. 00:35:42.930 --> 00:35:46.950 align:middle line:84% You have x, which you computed, the value 00:35:46.950 --> 00:35:54.420 align:middle line:84% v. And now you have some i in kind of 0, 1 to the length of x. 00:35:54.420 --> 00:35:58.210 align:middle line:84% So this is kind of which index I want you to open. 00:35:58.210 --> 00:36:06.400 align:middle line:84% And what you output is a bit B-- which is kind of corresponding 00:36:06.400 --> 00:36:08.290 align:middle line:90% to xi, the i-th bit-- 00:36:08.290 --> 00:36:13.760 align:middle line:90% a bit and an opening value rho. 00:36:13.760 --> 00:36:22.900 align:middle line:84% OK, this is some kind of string, and this is of size lambda, 00:36:22.900 --> 00:36:25.260 align:middle line:90% so, small. 00:36:25.260 --> 00:36:34.390 align:middle line:84% Or it can be poly lambda, OK, an opening of size poly lambda. 00:36:34.390 --> 00:36:35.362 align:middle line:90% Yes? 00:36:35.362 --> 00:36:36.820 align:middle line:84% AUDIENCE: In this definition, who's 00:36:36.820 --> 00:36:38.230 align:middle line:90% running the Open [INAUDIBLE]? 00:36:38.230 --> 00:36:38.650 align:middle line:90% YAEL KALAI: Good. 00:36:38.650 --> 00:36:39.650 align:middle line:90% Who's running the Open? 00:36:39.650 --> 00:36:40.150 align:middle line:90% Good. 00:36:40.150 --> 00:36:42.260 align:middle line:84% The person who generated the hash. 00:36:42.260 --> 00:36:44.170 align:middle line:90% So let's say you're the prover. 00:36:44.170 --> 00:36:48.370 align:middle line:84% You want to prove to me that phi is satisfiable. 00:36:48.370 --> 00:36:49.840 align:middle line:90% You generate a PCP. 00:36:49.840 --> 00:36:50.898 align:middle line:90% I don't want your PCP. 00:36:50.898 --> 00:36:51.440 align:middle line:90% It's too big. 00:36:51.440 --> 00:36:54.060 align:middle line:84% You give me a hash, a value V. Thank you very much. 00:36:54.060 --> 00:36:57.440 align:middle line:84% Now I want you to open the PCP and some location i. 00:36:57.440 --> 00:37:00.040 align:middle line:90% So I tell you, here's i. 00:37:00.040 --> 00:37:01.490 align:middle line:90% I don't know your PCP. 00:37:01.490 --> 00:37:03.230 align:middle line:90% I don't know your input. 00:37:03.230 --> 00:37:07.590 align:middle line:84% You give me some rho i, like an opening-- give me xi. 00:37:07.590 --> 00:37:09.300 align:middle line:84% If you only give me xi, you can cheat. 00:37:09.300 --> 00:37:10.310 align:middle line:84% You can give me whatever you want. 00:37:10.310 --> 00:37:11.190 align:middle line:90% I don't believe you. 00:37:11.190 --> 00:37:14.000 align:middle line:84% So I want you to give me kind of-- rho i, this opening, 00:37:14.000 --> 00:37:17.870 align:middle line:84% is like a proof that indeed what I hashed down 00:37:17.870 --> 00:37:21.020 align:middle line:84% in the i-th location is sitting xi. 00:37:21.020 --> 00:37:22.740 align:middle line:90% This is what you think of rho i. 00:37:22.740 --> 00:37:23.610 align:middle line:90% It's like a proof. 00:37:23.610 --> 00:37:24.740 align:middle line:90% Yeah? 00:37:24.740 --> 00:37:29.203 align:middle line:84% AUDIENCE: Shouldn't i be in the log of the [INAUDIBLE]? 00:37:29.203 --> 00:37:30.120 align:middle line:90% YAEL KALAI: Oh, sorry. 00:37:30.120 --> 00:37:31.010 align:middle line:90% Sorry, sorry, sorry. 00:37:31.010 --> 00:37:31.920 align:middle line:90% Sorry. 00:37:31.920 --> 00:37:33.260 align:middle line:90% Thank you. 00:37:33.260 --> 00:37:35.360 align:middle line:90% Sorry. 00:37:35.360 --> 00:37:37.380 align:middle line:90% It's in index, not in 0, 1. 00:37:37.380 --> 00:37:37.880 align:middle line:90% Sorry. 00:37:37.880 --> 00:37:42.170 align:middle line:84% It's in index, with 1 until the length of x-- 00:37:42.170 --> 00:37:43.320 align:middle line:90% 1 to n, let's say. 00:37:43.320 --> 00:37:43.820 align:middle line:90% Yeah. 00:37:43.820 --> 00:37:44.653 align:middle line:90% Thank you very much. 00:37:44.653 --> 00:37:48.850 align:middle line:90% 00:37:48.850 --> 00:37:49.600 align:middle line:90% Questions? 00:37:49.600 --> 00:37:50.410 align:middle line:90% Yeah? 00:37:50.410 --> 00:37:53.560 align:middle line:84% AUDIENCE: Not so much a question as just, like, I 00:37:53.560 --> 00:37:57.160 align:middle line:84% guess it's just interesting that you have to retain 00:37:57.160 --> 00:38:00.670 align:middle line:90% the entire hashed value x. 00:38:00.670 --> 00:38:02.650 align:middle line:84% Maybe that's necessary for correctness, 00:38:02.650 --> 00:38:06.662 align:middle line:84% to be able to confirm any bit of x, but I don't know, 00:38:06.662 --> 00:38:08.620 align:middle line:84% it just seems interesting that in practice, you 00:38:08.620 --> 00:38:11.770 align:middle line:84% would have to keep storing all of these hashed values. 00:38:11.770 --> 00:38:13.478 align:middle line:84% YAEL KALAI: Right, so what you're-- wait, 00:38:13.478 --> 00:38:15.170 align:middle line:84% let me make sure what your comment is. 00:38:15.170 --> 00:38:17.890 align:middle line:84% Note that to open, you need to know the entire 00:38:17.890 --> 00:38:22.130 align:middle line:84% x, and why do you need to know the entire x, in a sense, 00:38:22.130 --> 00:38:23.450 align:middle line:90% to open to a bit i? 00:38:23.450 --> 00:38:28.080 align:middle line:84% So in some sense, look, I mean, to open to bit i, 00:38:28.080 --> 00:38:29.630 align:middle line:84% all you need to remember is rho i. 00:38:29.630 --> 00:38:31.900 align:middle line:84% That's what you need to give for the opening. 00:38:31.900 --> 00:38:37.270 align:middle line:84% But all the rho-i's together contain all the x. 00:38:37.270 --> 00:38:42.540 align:middle line:84% So that's why you need to kind of store all the x. 00:38:42.540 --> 00:38:46.780 align:middle line:84% And you'll see the construction soon, so it'll be kind of clear. 00:38:46.780 --> 00:38:51.420 align:middle line:84% OK, the last algorithm is what we call Ver, or Verify, 00:38:51.420 --> 00:38:57.210 align:middle line:84% and Verify, it takes as input a hash key of-- 00:38:57.210 --> 00:38:58.170 align:middle line:90% and now I'm verifying. 00:38:58.170 --> 00:39:00.480 align:middle line:90% You gave me xi and rho i. 00:39:00.480 --> 00:39:01.690 align:middle line:90% How do I know it's good? 00:39:01.690 --> 00:39:04.060 align:middle line:84% So I take my hash key, the hash key, 00:39:04.060 --> 00:39:09.840 align:middle line:84% the value that you gave me, i, xi, and rho i, 00:39:09.840 --> 00:39:14.530 align:middle line:84% and this algorithm outputs 0 or 1-- 00:39:14.530 --> 00:39:17.190 align:middle line:90% namely, accept or reject. 00:39:17.190 --> 00:39:25.460 align:middle line:84% So I can verify whether the rho is a valid opening. 00:39:25.460 --> 00:39:26.140 align:middle line:90% OK. 00:39:26.140 --> 00:39:28.200 align:middle line:84% And now, what are the guarantees? 00:39:28.200 --> 00:39:32.450 align:middle line:84% So you can hash, and then you can open. 00:39:32.450 --> 00:39:33.990 align:middle line:90% What is the guarantee? 00:39:33.990 --> 00:39:37.220 align:middle line:84% The guarantee is, first of all, if you do everything honestly, 00:39:37.220 --> 00:39:38.370 align:middle line:90% I'll accept you. 00:39:38.370 --> 00:39:40.790 align:middle line:90% OK, so there's two guarantees. 00:39:40.790 --> 00:39:44.390 align:middle line:84% The first guarantee is just correctness, 00:39:44.390 --> 00:39:47.190 align:middle line:84% and the second guarantee we want is collision resistance. 00:39:47.190 --> 00:39:47.940 align:middle line:90% So we'll see. 00:39:47.940 --> 00:39:57.560 align:middle line:84% So for correctness-- before, actually, let me just-- 00:39:57.560 --> 00:40:02.810 align:middle line:84% sorry, let me just say, these are all PPT algorithms. 00:40:02.810 --> 00:40:05.690 align:middle line:84% OK, all of them are polynomial time. 00:40:05.690 --> 00:40:09.110 align:middle line:84% Actually, the only-- everything is-- these are-- 00:40:09.110 --> 00:40:12.540 align:middle line:84% I should say, these are poly-time algorithm, 00:40:12.540 --> 00:40:14.480 align:middle line:90% and this is PPT. 00:40:14.480 --> 00:40:16.880 align:middle line:84% So this is a randomized algorithm, 00:40:16.880 --> 00:40:19.340 align:middle line:84% poly time, so it runs in time poly lambda, 00:40:19.340 --> 00:40:21.210 align:middle line:90% generates a hash key. 00:40:21.210 --> 00:40:23.563 align:middle line:84% These are all deterministic algorithms, OK, 00:40:23.563 --> 00:40:24.480 align:middle line:90% that run in poly time. 00:40:24.480 --> 00:40:26.120 align:middle line:90% So Eval takes his input x. 00:40:26.120 --> 00:40:28.590 align:middle line:90% He runs in time x, of course. 00:40:28.590 --> 00:40:30.080 align:middle line:90% Open runs in time x. 00:40:30.080 --> 00:40:35.370 align:middle line:84% But Verify runs in time poly lambda. 00:40:35.370 --> 00:40:35.870 align:middle line:90% Why? 00:40:35.870 --> 00:40:38.460 align:middle line:84% Because the hash key is of size poly lambda. 00:40:38.460 --> 00:40:41.510 align:middle line:84% This is of size poly lambda, because I required it. 00:40:41.510 --> 00:40:44.210 align:middle line:84% And xi is a bit, and this is of size poly lambda, 00:40:44.210 --> 00:40:45.680 align:middle line:90% because I required it. 00:40:45.680 --> 00:40:50.600 align:middle line:84% So the verifier runs in time poly lambda. 00:40:50.600 --> 00:40:52.590 align:middle line:84% OK, so when you send me a hash value, 00:40:52.590 --> 00:40:54.180 align:middle line:90% I get a value of size lambda. 00:40:54.180 --> 00:40:57.180 align:middle line:84% When I want you to open to a certain bit, 00:40:57.180 --> 00:41:00.000 align:middle line:84% I can check it in time poly lambda independent of n. 00:41:00.000 --> 00:41:02.740 align:middle line:84% I mean, lambda may depend on n, but it doesn't grow with n. 00:41:02.740 --> 00:41:03.330 align:middle line:90% Yes? 00:41:03.330 --> 00:41:06.090 align:middle line:84% AUDIENCE: Why [INAUDIBLE] ought to be probabilistic? 00:41:06.090 --> 00:41:07.470 align:middle line:90% YAEL KALAI: Why is Gen-- 00:41:07.470 --> 00:41:08.410 align:middle line:90% AUDIENCE: Just Eval. 00:41:08.410 --> 00:41:10.591 align:middle line:84% YAEL KALAI: Eval is not-- these are polynomial time. 00:41:10.591 --> 00:41:11.216 align:middle line:90% AUDIENCE: Yeah. 00:41:11.216 --> 00:41:11.402 align:middle line:90% Why is it not allowed? 00:41:11.402 --> 00:41:12.027 align:middle line:90% YAEL KALAI: Ah. 00:41:12.027 --> 00:41:13.890 align:middle line:90% Why is it not allowed? 00:41:13.890 --> 00:41:16.240 align:middle line:90% It doesn't need to be. 00:41:16.240 --> 00:41:19.870 align:middle line:84% It just doesn't need to be probabilistic. 00:41:19.870 --> 00:41:23.630 align:middle line:84% I'm not inherently opposed to using randomness in algorithms, 00:41:23.630 --> 00:41:26.260 align:middle line:84% but it just doesn't need to be, whereas Gen 00:41:26.260 --> 00:41:27.600 align:middle line:90% has to be probabilistic. 00:41:27.600 --> 00:41:28.100 align:middle line:90% OK. 00:41:28.100 --> 00:41:28.640 align:middle line:90% Great. 00:41:28.640 --> 00:41:29.140 align:middle line:90% Thanks. 00:41:29.140 --> 00:41:30.490 align:middle line:90% Good question. 00:41:30.490 --> 00:41:32.450 align:middle line:90% OK. 00:41:32.450 --> 00:41:37.350 align:middle line:84% So the correctness guarantee just says that-- 00:41:37.350 --> 00:41:44.820 align:middle line:84% let's see-- for every lambda, every hash key generated, like, 00:41:44.820 --> 00:41:52.000 align:middle line:84% in the image of Gen, and every x-- 00:41:52.000 --> 00:41:53.560 align:middle line:90% OK, not every x. 00:41:53.560 --> 00:41:59.970 align:middle line:84% We get completeness up to x in 0, 1 to the 2 to the lambda. 00:41:59.970 --> 00:42:01.530 align:middle line:90% OK. 00:42:01.530 --> 00:42:06.180 align:middle line:84% Or, I should say, sorry, small or equal to 2 to the lambda. 00:42:06.180 --> 00:42:08.740 align:middle line:84% So let's think of the security parameter. 00:42:08.740 --> 00:42:12.230 align:middle line:84% It's at least of size log n. n is the size of x. 00:42:12.230 --> 00:42:12.730 align:middle line:90% OK. 00:42:12.730 --> 00:42:14.230 align:middle line:84% We never take the security parameter 00:42:14.230 --> 00:42:16.830 align:middle line:90% to be smaller than log n. 00:42:16.830 --> 00:42:17.570 align:middle line:90% OK. 00:42:17.570 --> 00:42:23.010 align:middle line:84% And so that's why we always assume that the size of x 00:42:23.010 --> 00:42:25.150 align:middle line:84% is at most 2 to the security parameter, 00:42:25.150 --> 00:42:27.320 align:middle line:90% the number of bits in x. 00:42:27.320 --> 00:42:34.130 align:middle line:84% OK, so for every x, we want the probability that Verify-- 00:42:34.130 --> 00:42:44.540 align:middle line:84% oh, I forgot to say, for every i, the probability 00:42:44.540 --> 00:42:52.030 align:middle line:90% that Verify hk, Eval hk of x-- 00:42:52.030 --> 00:42:55.410 align:middle line:90% this is v-- what else do I have? 00:42:55.410 --> 00:43:00.345 align:middle line:84% i, xi, and rho i, which is Open-- 00:43:00.345 --> 00:43:07.430 align:middle line:90% 00:43:07.430 --> 00:43:09.140 align:middle line:90% this is kind of the rho-- 00:43:09.140 --> 00:43:12.380 align:middle line:90% it outputs 1 with probability 1. 00:43:12.380 --> 00:43:18.710 align:middle line:84% So if you are honest, you take some input x, any hash key, 00:43:18.710 --> 00:43:22.970 align:middle line:84% and you give me a hash value and then you open it, 00:43:22.970 --> 00:43:24.280 align:middle line:90% I'll accept you. 00:43:24.280 --> 00:43:24.960 align:middle line:90% OK. 00:43:24.960 --> 00:43:26.668 align:middle line:84% If everyone's doing what they're supposed 00:43:26.668 --> 00:43:30.720 align:middle line:84% to do for any x and for any hash key, we'll get output 1. 00:43:30.720 --> 00:43:34.340 align:middle line:84% By the way, sometimes, one can define also 00:43:34.340 --> 00:43:37.430 align:middle line:84% with high probability over randomly choosing a hash key. 00:43:37.430 --> 00:43:41.190 align:middle line:84% But our constructions work often in the worst case. 00:43:41.190 --> 00:43:42.320 align:middle line:90% But one can also-- 00:43:42.320 --> 00:43:45.072 align:middle line:84% a weaker definition is for a kind 00:43:45.072 --> 00:43:49.370 align:middle line:90% of hash key randomly generated. 00:43:49.370 --> 00:43:52.910 align:middle line:84% And here you have 1 minus negligible, 00:43:52.910 --> 00:43:56.010 align:middle line:84% where the probability is over the hash key. 00:43:56.010 --> 00:43:57.980 align:middle line:84% Here, actually, sorry, here there was no-- 00:43:57.980 --> 00:43:59.270 align:middle line:84% OK, before, there were no probabilities, 00:43:59.270 --> 00:44:00.645 align:middle line:84% because I just chose for average. 00:44:00.645 --> 00:44:03.740 align:middle line:84% But one can think of a hash key randomly generated, 00:44:03.740 --> 00:44:06.870 align:middle line:84% and you can have a negligible probability of error. 00:44:06.870 --> 00:44:08.450 align:middle line:90% We won't need that because-- 00:44:08.450 --> 00:44:12.450 align:middle line:84% I mean, some schemes, but many schemes are just probably 1. 00:44:12.450 --> 00:44:13.355 align:middle line:90% Yeah? 00:44:13.355 --> 00:44:15.230 align:middle line:84% AUDIENCE: So the [INAUDIBLE] that correctness 00:44:15.230 --> 00:44:17.063 align:middle line:84% always holds for any hash key, but soundness 00:44:17.063 --> 00:44:19.392 align:middle line:90% needs the randomness, right? 00:44:19.392 --> 00:44:20.282 align:middle line:90% YAEL KALAI: Right. 00:44:20.282 --> 00:44:21.740 align:middle line:84% Yeah, I didn't go to soundness yet. 00:44:21.740 --> 00:44:22.600 align:middle line:90% Yeah, yeah, yeah, yeah, yeah. 00:44:22.600 --> 00:44:23.980 align:middle line:90% We'll see soundness in a minute. 00:44:23.980 --> 00:44:26.010 align:middle line:84% But correctness, we can get for every hash key. 00:44:26.010 --> 00:44:28.800 align:middle line:84% But one can think of constructions 00:44:28.800 --> 00:44:31.600 align:middle line:84% that actually-- even correctness with high probability. 00:44:31.600 --> 00:44:33.720 align:middle line:84% But often, we think of it as correctness 1. 00:44:33.720 --> 00:44:34.860 align:middle line:90% Yes? 00:44:34.860 --> 00:44:37.360 align:middle line:84% AUDIENCE: For correctness, you have the position of x? 00:44:37.360 --> 00:44:38.110 align:middle line:90% YAEL KALAI: Again? 00:44:38.110 --> 00:44:39.120 align:middle line:84% AUDIENCE: [INAUDIBLE] for correctness, 00:44:39.120 --> 00:44:41.270 align:middle line:84% you have that restriction on the length of x, 00:44:41.270 --> 00:44:44.242 align:middle line:84% so the length should be less than 2 to the lambda, right? 00:44:44.242 --> 00:44:44.950 align:middle line:90% YAEL KALAI: Yeah. 00:44:44.950 --> 00:44:45.790 align:middle line:90% Yeah, yeah, yeah. 00:44:45.790 --> 00:44:46.690 align:middle line:90% You're asking why? 00:44:46.690 --> 00:44:47.315 align:middle line:90% AUDIENCE: Yeah. 00:44:47.315 --> 00:44:49.380 align:middle line:84% YAEL KALAI: Because our constructions, 00:44:49.380 --> 00:44:51.465 align:middle line:84% often, we'll see a construction, and we'll 00:44:51.465 --> 00:44:52.590 align:middle line:90% see that if the length is-- 00:44:52.590 --> 00:44:55.802 align:middle line:90% 00:44:55.802 --> 00:45:03.060 align:middle line:84% as I said, OK, the reason is our construction grows with log x. 00:45:03.060 --> 00:45:03.885 align:middle line:90% That's the truth. 00:45:03.885 --> 00:45:07.310 align:middle line:84% It just grows with log x, and we want the output to be lambda. 00:45:07.310 --> 00:45:09.020 align:middle line:84% So the fact of the matter is, the way 00:45:09.020 --> 00:45:10.950 align:middle line:84% we construct these schemes, our construction, 00:45:10.950 --> 00:45:13.840 align:middle line:90% the hash value grows with log x. 00:45:13.840 --> 00:45:15.612 align:middle line:84% But we don't want to kind of say it. 00:45:15.612 --> 00:45:17.570 align:middle line:84% We want to just say lambda, because it's nicer. 00:45:17.570 --> 00:45:19.870 align:middle line:84% So we just make sure lambda is at least log x, 00:45:19.870 --> 00:45:22.600 align:middle line:90% and then we're OK. 00:45:22.600 --> 00:45:25.670 align:middle line:90% OK, great question. 00:45:25.670 --> 00:45:29.160 align:middle line:84% OK, any other questions, before I go to soundness? 00:45:29.160 --> 00:45:29.660 align:middle line:90% OK. 00:45:29.660 --> 00:45:33.740 align:middle line:84% So soundness, that's the more interesting one. 00:45:33.740 --> 00:45:39.860 align:middle line:84% Soundness says, intuitively, that for any bounded poly 00:45:39.860 --> 00:45:43.730 align:middle line:84% lambda, or T bounded, there's some-- 00:45:43.730 --> 00:45:49.160 align:middle line:84% the soundness is like-- you can call it T soundness. 00:45:49.160 --> 00:45:51.260 align:middle line:90% OK, and you can think of-- 00:45:51.260 --> 00:45:53.970 align:middle line:84% poly soundness, you can think of it "2 to the lambda 00:45:53.970 --> 00:45:55.880 align:middle line:90% to the epsilon" soundness. 00:45:55.880 --> 00:45:57.650 align:middle line:84% But there's some T soundness, and it 00:45:57.650 --> 00:46:02.990 align:middle line:84% says any adversary that runs in time of size 00:46:02.990 --> 00:46:09.910 align:middle line:84% at most T, the probability that it can find 00:46:09.910 --> 00:46:14.750 align:middle line:84% a value and an index, a hash value and an index, 00:46:14.750 --> 00:46:18.910 align:middle line:84% so that at that index, he can successfully open to both 0 00:46:18.910 --> 00:46:21.375 align:middle line:90% and 1, is negligible. 00:46:21.375 --> 00:46:24.760 align:middle line:84% OK, so it essentially means, once the adversary gave you 00:46:24.760 --> 00:46:29.950 align:middle line:84% a hash value, for any index, he cannot generate a valid opening 00:46:29.950 --> 00:46:31.190 align:middle line:90% both for 0 and for 1. 00:46:31.190 --> 00:46:32.700 align:middle line:90% It's impossible for him. 00:46:32.700 --> 00:46:33.200 align:middle line:90% OK. 00:46:33.200 --> 00:46:34.810 align:middle line:90% So let me write it formally. 00:46:34.810 --> 00:46:40.400 align:middle line:90% So for any poly T-- 00:46:40.400 --> 00:46:43.040 align:middle line:84% again, phi of T is, like, linear, so poly lambda-- 00:46:43.040 --> 00:46:50.610 align:middle line:84% poly-T-sized adversary, the probability-- 00:46:50.610 --> 00:46:53.330 align:middle line:84% and the probability is over hash key-- he gets a random hash 00:46:53.330 --> 00:47:00.200 align:middle line:84% key chosen by Gen, OK, gets a random hash key chosen by Gen. 00:47:00.200 --> 00:47:04.580 align:middle line:84% This adversary, given the hash key, 00:47:04.580 --> 00:47:08.520 align:middle line:84% he tries to open some index in two different ways. 00:47:08.520 --> 00:47:13.730 align:middle line:84% So his goal is to give you a hash value v, an index 00:47:13.730 --> 00:47:18.060 align:middle line:84% i, and a valid opening rho 0 that 00:47:18.060 --> 00:47:24.190 align:middle line:84% opens to 0 and a valid opening rho 1 that opens to 1. 00:47:24.190 --> 00:47:25.400 align:middle line:90% That's what he outputs. 00:47:25.400 --> 00:47:26.930 align:middle line:90% So the adversary outputs-- 00:47:26.930 --> 00:47:28.030 align:middle line:90% he gets a hash key. 00:47:28.030 --> 00:47:31.900 align:middle line:84% He outputs a hash value, an index, and two openings 00:47:31.900 --> 00:47:32.900 align:middle line:90% for that index-- 00:47:32.900 --> 00:47:35.200 align:middle line:84% that's what he's trying to do-- one corresponding to 0, 00:47:35.200 --> 00:47:36.490 align:middle line:90% one corresponding to 1. 00:47:36.490 --> 00:47:39.370 align:middle line:84% And the probability that both of them 00:47:39.370 --> 00:47:42.940 align:middle line:84% are a valid opening, the probability that for every b 00:47:42.940 --> 00:47:47.540 align:middle line:90% in 0, 1, Verify agrees-- 00:47:47.540 --> 00:47:59.410 align:middle line:84% so Verify, given hash key v, i, and b and rho b, outputs 1, 00:47:59.410 --> 00:48:01.100 align:middle line:90% this is negligible. 00:48:01.100 --> 00:48:06.340 align:middle line:90% 00:48:06.340 --> 00:48:06.840 align:middle line:90% OK. 00:48:06.840 --> 00:48:10.170 align:middle line:84% So again, soundness is like collision resistance 00:48:10.170 --> 00:48:11.170 align:middle line:90% in this setting. 00:48:11.170 --> 00:48:14.400 align:middle line:84% So this is kind of another way to-- usually, people 00:48:14.400 --> 00:48:18.478 align:middle line:84% call this property collision resistance. 00:48:18.478 --> 00:48:20.020 align:middle line:84% And the collision resistance property 00:48:20.020 --> 00:48:22.840 align:middle line:84% says that once the adversary chose 00:48:22.840 --> 00:48:27.750 align:middle line:84% a hash value, the probability that for any index-- 00:48:27.750 --> 00:48:31.510 align:middle line:90% OK, he chooses for any index i-- 00:48:31.510 --> 00:48:35.610 align:middle line:84% the probability that it can open in a way 00:48:35.610 --> 00:48:38.760 align:middle line:84% that verifies, in an accepting way, to both 0 00:48:38.760 --> 00:48:42.850 align:middle line:84% and 1-- so for every b, rho b is a valid opening, 00:48:42.850 --> 00:48:45.960 align:middle line:84% rho 0 is valid for 0, and rho 1 is a valid opening for 1-- 00:48:45.960 --> 00:48:49.220 align:middle line:84% that happens with negligible probability. 00:48:49.220 --> 00:48:53.990 align:middle line:84% OK, so for every rho, there exists negligible-- 00:48:53.990 --> 00:48:57.120 align:middle line:90% 00:48:57.120 --> 00:49:07.270 align:middle line:84% such that-- OK, so this is the collision resistance property. 00:49:07.270 --> 00:49:12.700 align:middle line:90% 00:49:12.700 --> 00:49:14.625 align:middle line:84% Any questions about the property? 00:49:14.625 --> 00:49:20.100 align:middle line:90% 00:49:20.100 --> 00:49:23.130 align:middle line:84% OK, so now I have two things I want to do. 00:49:23.130 --> 00:49:26.490 align:middle line:84% The first thing-- oh, sorry, unordered, 00:49:26.490 --> 00:49:28.080 align:middle line:90% two things I want to do-- 00:49:28.080 --> 00:49:33.640 align:middle line:84% one is show you how you construct this thing, and two, 00:49:33.640 --> 00:49:37.090 align:middle line:84% show you how to use it to construct 00:49:37.090 --> 00:49:39.370 align:middle line:90% an interactive argument. 00:49:39.370 --> 00:49:43.720 align:middle line:84% Any preference on the order, what goes first? 00:49:43.720 --> 00:49:47.660 align:middle line:90% Who wants construction first? 00:49:47.660 --> 00:49:49.565 align:middle line:84% Who wants interactive argument first? 00:49:49.565 --> 00:49:53.943 align:middle line:90% 00:49:53.943 --> 00:49:55.360 align:middle line:84% OK, we'll do interactive argument, 00:49:55.360 --> 00:49:57.700 align:middle line:90% and then we'll do construction. 00:49:57.700 --> 00:50:01.060 align:middle line:84% It's not that-- if anybody wants to weigh in, say so, 00:50:01.060 --> 00:50:17.450 align:middle line:84% because it wasn't very significant, the result. OK, 00:50:17.450 --> 00:50:19.620 align:middle line:90% so interactive argument first? 00:50:19.620 --> 00:50:20.120 align:middle line:90% Yeah? 00:50:20.120 --> 00:50:21.940 align:middle line:90% OK. 00:50:21.940 --> 00:50:22.440 align:middle line:90% OK. 00:50:22.440 --> 00:50:25.830 align:middle line:90% So here is the-- 00:50:25.830 --> 00:50:30.073 align:middle line:84% this is what's known as the Kilian-Micali protocol. 00:50:30.073 --> 00:50:43.185 align:middle line:90% 00:50:43.185 --> 00:50:43.685 align:middle line:90% OK. 00:50:43.685 --> 00:50:59.130 align:middle line:90% 00:50:59.130 --> 00:50:59.740 align:middle line:90% OK. 00:50:59.740 --> 00:51:05.415 align:middle line:84% So actually, I want succinct interactive arguments for NP. 00:51:05.415 --> 00:51:07.290 align:middle line:84% OK, so I'm going to show you how to construct 00:51:07.290 --> 00:51:10.590 align:middle line:84% a succinct interactive argument for any NP language. 00:51:10.590 --> 00:51:12.210 align:middle line:90% OK. 00:51:12.210 --> 00:51:14.580 align:middle line:84% So here is how I'm going to do it. 00:51:14.580 --> 00:51:19.650 align:middle line:84% The prover, first-- so we have a prover and a verifier, 00:51:19.650 --> 00:51:22.575 align:middle line:84% and here is what they both share, a witness x. 00:51:22.575 --> 00:51:25.230 align:middle line:84% And the prover wants to prove to the verifier 00:51:25.230 --> 00:51:29.310 align:middle line:84% that x is in the language, and he has some witness. 00:51:29.310 --> 00:51:33.150 align:middle line:84% OK, and you can think about it as a 3-CNF-- 00:51:33.150 --> 00:51:35.650 align:middle line:84% can talk about 3-CNF and pick of it anyway. 00:51:35.650 --> 00:51:38.330 align:middle line:84% It can be nice to have something concrete in mind so you can 00:51:38.330 --> 00:51:41.260 align:middle line:84% think about x as being a 3-CNF and w as satisfying 00:51:41.260 --> 00:51:43.010 align:middle line:90% the assignment. 00:51:43.010 --> 00:51:43.730 align:middle line:90% OK. 00:51:43.730 --> 00:51:46.550 align:middle line:84% What does the prover do, the first thing? 00:51:46.550 --> 00:51:51.207 align:middle line:84% Any guess what the prover first does? 00:51:51.207 --> 00:51:52.290 align:middle line:90% AUDIENCE: Compute the PCP. 00:51:52.290 --> 00:51:53.220 align:middle line:90% YAEL KALAI: Thank you. 00:51:53.220 --> 00:51:55.220 align:middle line:84% Compute the PCP, that's the first thing he does. 00:51:55.220 --> 00:51:58.905 align:middle line:84% So he takes w and converts it to a PCP. 00:51:58.905 --> 00:52:01.580 align:middle line:90% 00:52:01.580 --> 00:52:02.080 align:middle line:90% OK. 00:52:02.080 --> 00:52:04.610 align:middle line:84% And if you want to have something concrete in mind, 00:52:04.610 --> 00:52:07.780 align:middle line:84% he opens up the GKR, adds a low-degree extension 00:52:07.780 --> 00:52:08.750 align:middle line:90% of the witness. 00:52:08.750 --> 00:52:09.830 align:middle line:90% That's a huge thing. 00:52:09.830 --> 00:52:11.020 align:middle line:90% That's a PCP. 00:52:11.020 --> 00:52:12.580 align:middle line:90% He can't ship it over. 00:52:12.580 --> 00:52:13.960 align:middle line:90% That's too big. 00:52:13.960 --> 00:52:17.344 align:middle line:90% What does he want to do instead? 00:52:17.344 --> 00:52:18.320 align:middle line:90% AUDIENCE: Hash it. 00:52:18.320 --> 00:52:19.400 align:middle line:90% YAEL KALAI: Hash. 00:52:19.400 --> 00:52:20.950 align:middle line:90% OK. 00:52:20.950 --> 00:52:22.420 align:middle line:90% He needs a hash key. 00:52:22.420 --> 00:52:24.970 align:middle line:84% He's like, I want a hash, Can anybody 00:52:24.970 --> 00:52:26.416 align:middle line:90% give me a hash key, right? 00:52:26.416 --> 00:52:28.820 align:middle line:84% Oh, let me-- sorry, because it's an argument, 00:52:28.820 --> 00:52:33.280 align:middle line:84% I should say they also share security parameter. 00:52:33.280 --> 00:52:35.410 align:middle line:84% So the first thing the verifier does 00:52:35.410 --> 00:52:38.450 align:middle line:84% is it says, sure, I'm going to-- here's a hash key. 00:52:38.450 --> 00:52:44.360 align:middle line:84% I'm going to generate it, and here you go. 00:52:44.360 --> 00:52:45.730 align:middle line:90% Now what does the prover do? 00:52:45.730 --> 00:52:48.888 align:middle line:90% 00:52:48.888 --> 00:52:49.844 align:middle line:90% AUDIENCE: Hash. 00:52:49.844 --> 00:52:50.800 align:middle line:90% YAEL KALAI: Hash. 00:52:50.800 --> 00:52:51.960 align:middle line:90% Thank you very much. 00:52:51.960 --> 00:52:53.450 align:middle line:90% So I compute. 00:52:53.450 --> 00:52:56.290 align:middle line:84% He sends over v. Usually, it's an-- 00:52:56.290 --> 00:53:08.350 align:middle line:84% OK, he sends v, which is Eval of hash key and the PCP, pi. 00:53:08.350 --> 00:53:09.140 align:middle line:90% OK. 00:53:09.140 --> 00:53:13.560 align:middle line:84% So the verifier gets this v, this digest. 00:53:13.560 --> 00:53:16.690 align:middle line:84% It's a bunch of bits with no meaning. 00:53:16.690 --> 00:53:19.070 align:middle line:84% He wants to open this PCP, right? 00:53:19.070 --> 00:53:21.770 align:middle line:84% He wants-- OK, so what does he do? 00:53:21.770 --> 00:53:26.403 align:middle line:84% The verifier gets the v, doesn't understand a thing. 00:53:26.403 --> 00:53:27.820 align:middle line:84% What does he want from the prover? 00:53:27.820 --> 00:53:29.915 align:middle line:90% What will he ask the prover? 00:53:29.915 --> 00:53:31.290 align:middle line:84% AUDIENCE: Randomly selects a bit. 00:53:31.290 --> 00:53:32.790 align:middle line:84% AUDIENCE: Open [INAUDIBLE] to open it. 00:53:32.790 --> 00:53:33.623 align:middle line:90% YAEL KALAI: Exactly. 00:53:33.623 --> 00:53:36.690 align:middle line:84% He randomly selects a bit and has to open it. 00:53:36.690 --> 00:53:38.140 align:middle line:90% Which distribution? 00:53:38.140 --> 00:53:43.980 align:middle line:84% How will he choose which bits to open from this PCP? 00:53:43.980 --> 00:53:48.580 align:middle line:84% AUDIENCE: [INAUDIBLE] whatever-- the PCP asks to call it oracle, 00:53:48.580 --> 00:53:49.080 align:middle line:90% right? 00:53:49.080 --> 00:53:49.913 align:middle line:90% YAEL KALAI: Exactly. 00:53:49.913 --> 00:53:54.670 align:middle line:84% What the-- exactly, as the PCP verifier, so what he does, 00:53:54.670 --> 00:53:56.735 align:middle line:90% he runs the V PCP. 00:53:56.735 --> 00:54:00.680 align:middle line:90% 00:54:00.680 --> 00:54:05.550 align:middle line:84% And the PCP verifier tells him, oh, sure, I 00:54:05.550 --> 00:54:07.015 align:middle line:90% want to know some il. 00:54:07.015 --> 00:54:10.650 align:middle line:90% 00:54:10.650 --> 00:54:12.880 align:middle line:84% So, OK, let me just mention, sorry, 00:54:12.880 --> 00:54:15.420 align:middle line:84% I'm going to construct an interactive argument for NP 00:54:15.420 --> 00:54:16.870 align:middle line:90% from two ingredients. 00:54:16.870 --> 00:54:20.010 align:middle line:84% Yeah, one, I'm going to use a PCP, 00:54:20.010 --> 00:54:24.280 align:middle line:84% so we have a PCP in our heads, the GKR PCP-- yeah, we have it-- 00:54:24.280 --> 00:54:27.120 align:middle line:84% and, two, this collision-resistant hash 00:54:27.120 --> 00:54:30.320 align:middle line:90% with local opening. 00:54:30.320 --> 00:54:32.070 align:middle line:84% These are two ingredients that we're going 00:54:32.070 --> 00:54:34.530 align:middle line:90% to use in this construction. 00:54:34.530 --> 00:54:36.360 align:middle line:90% And we're going to assume-- 00:54:36.360 --> 00:54:38.620 align:middle line:84% remember, we talked about PCP when we defined it. 00:54:38.620 --> 00:54:41.130 align:middle line:84% It was before we went to kind of crypto land. 00:54:41.130 --> 00:54:43.560 align:middle line:84% And we said there's two parameters, c and s, 00:54:43.560 --> 00:54:44.710 align:middle line:90% completeness and soundness. 00:54:44.710 --> 00:54:48.120 align:middle line:84% We said that a PCP comes with two parameters, completeness 00:54:48.120 --> 00:54:49.500 align:middle line:90% and soundness, c and s. 00:54:49.500 --> 00:54:54.390 align:middle line:84% And usually, we think of the completeness as 1, 00:54:54.390 --> 00:54:57.700 align:middle line:84% because all our PCP have actually completeness 1. 00:54:57.700 --> 00:54:59.940 align:middle line:84% It's easy to construct them with completeness 1. 00:54:59.940 --> 00:55:03.790 align:middle line:90% Soundness, we pay for soundness. 00:55:03.790 --> 00:55:07.490 align:middle line:84% So the more queries you get, the better soundness you get. 00:55:07.490 --> 00:55:13.090 align:middle line:84% And here we're going to always assume that the soundness is 00:55:13.090 --> 00:55:13.940 align:middle line:90% negligible. 00:55:13.940 --> 00:55:17.360 align:middle line:90% 00:55:17.360 --> 00:55:17.860 align:middle line:90% OK. 00:55:17.860 --> 00:55:20.350 align:middle line:84% So we give enough-- so for example, 00:55:20.350 --> 00:55:25.780 align:middle line:84% if we do one GKR, if you just run the GKR verifier once, 00:55:25.780 --> 00:55:29.100 align:middle line:84% if you remember, you kind of query one point 00:55:29.100 --> 00:55:30.670 align:middle line:90% and the low-degree extension. 00:55:30.670 --> 00:55:35.350 align:middle line:84% But a field element in GKR is of size 1 over polylog. 00:55:35.350 --> 00:55:37.110 align:middle line:90% So the sound is still get-- 00:55:37.110 --> 00:55:39.070 align:middle line:84% sorry, the field size is polylog, 00:55:39.070 --> 00:55:41.200 align:middle line:84% so the soundness you'll get is 1 over polylog, 00:55:41.200 --> 00:55:43.410 align:middle line:90% which is not great. 00:55:43.410 --> 00:55:44.500 align:middle line:90% I want negligible. 00:55:44.500 --> 00:55:47.640 align:middle line:84% So I'll need to repeat the GKR enough times, 00:55:47.640 --> 00:55:51.370 align:middle line:84% like, log times, so that it will become negligible. 00:55:51.370 --> 00:55:53.590 align:middle line:84% I want my soundness to become negligible. 00:55:53.590 --> 00:55:56.760 align:middle line:84% The reason I want the soundness of the PCP to be negligible 00:55:56.760 --> 00:55:59.710 align:middle line:84% is because when we defined interactive arguments, 00:55:59.710 --> 00:56:01.720 align:middle line:84% we wanted soundness to be negligible. 00:56:01.720 --> 00:56:04.080 align:middle line:84% OK, and these two will kind of-- the soundness I 00:56:04.080 --> 00:56:06.852 align:middle line:84% get from my interactive argument will kind of 00:56:06.852 --> 00:56:09.060 align:middle line:84% depend on the soundness I'm going to get from my PCP. 00:56:09.060 --> 00:56:10.477 align:middle line:84% So I'm going to assume here that I 00:56:10.477 --> 00:56:13.510 align:middle line:84% have a PCP with negligible soundness, that I ask-- 00:56:13.510 --> 00:56:16.110 align:middle line:84% so if I have a PCP with soundness half, 00:56:16.110 --> 00:56:18.190 align:middle line:90% I'll just repeat it polylog-- 00:56:18.190 --> 00:56:21.400 align:middle line:84% like, I'll repeat it, let's say, lambda times, 00:56:21.400 --> 00:56:24.780 align:middle line:84% and now my soundness becomes 1 over 2 to the lambda. 00:56:24.780 --> 00:56:26.640 align:middle line:90% OK. 00:56:26.640 --> 00:56:31.520 align:middle line:84% So I'm going to always assume that it's negligible in lambda. 00:56:31.520 --> 00:56:35.010 align:middle line:90% 00:56:35.010 --> 00:56:40.930 align:middle line:84% OK, so I run the PCP verifier-- yeah? 00:56:40.930 --> 00:56:43.592 align:middle line:84% AUDIENCE: So c minus the oracle access to the proof? 00:56:43.592 --> 00:56:44.800 align:middle line:90% YAEL KALAI: What do you mean? 00:56:44.800 --> 00:56:46.480 align:middle line:90% What is the previous version? 00:56:46.480 --> 00:56:48.188 align:middle line:84% AUDIENCE: The previous version, where you 00:56:48.188 --> 00:56:50.355 align:middle line:90% had to query the proof oracle. 00:56:50.355 --> 00:56:50.980 align:middle line:90% YAEL KALAI: OK. 00:56:50.980 --> 00:56:52.130 align:middle line:90% So when you-- OK. 00:56:52.130 --> 00:56:54.910 align:middle line:84% So you said, let's remember the PCP model, 00:56:54.910 --> 00:56:58.160 align:middle line:84% where I had the PCP as an oracle, and I queried it. 00:56:58.160 --> 00:56:59.650 align:middle line:90% That was very succinct. 00:56:59.650 --> 00:57:04.060 align:middle line:84% But if I had an oracle, in which world do I have an oracle? 00:57:04.060 --> 00:57:05.890 align:middle line:90% This oracle is a nice-- 00:57:05.890 --> 00:57:07.942 align:middle line:84% like, who puts the PCP in the sky for me? 00:57:07.942 --> 00:57:08.650 align:middle line:90% Where is the sky? 00:57:08.650 --> 00:57:09.940 align:middle line:90% It's not sitting on a cloud. 00:57:09.940 --> 00:57:14.290 align:middle line:84% It's like a-- well, cloud, I guess, now has many meanings, 00:57:14.290 --> 00:57:16.340 align:middle line:84% so it can be sitting, actually, on a cloud. 00:57:16.340 --> 00:57:18.050 align:middle line:90% But that's kind of the point. 00:57:18.050 --> 00:57:20.080 align:middle line:84% We don't want anyone to store this thing. 00:57:20.080 --> 00:57:23.050 align:middle line:84% We don't want to assume someone actually holds this thing. 00:57:23.050 --> 00:57:26.450 align:middle line:84% So in that model where you assume you have an oracle, 00:57:26.450 --> 00:57:27.580 align:middle line:90% everything is succinct. 00:57:27.580 --> 00:57:30.370 align:middle line:84% Now what I'm trying to do here is get rid of that assumption 00:57:30.370 --> 00:57:32.300 align:middle line:90% that I have an oracle. 00:57:32.300 --> 00:57:32.800 align:middle line:90% Great. 00:57:32.800 --> 00:57:33.320 align:middle line:90% Yeah? 00:57:33.320 --> 00:57:35.028 align:middle line:84% AUDIENCE: What about even before the PCP, 00:57:35.028 --> 00:57:37.690 align:middle line:84% if you were to just do interactive GKR 00:57:37.690 --> 00:57:40.270 align:middle line:90% on the circuit [INAUDIBLE]? 00:57:40.270 --> 00:57:41.730 align:middle line:90% YAEL KALAI: OK. 00:57:41.730 --> 00:57:42.230 align:middle line:90% Good, good. 00:57:42.230 --> 00:57:42.860 align:middle line:90% Great, great. 00:57:42.860 --> 00:57:45.190 align:middle line:84% So the question is, look, just do an interactive GKR 00:57:45.190 --> 00:57:46.120 align:middle line:90% on the circuit-- 00:57:46.120 --> 00:57:51.310 align:middle line:84% on this c sub phi that may be here. 00:57:51.310 --> 00:57:53.290 align:middle line:90% Oh, no, it vanished. 00:57:53.290 --> 00:57:55.550 align:middle line:90% You can, but here's the problem. 00:57:55.550 --> 00:57:57.148 align:middle line:84% You can do GKR, and essentially, it's 00:57:57.148 --> 00:57:58.940 align:middle line:84% what we're doing in the PCP, in some sense. 00:57:58.940 --> 00:58:00.150 align:middle line:90% But here's the issue. 00:58:00.150 --> 00:58:01.400 align:middle line:90% But you're saying do you care. 00:58:01.400 --> 00:58:04.100 align:middle line:84% You don't need to deal with hashing, right. 00:58:04.100 --> 00:58:06.560 align:middle line:84% That's kind of your point-- a very, very good point. 00:58:06.560 --> 00:58:11.222 align:middle line:84% However, in GKR, anybody see-- that's actually a good-- anybody 00:58:11.222 --> 00:58:11.930 align:middle line:90% see what's wrong? 00:58:11.930 --> 00:58:13.975 align:middle line:90% So let me repeat your point. 00:58:13.975 --> 00:58:15.100 align:middle line:90% The point is the following. 00:58:15.100 --> 00:58:17.330 align:middle line:90% Look, GKR is succinct. 00:58:17.330 --> 00:58:18.370 align:middle line:90% Think of 3-SAT. 00:58:18.370 --> 00:58:19.237 align:middle line:90% It's very low depth. 00:58:19.237 --> 00:58:19.820 align:middle line:90% It's succinct. 00:58:19.820 --> 00:58:21.520 align:middle line:84% The communication is very succinct. 00:58:21.520 --> 00:58:25.720 align:middle line:84% Why are you now going to crypto and opening GKR just 00:58:25.720 --> 00:58:27.980 align:middle line:90% to be done with it? 00:58:27.980 --> 00:58:30.508 align:middle line:90% What are we doing all of this? 00:58:30.508 --> 00:58:31.800 align:middle line:90% AUDIENCE: You need the witness. 00:58:31.800 --> 00:58:33.030 align:middle line:90% YAEL KALAI: Very good. 00:58:33.030 --> 00:58:33.690 align:middle line:90% Why? 00:58:33.690 --> 00:58:36.000 align:middle line:84% Because GKR works if the verifier knows 00:58:36.000 --> 00:58:39.970 align:middle line:84% the witness, if the verifier knows the input. 00:58:39.970 --> 00:58:41.500 align:middle line:84% In GKR, when we talked about GKR, 00:58:41.500 --> 00:58:46.290 align:middle line:84% we said, look, the verifier and prover both hold an input. 00:58:46.290 --> 00:58:50.220 align:middle line:84% And the verifier wants to know the output of this circuit 00:58:50.220 --> 00:58:51.380 align:middle line:90% and the input that he has. 00:58:51.380 --> 00:58:53.960 align:middle line:90% 00:58:53.960 --> 00:58:56.600 align:middle line:84% And indeed, at the end, the verifier 00:58:56.600 --> 00:59:01.100 align:middle line:84% needs to check the final thing against his input. 00:59:01.100 --> 00:59:02.600 align:middle line:84% Is it, in the end, going to get kind 00:59:02.600 --> 00:59:04.500 align:middle line:84% of a value in the low-degree extension? 00:59:04.500 --> 00:59:07.220 align:middle line:84% And he checks, oh, is this consistent with the input 00:59:07.220 --> 00:59:09.320 align:middle line:90% I have in my hand? 00:59:09.320 --> 00:59:12.020 align:middle line:90% Now he doesn't have an input. 00:59:12.020 --> 00:59:13.520 align:middle line:90% So what do you do? 00:59:13.520 --> 00:59:17.200 align:middle line:84% So, actually, let me tell you something. 00:59:17.200 --> 00:59:18.719 align:middle line:84% The way these things are actually 00:59:18.719 --> 00:59:20.636 align:middle line:84% implemented-- it's a very interesting that you 00:59:20.636 --> 00:59:22.511 align:middle line:84% say that, because the way they're implemented 00:59:22.511 --> 00:59:24.370 align:middle line:84% is actually more along what you said. 00:59:24.370 --> 00:59:28.000 align:middle line:84% What they do is first they commit to just the witness. 00:59:28.000 --> 00:59:30.250 align:middle line:84% You're saying, why are you committing [INAUDIBLE] PCP? 00:59:30.250 --> 00:59:32.650 align:middle line:84% If you have a witness, commit to that, 00:59:32.650 --> 00:59:35.642 align:middle line:84% or commit to the low-degree extension of the witness. 00:59:35.642 --> 00:59:37.600 align:middle line:84% And actually, in practice, that's what they do. 00:59:37.600 --> 00:59:39.017 align:middle line:84% They only commit to the low-degree 00:59:39.017 --> 00:59:41.650 align:middle line:84% and then they apply this interactive GKR. 00:59:41.650 --> 00:59:44.470 align:middle line:84% Or now they have even better protocols, IOPs, 00:59:44.470 --> 00:59:46.665 align:middle line:90% but that's for another time. 00:59:46.665 --> 00:59:49.180 align:middle line:84% AUDIENCE: So you're saying that once you 00:59:49.180 --> 00:59:51.538 align:middle line:84% can commit to the witness and you do normal GKR, 00:59:51.538 --> 00:59:53.830 align:middle line:84% and then you only need to open the bits and the witness 00:59:53.830 --> 00:59:55.097 align:middle line:90% that you care about. 00:59:55.097 --> 00:59:55.930 align:middle line:90% YAEL KALAI: Exactly. 00:59:55.930 --> 00:59:57.880 align:middle line:84% So what you can do, you can-- first, 00:59:57.880 --> 01:00:00.500 align:middle line:84% the prover can tell the verifier-- sorry, 01:00:00.500 --> 01:00:03.550 align:middle line:84% the verifier tells the prover, you 01:00:03.550 --> 01:00:05.780 align:middle line:84% claim that you have a satisfying assignment. 01:00:05.780 --> 01:00:08.483 align:middle line:84% Give me a low-degree extension of your assignment, 01:00:08.483 --> 01:00:11.150 align:middle line:84% but hash it down because I don't want to hold this entire thing. 01:00:11.150 --> 01:00:12.250 align:middle line:90% Now I have a hash. 01:00:12.250 --> 01:00:13.600 align:middle line:90% Now we're going to do GKR. 01:00:13.600 --> 01:00:18.470 align:middle line:84% Do GKR, then I need to check a random point in the-- 01:00:18.470 --> 01:00:20.490 align:middle line:84% a random point in the low-degree extension. 01:00:20.490 --> 01:00:22.080 align:middle line:90% I'll ask the prover, now open. 01:00:22.080 --> 01:00:24.740 align:middle line:84% But now you're committed ahead of time. 01:00:24.740 --> 01:00:27.230 align:middle line:84% AUDIENCE: And then you have to make sure it was low degree. 01:00:27.230 --> 01:00:28.850 align:middle line:84% YAEL KALAI: You need to add a low-degree test to it. 01:00:28.850 --> 01:00:29.630 align:middle line:90% Yeah. 01:00:29.630 --> 01:00:32.260 align:middle line:90% Exactly. 01:00:32.260 --> 01:00:35.290 align:middle line:84% So, many of the implementations, that's exactly how they work. 01:00:35.290 --> 01:00:37.450 align:middle line:84% And actually, a lot of the work currently, 01:00:37.450 --> 01:00:40.300 align:middle line:84% in the last couple of years, is actually not 01:00:40.300 --> 01:00:43.000 align:middle line:84% so much on improving GKR-- that, too, but a lot of the work 01:00:43.000 --> 01:00:44.525 align:middle line:84% is actually on the commitment, How 01:00:44.525 --> 01:00:46.150 align:middle line:84% do you construct this commitment that's 01:00:46.150 --> 01:00:50.500 align:middle line:84% kind of the most efficient? and so on. 01:00:50.500 --> 01:00:51.200 align:middle line:90% OK. 01:00:51.200 --> 01:00:53.020 align:middle line:90% Great. 01:00:53.020 --> 01:00:55.077 align:middle line:90% So-- yeah? 01:00:55.077 --> 01:00:56.660 align:middle line:84% AUDIENCE: Do you not give the verifier 01:00:56.660 --> 01:00:58.470 align:middle line:84% the witness because the witness is too large? 01:00:58.470 --> 01:00:59.303 align:middle line:90% YAEL KALAI: Exactly. 01:00:59.303 --> 01:00:59.820 align:middle line:90% Exactly. 01:00:59.820 --> 01:01:01.260 align:middle line:84% We don't want to give the verifier the witness, 01:01:01.260 --> 01:01:02.218 align:middle line:90% because it's too large. 01:01:02.218 --> 01:01:04.440 align:middle line:84% AUDIENCE: So we don't have zero-knowledge properties. 01:01:04.440 --> 01:01:06.523 align:middle line:84% YAEL KALAI: I don't care now about zero-knowledge. 01:01:06.523 --> 01:01:08.280 align:middle line:84% Usually, when people implement this, 01:01:08.280 --> 01:01:10.610 align:middle line:84% they add zero-knowledge on top, kind of as a-- 01:01:10.610 --> 01:01:13.650 align:middle line:84% but for now, I don't care at all about hiding. 01:01:13.650 --> 01:01:17.000 align:middle line:84% I just want verification, like, just to verify correctness. 01:01:17.000 --> 01:01:17.630 align:middle line:90% Yeah. 01:01:17.630 --> 01:01:22.160 align:middle line:84% No, like, all of the hiding zero-knowledge 01:01:22.160 --> 01:01:23.660 align:middle line:90% is kind of orthogonal. 01:01:23.660 --> 01:01:24.560 align:middle line:90% Yeah? 01:01:24.560 --> 01:01:26.960 align:middle line:84% AUDIENCE: So the commitment that's given to the verifier 01:01:26.960 --> 01:01:28.440 align:middle line:90% is only used for verification. 01:01:28.440 --> 01:01:30.290 align:middle line:90% It's never actually opened. 01:01:30.290 --> 01:01:32.060 align:middle line:90% It's never opened completely. 01:01:32.060 --> 01:01:33.570 align:middle line:90% Yeah, it's never-- good point. 01:01:33.570 --> 01:01:37.040 align:middle line:84% So what you're saying-- this hash 01:01:37.040 --> 01:01:39.200 align:middle line:90% will never be completely opened. 01:01:39.200 --> 01:01:39.700 align:middle line:90% OK. 01:01:39.700 --> 01:01:43.170 align:middle line:90% So the prover computes this PCP. 01:01:43.170 --> 01:01:44.250 align:middle line:90% He sends it over. 01:01:44.250 --> 01:01:46.860 align:middle line:84% The PCP will never be opened in its entirety. 01:01:46.860 --> 01:01:48.560 align:middle line:90% It's too big, or the witness-- 01:01:48.560 --> 01:01:51.030 align:middle line:84% again, never going to be open in its entirety. 01:01:51.030 --> 01:01:56.400 align:middle line:84% Instead, what happens is the verifier generates PCP queries, 01:01:56.400 --> 01:02:01.790 align:middle line:84% and he sends the PCP queries i1 up to il. 01:02:01.790 --> 01:02:10.040 align:middle line:84% And what the prover does, he only opens the locations pi i1 01:02:10.040 --> 01:02:11.910 align:middle line:90% up to pi il. 01:02:11.910 --> 01:02:15.800 align:middle line:84% So he only gives him the PCP and these locations 01:02:15.800 --> 01:02:21.660 align:middle line:84% and opening, rho i1 up to rho il. 01:02:21.660 --> 01:02:22.425 align:middle line:90% Yeah? 01:02:22.425 --> 01:02:23.800 align:middle line:84% AUDIENCE: This is a minor detail, 01:02:23.800 --> 01:02:27.030 align:middle line:84% but it was mentioned before that when you query everything 01:02:27.030 --> 01:02:29.082 align:middle line:84% in parallel, sometimes it's not sound. 01:02:29.082 --> 01:02:30.540 align:middle line:84% Can these be sent at the same time, 01:02:30.540 --> 01:02:33.000 align:middle line:84% or would they have to be sent through multiple, sequential 01:02:33.000 --> 01:02:33.430 align:middle line:90% rounds? 01:02:33.430 --> 01:02:34.055 align:middle line:90% YAEL KALAI: OK. 01:02:34.055 --> 01:02:38.250 align:middle line:84% So if you do a PCP, then they can be sent exactly 01:02:38.250 --> 01:02:41.010 align:middle line:84% the same time, because a PCP was committed to the PCP, 01:02:41.010 --> 01:02:41.710 align:middle line:90% and we're done. 01:02:41.710 --> 01:02:43.960 align:middle line:84% If you do GKR, you need to do everything sequentially. 01:02:43.960 --> 01:02:44.627 align:middle line:90% AUDIENCE: Right. 01:02:44.627 --> 01:02:45.180 align:middle line:90% OK. 01:02:45.180 --> 01:02:47.730 align:middle line:84% YAEL KALAI: Yeah, if you did-- so if you did the version that 01:02:47.730 --> 01:02:52.210 align:middle line:84% was proposed here, where you don't do PCP at all, 01:02:52.210 --> 01:02:53.880 align:middle line:84% you have your witness, and then you 01:02:53.880 --> 01:02:57.960 align:middle line:84% need to do GKR completely interactive. 01:02:57.960 --> 01:02:59.920 align:middle line:84% But if you have a PCP, then it's committed. 01:02:59.920 --> 01:03:01.560 align:middle line:84% Now you don't have to do anything sequentially. 01:03:01.560 --> 01:03:02.140 align:middle line:90% That's it. 01:03:02.140 --> 01:03:03.990 align:middle line:90% The guy is kind of stuck. 01:03:03.990 --> 01:03:06.180 align:middle line:84% So you can do everything at the same time. 01:03:06.180 --> 01:03:08.680 align:middle line:84% So, great, so you send all the queries, 01:03:08.680 --> 01:03:10.230 align:middle line:90% you get back the answers. 01:03:10.230 --> 01:03:11.890 align:middle line:90% What does the verifier do. 01:03:11.890 --> 01:03:13.840 align:middle line:84% How does he decide if to accept or reject? 01:03:13.840 --> 01:03:16.310 align:middle line:90% What tests does the verifier do? 01:03:16.310 --> 01:03:20.990 align:middle line:90% 01:03:20.990 --> 01:03:21.490 align:middle line:90% Yeah? 01:03:21.490 --> 01:03:23.740 align:middle line:84% AUDIENCE: Verify that the opening is correct, and then 01:03:23.740 --> 01:03:24.730 align:middle line:90% runs the PCP verifier. 01:03:24.730 --> 01:03:26.250 align:middle line:90% YAEL KALAI: Fantastic exactly. 01:03:26.250 --> 01:03:26.940 align:middle line:90% What does he do? 01:03:26.940 --> 01:03:28.170 align:middle line:90% He runs two things. 01:03:28.170 --> 01:03:33.740 align:middle line:84% He runs the PCP verifier with kind of i1, il, pi 01:03:33.740 --> 01:03:42.350 align:middle line:84% i1 up to pi il, with x also, x comma, and checks that it's 1. 01:03:42.350 --> 01:03:44.220 align:middle line:84% And it also checks all the openings. 01:03:44.220 --> 01:03:59.350 align:middle line:84% So we check that Verify of hash key v, ij, pi ij, rho ij, 01:03:59.350 --> 01:04:03.636 align:middle line:90% equals 1 for every j. 01:04:03.636 --> 01:04:05.572 align:middle line:90% AUDIENCE: Would that be pi ix? 01:04:05.572 --> 01:04:08.480 align:middle line:90% [INAUDIBLE] 01:04:08.480 --> 01:04:10.513 align:middle line:84% YAEL KALAI: Pi ij is kind of-- oh. 01:04:10.513 --> 01:04:12.680 align:middle line:84% AUDIENCE: [INAUDIBLE] you add one should that be pi? 01:04:12.680 --> 01:04:17.690 align:middle line:84% YAEL KALAI: No, because when you verify a PCP, OK, 01:04:17.690 --> 01:04:19.880 align:middle line:84% the verifier never knows the entire pi. 01:04:19.880 --> 01:04:22.040 align:middle line:90% He never reads the entire pi. 01:04:22.040 --> 01:04:25.520 align:middle line:84% But to verify, of course, he needs to know the instance. 01:04:25.520 --> 01:04:27.330 align:middle line:84% You need to check it against the instance. 01:04:27.330 --> 01:04:31.550 align:middle line:84% So the proof is succinct, but the verifier's work, 01:04:31.550 --> 01:04:35.445 align:middle line:84% he has to read what the claim is. 01:04:35.445 --> 01:04:35.945 align:middle line:90% OK. 01:04:35.945 --> 01:04:39.620 align:middle line:84% So the verifier will run in time linear in x. 01:04:39.620 --> 01:04:42.950 align:middle line:84% That, he needs, to read what the claim is. 01:04:42.950 --> 01:04:46.290 align:middle line:84% But the communication is very small. 01:04:46.290 --> 01:04:49.230 align:middle line:84% So the communication is hash key, 01:04:49.230 --> 01:04:51.080 align:middle line:84% which is poly security parameter; 01:04:51.080 --> 01:04:55.300 align:middle line:84% v, which is a security parameter; i1 up to il, 01:04:55.300 --> 01:04:57.640 align:middle line:84% which is going to be at most security parameter; 01:04:57.640 --> 01:04:59.750 align:middle line:84% and the opening, which is a security parameter. 01:04:59.750 --> 01:05:03.220 align:middle line:84% So everything here only grows with the security parameter, 01:05:03.220 --> 01:05:05.900 align:middle line:84% OK, polynomial security parameter, not with x. 01:05:05.900 --> 01:05:09.175 align:middle line:84% So the security parameter is polylog n-- 01:05:09.175 --> 01:05:11.180 align:middle line:90% n being the length of x-- 01:05:11.180 --> 01:05:14.110 align:middle line:84% then you'll have communication polylog n. 01:05:14.110 --> 01:05:17.470 align:middle line:84% To verify-- well, OK, this verification 01:05:17.470 --> 01:05:19.960 align:middle line:84% is of size polylog n, like security parameter, 01:05:19.960 --> 01:05:21.500 align:middle line:90% because the x doesn't come in. 01:05:21.500 --> 01:05:24.950 align:middle line:84% But, of course, to verify the PCP, you need to read the input. 01:05:24.950 --> 01:05:27.910 align:middle line:84% You need to read the claim you're verifying. 01:05:27.910 --> 01:05:31.870 align:middle line:84% So here, you do run in time linear. 01:05:31.870 --> 01:05:34.330 align:middle line:84% These PCPs usually-- the runtime of the verifier 01:05:34.330 --> 01:05:37.240 align:middle line:90% is linear in the input length. 01:05:37.240 --> 01:05:39.490 align:middle line:84% And let me mention, actually, there's 01:05:39.490 --> 01:05:43.450 align:middle line:84% this notion which we won't go into this semester, 01:05:43.450 --> 01:05:46.160 align:middle line:84% but it's called PCP of proximity, 01:05:46.160 --> 01:05:49.220 align:middle line:84% where the verifier doesn't even need to read the input. 01:05:49.220 --> 01:05:51.070 align:middle line:90% He just reads a little bit. 01:05:51.070 --> 01:05:54.560 align:middle line:84% But now, of course, if he only reads a little bit, 01:05:54.560 --> 01:05:57.182 align:middle line:84% then how does he know that the input is correct? 01:05:57.182 --> 01:05:59.140 align:middle line:84% Maybe he didn't read one bit, and that flips it 01:05:59.140 --> 01:06:00.400 align:middle line:90% from true to false, you know? 01:06:00.400 --> 01:06:04.550 align:middle line:84% So the only guarantee he has that if he's accepted, 01:06:04.550 --> 01:06:08.140 align:middle line:84% then this input is closed to an input in the language, that's 01:06:08.140 --> 01:06:09.350 align:middle line:90% why the proximity. 01:06:09.350 --> 01:06:13.210 align:middle line:84% So there is a notion where the verifier is actually 01:06:13.210 --> 01:06:15.070 align:middle line:90% sublinear in x. 01:06:15.070 --> 01:06:16.463 align:middle line:84% He runs in time much less than x, 01:06:16.463 --> 01:06:18.880 align:middle line:84% but then the guarantee's weaker, the soundness guarantee's 01:06:18.880 --> 01:06:19.380 align:middle line:90% weaker. 01:06:19.380 --> 01:06:22.780 align:middle line:84% The soundness just says that if you accept, 01:06:22.780 --> 01:06:27.560 align:middle line:84% you cannot accept statements which are far from being 01:06:27.560 --> 01:06:29.480 align:middle line:84% in the language, but you may be able-- 01:06:29.480 --> 01:06:32.850 align:middle line:84% you may accept sentences-- you may accept claims that are false 01:06:32.850 --> 01:06:34.860 align:middle line:84% but close to ones that are in the language. 01:06:34.860 --> 01:06:38.630 align:middle line:84% So it's a proximity-type soundness guarantee, 01:06:38.630 --> 01:06:39.560 align:middle line:90% but without-- 01:06:39.560 --> 01:06:41.370 align:middle line:84% if you really want soundness, yes or no, 01:06:41.370 --> 01:06:43.240 align:middle line:90% you have to read the input. 01:06:43.240 --> 01:06:48.030 align:middle line:84% There's nothing you can do, unless the input 01:06:48.030 --> 01:06:50.082 align:middle line:84% is kind of in an error-correcting code 01:06:50.082 --> 01:06:51.790 align:middle line:84% or you changed something about the model. 01:06:51.790 --> 01:06:55.930 align:middle line:84% But otherwise, you have to read the input. 01:06:55.930 --> 01:06:58.220 align:middle line:84% Any questions about the construction? 01:06:58.220 --> 01:07:00.770 align:middle line:84% Forget about soundness and so on-- just about the-- 01:07:00.770 --> 01:07:05.030 align:middle line:84% like, about the proof, just about the construction. 01:07:05.030 --> 01:07:05.530 align:middle line:90% OK. 01:07:05.530 --> 01:07:07.260 align:middle line:84% So I just want to point to one thing 01:07:07.260 --> 01:07:10.890 align:middle line:84% that I said, let's send i1 up to il. 01:07:10.890 --> 01:07:15.240 align:middle line:84% Really, the way the PCP verifier works is he gets his input 01:07:15.240 --> 01:07:17.850 align:middle line:84% like-- let's say the security parameter just didn't know how 01:07:17.850 --> 01:07:19.690 align:middle line:90% many times to repeat the-- 01:07:19.690 --> 01:07:22.080 align:middle line:90% if the original PCP-- 01:07:22.080 --> 01:07:24.210 align:middle line:84% if the original PCP, let's say, is of size-- 01:07:24.210 --> 01:07:25.710 align:middle line:84% has soundness half, he needs to know 01:07:25.710 --> 01:07:27.280 align:middle line:84% how many times he needs to repeat it, 01:07:27.280 --> 01:07:29.220 align:middle line:84% so there's some security parameter. 01:07:29.220 --> 01:07:33.340 align:middle line:84% And some, he also knows the input length, like n in binary. 01:07:33.340 --> 01:07:40.280 align:middle line:84% So this can be very efficient, and he uses randomness. 01:07:40.280 --> 01:07:44.000 align:middle line:84% What my point is, instead of sending i1 one up to il, 01:07:44.000 --> 01:07:48.278 align:middle line:84% instead, he could have just sent the randomness. 01:07:48.278 --> 01:07:49.820 align:middle line:84% OK, he could have sent the randomness 01:07:49.820 --> 01:07:52.560 align:middle line:84% and told the prover, OK, you see this randomness? 01:07:52.560 --> 01:07:55.980 align:middle line:90% Compute-- run this yourself. 01:07:55.980 --> 01:07:56.480 align:middle line:90% OK. 01:07:56.480 --> 01:07:57.570 align:middle line:90% Why am I saying this? 01:07:57.570 --> 01:08:00.630 align:middle line:84% It's like, OK, fine, why is that interesting? 01:08:00.630 --> 01:08:05.150 align:middle line:84% The reason this is very interesting is because-- 01:08:05.150 --> 01:08:06.990 align:middle line:90% and also here, by the way. 01:08:06.990 --> 01:08:09.400 align:middle line:90% Here, instead of the-- 01:08:09.400 --> 01:08:13.070 align:middle line:90% this is a randomized algorithm. 01:08:13.070 --> 01:08:14.990 align:middle line:84% Actually, here, it's not important. 01:08:14.990 --> 01:08:16.410 align:middle line:90% Let's just leave this as is. 01:08:16.410 --> 01:08:17.840 align:middle line:90% I want to focus on this here. 01:08:17.840 --> 01:08:19.250 align:middle line:90% Why is this important? 01:08:19.250 --> 01:08:24.330 align:middle line:84% Because later-- not today, but later in this class-- 01:08:24.330 --> 01:08:26.120 align:middle line:84% we'll start, actually, next week. 01:08:26.120 --> 01:08:29.620 align:middle line:90% We'll see that a-- 01:08:29.620 --> 01:08:31.370 align:middle line:84% we'll want to go-- after we'll prove this, 01:08:31.370 --> 01:08:32.995 align:middle line:84% and we'll be very happy, and we'll say, 01:08:32.995 --> 01:08:36.270 align:middle line:84% wow, we have a succinct argument and it's so succinct, 01:08:36.270 --> 01:08:40.037 align:middle line:84% we can have the security parameter-- success, happiness. 01:08:40.037 --> 01:08:42.120 align:middle line:84% But then, of course, every time we have something, 01:08:42.120 --> 01:08:44.000 align:middle line:84% we want some more, and then we'll say, 01:08:44.000 --> 01:08:47.260 align:middle line:84% you know what, we don't want interaction. 01:08:47.260 --> 01:08:48.220 align:middle line:90% Why interaction? 01:08:48.220 --> 01:08:51.189 align:middle line:84% We want to go back to kind of actual proofs, 01:08:51.189 --> 01:08:53.450 align:middle line:84% so we want to eliminate interaction. 01:08:53.450 --> 01:08:56.590 align:middle line:84% And what we'll see is a way to eliminate interaction 01:08:56.590 --> 01:09:00.670 align:middle line:84% from protocols where the verifier's messages are 01:09:00.670 --> 01:09:03.920 align:middle line:84% completely random, OK, and that's 01:09:03.920 --> 01:09:06.990 align:middle line:84% why I want you to remember in your head that here, 01:09:06.990 --> 01:09:09.520 align:middle line:84% this message can be completely random. 01:09:09.520 --> 01:09:10.020 align:middle line:90% OK. 01:09:10.020 --> 01:09:12.868 align:middle line:84% We can make also this random, but we don't need to, 01:09:12.868 --> 01:09:14.160 align:middle line:90% because it's the first message. 01:09:14.160 --> 01:09:17.170 align:middle line:84% It's kind of-- the first message is 01:09:17.170 --> 01:09:20.240 align:middle line:84% kind of special in that it's kind of the first one, 01:09:20.240 --> 01:09:22.340 align:middle line:84% so we don't need to eliminate interaction from it. 01:09:22.340 --> 01:09:25.710 align:middle line:84% It's kind of the first one, so that's fine. 01:09:25.710 --> 01:09:30.160 align:middle line:84% All the later messages of the verifier will need to-- 01:09:30.160 --> 01:09:32.930 align:middle line:84% if they're really random, just random bits, 01:09:32.930 --> 01:09:35.470 align:middle line:84% then we can show how we can eliminate interaction, 01:09:35.470 --> 01:09:37.939 align:middle line:84% that we can actually get rid of the interaction. 01:09:37.939 --> 01:09:41.140 align:middle line:84% So I just want to point out, this message 01:09:41.140 --> 01:09:42.700 align:middle line:90% is completely random. 01:09:42.700 --> 01:09:44.630 align:middle line:90% These, i1 to il, are not random. 01:09:44.630 --> 01:09:45.800 align:middle line:90% They're actually correlated. 01:09:45.800 --> 01:09:47.630 align:middle line:84% But you can just send the randomness. 01:09:47.630 --> 01:09:48.375 align:middle line:90% Yes? 01:09:48.375 --> 01:09:50.000 align:middle line:84% AUDIENCE: I guess this wasn't assigned, 01:09:50.000 --> 01:09:51.820 align:middle line:84% but why is the first message special? 01:09:51.820 --> 01:09:54.189 align:middle line:84% Because you could imagine that, I don't know, 01:09:54.189 --> 01:09:56.320 align:middle line:84% there could exist some particular hash key which 01:09:56.320 --> 01:09:57.590 align:middle line:90% is really bad or something. 01:09:57.590 --> 01:10:01.480 align:middle line:84% So if you-- like, it feels like you should still be sampling 01:10:01.480 --> 01:10:02.648 align:middle line:90% the first hash [INAUDIBLE]. 01:10:02.648 --> 01:10:04.190 align:middle line:84% YAEL KALAI: Oh, you're definitely sampling it. 01:10:04.190 --> 01:10:04.690 align:middle line:90% No, no. 01:10:04.690 --> 01:10:06.770 align:middle line:84% You're going to sample this key, for sure. 01:10:06.770 --> 01:10:09.040 align:middle line:84% I'm just saying, the hash key itself 01:10:09.040 --> 01:10:10.720 align:middle line:90% is not necessarily random bits. 01:10:10.720 --> 01:10:11.990 align:middle line:90% It depends on the hash. 01:10:11.990 --> 01:10:14.510 align:middle line:90% Some hash keys are random. 01:10:14.510 --> 01:10:17.650 align:middle line:84% Some hash keys have some structure, 01:10:17.650 --> 01:10:20.280 align:middle line:84% depending on which hash function you use. 01:10:20.280 --> 01:10:23.450 align:middle line:84% So some hash keys, indeed, some hash keys are just random, 01:10:23.450 --> 01:10:26.020 align:middle line:84% and then this message is just random. 01:10:26.020 --> 01:10:28.580 align:middle line:90% Some hash keys are not random. 01:10:28.580 --> 01:10:31.120 align:middle line:84% I have an LWE structure, for those 01:10:31.120 --> 01:10:34.730 align:middle line:84% who know what LWE is, but have some special structure. 01:10:34.730 --> 01:10:36.130 align:middle line:90% So now I'm saying-- 01:10:36.130 --> 01:10:39.040 align:middle line:84% I guess what I was saying is if the message is 01:10:39.040 --> 01:10:42.980 align:middle line:84% from the verifier to the prover, we're truly random, 01:10:42.980 --> 01:10:45.290 align:middle line:84% we're going to see we can eliminate interaction. 01:10:45.290 --> 01:10:47.582 align:middle line:84% So I'm telling you, just notice it's completely random. 01:10:47.582 --> 01:10:48.998 align:middle line:84% And now you're going to say, wait, 01:10:48.998 --> 01:10:50.320 align:middle line:90% this is not necessarily random. 01:10:50.320 --> 01:10:52.112 align:middle line:84% I don't know how hash keys are distributed. 01:10:52.112 --> 01:10:53.540 align:middle line:90% Depends on the construction. 01:10:53.540 --> 01:10:54.915 align:middle line:84% Maybe it's not completely random. 01:10:54.915 --> 01:10:56.332 align:middle line:84% Then I tell you, don't worry, this 01:10:56.332 --> 01:10:58.790 align:middle line:84% doesn't have to be-- it can be an arbitrary distribution. 01:10:58.790 --> 01:11:01.105 align:middle line:84% AUDIENCE: But, I guess, since the n is already random, 01:11:01.105 --> 01:11:02.480 align:middle line:84% why can't you just send the bit-- 01:11:02.480 --> 01:11:03.140 align:middle line:84% the coins you used to [INAUDIBLE]. 01:11:03.140 --> 01:11:04.848 align:middle line:84% YAEL KALAI: Good, good, good, good, good. 01:11:04.848 --> 01:11:07.340 align:middle line:84% So you're saying, hey, send the coins here, too. 01:11:07.340 --> 01:11:08.250 align:middle line:90% Do the same. 01:11:08.250 --> 01:11:11.900 align:middle line:90% Put here r and send r. 01:11:11.900 --> 01:11:13.080 align:middle line:90% You can. 01:11:13.080 --> 01:11:16.040 align:middle line:84% However, not all hash functions-- there 01:11:16.040 --> 01:11:18.950 align:middle line:84% are many hash functions that are secure if you only 01:11:18.950 --> 01:11:21.642 align:middle line:84% give the hash key, but I'm not going 01:11:21.642 --> 01:11:23.850 align:middle line:84% to give the randomness used to generate the hash key. 01:11:23.850 --> 01:11:25.310 align:middle line:84% Maybe with this randomness, you can 01:11:25.310 --> 01:11:27.380 align:middle line:90% break the collision resistance. 01:11:27.380 --> 01:11:30.540 align:middle line:90% So some hash functions are OK. 01:11:30.540 --> 01:11:31.245 align:middle line:90% Some are not. 01:11:31.245 --> 01:11:33.620 align:middle line:84% Like, the hash function that we'll construct, you'll see, 01:11:33.620 --> 01:11:34.140 align:middle line:90% is fine. 01:11:34.140 --> 01:11:35.340 align:middle line:90% Actually, it's randomness. 01:11:35.340 --> 01:11:37.080 align:middle line:84% But that's under specific assumption. 01:11:37.080 --> 01:11:39.860 align:middle line:84% And some are not-- it's not OK to give the randomness. 01:11:39.860 --> 01:11:42.508 align:middle line:84% But I just want to point out that for later, 01:11:42.508 --> 01:11:45.050 align:middle line:84% to eliminate interaction, using what's called the Fiat-Shamir 01:11:45.050 --> 01:11:47.600 align:middle line:84% paradigm-- we'll talk about it next class-- 01:11:47.600 --> 01:11:49.820 align:middle line:84% the first message actually doesn't need to be random. 01:11:49.820 --> 01:11:52.470 align:middle line:84% It's only the later messages have to be random. 01:11:52.470 --> 01:11:56.610 align:middle line:84% So I just want to emphasize this is random. 01:11:56.610 --> 01:11:57.970 align:middle line:90% There were other questions? 01:11:57.970 --> 01:11:58.635 align:middle line:90% Yeah? 01:11:58.635 --> 01:11:59.260 align:middle line:90% AUDIENCE: Yeah. 01:11:59.260 --> 01:12:01.740 align:middle line:84% The PCP, the verifier, what is n? 01:12:01.740 --> 01:12:02.310 align:middle line:90% What is the-- 01:12:02.310 --> 01:12:03.977 align:middle line:84% YAEL KALAI: n, n is the size of x, yeah. 01:12:03.977 --> 01:12:10.325 align:middle line:84% So, sorry, I said, yeah, n, thank you, is the length of x. 01:12:10.325 --> 01:12:10.825 align:middle line:90% Thanks. 01:12:10.825 --> 01:12:13.840 align:middle line:90% 01:12:13.840 --> 01:12:15.340 align:middle line:84% So the PCP verifier needs to know 01:12:15.340 --> 01:12:17.440 align:middle line:84% the length of the instance he's working with 01:12:17.440 --> 01:12:19.300 align:middle line:90% to know which queries to ask. 01:12:19.300 --> 01:12:19.918 align:middle line:90% Yeah, Tina? 01:12:19.918 --> 01:12:21.960 align:middle line:84% AUDIENCE: Why is the [INAUDIBLE] for the instance 01:12:21.960 --> 01:12:24.317 align:middle line:84% given in binary but the security parameters 01:12:24.317 --> 01:12:25.650 align:middle line:90% given in generation [INAUDIBLE]? 01:12:25.650 --> 01:12:27.192 align:middle line:84% YAEL KALAI: OK, because-- yeah, good. 01:12:27.192 --> 01:12:32.500 align:middle line:84% So I just want to emphasize that to generate these queries, 01:12:32.500 --> 01:12:35.730 align:middle line:84% you don't need to run in time that's polynomial in n. 01:12:35.730 --> 01:12:38.220 align:middle line:84% It's enough to run in time polylog n in order 01:12:38.220 --> 01:12:39.220 align:middle line:90% to generate the queries. 01:12:39.220 --> 01:12:40.500 align:middle line:90% That's why I gave it an-- 01:12:40.500 --> 01:12:42.668 align:middle line:84% it doesn't matter so much, because here, anyway, 01:12:42.668 --> 01:12:43.960 align:middle line:90% you need to run in time linear. 01:12:43.960 --> 01:12:47.280 align:middle line:84% So you're like, why am I making this point? 01:12:47.280 --> 01:12:49.530 align:middle line:90% Yeah. 01:12:49.530 --> 01:12:51.688 align:middle line:84% It's not very important, even though sometimes it 01:12:51.688 --> 01:12:52.230 align:middle line:90% is important. 01:12:52.230 --> 01:12:54.360 align:middle line:84% When later you want to talk about proximity and stuff, then 01:12:54.360 --> 01:12:55.902 align:middle line:84% all of a sudden, it becomes an issue. 01:12:55.902 --> 01:12:57.720 align:middle line:84% So, yeah, just, this is just emphasized 01:12:57.720 --> 01:13:02.820 align:middle line:84% that the PCP verifier, at least when generating the queries, 01:13:02.820 --> 01:13:04.440 align:middle line:90% doesn't run in time linear in n. 01:13:04.440 --> 01:13:07.440 align:middle line:84% It runs in time, actually, linear in security parameter 01:13:07.440 --> 01:13:10.585 align:middle line:84% and polylog in n to generate the queries. 01:13:10.585 --> 01:13:14.120 align:middle line:90% 01:13:14.120 --> 01:13:14.620 align:middle line:90% OK. 01:13:14.620 --> 01:13:17.490 align:middle line:90% Questions? 01:13:17.490 --> 01:13:18.070 align:middle line:90% OK. 01:13:18.070 --> 01:13:22.680 align:middle line:84% So let's go ahead and prove the-- 01:13:22.680 --> 01:13:23.532 align:middle line:90% let me see. 01:13:23.532 --> 01:13:24.990 align:middle line:84% I changed the order, so I just want 01:13:24.990 --> 01:13:27.720 align:middle line:90% to make sure I'm not skipping. 01:13:27.720 --> 01:13:31.330 align:middle line:90% 01:13:31.330 --> 01:13:31.830 align:middle line:90% OK. 01:13:31.830 --> 01:13:32.330 align:middle line:90% Yeah. 01:13:32.330 --> 01:13:33.070 align:middle line:90% Let's do it. 01:13:33.070 --> 01:13:35.660 align:middle line:84% OK, soundness, let's analyze this. 01:13:35.660 --> 01:13:37.660 align:middle line:84% So I want to prove that it's complete and sound, 01:13:37.660 --> 01:13:38.760 align:middle line:90% this protocol. 01:13:38.760 --> 01:13:41.260 align:middle line:84% Yeah, so if it's an NP language, your favorite one, 01:13:41.260 --> 01:13:46.980 align:middle line:84% let's say 3-SAT, and I want to argue that if the prover is 01:13:46.980 --> 01:13:49.050 align:middle line:84% honest, he indeed has a satisfying assignment 01:13:49.050 --> 01:13:53.280 align:middle line:84% or a witness, the verifier will accept him with probability 1. 01:13:53.280 --> 01:13:55.780 align:middle line:84% And if he's honest, he does everything like he should, 01:13:55.780 --> 01:13:59.490 align:middle line:84% and the soundness, if he tries to cheat 01:13:59.490 --> 01:14:01.800 align:middle line:84% and gives me an x not in the language, 01:14:01.800 --> 01:14:03.690 align:middle line:90% we're going to catch him. 01:14:03.690 --> 01:14:07.110 align:middle line:84% He's going to be accepted with probability negligible. 01:14:07.110 --> 01:14:07.610 align:middle line:90% OK. 01:14:07.610 --> 01:14:08.402 align:middle line:90% So that's the goal. 01:14:08.402 --> 01:14:12.310 align:middle line:90% 01:14:12.310 --> 01:14:15.460 align:middle line:90% Any questions before we-- 01:14:15.460 --> 01:14:15.960 align:middle line:90% no? 01:14:15.960 --> 01:14:16.460 align:middle line:90% OK. 01:14:16.460 --> 01:14:17.290 align:middle line:90% So let's do it. 01:14:17.290 --> 01:14:19.440 align:middle line:84% So, OK, let's start with completeness, 01:14:19.440 --> 01:14:20.830 align:middle line:90% because that's really easy. 01:14:20.830 --> 01:14:22.500 align:middle line:84% The focus-- well, I can just say, 01:14:22.500 --> 01:14:25.050 align:middle line:84% completeness is not worth writing, 01:14:25.050 --> 01:14:26.100 align:middle line:90% because it's so trivial. 01:14:26.100 --> 01:14:26.860 align:middle line:90% So what do I want? 01:14:26.860 --> 01:14:27.985 align:middle line:90% What does completeness say? 01:14:27.985 --> 01:14:30.150 align:middle line:84% Completeness says, if the prover chooses 01:14:30.150 --> 01:14:33.520 align:middle line:84% x that's in the language, and he has a witness, 01:14:33.520 --> 01:14:35.685 align:middle line:84% he's going to be accepted with probability 1. 01:14:35.685 --> 01:14:36.185 align:middle line:90% Why? 01:14:36.185 --> 01:14:37.640 align:middle line:90% Why is he going to be accepted? 01:14:37.640 --> 01:14:38.900 align:middle line:90% Well, let's see what he does. 01:14:38.900 --> 01:14:40.720 align:middle line:90% He chooses a PCP. 01:14:40.720 --> 01:14:42.945 align:middle line:84% The PCP, let's say, has completeness 1. 01:14:42.945 --> 01:14:43.820 align:middle line:90% That's my assumption. 01:14:43.820 --> 01:14:49.000 align:middle line:84% It's soundness negligible and completeness 1. 01:14:49.000 --> 01:14:49.500 align:middle line:90% OK. 01:14:49.500 --> 01:14:50.625 align:middle line:90% I assume that about my PCP. 01:14:50.625 --> 01:14:52.792 align:middle line:84% Otherwise, the completeness is like the completeness 01:14:52.792 --> 01:14:53.730 align:middle line:90% of the PCP. 01:14:53.730 --> 01:14:57.600 align:middle line:90% So he chooses the PCP. 01:14:57.600 --> 01:14:59.250 align:middle line:90% He hashes it. 01:14:59.250 --> 01:15:03.810 align:middle line:84% Now he gets PCP queries from the verifier. 01:15:03.810 --> 01:15:06.240 align:middle line:90% He opens the PCP. 01:15:06.240 --> 01:15:10.530 align:middle line:84% Now, these are acceptable with probability 1. 01:15:10.530 --> 01:15:12.750 align:middle line:90% Now he generates also Open. 01:15:12.750 --> 01:15:14.303 align:middle line:90% These rhos are from Open. 01:15:14.303 --> 01:15:15.720 align:middle line:84% Right, so maybe I should write it. 01:15:15.720 --> 01:15:16.470 align:middle line:90% I didn't write it. 01:15:16.470 --> 01:15:24.960 align:middle line:84% But rho ij is by computing Open and hash key pi ij. 01:15:24.960 --> 01:15:28.920 align:middle line:90% That's the-- yeah. 01:15:28.920 --> 01:15:31.290 align:middle line:90% That's how he generates rho ij. 01:15:31.290 --> 01:15:32.370 align:middle line:90% And what do we know? 01:15:32.370 --> 01:15:36.690 align:middle line:84% We know, by completeness here, or correctness, he's 01:15:36.690 --> 01:15:39.110 align:middle line:90% accepted with probability 1. 01:15:39.110 --> 01:15:45.510 align:middle line:84% So the probability that both the PCP is accepted, 01:15:45.510 --> 01:15:49.640 align:middle line:84% the PCP verifier accepts, and the hash verifier accepts, 01:15:49.640 --> 01:15:51.750 align:middle line:90% is 1 because both of them is 1. 01:15:51.750 --> 01:15:53.970 align:middle line:84% I took perfect completeness for both of them, 01:15:53.970 --> 01:15:57.680 align:middle line:90% so that's all we do. 01:15:57.680 --> 01:15:59.800 align:middle line:90% So this is just pretty trivial. 01:15:59.800 --> 01:16:02.170 align:middle line:90% 01:16:02.170 --> 01:16:02.670 align:middle line:90% Yeah? 01:16:02.670 --> 01:16:03.610 align:middle line:90% Questions? 01:16:03.610 --> 01:16:07.523 align:middle line:90% 01:16:07.523 --> 01:16:09.190 align:middle line:84% Are you guys OK moving to the soundness? 01:16:09.190 --> 01:16:10.690 align:middle line:84% That's kind of the interesting part. 01:16:10.690 --> 01:16:11.330 align:middle line:90% OK. 01:16:11.330 --> 01:16:13.050 align:middle line:90% So how about soundness? 01:16:13.050 --> 01:16:21.180 align:middle line:90% 01:16:21.180 --> 01:16:22.560 align:middle line:90% OK, so what's the idea? 01:16:22.560 --> 01:16:25.030 align:middle line:84% The idea for soundness is the following. 01:16:25.030 --> 01:16:29.910 align:middle line:84% I want to say, so suppose there exists a cheating prover that 01:16:29.910 --> 01:16:34.420 align:middle line:84% chooses x not in the language, OK, and manages to cheat. 01:16:34.420 --> 01:16:36.690 align:middle line:84% So let's suppose and let's try to break the collision 01:16:36.690 --> 01:16:37.870 align:middle line:90% resistance. 01:16:37.870 --> 01:16:38.370 align:middle line:90% OK. 01:16:38.370 --> 01:16:49.959 align:middle line:84% So suppose there exists t time whatever-- 01:16:49.959 --> 01:17:00.960 align:middle line:84% so, OK, we assume this is with T soundness, or security, and CR, 01:17:00.960 --> 01:17:04.090 align:middle line:90% collision resistance. 01:17:04.090 --> 01:17:05.240 align:middle line:90% That's my assumption. 01:17:05.240 --> 01:17:07.300 align:middle line:84% Now, I want to argue, if I assume that 01:17:07.300 --> 01:17:11.810 align:middle line:84% the collision-resistant is T secure-- 01:17:11.810 --> 01:17:15.380 align:middle line:84% namely, even someone in time poly T cannot cheat-- 01:17:15.380 --> 01:17:19.790 align:middle line:84% then I want to argue, suppose there exists a-- 01:17:19.790 --> 01:17:20.560 align:middle line:90% oh. 01:17:20.560 --> 01:17:22.590 align:middle line:90% Sorry. 01:17:22.590 --> 01:17:24.570 align:middle line:90% We're going to-- OK. 01:17:24.570 --> 01:17:26.850 align:middle line:84% We're going to get back to this, OK, 01:17:26.850 --> 01:17:29.730 align:middle line:84% what exactly this is, and we'll see that it actually 01:17:29.730 --> 01:17:30.850 align:middle line:90% needs to be quite big. 01:17:30.850 --> 01:17:31.890 align:middle line:90% But we'll see that. 01:17:31.890 --> 01:17:40.730 align:middle line:84% Suppose there exists a poly-T cheating prover P star, 01:17:40.730 --> 01:17:45.800 align:middle line:90% that cheats, namely that-- 01:17:45.800 --> 01:17:50.900 align:middle line:84% and there exists, like, for every lambda-- 01:17:50.900 --> 01:18:01.360 align:middle line:84% or there exists a bunch of x lambda not in the language. 01:18:01.360 --> 01:18:13.550 align:middle line:84% And there exists a non-negligible epsilon such 01:18:13.550 --> 01:18:16.610 align:middle line:84% that the prover succeeds with that probability. 01:18:16.610 --> 01:18:22.350 align:middle line:84% The probability that P star talking to verifier on input x, 01:18:22.350 --> 01:18:27.380 align:middle line:84% the verifier accepts him, is at least epsilon, 01:18:27.380 --> 01:18:28.660 align:middle line:90% such that for every lambda-- 01:18:28.660 --> 01:18:34.490 align:middle line:90% 01:18:34.490 --> 01:18:38.300 align:middle line:84% to be precise, this is x of lambda. 01:18:38.300 --> 01:18:40.850 align:middle line:90% And they get lambda. 01:18:40.850 --> 01:18:44.150 align:middle line:84% OK, so suppose a cheating prover, for any lambda, 01:18:44.150 --> 01:18:49.540 align:middle line:84% he chooses some x of lambda and P star, 01:18:49.540 --> 01:18:54.530 align:middle line:84% and V accepts him, even though x lambda is not in the language. 01:18:54.530 --> 01:18:55.890 align:middle line:90% OK. 01:18:55.890 --> 01:19:01.230 align:middle line:84% One, my only assumption is that x lambda is smaller than 2 01:19:01.230 --> 01:19:01.990 align:middle line:90% to the lambda. 01:19:01.990 --> 01:19:04.120 align:middle line:84% So I choose my security parameter 01:19:04.120 --> 01:19:05.670 align:middle line:84% so that the [INAUDIBLE] number is 01:19:05.670 --> 01:19:11.190 align:middle line:90% bigger than log the size of x. 01:19:11.190 --> 01:19:13.345 align:middle line:90% OK. 01:19:13.345 --> 01:19:18.160 align:middle line:84% Then-- actually, it's not even needed for soundness. 01:19:18.160 --> 01:19:20.690 align:middle line:84% This actually was needed for completeness, 01:19:20.690 --> 01:19:26.280 align:middle line:84% because we only had completeness for these x's. 01:19:26.280 --> 01:19:28.620 align:middle line:84% For soundness, actually, it doesn't really matter. 01:19:28.620 --> 01:19:29.230 align:middle line:90% OK. 01:19:29.230 --> 01:19:30.160 align:middle line:90% So let's see. 01:19:30.160 --> 01:19:31.390 align:middle line:90% What do I want to do? 01:19:31.390 --> 01:19:33.682 align:middle line:84% I'm saying suppose there's-- because this is a cheating 01:19:33.682 --> 01:19:37.145 align:middle line:84% prover, and this cheating prover convinces. 01:19:37.145 --> 01:19:37.645 align:middle line:90% OK. 01:19:37.645 --> 01:19:40.190 align:middle line:84% Now, let's see, what did this cheating prover do? 01:19:40.190 --> 01:19:42.280 align:middle line:90% He committed to a P kind of-- 01:19:42.280 --> 01:19:43.690 align:middle line:90% he hashed a PCP. 01:19:43.690 --> 01:19:45.260 align:middle line:90% Now, I don't know what he did. 01:19:45.260 --> 01:19:45.950 align:middle line:90% He's a cheater. 01:19:45.950 --> 01:19:51.480 align:middle line:84% But he gave me a hash of something, should be a PCP. 01:19:51.480 --> 01:19:54.860 align:middle line:90% And then he opens this PCP. 01:19:54.860 --> 01:19:57.380 align:middle line:90% So what do I want to do? 01:19:57.380 --> 01:19:59.430 align:middle line:90% I'm going to-- 01:19:59.430 --> 01:20:01.160 align:middle line:84% I want to argue I can find a collision. 01:20:01.160 --> 01:20:02.562 align:middle line:90% Why can I find a collision? 01:20:02.562 --> 01:20:03.270 align:middle line:90% What is the idea? 01:20:03.270 --> 01:20:05.330 align:middle line:90% The idea is the following. 01:20:05.330 --> 01:20:08.660 align:middle line:84% I'm going to run this cheating prover. 01:20:08.660 --> 01:20:11.190 align:middle line:84% I'm going to ask the cheating prover, OK, here's a hash key, 01:20:11.190 --> 01:20:18.380 align:middle line:84% give me a v. Then I'm going to run him many, 01:20:18.380 --> 01:20:20.600 align:middle line:84% many, many times on many PCP verifiers. 01:20:20.600 --> 01:20:22.600 align:middle line:84% I'm going to tell him, OK, you know what, here's 01:20:22.600 --> 01:20:24.530 align:middle line:90% i1 to il from the PCP verifier. 01:20:24.530 --> 01:20:26.210 align:middle line:90% Give me openings. 01:20:26.210 --> 01:20:27.940 align:middle line:90% Again, here's i1 up to il. 01:20:27.940 --> 01:20:28.880 align:middle line:90% Give me openings. 01:20:28.880 --> 01:20:29.800 align:middle line:90% Again, give him the-- 01:20:29.800 --> 01:20:31.810 align:middle line:84% I'm going to kind of rewind him and try 01:20:31.810 --> 01:20:36.142 align:middle line:84% to give him tons of kind of messages, i1 up to il. 01:20:36.142 --> 01:20:37.600 align:middle line:84% So I'm going to kind of rewind him. 01:20:37.600 --> 01:20:38.100 align:middle line:90% OK. 01:20:38.100 --> 01:20:39.540 align:middle line:90% So again, what do I want to do? 01:20:39.540 --> 01:20:42.250 align:middle line:90% 01:20:42.250 --> 01:20:44.307 align:middle line:84% Given a hash key, OK, given a hash key, 01:20:44.307 --> 01:20:46.140 align:middle line:84% I want to find collisions for this hash key. 01:20:46.140 --> 01:20:49.010 align:middle line:84% How do I find collisions for this hash key? 01:20:49.010 --> 01:20:51.350 align:middle line:84% I'm going to give this prover the hash key. 01:20:51.350 --> 01:20:53.570 align:middle line:90% He gives me a value v. 01:20:53.570 --> 01:20:56.680 align:middle line:84% Then I'm going to tell the prover, 01:20:56.680 --> 01:20:59.290 align:middle line:90% I'm going to choose a random r. 01:20:59.290 --> 01:21:01.970 align:middle line:84% I'm going to tell him, open these locations. 01:21:01.970 --> 01:21:03.670 align:middle line:90% He opens. 01:21:03.670 --> 01:21:04.210 align:middle line:90% Good. 01:21:04.210 --> 01:21:05.335 align:middle line:90% Now I'm saying, OK, OK, OK. 01:21:05.335 --> 01:21:06.620 align:middle line:90% Actually, let's rewind him. 01:21:06.620 --> 01:21:08.420 align:middle line:90% Forget that I sent him these. 01:21:08.420 --> 01:21:11.106 align:middle line:84% Let me give him r2, different r's-- 01:21:11.106 --> 01:21:12.180 align:middle line:90% Open. 01:21:12.180 --> 01:21:13.290 align:middle line:90% OK. 01:21:13.290 --> 01:21:15.150 align:middle line:90% Forget-- r3-- 01:21:15.150 --> 01:21:18.750 align:middle line:84% I'm going to run this step tons of times-- 01:21:18.750 --> 01:21:22.550 align:middle line:84% r1, r2, r3, r4, ba-ba, ba-ba, a lot of them. 01:21:22.550 --> 01:21:26.492 align:middle line:84% And I'm going to have a lot of openings from him. 01:21:26.492 --> 01:21:28.200 align:middle line:84% I'm going to run it so much that I'm just 01:21:28.200 --> 01:21:29.510 align:middle line:90% going to have tons of opening. 01:21:29.510 --> 01:21:32.970 align:middle line:84% Like, I'm going to run in more than, like, poly 1 over epsilon 01:21:32.970 --> 01:21:36.250 align:middle line:84% and more than poly 1 over epsilon in n. 01:21:36.250 --> 01:21:39.330 align:middle line:84% So the point is I'm going to run it much more 01:21:39.330 --> 01:21:43.540 align:middle line:84% than-- like, the size of the PCP times 01:21:43.540 --> 01:21:47.252 align:middle line:84% 1 over epsilon, because it's some power to some-- 01:21:47.252 --> 01:21:49.172 align:middle line:90% to the third, whatever. 01:21:49.172 --> 01:21:50.380 align:middle line:90% that will take a lot of time. 01:21:50.380 --> 01:21:51.940 align:middle line:90% Now, what's the idea? 01:21:51.940 --> 01:21:53.420 align:middle line:90% The idea is the following. 01:21:53.420 --> 01:21:57.370 align:middle line:90% 01:21:57.370 --> 01:21:59.662 align:middle line:84% If there are no collisions, so if there-- look, 01:21:59.662 --> 01:22:00.370 align:middle line:90% I'm going to run. 01:22:00.370 --> 01:22:02.740 align:middle line:84% Now, if at any point, every time that he 01:22:02.740 --> 01:22:05.590 align:middle line:84% gave me an opening that didn't work-- 01:22:05.590 --> 01:22:06.705 align:middle line:90% it's 0, it didn't work-- 01:22:06.705 --> 01:22:08.080 align:middle line:84% OK, so I'm going to throw it out. 01:22:08.080 --> 01:22:10.640 align:middle line:84% OK, look, there's-- he only succeeds in probability epsilon. 01:22:10.640 --> 01:22:12.850 align:middle line:84% So all the times that he didn't succeed-- 01:22:12.850 --> 01:22:14.870 align:middle line:90% OK, well, failure. 01:22:14.870 --> 01:22:17.800 align:middle line:84% But 1 over epsilon's the time he succeeded. 01:22:17.800 --> 01:22:20.400 align:middle line:84% And in all these times, in all these 1 over epsilon-- 01:22:20.400 --> 01:22:22.580 align:middle line:84% sorry, epsilon is the time he succeeded. 01:22:22.580 --> 01:22:27.690 align:middle line:84% In all these epsilon times, I got a lot of good openings. 01:22:27.690 --> 01:22:30.610 align:middle line:84% Now let's look at all these openings that I got. 01:22:30.610 --> 01:22:35.200 align:middle line:84% If somewhere there's a collision, I found him. 01:22:35.200 --> 01:22:39.970 align:middle line:84% I found a collision, so I'm happy. 01:22:39.970 --> 01:22:43.030 align:middle line:84% If nowhere there's a collision, then essentially I 01:22:43.030 --> 01:22:44.440 align:middle line:90% found a PCP from him. 01:22:44.440 --> 01:22:47.540 align:middle line:84% I completely constructed, like, maybe not the entire PCP, 01:22:47.540 --> 01:22:48.530 align:middle line:90% but a lot of it. 01:22:48.530 --> 01:22:50.160 align:middle line:84% And the rest, I'm going to put zeros. 01:22:50.160 --> 01:22:52.410 align:middle line:84% I say, you know what, OK, these are identically zeros. 01:22:52.410 --> 01:22:55.340 align:middle line:84% But the argument is that if there were no collision, 01:22:55.340 --> 01:22:58.960 align:middle line:84% I get a PCP that's accepted with probability at least 01:22:58.960 --> 01:23:03.060 align:middle line:84% poly in epsilon, which is non-negligible. 01:23:03.060 --> 01:23:05.400 align:middle line:84% So that's the high-level idea, but let 01:23:05.400 --> 01:23:08.730 align:middle line:84% me say everything I said now, slowly. 01:23:08.730 --> 01:23:09.370 align:middle line:90% OK. 01:23:09.370 --> 01:23:15.740 align:middle line:84% So suppose I have a cheating prover that 01:23:15.740 --> 01:23:19.130 align:middle line:84% succeeds in convincing for x not in the language. 01:23:19.130 --> 01:23:20.375 align:middle line:90% I'm going to construct-- 01:23:20.375 --> 01:23:22.500 align:middle line:84% I'm going to find a collision to the hash function. 01:23:22.500 --> 01:23:30.880 align:middle line:84% So we're going to construct adversary A that 01:23:30.880 --> 01:23:41.280 align:middle line:84% breaks the collision resistance property. 01:23:41.280 --> 01:23:43.660 align:middle line:84% OK, how do I break the collision resistance property? 01:23:43.660 --> 01:23:45.060 align:middle line:90% Here's the idea. 01:23:45.060 --> 01:23:54.340 align:middle line:84% So, A, OK, so given, so he's given a random hash key, 01:23:54.340 --> 01:23:57.460 align:middle line:84% and his goal is to find collisions. 01:23:57.460 --> 01:23:59.090 align:middle line:90% How does he find collisions? 01:23:59.090 --> 01:24:00.310 align:middle line:90% What does he do? 01:24:00.310 --> 01:24:02.890 align:middle line:84% He gives-- so here's what A does. 01:24:02.890 --> 01:24:13.930 align:middle line:84% First compute v, which is P star and hash key. 01:24:13.930 --> 01:24:15.160 align:middle line:90% That's the first thing. 01:24:15.160 --> 01:24:20.690 align:middle line:84% I've got a v. Then I do the following, many times. 01:24:20.690 --> 01:24:31.310 align:middle line:84% So for i goes from 1 up to poly in n and 1 over epsilon-- 01:24:31.310 --> 01:24:43.560 align:middle line:84% so, many times-- what I do is I run, like, What P star, 01:24:43.560 --> 01:24:44.735 align:middle line:90% given hk-- 01:24:44.735 --> 01:24:46.550 align:middle line:90% and he gave v-- 01:24:46.550 --> 01:24:53.710 align:middle line:84% would run on input ri, ri corresponding to-- 01:24:53.710 --> 01:24:57.030 align:middle line:90% OK, let me call this j-- 01:24:57.030 --> 01:25:06.640 align:middle line:84% j corresponding to kind of i1 up to il. 01:25:06.640 --> 01:25:10.860 align:middle line:84% I just didn't want confuse this i with these i's. 01:25:10.860 --> 01:25:12.940 align:middle line:84% OK, so I'm going to run many times. 01:25:12.940 --> 01:25:15.045 align:middle line:90% I'm going to choose many r's. 01:25:15.045 --> 01:25:16.230 align:middle line:90% Oh, I didn't say-- 01:25:16.230 --> 01:25:18.210 align:middle line:90% sorry. 01:25:18.210 --> 01:25:24.940 align:middle line:84% Sorry, for i goes to 1, choose a random rj. 01:25:24.940 --> 01:25:30.580 align:middle line:84% So for j, go from 1, 2, up to poly in n and 1 over epsilon. 01:25:30.580 --> 01:25:31.955 align:middle line:90% I choose a random rj. 01:25:31.955 --> 01:25:35.970 align:middle line:90% 01:25:35.970 --> 01:25:37.770 align:middle line:90% How much random bits? 01:25:37.770 --> 01:25:42.180 align:middle line:84% Like the PCP verifier, I'm going to behave like the-- 01:25:42.180 --> 01:25:45.600 align:middle line:84% I'm going to give him the randomness of the PCP verifier 01:25:45.600 --> 01:25:49.180 align:middle line:84% corresponding to i1 up to il, and I'm 01:25:49.180 --> 01:25:51.070 align:middle line:84% going to compute the his answers, which 01:25:51.070 --> 01:25:53.750 align:middle line:90% is pi i1 up to pi. 01:25:53.750 --> 01:25:55.060 align:middle line:90% These may be malicious answers. 01:25:55.060 --> 01:25:56.810 align:middle line:84% I denoted by pi, but of course, it can-- 01:25:56.810 --> 01:25:59.185 align:middle line:84% I mean, it's not necessarily corresponding to a nice PCP. 01:25:59.185 --> 01:26:00.420 align:middle line:90% He's malicious and opening. 01:26:00.420 --> 01:26:04.584 align:middle line:90% 01:26:04.584 --> 01:26:07.280 align:middle line:84% OK, so this is how I find collisions. 01:26:07.280 --> 01:26:10.450 align:middle line:90% I get a hash key. 01:26:10.450 --> 01:26:13.820 align:middle line:84% I give it to the cheating prover to get a value. 01:26:13.820 --> 01:26:22.100 align:middle line:84% Then for m times, for j goes from 1 to m-- 01:26:22.100 --> 01:26:25.660 align:middle line:84% m is going to be poly in n and 1 over epsilon-- 01:26:25.660 --> 01:26:26.710 align:middle line:90% what do I do? 01:26:26.710 --> 01:26:30.220 align:middle line:84% I choose randomness for the PCP verifier, 01:26:30.220 --> 01:26:32.380 align:middle line:84% and I tell the prover, What are your answers 01:26:32.380 --> 01:26:34.820 align:middle line:84% for this randomness, with the same v? 01:26:34.820 --> 01:26:37.295 align:middle line:90% I didn't change the v. OK. 01:26:37.295 --> 01:26:40.730 align:middle line:84% So he gave me a v in the second message, 01:26:40.730 --> 01:26:44.910 align:middle line:84% and then I kind of run the third message with him many, many, 01:26:44.910 --> 01:26:51.427 align:middle line:84% many times, n times, and expect to see answers. 01:26:51.427 --> 01:26:51.927 align:middle line:90% OK. 01:26:51.927 --> 01:26:54.500 align:middle line:90% Now what do I do? 01:26:54.500 --> 01:26:59.420 align:middle line:84% Those for which the rho doesn't work, those for which 01:26:59.420 --> 01:27:01.770 align:middle line:84% rho doesn't accept, it has a bad-- 01:27:01.770 --> 01:27:05.563 align:middle line:84% the Verify doesn't-- this doesn't accept, I throw out, 01:27:05.563 --> 01:27:06.480 align:middle line:90% then it's meaningless. 01:27:06.480 --> 01:27:07.772 align:middle line:90% He could put whatever he wants. 01:27:07.772 --> 01:27:09.300 align:middle line:90% I throw it out. 01:27:09.300 --> 01:27:11.350 align:middle line:84% But that's only epsilon fraction of them, 01:27:11.350 --> 01:27:13.200 align:middle line:84% because it turns out the prover, I 01:27:13.200 --> 01:27:15.960 align:middle line:84% assume the prover is accepted with probability epsilon. 01:27:15.960 --> 01:27:17.405 align:middle line:90% So epsilon, I throw out. 01:27:17.405 --> 01:27:20.430 align:middle line:84% OK, but I chose much more than 1 over-- 01:27:20.430 --> 01:27:22.420 align:middle line:90% OK, this only affects-- 01:27:22.420 --> 01:27:22.920 align:middle line:90% you know. 01:27:22.920 --> 01:27:26.730 align:middle line:84% So except for these epsilon, the rest are good. 01:27:26.730 --> 01:27:27.360 align:middle line:90% Yeah? 01:27:27.360 --> 01:27:27.665 align:middle line:90% Sorry. 01:27:27.665 --> 01:27:28.560 align:middle line:84% AUDIENCE: [INAUDIBLE] threw out 1 minus epsilon. 01:27:28.560 --> 01:27:29.100 align:middle line:90% YAEL KALAI: I throw out-- 01:27:29.100 --> 01:27:29.640 align:middle line:90% AUDIENCE: [INAUDIBLE]. 01:27:29.640 --> 01:27:31.765 align:middle line:84% YAEL KALAI: As I said that, I-- yeah, I throw out-- 01:27:31.765 --> 01:27:33.000 align:middle line:90% I'm left with epsilon. 01:27:33.000 --> 01:27:34.870 align:middle line:90% OK, I throw out 1 minus epsilon. 01:27:34.870 --> 01:27:36.330 align:middle line:90% I'm left with epsilon. 01:27:36.330 --> 01:27:39.150 align:middle line:84% But epsilon is good enough, because I chose more than poly 1 01:27:39.150 --> 01:27:39.857 align:middle line:90% over epsilon. 01:27:39.857 --> 01:27:41.440 align:middle line:84% That's why I have here 1 over epsilon, 01:27:41.440 --> 01:27:43.840 align:middle line:84% because epsilon are bad, which is why. 01:27:43.840 --> 01:27:46.450 align:middle line:90% OK, so I still have a lot left. 01:27:46.450 --> 01:27:49.890 align:middle line:84% OK, so now what do I do with the ones I have left? 01:27:49.890 --> 01:27:52.530 align:middle line:90% So I want to argue-- 01:27:52.530 --> 01:27:54.120 align:middle line:90% so here's the claim. 01:27:54.120 --> 01:27:55.693 align:middle line:90% The claim is that-- 01:27:55.693 --> 01:28:00.750 align:middle line:90% 01:28:00.750 --> 01:28:01.720 align:middle line:90% let me write it here. 01:28:01.720 --> 01:28:05.470 align:middle line:84% So the claim is that I should be able to find collisions. 01:28:05.470 --> 01:28:07.740 align:middle line:84% So the algorithm, the algorithm A, 01:28:07.740 --> 01:28:09.180 align:middle line:84% what it does, the way it breaks-- 01:28:09.180 --> 01:28:19.450 align:middle line:84% and so find output, a collision, if one exists-- 01:28:19.450 --> 01:28:20.270 align:middle line:90% I'll write it here. 01:28:20.270 --> 01:28:31.680 align:middle line:84% Why am I-- output, so 3, output collision if one exists. 01:28:31.680 --> 01:28:35.170 align:middle line:90% 01:28:35.170 --> 01:28:36.180 align:middle line:90% That's it. 01:28:36.180 --> 01:28:38.720 align:middle line:84% So what do I mean, if one exists? 01:28:38.720 --> 01:28:40.960 align:middle line:90% Many of the i's here-- 01:28:40.960 --> 01:28:47.145 align:middle line:84% I asked many times, right, because I did poly in n-- 01:28:47.145 --> 01:28:50.070 align:middle line:84% n meaning kind of the witness length, yeah, more than-- 01:28:50.070 --> 01:28:53.760 align:middle line:84% think of the witness length to the power of 1/3 divided 01:28:53.760 --> 01:28:56.040 align:middle line:90% by epsilon. 01:28:56.040 --> 01:28:58.545 align:middle line:84% The size of the PCP divided by epsilon 01:28:58.545 --> 01:29:00.670 align:middle line:84% to the third, that's how you should think about it, 01:29:00.670 --> 01:29:03.120 align:middle line:84% or times, like, security parameter. 01:29:03.120 --> 01:29:04.740 align:middle line:90% OK, so now what's the point? 01:29:04.740 --> 01:29:10.260 align:middle line:84% The point is I saw the same i many, many times because I 01:29:10.260 --> 01:29:12.570 align:middle line:90% asked many, many queries. 01:29:12.570 --> 01:29:15.990 align:middle line:90% Now, I want to argue that if-- 01:29:15.990 --> 01:29:16.960 align:middle line:90% so there's two options. 01:29:16.960 --> 01:29:20.600 align:middle line:84% Either every time I ask for an i, 01:29:20.600 --> 01:29:24.940 align:middle line:84% if he gave me a valid opening, it's for the same one, 01:29:24.940 --> 01:29:27.860 align:middle line:84% or one of the i's, he gave me valid openings, 01:29:27.860 --> 01:29:29.500 align:middle line:90% one for 0 and one for 1. 01:29:29.500 --> 01:29:31.360 align:middle line:90% If that's the case, I won. 01:29:31.360 --> 01:29:33.730 align:middle line:90% I found a collision. 01:29:33.730 --> 01:29:35.870 align:middle line:84% And then I broke the hash function. 01:29:35.870 --> 01:29:38.270 align:middle line:84% So if you believe you cannot break a hash function, 01:29:38.270 --> 01:29:39.293 align:middle line:90% then you cannot break. 01:29:39.293 --> 01:29:40.960 align:middle line:84% Then the scheme is secure, which is kind 01:29:40.960 --> 01:29:43.698 align:middle line:90% of what we're trying to do. 01:29:43.698 --> 01:29:45.990 align:middle line:84% But now you can say, but maybe you didn't find a hash-- 01:29:45.990 --> 01:29:47.510 align:middle line:84% maybe you didn't find a collision. 01:29:47.510 --> 01:29:52.320 align:middle line:84% Maybe the cheating prover, whenever 01:29:52.320 --> 01:29:55.930 align:middle line:84% he answers, when he answers correctly, 01:29:55.930 --> 01:29:57.720 align:middle line:90% it's always with the same-- 01:29:57.720 --> 01:30:00.180 align:middle line:84% like, for every i, if he answers correctly, it's 01:30:00.180 --> 01:30:03.220 align:middle line:90% with the same pi i. 01:30:03.220 --> 01:30:08.460 align:middle line:84% He never answers correctly with pi i being 0 or pi i being 1. 01:30:08.460 --> 01:30:10.630 align:middle line:90% Then what happened? 01:30:10.630 --> 01:30:13.570 align:middle line:84% I take all the things that he asked me, 01:30:13.570 --> 01:30:16.320 align:middle line:84% and I pieced together a PCP from him. 01:30:16.320 --> 01:30:17.730 align:middle line:90% OK, so why? 01:30:17.730 --> 01:30:20.580 align:middle line:90% I say-- OK, so the question is-- 01:30:20.580 --> 01:30:24.360 align:middle line:84% suppose I output-- suppose that a collision happens 01:30:24.360 --> 01:30:25.690 align:middle line:90% with negligible probability. 01:30:25.690 --> 01:30:27.270 align:middle line:90% If it's non-negligible, I won. 01:30:27.270 --> 01:30:28.420 align:middle line:90% I'm done. 01:30:28.420 --> 01:30:28.920 align:middle line:90% OK. 01:30:28.920 --> 01:30:32.640 align:middle line:84% I want to argue that now, if not, if a collision-- 01:30:32.640 --> 01:30:42.710 align:middle line:90% so if a collision occurs-- 01:30:42.710 --> 01:30:49.820 align:middle line:90% 01:30:49.820 --> 01:30:50.780 align:middle line:90% AUDIENCE: Two Cs. 01:30:50.780 --> 01:31:00.500 align:middle line:84% YAEL KALAI: Thank you-- with negligible probability, then 01:31:00.500 --> 01:31:03.260 align:middle line:84% I want to argue I can come up with a PCP, 01:31:03.260 --> 01:31:09.740 align:middle line:84% then there exists a pi that I can construct 01:31:09.740 --> 01:31:17.720 align:middle line:84% from this adversary such that V PCP of pi 01:31:17.720 --> 01:31:22.930 align:middle line:84% accepts with non-negligible probability. 01:31:22.930 --> 01:31:26.190 align:middle line:90% 01:31:26.190 --> 01:31:28.380 align:middle line:84% And that's a contradiction, because I assumed 01:31:28.380 --> 01:31:31.050 align:middle line:90% that my pi is sound, with-- 01:31:31.050 --> 01:31:34.750 align:middle line:84% I mean, soundness holds with probability. 01:31:34.750 --> 01:31:38.390 align:middle line:84% You break soundness only with negligible probability. 01:31:38.390 --> 01:31:41.960 align:middle line:84% So I'm going to argue that if the probability of finding 01:31:41.960 --> 01:31:45.840 align:middle line:84% a collision is negligible, then, actually, I 01:31:45.840 --> 01:31:48.150 align:middle line:84% can come up with a PCP that's accepted 01:31:48.150 --> 01:31:49.750 align:middle line:90% with non-negligible probability. 01:31:49.750 --> 01:31:53.160 align:middle line:84% But x is not in the language, so that breaks my-- 01:31:53.160 --> 01:31:54.840 align:middle line:90% that can't happen. 01:31:54.840 --> 01:31:56.910 align:middle line:84% Because I know the PCP has soundness, 01:31:56.910 --> 01:31:59.110 align:middle line:84% negligible, so that can't happen. 01:31:59.110 --> 01:32:02.260 align:middle line:84% And therefore, I must have collisions 01:32:02.260 --> 01:32:05.780 align:middle line:84% with non-negligible probability, and hence broke the collision. 01:32:05.780 --> 01:32:11.720 align:middle line:84% So why is it the case that I can find a PCP that's accepted? 01:32:11.720 --> 01:32:13.670 align:middle line:90% Because what am I going to do? 01:32:13.670 --> 01:32:16.170 align:middle line:84% Remember-- let's think I never found collision. 01:32:16.170 --> 01:32:19.222 align:middle line:84% It's negligible, so for all practical purposes, it's never. 01:32:19.222 --> 01:32:20.930 align:middle line:84% OK, let's think of the fact that we never 01:32:20.930 --> 01:32:22.280 align:middle line:90% encountered a collision. 01:32:22.280 --> 01:32:23.730 align:middle line:90% So then what do we do? 01:32:23.730 --> 01:32:24.830 align:middle line:90% I take this PCP. 01:32:24.830 --> 01:32:26.370 align:middle line:90% I take this adversary. 01:32:26.370 --> 01:32:27.140 align:middle line:90% I run it. 01:32:27.140 --> 01:32:30.990 align:middle line:84% Oh, I start piecing up a PCP, and I say, oh, pi 1 here, 01:32:30.990 --> 01:32:32.190 align:middle line:90% good, pi i1. 01:32:32.190 --> 01:32:33.890 align:middle line:84% Every time I ask it again, I know 01:32:33.890 --> 01:32:37.150 align:middle line:84% it'll give me this answer, because there's no collisions. 01:32:37.150 --> 01:32:41.010 align:middle line:84% And I start slowly piecing together an entire PCP. 01:32:41.010 --> 01:32:43.810 align:middle line:90% 01:32:43.810 --> 01:32:47.230 align:middle line:84% Now, there may be some places of the PCP 01:32:47.230 --> 01:32:50.840 align:middle line:84% that he will never open correctly, never. 01:32:50.840 --> 01:32:52.920 align:middle line:84% He'll never give me a valid opening. 01:32:52.920 --> 01:32:54.098 align:middle line:90% So then I can't-- 01:32:54.098 --> 01:32:54.640 align:middle line:90% I don't know. 01:32:54.640 --> 01:32:55.250 align:middle line:90% I don't know. 01:32:55.250 --> 01:32:57.910 align:middle line:84% Moreover, there may be some places of the PCP 01:32:57.910 --> 01:33:01.040 align:middle line:84% that somehow this verifier never asked. 01:33:01.040 --> 01:33:02.420 align:middle line:90% That can also be. 01:33:02.420 --> 01:33:06.870 align:middle line:84% So I'm going to write-- all the places that actually opened, 01:33:06.870 --> 01:33:09.335 align:middle line:84% I'm going to write down whatever didn't open. 01:33:09.335 --> 01:33:10.710 align:middle line:84% Look, this adversary can always-- 01:33:10.710 --> 01:33:13.740 align:middle line:84% let's say it can always take 1-minus-epsilon fraction of this 01:33:13.740 --> 01:33:16.598 align:middle line:84% PCP and never open it, and the rest open correctly, 01:33:16.598 --> 01:33:18.640 align:middle line:84% because it's only a step of move for the epsilon. 01:33:18.640 --> 01:33:20.400 align:middle line:90% So there can be always-- 01:33:20.400 --> 01:33:22.050 align:middle line:84% not really 1 minus epsilon of the PCP 01:33:22.050 --> 01:33:23.467 align:middle line:84% because we asked too many queries, 01:33:23.467 --> 01:33:26.340 align:middle line:84% but there can, of course, be some parts of the PCP 01:33:26.340 --> 01:33:29.230 align:middle line:90% that he just never answers. 01:33:29.230 --> 01:33:31.450 align:middle line:84% And it's OK because of this epsilon. 01:33:31.450 --> 01:33:31.950 align:middle line:90% OK. 01:33:31.950 --> 01:33:33.930 align:middle line:90% So in that part, I'm going to-- 01:33:33.930 --> 01:33:37.890 align:middle line:84% wherever I don't want, I'm going to just put zeros. 01:33:37.890 --> 01:33:39.160 align:middle line:90% OK, but this is my PCP. 01:33:39.160 --> 01:33:41.750 align:middle line:90% 01:33:41.750 --> 01:33:43.250 align:middle line:90% And I said, now, this is fine. 01:33:43.250 --> 01:33:45.920 align:middle line:90% I'm going to call this pi. 01:33:45.920 --> 01:33:48.650 align:middle line:84% Now you're asking, Why would the verifier 01:33:48.650 --> 01:33:51.140 align:middle line:84% accept pi with non-negligible probability? 01:33:51.140 --> 01:33:57.130 align:middle line:84% Well, because this P star is accepted 01:33:57.130 --> 01:33:59.910 align:middle line:90% with probability epsilon. 01:33:59.910 --> 01:34:04.630 align:middle line:90% And, well, this-- 01:34:04.630 --> 01:34:06.800 align:middle line:90% V is going to ask-- 01:34:06.800 --> 01:34:07.900 align:middle line:90% OK, so what's the concern? 01:34:07.900 --> 01:34:11.710 align:middle line:84% The concern is, well, V now is going to ask, like, 01:34:11.710 --> 01:34:13.220 align:middle line:90% places that are 0 here. 01:34:13.220 --> 01:34:16.260 align:middle line:84% Right, so the point is we're saying-- 01:34:16.260 --> 01:34:20.960 align:middle line:84% your concern is-- look, P star succeeded. 01:34:20.960 --> 01:34:22.830 align:middle line:90% Maybe P star succeeded. 01:34:22.830 --> 01:34:25.850 align:middle line:84% But here, if P star succeeded, we have here our pi's, then 01:34:25.850 --> 01:34:28.610 align:middle line:84% P star will succeed, too, because P star answers 01:34:28.610 --> 01:34:29.310 align:middle line:90% like this. 01:34:29.310 --> 01:34:32.270 align:middle line:84% But you're saying, well, but maybe here there are zeros. 01:34:32.270 --> 01:34:33.810 align:middle line:90% Maybe here there are zeros. 01:34:33.810 --> 01:34:35.090 align:middle line:90% But why are there zeros? 01:34:35.090 --> 01:34:36.930 align:middle line:84% Let's remember, why did I put zeros here? 01:34:36.930 --> 01:34:39.420 align:middle line:90% Because P star failed on them. 01:34:39.420 --> 01:34:40.873 align:middle line:84% That's why there are zeros there. 01:34:40.873 --> 01:34:43.040 align:middle line:84% I asked this place many, many times, and every time, 01:34:43.040 --> 01:34:44.160 align:middle line:90% P star said no. 01:34:44.160 --> 01:34:46.180 align:middle line:90% So he won't succeed on this. 01:34:46.180 --> 01:34:49.100 align:middle line:84% Or there's also another option, that V PCP never 01:34:49.100 --> 01:34:50.835 align:middle line:84% asks that question, in which case 01:34:50.835 --> 01:34:52.210 align:middle line:84% he still won't ask that question. 01:34:52.210 --> 01:34:54.990 align:middle line:90% 01:34:54.990 --> 01:34:58.530 align:middle line:84% So again, the claim is that this PCP 01:34:58.530 --> 01:35:01.260 align:middle line:84% will be accepted with probability close 01:35:01.260 --> 01:35:05.640 align:middle line:84% to epsilon, because the probability that we will hit 01:35:05.640 --> 01:35:11.420 align:middle line:84% locations where we fail and he succeeds 01:35:11.420 --> 01:35:12.850 align:middle line:90% is very, very, very small. 01:35:12.850 --> 01:35:15.200 align:middle line:84% So whenever we fail, he will fail, too, 01:35:15.200 --> 01:35:18.680 align:middle line:84% with very high probability, because if he succeeds there, 01:35:18.680 --> 01:35:19.680 align:middle line:90% we would have succeeded. 01:35:19.680 --> 01:35:21.513 align:middle line:84% We asked so many questions, we would finally 01:35:21.513 --> 01:35:23.230 align:middle line:90% get the right answer. 01:35:23.230 --> 01:35:25.880 align:middle line:90% That's the high-level idea. 01:35:25.880 --> 01:35:26.380 align:middle line:90% OK. 01:35:26.380 --> 01:35:28.900 align:middle line:84% I don't want to go into more details. 01:35:28.900 --> 01:35:32.120 align:middle line:84% There's a link, in the website, exactly on the proof. 01:35:32.120 --> 01:35:35.500 align:middle line:84% But there's two reasons I don't want to go into more detail-- 01:35:35.500 --> 01:35:39.110 align:middle line:84% first, because it's tedious, so if you're interested, 01:35:39.110 --> 01:35:41.410 align:middle line:90% just look at the paper. 01:35:41.410 --> 01:35:46.570 align:middle line:84% But also, this is not the right proof. 01:35:46.570 --> 01:35:47.870 align:middle line:90% This is not the right proof. 01:35:47.870 --> 01:35:49.700 align:middle line:84% And why is it not the right proof? 01:35:49.700 --> 01:35:52.440 align:middle line:84% Because, note, I cheated you, actually. 01:35:52.440 --> 01:35:54.050 align:middle line:90% I actually lied. 01:35:54.050 --> 01:35:56.330 align:middle line:84% I promised you that I broke soundness, 01:35:56.330 --> 01:35:58.640 align:middle line:90% but I didn't actually. 01:35:58.640 --> 01:36:00.243 align:middle line:90% There's a very minor-- 01:36:00.243 --> 01:36:03.310 align:middle line:90% 01:36:03.310 --> 01:36:06.860 align:middle line:84% I don't know if you'd call it "bug," but I lied. 01:36:06.860 --> 01:36:11.330 align:middle line:90% And this doesn't quite do-- 01:36:11.330 --> 01:36:16.190 align:middle line:84% it doesn't quite break the collision resistance with my-- 01:36:16.190 --> 01:36:19.650 align:middle line:84% OK, when I say A breaks the collision resistance, 01:36:19.650 --> 01:36:23.090 align:middle line:90% I need to say A breaks-- 01:36:23.090 --> 01:36:28.970 align:middle line:84% poly-T-lambda adversary that breaks-- right, I said, 01:36:28.970 --> 01:36:35.170 align:middle line:84% I assume that you cannot break the collisions in time T lambda. 01:36:35.170 --> 01:36:39.580 align:middle line:84% So I said let's just say there's a T lambda times P star, 01:36:39.580 --> 01:36:43.810 align:middle line:90% and I'm going to break the-- 01:36:43.810 --> 01:36:47.070 align:middle line:84% I'm going to find the collision in time poly-T lambda. 01:36:47.070 --> 01:36:49.650 align:middle line:84% That's what gives me a contradiction. 01:36:49.650 --> 01:36:53.070 align:middle line:84% Right, I argue, my assumption is that there exists collisions 01:36:53.070 --> 01:36:56.430 align:middle line:84% in hash that cannot be broken, collisions cannot be found 01:36:56.430 --> 01:37:00.550 align:middle line:84% in time T. To break that, I need to say, 01:37:00.550 --> 01:37:04.670 align:middle line:84% if there is a cheating prover, then I can break the collision 01:37:04.670 --> 01:37:06.620 align:middle line:90% resistance in time poly T. 01:37:06.620 --> 01:37:09.980 align:middle line:84% Now, let's look at the runtime of this adversary. 01:37:09.980 --> 01:37:14.450 align:middle line:84% The P times of time poly T. That's OK. 01:37:14.450 --> 01:37:16.880 align:middle line:90% But what does my adversary do? 01:37:16.880 --> 01:37:23.200 align:middle line:84% My adversary, he tries to generate an entire PCP. 01:37:23.200 --> 01:37:25.930 align:middle line:84% And then he says, if I succeeded, I can succeed, 01:37:25.930 --> 01:37:27.410 align:middle line:84% and therefore, I must be collision. 01:37:27.410 --> 01:37:29.830 align:middle line:84% But to generate an entire PCP, he 01:37:29.830 --> 01:37:31.350 align:middle line:90% needs to run in time poly in n. 01:37:31.350 --> 01:37:34.240 align:middle line:90% 01:37:34.240 --> 01:37:38.610 align:middle line:84% What if T of lambda is smaller than n? 01:37:38.610 --> 01:37:43.788 align:middle line:84% Now, you can say, eh, come on, T of lambda 01:37:43.788 --> 01:37:44.830 align:middle line:90% must be bigger than an n. 01:37:44.830 --> 01:37:47.198 align:middle line:90% Otherwise, this kind of-- 01:37:47.198 --> 01:37:49.240 align:middle line:84% there's different-- I don't like this definition, 01:37:49.240 --> 01:37:50.920 align:middle line:84% because we shouldn't allow the cheating 01:37:50.920 --> 01:37:52.150 align:middle line:90% prover to run in time poly n. 01:37:52.150 --> 01:37:55.700 align:middle line:84% If you don't, something's wrong with the definition. 01:37:55.700 --> 01:37:57.830 align:middle line:84% I don't know, maybe yes, maybe no. 01:37:57.830 --> 01:38:02.630 align:middle line:84% I have no definition that says time T of lambda. 01:38:02.630 --> 01:38:04.640 align:middle line:84% Maybe you want T of lambda be smaller than n 01:38:04.640 --> 01:38:06.420 align:middle line:84% because the application makes sense, 01:38:06.420 --> 01:38:09.045 align:middle line:84% because you use it in a way that actually the prover will never 01:38:09.045 --> 01:38:11.042 align:middle line:90% run in time n. 01:38:11.042 --> 01:38:15.510 align:middle line:90% So I have now some T of lambda. 01:38:15.510 --> 01:38:18.380 align:middle line:84% How it connects to N, I actually don't know. 01:38:18.380 --> 01:38:23.240 align:middle line:84% And I want to ensure that I can break the adversary-- 01:38:23.240 --> 01:38:25.520 align:middle line:84% I can find collision time T to the lambda. 01:38:25.520 --> 01:38:28.867 align:middle line:84% But actually, I run piece time which is in time T 01:38:28.867 --> 01:38:29.450 align:middle line:90% to the lambda. 01:38:29.450 --> 01:38:30.590 align:middle line:90% That's fine. 01:38:30.590 --> 01:38:33.170 align:middle line:90% But I run it n times. 01:38:33.170 --> 01:38:36.290 align:middle line:84% 1 over epsilon is fine, because epsilon is like-- 01:38:36.290 --> 01:38:38.770 align:middle line:84% epsilon in lambda, or T to the lambda-- 01:38:38.770 --> 01:38:41.100 align:middle line:84% OK, it's 1 over poly T to the lambda. 01:38:41.100 --> 01:38:41.600 align:middle line:90% Fine. 01:38:41.600 --> 01:38:43.310 align:middle line:90% That's good, T to the lambda-- 01:38:43.310 --> 01:38:45.320 align:middle line:90% T of lambda, sorry. 01:38:45.320 --> 01:38:48.670 align:middle line:84% But this n, n can be bigger than T of lambda. 01:38:48.670 --> 01:38:52.170 align:middle line:90% 01:38:52.170 --> 01:39:01.680 align:middle line:84% So really, this works if-- this definition is good if, only if T 01:39:01.680 --> 01:39:02.850 align:middle line:90% of lambda is bigger than n. 01:39:02.850 --> 01:39:05.375 align:middle line:90% So this is a good proof if-- 01:39:05.375 --> 01:39:20.240 align:middle line:90% 01:39:20.240 --> 01:39:22.790 align:middle line:84% and this has kind of-- it's kind of bothered cryptographers, 01:39:22.790 --> 01:39:25.700 align:middle line:84% because even though it makes sense to assume that T of lambda 01:39:25.700 --> 01:39:28.460 align:middle line:84% is bigger than n, it makes sense to let the cheating prover run 01:39:28.460 --> 01:39:36.530 align:middle line:84% in time n, it's annoying that we need to do that. 01:39:36.530 --> 01:39:39.470 align:middle line:84% So I think we should take a break, a five-minute break. 01:39:39.470 --> 01:39:44.280 align:middle line:84% After the break, I'll tell you just a very high-level idea. 01:39:44.280 --> 01:39:47.210 align:middle line:84% There's a beautiful paper that came in 2002 by Barak 01:39:47.210 --> 01:39:51.060 align:middle line:84% and Goldreich, that they showed how to get around it, 01:39:51.060 --> 01:39:52.067 align:middle line:90% how to do it for any t. 01:39:52.067 --> 01:39:54.650 align:middle line:84% They get around-- they actually don't construct an entire PCP. 01:39:54.650 --> 01:40:00.140 align:middle line:84% They do what I think is more clever and more beautiful, 01:40:00.140 --> 01:40:05.060 align:middle line:84% kind of what I think of as the right proof for this. 01:40:05.060 --> 01:40:06.600 align:middle line:84% And we'll see that after the break, 01:40:06.600 --> 01:40:07.550 align:middle line:84% and then we'll do the construction 01:40:07.550 --> 01:40:08.520 align:middle line:90% of the collision-resistant. 01:40:08.520 --> 01:40:09.812 align:middle line:90% But there was questions before. 01:40:09.812 --> 01:40:11.090 align:middle line:90% Yeah? 01:40:11.090 --> 01:40:12.950 align:middle line:84% AUDIENCE: Is the rewinding necessary 01:40:12.950 --> 01:40:16.260 align:middle line:84% so you get lower success probability but still polynomial 01:40:16.260 --> 01:40:16.760 align:middle line:90% [INAUDIBLE]? 01:40:16.760 --> 01:40:19.710 align:middle line:90% YAEL KALAI: Great question. 01:40:19.710 --> 01:40:22.430 align:middle line:84% The rewinding for-- OK, so the question 01:40:22.430 --> 01:40:24.440 align:middle line:90% is, Is the rewinding necessary? 01:40:24.440 --> 01:40:26.190 align:middle line:90% And it's a great question. 01:40:26.190 --> 01:40:30.620 align:middle line:84% The answer is, for all I know, yes, the rewinding is necessary. 01:40:30.620 --> 01:40:34.890 align:middle line:84% This question was very important also for post-quantum, 01:40:34.890 --> 01:40:38.380 align:middle line:84% because today, we're worried about quantum computers. 01:40:38.380 --> 01:40:41.770 align:middle line:84% And if the cheating prover is a quantum device, 01:40:41.770 --> 01:40:44.280 align:middle line:84% you can't rewind him, because once you measure a quantum 01:40:44.280 --> 01:40:45.290 align:middle line:90% state, it collapses. 01:40:45.290 --> 01:40:45.790 align:middle line:90% Eh. 01:40:45.790 --> 01:40:49.720 align:middle line:84% And so proving post-quantum security of this protocol, 01:40:49.720 --> 01:40:50.220 align:middle line:90% it was-- 01:40:50.220 --> 01:40:52.780 align:middle line:84% actually, it's known to be post-quantum secure. 01:40:52.780 --> 01:40:54.750 align:middle line:84% But it was a lot of work because it 01:40:54.750 --> 01:40:56.880 align:middle line:84% was work that required to kind of rewind 01:40:56.880 --> 01:40:59.490 align:middle line:84% the cheating prover in the quantum-- 01:40:59.490 --> 01:41:02.297 align:middle line:84% to rewind the quantum cheating prover, and, Why can you rewind? 01:41:02.297 --> 01:41:03.880 align:middle line:84% So they showed you can actually do it. 01:41:03.880 --> 01:41:07.000 align:middle line:84% But just to answer your question, Do you need to rewind? 01:41:07.000 --> 01:41:10.320 align:middle line:84% yes, kind of we don't have a straight-line proof 01:41:10.320 --> 01:41:13.760 align:middle line:90% of soundness for this protocol. 01:41:13.760 --> 01:41:17.400 align:middle line:84% AUDIENCE: And is it because the witness [INAUDIBLE]? 01:41:17.400 --> 01:41:20.630 align:middle line:84% YAEL KALAI: You know, so it's-- the other proof I'll show you 01:41:20.630 --> 01:41:22.980 align:middle line:84% after the break doesn't quite construct the PCP. 01:41:22.980 --> 01:41:25.220 align:middle line:84% But in order to find collisions, we 01:41:25.220 --> 01:41:26.757 align:middle line:90% need to run them at least twice. 01:41:26.757 --> 01:41:28.340 align:middle line:84% I run them and then-- because how am I 01:41:28.340 --> 01:41:29.250 align:middle line:90% going to find collision? 01:41:29.250 --> 01:41:30.090 align:middle line:90% I give him queries. 01:41:30.090 --> 01:41:31.340 align:middle line:90% He's going to give me answers. 01:41:31.340 --> 01:41:33.650 align:middle line:84% How can I find collision from that? 01:41:33.650 --> 01:41:36.293 align:middle line:84% But if I run him once, and I run him again with-- 01:41:36.293 --> 01:41:37.710 align:middle line:84% the idea is I'm going to run him-- 01:41:37.710 --> 01:41:39.543 align:middle line:84% I'm going to choose, like, a random query i. 01:41:39.543 --> 01:41:41.660 align:middle line:84% I'm once going to run him i with some queries, 01:41:41.660 --> 01:41:44.850 align:middle line:84% and then I'm going to run him i with other queries. 01:41:44.850 --> 01:41:48.360 align:middle line:84% And the only way you can cheat is if you're not always 01:41:48.360 --> 01:41:49.890 align:middle line:90% consistent. 01:41:49.890 --> 01:41:51.635 align:middle line:84% But at least, I need to remind you twice. 01:41:51.635 --> 01:41:54.530 align:middle line:90% 01:41:54.530 --> 01:42:01.170 align:middle line:84% So that's the-- any other questions? 01:42:01.170 --> 01:42:02.105 align:middle line:90% Yeah? 01:42:02.105 --> 01:42:03.897 align:middle line:84% AUDIENCE: Could the right group [INAUDIBLE] 01:42:03.897 --> 01:42:07.500 align:middle line:84% query if we had a concrete hash function instead 01:42:07.500 --> 01:42:09.122 align:middle line:90% of this abstract notion? 01:42:09.122 --> 01:42:10.580 align:middle line:84% YAEL KALAI: No, I don't think the-- 01:42:10.580 --> 01:42:13.800 align:middle line:90% 01:42:13.800 --> 01:42:16.570 align:middle line:84% actually, when you look inside the hash function, 01:42:16.570 --> 01:42:18.360 align:middle line:90% it just becomes messy. 01:42:18.360 --> 01:42:21.000 align:middle line:84% I think actually abstracting out the hash functions, 01:42:21.000 --> 01:42:23.130 align:middle line:84% and just thinking what property it gives you, 01:42:23.130 --> 01:42:26.040 align:middle line:90% makes the proof cleaner. 01:42:26.040 --> 01:42:28.320 align:middle line:84% Kind of to put boxes around things 01:42:28.320 --> 01:42:30.840 align:middle line:84% and just modularize kind of what you need, 01:42:30.840 --> 01:42:33.210 align:middle line:84% it actually helps the understanding 01:42:33.210 --> 01:42:37.406 align:middle line:90% and simplifies the proof. 01:42:37.406 --> 01:42:39.810 align:middle line:84% Yeah, I think the problem with this proof 01:42:39.810 --> 01:42:42.170 align:middle line:84% is that it requires constructing an entire PCP, 01:42:42.170 --> 01:42:43.920 align:middle line:84% and sometimes you're saying, Why do I need 01:42:43.920 --> 01:42:45.690 align:middle line:90% to construct an entire PCP? 01:42:45.690 --> 01:42:47.820 align:middle line:84% So the other proof kind of shows that you actually 01:42:47.820 --> 01:42:48.760 align:middle line:90% don't need to do that. 01:42:48.760 --> 01:42:50.135 align:middle line:84% And that's why the prover doesn't 01:42:50.135 --> 01:42:51.570 align:middle line:90% need to run time linear in n. 01:42:51.570 --> 01:42:54.605 align:middle line:84% It just runs in time that depends on t. 01:42:54.605 --> 01:42:58.420 align:middle line:90% 01:42:58.420 --> 01:43:00.290 align:middle line:84% Any other questions before the break? 01:43:00.290 --> 01:43:00.920 align:middle line:90% Yeah? 01:43:00.920 --> 01:43:01.990 align:middle line:84% AUDIENCE: Just to clarify, n here 01:43:01.990 --> 01:43:03.910 align:middle line:84% is the size of the PCP, not the [INAUDIBLE]. 01:43:03.910 --> 01:43:06.285 align:middle line:84% YAEL KALAI: Yeah, you're right. n is the size of the PCP. 01:43:06.285 --> 01:43:08.710 align:middle line:84% But I'm thinking here, because I'm thinking of 3-SAT, 01:43:08.710 --> 01:43:11.230 align:middle line:84% I'm thinking the input, the instance, 01:43:11.230 --> 01:43:15.860 align:middle line:84% and the witness and the PCP are all poly-related. 01:43:15.860 --> 01:43:19.740 align:middle line:84% So because I have here a polynomial, it doesn't matter. 01:43:19.740 --> 01:43:23.480 align:middle line:84% But I do want to say, in some settings, 01:43:23.480 --> 01:43:28.730 align:middle line:84% you can think of the witness can be much, much smaller 01:43:28.730 --> 01:43:31.320 align:middle line:84% than the instance or much, much bigger than the instance. 01:43:31.320 --> 01:43:33.990 align:middle line:84% So for example, take nondeterministic time 01:43:33.990 --> 01:43:37.490 align:middle line:84% T. x is of size n, but the witness 01:43:37.490 --> 01:43:42.430 align:middle line:84% is of size T of n, which can be superpolynomial in n. 01:43:42.430 --> 01:43:45.980 align:middle line:84% Then this becomes polynomial in the witness. 01:43:45.980 --> 01:43:48.580 align:middle line:84% The PCP is always-- or, OK, the PCP 01:43:48.580 --> 01:43:52.118 align:middle line:84% is always polynomially related to the instance and witness. 01:43:52.118 --> 01:43:53.660 align:middle line:84% Now, sometimes the witness is bigger. 01:43:53.660 --> 01:43:54.820 align:middle line:84% Sometimes the instance is bigger. 01:43:54.820 --> 01:43:57.080 align:middle line:84% And the relation does not need to be polynomially related. 01:43:57.080 --> 01:43:58.280 align:middle line:84% If they're all polynomially related, 01:43:58.280 --> 01:44:00.155 align:middle line:84% it doesn't matter here, because I put a poly. 01:44:00.155 --> 01:44:03.500 align:middle line:84% But sometimes the witness can be much, much smaller, 01:44:03.500 --> 01:44:04.790 align:middle line:90% like a log clique. 01:44:04.790 --> 01:44:07.960 align:middle line:84% The witness is size log squared but the input is n. 01:44:07.960 --> 01:44:09.910 align:middle line:84% And sometimes the instance can be small 01:44:09.910 --> 01:44:11.620 align:middle line:90% and the witness can be big. 01:44:11.620 --> 01:44:16.510 align:middle line:84% So what I mean here is input plus witness length. 01:44:16.510 --> 01:44:18.760 align:middle line:84% Here, I just put one of them because I assume, 3-SAT, 01:44:18.760 --> 01:44:20.180 align:middle line:90% they're both the same. 01:44:20.180 --> 01:44:23.230 align:middle line:84% So, yeah, but that's a good-- what really I need to put here 01:44:23.230 --> 01:44:24.220 align:middle line:90% is PCP length. 01:44:24.220 --> 01:44:25.990 align:middle line:90% That's the truth. 01:44:25.990 --> 01:44:26.600 align:middle line:90% Yeah. 01:44:26.600 --> 01:44:27.100 align:middle line:90% Great. 01:44:27.100 --> 01:44:27.940 align:middle line:90% Great point. 01:44:27.940 --> 01:44:29.500 align:middle line:90% Fantastic. 01:44:29.500 --> 01:44:32.310 align:middle line:84% Are there questions before we break? 01:44:32.310 --> 01:44:35.450 align:middle line:84% OK, let's do a five-minute break, and then we'll return.