WEBVTT 00:00:00.000 --> 00:00:01.470 align:middle line:90% [SQUEAKING] 00:00:01.470 --> 00:00:02.940 align:middle line:90% 00:00:02.940 --> 00:00:04.410 align:middle line:90% [RUSTLING] 00:00:04.410 --> 00:00:07.350 align:middle line:90% [CLICKING] 00:00:07.350 --> 00:00:12.740 align:middle line:90% 00:00:12.740 --> 00:00:15.290 align:middle line:84% YAEL KALAI: Today, we're going to continue. 00:00:15.290 --> 00:00:17.140 align:middle line:84% We're going to talk about a new notion, 00:00:17.140 --> 00:00:20.270 align:middle line:84% a really, really interesting notion, in my opinion, 00:00:20.270 --> 00:00:22.350 align:middle line:84% called probabilistically checkable proofs. 00:00:22.350 --> 00:00:23.640 align:middle line:90% I'll explain what it is. 00:00:23.640 --> 00:00:25.640 align:middle line:84% So we're going to define this notion, 00:00:25.640 --> 00:00:29.420 align:middle line:84% and we're going to construct it from the GKR protocol. 00:00:29.420 --> 00:00:33.530 align:middle line:84% So you'll kind of see not only the definition, but you'll 00:00:33.530 --> 00:00:35.115 align:middle line:90% be able, after this class-- 00:00:35.115 --> 00:00:37.240 align:middle line:84% the hope is that you'll be able to construct a PCP. 00:00:37.240 --> 00:00:39.750 align:middle line:84% And if you need to construct a [? visual ?] proof, 00:00:39.750 --> 00:00:41.130 align:middle line:90% you'll be able to do that. 00:00:41.130 --> 00:00:44.700 align:middle line:84% So that's going to be the first part of today's lecture. 00:00:44.700 --> 00:00:46.370 align:middle line:84% And the second part of today's lecture 00:00:46.370 --> 00:00:48.453 align:middle line:84% is actually going to be the first time we actually 00:00:48.453 --> 00:00:49.200 align:middle line:90% use cryptography. 00:00:49.200 --> 00:00:54.225 align:middle line:84% So, so far, this class has not been at all about cryptography. 00:00:54.225 --> 00:00:55.350 align:middle line:90% Everything was information. 00:00:55.350 --> 00:00:57.350 align:middle line:84% It was actually complexity theory. 00:00:57.350 --> 00:00:59.750 align:middle line:84% But today is going to be the first time we're going 00:00:59.750 --> 00:01:02.640 align:middle line:90% to move into cryptography. 00:01:02.640 --> 00:01:06.260 align:middle line:84% And as we'll talk, we'll see that 00:01:06.260 --> 00:01:08.850 align:middle line:84% doing this information, theoretic proofs where you say, 00:01:08.850 --> 00:01:15.700 align:middle line:84% OK, no prover can give you a false proof, that is limiting. 00:01:15.700 --> 00:01:20.460 align:middle line:84% OK, we can't do everything we want using this notion. 00:01:20.460 --> 00:01:24.310 align:middle line:84% And therefore, we're going to go into a new notion of soundness, 00:01:24.310 --> 00:01:28.270 align:middle line:84% which is what we call arguments or computational soundness. 00:01:28.270 --> 00:01:31.590 align:middle line:84% And we're going to relax the prover and say, 00:01:31.590 --> 00:01:34.740 align:middle line:84% an all-power proof, an all-powerful prover, 00:01:34.740 --> 00:01:39.070 align:middle line:84% may be able to cheat, but the guarantee we give-- hey, Tony-- 00:01:39.070 --> 00:01:43.360 align:middle line:84% is that a computationally bounded prover cannot cheat. 00:01:43.360 --> 00:01:45.610 align:middle line:84% That's going to be the guarantee we get. 00:01:45.610 --> 00:01:48.480 align:middle line:84% And we'll see, once we relax the soundness requirement 00:01:48.480 --> 00:01:51.490 align:middle line:84% to a requirement that's only computational sound, 00:01:51.490 --> 00:01:53.340 align:middle line:84% then we'll be able to get a lot more, 00:01:53.340 --> 00:01:57.250 align:middle line:84% and the life will kind of open for us, 00:01:57.250 --> 00:02:01.080 align:middle line:84% and we're going to have a lot of new kind of constructions 00:02:01.080 --> 00:02:04.710 align:middle line:84% and things that we were unable to do information theoretically. 00:02:04.710 --> 00:02:07.200 align:middle line:90% So this is the plan for today. 00:02:07.200 --> 00:02:09.130 align:middle line:90% Questions before we start? 00:02:09.130 --> 00:02:13.240 align:middle line:84% I haven't seen you guys in a while, so it's good to see you. 00:02:13.240 --> 00:02:15.820 align:middle line:84% A lot of things changed since the last time I've seen you. 00:02:15.820 --> 00:02:19.140 align:middle line:84% I'm probably going to be a bit distracted today, so I'm sorry. 00:02:19.140 --> 00:02:21.150 align:middle line:90% OK. 00:02:21.150 --> 00:02:22.080 align:middle line:90% OK, let's start. 00:02:22.080 --> 00:02:24.490 align:middle line:90% So what are-- no questions? 00:02:24.490 --> 00:02:26.730 align:middle line:90% PL/ So let's start with PCPs. 00:02:26.730 --> 00:02:29.940 align:middle line:84% What are Probabilistically Checkable Proofs? 00:02:29.940 --> 00:02:34.020 align:middle line:84% So the idea of probabilistically checkable proofs 00:02:34.020 --> 00:02:36.840 align:middle line:84% is to take a proof, like a classical proof-- think of NP. 00:02:36.840 --> 00:02:40.560 align:middle line:84% In NP, we have an instance x and a witness. 00:02:40.560 --> 00:02:46.550 align:middle line:84% This witness is like a proof for x being in the language. 00:02:46.550 --> 00:02:50.150 align:middle line:84% To verify this proof, you need to read the entire thing 00:02:50.150 --> 00:02:54.630 align:middle line:84% and do some computation, like this verification circuit 00:02:54.630 --> 00:02:57.900 align:middle line:84% that checks that x and w is in the relation. 00:02:57.900 --> 00:03:00.125 align:middle line:84% There's a circuit that checks this. 00:03:00.125 --> 00:03:03.250 align:middle line:84% OK, what is the idea of a probabilistically checkable 00:03:03.250 --> 00:03:03.830 align:middle line:90% proof? 00:03:03.830 --> 00:03:07.570 align:middle line:84% The idea here, what we want, is to take this proof 00:03:07.570 --> 00:03:12.115 align:middle line:84% and convert it into a new proof and maybe larger 00:03:12.115 --> 00:03:13.490 align:middle line:84% actually than the original proof. 00:03:13.490 --> 00:03:16.900 align:middle line:84% So maybe the original proof was of size m. 00:03:16.900 --> 00:03:18.900 align:middle line:84% Let's say the instance of size n. 00:03:18.900 --> 00:03:21.490 align:middle line:90% This may be of size much bigger. 00:03:21.490 --> 00:03:24.420 align:middle line:84% Still, we want it to be polynomial in n and m. 00:03:24.420 --> 00:03:27.380 align:middle line:90% 00:03:27.380 --> 00:03:28.670 align:middle line:90% So we just made it bigger. 00:03:28.670 --> 00:03:30.740 align:middle line:90% So what's good about it? 00:03:30.740 --> 00:03:32.410 align:middle line:84% So what's nice about this proof is, 00:03:32.410 --> 00:03:35.200 align:middle line:84% the idea is, you don't actually have to read all of it 00:03:35.200 --> 00:03:36.780 align:middle line:90% to check it. 00:03:36.780 --> 00:03:37.900 align:middle line:90% And that's weird. 00:03:37.900 --> 00:03:39.690 align:middle line:84% So the idea here-- yeah, the proof 00:03:39.690 --> 00:03:42.300 align:middle line:84% may be a little longer, polynomially longer, 00:03:42.300 --> 00:03:48.150 align:middle line:84% but you only need to read a few locations to check 00:03:48.150 --> 00:03:49.120 align:middle line:90% that it's valid. 00:03:49.120 --> 00:03:53.940 align:middle line:84% So to verify-- often PCPs are denoted by pi-- 00:03:53.940 --> 00:03:59.593 align:middle line:84% a PCP proof given x, all the verifier needs to do is query. 00:03:59.593 --> 00:04:01.510 align:middle line:84% He doesn't actually need to read these things. 00:04:01.510 --> 00:04:05.050 align:middle line:84% He queries a few locations, a few bits, checks, 00:04:05.050 --> 00:04:07.170 align:middle line:84% a few bits of the proof, and then applies 00:04:07.170 --> 00:04:11.030 align:middle line:84% a verification circuit that depends only on these bits. 00:04:11.030 --> 00:04:15.570 align:middle line:84% And importantly, the bits he chooses are random. 00:04:15.570 --> 00:04:16.745 align:middle line:90% The prover doesn't know. 00:04:16.745 --> 00:04:19.073 align:middle line:90% Otherwise, it's like shrinking. 00:04:19.073 --> 00:04:20.990 align:middle line:84% If he knew, the prover knew, oh, the reference 00:04:20.990 --> 00:04:24.120 align:middle line:84% is going to only check in bit 17, 22, and 25, 00:04:24.120 --> 00:04:26.720 align:middle line:84% then he would just give you-- it's like you'll 00:04:26.720 --> 00:04:27.822 align:middle line:90% have a succinct witness. 00:04:27.822 --> 00:04:29.780 align:middle line:84% And, of course, we can't take arbitrary witness 00:04:29.780 --> 00:04:31.280 align:middle line:90% and just make them succinct. 00:04:31.280 --> 00:04:32.310 align:middle line:84% We don't believe that's possible. 00:04:32.310 --> 00:04:32.810 align:middle line:90% Yeah. 00:04:32.810 --> 00:04:34.820 align:middle line:84% AUDIENCE: So it's [INAUDIBLE] only useful 00:04:34.820 --> 00:04:37.565 align:middle line:90% if m is much greater than n? 00:04:37.565 --> 00:04:38.190 align:middle line:90% YAEL KALAI: OK. 00:04:38.190 --> 00:04:40.770 align:middle line:84% So the question was, is a PCP used 00:04:40.770 --> 00:04:43.190 align:middle line:90% if m is much greater than n? 00:04:43.190 --> 00:04:44.400 align:middle line:90% And the answer is no. 00:04:44.400 --> 00:04:49.460 align:middle line:84% Actually, think of it, we can even use it where m the length, 00:04:49.460 --> 00:04:52.490 align:middle line:90% w is n to the epsilon-- 00:04:52.490 --> 00:04:56.310 align:middle line:84% even less than n to the epsilon, even n to the little o of n. 00:04:56.310 --> 00:04:58.640 align:middle line:84% Now, this will still be polynomial in n. 00:04:58.640 --> 00:05:02.570 align:middle line:84% So actually, you took the proof and make it actually 00:05:02.570 --> 00:05:04.520 align:middle line:84% more than polynomially larger, because it's 00:05:04.520 --> 00:05:06.080 align:middle line:90% polynomial in n and m. 00:05:06.080 --> 00:05:10.870 align:middle line:84% And if the proof here smaller is n to the little o of 1, 00:05:10.870 --> 00:05:12.090 align:middle line:90% then this is poly n. 00:05:12.090 --> 00:05:14.420 align:middle line:84% It's actually more than polynomial bigger. 00:05:14.420 --> 00:05:16.120 align:middle line:90% So you think, what did we gain? 00:05:16.120 --> 00:05:18.400 align:middle line:84% We took a short proof, made it so much bigger. 00:05:18.400 --> 00:05:19.330 align:middle line:90% What did we gain? 00:05:19.330 --> 00:05:22.570 align:middle line:84% And what we gained is, the hope is, that you can query this, 00:05:22.570 --> 00:05:25.840 align:middle line:84% the verifier can query this, in very, very few locations, 00:05:25.840 --> 00:05:28.270 align:middle line:84% read only very, very few bits of this proof. 00:05:28.270 --> 00:05:29.490 align:middle line:90% AUDIENCE: OK, [INAUDIBLE]. 00:05:29.490 --> 00:05:31.432 align:middle line:84% Does the verifier also have to read x then? 00:05:31.432 --> 00:05:32.765 align:middle line:90% YAEL KALAI: Yeah, the verifier-- 00:05:32.765 --> 00:05:33.510 align:middle line:90% AUDIENCE: [INAUDIBLE]? 00:05:33.510 --> 00:05:34.020 align:middle line:90% YAEL KALAI: All of it. 00:05:34.020 --> 00:05:34.520 align:middle line:90% So, yes. 00:05:34.520 --> 00:05:35.322 align:middle line:90% Good. 00:05:35.322 --> 00:05:36.280 align:middle line:90% That's a good question. 00:05:36.280 --> 00:05:39.600 align:middle line:84% So the question was, does the verifier have to read all of x? 00:05:39.600 --> 00:05:41.100 align:middle line:84% Because I said he only needs to read 00:05:41.100 --> 00:05:43.710 align:middle line:84% a few locations in the proof, does he need to read all of x? 00:05:43.710 --> 00:05:45.960 align:middle line:84% And a priori, of course he needs to read all of x. 00:05:45.960 --> 00:05:49.050 align:middle line:84% Because even if there's one bit in x that he doesn't read, 00:05:49.050 --> 00:05:53.513 align:middle line:84% what if that bit is-- it's not clear what the sentence is, 00:05:53.513 --> 00:05:54.430 align:middle line:90% what the statement is. 00:05:54.430 --> 00:05:56.263 align:middle line:84% The prover needs to know, what am I reading? 00:05:56.263 --> 00:05:58.000 align:middle line:90% What are you proving to me? 00:05:58.000 --> 00:06:01.860 align:middle line:84% But there are extensions called PCP of proximity, which I'm not 00:06:01.860 --> 00:06:07.500 align:middle line:84% going to get into in this class, where actually the verifier also 00:06:07.500 --> 00:06:09.930 align:middle line:84% doesn't read all of x, but the guarantee is not 00:06:09.930 --> 00:06:11.190 align:middle line:90% that x is in the language. 00:06:11.190 --> 00:06:16.630 align:middle line:84% The guarantee is that the oracle that is given to the verifier, 00:06:16.630 --> 00:06:19.420 align:middle line:84% there is something close to it that's in the language. 00:06:19.420 --> 00:06:23.010 align:middle line:84% So there is a notion of extension of the PCP 00:06:23.010 --> 00:06:25.900 align:middle line:84% where the verifier doesn't even need to read all of x. 00:06:25.900 --> 00:06:29.740 align:middle line:84% The guarantees there are not very easy to state, 00:06:29.740 --> 00:06:31.150 align:middle line:90% but it's a very useful notion. 00:06:31.150 --> 00:06:32.233 align:middle line:90% Actually, it's used a lot. 00:06:32.233 --> 00:06:34.300 align:middle line:90% It's called PCPs of proximity. 00:06:34.300 --> 00:06:38.060 align:middle line:90% 00:06:38.060 --> 00:06:40.280 align:middle line:84% OK, so that's what we're going to do today. 00:06:40.280 --> 00:06:43.290 align:middle line:84% And let me just mention, before even we start the formal thing, 00:06:43.290 --> 00:06:46.620 align:middle line:84% let me just say, this is really an amazing line of work. 00:06:46.620 --> 00:06:49.850 align:middle line:84% Today, we know how to take any witness, 00:06:49.850 --> 00:06:53.090 align:middle line:84% convert it to a probabilistically checkable one 00:06:53.090 --> 00:06:56.640 align:middle line:84% that the verifier only reads 3 bits-- 00:06:56.640 --> 00:07:02.960 align:middle line:84% 3, 3 bits-- of this proof and is convinced, 00:07:02.960 --> 00:07:04.370 align:middle line:90% with [INAUDIBLE] probability. 00:07:04.370 --> 00:07:07.948 align:middle line:90% 7/7 is the parameter. 00:07:07.948 --> 00:07:09.990 align:middle line:84% And then, if you want more, of course you repeat. 00:07:09.990 --> 00:07:14.420 align:middle line:84% But even with just 3 bits, you get some soundness, 00:07:14.420 --> 00:07:15.720 align:middle line:90% and that's really amazing. 00:07:15.720 --> 00:07:17.880 align:middle line:84% So we're not going to see the 3-bit proof, 00:07:17.880 --> 00:07:19.920 align:middle line:84% but we're going to see a polylog n proof. 00:07:19.920 --> 00:07:22.340 align:middle line:84% So what we're going to show, the construction 00:07:22.340 --> 00:07:25.220 align:middle line:84% we're going to see today, is how to go from a witness 00:07:25.220 --> 00:07:27.080 align:middle line:84% to a probabilistically checkable one 00:07:27.080 --> 00:07:33.100 align:middle line:84% that the verifier only needs to read polylog n of these bits 00:07:33.100 --> 00:07:34.540 align:middle line:90% and verify. 00:07:34.540 --> 00:07:36.870 align:middle line:84% And to go to the constant, there's 00:07:36.870 --> 00:07:39.010 align:middle line:84% additional tricks of recursion and so on that one 00:07:39.010 --> 00:07:40.610 align:middle line:90% needs to do to get there. 00:07:40.610 --> 00:07:43.090 align:middle line:84% But we're not going to cover that part. 00:07:43.090 --> 00:07:47.410 align:middle line:90% OK, ready to roll sleeves? 00:07:47.410 --> 00:07:56.040 align:middle line:84% OK, let's-- so let me just define the complexity class. 00:07:56.040 --> 00:07:58.190 align:middle line:84% People often think of it as a complexity class, 00:07:58.190 --> 00:08:00.190 align:middle line:84% even though, for us, because this 00:08:00.190 --> 00:08:02.360 align:middle line:84% is more of a proof system, cryptography class, 00:08:02.360 --> 00:08:03.560 align:middle line:90% we always want efficiency. 00:08:03.560 --> 00:08:05.360 align:middle line:84% We don't care just about complexity. 00:08:05.360 --> 00:08:07.870 align:middle line:84% We want to say that actually we can take any witness 00:08:07.870 --> 00:08:09.350 align:middle line:90% and officially convert it. 00:08:09.350 --> 00:08:11.120 align:middle line:90% It's not just about existence. 00:08:11.120 --> 00:08:13.630 align:middle line:84% We want to actually use these things. 00:08:13.630 --> 00:08:16.220 align:middle line:84% And let me just jump ahead and say that these things are used. 00:08:16.220 --> 00:08:17.710 align:middle line:90% It's not just a theoretical. 00:08:17.710 --> 00:08:20.350 align:middle line:84% Even though everything we've seen so far in the class 00:08:20.350 --> 00:08:23.000 align:middle line:84% is very just beautiful mathematically, 00:08:23.000 --> 00:08:35.581 align:middle line:84% it seems a very kind of away from practice. 00:08:35.581 --> 00:08:36.539 align:middle line:90% But actually, it's not. 00:08:36.539 --> 00:08:38.872 align:middle line:84% All these things that I've shown you so far, that you've 00:08:38.872 --> 00:08:40.530 align:middle line:84% seen so far, are things that actually 00:08:40.530 --> 00:08:45.882 align:middle line:90% are used, and the PCP as well. 00:08:45.882 --> 00:08:47.590 align:middle line:84% All this machinery are things that's use, 00:08:47.590 --> 00:08:49.330 align:middle line:84% so we actually do care about efficiency. 00:08:49.330 --> 00:08:53.280 align:middle line:84% But let me first define it as a complexity class. 00:08:53.280 --> 00:08:58.920 align:middle line:84% So we define the complexity, the complexity class, PCP, 00:08:58.920 --> 00:09:03.750 align:middle line:84% c for completeness parameter, s for soundness parameter, 00:09:03.750 --> 00:09:08.260 align:middle line:84% r for randomness parameter, and q for query parameter. 00:09:08.260 --> 00:09:09.970 align:middle line:90% So this is a class. 00:09:09.970 --> 00:09:22.200 align:middle line:84% This is the class of all languages L 00:09:22.200 --> 00:09:30.350 align:middle line:84% that have a probabilistically checkable proof. 00:09:30.350 --> 00:09:33.460 align:middle line:84% But I'll explain exactly what I mean. 00:09:33.460 --> 00:09:38.050 align:middle line:84% So actually, let me see, these are all the-- 00:09:38.050 --> 00:09:40.840 align:middle line:90% let me write it formally. 00:09:40.840 --> 00:09:43.030 align:middle line:84% These are all the languages L such 00:09:43.030 --> 00:09:51.400 align:middle line:84% that there exists a PPT, a Probabilistic Polynomial Time 00:09:51.400 --> 00:09:52.286 align:middle line:90% verifier-- 00:09:52.286 --> 00:09:55.600 align:middle line:90% 00:09:55.600 --> 00:09:59.590 align:middle line:84% Actually, it's a PPT oracle machine, 00:09:59.590 --> 00:10:09.910 align:middle line:84% because it takes the PCP as an oracle machine V, such that-- 00:10:09.910 --> 00:10:15.710 align:middle line:90% so here are the condition. 00:10:15.710 --> 00:10:20.710 align:middle line:84% The completeness says that for every x in the language, 00:10:20.710 --> 00:10:29.720 align:middle line:84% there exists a PCP pi such that the probability that V, 00:10:29.720 --> 00:10:33.620 align:middle line:84% the Verifier, given Oracle access to this PCP pi 00:10:33.620 --> 00:10:39.470 align:middle line:84% and input the instance, there exists a PCP such 00:10:39.470 --> 00:10:42.260 align:middle line:84% that the verifier will accept, it will output 1, 00:10:42.260 --> 00:10:44.320 align:middle line:90% with probability at least c. 00:10:44.320 --> 00:10:45.860 align:middle line:84% That's the completeness parameter. 00:10:45.860 --> 00:10:49.400 align:middle line:84% For us, the PCP we'll see will have completeness parameter 1. 00:10:49.400 --> 00:10:55.190 align:middle line:84% So we want to say that a language L has such a PCP, 00:10:55.190 --> 00:10:59.570 align:middle line:84% if there is a verifier V, efficient verifier, it 00:10:59.570 --> 00:11:00.925 align:middle line:90% takes oracle access. 00:11:00.925 --> 00:11:02.300 align:middle line:84% So if x is in the language, there 00:11:02.300 --> 00:11:04.880 align:middle line:84% exists some PCP so that the verifier 00:11:04.880 --> 00:11:07.880 align:middle line:84% with oracle access to this PCP, given this input, 00:11:07.880 --> 00:11:09.650 align:middle line:90% outputs 1 with probability c. 00:11:09.650 --> 00:11:10.150 align:middle line:90% Yes. 00:11:10.150 --> 00:11:11.900 align:middle line:84% AUDIENCE: Maybe I'm jumping the gun a bit, 00:11:11.900 --> 00:11:13.430 align:middle line:84% but what does the oracle look like? 00:11:13.430 --> 00:11:14.570 align:middle line:90% What are the inputs and outputs? 00:11:14.570 --> 00:11:15.945 align:middle line:84% YAEL KALAI: OK, good, good, good. 00:11:15.945 --> 00:11:17.190 align:middle line:90% So OK, good. 00:11:17.190 --> 00:11:19.080 align:middle line:84% No, you're not jumping, so good question. 00:11:19.080 --> 00:11:22.970 align:middle line:84% So this pi, you should think of it as a string. 00:11:22.970 --> 00:11:24.800 align:middle line:90% It has bits b1-- 00:11:24.800 --> 00:11:30.620 align:middle line:84% Maybe I'll call it pi 1, pi 2, up to pi, I don't know, n. 00:11:30.620 --> 00:11:36.420 align:middle line:84% And the verifier can ask, give me pi 1, give me pi 2, 00:11:36.420 --> 00:11:37.280 align:middle line:90% give me pi 3. 00:11:37.280 --> 00:11:39.120 align:middle line:90% So it just has oracle queries. 00:11:39.120 --> 00:11:40.730 align:middle line:90% He can query this string. 00:11:40.730 --> 00:11:42.527 align:middle line:84% That's what Oracle-- it's not really-- 00:11:42.527 --> 00:11:43.860 align:middle line:90% don't think of it as a function. 00:11:43.860 --> 00:11:45.318 align:middle line:84% It has oracle access to the string, 00:11:45.318 --> 00:11:47.755 align:middle line:84% and he can just ask for specific bits from the string. 00:11:47.755 --> 00:11:48.380 align:middle line:90% Great question. 00:11:48.380 --> 00:11:50.770 align:middle line:90% Thank you. 00:11:50.770 --> 00:11:52.520 align:middle line:90% OK, good. 00:11:52.520 --> 00:12:00.910 align:middle line:84% And the soundness guarantee says that for every x 00:12:00.910 --> 00:12:04.510 align:middle line:90% that's not in the language-- 00:12:04.510 --> 00:12:08.120 align:middle line:90% any guesses, by the way? 00:12:08.120 --> 00:12:09.680 align:middle line:84% So you need to define the PCP here. 00:12:09.680 --> 00:12:12.460 align:middle line:90% How would you define soundness? 00:12:12.460 --> 00:12:13.220 align:middle line:90% Yeah. 00:12:13.220 --> 00:12:15.040 align:middle line:84% AUDIENCE: I guess for all pi prime, 00:12:15.040 --> 00:12:18.340 align:middle line:84% the probability that a verifier [? with ?] [? formal ?] 00:12:18.340 --> 00:12:22.960 align:middle line:84% [? access ?] [? to the ?] pi prime accepts x is at most s. 00:12:22.960 --> 00:12:24.550 align:middle line:90% YAEL KALAI: Wonderful. 00:12:24.550 --> 00:12:25.420 align:middle line:90% Exactly. 00:12:25.420 --> 00:12:29.060 align:middle line:84% You want to say that for every pi star-- 00:12:29.060 --> 00:12:31.443 align:middle line:84% that's often how we denote bad things, pi prime [? 00:12:31.443 --> 00:12:33.660 align:middle line:90% will do ?] too-- 00:12:33.660 --> 00:12:34.910 align:middle line:90% now there's a cheating prover. 00:12:34.910 --> 00:12:36.590 align:middle line:90% He tries to fool the verifier. 00:12:36.590 --> 00:12:37.370 align:middle line:90% He cannot. 00:12:37.370 --> 00:12:39.800 align:middle line:84% So no matter what he tries to give him, 00:12:39.800 --> 00:12:43.060 align:middle line:84% the verifier will reject him with probability 00:12:43.060 --> 00:12:47.230 align:middle line:84% or will acceptability smaller than s. 00:12:47.230 --> 00:12:49.060 align:middle line:90% That's the soundness guarantee. 00:12:49.060 --> 00:12:52.010 align:middle line:84% And ideally, we want to push the completeness to 1, the soundness 00:12:52.010 --> 00:12:54.110 align:middle line:90% to 0. 00:12:54.110 --> 00:12:54.710 align:middle line:90% Great. 00:12:54.710 --> 00:12:59.150 align:middle line:90% And then, the complexity is-- 00:12:59.150 --> 00:13:01.050 align:middle line:84% now, we want to say, in terms of complexity 00:13:01.050 --> 00:13:18.280 align:middle line:84% now will go to v uses r bits of randomness and q oracle calls. 00:13:18.280 --> 00:13:21.820 align:middle line:90% 00:13:21.820 --> 00:13:24.510 align:middle line:84% And moreover, we'll see this is important for us. 00:13:24.510 --> 00:13:26.780 align:middle line:84% This is often in the definition, though not always, 00:13:26.780 --> 00:13:30.605 align:middle line:84% but often this is part of the [INAUDIBLE], q nonadaptive. 00:13:30.605 --> 00:13:35.560 align:middle line:90% 00:13:35.560 --> 00:13:37.610 align:middle line:90% What do I mean by nonadaptive? 00:13:37.610 --> 00:13:42.770 align:middle line:84% What I mean is the way V works, he gets input x, 00:13:42.770 --> 00:13:53.580 align:middle line:84% he then chooses kind of i1 up to i q locations in the PCP. 00:13:53.580 --> 00:13:56.670 align:middle line:84% OK, so [INAUDIBLE] the V. He doesn't even look at the oracle 00:13:56.670 --> 00:13:57.710 align:middle line:90% yet. 00:13:57.710 --> 00:13:59.690 align:middle line:90% He has an input x. 00:13:59.690 --> 00:14:04.100 align:middle line:90% He first computes q locations. 00:14:04.100 --> 00:14:08.480 align:middle line:84% He then goes to the oracle, asks these q locations. 00:14:08.480 --> 00:14:12.320 align:middle line:84% And so V1 just decides these locations. 00:14:12.320 --> 00:14:17.714 align:middle line:84% And then, you can think of V as being like V1 and V2. 00:14:17.714 --> 00:14:19.490 align:middle line:90% V1 doesn't look at his Oracle. 00:14:19.490 --> 00:14:22.560 align:middle line:84% He just looks as an input and using 00:14:22.560 --> 00:14:25.470 align:middle line:90% randomness chooses locations. 00:14:25.470 --> 00:14:32.520 align:middle line:84% And then, V2 kind of just given x, i1 up 00:14:32.520 --> 00:14:43.920 align:middle line:84% to i q and pi i1 up to pi i q decides to accept or reject. 00:14:43.920 --> 00:14:44.420 align:middle line:90% OK? 00:14:44.420 --> 00:14:47.240 align:middle line:84% So this is how you should think of the verifier. 00:14:47.240 --> 00:14:49.650 align:middle line:84% The verifier has access to the proof pi. 00:14:49.650 --> 00:14:51.505 align:middle line:90% But what he does, he does-- 00:14:51.505 --> 00:14:53.650 align:middle line:84% because a more general verifier will 00:14:53.650 --> 00:14:57.610 align:middle line:84% have x, decides on location, first location to the i1, 00:14:57.610 --> 00:14:59.500 align:middle line:84% Look at pi 1, then, hmm, interesting. 00:14:59.500 --> 00:15:00.230 align:middle line:90% OK. 00:15:00.230 --> 00:15:02.320 align:middle line:84% In that case, I want to see location i2. 00:15:02.320 --> 00:15:04.090 align:middle line:90% Hmm, I get pi i2. 00:15:04.090 --> 00:15:04.780 align:middle line:90% Interesting. 00:15:04.780 --> 00:15:06.730 align:middle line:84% Given pi i2, I want to see location-- that 00:15:06.730 --> 00:15:08.470 align:middle line:90% would be an adaptive verifier. 00:15:08.470 --> 00:15:11.870 align:middle line:84% But often, in the PCP literature, when we define PCP, 00:15:11.870 --> 00:15:15.250 align:middle line:84% we require the verifier to be nonadaptive. 00:15:15.250 --> 00:15:19.190 align:middle line:84% And this nonadaptivity is kind of a property 00:15:19.190 --> 00:15:20.440 align:middle line:90% that we like for applications. 00:15:20.440 --> 00:15:23.860 align:middle line:84% And we'll see that today, and an example for why. 00:15:23.860 --> 00:15:25.780 align:middle line:84% When we'll construct succinct arguments, 00:15:25.780 --> 00:15:27.770 align:middle line:84% we'll use the fact that it's nonadaptive. 00:15:27.770 --> 00:15:30.963 align:middle line:84% But let me just say, most PCPs, all PCP I know, are nonadaptive. 00:15:30.963 --> 00:15:31.880 align:middle line:90% Maybe there are other. 00:15:31.880 --> 00:15:33.460 align:middle line:90% Was that your question? 00:15:33.460 --> 00:15:34.000 align:middle line:90% Yeah. 00:15:34.000 --> 00:15:37.540 align:middle line:90% So there may exist. 00:15:37.540 --> 00:15:39.310 align:middle line:84% I didn't do a full literature search. 00:15:39.310 --> 00:15:43.700 align:middle line:84% But the PCPs that are the most common ones that we talk about 00:15:43.700 --> 00:15:44.760 align:middle line:90% are all nonadaptive. 00:15:44.760 --> 00:15:45.260 align:middle line:90% Yeah. 00:15:45.260 --> 00:15:47.252 align:middle line:84% AUDIENCE: The [? V's ?] know what capital N is. 00:15:47.252 --> 00:15:47.960 align:middle line:90% YAEL KALAI: Yeah. 00:15:47.960 --> 00:15:48.668 align:middle line:90% Yeah, yeah, yeah. 00:15:48.668 --> 00:15:50.130 align:middle line:90% So V, yes. 00:15:50.130 --> 00:15:50.630 align:middle line:90% Yeah. 00:15:50.630 --> 00:15:52.890 align:middle line:90% So very good question. 00:15:52.890 --> 00:15:55.440 align:middle line:90% Let me repeat for the video. 00:15:55.440 --> 00:15:59.190 align:middle line:84% So the question was, does V know what capital N is? 00:15:59.190 --> 00:16:00.510 align:middle line:90% So the answer is yes. 00:16:00.510 --> 00:16:04.890 align:middle line:90% And V knows the language. 00:16:04.890 --> 00:16:06.675 align:middle line:90% So he knows what small n is. 00:16:06.675 --> 00:16:07.550 align:middle line:90% Well, he got small n. 00:16:07.550 --> 00:16:08.480 align:middle line:90% He knows small n. 00:16:08.480 --> 00:16:14.000 align:middle line:84% The language has there is m So V gets small n. 00:16:14.000 --> 00:16:15.300 align:middle line:90% So he knows what n is. 00:16:15.300 --> 00:16:19.010 align:middle line:84% The language is associated with a witness size m of n. 00:16:19.010 --> 00:16:20.840 align:middle line:84% So he knows that, because he knows the n, 00:16:20.840 --> 00:16:22.370 align:middle line:90% so he knows the witness size. 00:16:22.370 --> 00:16:28.745 align:middle line:84% And the PCP itself is associated with N, which is, 00:16:28.745 --> 00:16:30.210 align:middle line:90% you can think of it this way. 00:16:30.210 --> 00:16:32.040 align:middle line:90% So the answer is yes. 00:16:32.040 --> 00:16:33.210 align:middle line:90% These are kind of fixed. 00:16:33.210 --> 00:16:36.200 align:middle line:84% These m and n are fixed parameters 00:16:36.200 --> 00:16:39.380 align:middle line:84% that are defined by the PCPs, and the prover knows them. 00:16:39.380 --> 00:16:41.130 align:middle line:84% The verifier, the prover, they all-- yeah. 00:16:41.130 --> 00:16:41.630 align:middle line:90% Yes. 00:16:41.630 --> 00:16:44.803 align:middle line:84% AUDIENCE: Do we gain or lose something with V adaptive. 00:16:44.803 --> 00:16:45.470 align:middle line:90% YAEL KALAI: Yes. 00:16:45.470 --> 00:16:45.990 align:middle line:90% Good, good, good. 00:16:45.990 --> 00:16:47.698 align:middle line:84% So the question is, do we lose something? 00:16:47.698 --> 00:16:50.360 align:middle line:90% And the answer is, we do. 00:16:50.360 --> 00:16:53.040 align:middle line:84% OK, so what do we lose and what do we gain is your question. 00:16:53.040 --> 00:16:55.380 align:middle line:90% What we lose is for application. 00:16:55.380 --> 00:16:57.230 align:middle line:90% So when we'll go to-- 00:16:57.230 --> 00:16:59.187 align:middle line:84% in the second part of today's class, 00:16:59.187 --> 00:17:01.020 align:middle line:84% we're going to construct succinct arguments, 00:17:01.020 --> 00:17:03.090 align:middle line:84% and we're going to construct them from PCPs. 00:17:03.090 --> 00:17:06.079 align:middle line:84% And you'll see that if our PCP is adaptive, 00:17:06.079 --> 00:17:07.920 align:middle line:90% this becomes a problem. 00:17:07.920 --> 00:17:08.930 align:middle line:90% So we do gain. 00:17:08.930 --> 00:17:10.430 align:middle line:84% Now, you're saying, what do we lose? 00:17:10.430 --> 00:17:11.013 align:middle line:90% So we do lose. 00:17:11.013 --> 00:17:12.722 align:middle line:84% Sorry, we do lose if we make it adaptive. 00:17:12.722 --> 00:17:14.730 align:middle line:84% Now, we're saying, but maybe we gain something. 00:17:14.730 --> 00:17:17.750 align:middle line:84% Maybe we construct PCPs that are much better 00:17:17.750 --> 00:17:19.440 align:middle line:90% if you make them adaptive. 00:17:19.440 --> 00:17:23.960 align:middle line:84% And I don't think so, but I'm not sure. 00:17:23.960 --> 00:17:27.030 align:middle line:84% Maybe one can actually argue that you don't gain anything, 00:17:27.030 --> 00:17:28.790 align:middle line:90% but I haven't thought about it. 00:17:28.790 --> 00:17:30.470 align:middle line:90% But it's not something that-- 00:17:30.470 --> 00:17:34.320 align:middle line:84% making it nonadaptive, for all we know, is not a price. 00:17:34.320 --> 00:17:37.090 align:middle line:90% It's just our PCPs? 00:17:37.090 --> 00:17:38.090 align:middle line:90% Happened to be that way. 00:17:38.090 --> 00:17:38.600 align:middle line:90% Yeah. 00:17:38.600 --> 00:17:40.892 align:middle line:84% AUDIENCE: Is there a version where you choose [? the ?] 00:17:40.892 --> 00:17:42.862 align:middle line:90% [? instance ?] [INAUDIBLE] 00:17:42.862 --> 00:17:44.070 align:middle line:90% YAEL KALAI: Good, good, good. 00:17:44.070 --> 00:17:45.180 align:middle line:90% Very, very good question. 00:17:45.180 --> 00:17:48.330 align:middle line:84% So I think maybe I misunderstood, 00:17:48.330 --> 00:17:50.660 align:middle line:84% but maybe your question was, is it clear 00:17:50.660 --> 00:17:53.100 align:middle line:90% that these have to depend on X? 00:17:53.100 --> 00:17:55.880 align:middle line:84% Can they even not depend on X. And the answer is yes. 00:17:55.880 --> 00:17:57.410 align:middle line:84% Actually, in the PCPs, we'll see, 00:17:57.410 --> 00:18:03.260 align:middle line:84% they don't depend on X. The PCPs we know, actually, these, they 00:18:03.260 --> 00:18:10.250 align:middle line:84% only depend on n and the instance size or begin. 00:18:10.250 --> 00:18:12.590 align:middle line:84% But they don't actually depend on the instance. 00:18:12.590 --> 00:18:15.167 align:middle line:84% And the PCP I'll construct today, you'll see that. 00:18:15.167 --> 00:18:16.250 align:middle line:90% So we'll get back to that. 00:18:16.250 --> 00:18:17.610 align:middle line:90% Really, really great questions. 00:18:17.610 --> 00:18:18.305 align:middle line:90% Yeah. 00:18:18.305 --> 00:18:20.070 align:middle line:84% AUDIENCE: High level, how does that work? 00:18:20.070 --> 00:18:22.293 align:middle line:84% Because you think that if the prover knows 00:18:22.293 --> 00:18:24.210 align:middle line:84% what indices you're going to query in advance, 00:18:24.210 --> 00:18:25.010 align:middle line:90% you could construct [INAUDIBLE]. 00:18:25.010 --> 00:18:26.070 align:middle line:84% YAEL KALAI: Of course, of course. 00:18:26.070 --> 00:18:26.600 align:middle line:90% Great. 00:18:26.600 --> 00:18:27.990 align:middle line:84% Wow, guys, you're really lifting me up. 00:18:27.990 --> 00:18:28.573 align:middle line:90% This is great. 00:18:28.573 --> 00:18:29.270 align:middle line:90% Thank you. 00:18:29.270 --> 00:18:30.960 align:middle line:90% Yeah, 100%. 00:18:30.960 --> 00:18:35.690 align:middle line:84% So what you're saying is, of course, if the prover knew 00:18:35.690 --> 00:18:38.610 align:middle line:84% the locations you're querying, he will cheat. 00:18:38.610 --> 00:18:41.557 align:middle line:84% The thing is, these locations are random. 00:18:41.557 --> 00:18:43.140 align:middle line:84% The prover doesn't know what they are. 00:18:43.140 --> 00:18:44.970 align:middle line:90% They just don't depend on x. 00:18:44.970 --> 00:18:45.790 align:middle line:90% AUDIENCE: Oh, OK. 00:18:45.790 --> 00:18:47.310 align:middle line:84% YAEL KALAI: But they come from a distribution. 00:18:47.310 --> 00:18:48.143 align:middle line:90% It's very important. 00:18:48.143 --> 00:18:50.147 align:middle line:84% If these were deterministic, there's no way. 00:18:50.147 --> 00:18:52.230 align:middle line:84% If you can do a PCP where these are deterministic, 00:18:52.230 --> 00:18:54.290 align:middle line:84% it's like you took NP and you just 00:18:54.290 --> 00:18:56.280 align:middle line:90% made it n times much smaller. 00:18:56.280 --> 00:18:59.000 align:middle line:84% Like, we don't believe that can happen. 00:18:59.000 --> 00:19:02.730 align:middle line:84% So no, there's no way we believe you 00:19:02.730 --> 00:19:07.620 align:middle line:84% can construct PCPs for which the query distribution is 00:19:07.620 --> 00:19:08.350 align:middle line:90% deterministic. 00:19:08.350 --> 00:19:09.310 align:middle line:90% It's just fixed. 00:19:09.310 --> 00:19:11.230 align:middle line:84% This has to come from a distribution. 00:19:11.230 --> 00:19:14.070 align:middle line:84% But the question is, does this distribution depend on x, 00:19:14.070 --> 00:19:16.810 align:middle line:84% or does it only depend on the parameter n? 00:19:16.810 --> 00:19:19.330 align:middle line:84% And in what we'll see, it actually only depends on n. 00:19:19.330 --> 00:19:20.430 align:middle line:90% It doesn't depend on x. 00:19:20.430 --> 00:19:22.805 align:middle line:84% So that's what we'll see in a minute. 00:19:22.805 --> 00:19:25.460 align:middle line:90% 00:19:25.460 --> 00:19:26.460 align:middle line:90% Great question, guys. 00:19:26.460 --> 00:19:28.315 align:middle line:90% Any more questions before we-- 00:19:28.315 --> 00:19:32.950 align:middle line:90% 00:19:32.950 --> 00:19:33.655 align:middle line:90% yeah. 00:19:33.655 --> 00:19:36.560 align:middle line:84% AUDIENCE: So [INAUDIBLE] in V1 and V2, 00:19:36.560 --> 00:19:38.965 align:middle line:84% or do we really only care about the [INAUDIBLE]? 00:19:38.965 --> 00:19:39.840 align:middle line:90% YAEL KALAI: OK, good. 00:19:39.840 --> 00:19:43.640 align:middle line:84% So actually, usually V1 is randomized 00:19:43.640 --> 00:19:45.710 align:middle line:90% and V2 is deterministic. 00:19:45.710 --> 00:19:48.060 align:middle line:84% So you can think of it that way, that V1 is randomized, 00:19:48.060 --> 00:19:51.480 align:middle line:90% V2 is deterministic. 00:19:51.480 --> 00:19:51.980 align:middle line:90% OK. 00:19:51.980 --> 00:19:55.050 align:middle line:90% 00:19:55.050 --> 00:19:55.720 align:middle line:90% Great. 00:19:55.720 --> 00:19:58.053 align:middle line:84% So now, let me tell you what we know 00:19:58.053 --> 00:19:59.470 align:middle line:84% and what we're going to construct. 00:19:59.470 --> 00:20:03.080 align:middle line:84% So here's what we're going to prove today. 00:20:03.080 --> 00:20:06.140 align:middle line:84% Here is a theorem that we're going to prove, 00:20:06.140 --> 00:20:12.400 align:middle line:84% that PCP with a, let's say, completeness 1-- 00:20:12.400 --> 00:20:13.513 align:middle line:90% I'll put some as 1/2. 00:20:13.513 --> 00:20:16.180 align:middle line:84% We can get smaller, any constant smaller, but I'll just put 1/2, 00:20:16.180 --> 00:20:18.950 align:middle line:84% because by repetition it doesn't really matter-- 00:20:18.950 --> 00:20:23.930 align:middle line:84% you can get a PCP where the query complexity is-- 00:20:23.930 --> 00:20:29.320 align:middle line:84% so, OK, we can get a PCP with poly log n query 00:20:29.320 --> 00:20:33.525 align:middle line:90% complexity and polylog n-- 00:20:33.525 --> 00:20:37.680 align:middle line:90% 00:20:37.680 --> 00:20:40.890 align:middle line:84% sorry, poly log n randomness complexity and query complexity 00:20:40.890 --> 00:20:43.448 align:middle line:90% for all of NP. 00:20:43.448 --> 00:20:44.990 align:middle line:84% That's what we're going to see today. 00:20:44.990 --> 00:20:49.190 align:middle line:84% So we're going to see how for any NP language, 00:20:49.190 --> 00:20:52.750 align:middle line:84% we can construct a PCP where the verifier, the amount 00:20:52.750 --> 00:20:56.260 align:middle line:84% of randomness he uses, is polylog n bits of randomness 00:20:56.260 --> 00:20:58.100 align:middle line:90% and polylog n queries. 00:20:58.100 --> 00:21:00.950 align:middle line:84% And then, we get completeness 1 and soundness 1/2. 00:21:00.950 --> 00:21:02.140 align:middle line:90% Yeah, Tina. 00:21:02.140 --> 00:21:07.020 align:middle line:84% AUDIENCE: So [INAUDIBLE] this is not the usual [INAUDIBLE]. 00:21:07.020 --> 00:21:08.357 align:middle line:90% Usually, you want proof-- 00:21:08.357 --> 00:21:10.690 align:middle line:84% you want the randomness [? complexity to be ?] [? log ?] 00:21:10.690 --> 00:21:11.927 align:middle line:90% [INAUDIBLE] 00:21:11.927 --> 00:21:13.260 align:middle line:90% YAEL KALAI: Right, right, right. 00:21:13.260 --> 00:21:13.968 align:middle line:90% Yeah, yeah, yeah. 00:21:13.968 --> 00:21:14.670 align:middle line:90% So you're right. 00:21:14.670 --> 00:21:18.210 align:middle line:90% So often-- OK, you're right. 00:21:18.210 --> 00:21:19.970 align:middle line:90% The way I wrote it here-- 00:21:19.970 --> 00:21:23.030 align:middle line:84% so OK, why do people care about randomness complexity 00:21:23.030 --> 00:21:23.747 align:middle line:90% one can say. 00:21:23.747 --> 00:21:25.580 align:middle line:84% Well, who cares about the random complexity? 00:21:25.580 --> 00:21:28.790 align:middle line:84% And usually, the way I define PCP, and that's 00:21:28.790 --> 00:21:30.480 align:middle line:84% why I said as a complexity theory, 00:21:30.480 --> 00:21:35.600 align:middle line:84% this is how it's defined, if the verifier has only log n bits 00:21:35.600 --> 00:21:38.520 align:middle line:84% or order log n bits of randomness, 00:21:38.520 --> 00:21:42.770 align:middle line:84% then it means that the PCP is only poly n size. 00:21:42.770 --> 00:21:46.532 align:middle line:84% Because, look, go for all the log n bits of random, 00:21:46.532 --> 00:21:47.490 align:middle line:90% there's only n of them. 00:21:47.490 --> 00:21:52.080 align:middle line:84% So that's as much as you can query. 00:21:52.080 --> 00:21:53.990 align:middle line:84% So that means the PCP is upon it. and that's 00:21:53.990 --> 00:21:55.640 align:middle line:90% what we care about. 00:21:55.640 --> 00:21:56.240 align:middle line:90% OK. 00:21:56.240 --> 00:21:58.400 align:middle line:84% For me, I'm going to care about-- 00:21:58.400 --> 00:22:00.715 align:middle line:84% actually, for me, I'm going to add a requirement. 00:22:00.715 --> 00:22:02.090 align:middle line:84% Actually, I didn't write it here, 00:22:02.090 --> 00:22:03.465 align:middle line:84% because it's usually not defined. 00:22:03.465 --> 00:22:08.000 align:middle line:84% But I can add a requirement that says-- 00:22:08.000 --> 00:22:09.630 align:middle line:90% OK, I'll add it here tiny. 00:22:09.630 --> 00:22:13.290 align:middle line:84% This is a requirement that we add in cryptography. 00:22:13.290 --> 00:22:18.030 align:middle line:84% Often, what I'm writing now is not added in the definitions. 00:22:18.030 --> 00:22:21.530 align:middle line:84% But let me write another cryptography, another that given 00:22:21.530 --> 00:22:29.530 align:middle line:90% for every x in l and witness-- 00:22:29.530 --> 00:22:32.390 align:middle line:90% 00:22:32.390 --> 00:22:35.840 align:middle line:90% if it has a witness. 00:22:35.840 --> 00:22:39.230 align:middle line:84% W. OK, so suppose this is a language in n time, 00:22:39.230 --> 00:22:42.120 align:middle line:84% I don't know NP or N time T-- so it has some witness-- 00:22:42.120 --> 00:22:45.080 align:middle line:84% I want it to be the case that, given x and w, 00:22:45.080 --> 00:22:49.430 align:middle line:90% you can efficiently compute pi. 00:22:49.430 --> 00:22:54.450 align:middle line:84% So not only there exists pi of poly n size, 00:22:54.450 --> 00:22:56.780 align:middle line:84% you can actually efficiently compute it. 00:22:56.780 --> 00:22:59.258 align:middle line:84% And because I require efficient computing, 00:22:59.258 --> 00:23:00.800 align:middle line:84% I actually don't care anymore so much 00:23:00.800 --> 00:23:05.532 align:middle line:84% about the randomness, the number of randomness bits. 00:23:05.532 --> 00:23:06.990 align:middle line:84% But yeah, that's a very good point. 00:23:06.990 --> 00:23:07.530 align:middle line:90% Thank you. 00:23:07.530 --> 00:23:08.905 align:middle line:84% Guys, thank you for the question. 00:23:08.905 --> 00:23:11.090 align:middle line:90% This is great. 00:23:11.090 --> 00:23:13.410 align:middle line:84% OK, so that's what I'm going to prove. 00:23:13.410 --> 00:23:16.160 align:middle line:84% Even though, let me just mention, what is known 00:23:16.160 --> 00:23:21.655 align:middle line:84% is you can make this order log n, and you can make this 3. 00:23:21.655 --> 00:23:24.360 align:middle line:90% 00:23:24.360 --> 00:23:25.620 align:middle line:90% So it's really remarkable. 00:23:25.620 --> 00:23:29.630 align:middle line:84% If you think about it, wow, you can take any proof. 00:23:29.630 --> 00:23:32.410 align:middle line:84% So you know how, I don't know, take Fermat's last theorem. 00:23:32.410 --> 00:23:36.225 align:middle line:84% Take the hardest proof that we in mathematics. 00:23:36.225 --> 00:23:40.030 align:middle line:84% One can write them in a probabilistically checkable way. 00:23:40.030 --> 00:23:42.940 align:middle line:84% They can just take 3 bits and verify. 00:23:42.940 --> 00:23:44.830 align:middle line:84% And if you're not happy with probability 1/2, 00:23:44.830 --> 00:23:46.970 align:middle line:84% repeat it as many times as you want. 00:23:46.970 --> 00:23:50.590 align:middle line:84% You want to be sure that he can cheat with probability only 1/2 00:23:50.590 --> 00:23:52.160 align:middle line:90% 2 to the 500? 00:23:52.160 --> 00:23:54.172 align:middle line:90% Repeat it 500 times. 00:23:54.172 --> 00:23:55.880 align:middle line:84% And each one is like a very simple check. 00:23:55.880 --> 00:23:57.620 align:middle line:90% It depends on 3 bits. 00:23:57.620 --> 00:23:59.670 align:middle line:90% So it's really remarkable. 00:23:59.670 --> 00:24:02.550 align:middle line:90% 00:24:02.550 --> 00:24:03.808 align:middle line:90% AUDIENCE: Never mind, sorry. 00:24:03.808 --> 00:24:04.308 align:middle line:90% [? 00:24:04.308 --> 00:24:06.130 align:middle line:84% N choose 3 ?] probability is way too big, 00:24:06.130 --> 00:24:09.240 align:middle line:84% but I guess it doesn't really matter to have all 00:24:09.240 --> 00:24:09.880 align:middle line:90% the possible-- 00:24:09.880 --> 00:24:12.850 align:middle line:84% YAEL KALAI: Oh, you're saying it's too big for theory, 00:24:12.850 --> 00:24:13.840 align:middle line:90% for practice. 00:24:13.840 --> 00:24:15.990 align:middle line:84% Yeah, but we're still in theory land. 00:24:15.990 --> 00:24:20.620 align:middle line:84% Yeah, in practice, these PCP, you want them to be linear. 00:24:20.620 --> 00:24:22.420 align:middle line:84% That's the ideal if they're quasilinear. 00:24:22.420 --> 00:24:24.503 align:middle line:84% Even if they're quadratic, people don't like them. 00:24:24.503 --> 00:24:27.550 align:middle line:84% You really want linear, quasilinear PCPs for practice. 00:24:27.550 --> 00:24:29.470 align:middle line:90% But for here, poly is fantastic. 00:24:29.470 --> 00:24:34.530 align:middle line:84% We're not we're-- let us stay in the cloud a little bit. 00:24:34.530 --> 00:24:36.162 align:middle line:90% OK. 00:24:36.162 --> 00:24:40.500 align:middle line:90% So OK, let's construct this. 00:24:40.500 --> 00:24:41.850 align:middle line:90% Ready? 00:24:41.850 --> 00:24:43.265 align:middle line:90% OK. 00:24:43.265 --> 00:24:44.640 align:middle line:84% So we have the 3, but we're going 00:24:44.640 --> 00:24:47.440 align:middle line:84% to construct for the poly log poly log. 00:24:47.440 --> 00:24:51.950 align:middle line:84% And actually, here's what's amazing. 00:24:51.950 --> 00:24:54.560 align:middle line:84% You actually already know how to construct the PCP. 00:24:54.560 --> 00:24:57.350 align:middle line:90% You just don't know that. 00:24:57.350 --> 00:24:59.150 align:middle line:90% And how do you construct a PCP? 00:24:59.150 --> 00:25:02.310 align:middle line:84% It's really only the GKR protocol. 00:25:02.310 --> 00:25:03.470 align:middle line:90% That's it. 00:25:03.470 --> 00:25:06.800 align:middle line:84% So you can unfold GKR, and I'm going to show you 00:25:06.800 --> 00:25:09.260 align:middle line:90% exactly how to make it a PCP. 00:25:09.260 --> 00:25:12.410 align:middle line:84% So to do that, but before I now recall 00:25:12.410 --> 00:25:17.190 align:middle line:84% GKR in a second on that board, to do that, let's first-- 00:25:17.190 --> 00:25:19.280 align:middle line:84% so I want to say any language has a PCP-- 00:25:19.280 --> 00:25:25.670 align:middle line:90% let's focus on 3SAT. 00:25:25.670 --> 00:25:30.340 align:middle line:90% 00:25:30.340 --> 00:25:33.110 align:middle line:84% OK, so 3SAT is is an NP-complete language. 00:25:33.110 --> 00:25:34.720 align:middle line:84% Let's just construct a PCP for 3SAT. 00:25:34.720 --> 00:25:35.470 align:middle line:90% Sets. 00:25:35.470 --> 00:25:38.350 align:middle line:84% And what's nice about 3SAT is that-- 00:25:38.350 --> 00:25:40.550 align:middle line:84% I mean, any NP language you can convert to 3SAT, 00:25:40.550 --> 00:25:42.790 align:middle line:84% so it's nice in any NP language-- 00:25:42.790 --> 00:25:47.140 align:middle line:84% you have a circuit, a verification circuit-- 00:25:47.140 --> 00:25:52.270 align:middle line:84% so a circuit verifying, you can think of it, 00:25:52.270 --> 00:25:55.600 align:middle line:84% given w verifying that it's a valid witness-- 00:25:55.600 --> 00:25:57.640 align:middle line:90% of very small depth. 00:25:57.640 --> 00:25:59.093 align:middle line:90% OK, polylog n depth. 00:25:59.093 --> 00:26:00.010 align:middle line:90% And this is important. 00:26:00.010 --> 00:26:02.590 align:middle line:84% Because if you remember the GKR protocol, which 00:26:02.590 --> 00:26:06.370 align:middle line:84% we're going to use to construct this PCP, 00:26:06.370 --> 00:26:10.410 align:middle line:84% kind of the communication complexity grows with the depth. 00:26:10.410 --> 00:26:13.510 align:middle line:84% So we want the depth of the circuit to be small. 00:26:13.510 --> 00:26:16.900 align:middle line:84% But any NP language you can convert into a 3SAT, 00:26:16.900 --> 00:26:18.430 align:middle line:90% and 3SAT has-- 00:26:18.430 --> 00:26:21.550 align:middle line:84% actually, the depth of 3SAT is like actually only 2. 00:26:21.550 --> 00:26:25.890 align:middle line:84% But you need to do, little or's and then one big and. 00:26:25.890 --> 00:26:28.750 align:middle line:84% But if you remember, in GKR we wanted fend in 2. 00:26:28.750 --> 00:26:31.050 align:middle line:84% So once you have fended in 2, it's like order log. 00:26:31.050 --> 00:26:33.020 align:middle line:90% OK, so this is depth. 00:26:33.020 --> 00:26:37.900 align:middle line:84% You can think of it as being log n or I'm OK with poly log n. 00:26:37.900 --> 00:26:40.540 align:middle line:90% It doesn't matter. 00:26:40.540 --> 00:26:42.460 align:middle line:90% The point is, it's small. 00:26:42.460 --> 00:26:45.370 align:middle line:84% And the reason why I write also polylog 00:26:45.370 --> 00:26:47.480 align:middle line:90% is because it's actually log. 00:26:47.480 --> 00:26:53.260 align:middle line:90% However, this circuit is also-- 00:26:53.260 --> 00:26:56.650 align:middle line:84% and this I'm not going to get into, but it's logspace uniform. 00:26:56.650 --> 00:26:59.020 align:middle line:84% And now, you can consider the circuit. 00:26:59.020 --> 00:27:02.120 align:middle line:84% Change it a little bit the way Rachel taught you two weeks ago. 00:27:02.120 --> 00:27:03.740 align:middle line:90% If you don't remember, it's OK. 00:27:03.740 --> 00:27:05.320 align:middle line:90% You can take it as a black box. 00:27:05.320 --> 00:27:08.290 align:middle line:84% You can assume that the circuit, by kind looking 00:27:08.290 --> 00:27:11.020 align:middle line:84% at a universal version of it, that it 00:27:11.020 --> 00:27:19.310 align:middle line:84% has the gates add i and mult i are efficiently computable. 00:27:19.310 --> 00:27:22.660 align:middle line:90% 00:27:22.660 --> 00:27:23.840 align:middle line:90% And that's what we'll need. 00:27:23.840 --> 00:27:28.970 align:middle line:84% So if you don't remember things from two weeks ago, it's OK. 00:27:28.970 --> 00:27:31.490 align:middle line:84% I'll remind you what add i and mult is in a second. 00:27:31.490 --> 00:27:37.880 align:middle line:84% But you take any 3SAT, you can convert it into 3-CNF. 00:27:37.880 --> 00:27:40.930 align:middle line:84% So now, given a witness, you just check that it verifies. 00:27:40.930 --> 00:27:41.770 align:middle line:90% Hi. 00:27:41.770 --> 00:27:42.890 align:middle line:90% Hello. 00:27:42.890 --> 00:27:43.480 align:middle line:90% Hey. 00:27:43.480 --> 00:27:45.820 align:middle line:90% Wow, all my kids coming in. 00:27:45.820 --> 00:27:56.770 align:middle line:90% 00:27:56.770 --> 00:27:57.270 align:middle line:90% OK. 00:27:57.270 --> 00:28:03.160 align:middle line:84% So we're talking about how to construct PCPs from GKR 00:28:03.160 --> 00:28:06.040 align:middle line:90% right now. 00:28:06.040 --> 00:28:10.000 align:middle line:90% So what we're proving is that-- 00:28:10.000 --> 00:28:12.490 align:middle line:84% we're going to show how you can take any NP language-- 00:28:12.490 --> 00:28:15.100 align:middle line:84% in particular, we're focusing on three 3SAT-- 00:28:15.100 --> 00:28:20.140 align:middle line:84% and we're going to show how you can convert 3SAT into a PCP 00:28:20.140 --> 00:28:23.800 align:middle line:84% where the query complexity is polylog n. 00:28:23.800 --> 00:28:25.750 align:middle line:84% So converting to PCP, the verifier 00:28:25.750 --> 00:28:29.280 align:middle line:84% needs to query only polylog n locations. 00:28:29.280 --> 00:28:31.370 align:middle line:84% We know you can go all the way down to 3, 00:28:31.370 --> 00:28:34.100 align:middle line:84% but today we're going to solve polylog. 00:28:34.100 --> 00:28:35.880 align:middle line:84% This is the randomness complexity. 00:28:35.880 --> 00:28:37.520 align:middle line:90% This is the query complexity. 00:28:37.520 --> 00:28:40.520 align:middle line:84% We're focusing on completeness 1, soundness 1/2. 00:28:40.520 --> 00:28:41.190 align:middle line:90% OK. 00:28:41.190 --> 00:28:43.820 align:middle line:84% So we're going to now construct a PCP. 00:28:43.820 --> 00:28:47.720 align:middle line:84% And before we construct, the PCP essentially uses GKR. 00:28:47.720 --> 00:28:50.060 align:middle line:84% So let me first, on this board, remind you 00:28:50.060 --> 00:28:52.340 align:middle line:84% quickly what GKR looks like, because we're going 00:28:52.340 --> 00:28:54.230 align:middle line:90% to use it to construct the PCP. 00:28:54.230 --> 00:28:55.340 align:middle line:90% OK. 00:28:55.340 --> 00:28:56.935 align:middle line:90% Cameraman, it's OK to move? 00:28:56.935 --> 00:28:57.960 align:middle line:90% CREW: Yeah, no problem. 00:28:57.960 --> 00:28:59.630 align:middle line:90% YAEL KALAI: OK. 00:28:59.630 --> 00:29:00.300 align:middle line:90% Good. 00:29:00.300 --> 00:29:02.190 align:middle line:90% So let's just recall the GKR. 00:29:02.190 --> 00:29:03.120 align:middle line:90% How does it work? 00:29:03.120 --> 00:29:05.490 align:middle line:90% We have a circuit. 00:29:05.490 --> 00:29:07.110 align:middle line:90% There's an input w. 00:29:07.110 --> 00:29:11.680 align:middle line:84% We're going to think of w here as the satisfying assignment. 00:29:11.680 --> 00:29:12.180 align:middle line:90% OK? 00:29:12.180 --> 00:29:15.225 align:middle line:84% Remembering, the GKR, we assume the verifier has w in his hand, 00:29:15.225 --> 00:29:16.440 align:middle line:90% the input in his hand. 00:29:16.440 --> 00:29:17.250 align:middle line:90% Here, he doesn't. 00:29:17.250 --> 00:29:20.410 align:middle line:84% W is going to be the witness for the satisfying assignment. 00:29:20.410 --> 00:29:21.550 align:middle line:90% But that's OK. 00:29:21.550 --> 00:29:26.080 align:middle line:84% Now, I'm going to construct the PCP proof. 00:29:26.080 --> 00:29:26.580 align:middle line:90% OK? 00:29:26.580 --> 00:29:30.960 align:middle line:84% I have my witness, my satisfying assignment. 00:29:30.960 --> 00:29:32.970 align:middle line:84% I'm going to construct a probabilistic check. 00:29:32.970 --> 00:29:35.350 align:middle line:84% I'm going to convert w into a PCP, 00:29:35.350 --> 00:29:37.530 align:middle line:84% into a probabilistically checkable proof. 00:29:37.530 --> 00:29:39.300 align:middle line:90% OK, here's how I do it. 00:29:39.300 --> 00:29:44.077 align:middle line:84% I look at the circuit that checks that w-- 00:29:44.077 --> 00:29:46.410 align:middle line:84% actually, if you want to think of it as a completely new 00:29:46.410 --> 00:29:48.035 align:middle line:84% for me you can think of having x and w. 00:29:48.035 --> 00:29:52.860 align:middle line:84% So x and w, and it checks that kind of phi-- 00:29:52.860 --> 00:30:01.540 align:middle line:84% sorry-- x, which is phi, and it checks that phi of w is 1. 00:30:01.540 --> 00:30:02.040 align:middle line:90% OK? 00:30:02.040 --> 00:30:07.260 align:middle line:84% This is logspace uniform circuit. 00:30:07.260 --> 00:30:08.600 align:middle line:90% OK, now what do I do? 00:30:08.600 --> 00:30:10.030 align:middle line:90% So here's me. 00:30:10.030 --> 00:30:12.060 align:middle line:90% I know w. 00:30:12.060 --> 00:30:14.045 align:middle line:90% We both know the 3SAT formula. 00:30:14.045 --> 00:30:17.760 align:middle line:90% 00:30:17.760 --> 00:30:22.590 align:middle line:84% And we assume that the circuit has addition gates 00:30:22.590 --> 00:30:25.900 align:middle line:90% and multiplication gates. 00:30:25.900 --> 00:30:31.290 align:middle line:84% What I do, for every layer, I compute the values of the layer. 00:30:31.290 --> 00:30:31.790 align:middle line:90% OK? 00:30:31.790 --> 00:30:33.110 align:middle line:90% So I compute for every layer. 00:30:33.110 --> 00:30:35.410 align:middle line:90% Remember, I have V i. 00:30:35.410 --> 00:30:38.705 align:middle line:84% I assume every layer, let's say, the same size 00:30:38.705 --> 00:30:39.830 align:middle line:90% without loss of generality. 00:30:39.830 --> 00:30:40.570 align:middle line:90% We set size s. 00:30:40.570 --> 00:30:41.500 align:middle line:90% We called it s. 00:30:41.500 --> 00:30:46.120 align:middle line:90% So each layer has s wires. 00:30:46.120 --> 00:30:50.920 align:middle line:90% And we compute all these wires. 00:30:50.920 --> 00:30:53.590 align:middle line:84% For every layer i, we think of these wires 00:30:53.590 --> 00:30:56.180 align:middle line:90% as going from H to m to 0 1. 00:30:56.180 --> 00:31:01.820 align:middle line:84% So H is some set and, we assume that H to the m is s. 00:31:01.820 --> 00:31:02.320 align:middle line:90% OK? 00:31:02.320 --> 00:31:09.970 align:middle line:84% So we just encode these s wires in a m-dimensional cube of size 00:31:09.970 --> 00:31:14.110 align:middle line:84% H, and we just write all the values of the wires. 00:31:14.110 --> 00:31:14.610 align:middle line:90% OK? 00:31:14.610 --> 00:31:19.410 align:middle line:84% And then, what we do, we look at the extension V tilde which 00:31:19.410 --> 00:31:23.370 align:middle line:84% extends to a field F to the m to F. 00:31:23.370 --> 00:31:26.010 align:middle line:84% And this is kind of the low-degree extension. 00:31:26.010 --> 00:31:30.150 align:middle line:84% So we take any F that contains the set H, 00:31:30.150 --> 00:31:34.000 align:middle line:84% and we extend via the low-degree extension. 00:31:34.000 --> 00:31:36.490 align:middle line:90% So these are things we covered. 00:31:36.490 --> 00:31:39.960 align:middle line:84% Now is the first time-- you remember, when we talked GKR, 00:31:39.960 --> 00:31:44.280 align:middle line:84% I told you, OK, why not do 0 1 to the m? 00:31:44.280 --> 00:31:45.900 align:middle line:84% 0 to the log n, it's much natural 00:31:45.900 --> 00:31:48.540 align:middle line:84% to think of binary representation of s 00:31:48.540 --> 00:31:51.900 align:middle line:84% as opposed to this H to the m which is what H. And I told you, 00:31:51.900 --> 00:31:53.410 align:middle line:90% oh, often we like parameters. 00:31:53.410 --> 00:31:57.930 align:middle line:90% We like to think of H as log n-- 00:31:57.930 --> 00:32:04.000 align:middle line:84% sorry, log n, and m is log n over log log n. 00:32:04.000 --> 00:32:08.630 align:middle line:90% 00:32:08.630 --> 00:32:12.950 align:middle line:84% And if you'll see, H to the m just becomes n. 00:32:12.950 --> 00:32:19.140 align:middle line:84% Because you can think of H to the m is log n to the n, 00:32:19.140 --> 00:32:25.100 align:middle line:84% but log n is just to log log n to the n 00:32:25.100 --> 00:32:29.390 align:middle line:84% And the log log n cancels out, so you have 2 to the log n. 00:32:29.390 --> 00:32:34.130 align:middle line:84% So you have-- oh I did everything as s. 00:32:34.130 --> 00:32:35.600 align:middle line:90% Sorry. 00:32:35.600 --> 00:32:38.940 align:middle line:90% S. The n here is s. 00:32:38.940 --> 00:32:45.767 align:middle line:90% S. S. S. 00:32:45.767 --> 00:32:47.530 align:middle line:90% So you have s. 00:32:47.530 --> 00:32:50.860 align:middle line:84% Now, remember, I told you, oh, we'll 00:32:50.860 --> 00:32:53.690 align:middle line:84% need these set of parameters as opposed to the 0 1. 00:32:53.690 --> 00:32:56.510 align:middle line:84% It's natural to think of H as 0 1, and m is log n. 00:32:56.510 --> 00:32:58.180 align:middle line:90% That's much more natural. 00:32:58.180 --> 00:33:00.890 align:middle line:84% We're used, as computer scientists, to think in binary. 00:33:00.890 --> 00:33:02.840 align:middle line:90% Now, we're thinking of log s. 00:33:02.840 --> 00:33:05.060 align:middle line:84% It's like, really, how annoying can you be? 00:33:05.060 --> 00:33:07.220 align:middle line:90% And the reason is it's for this. 00:33:07.220 --> 00:33:08.980 align:middle line:90% Now, we need it. 00:33:08.980 --> 00:33:09.940 align:middle line:90% Why? 00:33:09.940 --> 00:33:20.340 align:middle line:84% Now, we take f that is going to be the extension of size poly 00:33:20.340 --> 00:33:21.170 align:middle line:90% log s. 00:33:21.170 --> 00:33:23.885 align:middle line:90% 00:33:23.885 --> 00:33:24.385 align:middle line:90% OK? 00:33:24.385 --> 00:33:26.480 align:middle line:84% And we'll see the poly will need to be big enough. 00:33:26.480 --> 00:33:27.813 align:middle line:90% We'll talk about it in a second. 00:33:27.813 --> 00:33:30.650 align:middle line:84% But the field, we don't want more than poly log s. 00:33:30.650 --> 00:33:39.030 align:middle line:84% And the reason is we want F to the m to be poly s. 00:33:39.030 --> 00:33:42.420 align:middle line:90% So we know H to the m is s. 00:33:42.420 --> 00:33:48.030 align:middle line:84% If F is only poly bigger, than we have this is poly s. 00:33:48.030 --> 00:33:50.670 align:middle line:90% 00:33:50.670 --> 00:33:52.440 align:middle line:90% And that's important for us. 00:33:52.440 --> 00:33:57.860 align:middle line:84% OK, note, if H was just 0 1, so the size of H was 2, 00:33:57.860 --> 00:34:02.310 align:middle line:84% we couldn't keep F poly and we couldn't keep F constant. 00:34:02.310 --> 00:34:04.240 align:middle line:84% You'll see, F will need to grow with m. 00:34:04.240 --> 00:34:07.580 align:middle line:84% And so, for soundness, m F will need 00:34:07.580 --> 00:34:13.949 align:middle line:84% to be bigger than m times H. Actually, 00:34:13.949 --> 00:34:15.420 align:middle line:84% there's also d that will come in. 00:34:15.420 --> 00:34:18.230 align:middle line:90% It's significantly bigger. 00:34:18.230 --> 00:34:21.199 align:middle line:84% So if we take H to be 2, we'll need 00:34:21.199 --> 00:34:23.239 align:middle line:90% to take F to be at least log n. 00:34:23.239 --> 00:34:26.310 align:middle line:84% And then, we'll have F to the m is log n to the power of log n. 00:34:26.310 --> 00:34:29.150 align:middle line:90% That's super poly. 00:34:29.150 --> 00:34:32.100 align:middle line:84% And I want F to the m to be poly. 00:34:32.100 --> 00:34:32.739 align:middle line:90% OK. 00:34:32.739 --> 00:34:34.120 align:middle line:90% So we do this. 00:34:34.120 --> 00:34:35.864 align:middle line:90% So now, what is the PCP? 00:34:35.864 --> 00:34:38.730 align:middle line:90% 00:34:38.730 --> 00:34:40.840 align:middle line:84% Actually, I'll right there the PCP. 00:34:40.840 --> 00:34:44.260 align:middle line:84% But now, let's just finish recalling the GKR. 00:34:44.260 --> 00:34:46.530 align:middle line:84% So what does the verifier do in the GKR, 00:34:46.530 --> 00:34:47.730 align:middle line:90% the prover do in the GKR? 00:34:47.730 --> 00:34:50.580 align:middle line:84% He computes all these low-degree extensions. 00:34:50.580 --> 00:34:56.280 align:middle line:84% And then, the GKR consists of d phases going from the output 00:34:56.280 --> 00:34:59.490 align:middle line:84% layer to the input layer, where in each phase 00:34:59.490 --> 00:35:04.050 align:middle line:84% we run two sumcheck protocols in parallel where the verifier uses 00:35:04.050 --> 00:35:05.760 align:middle line:90% the same randomness. 00:35:05.760 --> 00:35:08.190 align:middle line:84% And what the sumcheck protocol does 00:35:08.190 --> 00:35:13.080 align:middle line:84% is it reduces from checking two values here 00:35:13.080 --> 00:35:17.290 align:middle line:84% to reducing checking two values in the layer below. 00:35:17.290 --> 00:35:20.810 align:middle line:84% And we go kind of from checking and until we get to the input, 00:35:20.810 --> 00:35:22.810 align:middle line:84% and the input the verifier can check on his own. 00:35:22.810 --> 00:35:24.570 align:middle line:90% That's the idea. 00:35:24.570 --> 00:35:26.110 align:middle line:90% OK? 00:35:26.110 --> 00:35:26.610 align:middle line:90% OK. 00:35:26.610 --> 00:35:29.380 align:middle line:84% Now, let's just recall, in a sumcheck protocol here, 00:35:29.380 --> 00:35:33.280 align:middle line:84% each sumcheck protocol, if you remember-- 00:35:33.280 --> 00:35:37.200 align:middle line:84% maybe you don't, the details are not so important right now-- 00:35:37.200 --> 00:35:40.860 align:middle line:84% you go from V i in the extension, which 00:35:40.860 --> 00:35:45.150 align:middle line:84% is, let's say, V i tilde of some z, 00:35:45.150 --> 00:35:54.270 align:middle line:84% and you write it as this is kind of sum of points in H to the m, 00:35:54.270 --> 00:36:00.075 align:middle line:84% because that's the definition of extension, times some chi P 00:36:00.075 --> 00:36:03.787 align:middle line:84% z-- this is the function that checks equality. 00:36:03.787 --> 00:36:04.870 align:middle line:90% Again, it's not important. 00:36:04.870 --> 00:36:07.860 align:middle line:84% But what's important to me to show is that-- 00:36:07.860 --> 00:36:13.650 align:middle line:84% and then you do sum over P w1 w2 in H of m, 00:36:13.650 --> 00:36:16.755 align:middle line:90% and you convert V i to either-- 00:36:16.755 --> 00:36:19.902 align:middle line:90% 00:36:19.902 --> 00:36:22.110 align:middle line:84% if this is a plus gate, you convert it 00:36:22.110 --> 00:36:27.212 align:middle line:84% to the plus of the wires below with some duplication 00:36:27.212 --> 00:36:28.420 align:middle line:90% You check the multiplication. 00:36:28.420 --> 00:36:32.670 align:middle line:84% So, in other words, what this is, 00:36:32.670 --> 00:36:34.660 align:middle line:90% or I should say what this is-- 00:36:34.660 --> 00:36:35.790 align:middle line:90% let me just open this. 00:36:35.790 --> 00:36:37.260 align:middle line:90% What is V i P? 00:36:37.260 --> 00:36:46.270 align:middle line:90% It's if it's an add P w1 w2-- 00:36:46.270 --> 00:36:51.480 align:middle line:84% so if point P is this just the addition of the two wires below, 00:36:51.480 --> 00:37:00.840 align:middle line:84% then you replace P with w1 with V i minus 1 w1 plus V i 00:37:00.840 --> 00:37:02.194 align:middle line:90% minus 1 w2. 00:37:02.194 --> 00:37:09.960 align:middle line:90% 00:37:09.960 --> 00:37:17.890 align:middle line:84% And plus, if it was not an add gate, if it's a mult gate, 00:37:17.890 --> 00:37:21.850 align:middle line:84% then you replace it with the multiplication of V 00:37:21.850 --> 00:37:26.350 align:middle line:84% i minus 1 w1 times V i minus 1 w2. 00:37:26.350 --> 00:37:29.350 align:middle line:90% So the idea was-- 00:37:29.350 --> 00:37:34.490 align:middle line:90% and all this is times this chi. 00:37:34.490 --> 00:37:39.020 align:middle line:90% 00:37:39.020 --> 00:37:43.950 align:middle line:84% But again, how do we go from layer i to one layer below? 00:37:43.950 --> 00:37:46.500 align:middle line:84% We take that element in the extension, 00:37:46.500 --> 00:37:47.900 align:middle line:90% we think of it as a sum-- 00:37:47.900 --> 00:37:49.900 align:middle line:84% that's the definition of a low-degree extension. 00:37:49.900 --> 00:37:52.470 align:middle line:84% It's the sum of the elements in the circuit itself 00:37:52.470 --> 00:37:56.820 align:middle line:84% with some function, with some weight. 00:37:56.820 --> 00:37:59.460 align:middle line:90% And now, we look at the value. 00:37:59.460 --> 00:38:01.620 align:middle line:90% What is the value of this gate? 00:38:01.620 --> 00:38:06.537 align:middle line:84% Well, if it's an and gate, it's the sum of the two children. 00:38:06.537 --> 00:38:08.870 align:middle line:84% And if it's a mult gate, it should be the multiplication 00:38:08.870 --> 00:38:10.250 align:middle line:90% of the two children. 00:38:10.250 --> 00:38:15.180 align:middle line:84% And so add i just outputs 1 of these-- if w1, 00:38:15.180 --> 00:38:20.090 align:middle line:84% w2 are the children of P, 0 otherwise, similarly mult. 00:38:20.090 --> 00:38:21.915 align:middle line:84% But we do everything in the extension. 00:38:21.915 --> 00:38:23.540 align:middle line:84% We look at everything in the extension, 00:38:23.540 --> 00:38:26.220 align:middle line:84% because we want to think of it as a polynomial. 00:38:26.220 --> 00:38:29.010 align:middle line:84% And once we have these are all polynomials, 00:38:29.010 --> 00:38:31.640 align:middle line:90% then this is just a sumcheck. 00:38:31.640 --> 00:38:33.720 align:middle line:84% And we saw sumcheck how to do it efficiently. 00:38:33.720 --> 00:38:36.470 align:middle line:84% So now, the point is GKR consists of only these 2d 00:38:36.470 --> 00:38:37.730 align:middle line:90% sumchecks. 00:38:37.730 --> 00:38:39.445 align:middle line:90% So now, let me go to my PCP. 00:38:39.445 --> 00:38:52.860 align:middle line:90% 00:38:52.860 --> 00:38:54.770 align:middle line:90% I'll erase this. 00:38:54.770 --> 00:38:57.250 align:middle line:90% So here is our PCP. 00:38:57.250 --> 00:39:01.530 align:middle line:90% 00:39:01.530 --> 00:39:05.370 align:middle line:84% Essentially, my PCP is just GKR but opened up. 00:39:05.370 --> 00:39:09.360 align:middle line:84% Completely, completely unraveled. 00:39:09.360 --> 00:39:10.810 align:middle line:90% OK, so here's my PCP. 00:39:10.810 --> 00:39:13.620 align:middle line:90% I have my x and w. 00:39:13.620 --> 00:39:15.390 align:middle line:90% Here's what I do. 00:39:15.390 --> 00:39:24.330 align:middle line:84% I'm going to compute all the V i tilde, the extension, 00:39:24.330 --> 00:39:31.290 align:middle line:84% the values of all the gates in each wire, for every z-- 00:39:31.290 --> 00:39:34.340 align:middle line:90% for every z in F to the m. 00:39:34.340 --> 00:39:38.630 align:middle line:84% It's important, all this is going to be part of the PCP. 00:39:38.630 --> 00:39:40.620 align:middle line:84% So if F to the m is more than polynomial, 00:39:40.620 --> 00:39:43.050 align:middle line:90% my PCP is superpolynomial. 00:39:43.050 --> 00:39:45.250 align:middle line:84% so F to the m has to be polynomial. 00:39:45.250 --> 00:39:48.190 align:middle line:90% This is already size polynomial. 00:39:48.190 --> 00:39:49.000 align:middle line:90% Yeah. 00:39:49.000 --> 00:39:55.240 align:middle line:84% AUDIENCE: Do we still have [INAUDIBLE] 00:39:55.240 --> 00:39:56.320 align:middle line:90% YAEL KALAI: Again, sorry? 00:39:56.320 --> 00:39:58.070 align:middle line:84% AUDIENCE: Do we still have the restriction 00:39:58.070 --> 00:40:02.305 align:middle line:84% on the [INAUDIBLE] [? x ?] to have that [INAUDIBLE] 00:40:02.305 --> 00:40:03.680 align:middle line:84% YAEL KALAI: Oh, yeah, yeah, yeah. 00:40:03.680 --> 00:40:04.940 align:middle line:90% Yeah, yeah, yeah OK, good, good. 00:40:04.940 --> 00:40:05.440 align:middle line:90% Yes. 00:40:05.440 --> 00:40:10.750 align:middle line:84% So for GKR, we had a restriction that the circuit-- 00:40:10.750 --> 00:40:15.520 align:middle line:84% to do GKR, we said GKR is like proving that bounded depth 00:40:15.520 --> 00:40:16.940 align:middle line:90% circuit [INAUDIBLE] is y. 00:40:16.940 --> 00:40:19.660 align:middle line:84% And we had a restriction that the circuit has 00:40:19.660 --> 00:40:23.720 align:middle line:90% to be bounded space uniform. 00:40:23.720 --> 00:40:27.370 align:middle line:84% Or, in other words, we needed to ensure that add i and mult i, 00:40:27.370 --> 00:40:30.130 align:middle line:84% this extended n i and extended mult i, 00:40:30.130 --> 00:40:33.960 align:middle line:90% are computed efficiently. 00:40:33.960 --> 00:40:36.880 align:middle line:90% 3SAT has that property. 00:40:36.880 --> 00:40:38.380 align:middle line:84% Again, I didn't go into the details, 00:40:38.380 --> 00:40:41.310 align:middle line:90% but the 3SAT is very uniform. 00:40:41.310 --> 00:40:43.410 align:middle line:84% Given a phi and x, it's very uniform to check. 00:40:43.410 --> 00:40:45.460 align:middle line:90% It's a logspace uniform. 00:40:45.460 --> 00:40:50.190 align:middle line:84% And then, we can convert it, as Rachel did two weeks ago, 00:40:50.190 --> 00:40:57.300 align:middle line:84% to one that by increasing the depth by poly factors, 00:40:57.300 --> 00:41:01.050 align:middle line:84% so keeping it poly log, you can make add i 00:41:01.050 --> 00:41:04.470 align:middle line:84% at tilde that and multi be efficiently computable. 00:41:04.470 --> 00:41:05.460 align:middle line:90% So yeah, great. 00:41:05.460 --> 00:41:06.980 align:middle line:90% That's a very good question. 00:41:06.980 --> 00:41:08.550 align:middle line:90% So yes. 00:41:08.550 --> 00:41:09.050 align:middle line:90% Good. 00:41:09.050 --> 00:41:12.380 align:middle line:84% So this is going to be part of the PCP. 00:41:12.380 --> 00:41:13.940 align:middle line:90% But that's not all. 00:41:13.940 --> 00:41:17.120 align:middle line:84% By the way, we should also give-- 00:41:17.120 --> 00:41:22.770 align:middle line:84% we give this for every i from the input layer 0, 1 up to d. 00:41:22.770 --> 00:41:23.440 align:middle line:90% This is output. 00:41:23.440 --> 00:41:26.040 align:middle line:90% 00:41:26.040 --> 00:41:28.530 align:middle line:90% And this is the input layer. 00:41:28.530 --> 00:41:30.030 align:middle line:84% We have to give him the input layer, 00:41:30.030 --> 00:41:32.947 align:middle line:84% because the poor verifier doesn't have w. 00:41:32.947 --> 00:41:34.530 align:middle line:84% So he doesn't have actually the input. 00:41:34.530 --> 00:41:36.357 align:middle line:84% Before, in GKR, he had the input. 00:41:36.357 --> 00:41:37.690 align:middle line:90% Here, he doesn't have the input. 00:41:37.690 --> 00:41:41.670 align:middle line:84% But we're going to give him the low-degree extension of this w. 00:41:41.670 --> 00:41:43.740 align:middle line:90% OK, good. 00:41:43.740 --> 00:41:45.580 align:middle line:84% OK, so I'm the verifier, what do I do? 00:41:45.580 --> 00:41:47.170 align:middle line:90% I need to verify the sumchecks? 00:41:47.170 --> 00:41:49.520 align:middle line:84% Who do I interact with sumchecks? 00:41:49.520 --> 00:41:52.100 align:middle line:84% I'll put all the possible answers in the oracle. 00:41:52.100 --> 00:41:55.530 align:middle line:90% So now, we do 2d sumchecks. 00:41:55.530 --> 00:42:05.410 align:middle line:84% So for every possible, for every i 00:42:05.410 --> 00:42:10.130 align:middle line:84% and for every z in the GKR protocol, 00:42:10.130 --> 00:42:11.380 align:middle line:90% we may need to do a sumcheck. 00:42:11.380 --> 00:42:14.690 align:middle line:84% Because in the sumcheck protocol, in the GKR, 00:42:14.690 --> 00:42:15.710 align:middle line:90% how does it look like? 00:42:15.710 --> 00:42:19.090 align:middle line:84% The verifier first decides, OK, prove 00:42:19.090 --> 00:42:20.300 align:middle line:90% the output layer is correct. 00:42:20.300 --> 00:42:22.070 align:middle line:84% Let's say the output, the z is fixed. 00:42:22.070 --> 00:42:22.780 align:middle line:90% Fine. 00:42:22.780 --> 00:42:25.475 align:middle line:84% Then, he chooses randomness, randomness, randomness sum 00:42:25.475 --> 00:42:26.570 align:middle line:90% of sumcheck. 00:42:26.570 --> 00:42:30.250 align:middle line:90% It reduces the checking z-- 00:42:30.250 --> 00:42:33.490 align:middle line:90% d minus 1 in a random z. 00:42:33.490 --> 00:42:37.810 align:middle line:84% The z is determined by the random point of the verifier. 00:42:37.810 --> 00:42:39.260 align:middle line:90% So which z do I put? 00:42:39.260 --> 00:42:42.010 align:middle line:84% And I want to show a sumcheck for every possible z. 00:42:42.010 --> 00:42:48.145 align:middle line:84% So for every possible z, I'm going to put in the PCP 00:42:48.145 --> 00:42:50.180 align:middle line:90% a sumcheck. 00:42:50.180 --> 00:42:51.920 align:middle line:90% So I'm going to give a sumcheck. 00:42:51.920 --> 00:42:57.070 align:middle line:84% I'm going to add all the possible transcripts 00:42:57.070 --> 00:43:02.780 align:middle line:84% for a sumcheck corresponding to V i 00:43:02.780 --> 00:43:11.350 align:middle line:84% z or maybe to V i equals V i tilde z. 00:43:11.350 --> 00:43:16.060 align:middle line:84% So for every i and z, I'm going to give a sumcheck with respect 00:43:16.060 --> 00:43:20.930 align:middle line:84% to randomness r from the verifier. 00:43:20.930 --> 00:43:24.580 align:middle line:84% So for every i, for every z, and for any randomness r 00:43:24.580 --> 00:43:25.760 align:middle line:90% of the verifier. 00:43:25.760 --> 00:43:29.830 align:middle line:84% Now, how much randomness does the verifier use in a sumcheck 00:43:29.830 --> 00:43:30.660 align:middle line:90% protocol? 00:43:30.660 --> 00:43:36.820 align:middle line:84% So remember, the sumcheck is sum over H to the 3m kind 00:43:36.820 --> 00:43:38.060 align:middle line:90% of variables. 00:43:38.060 --> 00:43:38.560 align:middle line:90% OK? 00:43:38.560 --> 00:43:43.210 align:middle line:84% It's sum over P w1, w2, all of them in H to the m. 00:43:43.210 --> 00:43:49.130 align:middle line:84% So the r is going to be for every r in F to the 3m. 00:43:49.130 --> 00:43:51.190 align:middle line:84% Because in the sumcheck protocol, what you do, 00:43:51.190 --> 00:43:55.000 align:middle line:84% is every single H, every single kind of-- 00:43:55.000 --> 00:43:56.260 align:middle line:90% you have 3m variables. 00:43:56.260 --> 00:43:59.920 align:middle line:84% Every one you give a random field element to reduce-- 00:43:59.920 --> 00:44:01.880 align:middle line:90% get rid of one of the sums. 00:44:01.880 --> 00:44:08.410 align:middle line:84% So the verifier will choose r1 up to r 3m. 00:44:08.410 --> 00:44:11.380 align:middle line:90% So 3m field elements. 00:44:11.380 --> 00:44:16.000 align:middle line:84% So for every r, I'm going to actually give you 00:44:16.000 --> 00:44:16.972 align:middle line:90% the transcript. 00:44:16.972 --> 00:44:19.430 align:middle line:84% So now, I know I'm going to give you the entire transcript. 00:44:19.430 --> 00:44:21.970 align:middle line:90% 00:44:21.970 --> 00:44:25.600 align:middle line:84% But here is the thing, I'm going to have 00:44:25.600 --> 00:44:27.340 align:middle line:90% a sumcheck for all of them. 00:44:27.340 --> 00:44:28.530 align:middle line:90% And now, the verifier. 00:44:28.530 --> 00:44:29.030 align:middle line:90% OK. 00:44:29.030 --> 00:44:30.260 align:middle line:90% But we need to be careful. 00:44:30.260 --> 00:44:32.090 align:middle line:84% We don't just give for every r a sumcheck. 00:44:32.090 --> 00:44:33.610 align:middle line:90% If I knew r, I would cheat. 00:44:33.610 --> 00:44:45.270 align:middle line:84% So what I mean here is for every sumcheck, for every V i, for r1, 00:44:45.270 --> 00:44:47.740 align:middle line:84% I'm going to give all the outputs for r1, 00:44:47.740 --> 00:44:51.720 align:middle line:84% all the kind of answers of the sumcheck for r1. 00:44:51.720 --> 00:44:54.960 align:middle line:84% Then, for each one of them, for every r2, 00:44:54.960 --> 00:44:56.590 align:middle line:90% all the possible answers. 00:44:56.590 --> 00:44:57.640 align:middle line:90% So no repetition. 00:44:57.640 --> 00:44:59.800 align:middle line:84% You can't have two different elements. 00:44:59.800 --> 00:45:04.060 align:middle line:84% You can't have one value if you had r1, r2, 00:45:04.060 --> 00:45:07.770 align:middle line:84% but later different r's, or r1 or r2-- 00:45:07.770 --> 00:45:13.030 align:middle line:84% for every possible partial transcript, you give a value. 00:45:13.030 --> 00:45:15.330 align:middle line:90% That's what the PCP has in it. 00:45:15.330 --> 00:45:18.370 align:middle line:90% So for every-- 00:45:18.370 --> 00:45:20.370 align:middle line:90% I should say, yeah-- 00:45:20.370 --> 00:45:26.845 align:middle line:84% i, for every z, and for every, maybe I should write it as, r1 00:45:26.845 --> 00:45:34.340 align:middle line:90% up to r 3m, I have a transcript. 00:45:34.340 --> 00:45:50.010 align:middle line:84% I should have all partial transcripts of sumcheck with 00:45:50.010 --> 00:46:00.450 align:middle line:84% respect to V i equals V z and randomness r1 up to r j 00:46:00.450 --> 00:46:12.805 align:middle line:84% for every j between, I don't know, 1 and 3m. 00:46:12.805 --> 00:46:16.740 align:middle line:90% 00:46:16.740 --> 00:46:23.450 align:middle line:84% OK, so for every r1 I will say, what would be my answer? 00:46:23.450 --> 00:46:29.140 align:middle line:84% So now I have F to the m answers for every one of these answers. 00:46:29.140 --> 00:46:33.280 align:middle line:84% For every r2, I'm going to tell you, what is the answer? 00:46:33.280 --> 00:46:37.160 align:middle line:84% For every-- sorry, I said it wrong. 00:46:37.160 --> 00:46:39.830 align:middle line:84% For every r1, I would give it all the answer. 00:46:39.830 --> 00:46:42.560 align:middle line:90% I have F. Each one is one field. 00:46:42.560 --> 00:46:45.140 align:middle line:84% So for every r1, I'll tell you the answer. 00:46:45.140 --> 00:46:48.800 align:middle line:84% That's F options because there are F options for r1. 00:46:48.800 --> 00:46:52.910 align:middle line:84% And then, out of these F-- for each of these F's, for every r2, 00:46:52.910 --> 00:46:55.880 align:middle line:84% I'm going to give you what the prover will say. 00:46:55.880 --> 00:46:57.480 align:middle line:90% That that's F squared. 00:46:57.480 --> 00:47:00.510 align:middle line:84% And then, for each of these, I'm going to give you r3. 00:47:00.510 --> 00:47:03.170 align:middle line:84% So really, what this PCP-- for every Vi-- 00:47:03.170 --> 00:47:05.000 align:middle line:90% for every such Vi-- 00:47:05.000 --> 00:47:11.540 align:middle line:84% or for every kind of Vi z, for every possible r1, 00:47:11.540 --> 00:47:13.593 align:middle line:84% I'm going to give you-- this is over r1. 00:47:13.593 --> 00:47:16.010 align:middle line:84% I'm going to give you the possible answers in the sumcheck 00:47:16.010 --> 00:47:17.240 align:middle line:90% protocol. 00:47:17.240 --> 00:47:19.490 align:middle line:84% If the prover in the-- if the verifier in the sumcheck 00:47:19.490 --> 00:47:23.038 align:middle line:84% protocol, the first randomness was this r1, this r1, this r1, 00:47:23.038 --> 00:47:24.830 align:middle line:84% I'm going to write all of these in the PCP. 00:47:24.830 --> 00:47:28.350 align:middle line:84% And then, for each r1, every possible r2, 00:47:28.350 --> 00:47:31.090 align:middle line:90% I'm going to write my answers. 00:47:31.090 --> 00:47:35.240 align:middle line:84% And then, for each r1 or r2, for every possible r3, 00:47:35.240 --> 00:47:36.680 align:middle line:90% I'm going to write my answers. 00:47:36.680 --> 00:47:38.240 align:middle line:84% It seems like an exponential tree, 00:47:38.240 --> 00:47:40.230 align:middle line:90% and it is an exponential tree. 00:47:40.230 --> 00:47:42.580 align:middle line:90% But the depth is so small. 00:47:42.580 --> 00:47:45.120 align:middle line:84% So this is a huge tree, but this tree is only 00:47:45.120 --> 00:47:47.250 align:middle line:90% of size F to the m-- 00:47:47.250 --> 00:47:47.870 align:middle line:90% or to the 3-- 00:47:47.870 --> 00:47:51.420 align:middle line:90% I'm sorry-- which is polynomial. 00:47:51.420 --> 00:47:53.840 align:middle line:90% It's S to the 3rd. 00:47:53.840 --> 00:47:56.520 align:middle line:84% And you're right that this is not good enough for practice, 00:47:56.520 --> 00:48:00.050 align:middle line:84% but then there is a lot of optimization in the GKR 00:48:00.050 --> 00:48:02.880 align:middle line:84% that make it quasi-linear and, today, even linear. 00:48:02.880 --> 00:48:08.288 align:middle line:84% So you can actually optimize this to get linear time, but-- 00:48:08.288 --> 00:48:10.710 align:middle line:84% or-- but-- or quasi-linear as a PCP. 00:48:10.710 --> 00:48:14.090 align:middle line:84% But for now, we don't care about these polynomial is good enough 00:48:14.090 --> 00:48:15.670 align:middle line:90% for us. 00:48:15.670 --> 00:48:21.330 align:middle line:84% So for every i and for every z, we give this tree. 00:48:21.330 --> 00:48:22.390 align:middle line:90% That's the PCP. 00:48:22.390 --> 00:48:25.380 align:middle line:90% 00:48:25.380 --> 00:48:26.030 align:middle line:90% That's it. 00:48:26.030 --> 00:48:30.020 align:middle line:90% 00:48:30.020 --> 00:48:32.400 align:middle line:90% OK, so-- yeah? 00:48:32.400 --> 00:48:34.920 align:middle line:84% AUDIENCE: Doesn't the sumcheck protocol rely on the fact 00:48:34.920 --> 00:48:36.142 align:middle line:90% that F is big? 00:48:36.142 --> 00:48:37.850 align:middle line:84% YAEL KALAI: Good, good, good, good, good. 00:48:37.850 --> 00:48:39.110 align:middle line:90% Fantastic. 00:48:39.110 --> 00:48:41.600 align:middle line:84% You're like, wait, that's a problem. 00:48:41.600 --> 00:48:45.710 align:middle line:84% If I require F to be small, do we even get soundness? 00:48:45.710 --> 00:48:47.610 align:middle line:90% That's a great question. 00:48:47.610 --> 00:48:50.395 align:middle line:84% So the answer is, barely, but yes. 00:48:50.395 --> 00:48:51.395 align:middle line:90% [LAUGHTER] 00:48:51.395 --> 00:48:52.500 align:middle line:90% So let's see. 00:48:52.500 --> 00:48:56.360 align:middle line:84% What's the-- OK, what is the soundness that we get? 00:48:56.360 --> 00:49:00.080 align:middle line:84% For it to be sound, Each sumcheck, so that the-- 00:49:00.080 --> 00:49:02.390 align:middle line:84% OK, so let's talk about soundness. 00:49:02.390 --> 00:49:03.640 align:middle line:90% Maybe I'll put it here. 00:49:03.640 --> 00:49:07.350 align:middle line:90% 00:49:07.350 --> 00:49:10.590 align:middle line:84% Let's talk about soundness here for a second because you raised 00:49:10.590 --> 00:49:12.790 align:middle line:84% a very-- but you know what, actually, 00:49:12.790 --> 00:49:14.222 align:middle line:90% before we talk about soundness-- 00:49:14.222 --> 00:49:15.180 align:middle line:90% I'll jump to soundness. 00:49:15.180 --> 00:49:16.530 align:middle line:90% You have a very good point. 00:49:16.530 --> 00:49:17.655 align:middle line:90% We'll talk about soundness. 00:49:17.655 --> 00:49:20.660 align:middle line:84% But just to make sure the construction is clear, 00:49:20.660 --> 00:49:26.190 align:middle line:84% so let me just reiterate one last time I'm a PCP prover. 00:49:26.190 --> 00:49:29.910 align:middle line:84% I want to convince you guys that I have a satisfying assignment 00:49:29.910 --> 00:49:31.430 align:middle line:90% to a three-step formula. 00:49:31.430 --> 00:49:33.030 align:middle line:90% I have my w. 00:49:33.030 --> 00:49:36.300 align:middle line:84% What I do, I construct a low-degree extension 00:49:36.300 --> 00:49:38.400 align:middle line:90% of my w, my witness. 00:49:38.400 --> 00:49:40.770 align:middle line:84% But also, I have this entire circuit 00:49:40.770 --> 00:49:42.310 align:middle line:90% that verifies this witness. 00:49:42.310 --> 00:49:45.000 align:middle line:84% And I'm going to construct a low-degree extension of each 00:49:45.000 --> 00:49:47.440 align:middle line:90% and every layer in this circuit. 00:49:47.440 --> 00:49:49.040 align:middle line:84% Now, the way I wrote it, actually, I 00:49:49.040 --> 00:49:51.082 align:middle line:84% will construct a low-degree extension of x and w. 00:49:51.082 --> 00:49:53.530 align:middle line:84% That's kind of-- if I think of the input is x and w 00:49:53.530 --> 00:49:55.530 align:middle line:84% and to construct a low-degree extension of both. 00:49:55.530 --> 00:49:57.550 align:middle line:90% But you-- the verifier knows x. 00:49:57.550 --> 00:49:59.860 align:middle line:84% So if I construct a low-degree extension of w, 00:49:59.860 --> 00:50:02.910 align:middle line:84% he himself can construct a low-degree extension of x and w 00:50:02.910 --> 00:50:03.750 align:middle line:90% together. 00:50:03.750 --> 00:50:08.090 align:middle line:84% So in the PCP, because I don't want to-- in the PCP, 00:50:08.090 --> 00:50:09.590 align:middle line:90% I don't want to put x in there. 00:50:09.590 --> 00:50:10.840 align:middle line:90% The verifier has x. 00:50:10.840 --> 00:50:13.240 align:middle line:84% And if I have the freedom to put x in there, 00:50:13.240 --> 00:50:16.040 align:middle line:84% and you don't read it, then I can put the wrong x. 00:50:16.040 --> 00:50:22.650 align:middle line:84% So I'm just going to put V0 is just going to be of the witness. 00:50:22.650 --> 00:50:24.410 align:middle line:84% I'm going to think of x as fixed. 00:50:24.410 --> 00:50:27.347 align:middle line:84% So I'm just going to construct a low-degree extension of w. 00:50:27.347 --> 00:50:29.930 align:middle line:84% And then I'm going to construct a low-degree extension of each 00:50:29.930 --> 00:50:34.440 align:middle line:90% and every layer of the circuit. 00:50:34.440 --> 00:50:38.410 align:middle line:84% And I'm going to go-- for every layer and for every z, 00:50:38.410 --> 00:50:42.840 align:middle line:84% I'm going to construct all the possible prover messages 00:50:42.840 --> 00:50:44.370 align:middle line:90% in the sumcheck protocol. 00:50:44.370 --> 00:50:50.700 align:middle line:84% Now, because the randomness, the options for the number 00:50:50.700 --> 00:50:55.620 align:middle line:84% of possible random bits from the verifier is only F to the 3m 00:50:55.620 --> 00:51:01.900 align:middle line:84% because there are 3m variables, and f is the field. 00:51:01.900 --> 00:51:03.840 align:middle line:90% So it's only after the 3m. 00:51:03.840 --> 00:51:07.440 align:middle line:84% Then, this tree is only going to be of size f to the 3m, 00:51:07.440 --> 00:51:09.690 align:middle line:90% so it's not too bad. 00:51:09.690 --> 00:51:11.110 align:middle line:90% And I put all of them. 00:51:11.110 --> 00:51:13.860 align:middle line:84% I put all the possible sumchecks in there. 00:51:13.860 --> 00:51:17.610 align:middle line:90% So it's F to the 3m for every-- 00:51:17.610 --> 00:51:20.370 align:middle line:84% I have this size for every i and for every z. 00:51:20.370 --> 00:51:23.490 align:middle line:84% OK, so for every i, i is only D. It's this is small, 00:51:23.490 --> 00:51:25.620 align:middle line:84% and z is another f to the m I pay. 00:51:25.620 --> 00:51:26.670 align:middle line:90% Fine. 00:51:26.670 --> 00:51:29.020 align:middle line:90% So after for. 00:51:29.020 --> 00:51:34.540 align:middle line:84% So for every z and for every i, i have the sumcheck. 00:51:34.540 --> 00:51:37.450 align:middle line:84% Now, what the-- what is-- so that's the PCP. 00:51:37.450 --> 00:51:39.360 align:middle line:84% But now what's-- what does the verifier do? 00:51:39.360 --> 00:51:39.860 align:middle line:90% What is V? 00:51:39.860 --> 00:51:40.660 align:middle line:90% I need to define-- 00:51:40.660 --> 00:51:44.360 align:middle line:84% I told you how to construct this pi efficiently. 00:51:44.360 --> 00:51:47.380 align:middle line:90% And it's-- but what does V do? 00:51:47.380 --> 00:51:50.680 align:middle line:84% So what does-- what V does, he says, 00:51:50.680 --> 00:51:54.720 align:middle line:84% I'm going to pretend that I'm interacting with a GKR prover. 00:51:54.720 --> 00:51:56.770 align:middle line:84% So he says, look, what is the output? 00:51:56.770 --> 00:51:59.520 align:middle line:84% He's going to read the output, VD. 00:51:59.520 --> 00:52:00.750 align:middle line:90% And he's going to expect a 1. 00:52:00.750 --> 00:52:02.590 align:middle line:84% If he sees a 0, so that's one query. 00:52:02.590 --> 00:52:03.340 align:middle line:90% I'm going to read the output. 00:52:03.340 --> 00:52:04.020 align:middle line:90% If it's 1, good. 00:52:04.020 --> 00:52:06.396 align:middle line:90% I'm happy. 00:52:06.396 --> 00:52:10.890 align:middle line:84% Now he's going to go from verifying D verifying D minus 1, 00:52:10.890 --> 00:52:12.240 align:middle line:90% D minus 2, D minus 3. 00:52:12.240 --> 00:52:13.633 align:middle line:84% Now he wants to talk to a prover. 00:52:13.633 --> 00:52:15.800 align:middle line:84% He said, OK, here is my randomness, my first message 00:52:15.800 --> 00:52:17.070 align:middle line:90% of the sumcheck. 00:52:17.070 --> 00:52:18.270 align:middle line:90% Give me back something. 00:52:18.270 --> 00:52:19.280 align:middle line:90% OK. 00:52:19.280 --> 00:52:20.370 align:middle line:90% This is the prover. 00:52:20.370 --> 00:52:23.000 align:middle line:90% The prover is fixed in the PCP. 00:52:23.000 --> 00:52:25.250 align:middle line:84% OK, so he gets back an answer, da, da, da, da, da, da. 00:52:25.250 --> 00:52:25.750 align:middle line:90% Good. 00:52:25.750 --> 00:52:33.500 align:middle line:84% Now, here, these at the end, this defines V i minus 1 00:52:33.500 --> 00:52:38.550 align:middle line:84% Z. This should be all kind of elements in V minus 1 z. 00:52:38.550 --> 00:52:41.330 align:middle line:84% Now, actually, here, what you have here is, 00:52:41.330 --> 00:52:46.320 align:middle line:84% at the end of the GKR protocol, you're left with two V's, right? 00:52:46.320 --> 00:52:48.670 align:middle line:84% So if you verify here, you'll have-- 00:52:48.670 --> 00:52:52.230 align:middle line:84% at the end, you'll have V, I don't know, 0 and V-- 00:52:52.230 --> 00:52:53.427 align:middle line:90% z0 and z1. 00:52:53.427 --> 00:52:55.760 align:middle line:84% You'll verify-- you need to verify two points because we 00:52:55.760 --> 00:52:57.270 align:middle line:90% did two sumcheck all the way. 00:52:57.270 --> 00:52:59.480 align:middle line:90% So fine, he sees these two. 00:52:59.480 --> 00:53:00.320 align:middle line:90% He checks. 00:53:00.320 --> 00:53:01.190 align:middle line:90% There's these. 00:53:01.190 --> 00:53:02.660 align:middle line:90% He checks that they're equal. 00:53:02.660 --> 00:53:04.580 align:middle line:90% This is only 1. 00:53:04.580 --> 00:53:08.250 align:middle line:84% So we're giving him all the low-degree extension of Vi 00:53:08.250 --> 00:53:08.910 align:middle line:90% minus 1. 00:53:08.910 --> 00:53:11.470 align:middle line:84% He checks, and oh, yeah, this is-- corresponds. 00:53:11.470 --> 00:53:12.580 align:middle line:90% This corresponds. 00:53:12.580 --> 00:53:14.370 align:middle line:84% This is just to ensure that he doesn't put 00:53:14.370 --> 00:53:16.530 align:middle line:90% different ones in different-- 00:53:16.530 --> 00:53:22.140 align:middle line:84% here, he may-- in this branch, he may put the value of Z0 00:53:22.140 --> 00:53:23.640 align:middle line:84% to be something, and in this branch, 00:53:23.640 --> 00:53:26.050 align:middle line:84% he may put the value of Z0 to be something else. 00:53:26.050 --> 00:53:28.900 align:middle line:90% That's not good for us. 00:53:28.900 --> 00:53:31.200 align:middle line:84% So we just check because he put aside 00:53:31.200 --> 00:53:32.820 align:middle line:90% all the low-degree extensions. 00:53:32.820 --> 00:53:35.460 align:middle line:84% So he checks that it's equal to what he gave us. 00:53:35.460 --> 00:53:37.967 align:middle line:90% And we continue with that. 00:53:37.967 --> 00:53:38.467 align:middle line:90% OK? 00:53:38.467 --> 00:53:50.500 align:middle line:90% 00:53:50.500 --> 00:53:51.442 align:middle line:90% One second. 00:53:51.442 --> 00:53:52.400 align:middle line:90% Actually, I'm not sure. 00:53:52.400 --> 00:53:53.692 align:middle line:90% Maybe what I said is incorrect. 00:53:53.692 --> 00:53:56.660 align:middle line:84% I'm not actually sure that this is a problem. 00:53:56.660 --> 00:53:58.468 align:middle line:84% Even if he gives us different-- let 00:53:58.468 --> 00:53:59.760 align:middle line:90% me think about it for a second. 00:53:59.760 --> 00:54:08.630 align:middle line:90% 00:54:08.630 --> 00:54:12.050 align:middle line:84% Actually, I'm not even sure that we need-- 00:54:12.050 --> 00:54:13.790 align:middle line:90% we can just put the sumchecks. 00:54:13.790 --> 00:54:15.560 align:middle line:90% Even if he gives us-- 00:54:15.560 --> 00:54:17.040 align:middle line:90% even if he gives us-- 00:54:17.040 --> 00:54:28.430 align:middle line:90% 00:54:28.430 --> 00:54:29.820 align:middle line:90% no, OK, yeah. 00:54:29.820 --> 00:54:31.370 align:middle line:84% I want to say, even if it gives us, 00:54:31.370 --> 00:54:34.880 align:middle line:84% in this branch and this branch, different things, 00:54:34.880 --> 00:54:35.880 align:middle line:90% why do we care? 00:54:35.880 --> 00:54:38.297 align:middle line:84% It's like, we ran the sumcheck, and the sumcheck is sound. 00:54:38.297 --> 00:54:42.040 align:middle line:84% But we do care a little bit because then, in the next round, 00:54:42.040 --> 00:54:42.540 align:middle line:90% which-- 00:54:42.540 --> 00:54:45.210 align:middle line:90% 00:54:45.210 --> 00:54:46.450 align:middle line:90% let me think. 00:54:46.450 --> 00:54:49.030 align:middle line:84% You know what, I'm not actually-- what? 00:54:49.030 --> 00:54:49.540 align:middle line:84% AUDIENCE: [? My ?] [? understanding ?] [? is ?] 00:54:49.540 --> 00:54:51.850 align:middle line:84% that you sort of just lay out the whole randomness 00:54:51.850 --> 00:54:52.876 align:middle line:90% of the verifier, right? 00:54:52.876 --> 00:54:54.773 align:middle line:84% And then verifier [INAUDIBLE] actually [? interacting ?] [? 00:54:54.773 --> 00:54:55.860 align:middle line:84% with the ?] prover just like [INAUDIBLE]. 00:54:55.860 --> 00:54:56.693 align:middle line:90% YAEL KALAI: Exactly. 00:54:56.693 --> 00:54:57.630 align:middle line:90% You let all the-- 00:54:57.630 --> 00:54:58.290 align:middle line:90% so yeah. 00:54:58.290 --> 00:55:02.400 align:middle line:84% So I don't think, actually, you need to give these specific. 00:55:02.400 --> 00:55:03.900 align:middle line:90% You can just give-- 00:55:03.900 --> 00:55:07.890 align:middle line:84% for every Vi tilde, you give-- but it's the same because you 00:55:07.890 --> 00:55:09.040 align:middle line:90% give for every Vi tilde. 00:55:09.040 --> 00:55:12.040 align:middle line:84% So actually, it's-- I think these two are the same. 00:55:12.040 --> 00:55:12.540 align:middle line:90% So-- OK. 00:55:12.540 --> 00:55:18.930 align:middle line:84% What I-- I guess what I said is, these can be-- maybe Vi minus 1 00:55:18.930 --> 00:55:22.510 align:middle line:84% of z0 appears here and appears here, and they're different. 00:55:22.510 --> 00:55:23.660 align:middle line:90% Are we worried? 00:55:23.660 --> 00:55:25.243 align:middle line:84% We're not really worried, because it's 00:55:25.243 --> 00:55:27.452 align:middle line:84% like-- you think of it, it interacts with the prover. 00:55:27.452 --> 00:55:30.070 align:middle line:84% The prover-- the cheating prover may give him different 00:55:30.070 --> 00:55:31.400 align:middle line:90% z here and different z here. 00:55:31.400 --> 00:55:34.965 align:middle line:84% But later-- the point is, later, you'll have-- in Vi minus 1, 00:55:34.965 --> 00:55:35.840 align:middle line:90% you'll just continue. 00:55:35.840 --> 00:55:37.760 align:middle line:84% So actually, you just need to give-- 00:55:37.760 --> 00:55:40.250 align:middle line:84% but really, I think the two are equivalent, 00:55:40.250 --> 00:55:41.690 align:middle line:90% so it doesn't really matter. 00:55:41.690 --> 00:55:44.050 align:middle line:84% OK, so this is between how you verify. 00:55:44.050 --> 00:55:46.820 align:middle line:84% And at the end, at the end, at the end of the GKR, 00:55:46.820 --> 00:55:48.830 align:middle line:84% the verifier needs to read the input. 00:55:48.830 --> 00:55:51.460 align:middle line:84% He needs to check the input in some locations. 00:55:51.460 --> 00:55:53.470 align:middle line:90% He doesn't have the input. 00:55:53.470 --> 00:55:58.720 align:middle line:84% But he does, because we gave him the low-degree extension of w. 00:55:58.720 --> 00:56:01.580 align:middle line:84% So once he has the low-degree extension of w, 00:56:01.580 --> 00:56:04.360 align:middle line:90% he can compute anything. 00:56:04.360 --> 00:56:09.960 align:middle line:84% So the verifier needs to compute a low-degree extension of x 00:56:09.960 --> 00:56:15.720 align:middle line:84% and w, but any point in the low-degree extension of x and w 00:56:15.720 --> 00:56:19.590 align:middle line:84% is a point in the low-degree-- is a sum of points 00:56:19.590 --> 00:56:21.930 align:middle line:84% in the low-degree extension of x and point 00:56:21.930 --> 00:56:23.600 align:middle line:84% in the low-degree extension of w. 00:56:23.600 --> 00:56:29.460 align:middle line:84% So every point in the low-degree extension of x and w, 00:56:29.460 --> 00:56:32.430 align:middle line:84% you can write as a weighted sum of a point 00:56:32.430 --> 00:56:34.740 align:middle line:84% in the low-degree extension of x and a point 00:56:34.740 --> 00:56:36.280 align:middle line:84% in the low-degree extension of w. 00:56:36.280 --> 00:56:40.480 align:middle line:84% So once he needs to read the point in the extension of w, 00:56:40.480 --> 00:56:41.820 align:middle line:90% he has it here. 00:56:41.820 --> 00:56:43.920 align:middle line:90% So that's how the verifier does. 00:56:43.920 --> 00:56:45.930 align:middle line:90% So he really-- he's-- 00:56:45.930 --> 00:56:48.060 align:middle line:84% it's interesting, this PCP, he-- as 00:56:48.060 --> 00:56:49.980 align:middle line:84% if he's talking to the prover, but the prover 00:56:49.980 --> 00:56:53.130 align:middle line:84% is sitting in the sky in the PCP. 00:56:53.130 --> 00:56:58.470 align:middle line:84% The prover's strategy has just kind of opened up in the oracle. 00:56:58.470 --> 00:56:59.790 align:middle line:90% OK? 00:56:59.790 --> 00:57:00.430 align:middle line:90% OK, great. 00:57:00.430 --> 00:57:03.810 align:middle line:84% So now, any questions before we talk about soundness. 00:57:03.810 --> 00:57:04.440 align:middle line:90% Yeah. 00:57:04.440 --> 00:57:05.940 align:middle line:84% AUDIENCE: [INAUDIBLE] this protocol, 00:57:05.940 --> 00:57:10.290 align:middle line:84% the buffer versus the [INAUDIBLE] graphed. 00:57:10.290 --> 00:57:11.640 align:middle line:90% And then [INAUDIBLE]. 00:57:11.640 --> 00:57:12.970 align:middle line:90% YAEL KALAI: So right. 00:57:12.970 --> 00:57:13.470 align:middle line:90% OK. 00:57:13.470 --> 00:57:15.230 align:middle line:90% Good, good, good question. 00:57:15.230 --> 00:57:17.090 align:middle line:90% The verify-- great question. 00:57:17.090 --> 00:57:20.790 align:middle line:84% The verifier needs to check also that all these things are 00:57:20.790 --> 00:57:22.900 align:middle line:90% actually low-degree extension. 00:57:22.900 --> 00:57:28.122 align:middle line:84% So what if I said here, oh, you put Vi tilde z? 00:57:28.122 --> 00:57:30.580 align:middle line:84% How do I know that you actually put a low-degree extension? 00:57:30.580 --> 00:57:34.060 align:middle line:84% Maybe you put a very high degree polynomial there. 00:57:34.060 --> 00:57:39.410 align:middle line:84% Maybe you just put an arbitrary truth table of size after them. 00:57:39.410 --> 00:57:41.360 align:middle line:90% That would be problematic. 00:57:41.360 --> 00:57:44.150 align:middle line:84% So you're totally right that the verifier-- so 00:57:44.150 --> 00:57:47.940 align:middle line:84% let me write what the verifier does maybe before the soundness. 00:57:47.940 --> 00:57:52.860 align:middle line:90% 00:57:52.860 --> 00:57:54.280 align:middle line:90% Let me actually write it. 00:57:54.280 --> 00:58:02.540 align:middle line:90% So the verifier, he runs. 00:58:02.540 --> 00:58:10.965 align:middle line:84% The first thing he does, he runs V of GKR with its oracle. 00:58:10.965 --> 00:58:16.290 align:middle line:90% 00:58:16.290 --> 00:58:19.750 align:middle line:84% So he runs just the GKR, but he thinks 00:58:19.750 --> 00:58:24.910 align:middle line:84% of the oracle part as kind of the prover he's talking with. 00:58:24.910 --> 00:58:32.600 align:middle line:84% And the other thing he needs to do is he needs to check that 00:58:32.600 --> 00:58:41.200 align:middle line:84% for every i, Vi tilde is of low degree-- is-- 00:58:41.200 --> 00:58:51.621 align:middle line:90% 00:58:51.621 --> 00:58:54.850 align:middle line:84% AUDIENCE: Does the original verify of GKR do that? 00:58:54.850 --> 00:58:59.010 align:middle line:84% Again, doesn't it sound as if GKR just relies on [INAUDIBLE]? 00:58:59.010 --> 00:59:19.402 align:middle line:90% 00:59:19.402 --> 00:59:20.110 align:middle line:90% YAEL KALAI: Yeah. 00:59:20.110 --> 00:59:23.040 align:middle line:90% What you're saying is that if-- 00:59:23.040 --> 00:59:23.860 align:middle line:90% you're right. 00:59:23.860 --> 00:59:24.990 align:middle line:90% So what you're saying is-- 00:59:24.990 --> 00:59:31.690 align:middle line:90% 00:59:31.690 --> 00:59:36.720 align:middle line:84% what you're saying is if he gave Vi tilde, that was high degree. 00:59:36.720 --> 00:59:39.620 align:middle line:90% 00:59:39.620 --> 00:59:42.810 align:middle line:84% Then you're saying the GKR would fail. 00:59:42.810 --> 00:59:44.542 align:middle line:84% You would be rejected by the GKR. 00:59:44.542 --> 00:59:45.500 align:middle line:90% AUDIENCE: It should be. 00:59:45.500 --> 00:59:46.960 align:middle line:90% Otherwise, it just doesn't work. 00:59:46.960 --> 00:59:48.835 align:middle line:84% YAEL KALAI: It should be rejected by the GKR. 00:59:48.835 --> 00:59:59.353 align:middle line:90% 00:59:59.353 --> 01:00:02.535 align:middle line:84% I think you may be right, but actually, I'm not 100% sure now. 01:00:02.535 --> 01:00:05.900 align:middle line:90% 01:00:05.900 --> 01:00:08.690 align:middle line:84% AUDIENCE: [INAUDIBLE] that Ei is of high degree, 01:00:08.690 --> 01:00:11.030 align:middle line:84% but still agreed with the higher or more degree. 01:00:11.030 --> 01:00:11.738 align:middle line:90% YAEL KALAI: Yeah. 01:00:11.738 --> 01:00:12.660 align:middle line:90% So here's the concern. 01:00:12.660 --> 01:00:13.530 align:middle line:90% Here's the concern. 01:00:13.530 --> 01:00:18.770 align:middle line:84% The concern is we want to make sure that the verifier is 01:00:18.770 --> 01:00:22.190 align:middle line:90% behaving like-- 01:00:22.190 --> 01:00:30.515 align:middle line:84% we want to make sure that this Vi tilde is of low degree. 01:00:30.515 --> 01:00:31.015 align:middle line:90% Why? 01:00:31.015 --> 01:00:37.630 align:middle line:90% 01:00:37.630 --> 01:00:38.230 align:middle line:90% Sorry. 01:00:38.230 --> 01:00:38.730 align:middle line:90% 1 second. 01:00:38.730 --> 01:00:47.158 align:middle line:90% 01:00:47.158 --> 01:00:48.585 align:middle line:90% Yeah, actually, I-- 01:00:48.585 --> 01:00:58.120 align:middle line:90% 01:00:58.120 --> 01:01:00.100 align:middle line:84% I don't think we need to check that Vi tilde is 01:01:00.100 --> 01:01:01.570 align:middle line:90% a low degree, because-- 01:01:01.570 --> 01:01:04.430 align:middle line:84% I agree that we need to check that Vi tilde is of low degree, 01:01:04.430 --> 01:01:07.360 align:middle line:84% but I think GKR checks that the tilde is a low degree. 01:01:07.360 --> 01:01:09.980 align:middle line:84% So I actually don't want to recheck it. 01:01:09.980 --> 01:01:14.450 align:middle line:84% So all I want to do here, I think GKR tests it for you. 01:01:14.450 --> 01:01:17.560 align:middle line:84% So we're convinced that the GKR is sound. 01:01:17.560 --> 01:01:19.910 align:middle line:90% Let's not recall why it's sound. 01:01:19.910 --> 01:01:23.450 align:middle line:84% But let's remember-- we learned that it's sound. 01:01:23.450 --> 01:01:24.590 align:middle line:90% So GKR is good. 01:01:24.590 --> 01:01:25.863 align:middle line:90% Now, what are we doing? 01:01:25.863 --> 01:01:27.280 align:middle line:84% Essentially, what we're saying is, 01:01:27.280 --> 01:01:31.990 align:middle line:84% verifier, I'm giving you all the possible answers. 01:01:31.990 --> 01:01:32.932 align:middle line:90% What is the prover? 01:01:32.932 --> 01:01:33.890 align:middle line:90% The prover is the tree. 01:01:33.890 --> 01:01:35.690 align:middle line:84% You can think-- what is a cheating prover? 01:01:35.690 --> 01:01:40.552 align:middle line:84% A cheating prover, for every possible question, 01:01:40.552 --> 01:01:41.510 align:middle line:90% he gives you an answer. 01:01:41.510 --> 01:01:43.302 align:middle line:84% For every question, he gives you an answer. 01:01:43.302 --> 01:01:44.380 align:middle line:90% That's what it does. 01:01:44.380 --> 01:01:48.190 align:middle line:84% So now you're saying, look, I'm going to give you the tree. 01:01:48.190 --> 01:01:52.060 align:middle line:84% Now, in general, this tree is really, really big. 01:01:52.060 --> 01:01:55.030 align:middle line:84% And even in GKR, if you give the entire-- 01:01:55.030 --> 01:01:56.380 align:middle line:90% if you just open-- 01:01:56.380 --> 01:02:01.700 align:middle line:84% GKR has D rounds, D rounds of sum check. 01:02:01.700 --> 01:02:05.270 align:middle line:84% If you just open the sum check, it will be terrible. 01:02:05.270 --> 01:02:12.540 align:middle line:84% However, GKR has this property that it's kind of memoryless. 01:02:12.540 --> 01:02:14.190 align:middle line:90% What do I mean by memoryless? 01:02:14.190 --> 01:02:16.850 align:middle line:84% You can compute the first sum check. 01:02:16.850 --> 01:02:19.760 align:middle line:84% Then you don't care what happened before. 01:02:19.760 --> 01:02:22.760 align:middle line:84% All you care is what is Vi minus one that you cut, 01:02:22.760 --> 01:02:25.290 align:middle line:90% and you check those. 01:02:25.290 --> 01:02:28.590 align:middle line:84% So now I'm saying-- so you know, actually, 01:02:28.590 --> 01:02:29.590 align:middle line:90% let's think about this. 01:02:29.590 --> 01:02:33.610 align:middle line:84% First of all, we can say, open GKR to a huge tree. 01:02:33.610 --> 01:02:36.220 align:middle line:84% Any prover-- this is true in general. 01:02:36.220 --> 01:02:37.875 align:middle line:84% If you had any interactive proof, 01:02:37.875 --> 01:02:39.250 align:middle line:84% you can think of a prover, right? 01:02:39.250 --> 01:02:40.530 align:middle line:90% All the possible answers. 01:02:40.530 --> 01:02:44.583 align:middle line:84% Think of its strategy as a huge, huge tree. 01:02:44.583 --> 01:02:46.000 align:middle line:84% Now, of course, you get soundness. 01:02:46.000 --> 01:02:47.260 align:middle line:90% You interact with the prover. 01:02:47.260 --> 01:02:48.820 align:middle line:90% What's the difference? 01:02:48.820 --> 01:02:50.400 align:middle line:90% You can do that with GKR. 01:02:50.400 --> 01:02:53.140 align:middle line:84% But of course, if you do this huge tree, 01:02:53.140 --> 01:02:55.110 align:middle line:84% it's going to be gigantic because GKR consists 01:02:55.110 --> 01:03:00.910 align:middle line:90% of D kind of subprotocols. 01:03:00.910 --> 01:03:02.140 align:middle line:90% Each one is a subject. 01:03:02.140 --> 01:03:04.650 align:middle line:84% So now if you think of like a D, [INAUDIBLE] then 01:03:04.650 --> 01:03:06.400 align:middle line:90% you'll be too big. 01:03:06.400 --> 01:03:09.010 align:middle line:84% But I'm saying we don't need to, because GKR 01:03:09.010 --> 01:03:13.640 align:middle line:84% has a property that, actually, it consists of this subprotocol. 01:03:13.640 --> 01:03:15.700 align:middle line:84% And then all you need to remember-- 01:03:15.700 --> 01:03:19.150 align:middle line:84% you don't need to remember which branch you're on here. 01:03:19.150 --> 01:03:22.720 align:middle line:84% All you need to remember is what are the values here. 01:03:22.720 --> 01:03:25.120 align:middle line:90% That's all you need to remember. 01:03:25.120 --> 01:03:27.440 align:middle line:84% So there's no point in repeating. 01:03:27.440 --> 01:03:30.220 align:middle line:84% It's like you're repeating the tree for no reason. 01:03:30.220 --> 01:03:34.780 align:middle line:84% So all you need-- there's a way to open this prover in a more 01:03:34.780 --> 01:03:37.110 align:middle line:90% efficient way. 01:03:37.110 --> 01:03:39.040 align:middle line:84% So by not giving the entire trend, 01:03:39.040 --> 01:03:41.610 align:middle line:84% giving kind of a more efficient kind of opening, 01:03:41.610 --> 01:03:43.380 align:middle line:90% where all the Vi's-- 01:03:43.380 --> 01:03:47.380 align:middle line:84% all the Vi minus 1z, I'm going to say, OK, forget about it. 01:03:47.380 --> 01:03:50.160 align:middle line:84% Let's just go from Vi minus 1z and continue. 01:03:50.160 --> 01:03:53.500 align:middle line:84% Why do you need to repeat this kind of tree 100 times? 01:03:53.500 --> 01:04:01.350 align:middle line:84% But you can go from here to simulating an entire GKR prover. 01:04:01.350 --> 01:04:01.950 align:middle line:90% Yeah. 01:04:01.950 --> 01:04:04.200 align:middle line:84% AUDIENCE: So if I understand correctly, you're saying, 01:04:04.200 --> 01:04:06.990 align:middle line:84% actually, the tree of GKR is such that most of the parts 01:04:06.990 --> 01:04:08.328 align:middle line:90% are copied. 01:04:08.328 --> 01:04:10.120 align:middle line:84% And so you don't need to repeat the copies. 01:04:10.120 --> 01:04:10.980 align:middle line:90% You can just look it up. 01:04:10.980 --> 01:04:11.813 align:middle line:90% YAEL KALAI: Exactly. 01:04:11.813 --> 01:04:12.580 align:middle line:90% Exactly. 01:04:12.580 --> 01:04:14.155 align:middle line:90% Exactly. 01:04:14.155 --> 01:04:14.655 align:middle line:90% Exactly. 01:04:14.655 --> 01:04:17.830 align:middle line:90% 01:04:17.830 --> 01:04:20.950 align:middle line:84% Actually, in some sense, we're restricting the prover here more 01:04:20.950 --> 01:04:23.540 align:middle line:90% than he's restricted in GKR. 01:04:23.540 --> 01:04:24.040 align:middle line:90% Exactly. 01:04:24.040 --> 01:04:26.540 align:middle line:84% Because in GKR, he can be, you know what? 01:04:26.540 --> 01:04:29.695 align:middle line:84% I'm going to remember the R's, if he's cheating. 01:04:29.695 --> 01:04:31.570 align:middle line:84% And based on these R's, I'm going to give you 01:04:31.570 --> 01:04:32.890 align:middle line:90% a different strategy. 01:04:32.890 --> 01:04:33.562 align:middle line:90% Whatever. 01:04:33.562 --> 01:04:35.270 align:middle line:84% Here, we're not even letting him do that. 01:04:35.270 --> 01:04:37.420 align:middle line:84% We're saying, look, you tell me what you are here. 01:04:37.420 --> 01:04:39.310 align:middle line:90% From here, now you forget R's. 01:04:39.310 --> 01:04:42.100 align:middle line:84% From Vi minus 1, what's your strategy? 01:04:42.100 --> 01:04:43.030 align:middle line:90% And now you forget. 01:04:43.030 --> 01:04:45.470 align:middle line:84% From here, what is your strategy? 01:04:45.470 --> 01:04:47.780 align:middle line:90% So we're really just doing GKR. 01:04:47.780 --> 01:04:51.170 align:middle line:84% Now, you write that the Vi minus 1 tilde 01:04:51.170 --> 01:04:53.820 align:middle line:90% does need to be of low degree. 01:04:53.820 --> 01:04:55.950 align:middle line:90% But the GKR test is for you. 01:04:55.950 --> 01:04:59.140 align:middle line:84% So you don't need to do it on your own. 01:04:59.140 --> 01:04:59.960 align:middle line:90% But you're right. 01:04:59.960 --> 01:05:02.470 align:middle line:84% It's confusing a little bit, because if you-- if anyone 01:05:02.470 --> 01:05:04.160 align:middle line:84% is familiar with the PCP literature, 01:05:04.160 --> 01:05:06.530 align:middle line:84% there's always a low degree test in it. 01:05:06.530 --> 01:05:08.740 align:middle line:84% So it's kind of interesting this is 01:05:08.740 --> 01:05:11.660 align:middle line:90% hidden within the GKR protocol. 01:05:11.660 --> 01:05:13.470 align:middle line:84% AUDIENCE: This kind of transformation 01:05:13.470 --> 01:05:14.520 align:middle line:90% is not only for GKR. 01:05:14.520 --> 01:05:16.760 align:middle line:84% As long as there is an efficient way 01:05:16.760 --> 01:05:19.610 align:middle line:84% to change the prover into a sequence 01:05:19.610 --> 01:05:21.948 align:middle line:84% that the verifier knows where to compare 01:05:21.948 --> 01:05:23.240 align:middle line:90% it will give you a [INAUDIBLE]. 01:05:23.240 --> 01:05:24.450 align:middle line:90% YAEL KALAI: Exactly, exactly. 01:05:24.450 --> 01:05:27.030 align:middle line:90% So yeah, this proof holds. 01:05:27.030 --> 01:05:28.820 align:middle line:90% It's not specific to GKR. 01:05:28.820 --> 01:05:31.610 align:middle line:84% You can take any succinct protocol 01:05:31.610 --> 01:05:34.730 align:middle line:84% and interactive protocol and lay it open. 01:05:34.730 --> 01:05:38.660 align:middle line:84% However, let me just mention we have very few-- 01:05:38.660 --> 01:05:42.750 align:middle line:84% actually, kind of two examples of succinct protocols. 01:05:42.750 --> 01:05:45.602 align:middle line:84% So it sounds like you can take any of your choice. 01:05:45.602 --> 01:05:47.310 align:middle line:84% Yeah, any, but we don't have much choice. 01:05:47.310 --> 01:05:49.838 align:middle line:90% 01:05:49.838 --> 01:05:52.310 align:middle line:84% Coming up with these succinct, interactive proofs 01:05:52.310 --> 01:05:54.680 align:middle line:90% is a super interesting question. 01:05:54.680 --> 01:05:56.690 align:middle line:84% I'll talk a little bit more about this 01:05:56.690 --> 01:06:00.410 align:middle line:84% after we do the analysis of the PCP. 01:06:00.410 --> 01:06:04.060 align:middle line:90% So great. 01:06:04.060 --> 01:06:08.460 align:middle line:84% Any questions before we move to soundness. 01:06:08.460 --> 01:06:09.840 align:middle line:90% So let's talk about soundness. 01:06:09.840 --> 01:06:12.630 align:middle line:84% And the question that was raised, 01:06:12.630 --> 01:06:15.210 align:middle line:84% which was a great question, is, wait, f needs 01:06:15.210 --> 01:06:16.570 align:middle line:90% to be big to get soundness. 01:06:16.570 --> 01:06:19.710 align:middle line:84% So let's really understand what the size of f needs to be. 01:06:19.710 --> 01:06:24.060 align:middle line:84% So to get soundness, we do 2d sum check protocols. 01:06:24.060 --> 01:06:26.580 align:middle line:84% Each sum check protocol needs to be pretty sound, 01:06:26.580 --> 01:06:28.622 align:middle line:84% because it's enough that you cheat on one of them 01:06:28.622 --> 01:06:30.810 align:middle line:90% and we're dead. 01:06:30.810 --> 01:06:33.450 align:middle line:84% Now, each sum check protocol, this is 01:06:33.450 --> 01:06:42.260 align:middle line:84% just recall that each sum check protocol 01:06:42.260 --> 01:06:54.670 align:middle line:84% has soundness, which is H/F times m the number of variables. 01:06:54.670 --> 01:06:59.260 align:middle line:84% But for us, it's 3m, because we have 3m variables. 01:06:59.260 --> 01:07:01.980 align:middle line:84% This is just the sum check protocol. 01:07:01.980 --> 01:07:06.250 align:middle line:84% Now, for us, so you can cheat, but with this probability. 01:07:06.250 --> 01:07:07.870 align:middle line:90% Now for us, we have 2d. 01:07:07.870 --> 01:07:10.480 align:middle line:84% D is polylog n, like the depth of the circuit. 01:07:10.480 --> 01:07:18.352 align:middle line:90% So for us, our soundness is-- 01:07:18.352 --> 01:07:19.810 align:middle line:84% I'm just doing it with union bound. 01:07:19.810 --> 01:07:21.780 align:middle line:90% So to cheat, there exists-- 01:07:21.780 --> 01:07:25.740 align:middle line:84% needs to be at least a kind of on sum check protocol 01:07:25.740 --> 01:07:27.220 align:middle line:90% for which you cheated on. 01:07:27.220 --> 01:07:29.830 align:middle line:90% So you get by union bound. 01:07:29.830 --> 01:07:34.290 align:middle line:84% So we have 2d sum checks, and then, therefore, 01:07:34.290 --> 01:07:47.810 align:middle line:84% the soundness is 2d times 3m H divided by F. 01:07:47.810 --> 01:07:50.130 align:middle line:84% So now if we want soundness half-- 01:07:50.130 --> 01:07:52.940 align:middle line:84% let's say we want F so that you can repeat to increase 01:07:52.940 --> 01:07:56.390 align:middle line:84% the soundness-- all we need is that F-- 01:07:56.390 --> 01:07:59.600 align:middle line:84% so if we want this to be smaller than half, 01:07:59.600 --> 01:08:08.070 align:middle line:84% then we need F to be bigger than 12d m H But that's good. 01:08:08.070 --> 01:08:09.860 align:middle line:90% This is log n. 01:08:09.860 --> 01:08:11.390 align:middle line:84% I don't know if you guys can see. 01:08:11.390 --> 01:08:12.780 align:middle line:90% Log s-- sorry. 01:08:12.780 --> 01:08:15.440 align:middle line:90% This is smaller than log s. 01:08:15.440 --> 01:08:18.270 align:middle line:90% This is some polylog s. 01:08:18.270 --> 01:08:20.939 align:middle line:84% So just make it bigger than all of them. 01:08:20.939 --> 01:08:24.000 align:middle line:90% It's still polylog. 01:08:24.000 --> 01:08:26.760 align:middle line:84% And polylog s is good enough, because then 01:08:26.760 --> 01:08:28.130 align:middle line:90% after them is poly s. 01:08:28.130 --> 01:08:42.010 align:middle line:90% 01:08:42.010 --> 01:08:44.127 align:middle line:90% So this was soundness. 01:08:44.127 --> 01:08:44.794 align:middle line:90% AUDIENCE: Sorry. 01:08:44.794 --> 01:08:45.795 align:middle line:90% Why did we need-- 01:08:45.795 --> 01:08:46.920 align:middle line:90% I think I just [INAUDIBLE]. 01:08:46.920 --> 01:08:49.696 align:middle line:84% Why did we need F to the m to be poly s here? 01:08:49.696 --> 01:08:50.500 align:middle line:90% YAEL KALAI: Oh, oh! 01:08:50.500 --> 01:08:50.960 align:middle line:90% Good. 01:08:50.960 --> 01:08:52.959 align:middle line:84% Why do we need-- you're saying, why can't it be bigger? 01:08:52.959 --> 01:08:53.350 align:middle line:90% AUDIENCE: Yeah. 01:08:53.350 --> 01:08:54.620 align:middle line:90% YAEL KALAI: Because-- good. 01:08:54.620 --> 01:08:58.180 align:middle line:84% Because we want our PCP to be-- so the question is, just 01:08:58.180 --> 01:08:59.950 align:middle line:84% to recap, why do we need-- why do 01:08:59.950 --> 01:09:01.720 align:middle line:90% we insist that F is not bigger? 01:09:01.720 --> 01:09:04.130 align:middle line:84% Why does it have to be polynomially related to F? 01:09:04.130 --> 01:09:07.819 align:middle line:84% And the reason is we want the PCP to be of type poly s. 01:09:07.819 --> 01:09:11.439 align:middle line:90% We want the PCP a to be-- 01:09:11.439 --> 01:09:12.800 align:middle line:90% we want it to be efficient. 01:09:12.800 --> 01:09:15.939 align:middle line:84% We want to efficiently convert a witness to a PCP. 01:09:15.939 --> 01:09:20.630 align:middle line:84% And the PCP grows with F to the m much more. 01:09:20.630 --> 01:09:21.910 align:middle line:90% It's like F to the 3m. 01:09:21.910 --> 01:09:23.319 align:middle line:90% And it needs to be repeated. 01:09:23.319 --> 01:09:27.430 align:middle line:90% And F to the m is poly-- 01:09:27.430 --> 01:09:33.790 align:middle line:84% if this is bigger than poly, if F is more than poly H, 01:09:33.790 --> 01:09:37.729 align:middle line:84% then F to the m will be more than poly H to the m. 01:09:37.729 --> 01:09:41.050 align:middle line:84% So that's why we want it to be-- it's for the sake of efficiency 01:09:41.050 --> 01:09:44.260 align:middle line:84% for the PCP to be small or polynomial 01:09:44.260 --> 01:09:47.040 align:middle line:90% related to the circuit. 01:09:47.040 --> 01:09:49.660 align:middle line:84% AUDIENCE: Just so I understand, so here you're 01:09:49.660 --> 01:09:51.830 align:middle line:84% saying that the randomness complexity is polylog n. 01:09:51.830 --> 01:09:54.492 align:middle line:84% Now, normally, you'd be like, the proof size is just 2 01:09:54.492 --> 01:09:55.700 align:middle line:90% to the randomness complexity. 01:09:55.700 --> 01:09:57.370 align:middle line:84% But here, you've been more smart, right? 01:09:57.370 --> 01:09:59.740 align:middle line:84% You've found a way to make the pair shorter 01:09:59.740 --> 01:10:01.070 align:middle line:90% than it would be otherwise. 01:10:01.070 --> 01:10:01.365 align:middle line:90% YAEL KALAI: OK. 01:10:01.365 --> 01:10:02.073 align:middle line:90% Good, good, good. 01:10:02.073 --> 01:10:05.030 align:middle line:84% So now let's go to the-- we didn't do the complexity yet, 01:10:05.030 --> 01:10:09.400 align:middle line:84% but yeah, you're a bit ahead of me, but you're totally right. 01:10:09.400 --> 01:10:10.910 align:middle line:84% So far we've talked about soundness. 01:10:10.910 --> 01:10:13.553 align:middle line:84% Completeness is one, because the GKR is complete. 01:10:13.553 --> 01:10:14.470 align:middle line:90% It has completeness 1. 01:10:14.470 --> 01:10:16.390 align:middle line:84% So the sum check has completeness 1. 01:10:16.390 --> 01:10:17.210 align:middle line:90% So we're good. 01:10:17.210 --> 01:10:18.510 align:middle line:90% We talked about sum checks. 01:10:18.510 --> 01:10:19.820 align:middle line:90% Any question about soundness? 01:10:19.820 --> 01:10:21.200 align:middle line:84% Any question about the soundness? 01:10:21.200 --> 01:10:24.330 align:middle line:90% 01:10:24.330 --> 01:10:26.580 align:middle line:90% Let's talk about the complexity. 01:10:26.580 --> 01:10:29.700 align:middle line:84% So the randomness complexity in the communi-- 01:10:29.700 --> 01:10:31.990 align:middle line:90% and the query complexity. 01:10:31.990 --> 01:10:35.110 align:middle line:84% So how much query and randomness do we need? 01:10:35.110 --> 01:10:39.880 align:middle line:84% So the randomness complexity is-- 01:10:39.880 --> 01:10:44.966 align:middle line:84% well, there's 2d-- so let's put here randomness. 01:10:44.966 --> 01:10:51.790 align:middle line:90% 01:10:51.790 --> 01:10:54.680 align:middle line:90% So there's 2d sum checks. 01:10:54.680 --> 01:10:58.780 align:middle line:84% So the verifier kind of interacts with his oracle on 2d 01:10:58.780 --> 01:10:59.630 align:middle line:90% sum checks. 01:10:59.630 --> 01:11:04.070 align:middle line:84% So for each 2d sum check, he needs to toss coins. 01:11:04.070 --> 01:11:05.940 align:middle line:84% Now, how much coins does he toss? 01:11:05.940 --> 01:11:11.720 align:middle line:84% Well, he needs to generate r random in F to the 3m. 01:11:11.720 --> 01:11:13.120 align:middle line:90% That's each sum check. 01:11:13.120 --> 01:11:15.400 align:middle line:90% You need-- so it's F-- 01:11:15.400 --> 01:11:20.420 align:middle line:84% it's like 3m log F bits of randomness. 01:11:20.420 --> 01:11:25.880 align:middle line:84% Now, this is really polylog F. It's like polylog s. 01:11:25.880 --> 01:11:28.350 align:middle line:90% It's not log s. 01:11:28.350 --> 01:11:36.860 align:middle line:84% This is really poly, poly log s, not just log s. 01:11:36.860 --> 01:11:38.210 align:middle line:90% So one can be weighed. 01:11:38.210 --> 01:11:40.610 align:middle line:84% We need to be careful, because, are we sure 01:11:40.610 --> 01:11:42.330 align:middle line:84% we're getting an efficient PCP here? 01:11:42.330 --> 01:11:43.650 align:middle line:90% It's a lot of randomness. 01:11:43.650 --> 01:11:45.590 align:middle line:84% Are we sure there's no blow up in PCP? 01:11:45.590 --> 01:11:47.610 align:middle line:84% And the reason there's no blow up, 01:11:47.610 --> 01:11:53.000 align:middle line:84% the reason we have large randomness, yet the PCP is small 01:11:53.000 --> 01:11:58.700 align:middle line:84% is exactly because GKR has this property of forgetting. 01:11:58.700 --> 01:12:02.000 align:middle line:84% The fact we actually don't need to open the entire tree, 01:12:02.000 --> 01:12:06.020 align:middle line:84% because of that, we use an additional property. 01:12:06.020 --> 01:12:11.247 align:middle line:84% The point is if you know nothing about the PCP, then, of course, 01:12:11.247 --> 01:12:13.330 align:middle line:84% as I said, if it's order log s bits of randomness, 01:12:13.330 --> 01:12:14.955 align:middle line:90% it's always F poly s. 01:12:14.955 --> 01:12:17.080 align:middle line:84% But the fact that there are more bits of randomness 01:12:17.080 --> 01:12:20.120 align:middle line:84% does not necessarily force our PCP to be bigger. 01:12:20.120 --> 01:12:22.870 align:middle line:84% We're just not going to open it trivially. 01:12:22.870 --> 01:12:25.862 align:middle line:84% If we did open it trivially, then we 01:12:25.862 --> 01:12:27.070 align:middle line:90% would look at all the random. 01:12:27.070 --> 01:12:28.640 align:middle line:84% It'd be a huge tree, like the depth. 01:12:28.640 --> 01:12:31.160 align:middle line:84% But because we do pack it efficiently, 01:12:31.160 --> 01:12:33.430 align:middle line:84% we're able to get a small PCP, even though we 01:12:33.430 --> 01:12:35.797 align:middle line:90% have a lot of randomness. 01:12:35.797 --> 01:12:37.880 align:middle line:84% AUDIENCE: Is it because you're saying each tree is 01:12:37.880 --> 01:12:39.447 align:middle line:90% sized poly and then poly trees? 01:12:39.447 --> 01:12:40.280 align:middle line:90% YAEL KALAI: Exactly. 01:12:40.280 --> 01:12:43.590 align:middle line:84% Each tree is size poly, and they're poly trees. 01:12:43.590 --> 01:12:46.940 align:middle line:84% And we're not-- there's a more straightforward way 01:12:46.940 --> 01:12:49.940 align:middle line:84% to do it is for each tree, append, append. 01:12:49.940 --> 01:12:53.430 align:middle line:84% No, we're kind of doing them in chunks. 01:12:53.430 --> 01:12:56.520 align:middle line:90% And so we get the efficiency. 01:12:56.520 --> 01:13:00.060 align:middle line:90% 01:13:00.060 --> 01:13:02.196 align:middle line:84% Let's go for the query complexity. 01:13:02.196 --> 01:13:06.573 align:middle line:90% 01:13:06.573 --> 01:13:07.490 align:middle line:90% I'll just put it here. 01:13:07.490 --> 01:13:10.660 align:middle line:90% 01:13:10.660 --> 01:13:12.100 align:middle line:90% So let's see. 01:13:12.100 --> 01:13:14.110 align:middle line:84% So for-- again, what's the query? 01:13:14.110 --> 01:13:14.890 align:middle line:90% He does GKR. 01:13:14.890 --> 01:13:18.370 align:middle line:90% So he does 2d sum checks. 01:13:18.370 --> 01:13:24.250 align:middle line:84% For each sum check, he needs to read what the answer is. 01:13:24.250 --> 01:13:29.300 align:middle line:84% Each answer, so there's 3m rounds that he needs to read. 01:13:29.300 --> 01:13:33.400 align:middle line:84% In each answer, he gets kind of a univariate polynomial 01:13:33.400 --> 01:13:36.190 align:middle line:90% of small degree. 01:13:36.190 --> 01:13:38.150 align:middle line:84% Each answer is not just one field element. 01:13:38.150 --> 01:13:39.625 align:middle line:84% It's actually a few field elements. 01:13:39.625 --> 01:13:48.210 align:middle line:90% 01:13:48.210 --> 01:14:00.940 align:middle line:84% So he gets log F elements times the degree, 01:14:00.940 --> 01:14:06.230 align:middle line:84% which will be in each sum check like poly H at most. 01:14:06.230 --> 01:14:09.730 align:middle line:84% And this, again, goes back to the golden eye of what's exactly 01:14:09.730 --> 01:14:11.710 align:middle line:90% the degree of the add i multi. 01:14:11.710 --> 01:14:12.740 align:middle line:90% It's polynomial. 01:14:12.740 --> 01:14:14.170 align:middle line:84% So I'm not-- it's polynomial in H. 01:14:14.170 --> 01:14:21.730 align:middle line:84% It's polylog H. I don't want to-- this is the degree of each 01:14:21.730 --> 01:14:24.346 align:middle line:90% of the sum check polynomial. 01:14:24.346 --> 01:14:27.010 align:middle line:90% 01:14:27.010 --> 01:14:29.830 align:middle line:84% And the degree is affected by the add i multi, which 01:14:29.830 --> 01:14:36.580 align:middle line:84% we assumed the degree is poly H. But it's still, again, polylog. 01:14:36.580 --> 01:14:44.380 align:middle line:84% So this gives-- so before we take a break, let me-- 01:14:44.380 --> 01:14:46.300 align:middle line:90% where are we now? 01:14:46.300 --> 01:14:50.620 align:middle line:84% So we studied the-- we started, actually, 01:14:50.620 --> 01:14:53.660 align:middle line:84% this class by looking at sum check. 01:14:53.660 --> 01:14:55.618 align:middle line:84% And so I started this class with a regular look 01:14:55.618 --> 01:14:57.640 align:middle line:90% that sum check is a miracle. 01:14:57.640 --> 01:15:00.160 align:middle line:84% Given sum check, it gives you everything, everything. 01:15:00.160 --> 01:15:03.350 align:middle line:90% And I hope that now you see why. 01:15:03.350 --> 01:15:04.570 align:middle line:90% So we start by sum check. 01:15:04.570 --> 01:15:07.280 align:middle line:84% And we looked at sum checks like, who cares? 01:15:07.280 --> 01:15:10.150 align:middle line:84% This sum, modal it seems like why would we 01:15:10.150 --> 01:15:14.780 align:middle line:84% need to sum over so many multivariate polynomial? 01:15:14.780 --> 01:15:16.178 align:middle line:90% Where does that come up? 01:15:16.178 --> 01:15:16.720 align:middle line:90% I don't know. 01:15:16.720 --> 01:15:19.750 align:middle line:84% It was like, why am I learning this? 01:15:19.750 --> 01:15:22.370 align:middle line:90% So now what did we do with it? 01:15:22.370 --> 01:15:24.520 align:middle line:90% We started with sum check. 01:15:24.520 --> 01:15:29.090 align:middle line:84% We saw just by doing sum check repeatedly, 01:15:29.090 --> 01:15:32.890 align:middle line:84% you can verify any low depth computation. 01:15:32.890 --> 01:15:34.350 align:middle line:90% That's pretty amazing. 01:15:34.350 --> 01:15:38.120 align:middle line:84% And then we saw that, actually, you can recover the IP equals 01:15:38.120 --> 01:15:41.850 align:middle line:84% space space theorem, that GKR actually gives you the IP equals 01:15:41.850 --> 01:15:42.750 align:middle line:90% space space theorem. 01:15:42.750 --> 01:15:47.930 align:middle line:84% And now we see GKR actually gives you PCP. 01:15:47.930 --> 01:15:48.860 align:middle line:90% And what is GKR? 01:15:48.860 --> 01:15:51.310 align:middle line:90% It's just sum checks. 01:15:51.310 --> 01:15:54.870 align:middle line:84% So just these sum checks, you kind of 01:15:54.870 --> 01:15:56.610 align:middle line:84% unroll them-- unravel them, and you get 01:15:56.610 --> 01:16:00.040 align:middle line:90% a PCP with polylog n queries. 01:16:00.040 --> 01:16:01.510 align:middle line:90% And not-- it's like efficient. 01:16:01.510 --> 01:16:05.320 align:middle line:84% You can take your input, your witness, and efficiently 01:16:05.320 --> 01:16:07.610 align:middle line:90% generate this PCP. 01:16:07.610 --> 01:16:11.160 align:middle line:90% And in a very-- 01:16:11.160 --> 01:16:14.070 align:middle line:84% like, a straightforward way in a sense. 01:16:14.070 --> 01:16:15.490 align:middle line:90% You do your computation. 01:16:15.490 --> 01:16:16.570 align:middle line:90% You have your witness. 01:16:16.570 --> 01:16:17.830 align:middle line:90% You do the computation. 01:16:17.830 --> 01:16:19.680 align:middle line:84% You do all the low-degree extensions. 01:16:19.680 --> 01:16:22.320 align:middle line:90% And you convince round by round. 01:16:22.320 --> 01:16:24.518 align:middle line:84% You just lay it out, and that's it. 01:16:24.518 --> 01:16:25.310 align:middle line:90% And you have a PCP. 01:16:25.310 --> 01:16:29.760 align:middle line:90% 01:16:29.760 --> 01:16:31.930 align:middle line:90% Any questions about? 01:16:31.930 --> 01:16:35.020 align:middle line:84% AUDIENCE: So the fact that the GKR tree can be extended, 01:16:35.020 --> 01:16:38.290 align:middle line:84% that relies on just the fact that it consists of these kind 01:16:38.290 --> 01:16:41.680 align:middle line:84% of independent subjects, or also the fact that subject itself 01:16:41.680 --> 01:16:43.772 align:middle line:84% has-- like, each query is just a random-- 01:16:43.772 --> 01:16:44.980 align:middle line:90% YAEL KALAI: Good, good, good. 01:16:44.980 --> 01:16:47.050 align:middle line:84% So the question is, again, let's understand 01:16:47.050 --> 01:16:50.710 align:middle line:84% why do we get this PCP that's efficient. 01:16:50.710 --> 01:16:53.110 align:middle line:84% Why do we get only poly-sized PCP? 01:16:53.110 --> 01:16:56.190 align:middle line:84% And the reason we get-- it's two-- both, twofold. 01:16:56.190 --> 01:16:57.810 align:middle line:90% You said both reasons. 01:16:57.810 --> 01:17:02.530 align:middle line:84% Reason number one, when we do each sum check, after that, 01:17:02.530 --> 01:17:04.520 align:middle line:84% we can forget about this randomness. 01:17:04.520 --> 01:17:06.670 align:middle line:90% And for each Vi consider. 01:17:06.670 --> 01:17:12.130 align:middle line:84% So we really need to write down only kind of d times F 01:17:12.130 --> 01:17:13.960 align:middle line:90% to the m sum checks. 01:17:13.960 --> 01:17:18.020 align:middle line:84% That's the depth of the circuit times F to the sum checks. 01:17:18.020 --> 01:17:18.800 align:middle line:90% That's number one. 01:17:18.800 --> 01:17:20.960 align:middle line:84% But number two, why is the sum check? 01:17:20.960 --> 01:17:22.550 align:middle line:84% Can we write out all the sum checks? 01:17:22.550 --> 01:17:25.030 align:middle line:84% I mean, the sum check is also an interactive protocol. 01:17:25.030 --> 01:17:28.720 align:middle line:84% Can we actually open it up and write the entire thing? 01:17:28.720 --> 01:17:34.190 align:middle line:84% And the answer is, well, yeah, but at an exponential cost. 01:17:34.190 --> 01:17:38.180 align:middle line:84% But an exponential cost in m, the number of variables. 01:17:38.180 --> 01:17:41.320 align:middle line:84% But here, the number of variables is log. 01:17:41.320 --> 01:17:42.370 align:middle line:90% That's important. 01:17:42.370 --> 01:17:45.670 align:middle line:84% If m was polylog, we would have been doomed. 01:17:45.670 --> 01:17:52.390 align:middle line:84% But m-- or I mean, OK, it's not just log. 01:17:52.390 --> 01:17:54.650 align:middle line:84% We set the parameters so that it's OK. 01:17:54.650 --> 01:17:55.670 align:middle line:90% That's what we needed. 01:17:55.670 --> 01:17:58.730 align:middle line:84% That's exactly-- so why can we open up this entire sum check? 01:17:58.730 --> 01:18:03.940 align:middle line:84% It's because we set F to be poly H, and H to the m is S. 01:18:03.940 --> 01:18:08.050 align:middle line:84% So we set it up so that opening the sum check 01:18:08.050 --> 01:18:16.610 align:middle line:84% requires F to the m kind of answers, F to the m answers. 01:18:16.610 --> 01:18:19.550 align:middle line:84% Each one is kind of a low-degree polynomial, but that's fine, 01:18:19.550 --> 01:18:22.930 align:middle line:84% but F to the m of them, or F to the 3m here, because we have-- 01:18:22.930 --> 01:18:25.920 align:middle line:90% the number of variables is 3m. 01:18:25.920 --> 01:18:28.740 align:middle line:84% And we just need to make sure that F to the 3m is polynomial. 01:18:28.740 --> 01:18:32.290 align:middle line:84% And to ensure that, we did do some parameter engineering. 01:18:32.290 --> 01:18:35.490 align:middle line:84% That's why we didn't go the natural route of taking 01:18:35.490 --> 01:18:38.168 align:middle line:90% H to be 2 and m to be log s. 01:18:38.168 --> 01:18:40.210 align:middle line:84% That would be natural, but then we would not get. 01:18:40.210 --> 01:18:43.470 align:middle line:84% So we actually did need to do some kind of engineering 01:18:43.470 --> 01:18:47.430 align:middle line:84% and parameters, like an annoying fiddling of parameters. 01:18:47.430 --> 01:18:52.500 align:middle line:84% This setting of parameters that you see over and over in any PCP 01:18:52.500 --> 01:18:54.990 align:middle line:84% construction, this is-- we're not the first. 01:18:54.990 --> 01:18:58.120 align:middle line:84% We're actually the last, if anything, to come-- to use this. 01:18:58.120 --> 01:19:03.110 align:middle line:84% This was used in the '90s in the early PCP constructions. 01:19:03.110 --> 01:19:06.210 align:middle line:84% And it's when you look at it first, like, really? 01:19:06.210 --> 01:19:08.168 align:middle line:90% Like, log n over log log n? 01:19:08.168 --> 01:19:08.960 align:middle line:90% Are you kidding me? 01:19:08.960 --> 01:19:10.627 align:middle line:84% Like, couldn't you find something nicer? 01:19:10.627 --> 01:19:15.190 align:middle line:84% But this is why, because we want these parameters to be poly. 01:19:15.190 --> 01:19:16.450 align:middle line:90% Yeah. 01:19:16.450 --> 01:19:18.010 align:middle line:84% AUDIENCE: So since you're essentially 01:19:18.010 --> 01:19:22.750 align:middle line:84% asking for this to be like a non-adaptive prover, 01:19:22.750 --> 01:19:25.630 align:middle line:84% can you just use the same randomness for each round 01:19:25.630 --> 01:19:27.770 align:middle line:84% and then get rid of the d factor [INAUDIBLE]? 01:19:27.770 --> 01:19:28.520 align:middle line:90% YAEL KALAI: Sorry. 01:19:28.520 --> 01:19:29.562 align:middle line:90% So you're saying-- sorry. 01:19:29.562 --> 01:19:32.480 align:middle line:84% Your question is-- you're saying-- 01:19:32.480 --> 01:19:36.160 align:middle line:84% are you talking about the fact that this verifier 01:19:36.160 --> 01:19:37.090 align:middle line:90% is non-adaptive? 01:19:37.090 --> 01:19:39.590 align:middle line:84% AUDIENCE: Or that the prover is non-adaptive, I guess. 01:19:39.590 --> 01:19:42.610 align:middle line:84% YAEL KALAI: The prover in that-- yes, like it's 01:19:42.610 --> 01:19:45.728 align:middle line:84% non-adaptive in the previous sum checks. 01:19:45.728 --> 01:19:47.020 align:middle line:90% AUDIENCE: [INAUDIBLE] previous. 01:19:47.020 --> 01:19:47.810 align:middle line:90% YAEL KALAI: Previous sum checks. 01:19:47.810 --> 01:19:48.910 align:middle line:90% yeah, so then what? 01:19:48.910 --> 01:19:51.800 align:middle line:84% AUDIENCE: Can you use the same randomness for each round? 01:19:51.800 --> 01:19:53.080 align:middle line:84% Like, what would happen if you use the same randomness? 01:19:53.080 --> 01:19:53.990 align:middle line:90% YAEL KALAI: No. 01:19:53.990 --> 01:19:54.712 align:middle line:90% OK, OK. 01:19:54.712 --> 01:19:55.670 align:middle line:90% That's a good question. 01:19:55.670 --> 01:19:57.045 align:middle line:84% So you're asking-- you're saying, 01:19:57.045 --> 01:19:59.680 align:middle line:84% look, we're doing the sum check d times. 01:19:59.680 --> 01:20:01.940 align:middle line:84% Can't we use the same randomness? 01:20:01.940 --> 01:20:03.230 align:middle line:90% And the answer is we cannot. 01:20:03.230 --> 01:20:03.730 align:middle line:90% Why? 01:20:03.730 --> 01:20:05.950 align:middle line:84% Because you should think if we use 01:20:05.950 --> 01:20:08.750 align:middle line:84% the same randomness for different rounds, 01:20:08.750 --> 01:20:11.450 align:middle line:84% then you should think of, I'm a prover. 01:20:11.450 --> 01:20:17.550 align:middle line:84% I'm like, oh, you're going to use the same randomness for all 01:20:17.550 --> 01:20:18.050 align:middle line:90% your rounds. 01:20:18.050 --> 01:20:20.200 align:middle line:84% I know that, because you're telling me already, 01:20:20.200 --> 01:20:22.075 align:middle line:84% that you're going to use the same randomness. 01:20:22.075 --> 01:20:25.180 align:middle line:84% So now in the first round, I'm going to behave, honestly, 01:20:25.180 --> 01:20:26.600 align:middle line:90% just to learn your randomness. 01:20:26.600 --> 01:20:28.310 align:middle line:90% Give you-- I'm sorry. 01:20:28.310 --> 01:20:29.310 align:middle line:90% I'm not going to behave. 01:20:29.310 --> 01:20:31.135 align:middle line:84% I'm going to cheat in the first round. 01:20:31.135 --> 01:20:32.510 align:middle line:84% So of course, I'm going to cheat. 01:20:32.510 --> 01:20:34.940 align:middle line:84% The output is 1, even though it's 0. 01:20:34.940 --> 01:20:38.630 align:middle line:84% I'm going to manage to convince you in the first kind of-- 01:20:38.630 --> 01:20:42.230 align:middle line:84% in the first sum check I do, because I'm just 01:20:42.230 --> 01:20:44.790 align:middle line:84% going to lie consistently with myself. 01:20:44.790 --> 01:20:46.790 align:middle line:84% I'll write to Vi minus-- to the next layer, 01:20:46.790 --> 01:20:48.740 align:middle line:84% and the wrong-- still inconsistent. 01:20:48.740 --> 01:20:53.150 align:middle line:84% But now I know the randomness, because you're going to reuse. 01:20:53.150 --> 01:20:55.560 align:middle line:84% You see, the point is the following. 01:20:55.560 --> 01:21:02.750 align:middle line:84% The verifier here should behave like an honest verifier 01:21:02.750 --> 01:21:03.950 align:middle line:90% in the GKR. 01:21:03.950 --> 01:21:07.100 align:middle line:84% If the verifier here, you cannot-- 01:21:07.100 --> 01:21:10.790 align:middle line:84% when you use this verifier, he essentially 01:21:10.790 --> 01:21:13.077 align:middle line:90% behaves like a GKR verifier. 01:21:13.077 --> 01:21:14.910 align:middle line:84% So now you're telling-- you're saying, look, 01:21:14.910 --> 01:21:17.300 align:middle line:84% why doesn't he use the same randomness 01:21:17.300 --> 01:21:20.910 align:middle line:90% for the different subprotocols? 01:21:20.910 --> 01:21:23.730 align:middle line:84% Because if he did a GKR, then he would fail. 01:21:23.730 --> 01:21:27.080 align:middle line:84% Then a cheating prover can take advantage of him. 01:21:27.080 --> 01:21:28.580 align:middle line:84% AUDIENCE: Isn't there the difference 01:21:28.580 --> 01:21:30.770 align:middle line:84% here that this prover is not adaptive? 01:21:30.770 --> 01:21:32.420 align:middle line:84% It doesn't remember the randomness. 01:21:32.420 --> 01:21:37.180 align:middle line:84% All it depends on is V tilde i minus 1. 01:21:37.180 --> 01:21:38.245 align:middle line:90% YAEL KALAI: Right. 01:21:38.245 --> 01:21:40.120 align:middle line:84% AUDIENCE: So you can't just be like, oh, this 01:21:40.120 --> 01:21:40.850 align:middle line:90% is the randomness. 01:21:40.850 --> 01:21:41.145 align:middle line:90% [INAUDIBLE] 01:21:41.145 --> 01:21:41.990 align:middle line:90% YAEL KALAI: Oh, I see. 01:21:41.990 --> 01:21:42.860 align:middle line:90% You're saying-- I see. 01:21:42.860 --> 01:21:43.160 align:middle line:90% I see. 01:21:43.160 --> 01:21:43.640 align:middle line:90% OK, OK. 01:21:43.640 --> 01:21:44.932 align:middle line:90% Now I understand your question. 01:21:44.932 --> 01:21:50.900 align:middle line:84% You're saying, this guy, this prover is stuck. 01:21:50.900 --> 01:21:51.600 align:middle line:90% Sorry. 01:21:51.600 --> 01:21:53.100 align:middle line:84% Now I understand what you're saying. 01:21:53.100 --> 01:21:55.570 align:middle line:84% You're saying, look, you're tying the hand of this prover. 01:21:55.570 --> 01:21:59.540 align:middle line:90% The prover in GKR, he has power. 01:21:59.540 --> 01:22:01.010 align:middle line:90% He sees your randomness. 01:22:01.010 --> 01:22:02.468 align:middle line:84% And based on that, he can continue. 01:22:02.468 --> 01:22:04.302 align:middle line:84% The honest prover, of course, won't do that. 01:22:04.302 --> 01:22:05.680 align:middle line:90% But the cheating prover may. 01:22:05.680 --> 01:22:07.180 align:middle line:84% Here, you're saying, I'm not going 01:22:07.180 --> 01:22:09.020 align:middle line:90% to let the prover do that to me. 01:22:09.020 --> 01:22:10.750 align:middle line:84% I'm going to force him to forget. 01:22:10.750 --> 01:22:13.870 align:middle line:84% Because I forced him to forget, can I 01:22:13.870 --> 01:22:15.620 align:middle line:84% think of using the same randomness? 01:22:15.620 --> 01:22:18.190 align:middle line:84% That's a good question, actually. 01:22:18.190 --> 01:22:19.610 align:middle line:90% A great-- very good question. 01:22:19.610 --> 01:22:21.652 align:middle line:84% It took me time to understand what you're asking. 01:22:21.652 --> 01:22:24.937 align:middle line:90% 01:22:24.937 --> 01:22:26.270 align:middle line:90% AUDIENCE: Can you use the same-- 01:22:26.270 --> 01:22:27.140 align:middle line:90% YAEL KALAI: It's a great-- 01:22:27.140 --> 01:22:27.700 align:middle line:90% great point. 01:22:27.700 --> 01:22:29.367 align:middle line:84% AUDIENCE: --that same malicious verifier 01:22:29.367 --> 01:22:30.650 align:middle line:90% you just said to break that? 01:22:30.650 --> 01:22:34.368 align:middle line:90% YAEL KALAI: Well, no, because-- 01:22:34.368 --> 01:22:35.660 align:middle line:90% so your point is the following. 01:22:35.660 --> 01:22:36.590 align:middle line:90% You know what? 01:22:36.590 --> 01:22:39.320 align:middle line:84% Use the same randomness in all the subprotocols. 01:22:39.320 --> 01:22:42.720 align:middle line:84% Now, in the GKR, it's a big problem, because the prover, 01:22:42.720 --> 01:22:43.988 align:middle line:90% he knows what you saw. 01:22:43.988 --> 01:22:44.780 align:middle line:90% And he'll use that. 01:22:44.780 --> 01:22:45.800 align:middle line:90% He knows the randomness. 01:22:45.800 --> 01:22:52.915 align:middle line:84% But in the PCP, the PCP GKR prover, his hands are tied. 01:22:52.915 --> 01:22:53.540 align:middle line:90% AUDIENCE: Yeah. 01:22:53.540 --> 01:22:54.960 align:middle line:90% But the fact that he-- 01:22:54.960 --> 01:22:57.290 align:middle line:84% if the prover knows that you're going to do this, 01:22:57.290 --> 01:22:59.540 align:middle line:84% then he might be able to engineer all of his responses 01:22:59.540 --> 01:23:01.970 align:middle line:84% in a way that takes advantage of the correlation 01:23:01.970 --> 01:23:03.080 align:middle line:90% of the randomness. 01:23:03.080 --> 01:23:03.440 align:middle line:90% AUDIENCE: Exactly. 01:23:03.440 --> 01:23:04.982 align:middle line:84% You think the same verifier you said. 01:23:04.982 --> 01:23:08.310 align:middle line:84% Pretend you have that verifier that cheats [INAUDIBLE] 01:23:08.310 --> 01:23:09.410 align:middle line:90% use the same randomness. 01:23:09.410 --> 01:23:13.570 align:middle line:84% Now, this tree follows that verifier's strategy. 01:23:13.570 --> 01:23:14.970 align:middle line:90% Then shouldn't that break it? 01:23:14.970 --> 01:23:17.595 align:middle line:84% AUDIENCE: Even if it doesn't follow just a GKR soundness. 01:23:17.595 --> 01:23:18.220 align:middle line:90% AUDIENCE: Yeah. 01:23:18.220 --> 01:23:20.540 align:middle line:84% I mean, it is-- it could be some, 01:23:20.540 --> 01:23:22.990 align:middle line:84% but yeah, there's this correlation 01:23:22.990 --> 01:23:25.390 align:middle line:84% between the randomness, which the prover would 01:23:25.390 --> 01:23:26.610 align:middle line:90% know about in advance, right? 01:23:26.610 --> 01:23:28.610 align:middle line:84% So even though he can't remember the randomness, 01:23:28.610 --> 01:23:30.943 align:middle line:84% he can engineer a strategy to take advantage of the fact 01:23:30.943 --> 01:23:32.720 align:middle line:90% that the randomness repeats. 01:23:32.720 --> 01:23:34.750 align:middle line:84% YAEL KALAI: Let me say the following 01:23:34.750 --> 01:23:36.430 align:middle line:90% to close the discussion. 01:23:36.430 --> 01:23:38.480 align:middle line:84% A, the discussion is super interesting. 01:23:38.480 --> 01:23:41.990 align:middle line:84% The question you raised is super interesting. 01:23:41.990 --> 01:23:45.420 align:middle line:84% You know, we have one P set in this class. 01:23:45.420 --> 01:23:46.580 align:middle line:90% [LAUGHTER] 01:23:46.580 --> 01:23:49.225 align:middle line:84% You gave me a great idea for a question. 01:23:49.225 --> 01:23:52.130 align:middle line:90% 01:23:52.130 --> 01:23:54.653 align:middle line:84% By the way, before we break, I just 01:23:54.653 --> 01:23:56.070 align:middle line:84% want to make a quick announcement. 01:23:56.070 --> 01:24:00.785 align:middle line:84% So I wrote in the website that the P set will come later 01:24:00.785 --> 01:24:02.660 align:middle line:84% during this class, because I thought it would 01:24:02.660 --> 01:24:05.650 align:middle line:90% be good to cover more material. 01:24:05.650 --> 01:24:09.500 align:middle line:84% But I know that I wrote it pretty close to the break. 01:24:09.500 --> 01:24:15.950 align:middle line:84% And maybe that's-- so maybe I'll put it out earlier, 01:24:15.950 --> 01:24:19.500 align:middle line:84% give you two weeks, just because I don't want you to sit with it 01:24:19.500 --> 01:24:20.000 align:middle line:90% too long. 01:24:20.000 --> 01:24:20.630 align:middle line:90% It's just annoying. 01:24:20.630 --> 01:24:22.790 align:middle line:84% But if you feel like the time just doesn't work, 01:24:22.790 --> 01:24:24.850 align:middle line:84% and you want an extension, just let me know. 01:24:24.850 --> 01:24:27.045 align:middle line:84% I don't really care, to tell you the truth. 01:24:27.045 --> 01:24:28.420 align:middle line:84% I just want you to think about it 01:24:28.420 --> 01:24:30.590 align:middle line:90% and have fun with the material. 01:24:30.590 --> 01:24:31.150 align:middle line:90% Yeah. 01:24:31.150 --> 01:24:32.567 align:middle line:84% AUDIENCE: When we argue soundness, 01:24:32.567 --> 01:24:34.457 align:middle line:84% are we using any sort of union bound lexeme? 01:24:34.457 --> 01:24:35.540 align:middle line:90% YAEL KALAI: Yeah, exactly. 01:24:35.540 --> 01:24:36.623 align:middle line:90% We're doing a union bound. 01:24:36.623 --> 01:24:37.580 align:middle line:90% Yes, exactly. 01:24:37.580 --> 01:24:40.340 align:middle line:84% Because in the soundness, we say the following. 01:24:40.340 --> 01:24:45.850 align:middle line:84% We say that in the-- so essentially, 01:24:45.850 --> 01:24:48.460 align:middle line:84% we're talking with the prover and the GKR prover. 01:24:48.460 --> 01:24:50.080 align:middle line:90% And we're saying for the GKR-- 01:24:50.080 --> 01:24:53.930 align:middle line:84% even like a tied GKR prover, as you mentioned, 01:24:53.930 --> 01:24:56.390 align:middle line:84% it's a GKR prover with tied hands. 01:24:56.390 --> 01:25:01.700 align:middle line:84% So for this prover to cheat, he needs-- so the output is false. 01:25:01.700 --> 01:25:03.080 align:middle line:90% That's kind of-- he cheated. 01:25:03.080 --> 01:25:06.300 align:middle line:84% So somewhere, he needs to cheat in one of the GKRs. 01:25:06.300 --> 01:25:09.950 align:middle line:84% One of the sum checks, he needs to go from false to true, 01:25:09.950 --> 01:25:10.850 align:middle line:90% somewhere. 01:25:10.850 --> 01:25:12.692 align:middle line:84% Because at the end, you're verifying. 01:25:12.692 --> 01:25:13.400 align:middle line:90% You're verifying. 01:25:13.400 --> 01:25:15.300 align:middle line:90% He put here a witness. 01:25:15.300 --> 01:25:16.980 align:middle line:90% So he put in this guy a witness. 01:25:16.980 --> 01:25:18.650 align:middle line:84% That witness is false, because there's 01:25:18.650 --> 01:25:19.860 align:middle line:90% no satisfying assignment. 01:25:19.860 --> 01:25:23.250 align:middle line:84% So he put something that's actually false. 01:25:23.250 --> 01:25:23.750 align:middle line:90% Oh! 01:25:23.750 --> 01:25:24.250 align:middle line:90% 1 second. 01:25:24.250 --> 01:25:25.042 align:middle line:90% There is something. 01:25:25.042 --> 01:25:25.680 align:middle line:90% OK, sorry. 01:25:25.680 --> 01:25:26.370 align:middle line:90% Now I remember. 01:25:26.370 --> 01:25:27.180 align:middle line:90% There is something. 01:25:27.180 --> 01:25:28.650 align:middle line:84% There is a low-degree test to do. 01:25:28.650 --> 01:25:29.850 align:middle line:90% We'll get back to that. 01:25:29.850 --> 01:25:32.000 align:middle line:90% Sorry. 01:25:32.000 --> 01:25:33.630 align:middle line:84% We'll get back to the low-degree test. 01:25:33.630 --> 01:25:40.710 align:middle line:84% But so you're talking with a GKR prover. 01:25:40.710 --> 01:25:43.670 align:middle line:84% And this prover, the only way he can convince you 01:25:43.670 --> 01:25:46.890 align:middle line:84% is to go from a false statement to a true statement. 01:25:46.890 --> 01:25:48.770 align:middle line:90% Because at the end, you verif-- 01:25:48.770 --> 01:25:51.910 align:middle line:84% and to do that, you need to break one of the sum checks. 01:25:51.910 --> 01:25:55.130 align:middle line:84% So to break one of the sum checks, you have 2d sum checks. 01:25:55.130 --> 01:25:57.010 align:middle line:84% And I'm using a union bound to say 01:25:57.010 --> 01:26:01.900 align:middle line:84% that the probability that you managed to break one of them 01:26:01.900 --> 01:26:03.760 align:middle line:84% is 2 to the d times the probability 01:26:03.760 --> 01:26:06.660 align:middle line:84% that you managed to break one of them. 01:26:06.660 --> 01:26:08.970 align:middle line:84% AUDIENCE: But then back to the discussion 01:26:08.970 --> 01:26:14.200 align:middle line:84% where you're sharing randomness, so does union bound help here? 01:26:14.200 --> 01:26:15.840 align:middle line:90% YAEL KALAI: You're saying-- 01:26:15.840 --> 01:26:16.540 align:middle line:90% oh! 01:26:16.540 --> 01:26:17.590 align:middle line:90% Because of the-- 01:26:17.590 --> 01:26:19.380 align:middle line:84% AUDIENCE: [INAUDIBLE] dependence of them. 01:26:19.380 --> 01:26:20.005 align:middle line:90% YAEL KALAI: OK. 01:26:20.005 --> 01:26:23.210 align:middle line:84% So is this related to this question? 01:26:23.210 --> 01:26:24.085 align:middle line:90% AUDIENCE: [INAUDIBLE] 01:26:24.085 --> 01:26:25.880 align:middle line:84% YAEL KALAI: Actually, I don't think so, 01:26:25.880 --> 01:26:29.880 align:middle line:84% because union bound, in general, it can be correlated. 01:26:29.880 --> 01:26:32.888 align:middle line:84% A union bound in general says that the probability 01:26:32.888 --> 01:26:35.180 align:middle line:84% that this or this, I don't care how they're correlated. 01:26:35.180 --> 01:26:37.450 align:middle line:84% It's small or equal the probability of this 01:26:37.450 --> 01:26:39.250 align:middle line:90% plus the probability of this. 01:26:39.250 --> 01:26:42.610 align:middle line:84% So the correlation here, the union bound 01:26:42.610 --> 01:26:47.280 align:middle line:84% is very easily used in any situation. 01:26:47.280 --> 01:26:51.310 align:middle line:84% You just have the probability that you have an event. 01:26:51.310 --> 01:26:52.953 align:middle line:90% You cheated on test 1. 01:26:52.953 --> 01:26:53.870 align:middle line:90% You cheated on test 2. 01:26:53.870 --> 01:26:54.830 align:middle line:90% You cheated on test 3. 01:26:54.830 --> 01:26:56.980 align:middle line:84% I don't care how they're correlated. 01:26:56.980 --> 01:26:58.960 align:middle line:84% The probability that you cheated on one of them 01:26:58.960 --> 01:27:02.320 align:middle line:90% is smaller or equal then. 01:27:02.320 --> 01:27:04.800 align:middle line:84% But actually, before we break-- sorry-- 01:27:04.800 --> 01:27:06.815 align:middle line:90% there is a low-degree extension. 01:27:06.815 --> 01:27:07.690 align:middle line:90% AUDIENCE: [INAUDIBLE] 01:27:07.690 --> 01:27:08.130 align:middle line:90% YAEL KALAI: What? 01:27:08.130 --> 01:27:09.540 align:middle line:84% AUDIENCE: In the first [INAUDIBLE]. 01:27:09.540 --> 01:27:10.386 align:middle line:90% YAEL KALAI: Exactly! 01:27:10.386 --> 01:27:13.010 align:middle line:84% AUDIENCE: Because in GKR, you can just use brute force. 01:27:13.010 --> 01:27:13.830 align:middle line:90% YAEL KALAI: Good. 01:27:13.830 --> 01:27:15.270 align:middle line:90% OK, OK, OK. 01:27:15.270 --> 01:27:17.430 align:middle line:90% Sorry. 01:27:17.430 --> 01:27:18.990 align:middle line:90% Good. 01:27:18.990 --> 01:27:20.220 align:middle line:90% I love you guys. 01:27:20.220 --> 01:27:33.730 align:middle line:84% So yeah, V-- check V 0 tilde is low degree, 01:27:33.730 --> 01:27:43.540 align:middle line:84% because in GKR, the verifier has the input, which is the witness. 01:27:43.540 --> 01:27:46.820 align:middle line:84% He computes a little extension by himself. 01:27:46.820 --> 01:27:50.228 align:middle line:84% Here, the prover is giving it to him. 01:27:50.228 --> 01:27:51.770 align:middle line:84% What if you didn't give a low degree? 01:27:51.770 --> 01:27:55.160 align:middle line:90% 01:27:55.160 --> 01:27:58.610 align:middle line:84% So we do need one low-degree test in the input. 01:27:58.610 --> 01:28:01.730 align:middle line:84% Other than that, it's GKR, black box. 01:28:01.730 --> 01:28:04.010 align:middle line:90% But we do need this. 01:28:04.010 --> 01:28:08.240 align:middle line:84% And by the way, note that we're using the GKR, the GKR has 01:28:08.240 --> 01:28:10.950 align:middle line:90% actually properties. 01:28:10.950 --> 01:28:12.710 align:middle line:84% And I want to go back to the succinctness, 01:28:12.710 --> 01:28:14.390 align:middle line:84% because, actually, you're saying, 01:28:14.390 --> 01:28:16.670 align:middle line:84% can't you do it with any succinct protocol? 01:28:16.670 --> 01:28:19.470 align:middle line:90% And the answer is maybe. 01:28:19.470 --> 01:28:21.990 align:middle line:84% But there's also this point, which is problematic, 01:28:21.990 --> 01:28:25.040 align:middle line:84% that in GKR, it's nice because you just 01:28:25.040 --> 01:28:28.920 align:middle line:84% check one point in the low-degree extension. 01:28:28.920 --> 01:28:33.732 align:middle line:84% And we can verify that you do the low-degree extension. 01:28:33.732 --> 01:28:36.190 align:middle line:84% There is a low-degree test that I didn't talk to you about, 01:28:36.190 --> 01:28:37.880 align:middle line:84% but we'll mention that after the break. 01:28:37.880 --> 01:28:41.070 align:middle line:90% So there's a GKR. 01:28:41.070 --> 01:28:42.600 align:middle line:90% You can verify. 01:28:42.600 --> 01:28:46.320 align:middle line:84% The verifier, to verify, all he needs to do is take his input 01:28:46.320 --> 01:28:50.130 align:middle line:84% and compute only two points in the low-degree extension 01:28:50.130 --> 01:28:52.310 align:middle line:90% of that input. 01:28:52.310 --> 01:28:57.070 align:middle line:84% This is actually used here, because now the prover-- 01:28:57.070 --> 01:28:59.490 align:middle line:84% the verifier doesn't have the input, the witness. 01:28:59.490 --> 01:29:01.690 align:middle line:90% The prover has it. 01:29:01.690 --> 01:29:04.000 align:middle line:90% He's going to put in the sky. 01:29:04.000 --> 01:29:06.700 align:middle line:84% And now you can't read the entire input. 01:29:06.700 --> 01:29:07.730 align:middle line:90% That's a witness. 01:29:07.730 --> 01:29:16.290 align:middle line:84% But you can read what the kind of succinct protocol 01:29:16.290 --> 01:29:17.290 align:middle line:90% tells you to read. 01:29:17.290 --> 01:29:22.527 align:middle line:84% And so this part is important in the GKR. 01:29:22.527 --> 01:29:29.100 align:middle line:90% 01:29:29.100 --> 01:29:31.310 align:middle line:90% Questions before we break? 01:29:31.310 --> 01:29:33.510 align:middle line:84% So after the-- we'll take a 5-minute break. 01:29:33.510 --> 01:29:36.840 align:middle line:84% And then we'll talk quickly about the low-degree test, 01:29:36.840 --> 01:29:41.500 align:middle line:84% wrap up the information theory, and go to cryptography. 01:29:41.500 --> 01:29:42.000 align:middle line:90%