WEBVTT 00:00:00.000 --> 00:00:02.420 align:middle line:90% [SQUEAKING] 00:00:02.420 --> 00:00:04.356 align:middle line:90% [RUSTLING] 00:00:04.356 --> 00:00:06.292 align:middle line:90% [CLICKING] 00:00:06.292 --> 00:00:13.380 align:middle line:90% 00:00:13.380 --> 00:00:15.060 align:middle line:84% PROFESSOR: So our last class, which 00:00:15.060 --> 00:00:17.140 align:middle line:84% is happy, because we get to go on break, 00:00:17.140 --> 00:00:20.320 align:middle line:84% but there's so much more I want to tell you guys. 00:00:20.320 --> 00:00:23.070 align:middle line:90% But that's all we have time for. 00:00:23.070 --> 00:00:26.020 align:middle line:84% There are cookies here to make our last class sweet. 00:00:26.020 --> 00:00:28.270 align:middle line:84% So please come and get some if you want. 00:00:28.270 --> 00:00:29.410 align:middle line:90% They're very small. 00:00:29.410 --> 00:00:30.633 align:middle line:90% So you can take two. 00:00:30.633 --> 00:00:33.722 align:middle line:90% 00:00:33.722 --> 00:00:35.680 align:middle line:84% If you didn't want to commit to a large cookie, 00:00:35.680 --> 00:00:36.430 align:middle line:90% you don't need to. 00:00:36.430 --> 00:00:39.760 align:middle line:90% 00:00:39.760 --> 00:00:43.620 align:middle line:84% So today, finally, we're going to actually construct the SNARGs 00:00:43.620 --> 00:00:45.220 align:middle line:90% that we've been after. 00:00:45.220 --> 00:00:50.610 align:middle line:84% That was kind of the goal is to construct SNARGs, Succinct 00:00:50.610 --> 00:00:54.180 align:middle line:84% Non-Interactive Arguments, and like this entire course 00:00:54.180 --> 00:00:57.165 align:middle line:84% was a buildup to construct these SNARGs. 00:00:57.165 --> 00:00:59.290 align:middle line:84% And today we're going to see how to construct them. 00:00:59.290 --> 00:01:02.010 align:middle line:90% There are cookies, guys-- 00:01:02.010 --> 00:01:05.080 align:middle line:84% cookies, if you want, from flour-- really good ones. 00:01:05.080 --> 00:01:08.500 align:middle line:90% So feel free to take some. 00:01:08.500 --> 00:01:10.740 align:middle line:84% So what we're going to do today is show 00:01:10.740 --> 00:01:12.420 align:middle line:90% how to construct these SNARGs. 00:01:12.420 --> 00:01:14.770 align:middle line:90% And we're going to-- 00:01:14.770 --> 00:01:18.240 align:middle line:84% last class, Zhengzhong showed you 00:01:18.240 --> 00:01:22.410 align:middle line:84% his really beautiful work and constructing BARGs, 00:01:22.410 --> 00:01:24.600 align:middle line:90% which are Batch Argument. 00:01:24.600 --> 00:01:29.160 align:middle line:84% And on their own, you can say, why do we 00:01:29.160 --> 00:01:30.340 align:middle line:90% care about batch argument? 00:01:30.340 --> 00:01:31.920 align:middle line:84% I'm going to recall the definition. 00:01:31.920 --> 00:01:34.720 align:middle line:84% But I mean, it's interesting on its own. 00:01:34.720 --> 00:01:36.600 align:middle line:84% But what makes it super interesting 00:01:36.600 --> 00:01:40.320 align:middle line:84% is that we can use it in a pretty straightforward manner 00:01:40.320 --> 00:01:41.820 align:middle line:90% to construct SNARGs. 00:01:41.820 --> 00:01:43.870 align:middle line:84% So that's what we're going to see today. 00:01:43.870 --> 00:01:46.958 align:middle line:84% We're going to see how to use these BARGs, that I'm 00:01:46.958 --> 00:01:48.750 align:middle line:84% going to recall the definition in a second, 00:01:48.750 --> 00:01:50.580 align:middle line:90% and also how to use-- 00:01:50.580 --> 00:01:54.810 align:middle line:84% I think Zhengzhong called it somewhere statistically binding 00:01:54.810 --> 00:01:55.660 align:middle line:90% hash functions. 00:01:55.660 --> 00:01:57.930 align:middle line:84% It's also known in the literature as somewhere 00:01:57.930 --> 00:01:59.320 align:middle line:90% extractable hash functions. 00:01:59.320 --> 00:02:00.070 align:middle line:90% Both are used. 00:02:00.070 --> 00:02:01.528 align:middle line:84% So I'm just going to use the other, 00:02:01.528 --> 00:02:08.650 align:middle line:84% just so you're familiar with both formulations, both names. 00:02:08.650 --> 00:02:10.479 align:middle line:84% So what we're going to see today is 00:02:10.479 --> 00:02:13.750 align:middle line:84% how to use these BARGs with these hash functions 00:02:13.750 --> 00:02:15.490 align:middle line:90% to get SNARGs. 00:02:15.490 --> 00:02:18.580 align:middle line:84% That's kind of the plan for today. 00:02:18.580 --> 00:02:22.700 align:middle line:84% So let me first recall what a BARG is really fast. 00:02:22.700 --> 00:02:28.390 align:middle line:84% So a BARG, you want to prove that many instances belong 00:02:28.390 --> 00:02:29.510 align:middle line:90% to an NP language. 00:02:29.510 --> 00:02:33.520 align:middle line:84% So a BARG for an NP language L consists of three algorithms. 00:02:33.520 --> 00:02:38.980 align:middle line:84% Gen takes as input a security parameter, the number 00:02:38.980 --> 00:02:41.350 align:middle line:90% of instances you want to batch. 00:02:41.350 --> 00:02:42.800 align:middle line:90% Maybe I'll close-- thank you. 00:02:42.800 --> 00:02:43.460 align:middle line:90% Can you close the door? 00:02:43.460 --> 00:02:43.960 align:middle line:90% Thanks. 00:02:43.960 --> 00:02:46.410 align:middle line:90% 00:02:46.410 --> 00:02:49.200 align:middle line:84% k, which is the number of instances you want to batch, 00:02:49.200 --> 00:02:52.200 align:middle line:84% and n, which is the length of each instance. 00:02:52.200 --> 00:02:56.250 align:middle line:90% And then output some CRS. 00:02:56.250 --> 00:02:58.790 align:middle line:90% 00:02:58.790 --> 00:03:01.850 align:middle line:84% Note lambda is given in unary because we want them 00:03:01.850 --> 00:03:04.070 align:middle line:90% to run in time poly lambda. 00:03:04.070 --> 00:03:05.897 align:middle line:90% But k and n are given in binary. 00:03:05.897 --> 00:03:07.730 align:middle line:84% So because it's a polynomial time algorithm, 00:03:07.730 --> 00:03:12.680 align:middle line:84% it runs in time polylog in k and polylog in n, the instant size. 00:03:12.680 --> 00:03:19.640 align:middle line:84% And then the prover algorithm takes as input the CRS, 00:03:19.640 --> 00:03:23.550 align:middle line:90% and then x1 up to xn-- xk-- 00:03:23.550 --> 00:03:24.170 align:middle line:90% sorry. 00:03:24.170 --> 00:03:35.570 align:middle line:84% So k elements with witnesses and outputs, a proof pi-- 00:03:35.570 --> 00:03:39.120 align:middle line:84% but importantly, this proof should be small. 00:03:39.120 --> 00:03:47.100 align:middle line:90% So this pi is of size poly log-- 00:03:47.100 --> 00:03:52.110 align:middle line:84% or poly n security parameter, but log k. 00:03:52.110 --> 00:03:54.410 align:middle line:90% That's important. 00:03:54.410 --> 00:03:58.340 align:middle line:84% We want it to depend only polylogarithmically on k. 00:03:58.340 --> 00:03:59.730 align:middle line:90% That's kind of our goal. 00:03:59.730 --> 00:04:02.820 align:middle line:84% And then, maybe ideally, also log n. 00:04:02.820 --> 00:04:05.100 align:middle line:84% But the point is we want it to be succinct. 00:04:05.100 --> 00:04:06.380 align:middle line:90% Otherwise, it's trivial. 00:04:06.380 --> 00:04:07.910 align:middle line:90% You just output the witnesses. 00:04:07.910 --> 00:04:14.420 align:middle line:84% And the verifier takes as input CRS, the instances, 00:04:14.420 --> 00:04:15.860 align:middle line:90% and the proof. 00:04:15.860 --> 00:04:17.289 align:middle line:90% And it outputs 0, 1-- 00:04:17.289 --> 00:04:20.610 align:middle line:90% 00:04:20.610 --> 00:04:22.320 align:middle line:90% accept or reject. 00:04:22.320 --> 00:04:27.420 align:middle line:84% And this, when I say the size of the proof is this, actually, 00:04:27.420 --> 00:04:28.960 align:middle line:84% you can make it bigger or smaller, 00:04:28.960 --> 00:04:31.590 align:middle line:90% but we want it to be succinct. 00:04:31.590 --> 00:04:33.060 align:middle line:90% Sorry. 00:04:33.060 --> 00:04:33.630 align:middle line:90% Sorry. 00:04:33.630 --> 00:04:38.280 align:middle line:84% I didn't-- we want it to depend only logarithmically in k 00:04:38.280 --> 00:04:46.990 align:middle line:84% and so on, but we allow it to depend polynomially in one 00:04:46.990 --> 00:04:48.270 align:middle line:90% witness. 00:04:48.270 --> 00:04:53.597 align:middle line:84% So I can put it here, a single witness, one, not many. 00:04:53.597 --> 00:04:55.430 align:middle line:84% I really want to be as succinct as possible, 00:04:55.430 --> 00:04:58.960 align:middle line:84% but what we can get is a BARG that depends-- 00:04:58.960 --> 00:05:03.430 align:middle line:84% grows with one instance, one witness, as opposed to k 00:05:03.430 --> 00:05:06.560 align:middle line:90% instances. 00:05:06.560 --> 00:05:09.600 align:middle line:84% So this is kind of the algorithms, 00:05:09.600 --> 00:05:12.270 align:middle line:84% then we want completeness and soundness. 00:05:12.270 --> 00:05:13.970 align:middle line:84% Completeness is the usual thing that 00:05:13.970 --> 00:05:17.030 align:middle line:84% just says, if P has valid witnesses 00:05:17.030 --> 00:05:20.630 align:middle line:84% and it generates a BARG, this BARG 00:05:20.630 --> 00:05:24.770 align:middle line:84% is going to be accepting with probability 1 over the CRS 00:05:24.770 --> 00:05:25.560 align:middle line:90% generation. 00:05:25.560 --> 00:05:27.420 align:middle line:84% So that's the standard completeness. 00:05:27.420 --> 00:05:32.910 align:middle line:84% And then the soundness property that we have, 00:05:32.910 --> 00:05:36.140 align:middle line:84% ideally, you would want to say that-- 00:05:36.140 --> 00:05:38.550 align:middle line:84% so in soundness, computational soundness, 00:05:38.550 --> 00:05:41.870 align:middle line:84% we have adaptive soundness and non-adaptive soundness. 00:05:41.870 --> 00:05:45.530 align:middle line:84% And we want to say that a cheating prover cannot convince 00:05:45.530 --> 00:05:47.340 align:middle line:90% you of a false statement. 00:05:47.340 --> 00:05:51.620 align:middle line:84% So he cannot generate-- he cannot give you x's that are not 00:05:51.620 --> 00:05:54.320 align:middle line:84% all in the language with a valid proof. 00:05:54.320 --> 00:05:56.270 align:middle line:90% That's soundness. 00:05:56.270 --> 00:05:57.440 align:middle line:90% There's an issue with it. 00:05:57.440 --> 00:06:00.900 align:middle line:84% When does the cheating prover get to choose these x's? 00:06:00.900 --> 00:06:05.550 align:middle line:84% Is it before he sees the CRS or after he sees the CRS? 00:06:05.550 --> 00:06:08.950 align:middle line:84% If he needs to decide that before he sees the CRS, 00:06:08.950 --> 00:06:10.240 align:middle line:90% then it's not adaptive. 00:06:10.240 --> 00:06:13.250 align:middle line:84% If you get to decide it after, then it's adaptive. 00:06:13.250 --> 00:06:19.790 align:middle line:84% Ideally, we want to say it's a cure for all very-- 00:06:19.790 --> 00:06:22.320 align:middle line:84% as big class provers as possible. 00:06:22.320 --> 00:06:24.980 align:middle line:84% And thus we would like to have something against adaptive 00:06:24.980 --> 00:06:29.150 align:middle line:84% provers to say, even if a cheating prover chooses this x1 00:06:29.150 --> 00:06:32.570 align:middle line:84% of xk, adaptively, after seeing the CRS, 00:06:32.570 --> 00:06:35.990 align:middle line:84% if one of them is false, he cannot generate a proof. 00:06:35.990 --> 00:06:38.500 align:middle line:84% That's what we would like to say. 00:06:38.500 --> 00:06:42.540 align:middle line:84% What we can say is what's called a semi-adaptive, something 00:06:42.540 --> 00:06:43.600 align:middle line:90% in between. 00:06:43.600 --> 00:06:45.430 align:middle line:90% So let me just write it here. 00:06:45.430 --> 00:06:58.500 align:middle line:84% So semi-adaptive soundness just says the adversary needs to tell 00:06:58.500 --> 00:07:00.480 align:middle line:90% you which-- 00:07:00.480 --> 00:07:03.180 align:middle line:84% so he's going to give you k instances. 00:07:03.180 --> 00:07:06.180 align:middle line:84% He can choose them adaptively, but he 00:07:06.180 --> 00:07:08.790 align:middle line:84% needs to choose the i on which he's going to cheat. 00:07:08.790 --> 00:07:10.230 align:middle line:90% So he's a cheater. 00:07:10.230 --> 00:07:13.450 align:middle line:84% So one of the xi's is not in the language. 00:07:13.450 --> 00:07:16.300 align:middle line:84% Which i, which location i, the xi, 00:07:16.300 --> 00:07:17.770 align:middle line:84% is going to be not in the language? 00:07:17.770 --> 00:07:20.780 align:middle line:84% That should not depend on the CRS. 00:07:20.780 --> 00:07:29.030 align:middle line:84% So it says that for any poly size P star 00:07:29.030 --> 00:07:33.180 align:middle line:84% and for every i, which, of course, may depend 00:07:33.180 --> 00:07:36.620 align:middle line:84% on lambda, because for any lambda 00:07:36.620 --> 00:07:39.290 align:middle line:84% you have an i, because the i is between 1 and k. 00:07:39.290 --> 00:07:41.610 align:middle line:90% And k grows with-- 00:07:41.610 --> 00:07:42.750 align:middle line:90% can grow with lambda. 00:07:42.750 --> 00:07:46.190 align:middle line:84% So for any i, you want to say the probability 00:07:46.190 --> 00:07:55.720 align:middle line:84% that P star, given the CRS output x1 up to xk and pi, 00:07:55.720 --> 00:08:01.870 align:middle line:84% such that xi is not in the language and pi is accepted 00:08:01.870 --> 00:08:03.340 align:middle line:90% is negligible. 00:08:03.340 --> 00:08:07.240 align:middle line:84% So xi, one of them is-- the xi one is not in the language. 00:08:07.240 --> 00:08:10.770 align:middle line:84% And the i was chosen before he saw the CRS. 00:08:10.770 --> 00:08:14.050 align:middle line:84% So for any P star, he tells you, I'm 00:08:14.050 --> 00:08:17.150 align:middle line:90% going to cheat on location i. 00:08:17.150 --> 00:08:19.280 align:middle line:90% Now, he's given a CRS. 00:08:19.280 --> 00:08:21.200 align:middle line:84% The probability that he gives you 00:08:21.200 --> 00:08:25.370 align:middle line:84% an accepting proof for x1 of xk that he chose adaptively 00:08:25.370 --> 00:08:28.400 align:middle line:84% after seeing the CRS, the probability that it's 00:08:28.400 --> 00:08:34.885 align:middle line:84% accepting-- so CRS x1 up to xk and pi is 1. 00:08:34.885 --> 00:08:39.970 align:middle line:90% 00:08:39.970 --> 00:08:42.220 align:middle line:90% And x is not in the language. 00:08:42.220 --> 00:08:45.860 align:middle line:90% xi is negligible. 00:08:45.860 --> 00:08:48.990 align:middle line:90% This equals a negligible. 00:08:48.990 --> 00:08:52.430 align:middle line:90% 00:08:52.430 --> 00:08:56.990 align:middle line:84% So again, for any cheating prover, he needs ahead of time, 00:08:56.990 --> 00:09:00.900 align:middle line:84% I'm going to choose my xi and xk adaptively after I see the CRS. 00:09:00.900 --> 00:09:04.062 align:middle line:84% But I'm going to cheat on location i. 00:09:04.062 --> 00:09:06.740 align:middle line:84% The probability that he succeeds in cheating 00:09:06.740 --> 00:09:12.530 align:middle line:84% in location i in the accepting way is negligible. 00:09:12.530 --> 00:09:16.220 align:middle line:84% That's the semi-adaptive soundness. 00:09:16.220 --> 00:09:21.170 align:middle line:84% And last class, Zhengzhong kind of 00:09:21.170 --> 00:09:23.300 align:middle line:84% showed you the high level of how you 00:09:23.300 --> 00:09:28.580 align:middle line:84% construct such a-- like the construction of such a BARG. 00:09:28.580 --> 00:09:29.180 align:middle line:90% Any questions? 00:09:29.180 --> 00:09:29.890 align:middle line:90% Yes. 00:09:29.890 --> 00:09:31.540 align:middle line:90% AUDIENCE: Is this required? 00:09:31.540 --> 00:09:33.370 align:middle line:84% The indices other than i, are those 00:09:33.370 --> 00:09:35.882 align:middle line:90% required to be in the language? 00:09:35.882 --> 00:09:37.090 align:middle line:90% PROFESSOR: No, we don't care. 00:09:37.090 --> 00:09:38.420 align:middle line:90% So yeah, good question. 00:09:38.420 --> 00:09:41.693 align:middle line:84% So the P star can choose the rest of the x's however 00:09:41.693 --> 00:09:44.110 align:middle line:84% he wants-- in the language, outside the language-- however 00:09:44.110 --> 00:09:46.210 align:middle line:90% he wants. 00:09:46.210 --> 00:09:50.250 align:middle line:84% But he wins if the xi is not in the language 00:09:50.250 --> 00:09:52.340 align:middle line:90% and the pi is accepting. 00:09:52.340 --> 00:09:54.180 align:middle line:84% And he wins with negligible probability. 00:09:54.180 --> 00:09:55.227 align:middle line:90% Yes. 00:09:55.227 --> 00:09:57.380 align:middle line:84% AUDIENCE: Does the-- transforming it 00:09:57.380 --> 00:10:01.490 align:middle line:84% into fully adaptive, would it imply guessing? 00:10:01.490 --> 00:10:03.710 align:middle line:90% PROFESSOR: Yeah. 00:10:03.710 --> 00:10:05.040 align:middle line:90% OK, good. 00:10:05.040 --> 00:10:09.260 align:middle line:84% So the question is, can we transform this 00:10:09.260 --> 00:10:12.360 align:middle line:90% into a fully adaptive SNARG? 00:10:12.360 --> 00:10:21.570 align:middle line:84% So converting it into a fully adaptive SNARG is non-trivial. 00:10:21.570 --> 00:10:24.000 align:middle line:90% And I'll tell you why. 00:10:24.000 --> 00:10:25.190 align:middle line:90% You can guess i. 00:10:25.190 --> 00:10:26.660 align:middle line:90% You can guess i. 00:10:26.660 --> 00:10:31.550 align:middle line:84% And you'll guess it correctly with probability 1/k in general. 00:10:31.550 --> 00:10:34.470 align:middle line:90% But here is-- so you can do it. 00:10:34.470 --> 00:10:35.970 align:middle line:90% But here is the issue. 00:10:35.970 --> 00:10:40.400 align:middle line:84% I'll tell you what the complication is. 00:10:40.400 --> 00:10:42.260 align:middle line:84% In the analysis-- so I don't want 00:10:42.260 --> 00:10:44.550 align:middle line:84% to recall too much of the construction, 00:10:44.550 --> 00:10:48.110 align:middle line:84% but the high level idea of how these BARGs are analyzed, even 00:10:48.110 --> 00:10:50.180 align:middle line:84% without knowing the construction, 00:10:50.180 --> 00:10:54.500 align:middle line:84% the way they're analyzed-- in the CRS, so in the proof, 00:10:54.500 --> 00:10:57.380 align:middle line:84% in the analysis, we say, suppose there exists some cheating 00:10:57.380 --> 00:11:01.370 align:middle line:90% prover that cheats on some i. 00:11:01.370 --> 00:11:05.347 align:middle line:84% In the CRS, I'm going to change the CRS now. 00:11:05.347 --> 00:11:07.680 align:middle line:84% I'm going to tell the cheating prover, here's a new CRS. 00:11:07.680 --> 00:11:11.610 align:middle line:84% And in this new CRS, I'm going to hard wire i. 00:11:11.610 --> 00:11:13.350 align:middle line:84% I'm going to put some information about i 00:11:13.350 --> 00:11:15.650 align:middle line:90% in a way that's unnoticeable. 00:11:15.650 --> 00:11:18.230 align:middle line:84% And when we'll see, I'm going to call the somewhere 00:11:18.230 --> 00:11:20.330 align:middle line:84% extractable hash, or what Zhengzhong 00:11:20.330 --> 00:11:23.460 align:middle line:84% called SSB hash, somewhere statistically binding. 00:11:23.460 --> 00:11:26.000 align:middle line:84% And then I'll remind you a little bit how we-- 00:11:26.000 --> 00:11:28.730 align:middle line:90% where we stick the index i. 00:11:28.730 --> 00:11:31.310 align:middle line:84% But in the analysis, we say, let me change 00:11:31.310 --> 00:11:33.618 align:middle line:90% the CRS to a different CRS. 00:11:33.618 --> 00:11:35.160 align:middle line:84% It has a very different distribution, 00:11:35.160 --> 00:11:36.300 align:middle line:90% but it's indistinguishable. 00:11:36.300 --> 00:11:38.330 align:middle line:90% It looks like the original CRS. 00:11:38.330 --> 00:11:41.090 align:middle line:84% So P star can't distinguish between the two. 00:11:41.090 --> 00:11:44.330 align:middle line:84% So he'll still give me a valid BARG. 00:11:44.330 --> 00:11:48.200 align:middle line:84% And now I'm going to say, in this new CRS, 00:11:48.200 --> 00:11:50.390 align:middle line:84% actually, there's no way he can cheat on location i. 00:11:50.390 --> 00:11:51.980 align:middle line:90% There's no way he can cheat. 00:11:51.980 --> 00:11:53.520 align:middle line:90% What is the issue? 00:11:53.520 --> 00:11:55.370 align:middle line:84% So now you're saying, why do we need-- 00:11:55.370 --> 00:11:57.830 align:middle line:90% why can't we do fully adaptive? 00:11:57.830 --> 00:12:03.720 align:middle line:84% The issue is it may be the case that once we switch the CRS, 00:12:03.720 --> 00:12:05.490 align:middle line:90% it switches where he's cheating. 00:12:05.490 --> 00:12:07.700 align:middle line:90% So here's an alternative way. 00:12:07.700 --> 00:12:09.745 align:middle line:84% Let's say the prover tells you, you know what? 00:12:09.745 --> 00:12:11.120 align:middle line:84% I'm going to cheat in location i. 00:12:11.120 --> 00:12:14.840 align:middle line:84% But I can be adaptive-- chosen based on the CRS. 00:12:14.840 --> 00:12:16.620 align:middle line:84% So now in the analysis, I'm going to say-- 00:12:16.620 --> 00:12:18.120 align:middle line:84% I'm going to guess where he cheated. 00:12:18.120 --> 00:12:20.570 align:middle line:84% I'm going to say, let's guess he cheated in location 7. 00:12:20.570 --> 00:12:22.580 align:middle line:84% I'm going to hardwire kind of the CRS 00:12:22.580 --> 00:12:24.600 align:middle line:90% to depend on this location. 00:12:24.600 --> 00:12:27.680 align:middle line:84% And then the cheating prover doesn't cheat on 7. 00:12:27.680 --> 00:12:29.330 align:middle line:90% It cheats on something else. 00:12:29.330 --> 00:12:31.160 align:middle line:90% He can kind of evade me. 00:12:31.160 --> 00:12:34.260 align:middle line:84% Now, you're saying, oh, if he cheated on something else, 00:12:34.260 --> 00:12:35.370 align:middle line:90% I can tell the difference. 00:12:35.370 --> 00:12:37.500 align:middle line:90% So I shouldn't be able to tell. 00:12:37.500 --> 00:12:40.580 align:middle line:84% But the thing is you don't know what's in the language, what's 00:12:40.580 --> 00:12:41.700 align:middle line:90% not in the language. 00:12:41.700 --> 00:12:45.050 align:middle line:84% So the problem is whether xi is in the language 00:12:45.050 --> 00:12:48.170 align:middle line:84% or not in the language can be very hard to tell. 00:12:48.170 --> 00:12:53.860 align:middle line:84% It may take-- and that's why kind of getting adaptive-- 00:12:53.860 --> 00:13:00.720 align:middle line:84% just guessing is not good enough, because he needs to-- 00:13:00.720 --> 00:13:03.240 align:middle line:84% the issue is if you could tell efficiently 00:13:03.240 --> 00:13:07.090 align:middle line:84% whether x is in the language or not in the language, then, yes. 00:13:07.090 --> 00:13:10.920 align:middle line:84% But because it can be very hard, that's 00:13:10.920 --> 00:13:12.570 align:middle line:90% where things become tricky. 00:13:12.570 --> 00:13:18.330 align:middle line:84% So that's-- so you can guess, but it's not good enough is 00:13:18.330 --> 00:13:19.115 align:middle line:90% the answer. 00:13:19.115 --> 00:13:23.310 align:middle line:90% 00:13:23.310 --> 00:13:23.810 align:middle line:90% Yeah. 00:13:23.810 --> 00:13:25.060 align:middle line:90% AUDIENCE: Even if he commits-- 00:13:25.060 --> 00:13:25.810 align:middle line:90% PROFESSOR: Huh? 00:13:25.810 --> 00:13:31.600 align:middle line:84% AUDIENCE: Even if he commits to doing it, [INAUDIBLE]? 00:13:31.600 --> 00:13:34.930 align:middle line:84% PROFESSOR: Well, he can-- what do you mean he commits? 00:13:34.930 --> 00:13:37.360 align:middle line:84% So you're saying let's change the scheme kind of 00:13:37.360 --> 00:13:40.750 align:middle line:90% and have him add commitments? 00:13:40.750 --> 00:13:44.470 align:middle line:84% AUDIENCE: Well, I guess it might be different. 00:13:44.470 --> 00:13:47.290 align:middle line:84% PROFESSOR: I guess the issue is-- look, when he's cheating, 00:13:47.290 --> 00:13:48.660 align:middle line:90% we don't know whether-- 00:13:48.660 --> 00:13:51.750 align:middle line:84% he gives you x1 up to xk and a proof pi. 00:13:51.750 --> 00:13:54.653 align:middle line:84% Now, he cheats if one of them is not in the language. 00:13:54.653 --> 00:13:55.570 align:middle line:90% That's when he cheats. 00:13:55.570 --> 00:13:59.280 align:middle line:84% It's hard to know whether one of them is in the language 00:13:59.280 --> 00:14:00.520 align:middle line:90% or not in the language. 00:14:00.520 --> 00:14:02.282 align:middle line:90% And the concern is he can say i. 00:14:02.282 --> 00:14:03.490 align:middle line:90% He can say whatever he wants. 00:14:03.490 --> 00:14:04.323 align:middle line:90% He's going to cheat. 00:14:04.323 --> 00:14:07.510 align:middle line:90% So nothing he says we believe. 00:14:07.510 --> 00:14:10.020 align:middle line:84% And the concern is that maybe when 00:14:10.020 --> 00:14:13.590 align:middle line:84% we switch the CRS to depend on i, also 00:14:13.590 --> 00:14:16.350 align:middle line:90% the xi becomes in the language. 00:14:16.350 --> 00:14:17.370 align:middle line:90% And then what do you do? 00:14:17.370 --> 00:14:19.230 align:middle line:84% And now you can say you can't tell the difference, because xi 00:14:19.230 --> 00:14:22.080 align:middle line:84% in the language and outside the language, they look the same. 00:14:22.080 --> 00:14:27.190 align:middle line:84% So that's why guessing is, in some sense, not good enough. 00:14:27.190 --> 00:14:30.020 align:middle line:90% It's not helpful. 00:14:30.020 --> 00:14:32.480 align:middle line:84% So this is-- any other questions? 00:14:32.480 --> 00:14:35.070 align:middle line:90% 00:14:35.070 --> 00:14:36.820 align:middle line:84% So this is one ingredient that we're going 00:14:36.820 --> 00:14:38.500 align:middle line:90% to use to construct our SNARG. 00:14:38.500 --> 00:14:44.710 align:middle line:84% The other ingredient is a somewhere extractable hash, 00:14:44.710 --> 00:14:46.660 align:middle line:90% or SSB hash. 00:14:46.660 --> 00:14:47.870 align:middle line:90% So let me write it out. 00:14:47.870 --> 00:14:51.470 align:middle line:84% I'm going to write it here, so we'll keep it on the board. 00:14:51.470 --> 00:14:54.610 align:middle line:84% So let me just recall the definition. 00:14:54.610 --> 00:14:59.020 align:middle line:84% Somewhere extractable hash family 00:14:59.020 --> 00:15:04.125 align:middle line:84% consists of many several PPT algorithms. 00:15:04.125 --> 00:15:05.000 align:middle line:90% Let me start writing. 00:15:05.000 --> 00:15:12.820 align:middle line:84% So the first one is gen. So now we're constructing a hash. 00:15:12.820 --> 00:15:16.290 align:middle line:84% So gen takes a security parameter, 00:15:16.290 --> 00:15:18.820 align:middle line:84% the length, how many bits we're going to hash. 00:15:18.820 --> 00:15:21.390 align:middle line:84% So let's say n bits we're going to hash. 00:15:21.390 --> 00:15:24.880 align:middle line:84% And how many-- so let's say in the location i, 00:15:24.880 --> 00:15:26.730 align:middle line:90% this is going to be i and n. 00:15:26.730 --> 00:15:28.590 align:middle line:84% This is where we're going to be binding on, 00:15:28.590 --> 00:15:30.960 align:middle line:84% or where we want to be extractable on. 00:15:30.960 --> 00:15:37.950 align:middle line:84% And it outputs a hash key and a trapdoor. 00:15:37.950 --> 00:15:40.260 align:middle line:84% This trapdoor is going to be-- we're 00:15:40.260 --> 00:15:42.480 align:middle line:84% going to use it to extract from the hash 00:15:42.480 --> 00:15:46.300 align:middle line:84% the i-th location of what we hashed. 00:15:46.300 --> 00:15:48.120 align:middle line:84% So there's a hash key and a trapdoor. 00:15:48.120 --> 00:15:50.988 align:middle line:84% I know when Zhengzhong taught it, then he just said, hash key, 00:15:50.988 --> 00:15:52.780 align:middle line:84% and he put kind of the trapdoor at the end. 00:15:52.780 --> 00:15:55.860 align:middle line:84% So I'm going to write it with a trapdoor. 00:15:55.860 --> 00:15:58.960 align:middle line:84% So gen outputs a hash key and a trapdoor. 00:15:58.960 --> 00:16:01.510 align:middle line:84% And then you have eval algorithm. 00:16:01.510 --> 00:16:09.190 align:middle line:84% It just takes the hash key, an input x and 0, 1 to the n, 00:16:09.190 --> 00:16:13.550 align:middle line:90% and then outputs a hash value v. 00:16:13.550 --> 00:16:17.830 align:middle line:84% And then you have open, where you 00:16:17.830 --> 00:16:22.240 align:middle line:84% take a hash key, the x, and some index j 00:16:22.240 --> 00:16:25.180 align:middle line:90% that you want to open to. 00:16:25.180 --> 00:16:29.230 align:middle line:84% And it outputs an opening rho or rho J. 00:16:29.230 --> 00:16:35.210 align:middle line:84% And this should be in 0, 1 to the lambda, or poly lambda. 00:16:35.210 --> 00:16:37.180 align:middle line:84% Similarly here, this should be small-- 00:16:37.180 --> 00:16:39.870 align:middle line:84% 0, 1 to the lambda or poly lambda. 00:16:39.870 --> 00:16:45.790 align:middle line:90% 00:16:45.790 --> 00:16:48.880 align:middle line:84% And then there's ver that verifies. 00:16:48.880 --> 00:16:52.540 align:middle line:84% So ver takes a hash key, a value. 00:16:52.540 --> 00:16:54.890 align:middle line:84% And now let's say you want to say, 00:16:54.890 --> 00:16:57.710 align:middle line:90% I'm going to open location j. 00:16:57.710 --> 00:16:59.650 align:middle line:90% Here's my b that opens. 00:16:59.650 --> 00:17:02.120 align:middle line:90% And here's the opening. 00:17:02.120 --> 00:17:02.840 align:middle line:90% And he checks. 00:17:02.840 --> 00:17:04.829 align:middle line:90% Is it a valid opening or not? 00:17:04.829 --> 00:17:10.099 align:middle line:90% So it outputs 0 or 1. 00:17:10.099 --> 00:17:12.800 align:middle line:90% 00:17:12.800 --> 00:17:19.640 align:middle line:84% And finally, so it consists of five PPT algorithms. 00:17:19.640 --> 00:17:23.040 align:middle line:84% So first, you generate a hash key with a trapdoor. 00:17:23.040 --> 00:17:27.680 align:middle line:84% Then there's an eval algorithm that given an n-bit string 00:17:27.680 --> 00:17:29.600 align:middle line:90% outputs the hash value v-- 00:17:29.600 --> 00:17:31.260 align:middle line:90% short, succinct. 00:17:31.260 --> 00:17:34.560 align:middle line:84% Then there's open that you can open, 00:17:34.560 --> 00:17:40.650 align:middle line:84% given that you can generate an opening for a specific index j. 00:17:40.650 --> 00:17:43.820 align:middle line:84% So you generate row j, which is an opening, 00:17:43.820 --> 00:17:47.210 align:middle line:84% and anybody can verify the opening using 00:17:47.210 --> 00:17:49.080 align:middle line:90% only the succinct hash value. 00:17:49.080 --> 00:17:53.280 align:middle line:84% So given a hash key, the succinct hash value, the index, 00:17:53.280 --> 00:17:55.580 align:middle line:84% the bit, you can verify the opening. 00:17:55.580 --> 00:17:58.500 align:middle line:84% And finally, that's the extract algorithm. 00:17:58.500 --> 00:18:01.400 align:middle line:90% 00:18:01.400 --> 00:18:08.910 align:middle line:84% And it takes the trapdoor and the value, and it outputs a bit. 00:18:08.910 --> 00:18:14.290 align:middle line:90% And this bit should be xi. 00:18:14.290 --> 00:18:19.450 align:middle line:90% So let me say, the properties-- 00:18:19.450 --> 00:18:26.760 align:middle line:84% so the first property is completeness. 00:18:26.760 --> 00:18:34.592 align:middle line:84% That's kind of usually the straightforward property, which, 00:18:34.592 --> 00:18:36.550 align:middle line:84% essentially, says, look, if everybody's honest, 00:18:36.550 --> 00:18:39.820 align:middle line:84% you get what you expect, which means, one, 00:18:39.820 --> 00:18:41.820 align:middle line:84% the verifier would accept the opening, 00:18:41.820 --> 00:18:45.660 align:middle line:84% and b, the extract will output the i-th bit. 00:18:45.660 --> 00:18:49.030 align:middle line:84% So it says that the probability-- 00:18:49.030 --> 00:18:56.250 align:middle line:84% so for every x, for every lambda, for every n, which 00:18:56.250 --> 00:18:57.900 align:middle line:84% is at most 2 to the lambda, we always 00:18:57.900 --> 00:19:02.130 align:middle line:84% restrict the length of what we're hashing to be at most 2 00:19:02.130 --> 00:19:09.400 align:middle line:84% to the lambda, and for every i, we 00:19:09.400 --> 00:19:19.380 align:middle line:84% say that the probability that an open-- 00:19:19.380 --> 00:19:25.410 align:middle line:84% sorry-- that ver a hash key generated from gen, 00:19:25.410 --> 00:19:29.315 align:middle line:90% which is the eval, for every j. 00:19:29.315 --> 00:19:34.410 align:middle line:90% 00:19:34.410 --> 00:19:39.880 align:middle line:90% j rho generated by open. 00:19:39.880 --> 00:19:41.650 align:middle line:90% It always outputs 1. 00:19:41.650 --> 00:19:42.970 align:middle line:90% It outputs 1, probability 1. 00:19:42.970 --> 00:19:47.710 align:middle line:84% And extract-- I'll just denote by-- 00:19:47.710 --> 00:19:52.780 align:middle line:84% extract, let me denote by just x for simplicity, given trapdoor 00:19:52.780 --> 00:19:56.050 align:middle line:90% and the output xi. 00:19:56.050 --> 00:19:58.270 align:middle line:84% And this holds with probability 1, where 00:19:58.270 --> 00:20:00.040 align:middle line:90% the probability is over what? 00:20:00.040 --> 00:20:07.202 align:middle line:84% Hash key and trapdoor are in gen. So essentially-- 00:20:07.202 --> 00:20:07.910 align:middle line:90% I won't write it. 00:20:07.910 --> 00:20:11.230 align:middle line:84% But the hash key is generated by this. 00:20:11.230 --> 00:20:13.780 align:middle line:90% v is generated by this eval. 00:20:13.780 --> 00:20:16.450 align:middle line:90% Rho-- or I'll call rho j-- 00:20:16.450 --> 00:20:19.840 align:middle line:90% is generated by open. 00:20:19.840 --> 00:20:23.810 align:middle line:84% And this just says if everything was done correctly, 00:20:23.810 --> 00:20:27.280 align:middle line:84% the var always accepts, and the extract indeed 00:20:27.280 --> 00:20:29.960 align:middle line:90% will extract the correct bit. 00:20:29.960 --> 00:20:32.340 align:middle line:84% So this is just if everybody follows the protocol, 00:20:32.340 --> 00:20:36.040 align:middle line:84% everything should be as you expect. 00:20:36.040 --> 00:20:44.940 align:middle line:84% The soundness or binding, or the statistical binding, 00:20:44.940 --> 00:20:48.830 align:middle line:84% I should say, somewhere-- or I can call the FSB somewhere 00:20:48.830 --> 00:20:55.300 align:middle line:84% statistically binding condition says that on location-- 00:20:55.300 --> 00:20:59.220 align:middle line:84% Oh, before I go to FSB, there's another property, 00:20:59.220 --> 00:21:00.325 align:middle line:90% which is index hiding. 00:21:00.325 --> 00:21:04.160 align:middle line:90% 00:21:04.160 --> 00:21:10.640 align:middle line:84% Index hiding means that the hash key hides the index. 00:21:10.640 --> 00:21:15.070 align:middle line:84% If you see just hash key, you have no idea what i is. 00:21:15.070 --> 00:21:19.440 align:middle line:84% So it just says that for every i and j, 00:21:19.440 --> 00:21:23.950 align:middle line:84% if you look at hash key generated by-- 00:21:23.950 --> 00:21:30.390 align:middle line:84% I don't know-- call it i, or hash key generated by j, 00:21:30.390 --> 00:21:32.830 align:middle line:90% they're indistinguishable. 00:21:32.830 --> 00:21:37.435 align:middle line:84% This is just a notation to say hash key generated where here I 00:21:37.435 --> 00:21:38.290 align:middle line:90% have i. 00:21:38.290 --> 00:21:40.780 align:middle line:84% And this is just a notation saying 00:21:40.780 --> 00:21:47.950 align:middle line:84% this is a hash key generated by giving j to gen. So the hash 00:21:47.950 --> 00:21:53.330 align:middle line:84% key hides the index for any i and j, the hash key generated 00:21:53.330 --> 00:21:57.740 align:middle line:84% with i, the hash key generated with j, they look the same. 00:21:57.740 --> 00:21:59.540 align:middle line:90% So that's the index hiding. 00:21:59.540 --> 00:22:03.820 align:middle line:84% And finally is the binding condition. 00:22:03.820 --> 00:22:07.010 align:middle line:84% And the binding condition says that-- 00:22:07.010 --> 00:22:10.840 align:middle line:84% so the SSB, the Somewhere Statistical Binding, 00:22:10.840 --> 00:22:19.340 align:middle line:84% says that for the location i, that we're binding on, even 00:22:19.340 --> 00:22:25.560 align:middle line:84% an all powerful adversary that is given hash key cannot 00:22:25.560 --> 00:22:31.290 align:middle line:84% generate v and two different openings to location i, 00:22:31.290 --> 00:22:36.210 align:middle line:84% an opening to 0, an opening to 1 on location i. 00:22:36.210 --> 00:22:39.690 align:middle line:84% So on location i, you're really [INAUDIBLE] 00:22:39.690 --> 00:22:41.160 align:middle line:90% theoretically bounded. 00:22:41.160 --> 00:22:45.855 align:middle line:84% So again, even in an all powerful adversary that is given 00:22:45.855 --> 00:22:52.140 align:middle line:84% the hash key with respect to i, a location i cannot open both 00:22:52.140 --> 00:22:57.000 align:middle line:84% to 0 and to 1, except with negligible probability. 00:22:57.000 --> 00:23:03.490 align:middle line:84% So I hope to put everything on that, but I'll add one here. 00:23:03.490 --> 00:23:05.710 align:middle line:84% So I'll put here the binding condition, 00:23:05.710 --> 00:23:11.210 align:middle line:84% so the SSB binding, the somewhere statistically binding 00:23:11.210 --> 00:23:19.450 align:middle line:84% says that for every all powerful adversary a, 00:23:19.450 --> 00:23:28.710 align:middle line:84% the probability that a and hash key, where hash key is generated 00:23:28.710 --> 00:23:34.950 align:middle line:84% from gen 1 lambda n and i, the probability 00:23:34.950 --> 00:23:45.760 align:middle line:84% that he outputs any value v and rho 0 and rho 1 such 00:23:45.760 --> 00:23:48.430 align:middle line:84% that they would accept both, such that for every b, 00:23:48.430 --> 00:24:00.250 align:middle line:84% both 0 and 1 there on hash key vi b rho b outputs 1, 00:24:00.250 --> 00:24:01.730 align:middle line:90% this is negligible. 00:24:01.730 --> 00:24:04.510 align:middle line:90% 00:24:04.510 --> 00:24:10.090 align:middle line:84% So on index i, the one that we're-- 00:24:10.090 --> 00:24:14.440 align:middle line:84% the hash came from that we're binding on, he cannot open 00:24:14.440 --> 00:24:20.122 align:middle line:84% to both 0 and open to 1 in an accepting way with accept 00:24:20.122 --> 00:24:21.080 align:middle line:90% negligible probability. 00:24:21.080 --> 00:24:21.340 align:middle line:90% Yeah. 00:24:21.340 --> 00:24:23.440 align:middle line:84% AUDIENCE: Does v have to be generated from eval 00:24:23.440 --> 00:24:23.870 align:middle line:90% here or maybe [INAUDIBLE]? 00:24:23.870 --> 00:24:24.710 align:middle line:90% PROFESSOR: No, no. 00:24:24.710 --> 00:24:25.550 align:middle line:90% Good, good. 00:24:25.550 --> 00:24:26.260 align:middle line:90% Great question. 00:24:26.260 --> 00:24:28.540 align:middle line:90% v is malicious. 00:24:28.540 --> 00:24:32.360 align:middle line:84% There is no-- a can be-- so the adversary, 00:24:32.360 --> 00:24:34.510 align:middle line:84% he's not following any guidelines. 00:24:34.510 --> 00:24:36.310 align:middle line:90% He's completely malicious. 00:24:36.310 --> 00:24:38.740 align:middle line:84% He generates v according to his own will, 00:24:38.740 --> 00:24:42.580 align:middle line:84% generating rho 0, rho 1 however he wants. 00:24:42.580 --> 00:24:44.090 align:middle line:90% And he's all powerful. 00:24:44.090 --> 00:24:50.810 align:middle line:84% He still cannot generate two accepting openings for location 00:24:50.810 --> 00:24:52.480 align:middle line:90% i. 00:24:52.480 --> 00:24:52.980 align:middle line:90% Yeah. 00:24:52.980 --> 00:24:55.040 align:middle line:84% AUDIENCE: I'm just going to follow-up on that. 00:24:55.040 --> 00:24:57.290 align:middle line:84% That's the only reason that we don't get this for free 00:24:57.290 --> 00:24:58.490 align:middle line:90% from extraction. 00:24:58.490 --> 00:24:59.313 align:middle line:90% PROFESSOR: Exactly. 00:24:59.313 --> 00:25:00.480 align:middle line:90% Good, good, good, very good. 00:25:00.480 --> 00:25:04.340 align:middle line:84% So let me just repeat what [INAUDIBLE] said. 00:25:04.340 --> 00:25:07.170 align:middle line:84% Look, in extraction, we said that we're binding, 00:25:07.170 --> 00:25:09.750 align:middle line:84% completely binding, because guess what-- from v, 00:25:09.750 --> 00:25:11.690 align:middle line:90% we can actually-- 00:25:11.690 --> 00:25:15.980 align:middle line:84% we can actually learn the bit xi. 00:25:15.980 --> 00:25:17.780 align:middle line:90% So xi is sitting there. 00:25:17.780 --> 00:25:21.540 align:middle line:84% So yeah, if you're honest xi is sitting there. 00:25:21.540 --> 00:25:24.990 align:middle line:84% But if you're malicious, you can do whatever you want. 00:25:24.990 --> 00:25:27.230 align:middle line:84% And maybe for a malicious v, maybe there's 00:25:27.230 --> 00:25:31.450 align:middle line:84% no-- you can't extract anything from it. 00:25:31.450 --> 00:25:32.390 align:middle line:90% Yeah. 00:25:32.390 --> 00:25:34.473 align:middle line:84% AUDIENCE: Is it the same as saying the probability 00:25:34.473 --> 00:25:36.115 align:middle line:90% there exists v [INAUDIBLE]? 00:25:36.115 --> 00:25:38.672 align:middle line:90% 00:25:38.672 --> 00:25:39.380 align:middle line:90% PROFESSOR: Right. 00:25:39.380 --> 00:25:40.460 align:middle line:90% Good, good, good, very good. 00:25:40.460 --> 00:25:41.080 align:middle line:90% Yes, yes, yes. 00:25:41.080 --> 00:25:47.570 align:middle line:84% This is the same as saying that there exists a v rho 00:25:47.570 --> 00:25:49.730 align:middle line:90% 0 for any hash-- 00:25:49.730 --> 00:25:52.970 align:middle line:84% for almost all hash keys, the probability 00:25:52.970 --> 00:25:57.500 align:middle line:84% that there exists v rho 0 rho 1 is 0. 00:25:57.500 --> 00:25:58.580 align:middle line:90% So they don't exist. 00:25:58.580 --> 00:26:03.020 align:middle line:84% For almost all hash keys, this triplet that satisfies this 00:26:03.020 --> 00:26:04.020 align:middle line:90% does not exist. 00:26:04.020 --> 00:26:05.030 align:middle line:90% Yes. 00:26:05.030 --> 00:26:06.450 align:middle line:90% Yeah. 00:26:06.450 --> 00:26:08.310 align:middle line:90% Very good. 00:26:08.310 --> 00:26:11.650 align:middle line:90% Any other questions? 00:26:11.650 --> 00:26:15.150 align:middle line:84% So the plan for today is to show how to use these two building 00:26:15.150 --> 00:26:18.030 align:middle line:90% blocks to get a SNARG. 00:26:18.030 --> 00:26:22.380 align:middle line:84% But before I do that, I want to say a few more-- 00:26:22.380 --> 00:26:25.728 align:middle line:84% first, I want to give you time to digest and to ask questions. 00:26:25.728 --> 00:26:27.270 align:middle line:84% Also, I want to say a few more things 00:26:27.270 --> 00:26:28.660 align:middle line:90% about these two primitives. 00:26:28.660 --> 00:26:31.680 align:middle line:90% 00:26:31.680 --> 00:26:34.980 align:middle line:90% Any questions before I-- 00:26:34.980 --> 00:26:35.680 align:middle line:90% OK. 00:26:35.680 --> 00:26:38.610 align:middle line:84% So one thing I want to mention is 00:26:38.610 --> 00:26:42.855 align:middle line:84% even though the binding condition was only an i, 00:26:42.855 --> 00:26:47.180 align:middle line:84% I said only on this specific i, I promise you, 00:26:47.180 --> 00:26:48.920 align:middle line:84% you can't open two different ways. 00:26:48.920 --> 00:26:49.940 align:middle line:90% What about the other i? 00:26:49.940 --> 00:26:51.070 align:middle line:90% What about j? 00:26:51.070 --> 00:26:53.145 align:middle line:84% j can address to open two different ways? 00:26:53.145 --> 00:26:57.250 align:middle line:90% 00:26:57.250 --> 00:26:58.280 align:middle line:90% And the answer is no. 00:26:58.280 --> 00:26:59.072 align:middle line:90% Actually, he can't. 00:26:59.072 --> 00:27:02.290 align:middle line:84% And we don't need to state that explicitly. 00:27:02.290 --> 00:27:06.170 align:middle line:84% From the FSB and the index hiding, 00:27:06.170 --> 00:27:11.230 align:middle line:84% I want to argue already we can conclude that a poly size 00:27:11.230 --> 00:27:15.400 align:middle line:84% adversary cannot open a poly size-- not all powerful, 00:27:15.400 --> 00:27:22.420 align:middle line:84% but a poly size adversary cannot generate v any index j, 00:27:22.420 --> 00:27:25.910 align:middle line:84% and two openings that will be accepted, 00:27:25.910 --> 00:27:28.910 align:middle line:90% except non-zero probability. 00:27:28.910 --> 00:27:31.310 align:middle line:84% So in other words, I'm saying binding holds-- 00:27:31.310 --> 00:27:34.280 align:middle line:84% this local binding holds for every j. 00:27:34.280 --> 00:27:39.225 align:middle line:84% Not against all powerful, but for any PPT or poly size 00:27:39.225 --> 00:27:43.050 align:middle line:84% A, we get this binding condition for every j. 00:27:43.050 --> 00:27:45.420 align:middle line:90% 00:27:45.420 --> 00:27:45.920 align:middle line:90% Why? 00:27:45.920 --> 00:27:50.507 align:middle line:90% 00:27:50.507 --> 00:27:53.090 align:middle line:84% AUDIENCE: Is it because of the index hiding property where you 00:27:53.090 --> 00:27:56.270 align:middle line:84% cannot distinguish [INAUDIBLE] index is higher or something 00:27:56.270 --> 00:27:56.840 align:middle line:90% else then? 00:27:56.840 --> 00:27:57.715 align:middle line:90% PROFESSOR: Precisely. 00:27:57.715 --> 00:28:01.790 align:middle line:84% So the reason is this A, he doesn't know if hash key came 00:28:01.790 --> 00:28:03.980 align:middle line:90% from index i or index j. 00:28:03.980 --> 00:28:05.360 align:middle line:90% They're indistinguishable. 00:28:05.360 --> 00:28:09.920 align:middle line:84% So now if he can generate it for index j, 00:28:09.920 --> 00:28:12.600 align:middle line:84% then he should be able to generate it also for index-- 00:28:12.600 --> 00:28:14.220 align:middle line:84% so let's replace this with index j. 00:28:14.220 --> 00:28:15.240 align:middle line:90% He can't distinguish. 00:28:15.240 --> 00:28:17.550 align:middle line:84% So he'll follow the same j again at some point. 00:28:17.550 --> 00:28:19.860 align:middle line:90% And there'll be a contradiction. 00:28:19.860 --> 00:28:22.540 align:middle line:84% So because he has no idea what's sitting here, 00:28:22.540 --> 00:28:25.710 align:middle line:84% the fact that he cannot do it for that index i, 00:28:25.710 --> 00:28:28.380 align:middle line:84% even information theoretically means he can't do it for any 00:28:28.380 --> 00:28:29.970 align:middle line:90% other index. 00:28:29.970 --> 00:28:30.470 align:middle line:90% Yeah. 00:28:30.470 --> 00:28:32.120 align:middle line:84% AUDIENCE: So this index had to get really [INAUDIBLE]. 00:28:32.120 --> 00:28:33.430 align:middle line:84% PROFESSOR: No, this is [INAUDIBLE]. 00:28:33.430 --> 00:28:34.638 align:middle line:90% It's computational, actually. 00:28:34.638 --> 00:28:35.961 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:28:35.961 --> 00:28:37.370 align:middle line:90% PROFESSOR: Oh, good, good, good. 00:28:37.370 --> 00:28:44.600 align:middle line:84% So the corollary is, for any poly size, 00:28:44.600 --> 00:28:47.270 align:middle line:84% the corollary says that only any poly size 00:28:47.270 --> 00:28:52.500 align:middle line:84% A, the probability that A on hash key, 00:28:52.500 --> 00:28:59.930 align:middle line:84% let's say from i, same hash key, outputs v or v, j rho 0 and rho 00:28:59.930 --> 00:29:04.160 align:middle line:84% 1, such that the same thing here holds. 00:29:04.160 --> 00:29:06.890 align:middle line:84% Namely, for every b he generates accepting 00:29:06.890 --> 00:29:12.340 align:middle line:84% answers for both 0 and 1 is negligible. 00:29:12.340 --> 00:29:15.850 align:middle line:84% Because if there exists some j that he 00:29:15.850 --> 00:29:18.600 align:middle line:84% does that for non-negligible probability, 00:29:18.600 --> 00:29:23.250 align:middle line:84% then let's replace hk with hash key generating that's 00:29:23.250 --> 00:29:26.960 align:middle line:84% binding on this, that's actually statistically binding on this j. 00:29:26.960 --> 00:29:28.350 align:middle line:90% A can't distinguish. 00:29:28.350 --> 00:29:30.440 align:middle line:84% So we'll still do this for that j 00:29:30.440 --> 00:29:32.450 align:middle line:84% with some non-negligible probability. 00:29:32.450 --> 00:29:35.510 align:middle line:84% And that he cannot do with that information theoretically. 00:29:35.510 --> 00:29:37.880 align:middle line:90% So that's why we get, like-- 00:29:37.880 --> 00:29:40.490 align:middle line:84% because index hiding, actually, just 00:29:40.490 --> 00:29:43.730 align:middle line:84% getting statistically binding on one of them is good enough. 00:29:43.730 --> 00:29:48.280 align:middle line:84% It will imply computational binding on all the rest. 00:29:48.280 --> 00:29:50.360 align:middle line:84% Another thing I want to mention-- 00:29:50.360 --> 00:29:53.620 align:middle line:84% and this we'll use, actually, in our construction today-- 00:29:53.620 --> 00:29:59.110 align:middle line:84% I said that the hash is binding on one location, on xi. 00:29:59.110 --> 00:30:03.820 align:middle line:84% We can get it binding, actually, on l locations, not just one. 00:30:03.820 --> 00:30:07.250 align:middle line:84% How do I get it binding on l locations? 00:30:07.250 --> 00:30:11.360 align:middle line:84% I'm going to just generate hk1, hk2, up to hkl, 00:30:11.360 --> 00:30:13.400 align:middle line:84% where the first l is binding, and the first-- 00:30:13.400 --> 00:30:17.730 align:middle line:84% I'm just going to generate l hashes. 00:30:17.730 --> 00:30:21.100 align:middle line:84% I'm going to ask the-- generate the eval on all these hashes. 00:30:21.100 --> 00:30:23.610 align:middle line:84% So the hash value now is going to be v1 up 00:30:23.610 --> 00:30:27.780 align:middle line:84% to vl, where the honest eval is going 00:30:27.780 --> 00:30:30.420 align:middle line:84% to take the x you want to hash and do 00:30:30.420 --> 00:30:34.500 align:middle line:90% eval hk1 of x, eval hk2 of x. 00:30:34.500 --> 00:30:39.280 align:middle line:84% So just hash the same x with all l keys. 00:30:39.280 --> 00:30:43.620 align:middle line:84% So now the hash value grows by a factor of l. 00:30:43.620 --> 00:30:47.200 align:middle line:84% And then when you open a certain bit, a certain location, 00:30:47.200 --> 00:30:49.530 align:middle line:84% you'll generate all the openings. 00:30:49.530 --> 00:30:52.810 align:middle line:84% So just do the same thing kind of l times, 00:30:52.810 --> 00:30:54.670 align:middle line:90% just repeat it l times. 00:30:54.670 --> 00:30:56.870 align:middle line:84% And now what do we have from that? 00:30:56.870 --> 00:31:00.790 align:middle line:84% If you-- by repeating l times, so let me write it. 00:31:00.790 --> 00:31:09.990 align:middle line:90% 00:31:09.990 --> 00:31:11.320 align:middle line:90% Let me erase the corollary. 00:31:11.320 --> 00:31:12.080 align:middle line:90% So I'll have room. 00:31:12.080 --> 00:31:15.210 align:middle line:90% 00:31:15.210 --> 00:31:33.090 align:middle line:84% So note, remark, by repeating l times, 00:31:33.090 --> 00:31:38.250 align:middle line:84% we get a somewhere extractable hash that's 00:31:38.250 --> 00:31:44.756 align:middle line:90% extractable on l locations. 00:31:44.756 --> 00:31:49.230 align:middle line:90% 00:31:49.230 --> 00:31:53.340 align:middle line:84% And moreover, another property that we're going to need-- 00:31:53.340 --> 00:31:58.710 align:middle line:84% even if I, let's say, gave you the trapdoor corresponding 00:31:58.710 --> 00:32:01.230 align:middle line:84% to some of the l-- not all the l locations-- let's 00:32:01.230 --> 00:32:04.950 align:middle line:84% say I give you trapdoor 1, trapdoor 2, and trapdoor 3, 00:32:04.950 --> 00:32:10.440 align:middle line:84% still, what's the location hidden in hk4? 00:32:10.440 --> 00:32:11.910 align:middle line:90% You have no idea what it is. 00:32:11.910 --> 00:32:15.390 align:middle line:84% So even if I reveal some of the trapdoors, 00:32:15.390 --> 00:32:19.650 align:middle line:90% the other indices remain hidden. 00:32:19.650 --> 00:32:22.390 align:middle line:84% And we're going to use this property. 00:32:22.390 --> 00:32:29.180 align:middle line:84% So again, if we repeat l times, we're binding on l locations. 00:32:29.180 --> 00:32:30.870 align:middle line:90% But even if I dest-- 00:32:30.870 --> 00:32:34.310 align:middle line:84% I kind of reveal the trapdoor corresponding to-- 00:32:34.310 --> 00:32:37.907 align:middle line:84% I don't know-- a location to a couple locations, the rest 00:32:37.907 --> 00:32:39.990 align:middle line:84% of the-- so of course, if I give you the trapdoor, 00:32:39.990 --> 00:32:41.275 align:middle line:90% then all bets are off. 00:32:41.275 --> 00:32:42.150 align:middle line:90% You learn everything. 00:32:42.150 --> 00:32:43.145 align:middle line:90% You learn the i. 00:32:43.145 --> 00:32:44.630 align:middle line:90% You learn everything. 00:32:44.630 --> 00:32:46.730 align:middle line:84% And the trapdoor or trapdoors are 00:32:46.730 --> 00:32:49.230 align:middle line:84% such that once I give you the trapdoor, you learn the index. 00:32:49.230 --> 00:32:50.840 align:middle line:90% You learn everything. 00:32:50.840 --> 00:32:57.770 align:middle line:84% But the other indices that do not correspond to the trapdoors 00:32:57.770 --> 00:32:59.930 align:middle line:84% that I gave are still completely hidden, 00:32:59.930 --> 00:33:03.535 align:middle line:84% because I did them completely independent. 00:33:03.535 --> 00:33:04.910 align:middle line:84% And this is something we're going 00:33:04.910 --> 00:33:06.910 align:middle line:84% to use when we're going to construct our SNARGs. 00:33:06.910 --> 00:33:09.380 align:middle line:90% 00:33:09.380 --> 00:33:12.710 align:middle line:84% So that's one thing we're going to use. 00:33:12.710 --> 00:33:14.240 align:middle line:90% I want to mention a little-- 00:33:14.240 --> 00:33:16.380 align:middle line:84% I want to talk a little bit about the construction, 00:33:16.380 --> 00:33:20.540 align:middle line:84% because I think maybe in Zhengzhong lecture last time, 00:33:20.540 --> 00:33:22.995 align:middle line:84% this was missed a little, because he said it, 00:33:22.995 --> 00:33:24.120 align:middle line:90% I think, a little too fast. 00:33:24.120 --> 00:33:27.150 align:middle line:84% So I want to say a few words about the construction. 00:33:27.150 --> 00:33:29.130 align:middle line:84% But before I talk about the construction, 00:33:29.130 --> 00:33:32.060 align:middle line:84% I want to say one more property about the BARGs 00:33:32.060 --> 00:33:33.740 align:middle line:90% that we're going to also use. 00:33:33.740 --> 00:33:35.970 align:middle line:84% So what we're going to use about the BARG, 00:33:35.970 --> 00:33:39.620 align:middle line:84% so we said that these gen P and V 00:33:39.620 --> 00:33:42.320 align:middle line:84% are polynomial time algorithm, probabilistic polynomial time 00:33:42.320 --> 00:33:43.130 align:middle line:90% algorithms. 00:33:43.130 --> 00:33:46.490 align:middle line:84% In particular, V, I want to talk about V. V is a polynomial time 00:33:46.490 --> 00:33:47.570 align:middle line:90% algorithm. 00:33:47.570 --> 00:33:49.440 align:middle line:90% But V's input is really large. 00:33:49.440 --> 00:33:50.960 align:middle line:90% It has x1 up to xk. 00:33:50.960 --> 00:33:54.620 align:middle line:84% So polynomial time means it runs at least in time poly k. 00:33:54.620 --> 00:33:57.290 align:middle line:90% It needs to read its input. 00:33:57.290 --> 00:34:00.770 align:middle line:84% However, it turns out that the BARGs we have-- 00:34:00.770 --> 00:34:04.200 align:middle line:84% this is what Zhengzhong called a BARG for index languages-- 00:34:04.200 --> 00:34:07.340 align:middle line:84% if there exists a succinct description 00:34:07.340 --> 00:34:10.639 align:middle line:84% of these x1 up to xk, the verifier 00:34:10.639 --> 00:34:14.340 align:middle line:84% only needs to run in time that depends on the description. 00:34:14.340 --> 00:34:17.400 align:middle line:90% In other words, we can replace-- 00:34:17.400 --> 00:34:24.350 align:middle line:90% so if-- I didn't bring my-- 00:34:24.350 --> 00:34:28.280 align:middle line:84% I forgot to bring my colorful chalk. 00:34:28.280 --> 00:34:29.020 align:middle line:90% Sorry. 00:34:29.020 --> 00:34:30.270 align:middle line:90% But at least you have cookies. 00:34:30.270 --> 00:34:33.389 align:middle line:84% I mean, what would you prefer, colorful chalks or cookies? 00:34:33.389 --> 00:34:38.780 align:middle line:84% So if you can generate these x1 up 00:34:38.780 --> 00:34:43.300 align:middle line:84% to xk, if there's kind of a succinct description, 00:34:43.300 --> 00:34:45.610 align:middle line:84% then the verify runs in polynomial time 00:34:45.610 --> 00:34:47.250 align:middle line:90% in the description. 00:34:47.250 --> 00:34:53.420 align:middle line:84% So if, let's say, there exists some machine M 00:34:53.420 --> 00:35:02.340 align:middle line:84% such that for every i, xi is just 00:35:02.340 --> 00:35:07.600 align:middle line:84% kind of the Turing machine on input i. 00:35:07.600 --> 00:35:11.250 align:middle line:84% So this kind of machine, you should think this algorithm, 00:35:11.250 --> 00:35:13.980 align:middle line:84% you should think it has kind of a succinct description of all 00:35:13.980 --> 00:35:15.210 align:middle line:90% the x1 up to xk. 00:35:15.210 --> 00:35:17.865 align:middle line:90% And you give him i. 00:35:17.865 --> 00:35:18.990 align:middle line:90% It always gives you the xi. 00:35:18.990 --> 00:35:32.150 align:middle line:84% If this is the case, then V the runtime, or I say time of V, 00:35:32.150 --> 00:35:39.730 align:middle line:84% it grows with the size of m as opposed to k. 00:35:39.730 --> 00:35:49.090 align:middle line:84% So it grows with m and does not grow with k. 00:35:49.090 --> 00:35:51.005 align:middle line:84% So of course, if you give him x1 up to xk, 00:35:51.005 --> 00:35:52.130 align:middle line:90% he needs to read his input. 00:35:52.130 --> 00:35:53.660 align:middle line:90% His runtime grows with k. 00:35:53.660 --> 00:35:56.710 align:middle line:84% But if you can generate in a succinct way, 00:35:56.710 --> 00:36:00.934 align:middle line:84% then he doesn't need to grow with k. 00:36:00.934 --> 00:36:03.410 align:middle line:84% So you should-- another way to think about it, 00:36:03.410 --> 00:36:09.940 align:middle line:84% you can think of xi as m comma i. 00:36:09.940 --> 00:36:13.570 align:middle line:84% And the instance just says if you run m on i, xi, 00:36:13.570 --> 00:36:15.328 align:middle line:90% then xi is in the language. 00:36:15.328 --> 00:36:17.620 align:middle line:84% And that's why it's called index language, because it's 00:36:17.620 --> 00:36:18.960 align:middle line:90% like there's an index. 00:36:18.960 --> 00:36:19.500 align:middle line:90% Yeah. 00:36:19.500 --> 00:36:21.640 align:middle line:84% AUDIENCE: So this means that there's still a log k dependence 00:36:21.640 --> 00:36:22.610 align:middle line:90% in V's runtime, right? 00:36:22.610 --> 00:36:22.930 align:middle line:90% PROFESSOR: Yeah, yeah, yeah. 00:36:22.930 --> 00:36:24.440 align:middle line:84% There is a log k dependence, 100%. 00:36:24.440 --> 00:36:24.940 align:middle line:90% Sorry. 00:36:24.940 --> 00:36:25.660 align:middle line:90% Yeah, yeah. 00:36:25.660 --> 00:36:27.230 align:middle line:90% It just means-- yeah, exactly. 00:36:27.230 --> 00:36:29.290 align:middle line:90% That runs in time log k. 00:36:29.290 --> 00:36:32.070 align:middle line:84% Actually, yeah, you have i here, which is log k. 00:36:32.070 --> 00:36:33.920 align:middle line:90% So there is a log k dependence. 00:36:33.920 --> 00:36:34.420 align:middle line:90% Yeah. 00:36:34.420 --> 00:36:38.470 align:middle line:84% AUDIENCE: [INAUDIBLE] the CRS is sublinear in k as well. 00:36:38.470 --> 00:36:39.860 align:middle line:90% Is that true? 00:36:39.860 --> 00:36:41.860 align:middle line:84% PROFESSOR: The length of the CRS in general, you 00:36:41.860 --> 00:36:43.240 align:middle line:90% want it to be sublinear in k. 00:36:43.240 --> 00:36:48.260 align:middle line:84% In the SNARG construction, it's poly log k. 00:36:48.260 --> 00:36:48.760 align:middle line:90% Yes. 00:36:48.760 --> 00:36:51.310 align:middle line:84% But when we'll talk about SNARGs-- 00:36:51.310 --> 00:36:55.315 align:middle line:84% so in the BARG construction, we have the CRS. 00:36:55.315 --> 00:36:58.020 align:middle line:90% 00:36:58.020 --> 00:37:02.040 align:middle line:84% Most of our construction in the CRS is of size poly log k. 00:37:02.040 --> 00:37:04.110 align:middle line:84% The one under LWE that Zhengzhong showed 00:37:04.110 --> 00:37:08.582 align:middle line:90% is of size poly log k. 00:37:08.582 --> 00:37:10.040 align:middle line:84% AUDIENCE: So I know that if we have 00:37:10.040 --> 00:37:12.410 align:middle line:84% a BARG that satisfies these properties 00:37:12.410 --> 00:37:14.780 align:middle line:84% and is a more tractable hash function, 00:37:14.780 --> 00:37:19.100 align:middle line:84% I guess you can always kind of add the property that you want 00:37:19.100 --> 00:37:21.770 align:middle line:84% here of being able to extract the witness from the BARG group 00:37:21.770 --> 00:37:22.370 align:middle line:90% itself. 00:37:22.370 --> 00:37:24.020 align:middle line:84% Is there a world-- like, do we have 00:37:24.020 --> 00:37:26.180 align:middle line:84% any BARGs without the assumptions 00:37:26.180 --> 00:37:29.383 align:middle line:84% that we need for somewhere extractable hash functions? 00:37:29.383 --> 00:37:30.800 align:middle line:84% PROFESSOR: You're asking, is there 00:37:30.800 --> 00:37:34.687 align:middle line:84% a BARG for which we don't know how to extract. 00:37:34.687 --> 00:37:35.270 align:middle line:90% AUDIENCE: Yes. 00:37:35.270 --> 00:37:36.853 align:middle line:84% PROFESSOR: Is that what you're asking? 00:37:36.853 --> 00:37:37.508 align:middle line:90% OK, OK. 00:37:37.508 --> 00:37:39.300 align:middle line:84% So let me-- you're asking a great question. 00:37:39.300 --> 00:37:40.015 align:middle line:90% Let me kind of-- 00:37:40.015 --> 00:37:42.940 align:middle line:90% 00:37:42.940 --> 00:37:45.820 align:middle line:90% so when we said-- 00:37:45.820 --> 00:37:50.560 align:middle line:84% the soundness condition just says that a cheating prover 00:37:50.560 --> 00:37:53.330 align:middle line:90% cannot cheat-- 00:37:53.330 --> 00:37:55.570 align:middle line:84% cannot generate x1 up to xk, that one of them, 00:37:55.570 --> 00:37:58.480 align:middle line:84% the i-th is not in the language, and yet convince. 00:37:58.480 --> 00:38:02.750 align:middle line:84% Oftentime, also in our SNARG, in our SNARG construction, 00:38:02.750 --> 00:38:04.430 align:middle line:90% we want something stronger. 00:38:04.430 --> 00:38:08.320 align:middle line:84% What we want is that I can actually extract a witness 00:38:08.320 --> 00:38:11.380 align:middle line:90% from this cheating prover. 00:38:11.380 --> 00:38:14.350 align:middle line:84% So I want to say this cheating prover, 00:38:14.350 --> 00:38:16.720 align:middle line:84% I can't extract all the witnesses. 00:38:16.720 --> 00:38:23.620 align:middle line:84% But for some i, I can generate a CRS that looks like-- 00:38:23.620 --> 00:38:28.090 align:middle line:84% just standard CRS-- but I can change the distribution of a CRS 00:38:28.090 --> 00:38:31.640 align:middle line:84% to be such that using some trapdoor about the CRS, 00:38:31.640 --> 00:38:36.663 align:middle line:84% I can actually extract from P star a witness for xi. 00:38:36.663 --> 00:38:38.330 align:middle line:84% And once I extract a witness, of course, 00:38:38.330 --> 00:38:39.370 align:middle line:84% it has to be in the language, xi. 00:38:39.370 --> 00:38:41.200 align:middle line:84% I argue not only it's in the language. 00:38:41.200 --> 00:38:44.260 align:middle line:84% I can even find-- get a witness from him. 00:38:44.260 --> 00:38:45.790 align:middle line:84% So that's called somewhere-- this 00:38:45.790 --> 00:38:48.610 align:middle line:90% is a somewhere extractable BARG. 00:38:48.610 --> 00:38:53.320 align:middle line:84% Now, what Ali was saying is that the BARG that Zhengzhong 00:38:53.320 --> 00:38:57.840 align:middle line:84% showed you last time had the somewhere extractable property. 00:38:57.840 --> 00:38:58.880 align:middle line:90% It was extractable. 00:38:58.880 --> 00:39:00.340 align:middle line:84% Actually, let me tell you, we also 00:39:00.340 --> 00:39:02.720 align:middle line:84% will need BARGs that are somewhere extractable. 00:39:02.720 --> 00:39:04.130 align:middle line:90% I didn't write that here. 00:39:04.130 --> 00:39:05.358 align:middle line:90% Why didn't I write it here? 00:39:05.358 --> 00:39:06.400 align:middle line:90% And this is where the n-- 00:39:06.400 --> 00:39:06.820 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:39:06.820 --> 00:39:07.750 align:middle line:90% PROFESSOR: Exactly. 00:39:07.750 --> 00:39:12.530 align:middle line:84% The answer is any BARG, we can make it somewhere extractable 00:39:12.530 --> 00:39:14.250 align:middle line:90% by just adding a hash. 00:39:14.250 --> 00:39:16.540 align:middle line:90% So we can kind of-- 00:39:16.540 --> 00:39:18.440 align:middle line:84% we don't need to worry about somewhere 00:39:18.440 --> 00:39:22.790 align:middle line:84% extractability of a BARG, because what we can always do 00:39:22.790 --> 00:39:24.470 align:middle line:90% is add-- 00:39:24.470 --> 00:39:27.152 align:middle line:90% put a hash of all the witnesses. 00:39:27.152 --> 00:39:28.860 align:middle line:84% If you have a somewhere extractable hash, 00:39:28.860 --> 00:39:30.630 align:middle line:84% if you have a somewhere extractable hash, 00:39:30.630 --> 00:39:32.540 align:middle line:90% you can tell the verifier-- 00:39:32.540 --> 00:39:36.060 align:middle line:84% put a somewhere extractable hash of all your witnesses. 00:39:36.060 --> 00:39:39.380 align:middle line:84% So take witness 1, witness 2, witness 3, up to witness k, 00:39:39.380 --> 00:39:43.523 align:middle line:84% hash them, and in the analysis, just jumping ahead, 00:39:43.523 --> 00:39:46.190 align:middle line:84% we're going to be extractable on all the locations corresponding 00:39:46.190 --> 00:39:47.810 align:middle line:90% to witness i. 00:39:47.810 --> 00:39:49.800 align:middle line:84% And now we're going to tell him-- 00:39:49.800 --> 00:39:51.620 align:middle line:84% we're going to say, give me a BARG. 00:39:51.620 --> 00:39:55.730 align:middle line:84% The BARG is not for the original language l. 00:39:55.730 --> 00:40:00.290 align:middle line:84% The BARG says-- the BARG that xi is in the language now 00:40:00.290 --> 00:40:04.010 align:middle line:84% says there is an opening for the hash value 00:40:04.010 --> 00:40:06.440 align:middle line:84% that [INAUDIBLE] the locations correspond to wi. 00:40:06.440 --> 00:40:09.800 align:middle line:84% If you opened, you would get a valid witness. 00:40:09.800 --> 00:40:11.730 align:middle line:90% BARG that language. 00:40:11.730 --> 00:40:13.940 align:middle line:84% So instead of BARGing the original language l, 00:40:13.940 --> 00:40:17.300 align:middle line:84% BARG a little bit kind of upgraded language 00:40:17.300 --> 00:40:20.630 align:middle line:84% that, again, says there's a-- so the verifier 00:40:20.630 --> 00:40:23.660 align:middle line:84% will give you a hash of all the witnesses. 00:40:23.660 --> 00:40:24.950 align:middle line:90% And it will prove-- 00:40:24.950 --> 00:40:28.820 align:middle line:84% for every i, he won't prove just excising the language. 00:40:28.820 --> 00:40:33.530 align:middle line:84% He's going to prove for every i, I have openings corresponding 00:40:33.530 --> 00:40:35.750 align:middle line:90% to witness i. 00:40:35.750 --> 00:40:37.670 align:middle line:90% So the eight openings are valid. 00:40:37.670 --> 00:40:40.700 align:middle line:90% And BWI is in the language l. 00:40:40.700 --> 00:40:42.950 align:middle line:84% That's the BARG he's going to give you. 00:40:42.950 --> 00:40:46.010 align:middle line:84% And now the fact that you're in the language 00:40:46.010 --> 00:40:50.960 align:middle line:84% means that it must be that if you take the trapdoor 00:40:50.960 --> 00:40:54.550 align:middle line:84% and look into it, it must be by soundness. 00:40:54.550 --> 00:40:55.053 align:middle line:90% It must be. 00:40:55.053 --> 00:40:57.220 align:middle line:84% That's what's sitting there, because you're binding. 00:40:57.220 --> 00:40:59.380 align:middle line:84% If you're going to be binding on that part, 00:40:59.380 --> 00:41:00.547 align:middle line:90% that's what's sitting there. 00:41:00.547 --> 00:41:02.770 align:middle line:90% It must be the correct witness. 00:41:02.770 --> 00:41:07.630 align:middle line:84% So that's kind of why, actually, we 00:41:07.630 --> 00:41:11.120 align:middle line:84% don't need to construct BARGs with extractability. 00:41:11.120 --> 00:41:14.715 align:middle line:84% We can always attach a somewhere extractable hash to them. 00:41:14.715 --> 00:41:15.340 align:middle line:90% AUDIENCE: Yeah. 00:41:15.340 --> 00:41:17.590 align:middle line:84% I was actually wondering something about assumptions,. 00:41:17.590 --> 00:41:20.350 align:middle line:84% Do we have any constructions of BARGs from assumptions 00:41:20.350 --> 00:41:22.552 align:middle line:84% weaker than those needed to construct a somewhere 00:41:22.552 --> 00:41:23.260 align:middle line:90% extractable hash? 00:41:23.260 --> 00:41:23.700 align:middle line:90% PROFESSOR: I see. 00:41:23.700 --> 00:41:25.370 align:middle line:84% AUDIENCE: Which would then make it, I guess, interesting. 00:41:25.370 --> 00:41:26.870 align:middle line:84% PROFESSOR: I see what you're saying. 00:41:26.870 --> 00:41:27.680 align:middle line:90% I see. 00:41:27.680 --> 00:41:28.930 align:middle line:90% AUDIENCE: I don't [INAUDIBLE]. 00:41:28.930 --> 00:41:30.380 align:middle line:84% PROFESSOR: Yeah, I don't think so. 00:41:30.380 --> 00:41:31.650 align:middle line:90% I don't think so. 00:41:31.650 --> 00:41:33.408 align:middle line:84% AUDIENCE: [INAUDIBLE] probably shouldn't. 00:41:33.408 --> 00:41:36.543 align:middle line:90% 00:41:36.543 --> 00:41:37.210 align:middle line:90% PROFESSOR: Yeah. 00:41:37.210 --> 00:41:38.903 align:middle line:84% I don't know how to construct a BARG 00:41:38.903 --> 00:41:41.320 align:middle line:84% from an assumption for which I don't know how to construct 00:41:41.320 --> 00:41:42.560 align:middle line:90% a somewhere extractable hash. 00:41:42.560 --> 00:41:44.430 align:middle line:90% Yeah. 00:41:44.430 --> 00:41:45.870 align:middle line:90% OK. 00:41:45.870 --> 00:41:47.170 align:middle line:90% Any other questions? 00:41:47.170 --> 00:41:51.240 align:middle line:90% 00:41:51.240 --> 00:41:55.250 align:middle line:84% So I want to get to the construction of the SNARG. 00:41:55.250 --> 00:41:58.250 align:middle line:84% But before I do so, I do want to spend 00:41:58.250 --> 00:42:00.560 align:middle line:84% a little more time on the somewhere extractable hash 00:42:00.560 --> 00:42:03.270 align:middle line:84% and say a little bit about the way we construct it, 00:42:03.270 --> 00:42:11.770 align:middle line:84% because I just want to make sure that you didn't miss 00:42:11.770 --> 00:42:13.990 align:middle line:84% a part from last lecture that I think 00:42:13.990 --> 00:42:16.070 align:middle line:90% was a bit said too succinctly. 00:42:16.070 --> 00:42:19.840 align:middle line:84% So the high level idea of how you construct a somewhere 00:42:19.840 --> 00:42:25.540 align:middle line:84% extractable hash is using fully homomorphic encryption. 00:42:25.540 --> 00:42:27.822 align:middle line:90% So I don't want to get into-- 00:42:27.822 --> 00:42:29.780 align:middle line:84% I don't want to recall too much the definition, 00:42:29.780 --> 00:42:31.310 align:middle line:90% but I'll give you a high level. 00:42:31.310 --> 00:42:34.388 align:middle line:84% So the basic idea, which doesn't work-- 00:42:34.388 --> 00:42:36.430 align:middle line:84% let me first tell you the idea that doesn't work, 00:42:36.430 --> 00:42:37.640 align:middle line:90% because that's very natural. 00:42:37.640 --> 00:42:40.190 align:middle line:84% And I think maybe that's what you got from last lecture. 00:42:40.190 --> 00:42:46.330 align:middle line:84% So the basic idea that doesn't work is to say that gen-- 00:42:46.330 --> 00:42:52.740 align:middle line:90% 00:42:52.740 --> 00:42:58.630 align:middle line:84% well, just the output, encryption, so we'll 00:42:58.630 --> 00:43:03.820 align:middle line:84% give you a public key and encryption of i 00:43:03.820 --> 00:43:05.080 align:middle line:90% with this public key. 00:43:05.080 --> 00:43:08.770 align:middle line:90% 00:43:08.770 --> 00:43:12.250 align:middle line:84% And the trapdoor, that's going to be the hash key. 00:43:12.250 --> 00:43:14.220 align:middle line:84% And the trapdoor is going to be the secret key. 00:43:14.220 --> 00:43:17.270 align:middle line:90% 00:43:17.270 --> 00:43:21.320 align:middle line:84% So just the hash key is going to be an encryption of the index. 00:43:21.320 --> 00:43:28.280 align:middle line:90% Now, I want x1 up to xn. 00:43:28.280 --> 00:43:30.890 align:middle line:84% Let me assume for simplicity that N-- 00:43:30.890 --> 00:43:38.660 align:middle line:90% suppose N is a power of 2. 00:43:38.660 --> 00:43:41.160 align:middle line:90% Otherwise, you know, pad. 00:43:41.160 --> 00:43:42.990 align:middle line:84% So let's say big N is a power of 2. 00:43:42.990 --> 00:43:44.750 align:middle line:90% So it's some 2 to the small n. 00:43:44.750 --> 00:43:46.580 align:middle line:84% Now, here's what I'm going to do. 00:43:46.580 --> 00:43:49.320 align:middle line:84% Let me-- so when I say encryption of i, 00:43:49.320 --> 00:43:51.360 align:middle line:84% let's think of it as bit by bit encryption. 00:43:51.360 --> 00:43:58.520 align:middle line:84% So it's encryption of i1 up to encryption of in. 00:43:58.520 --> 00:44:01.900 align:middle line:90% 00:44:01.900 --> 00:44:03.615 align:middle line:90% And now the idea is-- 00:44:03.615 --> 00:44:07.100 align:middle line:90% 00:44:07.100 --> 00:44:11.143 align:middle line:90% what we'll do is for each pair-- 00:44:11.143 --> 00:44:13.770 align:middle line:90% 00:44:13.770 --> 00:44:15.840 align:middle line:84% so I'm going to do kind of a Merkle hash. 00:44:15.840 --> 00:44:18.720 align:middle line:84% And for each pair I'm going to encrypt, 00:44:18.720 --> 00:44:22.650 align:middle line:84% so I'm going to do this Merkle hash, where for each node 00:44:22.650 --> 00:44:24.510 align:middle line:84% I'm going to associate a ciphertext. 00:44:24.510 --> 00:44:27.400 align:middle line:84% And the output is going to be the ciphertext of the root. 00:44:27.400 --> 00:44:28.608 align:middle line:90% That's my hash value. 00:44:28.608 --> 00:44:30.900 align:middle line:84% The hash value is going to be a ciphertext of the root. 00:44:30.900 --> 00:44:32.950 align:middle line:84% And this ciphertext can be a ciphertext. 00:44:32.950 --> 00:44:36.270 align:middle line:90% It's an re-encryption of xi. 00:44:36.270 --> 00:44:37.155 align:middle line:90% How do I associate? 00:44:37.155 --> 00:44:39.030 align:middle line:84% So of course, I can compute encryption of xi. 00:44:39.030 --> 00:44:40.590 align:middle line:84% This is a homomorphic encryption. 00:44:40.590 --> 00:44:44.130 align:middle line:84% Given x and encryption of i, I can do computation 00:44:44.130 --> 00:44:45.030 align:middle line:90% under the hood. 00:44:45.030 --> 00:44:48.850 align:middle line:84% So I can compute encryption of x sub i. 00:44:48.850 --> 00:44:52.620 align:middle line:84% So because this is a fully homomorphic encryption, 00:44:52.620 --> 00:44:58.680 align:middle line:84% given x and encryption of i, I can 00:44:58.680 --> 00:45:02.798 align:middle line:90% compute encryption of x sub i. 00:45:02.798 --> 00:45:04.090 align:middle line:90% Of course, there's public keys. 00:45:04.090 --> 00:45:07.920 align:middle line:84% I'm omitting them for succinctness of notation. 00:45:07.920 --> 00:45:11.670 align:middle line:84% This is because I can compute under the hood. 00:45:11.670 --> 00:45:15.630 align:middle line:84% The value of the route is going to be encryption of xi. 00:45:15.630 --> 00:45:17.490 align:middle line:90% But what kind of encryption? 00:45:17.490 --> 00:45:19.830 align:middle line:84% It's not any-- so let me tell you exactly how we 00:45:19.830 --> 00:45:21.300 align:middle line:90% compute this encryption. 00:45:21.300 --> 00:45:25.170 align:middle line:90% So the idea would be-- 00:45:25.170 --> 00:45:27.980 align:middle line:84% and not only that, how do I open? 00:45:27.980 --> 00:45:29.290 align:middle line:90% I want to do a local opening. 00:45:29.290 --> 00:45:32.460 align:middle line:84% So the way I'm going to do it is as follows. 00:45:32.460 --> 00:45:35.820 align:middle line:84% For each pair, I'm going to encrypt only one of them. 00:45:35.820 --> 00:45:38.370 align:middle line:84% I'm going to either put here encryption of x1 00:45:38.370 --> 00:45:39.700 align:middle line:90% or encryption of x2. 00:45:39.700 --> 00:45:40.530 align:middle line:90% Which one? 00:45:40.530 --> 00:45:41.820 align:middle line:90% Depending on i1. 00:45:41.820 --> 00:45:43.690 align:middle line:90% So let's start with i1. 00:45:43.690 --> 00:45:47.970 align:middle line:84% If i1 is 0, I'm going to-- so I'm going to, 00:45:47.970 --> 00:45:49.240 align:middle line:90% let's say, choose x1. 00:45:49.240 --> 00:45:51.833 align:middle line:84% If i1 is 1, I'm going to choose x2. 00:45:51.833 --> 00:45:54.000 align:middle line:84% I'm going to choose the even-odd, so that the output 00:45:54.000 --> 00:45:55.950 align:middle line:90% will be the correct one. 00:45:55.950 --> 00:45:58.020 align:middle line:90% So I'm going to-- 00:45:58.020 --> 00:46:01.320 align:middle line:84% the i1, depending on encryption of i1, 00:46:01.320 --> 00:46:03.520 align:middle line:84% that's going to tell me which one to put here. 00:46:03.520 --> 00:46:08.490 align:middle line:84% 0, I put on the left, like the left children, or 1, 00:46:08.490 --> 00:46:10.570 align:middle line:90% I put the right children. 00:46:10.570 --> 00:46:12.050 align:middle line:84% And then I do the exact same thing. 00:46:12.050 --> 00:46:15.340 align:middle line:84% Given these, whether I choose the left or right 00:46:15.340 --> 00:46:17.380 align:middle line:90% depends on the encryption of i2. 00:46:17.380 --> 00:46:19.610 align:middle line:90% If i2 is 0, I choose the left. 00:46:19.610 --> 00:46:23.470 align:middle line:84% If i2 is 1, I choose the right, and so on and so forth. 00:46:23.470 --> 00:46:25.261 align:middle line:90% That's the idea. 00:46:25.261 --> 00:46:28.030 align:middle line:90% AUDIENCE: Is this like an OT? 00:46:28.030 --> 00:46:29.350 align:middle line:90% PROFESSOR: It's like an OT. 00:46:29.350 --> 00:46:30.500 align:middle line:90% It's really like an OT. 00:46:30.500 --> 00:46:31.607 align:middle line:90% Exactly, exactly. 00:46:31.607 --> 00:46:33.940 align:middle line:84% I didn't define what OT is, but it's exactly like an OT. 00:46:33.940 --> 00:46:36.940 align:middle line:90% 00:46:36.940 --> 00:46:38.130 align:middle line:90% This does not work. 00:46:38.130 --> 00:46:41.880 align:middle line:90% 00:46:41.880 --> 00:46:44.480 align:middle line:84% It almost works, but it does not work. 00:46:44.480 --> 00:46:47.400 align:middle line:84% So let me tell you why it seems like it should work. 00:46:47.400 --> 00:46:55.240 align:middle line:84% And then I just want to mention the subtlety here. 00:46:55.240 --> 00:47:00.230 align:middle line:84% So the reason-- so first, how do you generate the local opening? 00:47:00.230 --> 00:47:04.390 align:middle line:84% Well, you check-- so if you want to open xi, I'll tell you, 00:47:04.390 --> 00:47:08.550 align:middle line:84% give me x1 and x2 so I can check that this is correct. 00:47:08.550 --> 00:47:11.910 align:middle line:84% And then give me the hash in ciphertext here. 00:47:11.910 --> 00:47:14.040 align:middle line:84% And I can check that this is correct, 00:47:14.040 --> 00:47:20.670 align:middle line:84% because each ciphertext is some FHE valuation that 00:47:20.670 --> 00:47:25.620 align:middle line:84% depends on the two children and the hash key, which 00:47:25.620 --> 00:47:26.860 align:middle line:90% is encryption. 00:47:26.860 --> 00:47:32.310 align:middle line:84% So in layer J, it depends on the two children 00:47:32.310 --> 00:47:35.140 align:middle line:90% and encryption of ij. 00:47:35.140 --> 00:47:39.340 align:middle line:90% Each time the node-- 00:47:39.340 --> 00:47:43.780 align:middle line:84% the ciphertext corresponding to some node 00:47:43.780 --> 00:47:48.070 align:middle line:84% is a deterministic function of the ciphertext corresponding 00:47:48.070 --> 00:47:52.700 align:middle line:84% to the children, and the hash key corresponding to that level. 00:47:52.700 --> 00:47:57.430 align:middle line:84% So encryption of, let's say, ij, because, remember, 00:47:57.430 --> 00:48:01.340 align:middle line:84% if I'm, let's say, in level 2, I have here a ciphertext. 00:48:01.340 --> 00:48:03.290 align:middle line:90% I have a 1 in ciphertext 2. 00:48:03.290 --> 00:48:12.970 align:middle line:84% Then I do-- the way I compute the parent ciphertext is just 00:48:12.970 --> 00:48:16.210 align:middle line:84% a homomorphic evaluation that takes-- 00:48:16.210 --> 00:48:22.900 align:middle line:84% if i2 is 0, it takes ciphertext 2. 00:48:22.900 --> 00:48:25.630 align:middle line:90% If i2 is 1, it takes-- 00:48:25.630 --> 00:48:26.130 align:middle line:90% I'm sorry. 00:48:26.130 --> 00:48:28.430 align:middle line:84% So if it's a 1, otherwise, it takes ciphertext 2. 00:48:28.430 --> 00:48:30.520 align:middle line:84% So this is really just a deterministic homomorphic 00:48:30.520 --> 00:48:32.170 align:middle line:90% evaluation. 00:48:32.170 --> 00:48:33.530 align:middle line:90% And so that's how I open. 00:48:33.530 --> 00:48:35.450 align:middle line:84% I just open all the relevant ciphertext 00:48:35.450 --> 00:48:39.020 align:middle line:84% and the verifier will check that the homomorphic evaluation was 00:48:39.020 --> 00:48:40.730 align:middle line:90% done correctly. 00:48:40.730 --> 00:48:42.480 align:middle line:90% So you can local opening-- 00:48:42.480 --> 00:48:44.930 align:middle line:84% you can do local opening, but it's not binding. 00:48:44.930 --> 00:48:47.360 align:middle line:84% Or I don't know how to prove that it's binding 00:48:47.360 --> 00:48:49.120 align:middle line:90% is the problem. 00:48:49.120 --> 00:48:51.700 align:middle line:84% And probably, you can find a weird FHE 00:48:51.700 --> 00:48:52.880 align:middle line:90% for which it's not binding. 00:48:52.880 --> 00:48:55.638 align:middle line:84% I don't know-- maybe for natural constructions, it is binding. 00:48:55.638 --> 00:48:56.180 align:middle line:90% I don't know. 00:48:56.180 --> 00:48:57.388 align:middle line:90% I don't know how to prove it. 00:48:57.388 --> 00:48:59.600 align:middle line:84% But there's a problem with binding. 00:48:59.600 --> 00:49:03.400 align:middle line:84% And the problem with binding is that a cheating-- so it seems 00:49:03.400 --> 00:49:05.230 align:middle line:84% like it should be binding because, look, 00:49:05.230 --> 00:49:08.340 align:middle line:84% here it's sitting encryption of xi. 00:49:08.340 --> 00:49:11.160 align:middle line:84% But the thing is the reason why it's not 00:49:11.160 --> 00:49:18.470 align:middle line:84% binding is because a malicious adversary, 00:49:18.470 --> 00:49:21.950 align:middle line:84% he may give ciphertexts that are garbage-- 00:49:21.950 --> 00:49:23.540 align:middle line:90% are completely garbage. 00:49:23.540 --> 00:49:26.450 align:middle line:84% They don't actually-- they're not legal ciphertexts. 00:49:26.450 --> 00:49:29.390 align:middle line:84% And if he gives ciphertexts that are garbage, 00:49:29.390 --> 00:49:32.790 align:middle line:84% I don't know why would there be binding. 00:49:32.790 --> 00:49:36.560 align:middle line:84% So I mean, maybe extract doesn't work. 00:49:36.560 --> 00:49:37.170 align:middle line:90% Here's me. 00:49:37.170 --> 00:49:39.260 align:middle line:90% I'm a malicious person. 00:49:39.260 --> 00:49:42.300 align:middle line:84% i-- nothing-- no, you can't extract anything. 00:49:42.300 --> 00:49:43.680 align:middle line:90% I just want to ruin the binding. 00:49:43.680 --> 00:49:47.030 align:middle line:90% My whole goal is to-- 00:49:47.030 --> 00:49:49.130 align:middle line:90% kind of ruin binding here. 00:49:49.130 --> 00:49:52.350 align:middle line:84% I'm going to give you v that doesn't encrypt anything. 00:49:52.350 --> 00:49:56.090 align:middle line:84% It's a junk v. And I'm going to open it in two different ways. 00:49:56.090 --> 00:50:02.040 align:middle line:84% Maybe I can generate a v. Like I call it ciphertext, 00:50:02.040 --> 00:50:05.040 align:middle line:84% but it's just a bunch of bits that have no meaning-- 00:50:05.040 --> 00:50:06.570 align:middle line:90% cannot be decrypted at all. 00:50:06.570 --> 00:50:10.470 align:middle line:84% And maybe I can somehow generate valid openings. 00:50:10.470 --> 00:50:14.960 align:middle line:84% And we don't know how to argue that you cannot do that. 00:50:14.960 --> 00:50:17.820 align:middle line:84% So in order to actually get soundness, 00:50:17.820 --> 00:50:21.760 align:middle line:84% I need to make sure that the things are well-formed, 00:50:21.760 --> 00:50:23.730 align:middle line:84% that these are actually valid ciphertexts, 00:50:23.730 --> 00:50:27.330 align:middle line:84% or what I open to is a valid ciphertext. 00:50:27.330 --> 00:50:32.580 align:middle line:84% And the way we get this is by making 00:50:32.580 --> 00:50:35.550 align:middle line:90% this a little more cumbersome. 00:50:35.550 --> 00:50:38.400 align:middle line:84% So the way we get this is we actually 00:50:38.400 --> 00:50:40.140 align:middle line:90% don't use one public key. 00:50:40.140 --> 00:50:42.970 align:middle line:90% We use small and public keys. 00:50:42.970 --> 00:50:46.840 align:middle line:84% So for each layer, we'll use a different public key. 00:50:46.840 --> 00:50:49.760 align:middle line:90% And what we encrypt-- 00:50:49.760 --> 00:50:58.950 align:middle line:84% so what we do is we have public key j for j goes from 1 to n. 00:50:58.950 --> 00:51:00.810 align:middle line:90% So we have n public keys. 00:51:00.810 --> 00:51:07.730 align:middle line:84% And with public key j, we encrypt ij. 00:51:07.730 --> 00:51:13.400 align:middle line:84% But also, so when i has i1 up to in, we encrypt ij. 00:51:13.400 --> 00:51:18.560 align:middle line:90% But we also encrypt skj minus 1. 00:51:18.560 --> 00:51:21.080 align:middle line:90% I want to have the decryption. 00:51:21.080 --> 00:51:25.180 align:middle line:84% It's important to me to have the decryption key. 00:51:25.180 --> 00:51:31.930 align:middle line:84% Now, so the important bit is the homomorphic evaluation 00:51:31.930 --> 00:51:34.900 align:middle line:84% I'm doing here, I need to know the secret key, 00:51:34.900 --> 00:51:37.750 align:middle line:84% because I'm not just going to say-- 00:51:37.750 --> 00:51:41.080 align:middle line:84% before I said, what's going on underneath under the hood? 00:51:41.080 --> 00:51:43.242 align:middle line:90% I'm saying, look, I have i1. 00:51:43.242 --> 00:51:44.200 align:middle line:90% I have two ciphertexts. 00:51:44.200 --> 00:51:45.110 align:middle line:90% Give me one of them. 00:51:45.110 --> 00:51:46.310 align:middle line:90% No, no, no, no. 00:51:46.310 --> 00:51:50.230 align:middle line:84% What I want to do is to say the following under the hood. 00:51:50.230 --> 00:51:53.480 align:middle line:90% Decrypt this. 00:51:53.480 --> 00:51:54.355 align:middle line:90% Decrypt this. 00:51:54.355 --> 00:51:57.050 align:middle line:90% 00:51:57.050 --> 00:51:59.660 align:middle line:84% And give me only the relevant one. 00:51:59.660 --> 00:52:04.260 align:middle line:84% So that even if this does not decrypt-- 00:52:04.260 --> 00:52:05.980 align:middle line:90% so here's the point. 00:52:05.980 --> 00:52:07.420 align:middle line:90% Let's say I want to open to x2. 00:52:07.420 --> 00:52:10.680 align:middle line:90% 00:52:10.680 --> 00:52:11.600 align:middle line:90% He gives me x1. 00:52:11.600 --> 00:52:12.770 align:middle line:90% These are valid. 00:52:12.770 --> 00:52:14.120 align:middle line:90% So this is valid. 00:52:14.120 --> 00:52:15.790 align:middle line:90% Good. 00:52:15.790 --> 00:52:20.910 align:middle line:84% But now, ciphertext 2 can be completely not valid. 00:52:20.910 --> 00:52:24.517 align:middle line:84% Because when he opens, he gives me ciphertext 1 with these two. 00:52:24.517 --> 00:52:26.100 align:middle line:84% So I know this was valid, because this 00:52:26.100 --> 00:52:27.570 align:middle line:90% is a different computation. 00:52:27.570 --> 00:52:29.970 align:middle line:84% And then I give him ciphertext 2. 00:52:29.970 --> 00:52:31.520 align:middle line:90% And I do this evaluation. 00:52:31.520 --> 00:52:34.770 align:middle line:84% And then he gives me-- so the sibling ciphertext 00:52:34.770 --> 00:52:38.250 align:middle line:84% that he gives me, they may not be valid. 00:52:38.250 --> 00:52:41.340 align:middle line:84% I want to ensure, even if they're not valid, 00:52:41.340 --> 00:52:45.620 align:middle line:84% even if they're not valid, this is going to be valid. 00:52:45.620 --> 00:52:50.150 align:middle line:84% The openings are going to be valid, kind of on the path, 00:52:50.150 --> 00:52:53.180 align:middle line:84% things are going to be valid, even though the siblings that 00:52:53.180 --> 00:52:57.000 align:middle line:84% are given in order to just kind do the-- verify the opening, 00:52:57.000 --> 00:53:00.470 align:middle line:84% even if they're not valid, the opening path 00:53:00.470 --> 00:53:03.320 align:middle line:84% will be kind of valid ciphertext. 00:53:03.320 --> 00:53:05.250 align:middle line:84% So why are they going to be valid? 00:53:05.250 --> 00:53:09.680 align:middle line:84% Because the way that-- what is-- so now, 00:53:09.680 --> 00:53:11.450 align:middle line:84% what is the deterministic computation 00:53:11.450 --> 00:53:12.540 align:middle line:90% that's happening here? 00:53:12.540 --> 00:53:16.230 align:middle line:84% Or the evaluation, the evaluated ciphertext? 00:53:16.230 --> 00:53:18.270 align:middle line:84% The way we do the evaluation is the following. 00:53:18.270 --> 00:53:21.440 align:middle line:84% I decrypt this, and I decrypt this. 00:53:21.440 --> 00:53:26.740 align:middle line:84% And then I take the decrypted value. 00:53:26.740 --> 00:53:30.490 align:middle line:84% And I encrypt it with the next public key. 00:53:30.490 --> 00:53:33.790 align:middle line:84% So the point is, even if this didn't decrypt-- 00:53:33.790 --> 00:53:35.800 align:middle line:90% maybe this didn't decrypt-- 00:53:35.800 --> 00:53:38.090 align:middle line:90% I don't care. 00:53:38.090 --> 00:53:39.760 align:middle line:84% And this is still going to be valid. 00:53:39.760 --> 00:53:42.750 align:middle line:90% 00:53:42.750 --> 00:53:47.010 align:middle line:84% So the point is, even if the sibling ciphertexts 00:53:47.010 --> 00:53:50.770 align:middle line:84% that are given only for verifying the opening, 00:53:50.770 --> 00:53:55.370 align:middle line:84% even if these sibling ciphertexts are malformed, 00:53:55.370 --> 00:53:58.020 align:middle line:84% if you give me the opening and the entire path, 00:53:58.020 --> 00:54:01.620 align:middle line:84% I get the guarantee that on the path, not on the siblings, 00:54:01.620 --> 00:54:03.920 align:middle line:84% on the path, things are well formed. 00:54:03.920 --> 00:54:05.890 align:middle line:84% And I mean well-formed ciphertext. 00:54:05.890 --> 00:54:08.750 align:middle line:84% These are ciphertext that decrypt correctly. 00:54:08.750 --> 00:54:11.600 align:middle line:84% And that's what I need for the soundness. 00:54:11.600 --> 00:54:13.680 align:middle line:84% So it's important to do the decryption. 00:54:13.680 --> 00:54:15.313 align:middle line:90% This is really crucial. 00:54:15.313 --> 00:54:16.980 align:middle line:84% AUDIENCE: Are you doing it on each node? 00:54:16.980 --> 00:54:18.202 align:middle line:90% I didn't fully follow. 00:54:18.202 --> 00:54:20.160 align:middle line:84% PROFESSOR: Again, what am I doing on each node? 00:54:20.160 --> 00:54:20.690 align:middle line:90% Good, good, good. 00:54:20.690 --> 00:54:22.400 align:middle line:84% So here's what I'm doing on each node. 00:54:22.400 --> 00:54:28.790 align:middle line:84% The evaluation function takes kind of ij secret key j minus 1 00:54:28.790 --> 00:54:32.870 align:middle line:84% and two ciphertexts, ciphertext 0 and ciphertext 1. 00:54:32.870 --> 00:54:35.450 align:middle line:84% And what it does is the following-- decrypt 00:54:35.450 --> 00:54:42.140 align:middle line:84% ciphertext 0, so it decrypts with SKJ minus 1 ciphertext 0-- 00:54:42.140 --> 00:54:44.060 align:middle line:90% ciphertext b for every b. 00:54:44.060 --> 00:54:46.460 align:middle line:90% It gets some bit-- 00:54:46.460 --> 00:54:50.920 align:middle line:90% I don't know-- an alpha B. 00:54:50.920 --> 00:54:56.590 align:middle line:90% And then it outputs one of them. 00:54:56.590 --> 00:54:59.460 align:middle line:90% I know alpha, b star, alpha ij. 00:54:59.460 --> 00:55:02.660 align:middle line:90% 00:55:02.660 --> 00:55:06.190 align:middle line:84% So it gets two bits, and he chooses one of them, 00:55:06.190 --> 00:55:08.400 align:middle line:84% which one depending on the ij you want. 00:55:08.400 --> 00:55:11.040 align:middle line:84% So what you-- the point is what you will get 00:55:11.040 --> 00:55:13.170 align:middle line:90% is really an encryption. 00:55:13.170 --> 00:55:15.350 align:middle line:90% So the point is, let's say if-- 00:55:15.350 --> 00:55:17.100 align:middle line:84% AUDIENCE: You're doing it homomorphically. 00:55:17.100 --> 00:55:18.517 align:middle line:84% PROFESSOR: I do it under the hood. 00:55:18.517 --> 00:55:20.770 align:middle line:84% This is a computation that is done under the hood. 00:55:20.770 --> 00:55:21.270 align:middle line:90% Yes. 00:55:21.270 --> 00:55:24.690 align:middle line:84% So this is going to be encrypted in a box. 00:55:24.690 --> 00:55:28.390 align:middle line:84% But what I'm going to do under the box is to say-- 00:55:28.390 --> 00:55:30.100 align:middle line:90% so these, I have-- so sorry. 00:55:30.100 --> 00:55:35.080 align:middle line:84% These two are-- ij and skj minus 1 are in a box. 00:55:35.080 --> 00:55:38.570 align:middle line:84% And the computation that I'm doing inside the box 00:55:38.570 --> 00:55:40.610 align:middle line:84% is I'm saying, I have these in a box. 00:55:40.610 --> 00:55:42.450 align:middle line:90% I have these in the clear. 00:55:42.450 --> 00:55:44.680 align:middle line:84% Inside the box, what I do is the following. 00:55:44.680 --> 00:55:47.820 align:middle line:84% I say, I have the secret key j minus 1 and these two 00:55:47.820 --> 00:55:48.760 align:middle line:90% ciphertexts. 00:55:48.760 --> 00:55:50.600 align:middle line:90% Let me decrypt both of them. 00:55:50.600 --> 00:55:53.090 align:middle line:84% I'm going to get two bits, alpha 0 and alpha 1. 00:55:53.090 --> 00:55:55.740 align:middle line:84% Now, maybe one of them is bad, so bad. 00:55:55.740 --> 00:55:58.140 align:middle line:84% So maybe one of them doesn't decrypt. 00:55:58.140 --> 00:56:02.280 align:middle line:84% So the one that doesn't decrypt output bad. 00:56:02.280 --> 00:56:05.970 align:middle line:84% And then the output will be the relevant one 00:56:05.970 --> 00:56:09.370 align:middle line:84% that, according if it's 0, I'm going to output alpha 0. 00:56:09.370 --> 00:56:11.250 align:middle line:84% If it's 1, I'm going to output alpha 1. 00:56:11.250 --> 00:56:15.670 align:middle line:84% And now what I can argue is on the path itself, 00:56:15.670 --> 00:56:17.400 align:middle line:84% everything has to be well-formed. 00:56:17.400 --> 00:56:22.600 align:middle line:84% So I'm actually going to get the correct ciphertext. 00:56:22.600 --> 00:56:26.202 align:middle line:84% And I can argue that by induction. 00:56:26.202 --> 00:56:27.910 align:middle line:84% And here, of course, this is well-formed, 00:56:27.910 --> 00:56:30.430 align:middle line:84% because this is just a deterministic computation that's 00:56:30.430 --> 00:56:31.760 align:middle line:90% done locally. 00:56:31.760 --> 00:56:33.430 align:middle line:90% Now, the point is-- 00:56:33.430 --> 00:56:36.130 align:middle line:84% so let's say, like, I want to output-- 00:56:36.130 --> 00:56:38.500 align:middle line:90% I want to-- I'm binding on x1. 00:56:38.500 --> 00:56:40.130 align:middle line:90% x1 is what I want to open. 00:56:40.130 --> 00:56:42.190 align:middle line:90% So this must be well-formed. 00:56:42.190 --> 00:56:47.000 align:middle line:84% And now the point is, even if this is not well-formed, 00:56:47.000 --> 00:56:48.430 align:middle line:90% what will I do under the hood? 00:56:48.430 --> 00:56:50.340 align:middle line:84% I'm going to open this and open this. 00:56:50.340 --> 00:56:51.990 align:middle line:84% This is going to be the correct value. 00:56:51.990 --> 00:56:54.490 align:middle line:84% This is not going to be maybe the correct-- this may be bad. 00:56:54.490 --> 00:56:56.700 align:middle line:90% But this is the one I choose. 00:56:56.700 --> 00:56:57.910 align:middle line:90% And then I encrypt it. 00:56:57.910 --> 00:56:59.430 align:middle line:90% So I have it here. 00:56:59.430 --> 00:57:01.560 align:middle line:84% And then, again, this may be bad. 00:57:01.560 --> 00:57:02.770 align:middle line:90% I'm going to decrypt it. 00:57:02.770 --> 00:57:04.980 align:middle line:84% It may be bad, but this is going to be good, 00:57:04.980 --> 00:57:06.600 align:middle line:90% and this is the one I choose. 00:57:06.600 --> 00:57:09.180 align:middle line:84% So one can argue kind of by induction 00:57:09.180 --> 00:57:10.930 align:middle line:84% that this is going to be encryption of x1. 00:57:10.930 --> 00:57:13.347 align:middle line:84% This is going to be encryption of blah blah blah. everyone 00:57:13.347 --> 00:57:14.830 align:middle line:90% encryption of x1 until the end. 00:57:14.830 --> 00:57:16.955 align:middle line:84% So there's no way you can open two different roads. 00:57:16.955 --> 00:57:18.083 align:middle line:90% You have to open x1. 00:57:18.083 --> 00:57:19.500 align:middle line:84% AUDIENCE: And the verifier is also 00:57:19.500 --> 00:57:21.468 align:middle line:84% going to do the same computation to check? 00:57:21.468 --> 00:57:22.260 align:middle line:90% PROFESSOR: Exactly! 00:57:22.260 --> 00:57:24.930 align:middle line:84% The verifier does the exact same computation to check. 00:57:24.930 --> 00:57:25.430 align:middle line:90% Yes. 00:57:25.430 --> 00:57:28.420 align:middle line:90% 00:57:28.420 --> 00:57:29.690 align:middle line:90% Yeah. 00:57:29.690 --> 00:57:31.990 align:middle line:84% AUDIENCE: [INAUDIBLE] can only open the [INAUDIBLE] 00:57:31.990 --> 00:57:33.670 align:middle line:90% that you generated, right? 00:57:33.670 --> 00:57:35.073 align:middle line:90% This is not opening a general i. 00:57:35.073 --> 00:57:35.740 align:middle line:90% PROFESSOR: Good. 00:57:35.740 --> 00:57:36.940 align:middle line:90% So this-- exactly. 00:57:36.940 --> 00:57:40.310 align:middle line:90% This shows that the specific-- 00:57:40.310 --> 00:57:52.720 align:middle line:84% so this-- this shows that the specific i that's encrypted 00:57:52.720 --> 00:57:53.960 align:middle line:90% here-- 00:57:53.960 --> 00:57:57.890 align:middle line:84% so there's one-- the hash key is binding on one i, 00:57:57.890 --> 00:57:59.780 align:middle line:90% on a specific i. 00:57:59.780 --> 00:58:04.130 align:middle line:84% The i on which you're binding, you can only 00:58:04.130 --> 00:58:07.810 align:middle line:90% open in one way statistically. 00:58:07.810 --> 00:58:11.110 align:middle line:84% And then by the index hiding, it means that you can-- 00:58:11.110 --> 00:58:13.840 align:middle line:84% for any j, you can only open one-way computationally, 00:58:13.840 --> 00:58:16.730 align:middle line:90% because you can't distinguish. 00:58:16.730 --> 00:58:17.240 align:middle line:90% Yeah. 00:58:17.240 --> 00:58:18.860 align:middle line:84% AUDIENCE: Can you avoid this chain of keys 00:58:18.860 --> 00:58:20.793 align:middle line:84% if you are happy to just encrypt the secret key 00:58:20.793 --> 00:58:21.440 align:middle line:90% at the same [INAUDIBLE]? 00:58:21.440 --> 00:58:22.950 align:middle line:84% PROFESSOR: Good, very good, good. 00:58:22.950 --> 00:58:25.490 align:middle line:90% Yes. 00:58:25.490 --> 00:58:27.510 align:middle line:84% You can avoid using many public keys. 00:58:27.510 --> 00:58:30.030 align:middle line:90% You can just use one public key. 00:58:30.030 --> 00:58:33.420 align:middle line:84% Encrypt the secret key, and rely on what's 00:58:33.420 --> 00:58:34.650 align:middle line:90% called circular security. 00:58:34.650 --> 00:58:36.950 align:middle line:84% That's another option, if you wish. 00:58:36.950 --> 00:58:39.300 align:middle line:90% Sorry it doesn't want to do it. 00:58:39.300 --> 00:58:41.820 align:middle line:90% But yes, exactly. 00:58:41.820 --> 00:58:42.870 align:middle line:90% Exactly. 00:58:42.870 --> 00:58:44.710 align:middle line:90% Yeah. 00:58:44.710 --> 00:58:47.527 align:middle line:84% AUDIENCE: You can get collision resistance? 00:58:47.527 --> 00:58:48.110 align:middle line:90% PROFESSOR: OK. 00:58:48.110 --> 00:58:51.400 align:middle line:84% So yeah, So you're asking, will you get a collision-- 00:58:51.400 --> 00:58:52.880 align:middle line:90% like collision resistance? 00:58:52.880 --> 00:58:58.270 align:middle line:84% And the answer is yes, because for this specific i that you-- 00:58:58.270 --> 00:59:04.250 align:middle line:84% for the specific i that kind of you encrypted in the hash key, 00:59:04.250 --> 00:59:08.422 align:middle line:90% you get a binding statistically. 00:59:08.422 --> 00:59:10.380 align:middle line:84% There's no way you can open two different ways. 00:59:10.380 --> 00:59:14.097 align:middle line:90% 00:59:14.097 --> 00:59:15.680 align:middle line:84% AUDIENCE: What you have at [INAUDIBLE] 00:59:15.680 --> 00:59:18.100 align:middle line:84% is just the encryption of that index, right? 00:59:18.100 --> 00:59:19.456 align:middle line:90% PROFESSOR: Right. 00:59:19.456 --> 00:59:21.925 align:middle line:84% So you're asking about a different j? 00:59:21.925 --> 00:59:22.915 align:middle line:90% Oh, sorry. 00:59:22.915 --> 00:59:28.710 align:middle line:84% AUDIENCE: No, that you have two x's that have the same index. 00:59:28.710 --> 00:59:31.650 align:middle line:84% They have the same [INAUDIBLE], the index, 00:59:31.650 --> 00:59:33.986 align:middle line:90% but the rest are different. 00:59:33.986 --> 00:59:37.800 align:middle line:84% Will you get a different output of the hash if you take those 00:59:37.800 --> 00:59:38.700 align:middle line:90% two different x's? 00:59:38.700 --> 00:59:39.867 align:middle line:90% PROFESSOR: Good, good, good. 00:59:39.867 --> 00:59:42.870 align:middle line:84% So if you take two different x's for which, 00:59:42.870 --> 00:59:45.030 align:middle line:84% let's say, they have the same x1. 00:59:45.030 --> 00:59:50.400 align:middle line:84% And let's say the hash key is binding on location 1, 00:59:50.400 --> 00:59:54.480 align:middle line:84% the value you would get if you hash them honestly will 00:59:54.480 --> 00:59:56.400 align:middle line:90% be actually very different. 00:59:56.400 --> 00:59:59.760 align:middle line:84% But because you use different x's, but so you'll 00:59:59.760 --> 01:00:00.970 align:middle line:90% get different values. 01:00:00.970 --> 01:00:04.650 align:middle line:84% But if you decrypt, these values correspond to a ciphertext. 01:00:04.650 --> 01:00:07.570 align:middle line:84% As values, they're going to look very different. 01:00:07.570 --> 01:00:11.850 align:middle line:84% But if you decrypt, you will get the same bit, which is x1. 01:00:11.850 --> 01:00:12.480 align:middle line:90% Yeah. 01:00:12.480 --> 01:00:14.060 align:middle line:90% Good. 01:00:14.060 --> 01:00:18.848 align:middle line:84% So anyway, if you didn't follow the exact construction, 01:00:18.848 --> 01:00:19.890 align:middle line:90% it doesn't really matter. 01:00:19.890 --> 01:00:25.520 align:middle line:84% I just wanted to make sure that it was clear that you really 01:00:25.520 --> 01:00:27.290 align:middle line:90% need to do this decryption. 01:00:27.290 --> 01:00:27.902 align:middle line:90% Yeah. 01:00:27.902 --> 01:00:30.110 align:middle line:84% AUDIENCE: The reason you don't need circular security 01:00:30.110 --> 01:00:33.560 align:middle line:84% as it is for this FHE is that each of these computations 01:00:33.560 --> 01:00:37.110 align:middle line:84% is simple enough that you don't need to bootstrap. 01:00:37.110 --> 01:00:37.610 align:middle line:90% Is that-- 01:00:37.610 --> 01:00:38.527 align:middle line:90% PROFESSOR: The reason? 01:00:38.527 --> 01:00:43.250 align:middle line:84% The reason I don't need a circular security 01:00:43.250 --> 01:00:52.610 align:middle line:84% is I'm never encrypting a secret key under its public key. 01:00:52.610 --> 01:00:53.273 align:middle line:90% So sorry. 01:00:53.273 --> 01:00:55.940 align:middle line:84% AUDIENCE: I think he was asking why is it FHE that you're using, 01:00:55.940 --> 01:00:58.006 align:middle line:90% not [INAUDIBLE] unbounded. 01:00:58.006 --> 01:00:58.998 align:middle line:90% PROFESSOR: Oh! 01:00:58.998 --> 01:00:59.970 align:middle line:90% Oh! 01:00:59.970 --> 01:01:00.470 align:middle line:90% OK. 01:01:00.470 --> 01:01:00.930 align:middle line:90% OK. 01:01:00.930 --> 01:01:01.760 align:middle line:90% You're saying-- OK. 01:01:01.760 --> 01:01:02.910 align:middle line:90% Sorry, sorry. 01:01:02.910 --> 01:01:04.530 align:middle line:90% You're asking me-- OK, got it. 01:01:04.530 --> 01:01:08.090 align:middle line:84% You're saying, while in general, if we want arbitrary FHE, 01:01:08.090 --> 01:01:11.435 align:middle line:84% we need to assume circular secure LW inside it, kind of. 01:01:11.435 --> 01:01:13.310 align:middle line:84% And you're asking, do we not need to assume-- 01:01:13.310 --> 01:01:15.210 align:middle line:90% you're kind of going into the-- 01:01:15.210 --> 01:01:17.342 align:middle line:84% you're saying, do we actually need fully, fully, 01:01:17.342 --> 01:01:18.550 align:middle line:90% fully homomorphic encryption? 01:01:18.550 --> 01:01:20.310 align:middle line:84% Because if we do, then, actually, we 01:01:20.310 --> 01:01:23.280 align:middle line:84% need to rely on a circular security assumption inside, too. 01:01:23.280 --> 01:01:25.770 align:middle line:84% The answer is we because the computation 01:01:25.770 --> 01:01:28.450 align:middle line:84% is very specific and very small depth, 01:01:28.450 --> 01:01:31.820 align:middle line:84% you don't need to-- there's no-- you don't need full, full FHE. 01:01:31.820 --> 01:01:35.640 align:middle line:84% You need FHE for very bounded depth computations. 01:01:35.640 --> 01:01:37.130 align:middle line:90% Yeah. 01:01:37.130 --> 01:01:37.630 align:middle line:90% Great. 01:01:37.630 --> 01:01:39.330 align:middle line:90% Thank you. 01:01:39.330 --> 01:01:43.090 align:middle line:90% Any other questions? 01:01:43.090 --> 01:01:46.870 align:middle line:90% So let's SNARG. 01:01:46.870 --> 01:01:51.700 align:middle line:84% Well, let me just make sure I covered everything I wanted to. 01:01:51.700 --> 01:01:53.390 align:middle line:84% AUDIENCE: After three months, we SNARG. 01:01:53.390 --> 01:01:55.030 align:middle line:90% PROFESSOR: We SNARG. 01:01:55.030 --> 01:01:57.160 align:middle line:84% The last kind of two hours in class, 01:01:57.160 --> 01:01:58.285 align:middle line:90% last, we're going to SNARG. 01:01:58.285 --> 01:02:03.050 align:middle line:90% 01:02:03.050 --> 01:02:05.350 align:middle line:84% So now the SNARG is really simple. 01:02:05.350 --> 01:02:08.640 align:middle line:84% It's like as simple as one can-- like, essentially, 01:02:08.640 --> 01:02:09.470 align:middle line:90% you can do it. 01:02:09.470 --> 01:02:10.940 align:middle line:90% Done, we're done. 01:02:10.940 --> 01:02:13.930 align:middle line:90% So how do we-- 01:02:13.930 --> 01:02:14.785 align:middle line:90% we can go home. 01:02:14.785 --> 01:02:21.120 align:middle line:90% 01:02:21.120 --> 01:02:24.630 align:middle line:84% Anybody want a cookie before we SNARG? 01:02:24.630 --> 01:02:27.120 align:middle line:84% I feel like these grandmothers that kind of constantly 01:02:27.120 --> 01:02:29.350 align:middle line:90% feed you. 01:02:29.350 --> 01:02:30.200 align:middle line:90% So here's the idea. 01:02:30.200 --> 01:02:31.330 align:middle line:90% The idea is very simple. 01:02:31.330 --> 01:02:33.970 align:middle line:90% Take any-- so SNARG. 01:02:33.970 --> 01:02:42.270 align:middle line:90% 01:02:42.270 --> 01:02:45.838 align:middle line:84% So let me first say kind of the high level idea. 01:02:45.838 --> 01:02:47.380 align:middle line:84% The high level idea is the following. 01:02:47.380 --> 01:02:49.220 align:middle line:90% Here is what the prover will do. 01:02:49.220 --> 01:02:53.190 align:middle line:84% So the prover wants to convince that x is in the language. 01:02:53.190 --> 01:02:54.820 align:middle line:84% There's some verification circuit. 01:02:54.820 --> 01:02:56.400 align:middle line:90% So you have x. 01:02:56.400 --> 01:03:00.240 align:middle line:84% Let's start with-- let's take x in the language. 01:03:00.240 --> 01:03:02.490 align:middle line:90% There is some-- for any x-- 01:03:02.490 --> 01:03:09.150 align:middle line:84% it doesn't matter-- for any x, you have a circuit, C sub x. 01:03:09.150 --> 01:03:13.890 align:middle line:84% And C sub x takes a witness and outputs 0 or 1, 01:03:13.890 --> 01:03:15.757 align:middle line:84% like it's a verification circuit. 01:03:15.757 --> 01:03:17.340 align:middle line:84% You can also think of it, if you want, 01:03:17.340 --> 01:03:22.140 align:middle line:84% C as taking x and a witness, and outputs 01:03:22.140 --> 01:03:26.160 align:middle line:84% 0 if it's not a valid witness and 1 if it's a valid witness. 01:03:26.160 --> 01:03:28.612 align:middle line:84% If it's a deterministic computation, there's no witness. 01:03:28.612 --> 01:03:30.070 align:middle line:84% You just take x, and output 0 or 1. 01:03:30.070 --> 01:03:32.190 align:middle line:90% It does the computation. 01:03:32.190 --> 01:03:34.400 align:middle line:84% So when I talk about SNARG here, you 01:03:34.400 --> 01:03:36.520 align:middle line:84% can think of a SNARG of non-deterministic 01:03:36.520 --> 01:03:38.520 align:middle line:84% and a SNARG of a deterministic-- any language l. 01:03:38.520 --> 01:03:40.300 align:middle line:84% I don't even want to go too specific. 01:03:40.300 --> 01:03:43.862 align:middle line:84% But I have a language l, you know 01:03:43.862 --> 01:03:45.070 align:middle line:90% what does it mean a language? 01:03:45.070 --> 01:03:46.420 align:middle line:90% Well, there's some circuit. 01:03:46.420 --> 01:03:49.810 align:middle line:84% It takes the instance, maybe with a witness. 01:03:49.810 --> 01:03:52.110 align:middle line:84% And the circuit kind of does some checks 01:03:52.110 --> 01:03:55.740 align:middle line:84% to decide if it's valid or not valid. 01:03:55.740 --> 01:03:59.800 align:middle line:84% Now, I want to convince you I have an x. 01:03:59.800 --> 01:04:04.020 align:middle line:84% I want to give you a SNARG that this C, an x outputs 1. 01:04:04.020 --> 01:04:06.730 align:middle line:84% Either that there is a witness that outputs 1, 01:04:06.730 --> 01:04:08.200 align:middle line:90% or maybe it's deterministic. 01:04:08.200 --> 01:04:10.480 align:middle line:90% So just C of x outputs 1. 01:04:10.480 --> 01:04:12.480 align:middle line:90% Here's what I'm going to do. 01:04:12.480 --> 01:04:14.340 align:middle line:84% What I'm going to do, I'm going to compute 01:04:14.340 --> 01:04:16.380 align:middle line:90% all the wires of this circuit. 01:04:16.380 --> 01:04:18.960 align:middle line:84% I'm Include all the wires, and I'm 01:04:18.960 --> 01:04:21.040 align:middle line:84% going to give you a hash of all the wires. 01:04:21.040 --> 01:04:22.270 align:middle line:90% Now, there's a lot of wires. 01:04:22.270 --> 01:04:25.780 align:middle line:84% So it's going to be a shrinking hash. 01:04:25.780 --> 01:04:29.050 align:middle line:84% I'm going to actually use a somewhere extractable hash. 01:04:29.050 --> 01:04:32.350 align:middle line:84% So let's say we agreed on a hash key 01:04:32.350 --> 01:04:34.000 align:middle line:84% for a somewhere extractable hash. 01:04:34.000 --> 01:04:37.570 align:middle line:84% I, the prover, I'm going to compute all the wires 01:04:37.570 --> 01:04:40.720 align:middle line:90% of this verification circuit. 01:04:40.720 --> 01:04:42.970 align:middle line:84% And I'm going to give you the hash, the hash 01:04:42.970 --> 01:04:47.495 align:middle line:90% of the values of all the wires. 01:04:47.495 --> 01:04:49.420 align:middle line:84% The hash, what are you going to do with that? 01:04:49.420 --> 01:04:51.870 align:middle line:84% So the other thing I'm going to give you is I'm 01:04:51.870 --> 01:04:54.810 align:middle line:84% going to give you a BARG, a proof. 01:04:54.810 --> 01:04:56.370 align:middle line:90% A BARG of what? 01:04:56.370 --> 01:05:00.210 align:middle line:84% The BARG I'm going to give you is that every gate here 01:05:00.210 --> 01:05:01.800 align:middle line:90% is satisfied. 01:05:01.800 --> 01:05:03.910 align:middle line:90% So I committed to all the wires. 01:05:03.910 --> 01:05:05.580 align:middle line:90% I can commit to anything. 01:05:05.580 --> 01:05:07.150 align:middle line:90% I mean, I had all the wires. 01:05:07.150 --> 01:05:10.170 align:middle line:84% Now, I'm going to prove to you that for any gate, if you look 01:05:10.170 --> 01:05:15.480 align:middle line:84% at the two input wires to the gate and the output 01:05:15.480 --> 01:05:18.660 align:middle line:84% wire of the gate, they satisfy the gate. 01:05:18.660 --> 01:05:23.290 align:middle line:84% So for all-- every gate in the circuit, 01:05:23.290 --> 01:05:29.030 align:middle line:84% I'm going to prove to you that there exists an opening for this 01:05:29.030 --> 01:05:31.880 align:middle line:84% wire and an opening for this wire and for this wire, 01:05:31.880 --> 01:05:34.620 align:middle line:84% so that these openings are valid, 01:05:34.620 --> 01:05:39.000 align:middle line:84% and that the values that I open accept the-- 01:05:39.000 --> 01:05:42.960 align:middle line:90% kind of respect the gate. 01:05:42.960 --> 01:05:46.440 align:middle line:84% And I'm going to prove to you that the output-- 01:05:46.440 --> 01:05:50.622 align:middle line:84% so I said that I hashed all the wires. 01:05:50.622 --> 01:05:52.830 align:middle line:84% I'm going to argue I'm going to open the output wire. 01:05:52.830 --> 01:05:53.440 align:middle line:90% So you see? 01:05:53.440 --> 01:05:55.230 align:middle line:90% And end output is 1. 01:05:55.230 --> 01:05:56.800 align:middle line:90% So again, what am I going to do? 01:05:56.800 --> 01:06:00.760 align:middle line:84% I want to convince you that the output here is 1. 01:06:00.760 --> 01:06:03.310 align:middle line:84% I'm going to hash all the wires-- 01:06:03.310 --> 01:06:06.270 align:middle line:84% the value of all the wires in the circuit. 01:06:06.270 --> 01:06:10.090 align:middle line:84% I'm going to prove that every gate is kind of satisfied. 01:06:10.090 --> 01:06:13.180 align:middle line:84% I have an opening that kind of respects each and every gate. 01:06:13.180 --> 01:06:14.915 align:middle line:90% And the output wire is 1. 01:06:14.915 --> 01:06:17.480 align:middle line:90% 01:06:17.480 --> 01:06:18.860 align:middle line:90% That's my SNARG. 01:06:18.860 --> 01:06:19.730 align:middle line:90% Yeah. 01:06:19.730 --> 01:06:22.387 align:middle line:84% AUDIENCE: How is this different from GKR? 01:06:22.387 --> 01:06:22.970 align:middle line:90% PROFESSOR: OK. 01:06:22.970 --> 01:06:25.880 align:middle line:90% How is this different from GKR? 01:06:25.880 --> 01:06:30.180 align:middle line:84% OK, so GKR is very different in many ways. 01:06:30.180 --> 01:06:33.630 align:middle line:84% First of all, it's interactive protocol. 01:06:33.630 --> 01:06:38.600 align:middle line:84% Now, you can apply Fiat-Shamir to it, but, essentially, in GKR, 01:06:38.600 --> 01:06:40.710 align:middle line:90% you take the circuit. 01:06:40.710 --> 01:06:42.870 align:middle line:84% You compute all the wires in the circuit. 01:06:42.870 --> 01:06:45.440 align:middle line:90% But actually, I don't BARG-- 01:06:45.440 --> 01:06:47.220 align:middle line:84% say, look, all the wires are satisfied. 01:06:47.220 --> 01:06:49.637 align:middle line:84% Instead, I'm going to-- kind of we're doing an interactive 01:06:49.637 --> 01:06:51.650 align:middle line:90% process, saying, I'm going to-- 01:06:51.650 --> 01:06:53.460 align:middle line:90% I argue the output wire is 1. 01:06:53.460 --> 01:06:55.440 align:middle line:84% And then we do a little sum checker, 01:06:55.440 --> 01:06:58.680 align:middle line:84% some interactive process to reduce checking that value, 01:06:58.680 --> 01:07:01.110 align:middle line:84% to checking a value in one layer below. 01:07:01.110 --> 01:07:03.080 align:middle line:84% And then we do an interactive process 01:07:03.080 --> 01:07:07.010 align:middle line:84% to say, OK, if that was false, then 01:07:07.010 --> 01:07:11.100 align:middle line:84% the layer below needs to be false until we reach the leaves. 01:07:11.100 --> 01:07:12.620 align:middle line:84% And then you can apply Fiat-Shamir 01:07:12.620 --> 01:07:16.055 align:middle line:90% to that to make it a SNARG. 01:07:16.055 --> 01:07:17.930 align:middle line:84% Here, we're doing something very differently. 01:07:17.930 --> 01:07:19.190 align:middle line:90% We're starting with a BARG. 01:07:19.190 --> 01:07:21.880 align:middle line:84% Now, it's true that the construction you saw for BARG 01:07:21.880 --> 01:07:24.328 align:middle line:84% uses Fiat-Shamir also, but some constructions 01:07:24.328 --> 01:07:26.120 align:middle line:84% don't use Fiat-Shamir, actually, for BARGs. 01:07:26.120 --> 01:07:27.828 align:middle line:84% There are various constructions of BARGs. 01:07:27.828 --> 01:07:30.070 align:middle line:84% You saw one of them, but there are others. 01:07:30.070 --> 01:07:33.490 align:middle line:90% So we take any BARG. 01:07:33.490 --> 01:07:35.180 align:middle line:90% And there's no interaction here. 01:07:35.180 --> 01:07:36.822 align:middle line:84% Besides, maybe they're inside the BARG, 01:07:36.822 --> 01:07:39.280 align:middle line:84% but maybe the BARG doesn't have any Fiat-Shamir or anything 01:07:39.280 --> 01:07:39.830 align:middle line:90% to it. 01:07:39.830 --> 01:07:43.840 align:middle line:84% And we're saying just hash all the wires of the circuit 01:07:43.840 --> 01:07:45.620 align:middle line:84% and prove that everything is consistent. 01:07:45.620 --> 01:07:47.730 align:middle line:90% That's it. 01:07:47.730 --> 01:07:50.790 align:middle line:90% That's really what we're doing. 01:07:50.790 --> 01:07:52.270 align:middle line:90% So let me write this down. 01:07:52.270 --> 01:07:53.400 align:middle line:90% So it will be-- 01:07:53.400 --> 01:07:59.317 align:middle line:84% so my ingredients that I have for my SNARG is-- 01:07:59.317 --> 01:08:01.025 align:middle line:84% so ingredients, maybe I'll write it here. 01:08:01.025 --> 01:08:05.570 align:middle line:90% 01:08:05.570 --> 01:08:17.910 align:middle line:84% So my ingredients is a BARG, and some are extractable hash. 01:08:17.910 --> 01:08:19.479 align:middle line:90% These are my ingredients. 01:08:19.479 --> 01:08:21.210 align:middle line:84% And I'm going to show you my SNARG. 01:08:21.210 --> 01:08:25.330 align:middle line:90% So a SNARG has three algorithms. 01:08:25.330 --> 01:08:27.543 align:middle line:90% We have a gen algorithm. 01:08:27.543 --> 01:08:31.170 align:middle line:90% 01:08:31.170 --> 01:08:34.350 align:middle line:84% And here is what my gen algorithm is going to do. 01:08:34.350 --> 01:08:37.955 align:middle line:84% It's going to-- let's say the gen also has an input length. 01:08:37.955 --> 01:08:41.410 align:middle line:90% 01:08:41.410 --> 01:08:44.095 align:middle line:90% We don't need it. 01:08:44.095 --> 01:08:45.220 align:middle line:90% Here's what it's going to-- 01:08:45.220 --> 01:08:48.770 align:middle line:84% OK, let's say it has an input length. 01:08:48.770 --> 01:08:51.470 align:middle line:84% So this says, you're going to prove 01:08:51.470 --> 01:08:55.890 align:middle line:84% to me statements of length-- that the input x is of length n. 01:08:55.890 --> 01:08:57.605 align:middle line:84% So here's what we're going to do. 01:08:57.605 --> 01:08:59.620 align:middle line:84% The first thing we do is we're going 01:08:59.620 --> 01:09:13.580 align:middle line:84% to generate a hash key for gen of the somewhere 01:09:13.580 --> 01:09:15.140 align:middle line:90% extractable hash. 01:09:15.140 --> 01:09:16.939 align:middle line:84% So generate a hash key corresponding 01:09:16.939 --> 01:09:18.600 align:middle line:84% to the somewhere extractable hash. 01:09:18.600 --> 01:09:21.960 align:middle line:84% This is going to be a security parameter. 01:09:21.960 --> 01:09:24.830 align:middle line:90% n is going to be-- 01:09:24.830 --> 01:09:31.340 align:middle line:84% this is going to be the number of wires in the circuit C. 01:09:31.340 --> 01:09:35.660 align:middle line:84% This is the circuit that takes x of length n, possibly a witness, 01:09:35.660 --> 01:09:38.180 align:middle line:90% and outputs 0 or 1. 01:09:38.180 --> 01:09:41.840 align:middle line:84% So this is going to be the number of wires. 01:09:41.840 --> 01:09:42.842 align:middle line:90% And take any i. 01:09:42.842 --> 01:09:44.300 align:middle line:84% I don't know, whatever. i equals 1. 01:09:44.300 --> 01:09:46.880 align:middle line:90% Take any i in between 1 to n. 01:09:46.880 --> 01:09:47.840 align:middle line:90% It doesn't matter. 01:09:47.840 --> 01:09:51.729 align:middle line:84% Choose it arbitrarily, your favorite number. 01:09:51.729 --> 01:09:52.870 align:middle line:90% So that's first thing. 01:09:52.870 --> 01:09:56.430 align:middle line:84% And then you also generate a CRS for the BARG. 01:09:56.430 --> 01:10:01.495 align:middle line:84% So you generate a CRS for a BARG. 01:10:01.495 --> 01:10:05.260 align:middle line:90% 01:10:05.260 --> 01:10:07.810 align:middle line:90% This is for the BARG. 01:10:07.810 --> 01:10:10.540 align:middle line:90% And this will be with input 1-- 01:10:10.540 --> 01:10:12.400 align:middle line:90% with the script 1 to the lambda. 01:10:12.400 --> 01:10:15.400 align:middle line:84% K, the number of statements is like the number 01:10:15.400 --> 01:10:16.880 align:middle line:90% of gates in the circuit. 01:10:16.880 --> 01:10:23.410 align:middle line:84% So K is going to be the number of gates in C, 01:10:23.410 --> 01:10:25.297 align:middle line:84% because we're going to-- remember, 01:10:25.297 --> 01:10:27.880 align:middle line:84% we're going to say-- we're going to prove that for every gate, 01:10:27.880 --> 01:10:29.320 align:middle line:90% it's satisfied. 01:10:29.320 --> 01:10:31.197 align:middle line:84% So usually, K and N are very similar. 01:10:31.197 --> 01:10:32.780 align:middle line:84% It's like essentially the same number. 01:10:32.780 --> 01:10:35.845 align:middle line:84% But let me just be clear that this 01:10:35.845 --> 01:10:37.720 align:middle line:84% is-- we're going to have the number of gates. 01:10:37.720 --> 01:10:40.990 align:middle line:90% And the length n there-- 01:10:40.990 --> 01:10:42.350 align:middle line:90% let me call it n prime. 01:10:42.350 --> 01:10:44.260 align:middle line:90% We'll see what it is. 01:10:44.260 --> 01:10:46.490 align:middle line:84% We'll see what this n prime is in a minute. 01:10:46.490 --> 01:10:52.210 align:middle line:84% So we're going to BARG statements not of length n, 01:10:52.210 --> 01:10:54.050 align:middle line:84% but of a different length, n prime. 01:10:54.050 --> 01:10:55.480 align:middle line:90% We're going to see what that is. 01:10:55.480 --> 01:10:57.870 align:middle line:90% But the output is just a-- 01:10:57.870 --> 01:11:01.340 align:middle line:90% 01:11:01.340 --> 01:11:03.590 align:middle line:84% It was going to be called the CRS BARG. 01:11:03.590 --> 01:11:08.190 align:middle line:84% So you output CRS, which is equal to hash key and CRS BARG. 01:11:08.190 --> 01:11:16.850 align:middle line:90% 01:11:16.850 --> 01:11:18.020 align:middle line:90% So that's how you generate. 01:11:18.020 --> 01:11:21.100 align:middle line:84% So the key generation, the CRS has a CRS 01:11:21.100 --> 01:11:24.220 align:middle line:90% for the BARG and a hash key. 01:11:24.220 --> 01:11:25.975 align:middle line:90% Now, we're going to-- 01:11:25.975 --> 01:11:28.990 align:middle line:90% 01:11:28.990 --> 01:11:30.610 align:middle line:90% what does the prover do? 01:11:30.610 --> 01:11:33.580 align:middle line:90% So the prover gets as input x. 01:11:33.580 --> 01:11:36.550 align:middle line:90% Maybe a witness, if it's an NP. 01:11:36.550 --> 01:11:38.680 align:middle line:90% Maybe there is no witness. 01:11:38.680 --> 01:11:41.090 align:middle line:84% Let me say, generally, with a witness. 01:11:41.090 --> 01:11:43.900 align:middle line:84% But actually, the BARB we're going to construct today 01:11:43.900 --> 01:11:45.800 align:middle line:84% is going to be for deterministic languages. 01:11:45.800 --> 01:11:48.130 align:middle line:84% But let me write it also, because I'm going to show you 01:11:48.130 --> 01:11:50.440 align:middle line:90% a general framework. 01:11:50.440 --> 01:11:57.370 align:middle line:84% So P is going to get a CRS, an x, and maybe a witness 01:11:57.370 --> 01:11:59.440 align:middle line:90% if it's an NP. 01:11:59.440 --> 01:12:01.810 align:middle line:84% And it needs to generate a SNARG. 01:12:01.810 --> 01:12:04.390 align:middle line:90% So what does it do? 01:12:04.390 --> 01:12:09.630 align:middle line:84% Compute all the wires in the circuit. 01:12:09.630 --> 01:12:10.358 align:middle line:90% So x is fixed. 01:12:10.358 --> 01:12:12.650 align:middle line:84% Let's think of x as, like, that's not part of the wires 01:12:12.650 --> 01:12:13.710 align:middle line:90% because it's fixed. 01:12:13.710 --> 01:12:20.870 align:middle line:84% But let's compute all the w1 up to wn, which 01:12:20.870 --> 01:12:22.890 align:middle line:90% is the wires of the circuit. 01:12:22.890 --> 01:12:26.820 align:middle line:84% You can think of the first n as the actual witness. 01:12:26.820 --> 01:12:29.770 align:middle line:84% Let's say if you have a witness and it's of length m, 01:12:29.770 --> 01:12:33.180 align:middle line:84% w1 wm is the witness, but then the rest are the wires. 01:12:33.180 --> 01:12:35.780 align:middle line:84% So I'm thinking the wires include the witness 01:12:35.780 --> 01:12:36.870 align:middle line:90% and everything above. 01:12:36.870 --> 01:12:39.710 align:middle line:84% And if there is no witness, then it doesn't include a witness. 01:12:39.710 --> 01:12:41.340 align:middle line:90% So I compute. 01:12:41.340 --> 01:12:51.160 align:middle line:84% These are all the wires in C, except x, 01:12:51.160 --> 01:12:52.792 align:middle line:84% except the input wires corresponding-- 01:12:52.792 --> 01:12:54.250 align:middle line:84% the input wires corresponding to x, 01:12:54.250 --> 01:12:56.083 align:middle line:84% because that's-- kind of we know what it is. 01:12:56.083 --> 01:12:58.660 align:middle line:90% The verifier knows it. 01:12:58.660 --> 01:13:00.400 align:middle line:90% So you compute all the wires. 01:13:00.400 --> 01:13:05.170 align:middle line:84% And then you compute the hash of-- 01:13:05.170 --> 01:13:12.610 align:middle line:84% you compute z, which is a hash, the eval with hash key of w1 up 01:13:12.610 --> 01:13:14.080 align:middle line:90% to wn. 01:13:14.080 --> 01:13:16.870 align:middle line:84% So you hash all these wires together. 01:13:16.870 --> 01:13:18.700 align:middle line:84% So the verifier computed all the wires 01:13:18.700 --> 01:13:22.150 align:middle line:84% of the circuit, hashed all the wires. 01:13:22.150 --> 01:13:25.920 align:middle line:90% 01:13:25.920 --> 01:13:27.455 align:middle line:90% Actually, let me just say-- 01:13:27.455 --> 01:13:27.955 align:middle line:90% sorry. 01:13:27.955 --> 01:13:32.590 align:middle line:90% 01:13:32.590 --> 01:13:36.370 align:middle line:84% When you generate a key, I said use a somewhere 01:13:36.370 --> 01:13:37.340 align:middle line:90% extractable hash. 01:13:37.340 --> 01:13:38.840 align:middle line:90% Yes, exactly. 01:13:38.840 --> 01:13:41.840 align:middle line:84% But you don't need to just use one index. 01:13:41.840 --> 01:13:46.600 align:middle line:84% So let's use it with a few index, il. 01:13:46.600 --> 01:13:49.280 align:middle line:90% Now you can ask, what is l? 01:13:49.280 --> 01:13:49.980 align:middle line:90% We'll see. 01:13:49.980 --> 01:13:51.830 align:middle line:90% You can think of it as-- 01:13:51.830 --> 01:13:54.140 align:middle line:84% a few l's, you can think of polylog l. 01:13:54.140 --> 01:13:56.840 align:middle line:84% The bigger the l is, the less succinct 01:13:56.840 --> 01:13:58.070 align:middle line:90% the SNARG is going to be. 01:13:58.070 --> 01:14:03.080 align:middle line:84% So the SNARG is going to grow with l because the hash 01:14:03.080 --> 01:14:05.090 align:middle line:84% key grows with L. It's like L hash keys, 01:14:05.090 --> 01:14:07.520 align:middle line:84% essentially, because we're repeating. 01:14:07.520 --> 01:14:10.706 align:middle line:84% So here I'm going to be binding on l locations. 01:14:10.706 --> 01:14:13.280 align:middle line:90% 01:14:13.280 --> 01:14:17.000 align:middle line:84% The hash value grows with l, because you're computing, 01:14:17.000 --> 01:14:19.490 align:middle line:90% essentially, l hash values. 01:14:19.490 --> 01:14:24.588 align:middle line:84% So the bigger l is, in some sense, the more secure 01:14:24.588 --> 01:14:25.380 align:middle line:90% we're going to get. 01:14:25.380 --> 01:14:26.270 align:middle line:90% We'll see. 01:14:26.270 --> 01:14:28.990 align:middle line:84% But the more non-succinct it's going to be. 01:14:28.990 --> 01:14:31.140 align:middle line:84% So l now is going to be a parameter. 01:14:31.140 --> 01:14:32.850 align:middle line:84% And when we talk about the analysis, 01:14:32.850 --> 01:14:34.060 align:middle line:90% we'll see which l we want. 01:14:34.060 --> 01:14:34.730 align:middle line:90% Yeah. 01:14:34.730 --> 01:14:37.313 align:middle line:84% AUDIENCE: Is there any hope for getting a sublinear dependence 01:14:37.313 --> 01:14:38.930 align:middle line:84% on l, like, any other construction 01:14:38.930 --> 01:14:40.830 align:middle line:84% instead of the direct product construction? 01:14:40.830 --> 01:14:44.210 align:middle line:84% PROFESSOR: So in V, there's no way 01:14:44.210 --> 01:14:47.700 align:middle line:84% to get sublinear in l, because you need to extract. 01:14:47.700 --> 01:14:50.460 align:middle line:84% It's like there-- it must have information. 01:14:50.460 --> 01:14:53.270 align:middle line:90% So in v, there's no way to have. 01:14:53.270 --> 01:14:56.510 align:middle line:84% In the hash key, on the other hand-- 01:14:56.510 --> 01:14:59.330 align:middle line:90% 01:14:59.330 --> 01:15:00.000 align:middle line:90% OK. 01:15:00.000 --> 01:15:05.450 align:middle line:84% If the i, i1 up to il, can be shrunk somehow, 01:15:05.450 --> 01:15:08.840 align:middle line:84% if there is a succinct description of i1 to il-- 01:15:08.840 --> 01:15:11.180 align:middle line:84% for example, in the case of a witness, 01:15:11.180 --> 01:15:14.060 align:middle line:84% I want to be extractable on witness i. 01:15:14.060 --> 01:15:16.490 align:middle line:84% These are consecutive locations, so I 01:15:16.490 --> 01:15:19.580 align:middle line:84% don't need to write location i, i plus 1, i plus 2. 01:15:19.580 --> 01:15:21.420 align:middle line:84% You can just say i, and go from i10. 01:15:21.420 --> 01:15:22.940 align:middle line:84% There's a very succinct description. 01:15:22.940 --> 01:15:25.680 align:middle line:84% In the case where there's a description, 01:15:25.680 --> 01:15:29.290 align:middle line:84% you can hope to get the hash key smaller. 01:15:29.290 --> 01:15:31.510 align:middle line:84% And we do know how to get the hash key smaller. 01:15:31.510 --> 01:15:36.070 align:middle line:84% But in general, for the v value, there's no way-- information, 01:15:36.070 --> 01:15:37.640 align:middle line:90% theoretically. 01:15:37.640 --> 01:15:38.265 align:middle line:90% Great question. 01:15:38.265 --> 01:15:43.490 align:middle line:90% 01:15:43.490 --> 01:15:45.640 align:middle line:84% So you compute the hash value of all the wires, 01:15:45.640 --> 01:15:46.660 align:middle line:90% and then you add a BARG. 01:15:46.660 --> 01:15:54.690 align:middle line:84% So the last thing you do is you compute the P BARG. 01:15:54.690 --> 01:15:57.780 align:middle line:90% You take the BARG prover. 01:15:57.780 --> 01:15:59.830 align:middle line:90% And here's our BARG prover. 01:15:59.830 --> 01:16:02.165 align:middle line:90% You give it CRS of BARG. 01:16:02.165 --> 01:16:05.140 align:middle line:90% 01:16:05.140 --> 01:16:07.650 align:middle line:90% And you have x's and witnesses. 01:16:07.650 --> 01:16:10.060 align:middle line:84% Now, what are the x's and the witnesses? 01:16:10.060 --> 01:16:11.350 align:middle line:90% I want to use-- 01:16:11.350 --> 01:16:13.180 align:middle line:84% I want to argue I'm going to generate 01:16:13.180 --> 01:16:16.690 align:middle line:84% a bunch of x's and witnesses and generate a proof. 01:16:16.690 --> 01:16:18.790 align:middle line:90% So what is it that I'm-- 01:16:18.790 --> 01:16:25.080 align:middle line:84% so I'm going to give you x1 star xk star and w1 star. 01:16:25.080 --> 01:16:26.830 align:middle line:84% I'll tell you what these are in a second-- 01:16:26.830 --> 01:16:28.110 align:middle line:90% wk star. 01:16:28.110 --> 01:16:29.840 align:middle line:90% So this is going to be pi. 01:16:29.840 --> 01:16:39.460 align:middle line:84% This is going to be compute pi BARG. 01:16:39.460 --> 01:16:41.720 align:middle line:90% So you BARG k statements. 01:16:41.720 --> 01:16:43.090 align:middle line:90% But what are these statements? 01:16:43.090 --> 01:16:48.100 align:middle line:84% So let me just tell you what these and these are. 01:16:48.100 --> 01:16:56.820 align:middle line:90% So x star j is-- 01:16:56.820 --> 01:17:02.685 align:middle line:84% essentially, it's going to be hash key value nj. 01:17:02.685 --> 01:17:05.760 align:middle line:90% 01:17:05.760 --> 01:17:07.880 align:middle line:90% That's x. 01:17:07.880 --> 01:17:14.090 align:middle line:84% So what I'm going to prove, that for each gate j, 01:17:14.090 --> 01:17:18.020 align:middle line:84% I have an opening to the input wires of the gate 01:17:18.020 --> 01:17:20.600 align:middle line:84% and the upper wire of the gate with-- 01:17:20.600 --> 01:17:25.570 align:middle line:84% I have an opening with respect to v that satisfies the gate. 01:17:25.570 --> 01:17:29.100 align:middle line:84% So the xj is going to be-- well, I have the hash key. 01:17:29.100 --> 01:17:33.720 align:middle line:84% I have the hash value and gate j. 01:17:33.720 --> 01:17:40.180 align:middle line:84% And the witness for gate j is going to be opening. 01:17:40.180 --> 01:17:45.930 align:middle line:84% So I'm going to have a bit, like a left child, 01:17:45.930 --> 01:17:50.020 align:middle line:90% right child, output child-- 01:17:50.020 --> 01:17:53.380 align:middle line:90% not child-- output, the parent. 01:17:53.380 --> 01:17:58.960 align:middle line:84% So left child, right child, and parent of the gate opening, 01:17:58.960 --> 01:18:03.390 align:middle line:84% rho of left child, rho of right child, rho of the output. 01:18:03.390 --> 01:18:06.710 align:middle line:90% 01:18:06.710 --> 01:18:08.300 align:middle line:90% That's going to be a witness. 01:18:08.300 --> 01:18:10.590 align:middle line:90% And it's a valid witness. 01:18:10.590 --> 01:18:20.840 align:middle line:84% If B0 rho 0 are valid opening of the left child of kj. 01:18:20.840 --> 01:18:27.440 align:middle line:84% b1 rho 1 are a valid opening of the right child of kj. 01:18:27.440 --> 01:18:30.440 align:middle line:84% b out and rho out are valid openings 01:18:30.440 --> 01:18:32.360 align:middle line:90% of the output wire of kj. 01:18:32.360 --> 01:18:36.200 align:middle line:90% And these satisfy the gate. 01:18:36.200 --> 01:18:42.500 align:middle line:84% So if it's an AND gate, this and this is this. 01:18:42.500 --> 01:18:47.090 align:middle line:84% That's what-- that's going to-- so a valid witness is a six 01:18:47.090 --> 01:18:52.010 align:middle line:84% tuple like this that all these openings are accepted, 01:18:52.010 --> 01:18:55.570 align:middle line:90% and these bits satisfy the gate. 01:18:55.570 --> 01:18:58.780 align:middle line:84% And our valid opening with respect to which wires, 01:18:58.780 --> 01:19:00.910 align:middle line:84% the wires that I've defined by the gate. 01:19:00.910 --> 01:19:04.360 align:middle line:84% So think of it, we have this circuit C. 01:19:04.360 --> 01:19:07.040 align:middle line:90% The gates are kind of numbered. 01:19:07.040 --> 01:19:10.330 align:middle line:84% And for any gates j, we know there's-- we know the number 01:19:10.330 --> 01:19:14.378 align:middle line:84% of the input and output wire, because this is uniform. 01:19:14.378 --> 01:19:15.920 align:middle line:84% Everything of the circuit is uniform. 01:19:15.920 --> 01:19:19.360 align:middle line:84% So for every gate J, it corresponds to-- 01:19:19.360 --> 01:19:24.380 align:middle line:84% I know i, wire i, wire j, and wire k. 01:19:24.380 --> 01:19:26.800 align:middle line:84% And so these openings should be with respect 01:19:26.800 --> 01:19:28.938 align:middle line:90% to wire i, wire j, and wire k. 01:19:28.938 --> 01:19:31.230 align:middle line:84% AUDIENCE: Do you use the same hash key for all of them? 01:19:31.230 --> 01:19:32.938 align:middle line:84% PROFESSOR: Same hash key for all of them. 01:19:32.938 --> 01:19:34.540 align:middle line:84% Yeah, because I used one hash key. 01:19:34.540 --> 01:19:37.870 align:middle line:84% I mean, one hash key that's binding on l locations. 01:19:37.870 --> 01:19:41.280 align:middle line:84% But I'm now I'm thinking just one hash key that's binding. 01:19:41.280 --> 01:19:45.610 align:middle line:84% How I construct it, we'll abstract that for now. 01:19:45.610 --> 01:19:48.580 align:middle line:84% But yeah, I have one hash key that's binding on l locations. 01:19:48.580 --> 01:19:51.947 align:middle line:84% I hash all the values of the values 01:19:51.947 --> 01:19:54.280 align:middle line:84% of all the wires with respect to this specific hash key. 01:19:54.280 --> 01:19:58.710 align:middle line:84% And then I add a BARG for any gate j 01:19:58.710 --> 01:20:02.580 align:middle line:84% that I have an opening for the input, the two input 01:20:02.580 --> 01:20:10.540 align:middle line:84% children, the output wire of gate j that satisfy the gate. 01:20:10.540 --> 01:20:11.220 align:middle line:90% Yeah. 01:20:11.220 --> 01:20:13.178 align:middle line:84% AUDIENCE: So the only difference between the xj 01:20:13.178 --> 01:20:14.410 align:middle line:90% is the index j itself. 01:20:14.410 --> 01:20:16.963 align:middle line:84% So it's like, what are the index [INAUDIBLE] things? 01:20:16.963 --> 01:20:18.130 align:middle line:90% PROFESSOR: Yeah, yeah, yeah. 01:20:18.130 --> 01:20:18.600 align:middle line:90% Good, good, good. 01:20:18.600 --> 01:20:20.020 align:middle line:84% So you're saying, where's j here? 01:20:20.020 --> 01:20:22.110 align:middle line:90% Where's j? 01:20:22.110 --> 01:20:23.038 align:middle line:90% You're saying-- 01:20:23.038 --> 01:20:23.580 align:middle line:90% AUDIENCE: No. 01:20:23.580 --> 01:20:26.580 align:middle line:90% More like x, j star, and xj-- 01:20:26.580 --> 01:20:28.170 align:middle line:84% PROFESSOR: The only difference is j. 01:20:28.170 --> 01:20:30.250 align:middle line:84% So this is an index kind of language. 01:20:30.250 --> 01:20:32.110 align:middle line:90% This note, this is kind of-- 01:20:32.110 --> 01:20:35.530 align:middle line:84% it's the x1 and x1 star, x2 star, 01:20:35.530 --> 01:20:39.640 align:middle line:84% are the same hash key. vk1, 2, 3, 4 up to k. 01:20:39.640 --> 01:20:41.510 align:middle line:84% So it's kind of an index language. 01:20:41.510 --> 01:20:43.810 align:middle line:84% We're going to get back to it when-- 01:20:43.810 --> 01:20:46.585 align:middle line:84% because we want the efficiency of v. So we'll talk about that. 01:20:46.585 --> 01:20:47.085 align:middle line:90% But yes. 01:20:47.085 --> 01:20:50.260 align:middle line:90% 01:20:50.260 --> 01:20:53.295 align:middle line:84% Any question about the prover here? 01:20:53.295 --> 01:20:56.940 align:middle line:90% 01:20:56.940 --> 01:21:03.030 align:middle line:84% So now the verifier, what the verifier does is-- 01:21:03.030 --> 01:21:06.711 align:middle line:84% so now let's write the verifier somewhere. 01:21:06.711 --> 01:21:07.768 align:middle line:90% Oh, that's sad. 01:21:07.768 --> 01:21:08.685 align:middle line:90% I wanted to keep this. 01:21:08.685 --> 01:21:11.880 align:middle line:90% 01:21:11.880 --> 01:21:17.310 align:middle line:84% If you don't mind, we'll write the verifier here. 01:21:17.310 --> 01:21:19.230 align:middle line:90% So what does the verifier do? 01:21:19.230 --> 01:21:25.885 align:middle line:84% V takes as input a CRS, which is a hash key and CRS BARG. 01:21:25.885 --> 01:21:29.660 align:middle line:90% 01:21:29.660 --> 01:21:31.220 align:middle line:90% That's the CRS. 01:21:31.220 --> 01:21:35.460 align:middle line:84% And it takes an instant X and a proof. 01:21:35.460 --> 01:21:37.080 align:middle line:90% What is the proof? 01:21:37.080 --> 01:21:47.100 align:middle line:84% A proof is a value and a BARG, a hash value and a BARG. 01:21:47.100 --> 01:21:51.720 align:middle line:84% So the verifier, he gets the CRS, which is of this form. 01:21:51.720 --> 01:21:54.130 align:middle line:90% He gets an input x. 01:21:54.130 --> 01:21:55.900 align:middle line:90% And he gets a SNARG. 01:21:55.900 --> 01:21:58.610 align:middle line:84% A SNARG is-- oh, did I say what it outputs? 01:21:58.610 --> 01:21:59.420 align:middle line:90% Sorry. 01:21:59.420 --> 01:21:59.920 align:middle line:90% Sorry. 01:21:59.920 --> 01:22:01.043 align:middle line:90% Compute, output. 01:22:01.043 --> 01:22:05.880 align:middle line:90% 01:22:05.880 --> 01:22:07.240 align:middle line:90% v in pi BARG. 01:22:07.240 --> 01:22:13.840 align:middle line:90% 01:22:13.840 --> 01:22:24.930 align:middle line:84% So now he takes the SNARG, which is a hash and a BARG. 01:22:24.930 --> 01:22:29.640 align:middle line:84% And it just outputs 1, an output. 01:22:29.640 --> 01:22:32.690 align:middle line:90% 01:22:32.690 --> 01:22:35.810 align:middle line:84% The output of v BARG, he accepts if and only 01:22:35.810 --> 01:22:38.670 align:middle line:90% if the BARG is accepting. 01:22:38.670 --> 01:22:47.480 align:middle line:84% What do we mean the BARG-- v BARG takes CRS BARG and x1 star 01:22:47.480 --> 01:22:51.200 align:middle line:84% up to xk star, which are essentially an index language 01:22:51.200 --> 01:22:55.740 align:middle line:90% corresponding to hk, v, and j. 01:22:55.740 --> 01:23:02.130 align:middle line:90% 01:23:02.130 --> 01:23:07.240 align:middle line:84% So it accepts if and only if the BARG is accepted. 01:23:07.240 --> 01:23:11.040 align:middle line:90% 01:23:11.040 --> 01:23:12.100 align:middle line:90% That's the SNARG. 01:23:12.100 --> 01:23:21.380 align:middle line:90% 01:23:21.380 --> 01:23:25.490 align:middle line:84% One thing I-- so again, you generate a-- 01:23:25.490 --> 01:23:27.140 align:middle line:90% again, what is the SNARG? 01:23:27.140 --> 01:23:30.800 align:middle line:84% In the CRS generation, you generate a hash key 01:23:30.800 --> 01:23:32.360 align:middle line:84% for the somewhere extractable hash, 01:23:32.360 --> 01:23:34.580 align:middle line:84% and you generate a CRS for the BARG. 01:23:34.580 --> 01:23:38.490 align:middle line:84% The prover computes the values of all the wires 01:23:38.490 --> 01:23:42.000 align:middle line:84% in the circuits, hashes it using the hash key to generate 01:23:42.000 --> 01:23:45.930 align:middle line:84% a value, a hash value V, and then he proves-- 01:23:45.930 --> 01:23:49.220 align:middle line:84% it gives a BARG that all the gates are satisfied. 01:23:49.220 --> 01:23:52.050 align:middle line:84% Namely, for every gate he has an opening valid 01:23:52.050 --> 01:23:54.990 align:middle line:84% that's satisfied-- that respects the gate. 01:23:54.990 --> 01:23:56.605 align:middle line:90% And the output gate is 1. 01:23:56.605 --> 01:23:57.480 align:middle line:90% That's another thing. 01:23:57.480 --> 01:23:59.010 align:middle line:84% He also proves that-- the BARG also proves 01:23:59.010 --> 01:24:00.093 align:middle line:90% that the output gate is 1. 01:24:00.093 --> 01:24:03.570 align:middle line:84% So for the output gate, you prove it respects, namely-- 01:24:03.570 --> 01:24:04.340 align:middle line:90% you prove it's 1. 01:24:04.340 --> 01:24:07.740 align:middle line:90% 01:24:07.740 --> 01:24:08.320 align:middle line:90% Good. 01:24:08.320 --> 01:24:09.960 align:middle line:84% So that's-- and how do you verify? 01:24:09.960 --> 01:24:12.360 align:middle line:90% You just verify the BARG. 01:24:12.360 --> 01:24:15.210 align:middle line:84% Now, here's one important thing to note. 01:24:15.210 --> 01:24:20.205 align:middle line:84% This v BARG takes as input the BARG of length k. 01:24:20.205 --> 01:24:22.890 align:middle line:84% k is like the number of wires in the circuit. 01:24:22.890 --> 01:24:26.460 align:middle line:84% We do not want the verifier to run in time k. 01:24:26.460 --> 01:24:28.480 align:middle line:84% That would be the size of the circuit. 01:24:28.480 --> 01:24:32.760 align:middle line:84% No, we want the verifier to be very efficient. 01:24:32.760 --> 01:24:34.350 align:middle line:84% But that's OK, because he actually 01:24:34.350 --> 01:24:38.730 align:middle line:84% doesn't need to run in time k, because, actually, it's what's 01:24:38.730 --> 01:24:40.000 align:middle line:90% called an index language. 01:24:40.000 --> 01:24:45.580 align:middle line:84% Namely, x1 up to xk star, essentially, 01:24:45.580 --> 01:24:51.600 align:middle line:84% it's like an index on hash k and v. So you can generate them. 01:24:51.600 --> 01:24:56.640 align:middle line:84% You can express them very succinctly. 01:24:56.640 --> 01:25:01.200 align:middle line:84% You can express them by hash key V, and all the index 01:25:01.200 --> 01:25:02.520 align:middle line:90% between 1 and k. 01:25:02.520 --> 01:25:03.430 align:middle line:90% That's it. 01:25:03.430 --> 01:25:06.010 align:middle line:84% So because they have a succinct representation, 01:25:06.010 --> 01:25:09.630 align:middle line:84% the runtime of the verifier only grows with hash key nv, 01:25:09.630 --> 01:25:10.930 align:middle line:90% polynomial with hash key nv. 01:25:10.930 --> 01:25:13.260 align:middle line:90% He does not need to grow with k. 01:25:13.260 --> 01:25:18.097 align:middle line:84% That's kind of the efficiency property of index languages. 01:25:18.097 --> 01:25:19.180 align:middle line:90% And that's very important. 01:25:19.180 --> 01:25:23.570 align:middle line:84% Without it, we can't use it for the SNARG. 01:25:23.570 --> 01:25:27.200 align:middle line:84% So in terms of efficiency, if the BARG has good efficiency, 01:25:27.200 --> 01:25:30.980 align:middle line:84% let's say the dependence is polylog on k, 01:25:30.980 --> 01:25:37.040 align:middle line:84% then the v is going to be-- so what is the-- 01:25:37.040 --> 01:25:41.210 align:middle line:84% the SNARG grows with v and with a BARG proof. 01:25:41.210 --> 01:25:42.740 align:middle line:90% The BARG proof is very-- 01:25:42.740 --> 01:25:45.420 align:middle line:84% it grows polylogarithmically with k. 01:25:45.420 --> 01:25:47.210 align:middle line:84% It's like poly log the circuit size. 01:25:47.210 --> 01:25:49.040 align:middle line:90% It's very efficient. 01:25:49.040 --> 01:25:54.320 align:middle line:84% v grows with the number of indices we're binding on. 01:25:54.320 --> 01:25:56.210 align:middle line:90% So it grows with l. 01:25:56.210 --> 01:25:57.600 align:middle line:90% So it grows with l. 01:25:57.600 --> 01:25:58.850 align:middle line:90% We'll try to minimize l. 01:25:58.850 --> 01:26:02.420 align:middle line:84% We ideally want l to be polylog k. 01:26:02.420 --> 01:26:03.690 align:middle line:90% So that's what we want. 01:26:03.690 --> 01:26:05.210 align:middle line:90% We'll see what we get. 01:26:05.210 --> 01:26:07.310 align:middle line:84% But ideally, this should be polylog k. 01:26:07.310 --> 01:26:11.090 align:middle line:84% And the runtime of the verifier, because it's an index language, 01:26:11.090 --> 01:26:16.730 align:middle line:84% is also going to be polylog k, assuming a-- 01:26:16.730 --> 01:26:18.718 align:middle line:90% sorry-- and he needs to-- 01:26:18.718 --> 01:26:22.580 align:middle line:90% 01:26:22.580 --> 01:26:24.740 align:middle line:84% he does run in time x, because he also 01:26:24.740 --> 01:26:31.430 align:middle line:84% needs to check this pi BARG is pi BARG comma of x, because when 01:26:31.430 --> 01:26:36.590 align:middle line:84% you check the validity that each gate is satisfied, 01:26:36.590 --> 01:26:40.350 align:middle line:84% the gates in layer 1 depend on x. 01:26:40.350 --> 01:26:46.010 align:middle line:84% So the gates in layer 1, the input wires are x, xi, xj. 01:26:46.010 --> 01:26:47.580 align:middle line:90% So the BARG needs to know x. 01:26:47.580 --> 01:26:49.350 align:middle line:84% The verifier, of course, needs to know x. 01:26:49.350 --> 01:26:50.922 align:middle line:90% But that's it. 01:26:50.922 --> 01:26:52.380 align:middle line:84% So he doesn't need to run in time-- 01:26:52.380 --> 01:26:53.280 align:middle line:90% linear in x. 01:26:53.280 --> 01:26:55.800 align:middle line:84% But the BARG itself is very short. 01:26:55.800 --> 01:26:57.600 align:middle line:90% So this log is very short. 01:26:57.600 --> 01:26:59.970 align:middle line:84% The verifier, of course, needs to run time x. 01:26:59.970 --> 01:27:02.245 align:middle line:84% It needs to read the input, but that's it. 01:27:02.245 --> 01:27:05.330 align:middle line:90% 01:27:05.330 --> 01:27:09.980 align:middle line:90% So any questions? 01:27:09.980 --> 01:27:14.463 align:middle line:84% So let's take a break, a cookie break, a fun break. 01:27:14.463 --> 01:27:16.130 align:middle line:84% And let's start, again, like 10 minutes, 01:27:16.130 --> 01:27:18.090 align:middle line:84% and then we'll talk about the analysis and when-- 01:27:18.090 --> 01:27:19.470 align:middle line:84% but this is all-- but that's done. 01:27:19.470 --> 01:27:20.845 align:middle line:84% We're done with the construction. 01:27:20.845 --> 01:27:21.740 align:middle line:90% This is your SNARG. 01:27:21.740 --> 01:27:23.310 align:middle line:90% We built up to it. 01:27:23.310 --> 01:27:23.940 align:middle line:90% Here it is. 01:27:23.940 --> 01:27:27.500 align:middle line:84% And then we'll analyze it after the break. 01:27:27.500 --> 01:27:28.000 align:middle line:90%