WEBVTT 00:00:00.000 --> 00:00:05.808 align:middle line:84% [SQUEAKING] [RUSTLING] [CLICKING] 00:00:05.808 --> 00:00:12.590 align:middle line:90% 00:00:12.590 --> 00:00:14.640 align:middle line:84% PROFESSOR: Yes, of course, if we argue-- 00:00:14.640 --> 00:00:17.190 align:middle line:84% if we want to prove to him that x is in the language, 00:00:17.190 --> 00:00:19.340 align:middle line:84% it's essentially we're telling him, 00:00:19.340 --> 00:00:22.770 align:middle line:84% if you evaluate x on circuit C, you will get 1. 00:00:22.770 --> 00:00:25.160 align:middle line:84% Or maybe if there exists a witness 00:00:25.160 --> 00:00:28.260 align:middle line:84% that C of the witness C and x and the witness gives you 1. 00:00:28.260 --> 00:00:30.590 align:middle line:84% Of course, we assume the verifier knows the description 00:00:30.590 --> 00:00:31.970 align:middle line:90% of this circuit C. 00:00:31.970 --> 00:00:34.730 align:middle line:84% And usually, and for our purposes, 00:00:34.730 --> 00:00:38.760 align:middle line:84% you think of C as being a uniform, like a Turing machine. 00:00:38.760 --> 00:00:41.750 align:middle line:84% So it can be generated efficiently 00:00:41.750 --> 00:00:42.960 align:middle line:90% from a Turing machine. 00:00:42.960 --> 00:00:45.320 align:middle line:84% But yes, the verifier can generate-- 00:00:45.320 --> 00:00:49.520 align:middle line:84% both the prover and verifier can generate the circuit. 00:00:49.520 --> 00:00:53.342 align:middle line:84% So if you think of three SAT, the circuit 00:00:53.342 --> 00:00:54.800 align:middle line:84% takes as input all the assignments, 00:00:54.800 --> 00:01:00.488 align:middle line:84% and it checks that all the clauses are satisfied. 00:01:00.488 --> 00:01:01.780 align:middle line:90% That's an example of a circuit. 00:01:01.780 --> 00:01:02.290 align:middle line:90% Yeah, 00:01:02.290 --> 00:01:03.960 align:middle line:84% AUDIENCE: But also checking [INAUDIBLE], 00:01:03.960 --> 00:01:09.265 align:middle line:84% isn't that quite similar to just running that circuit? 00:01:09.265 --> 00:01:10.890 align:middle line:84% PROFESSOR: Yeah, it's like just-- yeah. 00:01:10.890 --> 00:01:12.480 align:middle line:84% So the prover essentially computes 00:01:12.480 --> 00:01:14.580 align:middle line:84% the circuit, all the gates in the circuit, 00:01:14.580 --> 00:01:18.300 align:middle line:84% hashes it, and then gives a BARG that each 00:01:18.300 --> 00:01:21.480 align:middle line:84% and every gate of the circuit is satisfied, 00:01:21.480 --> 00:01:26.550 align:middle line:84% that the value he hashed satisfy each-- 00:01:26.550 --> 00:01:29.427 align:middle line:90% respect each gate. 00:01:29.427 --> 00:01:31.260 align:middle line:84% AUDIENCE: It seems like because the verifier 00:01:31.260 --> 00:01:35.790 align:middle line:84% is going to also check if each of those bits, 00:01:35.790 --> 00:01:38.400 align:middle line:90% corresponding in B0 B1. 00:01:38.400 --> 00:01:40.240 align:middle line:90% Because want to be out. 00:01:40.240 --> 00:01:43.410 align:middle line:84% Seems like that among those running the gate. 00:01:43.410 --> 00:01:46.510 align:middle line:84% PROFESSOR: So the verifier doesn't know all these values, 00:01:46.510 --> 00:01:48.660 align:middle line:90% all these bits. 00:01:48.660 --> 00:01:51.040 align:middle line:84% The verifier only knows the hash. 00:01:51.040 --> 00:01:54.830 align:middle line:84% He gets only v. He doesn't know all these things, and he can't. 00:01:54.830 --> 00:01:55.955 align:middle line:90% There are too many of them. 00:01:55.955 --> 00:01:58.500 align:middle line:90% 00:01:58.500 --> 00:02:00.000 align:middle line:84% He knows what the circuit is, but he 00:02:00.000 --> 00:02:02.000 align:middle line:84% doesn't run in time that depends on the circuit. 00:02:02.000 --> 00:02:03.010 align:middle line:90% The circuit is too big. 00:02:03.010 --> 00:02:05.640 align:middle line:84% He just knows in his head how to generate 00:02:05.640 --> 00:02:07.800 align:middle line:90% each gate in the circuit. 00:02:07.800 --> 00:02:09.759 align:middle line:90% So he doesn't know these bits. 00:02:09.759 --> 00:02:14.555 align:middle line:84% All he knows is the hash value and the BARG, which is succinct. 00:02:14.555 --> 00:02:18.900 align:middle line:90% 00:02:18.900 --> 00:02:19.400 align:middle line:90% Yeah? 00:02:19.400 --> 00:02:20.983 align:middle line:84% AUDIENCE: Security is going to give us 00:02:20.983 --> 00:02:22.210 align:middle line:90% some lower bound on L, right? 00:02:22.210 --> 00:02:23.445 align:middle line:90% It just happens? 00:02:23.445 --> 00:02:24.820 align:middle line:84% PROFESSOR: A lower bound on what? 00:02:24.820 --> 00:02:25.380 align:middle line:90% AUDIENCE: On L. 00:02:25.380 --> 00:02:26.220 align:middle line:90% PROFESSOR: On L, yes. 00:02:26.220 --> 00:02:26.700 align:middle line:90% AUDIENCE: Yeah, OK. 00:02:26.700 --> 00:02:28.890 align:middle line:84% PROFESSOR: Yeah, we're going to-- yeah, yeah, yeah. 00:02:28.890 --> 00:02:30.932 align:middle line:84% Now we're going to talk about security soundness, 00:02:30.932 --> 00:02:31.800 align:middle line:90% so we'll see. 00:02:31.800 --> 00:02:35.100 align:middle line:84% One thing I want to say before we jump to soundness-- just 00:02:35.100 --> 00:02:40.260 align:middle line:84% note, because I said the CRS of the BARG, 00:02:40.260 --> 00:02:44.110 align:middle line:84% we generated with security parameter lambda, k, 00:02:44.110 --> 00:02:46.360 align:middle line:84% which is the number of gates, and then I said n prime. 00:02:46.360 --> 00:02:46.860 align:middle line:90% We'll see. 00:02:46.860 --> 00:02:48.300 align:middle line:90% We'll see what n prime is. 00:02:48.300 --> 00:02:50.590 align:middle line:90% I forgot to-- this is n prime. 00:02:50.590 --> 00:02:54.270 align:middle line:90% It's just security parameter. 00:02:54.270 --> 00:02:56.320 align:middle line:84% N prime will be the length of the hash key, 00:02:56.320 --> 00:02:58.870 align:middle line:84% the length of v, which grows with L, 00:02:58.870 --> 00:03:02.450 align:middle line:90% and J. That's the n prime. 00:03:02.450 --> 00:03:07.000 align:middle line:84% I'm just mentioning it because I forgot to circle back to it. 00:03:07.000 --> 00:03:10.460 align:middle line:84% OK, are you ready to talk about analyzing this? 00:03:10.460 --> 00:03:13.961 align:middle line:84% Because that's actually the very interesting part. 00:03:13.961 --> 00:03:15.340 align:middle line:90% So let's analyze. 00:03:15.340 --> 00:03:20.140 align:middle line:90% 00:03:20.140 --> 00:03:24.295 align:middle line:84% OK, we need to argue completeness and soundness. 00:03:24.295 --> 00:03:26.170 align:middle line:84% Completeness-- I don't want to waste our time 00:03:26.170 --> 00:03:27.340 align:middle line:90% because it's just trivial. 00:03:27.340 --> 00:03:29.800 align:middle line:84% Completeness just follows from the completeness of the BARG 00:03:29.800 --> 00:03:35.120 align:middle line:84% and completeness of some extractable hash. 00:03:35.120 --> 00:03:38.660 align:middle line:84% So essentially, if you're honest, if x is in the language, 00:03:38.660 --> 00:03:42.610 align:middle line:84% you compute all the wires correctly, 00:03:42.610 --> 00:03:44.770 align:middle line:90% you hashed all the wires. 00:03:44.770 --> 00:03:47.810 align:middle line:84% And if you hashed all the wires correctly, 00:03:47.810 --> 00:03:50.990 align:middle line:84% then you have a valid witness for all the wires. 00:03:50.990 --> 00:03:52.460 align:middle line:90% So your BARG will be accepted. 00:03:52.460 --> 00:03:54.880 align:middle line:84% If you did everything correctly, everything 00:03:54.880 --> 00:03:57.220 align:middle line:84% is going to be accepted because the completeness 00:03:57.220 --> 00:03:58.870 align:middle line:90% of the underlying primitive. 00:03:58.870 --> 00:04:00.500 align:middle line:84% There's nothing interesting going on. 00:04:00.500 --> 00:04:03.380 align:middle line:84% The interesting part is soundness. 00:04:03.380 --> 00:04:06.610 align:middle line:84% So how do we know you cannot cheat? 00:04:06.610 --> 00:04:12.970 align:middle line:84% And let me even jump and tell you, 00:04:12.970 --> 00:04:15.670 align:middle line:90% this thing is not really sound. 00:04:15.670 --> 00:04:16.640 align:middle line:90% But-- 00:04:16.640 --> 00:04:19.010 align:middle line:90% [LAUGHTER] 00:04:19.010 --> 00:04:19.510 align:middle line:90% 00:04:19.510 --> 00:04:23.030 align:middle line:90% But we'll make it sound. 00:04:23.030 --> 00:04:24.280 align:middle line:90% So what do we know? 00:04:24.280 --> 00:04:26.670 align:middle line:84% So soundness-- so what do we want to prove? 00:04:26.670 --> 00:04:33.880 align:middle line:90% 00:04:33.880 --> 00:04:35.660 align:middle line:84% Let's try to hope for-- so again, 00:04:35.660 --> 00:04:37.370 align:middle line:84% there's nonadaptive and adaptive. 00:04:37.370 --> 00:04:38.480 align:middle line:90% You can think of both. 00:04:38.480 --> 00:04:40.855 align:middle line:84% But let's talk about, what does it mean to be, let's say, 00:04:40.855 --> 00:04:41.750 align:middle line:90% adaptively sound? 00:04:41.750 --> 00:04:49.960 align:middle line:84% So we need to prove that for any polynomial-size cheating prover, 00:04:49.960 --> 00:04:56.780 align:middle line:84% we want to say the probability that P star takes a CRS 00:04:56.780 --> 00:05:00.650 align:middle line:84% of the BARG-- of the SNARG-- so a hash key and a CRS 00:05:00.650 --> 00:05:01.610 align:middle line:90% for the BARG-- 00:05:01.610 --> 00:05:08.750 align:middle line:84% it takes the CRS, and it outputs some x and pi such 00:05:08.750 --> 00:05:11.690 align:middle line:90% that x is not in the language. 00:05:11.690 --> 00:05:23.810 align:middle line:84% And pi, the SNARG is satisfied v and CRS x pi outputs 1. 00:05:23.810 --> 00:05:26.556 align:middle line:84% You want to say that this is negligible. 00:05:26.556 --> 00:05:29.300 align:middle line:90% 00:05:29.300 --> 00:05:31.040 align:middle line:90% That's what we need to prove. 00:05:31.040 --> 00:05:35.690 align:middle line:84% The probability that a cheating prover gets a CRS 00:05:35.690 --> 00:05:38.430 align:middle line:84% and generates any x that's not in the language 00:05:38.430 --> 00:05:43.220 align:middle line:90% and a proof that's accepted-- 00:05:43.220 --> 00:05:44.490 align:middle line:90% you can't do that. 00:05:44.490 --> 00:05:47.360 align:middle line:84% You can do that only with the Sanger probability. 00:05:47.360 --> 00:05:53.450 align:middle line:84% Let me just mention another more weaker definition is 00:05:53.450 --> 00:05:57.000 align:middle line:84% the nonadaptive, which says, for any P star and for every x-- 00:05:57.000 --> 00:05:58.820 align:middle line:90% so he gives x ahead of time. 00:05:58.820 --> 00:06:02.870 align:middle line:84% For any P star and for any x not in the language, 00:06:02.870 --> 00:06:05.270 align:middle line:84% when he gets a random CRS, the probability 00:06:05.270 --> 00:06:09.410 align:middle line:84% that he managed to generate a fake proof that's accepted 00:06:09.410 --> 00:06:10.543 align:middle line:90% is negligible. 00:06:10.543 --> 00:06:11.960 align:middle line:84% So there's two variants-- one when 00:06:11.960 --> 00:06:16.830 align:middle line:84% he needs to choose a given x for all the CRSes, 00:06:16.830 --> 00:06:20.030 align:middle line:84% or he can choose an x depending on the CRS. 00:06:20.030 --> 00:06:22.820 align:middle line:84% Let's talk about the adaptive because it's just stronger, 00:06:22.820 --> 00:06:26.240 align:middle line:84% and we can get it, at least in some cases. 00:06:26.240 --> 00:06:30.050 align:middle line:84% So today, the SNARGs is in the literature-- so 00:06:30.050 --> 00:06:32.280 align:middle line:84% achieve adaptive, some achieve nonadaptive. 00:06:32.280 --> 00:06:37.610 align:middle line:84% And in general, the ones for deterministic computations 00:06:37.610 --> 00:06:39.000 align:middle line:90% are adaptive. 00:06:39.000 --> 00:06:40.850 align:middle line:84% The one for nondeterministic computations 00:06:40.850 --> 00:06:42.600 align:middle line:84% are more on the nonadaptive side. 00:06:42.600 --> 00:06:44.570 align:middle line:84% And we don't have SNARGs for all of NP. 00:06:44.570 --> 00:06:48.030 align:middle line:84% So at the end of the talk, at the end of the class, 00:06:48.030 --> 00:06:51.510 align:middle line:84% I'll leave 10 minutes to talk about where 00:06:51.510 --> 00:06:53.410 align:middle line:90% we're standing as a community. 00:06:53.410 --> 00:06:57.300 align:middle line:84% But both definitions are relevant, 00:06:57.300 --> 00:06:59.670 align:middle line:84% and we have results in both settings-- the adaptive 00:06:59.670 --> 00:07:00.790 align:middle line:90% and the nonadaptive. 00:07:00.790 --> 00:07:05.770 align:middle line:84% But let's talk today on the adaptive setting. 00:07:05.770 --> 00:07:07.570 align:middle line:90% So that's what we want. 00:07:07.570 --> 00:07:10.450 align:middle line:84% But the question, do we get this? 00:07:10.450 --> 00:07:16.000 align:middle line:84% So let's try to see what this construction actually gives us. 00:07:16.000 --> 00:07:20.100 align:middle line:84% So what I'm going to argue is actually this construction 00:07:20.100 --> 00:07:24.150 align:middle line:90% does not give a soundness. 00:07:24.150 --> 00:07:30.460 align:middle line:84% What it gives us is a form of local soundness. 00:07:30.460 --> 00:07:31.990 align:middle line:90% So I'll explain what this means. 00:07:31.990 --> 00:07:39.630 align:middle line:84% So what I'm going to argue is that-- so claim the SNARG 00:07:39.630 --> 00:07:43.710 align:middle line:84% that I just constructed is, let me call it, 00:07:43.710 --> 00:07:49.990 align:middle line:84% locally sound or locally consistent. 00:07:49.990 --> 00:07:54.090 align:middle line:84% It's also people call locally consistent. 00:07:54.090 --> 00:07:55.610 align:middle line:90% And I'll explain what it is. 00:07:55.610 --> 00:07:58.430 align:middle line:90% 00:07:58.430 --> 00:07:59.830 align:middle line:90% We want to prove soundness. 00:07:59.830 --> 00:08:01.270 align:middle line:90% So what do we want to prove? 00:08:01.270 --> 00:08:06.570 align:middle line:84% We want to prove that this SNARG, if you manage 00:08:06.570 --> 00:08:08.520 align:middle line:84% to say that the output is 1, there's 00:08:08.520 --> 00:08:11.370 align:middle line:84% actually an assignment to all the wires that give you 1. 00:08:11.370 --> 00:08:14.040 align:middle line:90% That means it's sound. 00:08:14.040 --> 00:08:16.290 align:middle line:90% We can't prove that. 00:08:16.290 --> 00:08:19.110 align:middle line:90% What can we prove? 00:08:19.110 --> 00:08:24.390 align:middle line:84% We can prove that if you argue that the value is 1, 00:08:24.390 --> 00:08:28.080 align:middle line:84% I can use you to extract the value 00:08:28.080 --> 00:08:31.150 align:middle line:90% of any small set of wires-- 00:08:31.150 --> 00:08:34.590 align:middle line:84% how many L. So remember, our SNARG, 00:08:34.590 --> 00:08:37.480 align:middle line:90% we're binding on allocations. 00:08:37.480 --> 00:08:39.610 align:middle line:84% These allocations, I can extract. 00:08:39.610 --> 00:08:42.659 align:middle line:84% You gave me a V that's binding allocation. 00:08:42.659 --> 00:08:44.280 align:middle line:90% I can extract. 00:08:44.280 --> 00:08:48.340 align:middle line:84% I can get from you the L wire values. 00:08:48.340 --> 00:08:50.990 align:middle line:84% So I get L wires values from you. 00:08:50.990 --> 00:08:53.620 align:middle line:84% What I can argue about these L wire 00:08:53.620 --> 00:08:57.530 align:middle line:84% values is that locally they're consistent. 00:08:57.530 --> 00:09:01.630 align:middle line:84% So if there's a gate, if the L wire values-- 00:09:01.630 --> 00:09:04.040 align:middle line:84% let's say three of them are connected with a gate-- 00:09:04.040 --> 00:09:07.300 align:middle line:84% I can argue that this gate is satisfied. 00:09:07.300 --> 00:09:12.940 align:middle line:84% So I can argue this form of local consistency. 00:09:12.940 --> 00:09:15.380 align:middle line:84% So I'm going to define what local consistency is. 00:09:15.380 --> 00:09:19.150 align:middle line:84% But just high level, what I can argue 00:09:19.150 --> 00:09:23.650 align:middle line:84% is not that I have a assignment of all the wires 00:09:23.650 --> 00:09:25.900 align:middle line:84% that are consistent inside, and the output 00:09:25.900 --> 00:09:28.640 align:middle line:84% is 1, which is what I want to argue. 00:09:28.640 --> 00:09:30.670 align:middle line:84% I can argue that I have an assignment 00:09:30.670 --> 00:09:36.230 align:middle line:84% that I can have a small window to the wires, a window of size 00:09:36.230 --> 00:09:36.730 align:middle line:90% L. 00:09:36.730 --> 00:09:40.593 align:middle line:84% So I can look at these L wires, and they look consistent. 00:09:40.593 --> 00:09:43.010 align:middle line:84% And I can look at these L wires, and they look consistent. 00:09:43.010 --> 00:09:45.520 align:middle line:90% And the output is 1. 00:09:45.520 --> 00:09:48.272 align:middle line:84% So it seems like, OK, local now, we only 00:09:48.272 --> 00:09:49.730 align:middle line:84% need to stitch all of them together 00:09:49.730 --> 00:09:52.310 align:middle line:84% and to get a final assignment, and we're done. 00:09:52.310 --> 00:09:55.610 align:middle line:84% So the goal is we're going to say, locally we're consistent. 00:09:55.610 --> 00:09:59.100 align:middle line:84% And local consistency implies global consistency. 00:09:59.100 --> 00:10:02.400 align:middle line:90% And so we get soundness. 00:10:02.400 --> 00:10:06.000 align:middle line:84% So the plan-- we are going to prove local consistency. 00:10:06.000 --> 00:10:07.050 align:middle line:90% So that's check. 00:10:07.050 --> 00:10:10.190 align:middle line:84% And we're going to define it and prove it. 00:10:10.190 --> 00:10:13.100 align:middle line:84% The local consistency implies global. 00:10:13.100 --> 00:10:17.070 align:middle line:84% That turns out to be much more difficult than we thought. 00:10:17.070 --> 00:10:19.820 align:middle line:84% So when we started working on this, we were like, oh, 00:10:19.820 --> 00:10:20.730 align:middle line:90% local consistency. 00:10:20.730 --> 00:10:22.100 align:middle line:90% But we shouldn't apply global. 00:10:22.100 --> 00:10:23.070 align:middle line:90% That should be good. 00:10:23.070 --> 00:10:24.960 align:middle line:84% So we worked really hard local, local. 00:10:24.960 --> 00:10:26.420 align:middle line:84% And then turns out, local to global 00:10:26.420 --> 00:10:28.140 align:middle line:90% was another 10 years of work. 00:10:28.140 --> 00:10:30.400 align:middle line:84% And we're in progress, in progress. 00:10:30.400 --> 00:10:33.150 align:middle line:90% 00:10:33.150 --> 00:10:36.600 align:middle line:84% So what we're going to see today is how to get local consistency. 00:10:36.600 --> 00:10:40.070 align:middle line:84% We're going to talk a little bit about why local implies global 00:10:40.070 --> 00:10:42.420 align:middle line:90% and why not. 00:10:42.420 --> 00:10:44.610 align:middle line:84% Why doesn't it always imply global? 00:10:44.610 --> 00:10:47.260 align:middle line:84% And hopefully, it will give you some food for thought. 00:10:47.260 --> 00:10:50.480 align:middle line:90% 00:10:50.480 --> 00:10:52.455 align:middle line:84% So I'm going to argue that it's locally sound. 00:10:52.455 --> 00:10:54.330 align:middle line:84% And let me tell you what locally sound means. 00:10:54.330 --> 00:10:55.320 align:middle line:90% Let me first define it. 00:10:55.320 --> 00:11:06.860 align:middle line:84% So the definition-- so here's what it means. 00:11:06.860 --> 00:11:09.600 align:middle line:90% It means that there exists-- 00:11:09.600 --> 00:11:11.550 align:middle line:84% so I'm now defining what this means. 00:11:11.550 --> 00:11:14.510 align:middle line:84% It means that there exists an extractor-- 00:11:14.510 --> 00:11:18.890 align:middle line:84% what we call sometimes a local assignment-- 00:11:18.890 --> 00:11:23.244 align:middle line:84% so some extractor, a local assignment-- 00:11:23.244 --> 00:11:26.450 align:middle line:90% 00:11:26.450 --> 00:11:30.770 align:middle line:84% generator, that's another name we use-- 00:11:30.770 --> 00:11:36.810 align:middle line:84% E-- so we have an extractor that generates assignments for us. 00:11:36.810 --> 00:11:41.250 align:middle line:84% This assignment takes only L wire values on the circuit. 00:11:41.250 --> 00:11:48.930 align:middle line:84% So we have a circuit C. This extractor or local assignment 00:11:48.930 --> 00:11:51.360 align:middle line:90% generator, it gets L wires-- 00:11:51.360 --> 00:11:54.570 align:middle line:90% i1 up to il. 00:11:54.570 --> 00:11:59.790 align:middle line:84% They're all in the wires, which we denoted by n. 00:11:59.790 --> 00:12:04.500 align:middle line:84% So it takes l wires, and it outputs 00:12:04.500 --> 00:12:09.630 align:middle line:84% some x star in an instance and wire values-- 00:12:09.630 --> 00:12:14.080 align:middle line:90% and values wi1 up to wil. 00:12:14.080 --> 00:12:17.850 align:middle line:84% This is what our local assignment generator outputs. 00:12:17.850 --> 00:12:23.640 align:middle line:84% For any i1 up to il, it outputs some instance and y values 00:12:23.640 --> 00:12:38.100 align:middle line:84% that satisfy the following such that 1 is local consistency, 00:12:38.100 --> 00:12:40.980 align:middle line:90% which means any two wires-- 00:12:40.980 --> 00:12:46.080 align:middle line:84% any wires that are connected by a gate satisfy the gate. 00:12:46.080 --> 00:12:48.700 align:middle line:90% And the output wire is a 1. 00:12:48.700 --> 00:12:52.030 align:middle line:84% And if one of them are connected to input wires, 00:12:52.030 --> 00:12:54.930 align:middle line:84% then it's consistent with the input wire. 00:12:54.930 --> 00:12:57.060 align:middle line:84% So local consistency just means it 00:12:57.060 --> 00:13:08.430 align:middle line:84% respects all gates consistent with x1 up 00:13:08.430 --> 00:13:14.510 align:middle line:90% to xn and out and output one. 00:13:14.510 --> 00:13:18.960 align:middle line:90% 00:13:18.960 --> 00:13:22.260 align:middle line:84% So of course, if you just read wires here and here, 00:13:22.260 --> 00:13:26.560 align:middle line:84% like very spread, they are not connected with any gates, 00:13:26.560 --> 00:13:29.280 align:middle line:84% then the local consistency doesn't say anything 00:13:29.280 --> 00:13:31.380 align:middle line:84% because you can't determine the value of any gate. 00:13:31.380 --> 00:13:33.780 align:middle line:84% But any gate for which you have-- 00:13:33.780 --> 00:13:36.300 align:middle line:84% any gate for which the input and output 00:13:36.300 --> 00:13:39.030 align:middle line:84% wires are these or the output wire 00:13:39.030 --> 00:13:44.500 align:middle line:84% or the input wires, the gate should be satisfied. 00:13:44.500 --> 00:13:45.950 align:middle line:90% That's number 1. 00:13:45.950 --> 00:13:50.941 align:middle line:84% And number 2 is what we call nonsignaling. 00:13:50.941 --> 00:13:51.483 align:middle line:90% I'll explain. 00:13:51.483 --> 00:13:57.610 align:middle line:90% 00:13:57.610 --> 00:14:01.060 align:middle line:84% The number 2 says the wire values 00:14:01.060 --> 00:14:05.320 align:middle line:84% that he gives here, that the extractor, the local assignment 00:14:05.320 --> 00:14:09.370 align:middle line:84% generator gives, the distribution-- so this 00:14:09.370 --> 00:14:10.970 align:middle line:90% is a randomized algorithm. 00:14:10.970 --> 00:14:15.310 align:middle line:84% This extractor is a randomized algorithm. 00:14:15.310 --> 00:14:18.100 align:middle line:84% Given these wire, he gives a distribution 00:14:18.100 --> 00:14:21.580 align:middle line:90% over x star and wire values. 00:14:21.580 --> 00:14:25.640 align:middle line:84% The claim is the distribution of x star, for example, 00:14:25.640 --> 00:14:28.300 align:middle line:90% doesn't depend on i1 up to il. 00:14:28.300 --> 00:14:32.890 align:middle line:84% So the distribution of x star in this computationally 00:14:32.890 --> 00:14:37.700 align:middle line:84% looks the same, no matter which wires you give. 00:14:37.700 --> 00:14:41.950 align:middle line:84% Moreover, the distribution of wi1 00:14:41.950 --> 00:14:44.650 align:middle line:90% doesn't depend on i2 up to il. 00:14:44.650 --> 00:14:47.350 align:middle line:90% So let me say this formally. 00:14:47.350 --> 00:14:58.030 align:middle line:84% Formally, for every set I and J of size l-- 00:14:58.030 --> 00:14:58.930 align:middle line:90% let me-- sorry. 00:14:58.930 --> 00:15:07.460 align:middle line:84% For any I and J subset of n-- so for any set of wires of size l-- 00:15:07.460 --> 00:15:11.295 align:middle line:84% so take any set of wires, like i1 to il. 00:15:11.295 --> 00:15:15.940 align:middle line:84% Let me call the first set I, the second set J. 00:15:15.940 --> 00:15:21.140 align:middle line:84% And what we know is if you look at the intersection of-- 00:15:21.140 --> 00:15:22.365 align:middle line:90% so if you look at-- 00:15:22.365 --> 00:15:27.190 align:middle line:90% 00:15:27.190 --> 00:15:28.870 align:middle line:90% how will I-- one second. 00:15:28.870 --> 00:15:31.435 align:middle line:90% Let me just think of notation. 00:15:31.435 --> 00:15:37.390 align:middle line:84% If you look at extractor an I but only restricted 00:15:37.390 --> 00:15:42.710 align:middle line:84% to the coordinate in I intersect J. So the w's-- 00:15:42.710 --> 00:15:43.440 align:middle line:90% there's many. 00:15:43.440 --> 00:15:45.900 align:middle line:90% There's w for i1, i2. 00:15:45.900 --> 00:15:48.350 align:middle line:84% Let's look only at the w's in the locations 00:15:48.350 --> 00:15:52.670 align:middle line:90% that are both in I and in J. 00:15:52.670 --> 00:16:02.150 align:middle line:84% The distribution of them looks like-- it looks at in distinct 00:16:02.150 --> 00:16:03.450 align:middle line:90% from the distribution. 00:16:03.450 --> 00:16:08.420 align:middle line:84% If you looked at these coordinates with set 00:16:08.420 --> 00:16:13.740 align:middle line:84% J. In other words, let's say the intersection of I and J are, 00:16:13.740 --> 00:16:15.690 align:middle line:90% I don't know, some set of wires. 00:16:15.690 --> 00:16:18.540 align:middle line:84% Put the set of wires in the beginning. 00:16:18.540 --> 00:16:21.110 align:middle line:90% 00:16:21.110 --> 00:16:23.070 align:middle line:84% So if you look at a set of wires, 00:16:23.070 --> 00:16:24.860 align:middle line:90% look at their distribution. 00:16:24.860 --> 00:16:28.700 align:middle line:84% Their distribution does not depend 00:16:28.700 --> 00:16:31.670 align:middle line:90% on what the other wires are. 00:16:31.670 --> 00:16:33.960 align:middle line:84% If you look at the distribution of these, 00:16:33.960 --> 00:16:37.490 align:middle line:84% they will look the same whether the rest of the i's were 00:16:37.490 --> 00:16:39.800 align:middle line:90% of one form or another form. 00:16:39.800 --> 00:16:41.760 align:middle line:84% At least computationally, they look the same. 00:16:41.760 --> 00:16:44.160 align:middle line:84% They need not be exactly the same. 00:16:44.160 --> 00:16:47.360 align:middle line:84% But nobody can distinguish between the two. 00:16:47.360 --> 00:16:52.500 align:middle line:84% And this is including the x star. 00:16:52.500 --> 00:16:58.100 align:middle line:84% So E is like when the extractor here, it 00:16:58.100 --> 00:17:09.410 align:middle line:84% means x star and the wij for I, J in i. 00:17:09.410 --> 00:17:11.040 align:middle line:90% So I include the x star. 00:17:11.040 --> 00:17:12.560 align:middle line:84% So even with x star, the x star here 00:17:12.560 --> 00:17:15.950 align:middle line:84% and the x star here are indistinguishable. 00:17:15.950 --> 00:17:17.359 align:middle line:90% X star, I always include. 00:17:17.359 --> 00:17:21.480 align:middle line:84% Even if it's empty, I include x star. 00:17:21.480 --> 00:17:22.710 align:middle line:90% So that's a nonsignaling. 00:17:22.710 --> 00:17:25.339 align:middle line:84% The distributions are indistinguishable. 00:17:25.339 --> 00:17:29.600 align:middle line:84% And now I want to argue that we get-- 00:17:29.600 --> 00:17:30.663 align:middle line:90% I have this extractor. 00:17:30.663 --> 00:17:31.580 align:middle line:90% I'm going to show you. 00:17:31.580 --> 00:17:32.525 align:middle line:84% I'm going to construct this extractor. 00:17:32.525 --> 00:17:35.070 align:middle line:84% It's actually very easy to construct this extractor. 00:17:35.070 --> 00:17:38.160 align:middle line:84% So if you give me a cheating prover, 00:17:38.160 --> 00:17:39.380 align:middle line:90% if you give me any prover. 00:17:39.380 --> 00:17:40.297 align:middle line:90% Forgot about cheating. 00:17:40.297 --> 00:17:42.990 align:middle line:84% You give me a prover, I can construct this local assignment 00:17:42.990 --> 00:17:44.880 align:middle line:90% generator from him. 00:17:44.880 --> 00:17:48.150 align:middle line:84% And then all I need to do is argue that a local assignment 00:17:48.150 --> 00:17:53.410 align:middle line:84% generate implies that I have an assignment for all, 00:17:53.410 --> 00:17:56.177 align:middle line:84% like, not just locally consistent, 00:17:56.177 --> 00:17:58.260 align:middle line:84% but a fully consistent assignment to all the wires 00:17:58.260 --> 00:17:59.710 align:middle line:90% that give output 1. 00:17:59.710 --> 00:18:02.250 align:middle line:84% And therefore, x needs to be in the language. 00:18:02.250 --> 00:18:03.553 align:middle line:90% That's the proof strategy. 00:18:03.553 --> 00:18:06.240 align:middle line:90% 00:18:06.240 --> 00:18:10.390 align:middle line:84% So what I'm going to do first is show you how we get-- 00:18:10.390 --> 00:18:13.350 align:middle line:84% so we're going to show how, given any p star, 00:18:13.350 --> 00:18:17.070 align:middle line:84% we can generate a local assignment generate. 00:18:17.070 --> 00:18:19.740 align:middle line:84% We can give local assignment to all the wires 00:18:19.740 --> 00:18:23.100 align:middle line:84% that are consistent and satisfy this kind 00:18:23.100 --> 00:18:25.300 align:middle line:90% of nonsignaling property. 00:18:25.300 --> 00:18:27.930 align:middle line:84% And then I'm going to show how to use this local assignment 00:18:27.930 --> 00:18:31.650 align:middle line:90% generator to get soundness. 00:18:31.650 --> 00:18:32.490 align:middle line:90% Questions? 00:18:32.490 --> 00:18:33.510 align:middle line:90% Yeah? 00:18:33.510 --> 00:18:39.610 align:middle line:84% AUDIENCE: Is another issue with obtaining this soundness comes 00:18:39.610 --> 00:18:44.477 align:middle line:90% from the left side of BARG? 00:18:44.477 --> 00:18:46.810 align:middle line:84% PROFESSOR: Actually, the semi-adaptive soundness of BARG 00:18:46.810 --> 00:18:47.930 align:middle line:90% is enough for me. 00:18:47.930 --> 00:18:48.710 align:middle line:90% It's enough. 00:18:48.710 --> 00:18:50.390 align:middle line:90% I don't need to use-- 00:18:50.390 --> 00:18:52.160 align:middle line:90% you'll see, actually. 00:18:52.160 --> 00:18:55.245 align:middle line:84% I don't need full adaptive BARGs. 00:18:55.245 --> 00:18:56.830 align:middle line:90% I never use it. 00:18:56.830 --> 00:19:00.320 align:middle line:84% It's enough for me that the BARG only has semi even though-- 00:19:00.320 --> 00:19:01.520 align:middle line:90% OK, that's a good point. 00:19:01.520 --> 00:19:03.870 align:middle line:84% Note, I'm going to prove adaptive soundness. 00:19:03.870 --> 00:19:05.620 align:middle line:84% And you're saying, wait, but the BARG only 00:19:05.620 --> 00:19:07.330 align:middle line:90% has semi-adaptive soundness. 00:19:07.330 --> 00:19:08.330 align:middle line:90% Is that enough? 00:19:08.330 --> 00:19:10.180 align:middle line:84% Is it enough to use only semi-adaptive BARG 00:19:10.180 --> 00:19:12.170 align:middle line:90% and get fully adaptive SNARG? 00:19:12.170 --> 00:19:13.270 align:middle line:90% Yes. 00:19:13.270 --> 00:19:16.570 align:middle line:84% I will not need the full adaptivity of the BARG. 00:19:16.570 --> 00:19:17.950 align:middle line:90% We'll see it next. 00:19:17.950 --> 00:19:18.530 align:middle line:90% I'll use it. 00:19:18.530 --> 00:19:20.060 align:middle line:90% You'll see it doesn't come up. 00:19:20.060 --> 00:19:21.440 align:middle line:90% So it's enough. 00:19:21.440 --> 00:19:26.620 align:middle line:84% The problem is, to get this, the local assignment, I can get. 00:19:26.620 --> 00:19:29.150 align:middle line:84% The problem why, this implies global. 00:19:29.150 --> 00:19:30.380 align:middle line:90% So we'll see that. 00:19:30.380 --> 00:19:33.320 align:middle line:84% But the semi-- it seems counterintuitive. 00:19:33.320 --> 00:19:35.170 align:middle line:90% But actually, it's enough. 00:19:35.170 --> 00:19:36.295 align:middle line:90% Was there another question? 00:19:36.295 --> 00:19:37.253 align:middle line:90% Do you have a question? 00:19:37.253 --> 00:19:37.870 align:middle line:90% Yeah? 00:19:37.870 --> 00:19:40.120 align:middle line:84% AUDIENCE: Can you remind me what the x star is? 00:19:40.120 --> 00:19:40.870 align:middle line:90% Is that the same-- 00:19:40.870 --> 00:19:42.203 align:middle line:90% PROFESSOR: Oh, good, good, good. 00:19:42.203 --> 00:19:44.360 align:middle line:90% This is any-- OK, so good. 00:19:44.360 --> 00:19:45.100 align:middle line:90% What is x star? 00:19:45.100 --> 00:19:46.220 align:middle line:90% No, sorry. 00:19:46.220 --> 00:19:49.180 align:middle line:90% OK. 00:19:49.180 --> 00:19:50.590 align:middle line:90% OK, yeah. 00:19:50.590 --> 00:19:53.560 align:middle line:90% Let me call it x tilde. 00:19:53.560 --> 00:19:55.010 align:middle line:90% Sorry. 00:19:55.010 --> 00:19:56.470 align:middle line:90% Let me-- you're right. 00:19:56.470 --> 00:19:58.840 align:middle line:90% The extract-- OK. 00:19:58.840 --> 00:19:59.570 align:middle line:90% Yeah. 00:19:59.570 --> 00:20:03.745 align:middle line:90% So in p star outputs x tilde. 00:20:03.745 --> 00:20:06.050 align:middle line:84% It's crooked, kind of a cheating x. 00:20:06.050 --> 00:20:07.870 align:middle line:84% So let's use crooked, like tilde, 00:20:07.870 --> 00:20:10.160 align:middle line:84% to denote a crooked cheating thing. 00:20:10.160 --> 00:20:16.210 align:middle line:84% And he's also going to output some tilde because his is also 00:20:16.210 --> 00:20:16.970 align:middle line:90% crooked. 00:20:16.970 --> 00:20:21.190 align:middle line:84% And we want to argue that this crooked x is 00:20:21.190 --> 00:20:26.500 align:middle line:84% indistinguishable from the crooked x given by the cheating 00:20:26.500 --> 00:20:27.080 align:middle line:90% prover. 00:20:27.080 --> 00:20:28.783 align:middle line:90% We're going to-- yeah. 00:20:28.783 --> 00:20:30.700 align:middle line:84% Oh, yeah, so I need to say that x was-- sorry. 00:20:30.700 --> 00:20:31.660 align:middle line:90% So good. 00:20:31.660 --> 00:20:36.300 align:middle line:84% So let's say, again, the local assignment generator, it outputs 00:20:36.300 --> 00:20:40.020 align:middle line:90% a crooked x with Partial. 00:20:40.020 --> 00:20:41.490 align:middle line:84% Assignments to some of the wires, 00:20:41.490 --> 00:20:49.600 align:middle line:84% to the L wires such that it's consistent, nonsignaling, 00:20:49.600 --> 00:20:51.330 align:middle line:90% and it's also non-- and-- 00:20:51.330 --> 00:20:57.450 align:middle line:84% sorry, and x tilde is indistinguishable 00:20:57.450 --> 00:20:59.940 align:middle line:90% from the x tilde of p star. 00:20:59.940 --> 00:21:01.930 align:middle line:90% So p star also outputs x tilde. 00:21:01.930 --> 00:21:04.890 align:middle line:90% They look the same. 00:21:04.890 --> 00:21:08.650 align:middle line:84% Note, if it was nonadaptive, it would be fixed. 00:21:08.650 --> 00:21:12.090 align:middle line:84% So then x tilde is fixed ahead of time. 00:21:12.090 --> 00:21:13.840 align:middle line:84% Nobody will need to generate them anymore. 00:21:13.840 --> 00:21:14.460 align:middle line:90% It's fixed. 00:21:14.460 --> 00:21:18.150 align:middle line:84% And the extractor, the local assignment generator, 00:21:18.150 --> 00:21:22.290 align:middle line:84% will only give values to the wires. 00:21:22.290 --> 00:21:27.850 align:middle line:84% But in the adaptive setting, the p star, you give him CRS, 00:21:27.850 --> 00:21:29.500 align:middle line:90% he gives you a different x star. 00:21:29.500 --> 00:21:30.660 align:middle line:90% The x tilde. 00:21:30.660 --> 00:21:31.730 align:middle line:90% Sorry. 00:21:31.730 --> 00:21:34.230 align:middle line:84% He gives you a different x tilde. 00:21:34.230 --> 00:21:38.060 align:middle line:84% So every time he gives you a local window, 00:21:38.060 --> 00:21:44.120 align:middle line:84% it will be with respect to a different x tilde, possibly, 00:21:44.120 --> 00:21:45.140 align:middle line:90% in the adaptive setting. 00:21:45.140 --> 00:21:46.765 align:middle line:84% In the nonadaptive setting, it's always 00:21:46.765 --> 00:21:50.720 align:middle line:84% going to be with the same x tilde. 00:21:50.720 --> 00:21:52.520 align:middle line:90% OK. 00:21:52.520 --> 00:21:53.476 align:middle line:90% Any questions? 00:21:53.476 --> 00:21:56.630 align:middle line:90% 00:21:56.630 --> 00:21:58.160 align:middle line:84% Let's try to see why we get local-- 00:21:58.160 --> 00:22:01.680 align:middle line:84% how we construct this local assignment generator. 00:22:01.680 --> 00:22:03.210 align:middle line:90% So I have a cheating prover. 00:22:03.210 --> 00:22:06.710 align:middle line:90% So fix, so proof. 00:22:06.710 --> 00:22:16.820 align:middle line:84% So fix p star fix a poly size p star. 00:22:16.820 --> 00:22:22.140 align:middle line:84% I want to get a window to the-- there's the circuit. 00:22:22.140 --> 00:22:27.830 align:middle line:84% We have the circuit C that has x, maybe a witness. 00:22:27.830 --> 00:22:32.910 align:middle line:84% I want to use the C, the p, the cheating prover. 00:22:32.910 --> 00:22:34.360 align:middle line:90% So he's going to give me-- 00:22:34.360 --> 00:22:35.610 align:middle line:90% OK, so fixed p star. 00:22:35.610 --> 00:22:38.830 align:middle line:84% For any CRS, he's going to give me x. 00:22:38.830 --> 00:22:41.520 align:middle line:84% I'm going to get from him in x and a window 00:22:41.520 --> 00:22:43.750 align:middle line:84% to some of the wires of the circuit. 00:22:43.750 --> 00:22:45.280 align:middle line:90% So let's see how. 00:22:45.280 --> 00:22:47.610 align:middle line:90% So here's my extractor. 00:22:47.610 --> 00:22:49.440 align:middle line:84% The extractor or the local assignment 00:22:49.440 --> 00:22:52.170 align:middle line:84% generator-- it's going to use p star as an oracle. 00:22:52.170 --> 00:22:54.390 align:middle line:84% He's going to make use of p star. 00:22:54.390 --> 00:22:57.210 align:middle line:90% He's going to get i1 up to il. 00:22:57.210 --> 00:22:58.270 align:middle line:90% What does he do? 00:22:58.270 --> 00:23:01.590 align:middle line:84% He wants to get the values of these wires. 00:23:01.590 --> 00:23:03.070 align:middle line:90% What does he do? 00:23:03.070 --> 00:23:05.230 align:middle line:90% He's going to run p star. 00:23:05.230 --> 00:23:08.350 align:middle line:84% He's going to run p star on a CRS that he chooses. 00:23:08.350 --> 00:23:14.130 align:middle line:90% So he's going to generate CRS. 00:23:14.130 --> 00:23:15.990 align:middle line:90% We'll see how in a second. 00:23:15.990 --> 00:23:19.470 align:middle line:84% And then he's going to run p star on the CRS 00:23:19.470 --> 00:23:22.510 align:middle line:90% to get a value and a SNARG. 00:23:22.510 --> 00:23:28.710 align:middle line:84% And then he's going to extract the wires from this hash value. 00:23:28.710 --> 00:23:29.920 align:middle line:90% So let's see. 00:23:29.920 --> 00:23:31.990 align:middle line:90% So how does he generate the CRS? 00:23:31.990 --> 00:23:39.540 align:middle line:84% CRS is going to be a pi for CRS BARG and a hash key. 00:23:39.540 --> 00:23:46.470 align:middle line:84% So he's going to generate hash key 00:23:46.470 --> 00:23:51.490 align:middle line:84% by running gen and these location, i1 up to il. 00:23:51.490 --> 00:23:54.810 align:middle line:84% So let me actually-- he's going to first generate 00:23:54.810 --> 00:24:05.010 align:middle line:84% hash key, and trapdoor, and gen some extractable hash with 1 00:24:05.010 --> 00:24:10.900 align:middle line:84% to the lambda number of wires in the circuit and i1 up to il. 00:24:10.900 --> 00:24:14.430 align:middle line:84% These are the wires he wants to extract 00:24:14.430 --> 00:24:16.420 align:middle line:90% because he has i1 up to il. 00:24:16.420 --> 00:24:19.050 align:middle line:84% He wants to extract the values of these wires. 00:24:19.050 --> 00:24:21.060 align:middle line:84% So he's going to give you a hash key that's 00:24:21.060 --> 00:24:24.210 align:middle line:90% extractable on these locations. 00:24:24.210 --> 00:24:29.080 align:middle line:84% And then he's also going to generate gen 00:24:29.080 --> 00:24:35.530 align:middle line:90% for the BARG to get CRA BARG. 00:24:35.530 --> 00:24:37.090 align:middle line:84% He's just going to do this honestly. 00:24:37.090 --> 00:24:40.585 align:middle line:84% Here, he has 1 to the lambda k and n. 00:24:40.585 --> 00:24:44.380 align:middle line:90% 00:24:44.380 --> 00:24:45.250 align:middle line:90% This is n prime. 00:24:45.250 --> 00:24:49.090 align:middle line:84% The n prime, he's going to generate exactly as 00:24:49.090 --> 00:24:50.180 align:middle line:90% in the construction. 00:24:50.180 --> 00:24:52.970 align:middle line:90% And then he runs. 00:24:52.970 --> 00:25:02.140 align:middle line:84% Now, run p star with hash key and CRS BARG. 00:25:02.140 --> 00:25:04.260 align:middle line:90% That's the CRS he gives p star. 00:25:04.260 --> 00:25:06.850 align:middle line:90% 00:25:06.850 --> 00:25:11.300 align:middle line:90% And get v and pi BARG. 00:25:11.300 --> 00:25:16.330 align:middle line:84% That's what the p star gives you. 00:25:16.330 --> 00:25:21.220 align:middle line:84% Now, if this is rejected, start again. 00:25:21.220 --> 00:25:26.200 align:middle line:90% So if pi BARG-- 00:25:26.200 --> 00:25:31.540 align:middle line:90% or if v and pi BARG-- 00:25:31.540 --> 00:25:35.570 align:middle line:90% so if the verifier with input-- 00:25:35.570 --> 00:25:36.350 align:middle line:90% oh, wait. 00:25:36.350 --> 00:25:36.850 align:middle line:90% Sorry. 00:25:36.850 --> 00:25:38.480 align:middle line:90% X star also, x tilde. 00:25:38.480 --> 00:25:39.560 align:middle line:90% Sorry. 00:25:39.560 --> 00:25:42.440 align:middle line:90% So the p star gives what? 00:25:42.440 --> 00:25:44.320 align:middle line:84% Some x tilde because it's adaptive. 00:25:44.320 --> 00:25:47.380 align:middle line:90% He gives him some x and a proof. 00:25:47.380 --> 00:25:50.480 align:middle line:84% The proof is a hash value and the BARG. 00:25:50.480 --> 00:25:51.980 align:middle line:90% That's what the proof is. 00:25:51.980 --> 00:25:53.080 align:middle line:90% Now he checks. 00:25:53.080 --> 00:25:55.810 align:middle line:84% If v-- if the verifier rejects this proof-- 00:25:55.810 --> 00:25:57.230 align:middle line:90% if it's not a good proof-- 00:25:57.230 --> 00:26:00.880 align:middle line:90% so if v, given CRS-- 00:26:00.880 --> 00:26:01.970 align:middle line:90% which is these two. 00:26:01.970 --> 00:26:03.550 align:middle line:90% This is the CRS-- 00:26:03.550 --> 00:26:07.600 align:middle line:84% given CRS, given x tilde, and given pi-- 00:26:07.600 --> 00:26:14.235 align:middle line:84% this is pi-- outputs , if it rejects, try again. 00:26:14.235 --> 00:26:19.030 align:middle line:90% 00:26:19.030 --> 00:26:20.960 align:middle line:90% What do I mean by try again? 00:26:20.960 --> 00:26:25.560 align:middle line:84% Again, generate a hash key, generate a BARG, run. 00:26:25.560 --> 00:26:27.850 align:middle line:84% If this is accepted-- if it's rejected, 00:26:27.850 --> 00:26:34.150 align:middle line:84% try again until you get something good. 00:26:34.150 --> 00:26:39.670 align:middle line:84% Now, OK-- until we get something good. 00:26:39.670 --> 00:26:42.670 align:middle line:84% Once you get something good, you're happy. 00:26:42.670 --> 00:26:44.320 align:middle line:90% But then, what do you do? 00:26:44.320 --> 00:26:45.940 align:middle line:90% You output. 00:26:45.940 --> 00:26:47.490 align:middle line:90% So try again. 00:26:47.490 --> 00:27:00.510 align:middle line:84% If success, then output the x tilde. 00:27:00.510 --> 00:27:02.610 align:middle line:90% And what wire values? 00:27:02.610 --> 00:27:04.030 align:middle line:90% Extract from the v. 00:27:04.030 --> 00:27:07.680 align:middle line:84% So remember, this V. Is hash of all the wires of the circuit. 00:27:07.680 --> 00:27:08.770 align:middle line:90% Extract. 00:27:08.770 --> 00:27:11.200 align:middle line:84% You'll get the wires corresponding to i1 up to il. 00:27:11.200 --> 00:27:21.530 align:middle line:84% So output this, and output extract with trapdoor the value 00:27:21.530 --> 00:27:26.450 align:middle line:90% v to get wi1 up to wil. 00:27:26.450 --> 00:27:27.830 align:middle line:90% That's it. 00:27:27.830 --> 00:27:30.780 align:middle line:84% That's what the extractor-- the local assignment generator does. 00:27:30.780 --> 00:27:32.030 align:middle line:90% AUDIENCE: Why can you do this? 00:27:32.030 --> 00:27:34.470 align:middle line:90% The slide was adaptive. 00:27:34.470 --> 00:27:37.810 align:middle line:84% So if you change the CRS, why can you fix the x? 00:27:37.810 --> 00:27:39.060 align:middle line:90% PROFESSOR: No, it's not fixed. 00:27:39.060 --> 00:27:39.602 align:middle line:90% You're right. 00:27:39.602 --> 00:27:40.940 align:middle line:90% So what do I do? 00:27:40.940 --> 00:27:44.270 align:middle line:90% I generate hash key and a BARG. 00:27:44.270 --> 00:27:45.030 align:middle line:90% I run him. 00:27:45.030 --> 00:27:47.630 align:middle line:90% He gives me x tilde. 00:27:47.630 --> 00:27:50.790 align:middle line:84% If I'm happy with this proof, I output x tilde. 00:27:50.790 --> 00:27:52.740 align:middle line:90% The x tilde depends on the CRS. 00:27:52.740 --> 00:27:58.035 align:middle line:84% So given i1 to il, I'm going to get a different x tilde for i1 00:27:58.035 --> 00:27:58.610 align:middle line:90% up to il. 00:27:58.610 --> 00:28:05.810 align:middle line:84% So every time I get i1 to il, I generate a CRS for my SNARG. 00:28:05.810 --> 00:28:07.020 align:middle line:90% I run the prover. 00:28:07.020 --> 00:28:09.870 align:middle line:90% I get x tilde and a proof. 00:28:09.870 --> 00:28:12.830 align:middle line:84% If I'm happy with the proof, I output x tilde 00:28:12.830 --> 00:28:14.043 align:middle line:90% and extracted wires. 00:28:14.043 --> 00:28:15.710 align:middle line:84% AUDIENCE: So these are just wire values. 00:28:15.710 --> 00:28:16.220 align:middle line:90% They're not witnesses. 00:28:16.220 --> 00:28:16.887 align:middle line:90% PROFESSOR: Yeah. 00:28:16.887 --> 00:28:17.890 align:middle line:90% No, they're wire value. 00:28:17.890 --> 00:28:18.390 align:middle line:90% Sorry. 00:28:18.390 --> 00:28:20.580 align:middle line:90% These are not witnesses. 00:28:20.580 --> 00:28:24.740 align:middle line:84% Yeah, I use W for what wires, but it's also witness. 00:28:24.740 --> 00:28:27.613 align:middle line:90% 00:28:27.613 --> 00:28:28.113 align:middle line:90% Sorry. 00:28:28.113 --> 00:28:31.362 align:middle line:90% 00:28:31.362 --> 00:28:33.160 align:middle line:90% A bit of abuse of notation. 00:28:33.160 --> 00:28:33.660 align:middle line:90% Sorry. 00:28:33.660 --> 00:28:35.040 align:middle line:90% These are wire values. 00:28:35.040 --> 00:28:36.100 align:middle line:90% Forget about witness. 00:28:36.100 --> 00:28:37.990 align:middle line:84% There's no witnesses now, just wires. 00:28:37.990 --> 00:28:38.490 align:middle line:90% Yeah. 00:28:38.490 --> 00:28:39.300 align:middle line:90% Yeah? 00:28:39.300 --> 00:28:40.967 align:middle line:84% AUDIENCE: If you like rejection sampling 00:28:40.967 --> 00:28:42.930 align:middle line:84% until you get the verifier to accept, then 00:28:42.930 --> 00:28:45.090 align:middle line:84% how would the distribution of x going to be 00:28:45.090 --> 00:28:46.560 align:middle line:90% the distribution of p star? 00:28:46.560 --> 00:28:48.060 align:middle line:90% PROFESSOR: OK. 00:28:48.060 --> 00:28:49.110 align:middle line:90% OK. 00:28:49.110 --> 00:28:49.630 align:middle line:90% That's good. 00:28:49.630 --> 00:28:51.564 align:middle line:90% So I'm going to answer. 00:28:51.564 --> 00:28:52.064 align:middle line:90% Did you-- 00:28:52.064 --> 00:28:53.040 align:middle line:84% AUDIENCE: It's a different question. 00:28:53.040 --> 00:28:53.550 align:middle line:90% PROFESSOR: A different question. 00:28:53.550 --> 00:28:53.800 align:middle line:90% OK. 00:28:53.800 --> 00:28:55.217 align:middle line:84% Let me first answer this question. 00:28:55.217 --> 00:28:58.680 align:middle line:90% 00:28:58.680 --> 00:29:01.300 align:middle line:84% The question was-- first, there's a couple of issues. 00:29:01.300 --> 00:29:04.260 align:middle line:84% First of all, how many times am I going to do this rejection 00:29:04.260 --> 00:29:08.280 align:middle line:84% sampling/ Am I going to run forever What's going on here? 00:29:08.280 --> 00:29:09.485 align:middle line:90% And the answer is no. 00:29:09.485 --> 00:29:11.110 align:middle line:84% Actually, I'm not going to run forever. 00:29:11.110 --> 00:29:13.440 align:middle line:84% So fix a p star that, let's say, is 00:29:13.440 --> 00:29:25.810 align:middle line:84% accepted with non-negligible probability epsilon. 00:29:25.810 --> 00:29:27.820 align:middle line:90% Epsilon is non-negligible. 00:29:27.820 --> 00:29:29.710 align:middle line:90% I'm going to try again. 00:29:29.710 --> 00:29:38.520 align:middle line:84% At most, I know poly in lambda and 1 over epsilon times. 00:29:38.520 --> 00:29:42.910 align:middle line:90% 00:29:42.910 --> 00:29:46.390 align:middle line:84% So I'm going to do this only polynomially many times. 00:29:46.390 --> 00:29:49.270 align:middle line:84% Think of epsilon as 1 over poly lambda. 00:29:49.270 --> 00:29:52.450 align:middle line:84% So I'm going to run in time poly in lambda. 00:29:52.450 --> 00:29:54.226 align:middle line:90% OK. 00:29:54.226 --> 00:29:56.710 align:middle line:90% Now, given that-- and OK. 00:29:56.710 --> 00:29:58.420 align:middle line:84% So the first thing I want to argue 00:29:58.420 --> 00:30:01.030 align:middle line:90% is the probability that I will-- 00:30:01.030 --> 00:30:03.490 align:middle line:84% and so I'm going to run the most poly lambda in 1 00:30:03.490 --> 00:30:04.250 align:middle line:90% over epsilon time. 00:30:04.250 --> 00:30:05.030 align:middle line:90% That's it. 00:30:05.030 --> 00:30:07.660 align:middle line:84% And you say, what if all of them are reject? 00:30:07.660 --> 00:30:11.230 align:middle line:84% Then I'm going to say, OK, I was defeated. 00:30:11.230 --> 00:30:14.000 align:middle line:84% What is the probability that I'll be defeated? 00:30:14.000 --> 00:30:17.410 align:middle line:84% Negligible because each time I'm starting fresh 00:30:17.410 --> 00:30:21.676 align:middle line:84% and the probability of defeat is only-- 00:30:21.676 --> 00:30:24.050 align:middle line:90% is 1 over-- 00:30:24.050 --> 00:30:28.690 align:middle line:90% OK, I'm accepted. 00:30:28.690 --> 00:30:32.650 align:middle line:84% OK, I'm accepted with probability epsilon. 00:30:32.650 --> 00:30:36.950 align:middle line:84% If I repeat it lambda over epsilon times, 00:30:36.950 --> 00:30:39.620 align:middle line:84% by just concentration bound, by Chernoff bound, 00:30:39.620 --> 00:30:41.260 align:middle line:84% I'm going to be accepted in one of them 00:30:41.260 --> 00:30:43.220 align:middle line:84% with very, very high probability-- 00:30:43.220 --> 00:30:46.390 align:middle line:84% exponential, like, exponential in 2 00:30:46.390 --> 00:30:48.620 align:middle line:84% to the minus lambda or something like that. 00:30:48.620 --> 00:30:52.720 align:middle line:84% So if I repeat it enough times, one of them, 00:30:52.720 --> 00:30:55.510 align:middle line:84% I'm going to the probability of BARG of me 00:30:55.510 --> 00:30:59.716 align:middle line:90% being defeated is negligible. 00:30:59.716 --> 00:31:02.480 align:middle line:84% So but now, going back to your question, 00:31:02.480 --> 00:31:05.500 align:middle line:84% the question is, how do I know that x 00:31:05.500 --> 00:31:09.280 align:middle line:84% tilde here has the same distribution as the x tilde of p 00:31:09.280 --> 00:31:10.420 align:middle line:90% star? 00:31:10.420 --> 00:31:11.690 align:middle line:90% Yeah, that's the question. 00:31:11.690 --> 00:31:14.770 align:middle line:90% So good. 00:31:14.770 --> 00:31:19.140 align:middle line:90% So actually, I was a bit sloppy. 00:31:19.140 --> 00:31:21.890 align:middle line:84% When I say x tilde is in the signal from this, 00:31:21.890 --> 00:31:25.500 align:middle line:84% I mean, in this thing for x tilde condition on accept. 00:31:25.500 --> 00:31:26.630 align:middle line:90% Sorry, yeah. 00:31:26.630 --> 00:31:33.710 align:middle line:84% This is condition on p star accepting. 00:31:33.710 --> 00:31:36.650 align:middle line:84% So I can assume without loss of-- yeah. 00:31:36.650 --> 00:31:39.720 align:middle line:84% So let's think of p star either as outputting 00:31:39.720 --> 00:31:42.380 align:middle line:84% but there's no point in him giving a bad proof. 00:31:42.380 --> 00:31:43.560 align:middle line:90% He's going to be rejected. 00:31:43.560 --> 00:31:47.315 align:middle line:84% Either he's defeat or giving x with a good proof. 00:31:47.315 --> 00:31:49.880 align:middle line:90% 00:31:49.880 --> 00:31:54.898 align:middle line:84% So I always output x tilde with probability 1 minus negligible. 00:31:54.898 --> 00:31:56.690 align:middle line:84% And this x tilde is going to be distributed 00:31:56.690 --> 00:32:01.470 align:middle line:84% like x tilde conditioned on the p star not a boarding. 00:32:01.470 --> 00:32:02.180 align:middle line:90% Yeah? 00:32:02.180 --> 00:32:03.410 align:middle line:84% AUDIENCE: So then those two distributions 00:32:03.410 --> 00:32:05.900 align:middle line:84% are actually identical right up to the slight probability 00:32:05.900 --> 00:32:07.730 align:middle line:90% that you give up at the end? 00:32:07.730 --> 00:32:09.080 align:middle line:90% PROFESSOR: No. 00:32:09.080 --> 00:32:11.990 align:middle line:84% OK, so the question was, is the x tilde of p star 00:32:11.990 --> 00:32:15.720 align:middle line:84% actually identical to the x tilde of the extractor? 00:32:15.720 --> 00:32:17.750 align:middle line:84% And the answer is not quite because the x tilde 00:32:17.750 --> 00:32:22.580 align:middle line:84% of the extractor runs gen with these specific i's. 00:32:22.580 --> 00:32:26.390 align:middle line:84% And x tilde is run with p star with, let's say, 1, 2, 3, 00:32:26.390 --> 00:32:29.150 align:middle line:84% up to l, I don't know, like, fixed. 00:32:29.150 --> 00:32:31.080 align:middle line:90% And the I's change. 00:32:31.080 --> 00:32:32.220 align:middle line:90% That's the only difference. 00:32:32.220 --> 00:32:33.950 align:middle line:84% And that's why it's indistinguishable because the p 00:32:33.950 --> 00:32:34.860 align:middle line:90% star doesn't know. 00:32:34.860 --> 00:32:38.990 align:middle line:84% Because of the index hiding, p star 00:32:38.990 --> 00:32:42.620 align:middle line:84% has no idea what the index-- which indices 00:32:42.620 --> 00:32:44.880 align:middle line:90% are sitting behind the hash key. 00:32:44.880 --> 00:32:48.480 align:middle line:84% So the x tilde he gives is the same. 00:32:48.480 --> 00:32:50.000 align:middle line:90% It's indistinguishable. 00:32:50.000 --> 00:32:51.860 align:middle line:90% Nikon, did you-- are you-- 00:32:51.860 --> 00:32:55.267 align:middle line:84% AUDIENCE: I just to make sure from the last point. 00:32:55.267 --> 00:32:57.350 align:middle line:84% Each trial here will work with probability epsilon 00:32:57.350 --> 00:32:59.910 align:middle line:84% minus negligible because of the index hiding, right? 00:32:59.910 --> 00:33:00.780 align:middle line:90% PROFESSOR: Exactly. 00:33:00.780 --> 00:33:01.460 align:middle line:90% You're right. 00:33:01.460 --> 00:33:03.170 align:middle line:90% Yeah, you're right. 00:33:03.170 --> 00:33:03.950 align:middle line:90% Exactly. 00:33:03.950 --> 00:33:05.600 align:middle line:84% Epsilon minus-- that's why the epsilon 00:33:05.600 --> 00:33:08.580 align:middle line:84% has to be non-negligible, because you lose negligible. 00:33:08.580 --> 00:33:13.920 align:middle line:84% And it needs to be negligible compared to the epsilon. 00:33:13.920 --> 00:33:16.170 align:middle line:84% AUDIENCE: So my question was, the extract algorithm 00:33:16.170 --> 00:33:18.600 align:middle line:84% for the SEH is only required to extract 00:33:18.600 --> 00:33:22.680 align:middle line:90% when V is an eval of x, right? 00:33:22.680 --> 00:33:25.260 align:middle line:84% Is that true, or is that not true? 00:33:25.260 --> 00:33:26.130 align:middle line:90% PROFESSOR: OK. 00:33:26.130 --> 00:33:26.843 align:middle line:90% One second. 00:33:26.843 --> 00:33:32.010 align:middle line:90% 00:33:32.010 --> 00:33:33.810 align:middle line:90% Good point. 00:33:33.810 --> 00:33:35.850 align:middle line:90% No. 00:33:35.850 --> 00:33:36.990 align:middle line:90% OK. 00:33:36.990 --> 00:33:37.500 align:middle line:90% No. 00:33:37.500 --> 00:33:40.260 align:middle line:90% The completeness was assuming-- 00:33:40.260 --> 00:33:41.590 align:middle line:90% holds. 00:33:41.590 --> 00:33:47.490 align:middle line:84% But I didn't write it actually down. 00:33:47.490 --> 00:33:48.510 align:middle line:90% Good point, Nikon. 00:33:48.510 --> 00:33:49.235 align:middle line:90% Thank you. 00:33:49.235 --> 00:33:57.060 align:middle line:90% 00:33:57.060 --> 00:34:00.100 align:middle line:90% The sum of extractable hash-- 00:34:00.100 --> 00:34:01.600 align:middle line:90% I didn't say soundness of the-- 00:34:01.600 --> 00:34:03.815 align:middle line:84% I didn't write the soundness of this extract. 00:34:03.815 --> 00:34:07.800 align:middle line:90% 00:34:07.800 --> 00:34:10.369 align:middle line:84% The extract has the following property. 00:34:10.369 --> 00:34:18.690 align:middle line:90% 00:34:18.690 --> 00:34:23.960 align:middle line:84% If the cheating prover gives any-- 00:34:23.960 --> 00:34:24.460 align:middle line:90% hold on. 00:34:24.460 --> 00:34:25.640 align:middle line:90% Let me think for a second. 00:34:25.640 --> 00:34:30.120 align:middle line:90% 00:34:30.120 --> 00:34:33.040 align:middle line:84% If the cheating prover gives an opening-- 00:34:33.040 --> 00:34:34.750 align:middle line:90% if you're extract-- 00:34:34.750 --> 00:34:36.960 align:middle line:90% If the hash key-- 00:34:36.960 --> 00:34:37.650 align:middle line:90% OK. 00:34:37.650 --> 00:34:38.409 align:middle line:90% Thank you. 00:34:38.409 --> 00:34:41.969 align:middle line:84% If the hash key is generated with gen of i 00:34:41.969 --> 00:34:48.790 align:middle line:84% and if an adversary generated an opening of i, a valid opening-- 00:34:48.790 --> 00:34:55.110 align:middle line:84% so he successfully opened the i-th bit somehow with a b-- then 00:34:55.110 --> 00:34:59.490 align:middle line:84% the extract will work and give you that same b. 00:34:59.490 --> 00:35:02.900 align:middle line:84% So let me write it down because actually we need it here. 00:35:02.900 --> 00:35:19.150 align:middle line:90% 00:35:19.150 --> 00:35:28.780 align:middle line:84% For any A adversary and for every i, the probability 00:35:28.780 --> 00:35:33.620 align:middle line:84% that A and hash key, where the hash key is generated with i-- 00:35:33.620 --> 00:35:40.930 align:middle line:84% so hash key, trapdoor, they're generated with gen with 1 00:35:40.930 --> 00:35:44.080 align:middle line:90% to the lambda n and i. 00:35:44.080 --> 00:35:49.390 align:middle line:84% If he managed to give me a value adversarial value, 00:35:49.390 --> 00:35:57.340 align:middle line:84% but he manages to open with a b and rho-- 00:35:57.340 --> 00:36:00.100 align:middle line:90% let me call it bi and row i-- 00:36:00.100 --> 00:36:05.690 align:middle line:84% such that the verifier accepted such that there-- 00:36:05.690 --> 00:36:09.970 align:middle line:84% so the probability that he gives me 00:36:09.970 --> 00:36:19.840 align:middle line:84% a tuple that verifies-- so hash key vib rho is one. 00:36:19.840 --> 00:36:24.290 align:middle line:84% And but extraction fails is negligible. 00:36:24.290 --> 00:36:30.010 align:middle line:84% So the probability that this accepts but extract 00:36:30.010 --> 00:36:38.076 align:middle line:90% is not b, bi is negligible. 00:36:38.076 --> 00:36:40.960 align:middle line:90% 00:36:40.960 --> 00:36:43.760 align:middle line:84% So if you open, there must be valid. 00:36:43.760 --> 00:36:46.037 align:middle line:84% And if you think about the construction, 00:36:46.037 --> 00:36:48.620 align:middle line:84% if you open it, like, everything is in the correct encryption, 00:36:48.620 --> 00:36:50.912 align:middle line:84% encryption, encryption, the encryption must be correct, 00:36:50.912 --> 00:36:52.560 align:middle line:84% and the extractor will decrypt it. 00:36:52.560 --> 00:36:58.425 align:middle line:90% 00:36:58.425 --> 00:36:59.800 align:middle line:84% So if it doesn't open anything, v 00:36:59.800 --> 00:37:02.270 align:middle line:84% can be whatever, you may not be able to extract. 00:37:02.270 --> 00:37:09.062 align:middle line:84% But as long as he gave you the correct path, then OK. 00:37:09.062 --> 00:37:10.350 align:middle line:90% So we'll use it here. 00:37:10.350 --> 00:37:11.760 align:middle line:90% Thank you. 00:37:11.760 --> 00:37:12.260 align:middle line:90% OK. 00:37:12.260 --> 00:37:15.030 align:middle line:90% 00:37:15.030 --> 00:37:17.960 align:middle line:90% So now let's see why is-- 00:37:17.960 --> 00:37:20.630 align:middle line:84% but this is the extraction procedure. 00:37:20.630 --> 00:37:21.945 align:middle line:90% We'll analyze it in a second. 00:37:21.945 --> 00:37:23.070 align:middle line:90% We'll see why this is used. 00:37:23.070 --> 00:37:27.620 align:middle line:90% But again, let's just recall. 00:37:27.620 --> 00:37:29.760 align:middle line:84% So what is the local assignment generator? 00:37:29.760 --> 00:37:32.810 align:middle line:90% It takes l wires. 00:37:32.810 --> 00:37:36.750 align:middle line:84% He will generate a CRS and give it to the cheating prover. 00:37:36.750 --> 00:37:40.790 align:middle line:84% The CRS he generates consists of a hash key and a BARG 00:37:40.790 --> 00:37:42.060 align:middle line:90% and a CRS for the BARG. 00:37:42.060 --> 00:37:43.790 align:middle line:84% The CRS for the BARG, he just generates. 00:37:43.790 --> 00:37:46.760 align:middle line:84% And the CRS for the hash key, he generates 00:37:46.760 --> 00:37:50.690 align:middle line:84% with a trapdoor with respect to the wires 00:37:50.690 --> 00:37:53.600 align:middle line:90% that he needs to extract. 00:37:53.600 --> 00:37:55.380 align:middle line:90% He gives this to the prover. 00:37:55.380 --> 00:37:59.210 align:middle line:84% And the prover gives him a hash value 00:37:59.210 --> 00:38:03.590 align:middle line:84% that's extracted on these wires and a BARG proof. 00:38:03.590 --> 00:38:05.880 align:middle line:84% If the BARG proof is rejected, he starts all over. 00:38:05.880 --> 00:38:08.255 align:middle line:84% So we're going to do it until we have something accepted. 00:38:08.255 --> 00:38:13.480 align:middle line:84% Once it's accepted, we're going to just extract these wires 00:38:13.480 --> 00:38:15.260 align:middle line:90% because we have the trapdoor. 00:38:15.260 --> 00:38:17.170 align:middle line:90% The extractor has the trapdoor. 00:38:17.170 --> 00:38:19.420 align:middle line:84% We're going to-- or the e here, we're 00:38:19.420 --> 00:38:21.515 align:middle line:90% going to extract the wires. 00:38:21.515 --> 00:38:23.140 align:middle line:84% And that's what we're going to output-- 00:38:23.140 --> 00:38:27.350 align:middle line:90% the x tilde and the wires. 00:38:27.350 --> 00:38:29.360 align:middle line:84% So now we need to argue nonsignaling, 00:38:29.360 --> 00:38:32.740 align:middle line:84% and we need to argue local consistency. 00:38:32.740 --> 00:38:34.995 align:middle line:84% Any questions before I go ahead and do it? 00:38:34.995 --> 00:38:38.200 align:middle line:90% 00:38:38.200 --> 00:38:39.200 align:middle line:90% So let's see. 00:38:39.200 --> 00:38:42.860 align:middle line:84% Let's start with local consistency. 00:38:42.860 --> 00:38:46.210 align:middle line:84% Why are things locally consistent? 00:38:46.210 --> 00:38:50.170 align:middle line:84% So I claim that local consistency follows 00:38:50.170 --> 00:38:52.220 align:middle line:90% from the soundness of the BARG. 00:38:52.220 --> 00:38:53.972 align:middle line:90% So let's see why this is. 00:38:53.972 --> 00:39:09.330 align:middle line:90% 00:39:09.330 --> 00:39:10.445 align:middle line:90% What do we have here? 00:39:10.445 --> 00:39:17.370 align:middle line:90% 00:39:17.370 --> 00:39:17.890 align:middle line:90% OK. 00:39:17.890 --> 00:39:18.390 align:middle line:90% Oh, well. 00:39:18.390 --> 00:39:20.835 align:middle line:90% I'm just going to-- 00:39:20.835 --> 00:39:24.630 align:middle line:84% we're going to need it, but it's OK. 00:39:24.630 --> 00:39:25.180 align:middle line:90% OK, OK. 00:39:25.180 --> 00:39:30.380 align:middle line:90% 00:39:30.380 --> 00:39:34.050 align:middle line:84% So local consistency, I want to argue, 00:39:34.050 --> 00:39:36.150 align:middle line:84% follows from the correctness of the BARG-- 00:39:36.150 --> 00:39:37.680 align:middle line:90% from the soundness of the BARG. 00:39:37.680 --> 00:39:38.610 align:middle line:90% Why? 00:39:38.610 --> 00:39:51.660 align:middle line:84% Suppose, for contradiction-- so suppose 00:39:51.660 --> 00:39:56.760 align:middle line:84% that the extractor output x tilde and L wire are 00:39:56.760 --> 00:39:59.560 align:middle line:90% values that are not consistent. 00:39:59.560 --> 00:40:02.280 align:middle line:84% So the L wire values are not consistent. 00:40:02.280 --> 00:40:04.850 align:middle line:84% Then what does it mean they're not consistent? 00:40:04.850 --> 00:40:10.300 align:middle line:84% There's one gate that they don't respect. 00:40:10.300 --> 00:40:14.510 align:middle line:90% Now, remember-- so OK. 00:40:14.510 --> 00:40:16.760 align:middle line:84% So there's one gate that they don't respect. 00:40:16.760 --> 00:40:30.850 align:middle line:84% So suppose E and input i1 up to il output w1 up to wi1 00:40:30.850 --> 00:40:44.840 align:middle line:84% up to wil that do not respect some gate-- let's fix the gate-- 00:40:44.840 --> 00:40:48.920 align:middle line:84% some gate J with non-negligible probability. 00:40:48.920 --> 00:40:51.530 align:middle line:84% If there's one gate doesn't respect, choose one at random. 00:40:51.530 --> 00:40:53.910 align:middle line:84% So it won't respect this random one with probability. 00:40:53.910 --> 00:40:56.410 align:middle line:84% I mean, there exists one gate that's not respect probability 00:40:56.410 --> 00:40:58.312 align:middle line:90% 1 over poly. 00:40:58.312 --> 00:40:59.770 align:middle line:84% So suppose there exists some gate J 00:40:59.770 --> 00:41:07.390 align:middle line:84% that this does not with probability 1 over poly. 00:41:07.390 --> 00:41:09.680 align:middle line:90% Now let's look at the BARG. 00:41:09.680 --> 00:41:11.630 align:middle line:90% What does the BARG say? 00:41:11.630 --> 00:41:17.860 align:middle line:84% The BARG tells me that all the gates are respected. 00:41:17.860 --> 00:41:22.060 align:middle line:84% So what I'm going to do in the BARG, I'm going to-- 00:41:22.060 --> 00:41:26.690 align:middle line:84% so remember, in the BARG, I have this somewhere. 00:41:26.690 --> 00:41:29.990 align:middle line:84% Now I'm going to the adaptive versus the why-- 00:41:29.990 --> 00:41:30.920 align:middle line:90% some are adaptive. 00:41:30.920 --> 00:41:32.390 align:middle line:90% Soundness of BARG is enough. 00:41:32.390 --> 00:41:33.340 align:middle line:90% Why? 00:41:33.340 --> 00:41:37.960 align:middle line:84% If there some gate J that's not respect probability 1 over poly, 00:41:37.960 --> 00:41:45.130 align:middle line:84% in the BARG construction in the CRS, I'm going to hardwire-- 00:41:45.130 --> 00:41:46.180 align:middle line:90% sorry. 00:41:46.180 --> 00:41:49.220 align:middle line:84% OK, let me construct a cheating prover for the BARG. 00:41:49.220 --> 00:41:54.340 align:middle line:84% So we're going to construct a cheating 00:41:54.340 --> 00:42:03.295 align:middle line:90% prover for BARG that cheats. 00:42:03.295 --> 00:42:06.440 align:middle line:90% 00:42:06.440 --> 00:42:09.180 align:middle line:84% He's going to be somewhere adaptive soundness, 00:42:09.180 --> 00:42:15.360 align:middle line:84% and he's going to cheat on J and this specific J. 00:42:15.360 --> 00:42:17.160 align:middle line:84% I don't care about what the CRS is yet. 00:42:17.160 --> 00:42:19.020 align:middle line:90% I'm going to be semi-adaptive. 00:42:19.020 --> 00:42:23.060 align:middle line:84% So I'm going to tell you, my cheating prover, he may choose 00:42:23.060 --> 00:42:26.180 align:middle line:90% the x1 star up to xk star. 00:42:26.180 --> 00:42:28.340 align:middle line:90% The actual instance is later. 00:42:28.340 --> 00:42:30.990 align:middle line:84% But which one he's going to choose, he's going to cheat on, 00:42:30.990 --> 00:42:32.073 align:middle line:90% I'm going to tell you now. 00:42:32.073 --> 00:42:35.570 align:middle line:84% It's J. So it's going to be going to be nonadaptive 00:42:35.570 --> 00:42:36.570 align:middle line:90% and where he's cheating. 00:42:36.570 --> 00:42:38.220 align:middle line:90% That's the semi-adaptive. 00:42:38.220 --> 00:42:39.200 align:middle line:90% Yeah? 00:42:39.200 --> 00:42:42.290 align:middle line:84% AUDIENCE: But for that local consistency, 00:42:42.290 --> 00:42:45.860 align:middle line:84% is the statement that the instructor output-- 00:42:45.860 --> 00:42:48.750 align:middle line:84% is that the same as the prover is trying to cheat on? 00:42:48.750 --> 00:42:51.183 align:middle line:90% 00:42:51.183 --> 00:42:53.100 align:middle line:84% PROFESSOR: So you're asking, is there a match? 00:42:53.100 --> 00:42:55.190 align:middle line:90% How do we match these two? 00:42:55.190 --> 00:42:55.830 align:middle line:90% OK, so wait. 00:42:55.830 --> 00:42:57.330 align:middle line:84% Let me tell you the cheating prover. 00:42:57.330 --> 00:42:59.660 align:middle line:84% So I'm going to construct a cheating prover-- let's 00:42:59.660 --> 00:43:02.570 align:middle line:90% say p double star for the BARG. 00:43:02.570 --> 00:43:04.470 align:middle line:84% Here's what my p double star does. 00:43:04.470 --> 00:43:08.710 align:middle line:84% My p double star, he gets CRS of BARG. 00:43:08.710 --> 00:43:11.240 align:middle line:90% 00:43:11.240 --> 00:43:13.550 align:middle line:84% What he's going to do, he's going 00:43:13.550 --> 00:43:21.900 align:middle line:84% to run piece-- he's going to generate hash key on his own. 00:43:21.900 --> 00:43:31.280 align:middle line:84% And he's going to run p star, and the CRS BARG, 00:43:31.280 --> 00:43:33.330 align:middle line:84% and the hash key that he gives him. 00:43:33.330 --> 00:43:37.540 align:middle line:90% He's going to get v and pi BARG. 00:43:37.540 --> 00:43:41.750 align:middle line:90% 00:43:41.750 --> 00:43:44.000 align:middle line:90% And now he's going to cheat. 00:43:44.000 --> 00:43:46.970 align:middle line:90% P double star will cheat. 00:43:46.970 --> 00:43:49.110 align:middle line:84% And here's the instances that he gives. 00:43:49.110 --> 00:43:51.450 align:middle line:84% So he's going to give the instances adaptively. 00:43:51.450 --> 00:43:57.840 align:middle line:84% The instances are going to be hash key V and J for J 00:43:57.840 --> 00:44:03.262 align:middle line:84% goes from 1 to k, the number of gates. 00:44:03.262 --> 00:44:04.720 align:middle line:84% These are going to be the instance. 00:44:04.720 --> 00:44:09.880 align:middle line:84% So this is going to be xj star or xi. 00:44:09.880 --> 00:44:10.380 align:middle line:90% Sorry. 00:44:10.380 --> 00:44:17.130 align:middle line:90% That's a certain go I. 00:44:17.130 --> 00:44:18.670 align:middle line:90% So that's the xi star. 00:44:18.670 --> 00:44:20.645 align:middle line:84% And the BARG is going to be this. 00:44:20.645 --> 00:44:25.560 align:middle line:90% 00:44:25.560 --> 00:44:28.540 align:middle line:90% So that's how I'm cheating. 00:44:28.540 --> 00:44:34.690 align:middle line:84% I have k instances that I chose adaptively. 00:44:34.690 --> 00:44:37.350 align:middle line:84% But I'm arguing that the j-th one, 00:44:37.350 --> 00:44:42.420 align:middle line:84% which corresponds to gate j, is actually-- 00:44:42.420 --> 00:44:43.330 align:middle line:90% it's false. 00:44:43.330 --> 00:44:46.080 align:middle line:84% This xj star is not in the language 00:44:46.080 --> 00:44:50.520 align:middle line:84% because I'm binding on this j, and what's 00:44:50.520 --> 00:44:51.547 align:middle line:90% sitting there is false. 00:44:51.547 --> 00:44:53.130 align:middle line:84% So even if you're apart from this just 00:44:53.130 --> 00:44:56.700 align:middle line:90% does not exist of an opening. 00:44:56.700 --> 00:44:59.910 align:middle line:84% Because I'm binding on these locations, what 00:44:59.910 --> 00:45:04.480 align:middle line:84% I know from the binding condition, which is here, 00:45:04.480 --> 00:45:06.670 align:middle line:84% what I know from the binding condition-- 00:45:06.670 --> 00:45:09.070 align:middle line:84% there is no opening for the wrong value. 00:45:09.070 --> 00:45:10.540 align:middle line:90% It just doesn't exist. 00:45:10.540 --> 00:45:16.560 align:middle line:84% So there is no witness for xj star. 00:45:16.560 --> 00:45:21.030 align:middle line:84% But look, I have p double star managed to come up with a proof 00:45:21.030 --> 00:45:24.360 align:middle line:84% even though before, in the semi-adaptive way, 00:45:24.360 --> 00:45:26.940 align:middle line:90% he gave me a j, a gate. 00:45:26.940 --> 00:45:29.430 align:middle line:84% Before I got even the CRS, he gave me a gate 00:45:29.430 --> 00:45:32.850 align:middle line:84% and nevertheless managed to produce 00:45:32.850 --> 00:45:39.750 align:middle line:84% a BARG that all my x star-- and a bunch of x stars. 00:45:39.750 --> 00:45:41.710 align:middle line:90% And the BARG is satisfied. 00:45:41.710 --> 00:45:48.390 align:middle line:84% But the j-th instance does not have a witness-- 00:45:48.390 --> 00:45:49.600 align:middle line:90% contradiction. 00:45:49.600 --> 00:45:54.520 align:middle line:90% 00:45:54.520 --> 00:45:58.360 align:middle line:84% So the local consistency really follows 00:45:58.360 --> 00:46:00.230 align:middle line:90% from the soundness of the BARG. 00:46:00.230 --> 00:46:05.020 align:middle line:84% And all we need is a semi-adaptive soundness 00:46:05.020 --> 00:46:08.710 align:middle line:84% of the BARG because if you're somewhere in that local 00:46:08.710 --> 00:46:11.360 align:middle line:84% consistency-- not local consistent, 00:46:11.360 --> 00:46:14.290 align:middle line:90% even if you don't need to be-- 00:46:14.290 --> 00:46:16.930 align:middle line:84% even if there's one gate on which you're not 00:46:16.930 --> 00:46:19.090 align:middle line:84% local consistency only with probability epsilon, 00:46:19.090 --> 00:46:20.350 align:middle line:90% epsilon could be 1 over k. 00:46:20.350 --> 00:46:21.760 align:middle line:90% It can be very small. 00:46:21.760 --> 00:46:24.530 align:middle line:90% 00:46:24.530 --> 00:46:27.230 align:middle line:84% The claim is on each and every gate. 00:46:27.230 --> 00:46:31.870 align:middle line:84% Local consistency holds probability 1 minus negligible 00:46:31.870 --> 00:46:34.960 align:middle line:84% because otherwise, take that gate, and on that gate, 00:46:34.960 --> 00:46:37.070 align:middle line:84% we're going to cheat in the BARG. 00:46:37.070 --> 00:46:38.530 align:middle line:84% That's the instance, in which we're 00:46:38.530 --> 00:46:39.655 align:middle line:90% going to cheat on the BARG. 00:46:39.655 --> 00:46:41.980 align:middle line:90% 00:46:41.980 --> 00:46:46.090 align:middle line:90% So that's local consistency. 00:46:46.090 --> 00:46:49.100 align:middle line:84% And now you can ask, what about the nonsignaling? 00:46:49.100 --> 00:46:53.660 align:middle line:84% And the nonsignaling really follows from the fact 00:46:53.660 --> 00:46:55.045 align:middle line:90% from the index hiding. 00:46:55.045 --> 00:46:59.570 align:middle line:90% 00:46:59.570 --> 00:47:03.320 align:middle line:84% Are we OK with local consistency? 00:47:03.320 --> 00:47:04.610 align:middle line:90% OK. 00:47:04.610 --> 00:47:06.630 align:middle line:90% Any questions before I run-- 00:47:06.630 --> 00:47:07.350 align:middle line:90% actually, yeah? 00:47:07.350 --> 00:47:10.177 align:middle line:84% AUDIENCE: Is the i [? changed ?] [INAUDIBLE]? 00:47:10.177 --> 00:47:10.760 align:middle line:90% PROFESSOR: OK. 00:47:10.760 --> 00:47:11.390 align:middle line:90% Oh, sorry. 00:47:11.390 --> 00:47:12.600 align:middle line:90% I changed-- yeah, sorry. 00:47:12.600 --> 00:47:13.580 align:middle line:90% This is J. 00:47:13.580 --> 00:47:14.510 align:middle line:90% Thanks. 00:47:14.510 --> 00:47:15.420 align:middle line:90% Sorry about that. 00:47:15.420 --> 00:47:16.190 align:middle line:90% This is-- yeah. 00:47:16.190 --> 00:47:20.220 align:middle line:84% So I give you all-- this is an index language. 00:47:20.220 --> 00:47:24.000 align:middle line:84% So I give the instances are-- oh, ah, sorry. 00:47:24.000 --> 00:47:24.590 align:middle line:90% No. 00:47:24.590 --> 00:47:28.850 align:middle line:90% These are all for all i. 00:47:28.850 --> 00:47:31.550 align:middle line:84% Just J is a specific J, so I don't want to-- 00:47:31.550 --> 00:47:33.900 align:middle line:84% J is the one that I'm binding on. 00:47:33.900 --> 00:47:38.430 align:middle line:84% But I give you the instances are-- 00:47:38.430 --> 00:47:38.930 align:middle line:90% yeah. 00:47:38.930 --> 00:47:40.400 align:middle line:90% All of them are i. 00:47:40.400 --> 00:47:41.630 align:middle line:90% Sorry. 00:47:41.630 --> 00:47:44.630 align:middle line:84% J is the specific one on which I'm going to be-- 00:47:44.630 --> 00:47:46.190 align:middle line:90% I'm going to cheat on. 00:47:46.190 --> 00:47:47.160 align:middle line:90% All of them are i. 00:47:47.160 --> 00:47:48.440 align:middle line:90% Sorry about the-- yeah. 00:47:48.440 --> 00:47:53.720 align:middle line:90% 00:47:53.720 --> 00:47:56.280 align:middle line:90% Any other questions? 00:47:56.280 --> 00:47:59.560 align:middle line:90% 00:47:59.560 --> 00:48:04.550 align:middle line:84% So now the question is, now, what about nonsignaling? 00:48:04.550 --> 00:48:07.800 align:middle line:84% And nonsignaling-- I don't want to go into a lot of depth. 00:48:07.800 --> 00:48:12.320 align:middle line:90% But let me be hand-wavy here. 00:48:12.320 --> 00:48:14.480 align:middle line:90% The idea of why we're non-- 00:48:14.480 --> 00:48:19.610 align:middle line:84% so we want to argue that the local assignment generator-- 00:48:19.610 --> 00:48:25.520 align:middle line:84% the assignment values that he gives for any subset of wires 00:48:25.520 --> 00:48:30.300 align:middle line:84% do not depend on the other wires that is given to him. 00:48:30.300 --> 00:48:34.880 align:middle line:84% So if we look, if the extractor is given a bunch of wires 00:48:34.880 --> 00:48:38.240 align:middle line:84% and you look at the assignment and a subset, 00:48:38.240 --> 00:48:42.570 align:middle line:84% the distribution of the assignment that you get, 00:48:42.570 --> 00:48:45.680 align:middle line:84% it looks the same no matter what the other-- 00:48:45.680 --> 00:48:48.680 align:middle line:90% the rest of the wires are. 00:48:48.680 --> 00:48:51.220 align:middle line:90% And why is that? 00:48:51.220 --> 00:48:55.860 align:middle line:84% It just follows from the fact that-- 00:48:55.860 --> 00:48:58.080 align:middle line:90% I just erased it here. 00:48:58.080 --> 00:49:04.560 align:middle line:84% So it follows from the fact that when we do a sum or extractable 00:49:04.560 --> 00:49:07.830 align:middle line:84% hash with many-- when we construct 00:49:07.830 --> 00:49:10.890 align:middle line:84% a somewhat extractable hash with many indices that 00:49:10.890 --> 00:49:12.850 align:middle line:84% were extractable on many indices, 00:49:12.850 --> 00:49:17.670 align:middle line:84% we want to have the property that even if we extract it 00:49:17.670 --> 00:49:24.690 align:middle line:84% on some indices, the index hiding still 00:49:24.690 --> 00:49:25.840 align:middle line:90% holds for the other. 00:49:25.840 --> 00:49:27.900 align:middle line:84% So in other words, think of the way 00:49:27.900 --> 00:49:30.150 align:middle line:84% we're going to construct the somewhat extractable hash 00:49:30.150 --> 00:49:31.920 align:middle line:90% is by repetition. 00:49:31.920 --> 00:49:33.730 align:middle line:84% We're going to repeat it many, many times. 00:49:33.730 --> 00:49:40.680 align:middle line:84% So even if you saw if I extracted wire i1, wire i2, wire 00:49:40.680 --> 00:49:48.340 align:middle line:84% i3, the indices behind the other wires are completely hidden. 00:49:48.340 --> 00:49:53.730 align:middle line:84% So here, when you look at extract 00:49:53.730 --> 00:49:58.390 align:middle line:84% and a subset of witnesses, how do you find extract these? 00:49:58.390 --> 00:50:03.310 align:middle line:84% How does the local assignment generator generate these wires? 00:50:03.310 --> 00:50:06.720 align:middle line:84% He generates these wires using the corresponding trapdoors 00:50:06.720 --> 00:50:08.740 align:middle line:90% without the other trapdoors. 00:50:08.740 --> 00:50:11.103 align:middle line:90% So he actually has no idea. 00:50:11.103 --> 00:50:13.890 align:middle line:90% 00:50:13.890 --> 00:50:17.970 align:middle line:84% This should not signal anything about the value 00:50:17.970 --> 00:50:19.680 align:middle line:90% of the other wires. 00:50:19.680 --> 00:50:22.470 align:middle line:90% So again, let me say it again. 00:50:22.470 --> 00:50:24.700 align:middle line:84% Maybe I didn't say it quite right. 00:50:24.700 --> 00:50:28.170 align:middle line:84% But the local assignment generator, 00:50:28.170 --> 00:50:34.300 align:middle line:84% when he runs the cheating prover and the cheating prover, 00:50:34.300 --> 00:50:36.630 align:middle line:84% when you extract from the cheating 00:50:36.630 --> 00:50:40.300 align:middle line:84% prover the value of some of the wires, 00:50:40.300 --> 00:50:45.060 align:middle line:84% you need only to do that using the trapdoors for these wires. 00:50:45.060 --> 00:50:47.220 align:middle line:84% The cheating prover has no idea what 00:50:47.220 --> 00:50:50.390 align:middle line:84% the other wires-- what the trap door of the other wires are. 00:50:50.390 --> 00:50:53.890 align:middle line:84% So these values should not depend at all 00:50:53.890 --> 00:50:59.900 align:middle line:84% about the other indices used in the other repetitions. 00:50:59.900 --> 00:51:05.040 align:middle line:84% Otherwise, you've broken the timing for these repetitions. 00:51:05.040 --> 00:51:12.640 align:middle line:84% So the point is the nonsignaling really follows in a sense 00:51:12.640 --> 00:51:16.820 align:middle line:84% from the nonsignaling in the somewhat extractable hash. 00:51:16.820 --> 00:51:18.340 align:middle line:84% The somewhat extractable hash, when 00:51:18.340 --> 00:51:22.150 align:middle line:84% we repeat, when we do repetition, what we can argue 00:51:22.150 --> 00:51:28.660 align:middle line:84% is any cheating prover who, given a hash key, 00:51:28.660 --> 00:51:31.120 align:middle line:90% generates a value. 00:51:31.120 --> 00:51:37.570 align:middle line:84% If you extract some of the wires, the value you get 00:51:37.570 --> 00:51:40.820 align:middle line:84% do not depend on the other indices. 00:51:40.820 --> 00:51:44.300 align:middle line:84% This is a property of the somewhat extractable hash. 00:51:44.300 --> 00:51:47.380 align:middle line:84% So nonsignaling here follows directly 00:51:47.380 --> 00:51:50.920 align:middle line:84% from the nonsignaling of the somewhat extractable hash. 00:51:50.920 --> 00:51:52.700 align:middle line:90% So I'm running out of time. 00:51:52.700 --> 00:51:56.080 align:middle line:84% I don't want to go too much in depth because I 00:51:56.080 --> 00:51:57.560 align:middle line:90% think it's not as interesting. 00:51:57.560 --> 00:52:02.860 align:middle line:84% I want to actually go and talk about why is this not sufficient 00:52:02.860 --> 00:52:04.640 align:middle line:90% and when is it sufficient. 00:52:04.640 --> 00:52:07.465 align:middle line:90% 00:52:07.465 --> 00:52:09.050 align:middle line:90% So let's call-- let's say-- 00:52:09.050 --> 00:52:10.030 align:middle line:90% OK, so we have-- 00:52:10.030 --> 00:52:12.610 align:middle line:84% suppose we have a cheating prover. 00:52:12.610 --> 00:52:17.680 align:middle line:84% We manage to construct from him this local assignment generator. 00:52:17.680 --> 00:52:20.350 align:middle line:90% So we have the circuit. 00:52:20.350 --> 00:52:22.550 align:middle line:90% We have a cheating prover. 00:52:22.550 --> 00:52:24.280 align:middle line:90% He gave me an x. 00:52:24.280 --> 00:52:25.115 align:middle line:90% We want to argue. 00:52:25.115 --> 00:52:25.990 align:middle line:90% It's in the language. 00:52:25.990 --> 00:52:28.550 align:middle line:84% If he convinced me, it must be in the language. 00:52:28.550 --> 00:52:30.250 align:middle line:90% That's what soundness means. 00:52:30.250 --> 00:52:31.430 align:middle line:90% What do we know? 00:52:31.430 --> 00:52:34.755 align:middle line:84% We know when we look at any window, everything looks good. 00:52:34.755 --> 00:52:37.130 align:middle line:84% And when you look at the window that contains the output, 00:52:37.130 --> 00:52:39.700 align:middle line:90% it's 1. 00:52:39.700 --> 00:52:44.337 align:middle line:84% Does that mean we can have an entire assignment 00:52:44.337 --> 00:52:46.920 align:middle line:84% to all the wires that everything is consistent, in which case, 00:52:46.920 --> 00:52:50.180 align:middle line:90% we can then sound? 00:52:50.180 --> 00:52:52.240 align:middle line:84% So can we piece these things together? 00:52:52.240 --> 00:53:02.450 align:middle line:90% 00:53:02.450 --> 00:53:06.110 align:middle line:90% So the answer is yes and no. 00:53:06.110 --> 00:53:06.750 align:middle line:90% OK. 00:53:06.750 --> 00:53:09.925 align:middle line:84% So in general for np, the answer is no. 00:53:09.925 --> 00:53:11.550 align:middle line:84% We don't know how to piece it together. 00:53:11.550 --> 00:53:14.540 align:middle line:84% Moreover, we believe that you can't piece it together 00:53:14.540 --> 00:53:16.460 align:middle line:90% for any np language. 00:53:16.460 --> 00:53:24.470 align:middle line:84% We believe that there exists very hard NP languages 00:53:24.470 --> 00:53:26.610 align:middle line:84% that there's no way you can piece it together. 00:53:26.610 --> 00:53:29.480 align:middle line:90% But let me tell you why. 00:53:29.480 --> 00:53:32.330 align:middle line:84% Why is it hard to piece things together? 00:53:32.330 --> 00:53:34.820 align:middle line:90% And the reason is, even-- 00:53:34.820 --> 00:53:37.230 align:middle line:84% let's even think, now, for simplicity, 00:53:37.230 --> 00:53:38.940 align:middle line:84% I think, it would be easier to think, 00:53:38.940 --> 00:53:43.890 align:middle line:84% let's say, even in the nonadaptive version, x is fixed. 00:53:43.890 --> 00:53:49.500 align:middle line:84% Can we argue that for this fixed x, 00:53:49.500 --> 00:53:53.250 align:middle line:84% we can piece everything together? 00:53:53.250 --> 00:53:55.980 align:middle line:84% And the reason why it's hard to piece everything together 00:53:55.980 --> 00:54:00.090 align:middle line:84% is because this local assignment generator, every time 00:54:00.090 --> 00:54:03.630 align:middle line:84% you give them a bunch of wires, think 00:54:03.630 --> 00:54:07.620 align:middle line:90% of even a valid kind of prover. 00:54:07.620 --> 00:54:08.680 align:middle line:90% Think of a valid prover. 00:54:08.680 --> 00:54:11.860 align:middle line:84% Every time you run him, he uses a different witnesses. 00:54:11.860 --> 00:54:14.350 align:middle line:84% Maybe he has many, many witnesses in his disposal. 00:54:14.350 --> 00:54:16.240 align:middle line:84% Every time you run him, he's honest, 00:54:16.240 --> 00:54:18.165 align:middle line:90% but with a different witness. 00:54:18.165 --> 00:54:19.540 align:middle line:84% So it's actually in the language. 00:54:19.540 --> 00:54:23.220 align:middle line:84% But the question is, are we able to construct a satisfying 00:54:23.220 --> 00:54:24.280 align:middle line:90% assignment? 00:54:24.280 --> 00:54:26.760 align:middle line:84% And the reason why this is hard is-- or seems 00:54:26.760 --> 00:54:31.870 align:middle line:84% hard is because, OK, we have our local assignment generator. 00:54:31.870 --> 00:54:33.760 align:middle line:90% We give him a bunch of wires. 00:54:33.760 --> 00:54:35.820 align:middle line:84% He chooses one of his witnesses at random-- 00:54:35.820 --> 00:54:37.890 align:middle line:84% because that's what the cheating prover does-- and gives him 00:54:37.890 --> 00:54:39.520 align:middle line:84% an assignment with this, the witness. 00:54:39.520 --> 00:54:40.960 align:middle line:90% OK, local consistent. 00:54:40.960 --> 00:54:41.470 align:middle line:90% We're fine. 00:54:41.470 --> 00:54:42.340 align:middle line:90% We're happy. 00:54:42.340 --> 00:54:43.600 align:middle line:90% Now we run him again. 00:54:43.600 --> 00:54:45.360 align:middle line:90% He uses a different witness. 00:54:45.360 --> 00:54:46.295 align:middle line:90% It doesn't match. 00:54:46.295 --> 00:54:49.350 align:middle line:90% 00:54:49.350 --> 00:54:51.130 align:middle line:90% How do we match things together? 00:54:51.130 --> 00:54:53.620 align:middle line:84% So that's why in the nondeterministic case 00:54:53.620 --> 00:54:57.400 align:middle line:84% things are really difficult. And we do have some results, 00:54:57.400 --> 00:54:58.960 align:middle line:90% but for very specific languages. 00:54:58.960 --> 00:55:01.110 align:middle line:90% Let me not go into that. 00:55:01.110 --> 00:55:02.890 align:middle line:84% Let's talk about deterministic languages. 00:55:02.890 --> 00:55:05.260 align:middle line:90% That seems to be much easier. 00:55:05.260 --> 00:55:08.530 align:middle line:84% So let me first convince you that we can do it. 00:55:08.530 --> 00:55:11.040 align:middle line:84% And then I'll show you where I cheated. 00:55:11.040 --> 00:55:16.440 align:middle line:90% So let's first take a circuit. 00:55:16.440 --> 00:55:18.720 align:middle line:84% We have a local assignment generator. 00:55:18.720 --> 00:55:21.970 align:middle line:84% So let me convince you that the output must be 1. 00:55:21.970 --> 00:55:24.995 align:middle line:84% So we have an input-- x1 up to xn. 00:55:24.995 --> 00:55:28.500 align:middle line:90% 00:55:28.500 --> 00:55:31.180 align:middle line:84% I'm going to call my local assignment generator. 00:55:31.180 --> 00:55:34.260 align:middle line:84% I'm going to tell him, give me the values here. 00:55:34.260 --> 00:55:35.070 align:middle line:90% Or here, let me-- 00:55:35.070 --> 00:55:36.010 align:middle line:90% I have l, right? 00:55:36.010 --> 00:55:37.740 align:middle line:84% So let me use my l here, here, and here. 00:55:37.740 --> 00:55:38.640 align:middle line:90% I don't know. 00:55:38.640 --> 00:55:40.000 align:middle line:90% He gives me values. 00:55:40.000 --> 00:55:42.910 align:middle line:84% Now, this must be consistent because I 00:55:42.910 --> 00:55:46.040 align:middle line:84% know local consistency holds probability 1 minus negligible. 00:55:46.040 --> 00:55:49.630 align:middle line:84% And all of them are consistent, which means 00:55:49.630 --> 00:55:51.230 align:middle line:90% these are the correct values. 00:55:51.230 --> 00:55:53.320 align:middle line:90% Now we're deterministic. 00:55:53.320 --> 00:55:56.260 align:middle line:84% We're talking about a deterministic circuit. 00:55:56.260 --> 00:55:58.292 align:middle line:84% So if this is locally consistent, 00:55:58.292 --> 00:55:59.750 align:middle line:84% it means this is the correct value. 00:55:59.750 --> 00:56:00.050 align:middle line:90% I don't know. 00:56:00.050 --> 00:56:01.883 align:middle line:84% If it's an AND, it's an AND, whatever it is. 00:56:01.883 --> 00:56:04.780 align:middle line:90% So all of these are correct. 00:56:04.780 --> 00:56:08.200 align:middle line:84% I can argue, when I run the cheating-- the assignment-- so 00:56:08.200 --> 00:56:12.910 align:middle line:84% I want to argue essentially any local assignment 00:56:12.910 --> 00:56:16.423 align:middle line:84% generator, every wire he gives me must be the correct one. 00:56:16.423 --> 00:56:18.590 align:middle line:84% And then I'm done because the output is the correct. 00:56:18.590 --> 00:56:20.600 align:middle line:84% And if he gives me output 1, voila. 00:56:20.600 --> 00:56:21.230 align:middle line:90% It's correct. 00:56:21.230 --> 00:56:22.750 align:middle line:90% I'm done. 00:56:22.750 --> 00:56:25.450 align:middle line:84% So I'm going to argue, kind of by induction, 00:56:25.450 --> 00:56:28.750 align:middle line:84% that every wire he gives me must be the correct one. 00:56:28.750 --> 00:56:30.070 align:middle line:90% Why? 00:56:30.070 --> 00:56:30.850 align:middle line:90% OK. 00:56:30.850 --> 00:56:34.130 align:middle line:84% Let's try-- so I'm going to argue layer by layer. 00:56:34.130 --> 00:56:37.270 align:middle line:84% The induction is going to be by the-- think of the circuit 00:56:37.270 --> 00:56:37.940 align:middle line:90% as layered. 00:56:37.940 --> 00:56:41.590 align:middle line:84% And I'm going to argue this by induction on the layers. 00:56:41.590 --> 00:56:44.390 align:middle line:84% Layer 1-- what does the cheating prover gives me? 00:56:44.390 --> 00:56:46.070 align:middle line:90% He gives me an assignment. 00:56:46.070 --> 00:56:49.040 align:middle line:84% Now, I know I proved it locally satisfiable, 00:56:49.040 --> 00:56:51.290 align:middle line:84% which means it satisfies the gate. 00:56:51.290 --> 00:56:52.570 align:middle line:90% So it's correct. 00:56:52.570 --> 00:56:54.910 align:middle line:90% So layer 1, correct. 00:56:54.910 --> 00:56:56.770 align:middle line:90% Let's go to layer 2. 00:56:56.770 --> 00:56:59.660 align:middle line:84% Layer 2, now I'm going to ask him this. 00:56:59.660 --> 00:57:02.200 align:middle line:84% Let's say I'm going to ask him these. 00:57:02.200 --> 00:57:04.690 align:middle line:84% I want to argue that this is correct. 00:57:04.690 --> 00:57:07.810 align:middle line:84% All I know is that it's locally consistent. 00:57:07.810 --> 00:57:11.450 align:middle line:84% But I know that these are correct. 00:57:11.450 --> 00:57:13.760 align:middle line:90% Why are these correct? 00:57:13.760 --> 00:57:16.780 align:middle line:84% Because of the nonsignaling, I know. 00:57:16.780 --> 00:57:22.450 align:middle line:84% If I asked, give me these wires, give me these wires 00:57:22.450 --> 00:57:25.490 align:middle line:90% with the input, it was correct. 00:57:25.490 --> 00:57:27.520 align:middle line:90% I got the correct answer. 00:57:27.520 --> 00:57:31.370 align:middle line:84% So now when I ask the extract the local assignment generator, 00:57:31.370 --> 00:57:34.960 align:middle line:84% give me these wires with these, we 00:57:34.960 --> 00:57:38.660 align:middle line:84% said the distribution is the same up to-- or computationally 00:57:38.660 --> 00:57:39.950 align:middle line:90% indistinguishable. 00:57:39.950 --> 00:57:45.920 align:middle line:84% So when I asked him, give me the value of this wire, 00:57:45.920 --> 00:57:49.550 align:middle line:84% when I asked with the inputs or asked, 00:57:49.550 --> 00:57:53.245 align:middle line:84% give me these wires with this, it's the same distribution. 00:57:53.245 --> 00:57:55.800 align:middle line:84% If it was correct before, it's correct now. 00:57:55.800 --> 00:57:58.770 align:middle line:84% So these are correct, and this is locally consistent. 00:57:58.770 --> 00:58:00.680 align:middle line:90% So this is also correct. 00:58:00.680 --> 00:58:03.290 align:middle line:90% So these layers are correct. 00:58:03.290 --> 00:58:06.180 align:middle line:84% And again, now let's look at these. 00:58:06.180 --> 00:58:07.170 align:middle line:90% Is this correct? 00:58:07.170 --> 00:58:10.160 align:middle line:84% Yeah, because these still need to be correct 00:58:10.160 --> 00:58:11.630 align:middle line:90% because we argued it correct. 00:58:11.630 --> 00:58:13.652 align:middle line:84% And it doesn't depend on the distribution. 00:58:13.652 --> 00:58:15.860 align:middle line:84% It doesn't depend on the-- every time I ask him this, 00:58:15.860 --> 00:58:18.360 align:middle line:84% I get probability 1 minus negligible-- so correct. 00:58:18.360 --> 00:58:20.660 align:middle line:90% So this is correct. 00:58:20.660 --> 00:58:22.770 align:middle line:84% By induction, the output is correct. 00:58:22.770 --> 00:58:23.640 align:middle line:90% I know it's 1. 00:58:23.640 --> 00:58:27.660 align:middle line:84% That's what the local assignment generator promised me. 00:58:27.660 --> 00:58:29.480 align:middle line:90% So it's 1 and correct. 00:58:29.480 --> 00:58:30.280 align:middle line:90% I'm done. 00:58:30.280 --> 00:58:36.545 align:middle line:90% 00:58:36.545 --> 00:58:37.410 align:middle line:90% That's the proof. 00:58:37.410 --> 00:58:38.910 align:middle line:84% Moreover, let me tell you something. 00:58:38.910 --> 00:58:42.600 align:middle line:84% When we wrote this proof, we wrote it. 00:58:42.600 --> 00:58:44.160 align:middle line:90% We were happy with it. 00:58:44.160 --> 00:58:46.818 align:middle line:84% We literally almost submitted this thing. 00:58:46.818 --> 00:58:48.360 align:middle line:84% A couple of days before the deadline, 00:58:48.360 --> 00:58:49.880 align:middle line:90% we noticed there's a bug. 00:58:49.880 --> 00:58:51.000 align:middle line:90% This is wrong. 00:58:51.000 --> 00:58:51.865 align:middle line:90% This does not work. 00:58:51.865 --> 00:58:54.403 align:middle line:90% 00:58:54.403 --> 00:58:56.820 align:middle line:84% I'll tell you why it doesn't work as opposed to asking you 00:58:56.820 --> 00:58:58.140 align:middle line:90% because I think it's so subtle. 00:58:58.140 --> 00:58:59.970 align:middle line:84% But does anybody see why it doesn't work? 00:58:59.970 --> 00:59:01.762 align:middle line:84% It's very, very hard to see, in my opinion. 00:59:01.762 --> 00:59:03.510 align:middle line:84% But I mean, clearly, I didn't see it. 00:59:03.510 --> 00:59:08.600 align:middle line:84% But anybody see why I cheated here? 00:59:08.600 --> 00:59:09.608 align:middle line:90% Yeah? 00:59:09.608 --> 00:59:11.150 align:middle line:84% AUDIENCE: Is it because we restricted 00:59:11.150 --> 00:59:12.850 align:middle line:90% to deterministic witness? 00:59:12.850 --> 00:59:16.303 align:middle line:90% 00:59:16.303 --> 00:59:16.970 align:middle line:90% PROFESSOR: Yeah. 00:59:16.970 --> 00:59:17.670 align:middle line:90% So what? 00:59:17.670 --> 00:59:18.260 align:middle line:90% Why? 00:59:18.260 --> 00:59:19.743 align:middle line:90% Yeah, there's only the input. 00:59:19.743 --> 00:59:21.660 align:middle line:84% Actually, the fact that there's deterministic, 00:59:21.660 --> 00:59:25.077 align:middle line:84% it's helpful for us because now there's a notion of correctness. 00:59:25.077 --> 00:59:27.660 align:middle line:84% Once there's a witness, there's no-- what do you mean correct? 00:59:27.660 --> 00:59:28.618 align:middle line:90% Depends on the witness. 00:59:28.618 --> 00:59:31.140 align:middle line:84% Every wire has, like, if you use this witness, 00:59:31.140 --> 00:59:32.180 align:middle line:90% it can be this value. 00:59:32.180 --> 00:59:34.500 align:middle line:84% Here, because it's deterministic, 00:59:34.500 --> 00:59:36.550 align:middle line:84% there's only one value for each wire. 00:59:36.550 --> 00:59:39.613 align:middle line:84% And so there's the notion of correct value. 00:59:39.613 --> 00:59:42.150 align:middle line:90% 00:59:42.150 --> 00:59:44.795 align:middle line:84% And I can argue by induction that everything is correct. 00:59:44.795 --> 00:59:55.830 align:middle line:90% 00:59:55.830 --> 01:00:00.768 align:middle line:90% So I'll tell you why. 01:00:00.768 --> 01:00:01.960 align:middle line:90% I suffered through this. 01:00:01.960 --> 01:00:05.700 align:middle line:90% I have the desire to have you-- 01:00:05.700 --> 01:00:07.540 align:middle line:84% to torture you a little bit to see why. 01:00:07.540 --> 01:00:08.527 align:middle line:90% And so like I-- 01:00:08.527 --> 01:00:09.610 align:middle line:90% like the experience I had. 01:00:09.610 --> 01:00:14.560 align:middle line:84% But given that you only have 10 minutes left, I'll tell you. 01:00:14.560 --> 01:00:15.725 align:middle line:90% So here's why. 01:00:15.725 --> 01:00:18.540 align:middle line:90% 01:00:18.540 --> 01:00:25.140 align:middle line:90% So local consistency holds-- 01:00:25.140 --> 01:00:31.920 align:middle line:84% or yeah, local consistency holds with probability-- 01:00:31.920 --> 01:00:35.640 align:middle line:84% or the nonsignaling, everything holds with probability 1 01:00:35.640 --> 01:00:37.990 align:middle line:84% minus negligible, not with probability 1. 01:00:37.990 --> 01:00:39.840 align:middle line:84% If everything with probability 1-- 01:00:39.840 --> 01:00:44.980 align:middle line:84% 1, local consistency-- then this consists only 1. 01:00:44.980 --> 01:00:47.890 align:middle line:90% Then, everything would work out. 01:00:47.890 --> 01:00:51.000 align:middle line:84% If I promised you local consistency with probability 1 01:00:51.000 --> 01:00:52.860 align:middle line:84% and nonsignaling with probability 1, 01:00:52.860 --> 01:00:55.390 align:middle line:84% like it's exactly the same, we're good. 01:00:55.390 --> 01:00:57.270 align:middle line:90% Then I can prove. 01:00:57.270 --> 01:01:00.330 align:middle line:84% Now, it's used in cryptography, oh, come on, negligible. 01:01:00.330 --> 01:01:02.070 align:middle line:90% It's 0. 01:01:02.070 --> 01:01:03.160 align:middle line:90% Here, It's not zero. 01:01:03.160 --> 01:01:05.380 align:middle line:84% It turns out, negligible is a pain. 01:01:05.380 --> 01:01:07.540 align:middle line:84% This is the entire problem, the negligible. 01:01:07.540 --> 01:01:08.710 align:middle line:90% And I'll tell you why. 01:01:08.710 --> 01:01:10.140 align:middle line:90% It seems weird, but here's why. 01:01:10.140 --> 01:01:14.880 align:middle line:84% The reason is this is correct with 01:01:14.880 --> 01:01:16.570 align:middle line:90% all-but-negligible probability. 01:01:16.570 --> 01:01:20.820 align:middle line:84% So this is correct, except probability mu. 01:01:20.820 --> 01:01:25.290 align:middle line:84% This is correct, except with probability mu. 01:01:25.290 --> 01:01:29.800 align:middle line:84% But now this is correct if this needs to be correct, 01:01:29.800 --> 01:01:31.140 align:middle line:90% and this needs to be correct. 01:01:31.140 --> 01:01:34.420 align:middle line:84% If one of them is incorrect, you're not correct. 01:01:34.420 --> 01:01:35.840 align:middle line:90% So this is correct. 01:01:35.840 --> 01:01:41.080 align:middle line:84% Is probably correct, except probability 2 mu. 01:01:41.080 --> 01:01:43.400 align:middle line:90% So here, you have 2 mu. 01:01:43.400 --> 01:01:47.410 align:middle line:90% Now, 2 mu is also negligible. 01:01:47.410 --> 01:01:49.970 align:middle line:90% This is also acceptable 2 mu. 01:01:49.970 --> 01:01:53.500 align:middle line:84% But this-- for this to be correct, both of them 01:01:53.500 --> 01:01:54.440 align:middle line:90% need to be correct. 01:01:54.440 --> 01:01:58.720 align:middle line:84% So here, you have 4 mu and then 8 mu. 01:01:58.720 --> 01:02:02.590 align:middle line:84% You can get 2 to the depth times mu. 01:02:02.590 --> 01:02:07.480 align:middle line:84% Now, if the depth is more than log, 01:02:07.480 --> 01:02:09.620 align:middle line:90% it's not negligible anymore. 01:02:09.620 --> 01:02:13.120 align:middle line:90% 01:02:13.120 --> 01:02:16.120 align:middle line:84% So the problem is 2 to the depth may be much bigger than 1 01:02:16.120 --> 01:02:19.090 align:middle line:90% over mu. 01:02:19.090 --> 01:02:24.820 align:middle line:84% So there's this exponential curse of-- 01:02:24.820 --> 01:02:29.470 align:middle line:84% we carry-- the error grows by a factor of 2 each time 01:02:29.470 --> 01:02:32.590 align:middle line:90% and eventually it can kill us. 01:02:32.590 --> 01:02:34.270 align:middle line:90% That's the bug. 01:02:34.270 --> 01:02:36.650 align:middle line:84% So this works if it's bound to depth. 01:02:36.650 --> 01:02:37.970 align:middle line:90% Log depth, yes. 01:02:37.970 --> 01:02:43.420 align:middle line:90% More than that, not clear. 01:02:43.420 --> 01:02:45.550 align:middle line:90% OK. 01:02:45.550 --> 01:02:47.590 align:middle line:90% So what do we do? 01:02:47.590 --> 01:02:53.200 align:middle line:84% So to fix this, there is two ways to fix this. 01:02:53.200 --> 01:02:55.660 align:middle line:84% Option number 1, which is what we did originally 01:02:55.660 --> 01:02:58.760 align:middle line:84% because we didn't have a better idea, is we said, you know what? 01:02:58.760 --> 01:03:02.320 align:middle line:84% Let's assume that this circuit is very narrow. 01:03:02.320 --> 01:03:06.730 align:middle line:84% Think of bounded depth deterministic computations-- 01:03:06.730 --> 01:03:08.390 align:middle line:90% sorry, bounded space. 01:03:08.390 --> 01:03:10.090 align:middle line:84% So think of a distributed computation 01:03:10.090 --> 01:03:12.500 align:middle line:84% where each configuration is very small-- 01:03:12.500 --> 01:03:17.470 align:middle line:84% so like a Turing machine that has very-- 01:03:17.470 --> 01:03:20.050 align:middle line:84% the tableau is very thin and long. 01:03:20.050 --> 01:03:21.680 align:middle line:90% And then we said, you know what? 01:03:21.680 --> 01:03:26.960 align:middle line:84% Let's make L, like where you're statistically bounded on-- 01:03:26.960 --> 01:03:28.880 align:middle line:84% let's make it an entire configuration. 01:03:28.880 --> 01:03:31.715 align:middle line:84% So yeah, you pay with an entire-- 01:03:31.715 --> 01:03:32.880 align:middle line:90% with a space. 01:03:32.880 --> 01:03:35.880 align:middle line:84% The SNARG, the proof will grow with the space. 01:03:35.880 --> 01:03:38.430 align:middle line:84% But now we say, you can read the entire thing. 01:03:38.430 --> 01:03:41.940 align:middle line:84% You can read-- so here's the tableau. 01:03:41.940 --> 01:03:43.830 align:middle line:84% You can read the entire computation. 01:03:43.830 --> 01:03:45.660 align:middle line:84% You can read the entire configuration. 01:03:45.660 --> 01:03:48.600 align:middle line:84% And now we say, the first configuration is correct, 01:03:48.600 --> 01:03:49.640 align:middle line:90% so the probability mu. 01:03:49.640 --> 01:03:52.910 align:middle line:84% The second configuration, if this was correct, 01:03:52.910 --> 01:03:55.740 align:middle line:90% this is 2 mu, 3 mu, 4 mu. 01:03:55.740 --> 01:03:57.800 align:middle line:84% It doesn't grow exponential anymore 01:03:57.800 --> 01:04:00.140 align:middle line:84% because you read the entire thing. 01:04:00.140 --> 01:04:03.450 align:middle line:84% So I'm going to read these two configurations together. 01:04:03.450 --> 01:04:05.695 align:middle line:84% If this was consistent, this is consistent. 01:04:05.695 --> 01:04:08.070 align:middle line:84% There's always a probability of error that I'm incurring. 01:04:08.070 --> 01:04:09.380 align:middle line:90% Fine. 01:04:09.380 --> 01:04:12.720 align:middle line:84% But it doesn't double because I'm reading the entire thing. 01:04:12.720 --> 01:04:15.950 align:middle line:84% I said, if this was a correct configuration, 01:04:15.950 --> 01:04:18.140 align:middle line:84% then when I read this with this, this 01:04:18.140 --> 01:04:19.920 align:middle line:84% is going to be correct configuration. 01:04:19.920 --> 01:04:23.960 align:middle line:84% But I read the entire thing, so I don't double up things. 01:04:23.960 --> 01:04:29.660 align:middle line:84% So we get SNARG for any computation that's 01:04:29.660 --> 01:04:34.370 align:middle line:84% bounded space where the SNARG grows with the space. 01:04:34.370 --> 01:04:34.987 align:middle line:90% OK. 01:04:34.987 --> 01:04:36.570 align:middle line:84% But let me tell you, we can do better. 01:04:36.570 --> 01:04:39.170 align:middle line:84% We can actually-- we don't need to grow with the space. 01:04:39.170 --> 01:04:41.810 align:middle line:84% So I'll just say a word because I'm running out of time, 01:04:41.810 --> 01:04:43.860 align:middle line:84% and I want to do a quick summary. 01:04:43.860 --> 01:04:49.910 align:middle line:84% But the idea of not running into this exponential curse idea 01:04:49.910 --> 01:04:51.860 align:middle line:90% is to say the following. 01:04:51.860 --> 01:04:55.850 align:middle line:90% Let's do this hash in the BARG. 01:04:55.850 --> 01:04:57.110 align:middle line:90% So what did we do? 01:04:57.110 --> 01:05:00.290 align:middle line:84% This SNARG is like, hash all the wires and then BARG. 01:05:00.290 --> 01:05:03.950 align:middle line:84% The idea is don't do hash and BARG in the original circuit. 01:05:03.950 --> 01:05:07.280 align:middle line:84% Don't just do hash and BARG in the verification circuit. 01:05:07.280 --> 01:05:10.710 align:middle line:84% Do hash and BARG and an extended circuit. 01:05:10.710 --> 01:05:12.090 align:middle line:90% Change the circuit. 01:05:12.090 --> 01:05:16.130 align:middle line:84% Do hash and BARG on a slightly more elaborate circuit. 01:05:16.130 --> 01:05:18.075 align:middle line:84% So what is the more elaborate circuit? 01:05:18.075 --> 01:05:19.200 align:middle line:90% Let me give you an example. 01:05:19.200 --> 01:05:21.620 align:middle line:90% One example you can do-- 01:05:21.620 --> 01:05:30.000 align:middle line:84% take each kind of layer and add a Merkle hash in the circuit. 01:05:30.000 --> 01:05:32.740 align:middle line:84% So now before you add a verification circuit, 01:05:32.740 --> 01:05:33.910 align:middle line:90% change it a little bit. 01:05:33.910 --> 01:05:35.380 align:middle line:90% How do you change it? 01:05:35.380 --> 01:05:39.280 align:middle line:84% You compute each one, and then you compute a Merkle hash. 01:05:39.280 --> 01:05:42.010 align:middle line:84% Compute the next layer, and compute a Merkle hash. 01:05:42.010 --> 01:05:44.200 align:middle line:84% Compute the next layer, compute a Merkle hash. 01:05:44.200 --> 01:05:44.970 align:middle line:90% It's weird. 01:05:44.970 --> 01:05:46.060 align:middle line:90% Why would you do that? 01:05:46.060 --> 01:05:47.020 align:middle line:90% Do that. 01:05:47.020 --> 01:05:50.820 align:middle line:84% Moreover, also compute for every wire like the opening 01:05:50.820 --> 01:05:52.500 align:middle line:90% of the Merkle hash. 01:05:52.500 --> 01:05:55.320 align:middle line:84% And add all these Merkle hashes, and I add all these openings 01:05:55.320 --> 01:05:56.170 align:middle line:90% to the circuit. 01:05:56.170 --> 01:05:58.090 align:middle line:84% Now, that seems a ridiculous thing to do. 01:05:58.090 --> 01:06:00.270 align:middle line:84% Why would you add to the circuit that you're 01:06:00.270 --> 01:06:03.540 align:middle line:84% trying to verify that it's correct for each wire, 01:06:03.540 --> 01:06:09.400 align:middle line:84% Merkle hash all the wires, and add wires that check opening? 01:06:09.400 --> 01:06:10.450 align:middle line:90% Like, what? 01:06:10.450 --> 01:06:15.940 align:middle line:84% This sounds really weird and not a very-- a weird thing to do. 01:06:15.940 --> 01:06:17.740 align:middle line:84% Sorry, you don't need to check opening. 01:06:17.740 --> 01:06:19.090 align:middle line:90% You just add Merkle hashes. 01:06:19.090 --> 01:06:21.130 align:middle line:84% And for each wire, add Merkle hash to the wire. 01:06:21.130 --> 01:06:24.060 align:middle line:84% For each layer, add a Merkle hash, so on, and so forth. 01:06:24.060 --> 01:06:29.080 align:middle line:84% Why is adding Merkle hashes helpful at all? 01:06:29.080 --> 01:06:33.550 align:middle line:84% So I'll tell you why it's helpful, because now we have 01:06:33.550 --> 01:06:36.220 align:middle line:90% the local assignment generator. 01:06:36.220 --> 01:06:38.660 align:middle line:84% And now in the local assignment generator, 01:06:38.660 --> 01:06:41.440 align:middle line:84% what we can do-- we said, the first layer, each one 01:06:41.440 --> 01:06:44.050 align:middle line:90% is correct. 01:06:44.050 --> 01:06:46.420 align:middle line:84% Now we're going to argue, this implies 01:06:46.420 --> 01:06:52.400 align:middle line:84% that the Merkle root is correct, that this must be correct. 01:06:52.400 --> 01:06:56.630 align:middle line:84% Now, when we argue it, we do pay exponential with the depth. 01:06:56.630 --> 01:06:58.060 align:middle line:90% So this is a computation. 01:06:58.060 --> 01:07:01.910 align:middle line:84% And the error does grow, but the depth is long. 01:07:01.910 --> 01:07:05.440 align:middle line:84% Merkle hash is a very low-depth computation, so it grows. 01:07:05.440 --> 01:07:07.360 align:middle line:90% But polynomially, it's OK. 01:07:07.360 --> 01:07:11.620 align:middle line:84% Now, when we read things here, we're 01:07:11.620 --> 01:07:13.640 align:middle line:84% going to read them together with a root. 01:07:13.640 --> 01:07:15.250 align:middle line:84% We're not going to just-- we're going 01:07:15.250 --> 01:07:20.200 align:middle line:84% to say that when we ask the local assignment generator, what 01:07:20.200 --> 01:07:21.050 align:middle line:90% is the value? 01:07:21.050 --> 01:07:24.130 align:middle line:84% Give me the value here, here, here, we're 01:07:24.130 --> 01:07:26.890 align:middle line:84% going to also say, and give me the value 01:07:26.890 --> 01:07:32.050 align:middle line:84% of the root and the paths corresponding to this and this. 01:07:32.050 --> 01:07:33.950 align:middle line:84% And now the thing is the following. 01:07:33.950 --> 01:07:37.690 align:middle line:84% If the root was correct, both of them 01:07:37.690 --> 01:07:40.840 align:middle line:84% have to be correct unless you broke the hash function. 01:07:40.840 --> 01:07:43.910 align:middle line:84% So you don't need to get this independence. 01:07:43.910 --> 01:07:47.020 align:middle line:84% Before, we were like, oh, we needed this to be correct 01:07:47.020 --> 01:07:50.140 align:middle line:84% and this to be correct, and things doubled. 01:07:50.140 --> 01:07:52.730 align:middle line:84% Here, we can say, if the root is correct, 01:07:52.730 --> 01:07:56.830 align:middle line:84% we know that both of them have to be correct. 01:07:56.830 --> 01:07:59.510 align:middle line:84% So it's enough to argue that the root is correct. 01:07:59.510 --> 01:08:04.790 align:middle line:84% So it's a little bit simulates the case of reading 01:08:04.790 --> 01:08:08.150 align:middle line:84% the entire configuration or an entire layer, 01:08:08.150 --> 01:08:10.870 align:middle line:84% which is what we did in the bounded space. 01:08:10.870 --> 01:08:12.530 align:middle line:90% So I don't want to go-- 01:08:12.530 --> 01:08:14.240 align:middle line:84% I think that's all I want to say. 01:08:14.240 --> 01:08:16.960 align:middle line:84% But essentially, what I want to mention 01:08:16.960 --> 01:08:22.120 align:middle line:84% is this local satisfiability, or local soundness, 01:08:22.120 --> 01:08:28.250 align:middle line:84% or local consistency does not necessarily 01:08:28.250 --> 01:08:30.000 align:middle line:90% imply global correctness. 01:08:30.000 --> 01:08:32.630 align:middle line:84% Actually, , to use it to get global correctness, often, 01:08:32.630 --> 01:08:38.390 align:middle line:84% we need to change the circuit and do circuit gymnastics 01:08:38.390 --> 01:08:40.859 align:middle line:90% in weird ways to get it to work. 01:08:40.859 --> 01:08:44.240 align:middle line:84% And this is still work in progress. 01:08:44.240 --> 01:08:47.623 align:middle line:84% Us as a community are still combating with this. 01:08:47.623 --> 01:08:49.790 align:middle line:84% I see smiles because my students have been suffering 01:08:49.790 --> 01:08:52.040 align:middle line:90% with me through this a lot. 01:08:52.040 --> 01:08:53.860 align:middle line:84% It's like half smiling, half crying. 01:08:53.860 --> 01:08:58.229 align:middle line:90% 01:08:58.229 --> 01:09:01.080 align:middle line:90% So that's where we are today. 01:09:01.080 --> 01:09:03.470 align:middle line:84% So let me use the last three minutes 01:09:03.470 --> 01:09:06.029 align:middle line:90% or so to do a quick summary. 01:09:06.029 --> 01:09:11.510 align:middle line:84% So first of all, before I summarize, 01:09:11.510 --> 01:09:14.130 align:middle line:84% if you have any feedback, there's feedback forms. 01:09:14.130 --> 01:09:18.109 align:middle line:90% Please submit, so I'll improve. 01:09:18.109 --> 01:09:19.700 align:middle line:84% Or I'll keep on doing things that 01:09:19.700 --> 01:09:22.439 align:middle line:84% worked to try not to do things that didn't work. 01:09:22.439 --> 01:09:26.300 align:middle line:84% So it will be great, great, great. if you 01:09:26.300 --> 01:09:27.899 align:middle line:90% can submit the feedback form. 01:09:27.899 --> 01:09:30.540 align:middle line:84% That'll be really, really helpful. 01:09:30.540 --> 01:09:32.210 align:middle line:90% So with that, let me just-- 01:09:32.210 --> 01:09:38.270 align:middle line:84% I want to reflect a couple minutes on this journey 01:09:38.270 --> 01:09:41.270 align:middle line:90% and where we are and how. 01:09:41.270 --> 01:09:45.140 align:middle line:84% So if you remember, we started by saying, look, 01:09:45.140 --> 01:09:48.680 align:middle line:84% proofs has been something that mathematicians 01:09:48.680 --> 01:09:51.590 align:middle line:84% have been working with and thinking 01:09:51.590 --> 01:09:53.520 align:middle line:90% about for thousands of years. 01:09:53.520 --> 01:09:57.680 align:middle line:84% And proofs have always been very specific form 01:09:57.680 --> 01:09:59.730 align:middle line:90% of logical deductions. 01:09:59.730 --> 01:10:03.530 align:middle line:90% And cryptography changed this. 01:10:03.530 --> 01:10:06.350 align:middle line:84% With the introduction, with the thinking 01:10:06.350 --> 01:10:08.600 align:middle line:84% about zero-knowledge proofs, they 01:10:08.600 --> 01:10:10.970 align:middle line:84% defined this notion of interactive proof, a new proof 01:10:10.970 --> 01:10:12.080 align:middle line:90% model. 01:10:12.080 --> 01:10:15.920 align:middle line:84% And this new way of thinking about proofs 01:10:15.920 --> 01:10:20.410 align:middle line:84% was a huge, huge success story for cryptography, 01:10:20.410 --> 01:10:23.100 align:middle line:90% for complexity. 01:10:23.100 --> 01:10:29.490 align:middle line:84% And we noticed that these interactive proof systems turned 01:10:29.490 --> 01:10:31.120 align:middle line:90% out to be very, very powerful. 01:10:31.120 --> 01:10:35.040 align:middle line:84% And the main work that demonstrated that 01:10:35.040 --> 01:10:38.380 align:middle line:90% was the subject protocol. 01:10:38.380 --> 01:10:40.740 align:middle line:84% That was the first protocol that, wow, you 01:10:40.740 --> 01:10:44.590 align:middle line:84% can do something that we have no idea how to do classically. 01:10:44.590 --> 01:10:48.550 align:middle line:84% And that gave birth to the IP equals p space theorem. 01:10:48.550 --> 01:10:54.810 align:middle line:84% Once you had the sum-check from that with a little more work, 01:10:54.810 --> 01:10:59.170 align:middle line:84% you can do the IP equals p space theorem. 01:10:59.170 --> 01:11:00.810 align:middle line:84% And what we showed in this class is, 01:11:00.810 --> 01:11:03.910 align:middle line:90% actually, we went through GKR. 01:11:03.910 --> 01:11:08.050 align:middle line:84% So we showed that if you have sum-check, 01:11:08.050 --> 01:11:13.350 align:middle line:84% you can get actually-- just by a very simple idea of doing 01:11:13.350 --> 01:11:17.170 align:middle line:84% SNARG with a sum-check layer by layer, 01:11:17.170 --> 01:11:21.570 align:middle line:84% you can get a succinct, interactive proof 01:11:21.570 --> 01:11:23.490 align:middle line:84% for any bounded depth computation 01:11:23.490 --> 01:11:24.580 align:middle line:90% that's doubly efficient. 01:11:24.580 --> 01:11:26.760 align:middle line:84% So the prover is efficient, and the verifier 01:11:26.760 --> 01:11:30.240 align:middle line:90% is succinct or very efficient. 01:11:30.240 --> 01:11:34.170 align:middle line:84% And then we shoe the IP equals p space as a corollary. 01:11:34.170 --> 01:11:36.660 align:middle line:84% We showed that you can get PCP from it. 01:11:36.660 --> 01:11:39.780 align:middle line:84% And then we move to arguments, said, well, OK, that's 01:11:39.780 --> 01:11:43.030 align:middle line:84% where we are with proofs with statistical soundness. 01:11:43.030 --> 01:11:45.900 align:middle line:84% And then we said, well, if you're willing to rely, 01:11:45.900 --> 01:11:50.047 align:middle line:84% to reduce soundness to computational soundness, 01:11:50.047 --> 01:11:52.380 align:middle line:84% then we show that Kilian-Micali, you can get everything, 01:11:52.380 --> 01:11:57.720 align:middle line:84% like, really efficient interactive arguments by taking 01:11:57.720 --> 01:12:01.140 align:middle line:90% PCP and hashing them down. 01:12:01.140 --> 01:12:02.733 align:middle line:84% And then there was a question, OK, 01:12:02.733 --> 01:12:04.150 align:middle line:84% we can have interactive arguments. 01:12:04.150 --> 01:12:06.060 align:middle line:90% Can we have SNARGs? 01:12:06.060 --> 01:12:07.900 align:middle line:90% Can we eliminate interaction? 01:12:07.900 --> 01:12:10.813 align:middle line:84% And then we talked about Fiat-Shamir, 01:12:10.813 --> 01:12:12.480 align:middle line:84% went through zero-knowledge a little bit 01:12:12.480 --> 01:12:14.438 align:middle line:84% because that's the first time where Fiat-Shamir 01:12:14.438 --> 01:12:19.660 align:middle line:84% proved security of it, was in the context of zero-knowledge. 01:12:19.660 --> 01:12:21.220 align:middle line:90% But then we showed-- 01:12:21.220 --> 01:12:24.970 align:middle line:84% or Zhengzhong showed that actually you can do Fiat-Shamir 01:12:24.970 --> 01:12:26.810 align:middle line:90% also in the context of BARGs. 01:12:26.810 --> 01:12:32.142 align:middle line:84% So we have an interactive batch argument and you can-- 01:12:32.142 --> 01:12:34.600 align:middle line:84% or he constructed interactive batch argument showed you can 01:12:34.600 --> 01:12:35.170 align:middle line:90% use-- 01:12:35.170 --> 01:12:35.747 align:middle line:90% I don't know. 01:12:35.747 --> 01:12:36.830 align:middle line:90% He didn't get into detail. 01:12:36.830 --> 01:12:41.410 align:middle line:84% But it turns out, you can use similar techniques to show 01:12:41.410 --> 01:12:42.730 align:middle line:90% Fiat-Shamir is secure-- 01:12:42.730 --> 01:12:46.210 align:middle line:84% or these techniques, plus, plus show 01:12:46.210 --> 01:12:49.000 align:middle line:84% that Fiat-Shamir secure when applied to the interactive batch 01:12:49.000 --> 01:12:49.520 align:middle line:90% argument. 01:12:49.520 --> 01:12:53.440 align:middle line:84% And then you get this noninteractive BARG. 01:12:53.440 --> 01:12:56.810 align:middle line:84% And today, to close this entire journey, 01:12:56.810 --> 01:13:00.590 align:middle line:84% we showed how to get SNARGs from these BARGs. 01:13:00.590 --> 01:13:03.710 align:middle line:84% And as I said, we have it for deterministic computation. 01:13:03.710 --> 01:13:07.400 align:middle line:84% We have it for some nondeterministic computation. 01:13:07.400 --> 01:13:11.680 align:middle line:84% Constructing it for all of NP is still a major open question. 01:13:11.680 --> 01:13:15.530 align:middle line:84% So I invite you all to work on it with me. 01:13:15.530 --> 01:13:18.610 align:middle line:84% But I want to say one more thing about this area, which 01:13:18.610 --> 01:13:21.550 align:middle line:84% is, it's really nice because this is one example where 01:13:21.550 --> 01:13:24.800 align:middle line:84% this area has a beautiful, beautiful math, in my opinion. 01:13:24.800 --> 01:13:28.510 align:middle line:84% So it's very theoretical with beautiful mathematical ideas 01:13:28.510 --> 01:13:31.100 align:middle line:90% and applied. 01:13:31.100 --> 01:13:35.830 align:middle line:84% So this area has been a really nice bonding 01:13:35.830 --> 01:13:38.780 align:middle line:84% between theoreticians and practitioners. 01:13:38.780 --> 01:13:42.500 align:middle line:84% These things are used in particular by a lot of bankers. 01:13:42.500 --> 01:13:45.490 align:middle line:84% And people start using blockchains, and now 01:13:45.490 --> 01:13:47.750 align:middle line:84% bank systems and so on are interested in it. 01:13:47.750 --> 01:13:52.240 align:middle line:84% So it's been a really nice example 01:13:52.240 --> 01:13:57.700 align:middle line:84% where really beautiful theory is used, like, the theory itself 01:13:57.700 --> 01:13:59.690 align:middle line:90% is really deployed and used. 01:13:59.690 --> 01:14:04.270 align:middle line:84% So I think this is an example of success story 01:14:04.270 --> 01:14:06.490 align:middle line:90% for theoretical cryptography. 01:14:06.490 --> 01:14:07.150 align:middle line:90% OK. 01:14:07.150 --> 01:14:07.970 align:middle line:90% Thank you, guys. 01:14:07.970 --> 01:14:09.595 align:middle line:84% It was really, really fun teaching you. 01:14:09.595 --> 01:14:10.840 align:middle line:90% Thank you. 01:14:10.840 --> 01:14:13.590 align:middle line:90% [APPLAUSE] 01:14:13.590 --> 01:14:15.000 align:middle line:90%