WEBVTT 00:00:00.000 --> 00:00:01.980 align:middle line:90% [SQUEAKING] 00:00:01.980 --> 00:00:04.455 align:middle line:90% [RUSTLING] 00:00:04.455 --> 00:00:06.930 align:middle line:90% [CLICKING] 00:00:06.930 --> 00:00:13.190 align:middle line:90% 00:00:13.190 --> 00:00:15.590 align:middle line:84% ZHENGZHONG JIN: So here, so from this claim 00:00:15.590 --> 00:00:18.150 align:middle line:84% we can show this is in this relation r. 00:00:18.150 --> 00:00:21.155 align:middle line:84% So in fact, we also need a CI hash for this relation r. 00:00:21.155 --> 00:00:23.660 align:middle line:90% 00:00:23.660 --> 00:00:27.140 align:middle line:84% So in this contraction, we need a CI hash contraction 00:00:27.140 --> 00:00:29.220 align:middle line:90% for this relation r. 00:00:29.220 --> 00:00:30.900 align:middle line:90% So this follows from the-- 00:00:30.900 --> 00:00:34.630 align:middle line:84% so for this kind of CI hash, it follows from the work. 00:00:34.630 --> 00:00:37.190 align:middle line:90% 00:00:37.190 --> 00:00:42.770 align:middle line:84% So it almost can handle all of the sparse relation 00:00:42.770 --> 00:00:44.610 align:middle line:90% up to some parallel repetition. 00:00:44.610 --> 00:00:47.285 align:middle line:84% So I will not go into the detail of this work. 00:00:47.285 --> 00:00:49.410 align:middle line:84% So if you are interested, you can read it yourself. 00:00:49.410 --> 00:00:51.470 align:middle line:90% So this is the work-- 00:00:51.470 --> 00:00:55.130 align:middle line:84% so it's a CI hash for efficiently verifiable product 00:00:55.130 --> 00:00:56.420 align:middle line:90% relation. 00:00:56.420 --> 00:00:59.530 align:middle line:90% It's a beautiful work by-- 00:00:59.530 --> 00:01:02.680 align:middle line:90% so this is the [INAUDIBLE]. 00:01:02.680 --> 00:01:06.710 align:middle line:90% 00:01:06.710 --> 00:01:07.210 align:middle line:90% OK. 00:01:07.210 --> 00:01:15.490 align:middle line:90% 00:01:15.490 --> 00:01:16.010 align:middle line:90% OK. 00:01:16.010 --> 00:01:23.660 align:middle line:84% So finally-- so let me ask a question. 00:01:23.660 --> 00:01:24.160 align:middle line:90% OK. 00:01:24.160 --> 00:01:24.757 align:middle line:90% Yeah? 00:01:24.757 --> 00:01:26.590 align:middle line:84% AUDIENCE: Could you say again, why we need-- 00:01:26.590 --> 00:01:30.617 align:middle line:84% like, why the CIH we saw in last week's class isn't good enough? 00:01:30.617 --> 00:01:31.700 align:middle line:90% ZHENGZHONG JIN: Oh, right. 00:01:31.700 --> 00:01:32.390 align:middle line:90% Good question. 00:01:32.390 --> 00:01:36.260 align:middle line:84% So last week, the CI hash you saw is for searchable relation. 00:01:36.260 --> 00:01:39.020 align:middle line:90% So that means the relation-- 00:01:39.020 --> 00:01:42.460 align:middle line:90% so the relation here. 00:01:42.460 --> 00:01:44.820 align:middle line:90% So the CI hash relation here. 00:01:44.820 --> 00:01:54.640 align:middle line:90% 00:01:54.640 --> 00:01:55.150 align:middle line:90% Right. 00:01:55.150 --> 00:01:58.130 align:middle line:84% So the relation here need to satisfy the searchable property. 00:01:58.130 --> 00:02:02.790 align:middle line:84% So it means-- so this beta-- so for any fixed alpha, 00:02:02.790 --> 00:02:08.490 align:middle line:84% there exists a unique beta such that this alpha beta is 00:02:08.490 --> 00:02:10.360 align:middle line:90% in this relation r. 00:02:10.360 --> 00:02:13.620 align:middle line:84% And moreover, there is an efficient algorithm, 00:02:13.620 --> 00:02:15.690 align:middle line:84% some efficient algorithm f such that it 00:02:15.690 --> 00:02:18.570 align:middle line:84% can take this alpha and the output, such as beta. 00:02:18.570 --> 00:02:23.310 align:middle line:84% So that's a efficiently searchable mean. 00:02:23.310 --> 00:02:26.130 align:middle line:84% So here, it's possible that for a fixed alpha 00:02:26.130 --> 00:02:32.530 align:middle line:84% there might be multiple beta that can satisfy this relation. 00:02:32.530 --> 00:02:36.750 align:middle line:84% Because for a fixed PCP, there might be multiple queries that 00:02:36.750 --> 00:02:39.540 align:middle line:90% can make the PCP be accepted. 00:02:39.540 --> 00:02:40.380 align:middle line:90% Yes. 00:02:40.380 --> 00:02:41.230 align:middle line:90% Good question. 00:02:41.230 --> 00:02:42.855 align:middle line:90% Yeah. 00:02:42.855 --> 00:02:49.620 align:middle line:84% So what-- HR shows that if the sparse relation has an efficient 00:02:49.620 --> 00:02:53.250 align:middle line:84% wildfire algorithm then most of the-- 00:02:53.250 --> 00:02:55.800 align:middle line:84% then you can build a CI hash for them 00:02:55.800 --> 00:02:58.000 align:middle line:90% up to some parallel repetition. 00:02:58.000 --> 00:02:59.390 align:middle line:90% Roughly speaking, it's a-- 00:02:59.390 --> 00:02:59.890 align:middle line:90% yeah. 00:02:59.890 --> 00:03:04.790 align:middle line:90% 00:03:04.790 --> 00:03:10.100 align:middle line:84% So now, we have a contraction of SNARGs, 00:03:10.100 --> 00:03:12.675 align:middle line:84% but let's see what's the proof size for this SNARG. 00:03:12.675 --> 00:03:15.760 align:middle line:90% 00:03:15.760 --> 00:03:22.600 align:middle line:84% So the proof size consists of the first message 00:03:22.600 --> 00:03:24.140 align:middle line:90% and the third round message. 00:03:24.140 --> 00:03:26.080 align:middle line:84% So the first round of message consists 00:03:26.080 --> 00:03:28.820 align:middle line:90% of l, l for hash values. 00:03:28.820 --> 00:03:30.580 align:middle line:84% So you can think of each hash value 00:03:30.580 --> 00:03:34.900 align:middle line:84% is also [INAUDIBLE] ciphertext, so it's a poly lambda bits. 00:03:34.900 --> 00:03:43.600 align:middle line:84% So in total the first round of message consists of poly c times 00:03:43.600 --> 00:03:52.300 align:middle line:84% poly l, but it is independent of k. 00:03:52.300 --> 00:04:04.530 align:middle line:84% And the third round message is k times poly log c times poly l 00:04:04.530 --> 00:04:09.810 align:middle line:84% because, for each in the Celeron message, for each instance 00:04:09.810 --> 00:04:13.240 align:middle line:90% you send a q PCP answers. 00:04:13.240 --> 00:04:19.029 align:middle line:84% So the size of q is lambda times poly log c. 00:04:19.029 --> 00:04:22.990 align:middle line:84% So in total, you send a k of them. 00:04:22.990 --> 00:04:24.530 align:middle line:90% So in total, it's k times this. 00:04:24.530 --> 00:04:27.150 align:middle line:90% 00:04:27.150 --> 00:04:30.270 align:middle line:84% So this is already non-trivial because it's a-- 00:04:30.270 --> 00:04:37.440 align:middle line:84% so this number, it could be much smaller than k times k times w. 00:04:37.440 --> 00:04:40.500 align:middle line:84% Because the second term is almost order of k, 00:04:40.500 --> 00:04:43.050 align:middle line:90% and the first term is almost c. 00:04:43.050 --> 00:04:47.340 align:middle line:84% So this is already non-trivial, but it's still large. 00:04:47.340 --> 00:04:53.630 align:middle line:84% So the big issue is, if you look at the verification time, 00:04:53.630 --> 00:05:05.570 align:middle line:84% so the verification time is you will see is k times poly c. 00:05:05.570 --> 00:05:10.670 align:middle line:84% The reason is the verifier need to verify the PCP 00:05:10.670 --> 00:05:14.360 align:middle line:84% answers for each of the instances for x1 00:05:14.360 --> 00:05:18.840 align:middle line:90% to xk, so in this step. 00:05:18.840 --> 00:05:22.140 align:middle line:84% So each PCP verification need to take c time, 00:05:22.140 --> 00:05:28.110 align:middle line:84% and in total, it need to take k times poly c. 00:05:28.110 --> 00:05:28.610 align:middle line:90% Yeah? 00:05:28.610 --> 00:05:30.860 align:middle line:84% AUDIENCE: Why is there a poly lambda at the end? 00:05:30.860 --> 00:05:35.570 align:middle line:84% ZHENGZHONG JIN: So that's because each query is a-- 00:05:35.570 --> 00:05:38.990 align:middle line:84% so each query, so if you remember-- 00:05:38.990 --> 00:05:40.080 align:middle line:90% yeah, so here. 00:05:40.080 --> 00:05:44.020 align:middle line:84% So each query size is a lambda times poly log c. 00:05:44.020 --> 00:05:48.830 align:middle line:90% 00:05:48.830 --> 00:05:49.860 align:middle line:90% So it's-- yeah. 00:05:49.860 --> 00:05:51.450 align:middle line:84% AUDIENCE: So they're not just querying single bits. 00:05:51.450 --> 00:05:53.150 align:middle line:84% They're querying like blocks of links. 00:05:53.150 --> 00:05:56.317 align:middle line:90% 00:05:56.317 --> 00:05:58.900 align:middle line:84% ZHENGZHONG JIN: So here, we have a lambda term because we need 00:05:58.900 --> 00:06:00.940 align:middle line:90% to do the parallel repetition. 00:06:00.940 --> 00:06:05.920 align:middle line:84% So you take PCP with constant suddenness arrow, 00:06:05.920 --> 00:06:11.392 align:middle line:84% and then you amplify it lambda times by parallel repetition. 00:06:11.392 --> 00:06:12.850 align:middle line:84% AUDIENCE: And we want to amplify it 00:06:12.850 --> 00:06:15.178 align:middle line:84% because we want complete, like perfect completeness 00:06:15.178 --> 00:06:15.720 align:middle line:90% or something? 00:06:15.720 --> 00:06:17.770 align:middle line:84% ZHENGZHONG JIN: Yeah, so you can have 00:06:17.770 --> 00:06:20.530 align:middle line:90% PCP with perfect completeness. 00:06:20.530 --> 00:06:22.960 align:middle line:84% So you don't need to worry about when 00:06:22.960 --> 00:06:25.000 align:middle line:90% you do the parallel repetition. 00:06:25.000 --> 00:06:29.080 align:middle line:84% So verification time is still very large. 00:06:29.080 --> 00:06:32.180 align:middle line:84% So in fact you don't have any savings if you do this directly, 00:06:32.180 --> 00:06:36.340 align:middle line:90% so on the verification time. 00:06:36.340 --> 00:06:43.390 align:middle line:84% So let's consider for a general SNARGs for batch 00:06:43.390 --> 00:06:46.360 align:middle line:84% NP, or BARGs, so what's the verification time? 00:06:46.360 --> 00:06:50.740 align:middle line:84% So remember, in a bark, the verifier 00:06:50.740 --> 00:06:55.040 align:middle line:84% need to read at least the CRS and all of the statements 00:06:55.040 --> 00:06:56.600 align:middle line:90% to verify the proof. 00:06:56.600 --> 00:07:02.430 align:middle line:84% So the verifier need to at least read all of the instance. 00:07:02.430 --> 00:07:05.380 align:middle line:84% So it seems that there is a lower bound on the verification 00:07:05.380 --> 00:07:05.880 align:middle line:90% time. 00:07:05.880 --> 00:07:16.805 align:middle line:84% The lower bound is just at least K times X. 00:07:16.805 --> 00:07:20.480 align:middle line:84% So next I will show you how to reduce the verification time 00:07:20.480 --> 00:07:21.745 align:middle line:90% and the proof size of BARGs. 00:07:21.745 --> 00:07:27.800 align:middle line:90% 00:07:27.800 --> 00:07:30.900 align:middle line:84% So we will consider a variant of BARG, 00:07:30.900 --> 00:07:33.400 align:middle line:84% and it don't have this lower bound on the verification time. 00:07:33.400 --> 00:07:36.140 align:middle line:90% 00:07:36.140 --> 00:07:41.390 align:middle line:84% So I will define a new notion of BARGs. 00:07:41.390 --> 00:07:42.475 align:middle line:90% Let me erase this. 00:07:42.475 --> 00:08:09.820 align:middle line:90% 00:08:09.820 --> 00:08:21.010 align:middle line:84% So this notion of BARGs is called the index BARG, 00:08:21.010 --> 00:08:22.770 align:middle line:90% or you can also call it SNARGs. 00:08:22.770 --> 00:08:26.560 align:middle line:90% 00:08:26.560 --> 00:08:28.725 align:middle line:90% for a batch index. 00:08:28.725 --> 00:08:39.820 align:middle line:90% 00:08:39.820 --> 00:08:42.370 align:middle line:84% So in the original definition of BARGs, 00:08:42.370 --> 00:08:44.770 align:middle line:84% the verifier need to read all of the instance, 00:08:44.770 --> 00:08:46.760 align:middle line:84% because the instance are non-uniform. 00:08:46.760 --> 00:08:49.840 align:middle line:84% So in this notion, we will consider a special case 00:08:49.840 --> 00:08:52.580 align:middle line:90% when this instance are uniform. 00:08:52.580 --> 00:08:59.170 align:middle line:84% So intuitively, it means there exists some circuit U such 00:08:59.170 --> 00:09:03.250 align:middle line:84% that the I-th instance is generated by using the circuit U 00:09:03.250 --> 00:09:09.490 align:middle line:84% and the index I. So intuitively, it 00:09:09.490 --> 00:09:12.550 align:middle line:84% says the instance can be described in a uniform way 00:09:12.550 --> 00:09:14.500 align:middle line:90% by only using the index. 00:09:14.500 --> 00:09:18.130 align:middle line:84% And if this is the case, then what 00:09:18.130 --> 00:09:21.700 align:middle line:84% the prover will try to prove is X1 to XK 00:09:21.700 --> 00:09:25.240 align:middle line:90% is all in this language L. 00:09:25.240 --> 00:09:33.580 align:middle line:84% So now, it is equivalent to say, so for each index I, 00:09:33.580 --> 00:09:39.280 align:middle line:84% there exists a witness WI such that this circuit C 00:09:39.280 --> 00:09:44.350 align:middle line:90% and the UI WI equals 1. 00:09:44.350 --> 00:09:47.430 align:middle line:90% So then we can define. 00:09:47.430 --> 00:09:52.500 align:middle line:84% So essentially, this you can view this as a new NP relation. 00:09:52.500 --> 00:09:57.440 align:middle line:84% So the new NP relation is defined as follows. 00:09:57.440 --> 00:10:00.210 align:middle line:84% So the instance is just an index, 00:10:00.210 --> 00:10:05.110 align:middle line:84% and it verifies there exists a WI such that. 00:10:05.110 --> 00:10:16.070 align:middle line:90% 00:10:16.070 --> 00:10:20.190 align:middle line:84% So this is just a rewriting of this, right. 00:10:20.190 --> 00:10:24.620 align:middle line:90% 00:10:24.620 --> 00:10:27.650 align:middle line:90% So, right. 00:10:27.650 --> 00:10:32.420 align:middle line:84% And you can view this as a new NP verification circuit 00:10:32.420 --> 00:10:38.490 align:middle line:84% that some C prime so it only takes WI, and I and WI as input. 00:10:38.490 --> 00:10:41.480 align:middle line:84% And it internally compute this U and verify C. 00:10:41.480 --> 00:10:46.180 align:middle line:84% So this inspires us to define a new notion called index BARG. 00:10:46.180 --> 00:10:52.810 align:middle line:90% So, an index BARG definition-- 00:10:52.810 --> 00:11:09.200 align:middle line:84% an index BARG is a BARG for this kind of relation. 00:11:09.200 --> 00:11:13.870 align:middle line:84% So it is for this kind of language 00:11:13.870 --> 00:11:17.420 align:middle line:84% where the language is just some general NP language, 00:11:17.420 --> 00:11:37.930 align:middle line:84% but the instance is treated as an index for this language, 00:11:37.930 --> 00:11:44.253 align:middle line:84% So the prover, we still have a CRS. 00:11:44.253 --> 00:11:49.970 align:middle line:84% And the prover tries to convince the verifier 00:11:49.970 --> 00:11:56.570 align:middle line:84% that all of the indices from 1, 2, et cetera, to K 00:11:56.570 --> 00:11:57.805 align:middle line:90% is in this language. 00:11:57.805 --> 00:12:00.950 align:middle line:90% 00:12:00.950 --> 00:12:05.450 align:middle line:84% So the honest prover only need to read index K, 00:12:05.450 --> 00:12:11.790 align:middle line:84% and it has a witness from W1 to WK for each of the index. 00:12:11.790 --> 00:12:15.890 align:middle line:84% And the verifier only need to take K as input. 00:12:15.890 --> 00:12:20.690 align:middle line:84% So now the verifier, so this K can 00:12:20.690 --> 00:12:23.870 align:middle line:84% be represented as log K bits, because it's just an index. 00:12:23.870 --> 00:12:28.690 align:middle line:84% So what's the best verification time we can hope for? 00:12:28.690 --> 00:12:33.590 align:middle line:90% 00:12:33.590 --> 00:12:34.410 align:middle line:90% Anyone know? 00:12:34.410 --> 00:12:40.910 align:middle line:90% 00:12:40.910 --> 00:12:42.580 align:middle line:90% So all good. 00:12:42.580 --> 00:12:45.620 align:middle line:90% 00:12:45.620 --> 00:12:49.690 align:middle line:84% So the verifier only need to read this index K and the proof. 00:12:49.690 --> 00:12:55.000 align:middle line:84% So the verifier can be as small as verification time, only 00:12:55.000 --> 00:13:02.020 align:middle line:84% need to be some log K, can be as small as this much, so 00:13:02.020 --> 00:13:04.135 align:middle line:84% only depends on log K and the lambda. 00:13:04.135 --> 00:13:13.420 align:middle line:90% 00:13:13.420 --> 00:13:16.240 align:middle line:84% And for this index BARG, we also require the completeness 00:13:16.240 --> 00:13:20.170 align:middle line:84% and the soundness in the same way as before. 00:13:20.170 --> 00:13:21.305 align:middle line:90% Any questions? 00:13:21.305 --> 00:13:21.805 align:middle line:90% Yeah. 00:13:21.805 --> 00:13:23.650 align:middle line:84% AUDIENCE: How should I think of this U? 00:13:23.650 --> 00:13:25.360 align:middle line:84% Or should I think of it as being part of the instance 00:13:25.360 --> 00:13:26.610 align:middle line:90% or something globally defined? 00:13:26.610 --> 00:13:29.770 align:middle line:90% 00:13:29.770 --> 00:13:33.640 align:middle line:84% ZHENGZHONG JIN: So you can always absorb it 00:13:33.640 --> 00:13:36.350 align:middle line:90% in the relation circuit. 00:13:36.350 --> 00:13:38.290 align:middle line:84% So you can think it's part of the relation. 00:13:38.290 --> 00:13:39.040 align:middle line:90% AUDIENCE: Right. 00:13:39.040 --> 00:13:42.000 align:middle line:84% I guess, are we going to pay for the size of the description of U 00:13:42.000 --> 00:13:42.520 align:middle line:90% anywhere? 00:13:42.520 --> 00:13:43.222 align:middle line:90% Or is that a? 00:13:43.222 --> 00:13:44.680 align:middle line:84% ZHENGZHONG JIN: Right, right, good. 00:13:44.680 --> 00:13:47.160 align:middle line:84% So the verification circuit, in fact, 00:13:47.160 --> 00:13:49.770 align:middle line:84% also depends on C, because the verifier 00:13:49.770 --> 00:13:51.287 align:middle line:90% needs to read the circuit. 00:13:51.287 --> 00:13:51.870 align:middle line:90% AUDIENCE: Yes. 00:13:51.870 --> 00:13:55.470 align:middle line:90% 00:13:55.470 --> 00:13:57.900 align:middle line:84% And is there like a unique instance in this problem, 00:13:57.900 --> 00:14:01.830 align:middle line:84% then, like, where you're saying K itself, is that OK? 00:14:01.830 --> 00:14:03.690 align:middle line:84% ZHENGZHONG JIN: So now, the point 00:14:03.690 --> 00:14:07.080 align:middle line:84% is now the verification time only depends on linear in K. 00:14:07.080 --> 00:14:09.550 align:middle line:84% So previously, you need to read all of the instance. 00:14:09.550 --> 00:14:13.875 align:middle line:84% And now you, the verification time only grow log in K. 00:14:13.875 --> 00:14:17.310 align:middle line:84% AUDIENCE: Are we supposed to think of C as part of the input? 00:14:17.310 --> 00:14:21.590 align:middle line:84% ZHENGZHONG JIN: C as part of the input? 00:14:21.590 --> 00:14:31.325 align:middle line:84% AUDIENCE: So like, or I guess C prime, which stores U in it. 00:14:31.325 --> 00:14:33.005 align:middle line:84% ZHENGZHONG JIN: Right, yes, yes, right. 00:14:33.005 --> 00:14:36.300 align:middle line:84% AUDIENCE: So, that is part of the input. 00:14:36.300 --> 00:14:38.650 align:middle line:84% So V still has to read what C prime is? 00:14:38.650 --> 00:14:41.915 align:middle line:84% So doesn't that take a lot of value? 00:14:41.915 --> 00:14:44.040 align:middle line:84% ZHENGZHONG JIN: So it depends on how you define it. 00:14:44.040 --> 00:14:46.230 align:middle line:84% So you can define it for a fixed C, 00:14:46.230 --> 00:14:48.090 align:middle line:84% and then you have such a proof system. 00:14:48.090 --> 00:14:50.160 align:middle line:84% Or you can define a proof system for any C, 00:14:50.160 --> 00:14:53.630 align:middle line:84% then you need the verification time to grow with the circuits, 00:14:53.630 --> 00:14:54.500 align:middle line:90% size C. 00:14:54.500 --> 00:14:59.600 align:middle line:84% AUDIENCE: Is it defining it for a fixed C not that helpful, 00:14:59.600 --> 00:15:03.620 align:middle line:84% because you're just solving batch SNARG for a fixed set 00:15:03.620 --> 00:15:05.032 align:middle line:90% of X's. 00:15:05.032 --> 00:15:06.860 align:middle line:84% ZHENGZHONG JIN: But you can choose 00:15:06.860 --> 00:15:09.325 align:middle line:84% C to be universal circuit, then it's a-- yeah. 00:15:09.325 --> 00:15:13.250 align:middle line:90% 00:15:13.250 --> 00:15:16.250 align:middle line:90% Things in general. 00:15:16.250 --> 00:15:17.070 align:middle line:90% Good question. 00:15:17.070 --> 00:15:20.150 align:middle line:84% So in fact, I think, if you take universally, 00:15:20.150 --> 00:15:24.350 align:middle line:84% you need to-- if you use the U, maybe. 00:15:24.350 --> 00:15:26.520 align:middle line:84% It's good to think of C as the input. 00:15:26.520 --> 00:15:37.890 align:middle line:90% 00:15:37.890 --> 00:15:41.940 align:middle line:84% So in the remaining time of this lecture, 00:15:41.940 --> 00:15:43.860 align:middle line:84% we'll prove the following theorem. 00:15:43.860 --> 00:15:57.990 align:middle line:84% So there exists an Index BARG from LWE. 00:15:57.990 --> 00:16:08.880 align:middle line:84% And the proof size is poly log, so it will grow log 00:16:08.880 --> 00:16:12.620 align:middle line:90% in K, C, and lambda. 00:16:12.620 --> 00:16:15.540 align:middle line:90% 00:16:15.540 --> 00:16:26.420 align:middle line:84% And the verification time is log KC lambda. 00:16:26.420 --> 00:16:29.130 align:middle line:90% 00:16:29.130 --> 00:16:35.310 align:middle line:84% So both of them almost match the best 00:16:35.310 --> 00:16:37.710 align:middle line:84% you can hope for, up to some polynomial. 00:16:37.710 --> 00:16:52.190 align:middle line:90% 00:16:52.190 --> 00:17:10.670 align:middle line:84% So I want to emphasize here that, in fact, you can, 00:17:10.670 --> 00:17:13.250 align:middle line:84% if you know how to build this index BARG, 00:17:13.250 --> 00:17:16.790 align:middle line:84% then you can build BARGs with almost the same verification 00:17:16.790 --> 00:17:17.679 align:middle line:90% time and proof size. 00:17:17.679 --> 00:17:21.050 align:middle line:90% 00:17:21.050 --> 00:17:25.280 align:middle line:84% So in other words, in fact, a batch of instance 00:17:25.280 --> 00:17:29.760 align:middle line:84% are without loss of generality uniform, in some sense. 00:17:29.760 --> 00:17:37.540 align:middle line:84% So, what I will show you is, in fact, if you 00:17:37.540 --> 00:17:42.100 align:middle line:84% know how to build index BARG, then you 00:17:42.100 --> 00:17:44.310 align:middle line:84% can use it in a generic way to build BARGs. 00:17:44.310 --> 00:17:47.260 align:middle line:90% 00:17:47.260 --> 00:17:50.445 align:middle line:84% So the reduction works as follows. 00:17:50.445 --> 00:17:53.350 align:middle line:90% 00:17:53.350 --> 00:17:57.310 align:middle line:84% So now we want to build a BARG for a bunch of instance 00:17:57.310 --> 00:17:58.410 align:middle line:90% from X1 to XK. 00:17:58.410 --> 00:18:03.040 align:middle line:90% 00:18:03.040 --> 00:18:08.770 align:middle line:84% So the idea is we will first build a Merkle hash of all 00:18:08.770 --> 00:18:09.680 align:middle line:90% of the instances. 00:18:09.680 --> 00:18:16.679 align:middle line:90% 00:18:16.679 --> 00:18:18.195 align:middle line:90% And we have some hash root. 00:18:18.195 --> 00:18:23.470 align:middle line:90% 00:18:23.470 --> 00:18:27.135 align:middle line:84% So now we have the prover send this hash root to the verifier. 00:18:27.135 --> 00:18:30.320 align:middle line:90% 00:18:30.320 --> 00:18:37.560 align:middle line:84% And then we have the prover to show that for any index I, 00:18:37.560 --> 00:18:50.590 align:middle line:84% there exist a local opening, row I. So the local opening, 00:18:50.590 --> 00:18:54.360 align:middle line:84% remember, is the root to leaf path for each of the leaf. 00:18:54.360 --> 00:19:01.410 align:middle line:84% So there exists a local opening, row I, 00:19:01.410 --> 00:19:14.010 align:middle line:84% for XI, such that the local verification will pass 00:19:14.010 --> 00:19:22.056 align:middle line:90% for this XI local verification. 00:19:22.056 --> 00:19:26.490 align:middle line:90% 00:19:26.490 --> 00:19:28.050 align:middle line:84% So the local verification algorithm 00:19:28.050 --> 00:19:30.540 align:middle line:84% will take the hash root and the index I 00:19:30.540 --> 00:19:35.780 align:middle line:84% and the XI, which is the open the value, and also this local 00:19:35.780 --> 00:19:39.230 align:middle line:84% opening, which is the root-to-leaf path. 00:19:39.230 --> 00:19:43.940 align:middle line:84% And moreover, there also exists a WI such 00:19:43.940 --> 00:19:47.790 align:middle line:84% that the original circuit is satisfied. 00:19:47.790 --> 00:19:51.690 align:middle line:90% 00:19:51.690 --> 00:19:55.940 align:middle line:84% So the idea is you just hash all of the instance from X1 to XK, 00:19:55.940 --> 00:20:00.210 align:middle line:84% and you send the hash value to the verifier. 00:20:00.210 --> 00:20:04.460 align:middle line:84% Then you prove for each index I there exists an opening 00:20:04.460 --> 00:20:06.480 align:middle line:90% XI to this hash. 00:20:06.480 --> 00:20:10.370 align:middle line:90% And this C of XI is satisfied. 00:20:10.370 --> 00:20:20.870 align:middle line:84% So in this way, so you convert a batch of NP instance 00:20:20.870 --> 00:20:24.390 align:middle line:90% to a batch index instance. 00:20:24.390 --> 00:20:26.520 align:middle line:84% So now, the statement only grows. 00:20:26.520 --> 00:20:29.210 align:middle line:84% So it proves something for each index 00:20:29.210 --> 00:20:35.555 align:middle line:90% I, so you can view this part. 00:20:35.555 --> 00:20:38.250 align:middle line:90% 00:20:38.250 --> 00:20:42.130 align:middle line:84% So you can view this part as some circuit C prime. 00:20:42.130 --> 00:20:47.160 align:middle line:84% So C prime will take index I and the witness row I, 00:20:47.160 --> 00:20:53.220 align:middle line:90% WI, and check the two things. 00:20:53.220 --> 00:20:59.550 align:middle line:84% Then you can generate an index BARG for this instance for each 00:20:59.550 --> 00:21:08.514 align:middle line:84% of the instance from X1, from 1 to K. 00:21:08.514 --> 00:21:13.260 align:middle line:84% And then you generate an index BARG for this kind of instance. 00:21:13.260 --> 00:21:17.930 align:middle line:84% So now you send this to the verifier, and this is your BARG. 00:21:17.930 --> 00:21:24.990 align:middle line:90% 00:21:24.990 --> 00:21:28.690 align:middle line:84% So if pi is small and H is small, 00:21:28.690 --> 00:21:31.550 align:middle line:84% then your total proof size is also small. 00:21:31.550 --> 00:21:32.620 align:middle line:90% So that's the idea. 00:21:32.620 --> 00:21:41.760 align:middle line:90% 00:21:41.760 --> 00:21:43.670 align:middle line:84% So I will come back to this point later. 00:21:43.670 --> 00:21:46.190 align:middle line:90% 00:21:46.190 --> 00:21:48.800 align:middle line:84% Because the proof of soundness of this transformation 00:21:48.800 --> 00:21:54.210 align:middle line:84% is not trivial, because, in fact, you will see this is not-- 00:21:54.210 --> 00:21:56.840 align:middle line:84% so the non-adaptive soundness previously 00:21:56.840 --> 00:21:59.100 align:middle line:84% is not sufficient to prove the soundness, 00:21:59.100 --> 00:22:02.270 align:middle line:84% because this circuit will depends on this hash, 00:22:02.270 --> 00:22:05.310 align:middle line:84% and it's chosen adaptively by the adversary. 00:22:05.310 --> 00:22:06.800 align:middle line:84% So we will come back to this point 00:22:06.800 --> 00:22:08.870 align:middle line:84% later to show how to prove the soundness 00:22:08.870 --> 00:22:12.650 align:middle line:90% of this transformation. 00:22:12.650 --> 00:22:15.430 align:middle line:84% So next, I will show you how to build this index BARG. 00:22:15.430 --> 00:22:24.110 align:middle line:90% 00:22:24.110 --> 00:22:31.220 align:middle line:84% So our starting point is still this protocol. 00:22:31.220 --> 00:22:36.640 align:middle line:84% So, as I just said earlier, so the first round message 00:22:36.640 --> 00:22:39.260 align:middle line:84% is small because it only depends on C, 00:22:39.260 --> 00:22:41.180 align:middle line:84% but the third round message is large. 00:22:41.180 --> 00:22:43.755 align:middle line:84% So how can we further compress the third round message? 00:22:43.755 --> 00:23:14.366 align:middle line:90% 00:23:14.366 --> 00:23:17.350 align:middle line:84% So in the context of index BARG, all of the instance 00:23:17.350 --> 00:23:18.470 align:middle line:90% are just indices. 00:23:18.470 --> 00:23:27.210 align:middle line:84% So I can replace them with 1 to K. 00:23:27.210 --> 00:23:30.220 align:middle line:84% And the idea is we're going to delegate. 00:23:30.220 --> 00:23:37.410 align:middle line:90% 00:23:37.410 --> 00:23:39.550 align:middle line:84% We're going to remove this round of message. 00:23:39.550 --> 00:23:46.830 align:middle line:84% And so we're going to delegate the verification of this message 00:23:46.830 --> 00:23:47.980 align:middle line:90% to the prover. 00:23:47.980 --> 00:23:51.360 align:middle line:84% So the prover will have this open 00:23:51.360 --> 00:23:54.160 align:middle line:84% the query, the columns in his hand, 00:23:54.160 --> 00:23:57.190 align:middle line:84% but he is not going to send them to the verifier. 00:23:57.190 --> 00:24:01.950 align:middle line:84% Instead, the prover is going do the verification by itself 00:24:01.950 --> 00:24:06.360 align:middle line:84% and prove to the verifier those verification is indeed correct. 00:24:06.360 --> 00:24:13.020 align:middle line:84% So the conjunction work like this. 00:24:13.020 --> 00:24:23.550 align:middle line:84% So the prover still sends this H1 to HL to the verifier. 00:24:23.550 --> 00:24:29.770 align:middle line:84% And the prover is going to compute this PCP 00:24:29.770 --> 00:24:31.280 align:middle line:90% query using the CI hash. 00:24:31.280 --> 00:24:34.840 align:middle line:90% 00:24:34.840 --> 00:24:36.880 align:middle line:84% And then the prover and the verifier 00:24:36.880 --> 00:24:46.780 align:middle line:84% is going to run another protocol, so another SNARG. 00:24:46.780 --> 00:24:50.620 align:middle line:84% And this SNARG on the prover side, 00:24:50.620 --> 00:24:59.500 align:middle line:84% he's going to use the columns, open the columns 00:24:59.500 --> 00:25:03.370 align:middle line:90% as the input to this protocol. 00:25:03.370 --> 00:25:10.630 align:middle line:84% And in the end, the verifier is convinced the third round 00:25:10.630 --> 00:25:11.980 align:middle line:90% message verifies. 00:25:11.980 --> 00:25:25.980 align:middle line:84% So what does this mean is the prover 00:25:25.980 --> 00:25:28.800 align:middle line:84% is going to prove to this verifier in this protocol 00:25:28.800 --> 00:25:30.310 align:middle line:90% the following language. 00:25:30.310 --> 00:25:44.860 align:middle line:84% So there exist log columns Q such that two things. 00:25:44.860 --> 00:25:57.300 align:middle line:84% So one is for each column, for each Q in the query, the set, 00:25:57.300 --> 00:26:00.360 align:middle line:84% the hash is computed correctly, is 00:26:00.360 --> 00:26:02.610 align:middle line:84% consistent with the first message. 00:26:02.610 --> 00:26:10.360 align:middle line:84% So HQ is the SSV hash of the column. 00:26:10.360 --> 00:26:11.730 align:middle line:90% The Q is column. 00:26:11.730 --> 00:26:15.390 align:middle line:90% So I omit the SSV key here. 00:26:15.390 --> 00:26:21.640 align:middle line:84% And the second, for each PCP, for each instance, 00:26:21.640 --> 00:26:26.870 align:middle line:84% so for any I in K, so here the instance 00:26:26.870 --> 00:26:30.870 align:middle line:84% is just the index I. The I-th instance XI is just the index I. 00:26:30.870 --> 00:26:33.930 align:middle line:90% So he will verify this. 00:26:33.930 --> 00:26:36.620 align:middle line:90% 00:26:36.620 --> 00:26:58.130 align:middle line:84% So the PCP verification of I Q under the Q's column, 00:26:58.130 --> 00:27:01.550 align:middle line:84% the I-th coordinate of the Q column. 00:27:01.550 --> 00:27:03.220 align:middle line:90% And we collect them together. 00:27:03.220 --> 00:27:10.264 align:middle line:90% 00:27:10.264 --> 00:27:14.480 align:middle line:84% So this is a statement this protocol wants to prove. 00:27:14.480 --> 00:27:17.240 align:middle line:84% And the prover is going to supply it 00:27:17.240 --> 00:27:20.755 align:middle line:90% with the witness, which is this. 00:27:20.755 --> 00:27:24.304 align:middle line:90% 00:27:24.304 --> 00:27:27.730 align:middle line:90% So that's the high-level idea. 00:27:27.730 --> 00:27:34.240 align:middle line:84% But to achieve this, so suppose we can rewrite this statement 00:27:34.240 --> 00:27:36.200 align:middle line:90% as a batch index statement. 00:27:36.200 --> 00:27:40.060 align:middle line:84% Then I can apply the same construction again 00:27:40.060 --> 00:27:42.200 align:middle line:90% on top of this statement. 00:27:42.200 --> 00:27:46.990 align:middle line:84% So we can apply the same thing again to this new statement. 00:27:46.990 --> 00:27:49.300 align:middle line:90% And I can do the recursing. 00:27:49.300 --> 00:27:52.780 align:middle line:90% So that's the idea. 00:27:52.780 --> 00:27:54.580 align:middle line:84% But the issue is how do I represent 00:27:54.580 --> 00:27:57.170 align:middle line:90% this as a batch index language. 00:27:57.170 --> 00:28:04.460 align:middle line:84% So how do I represent this as a batch of index language? 00:28:04.460 --> 00:28:06.945 align:middle line:84% So how do I represent it as a batch of index? 00:28:06.945 --> 00:28:11.110 align:middle line:90% 00:28:11.110 --> 00:28:15.010 align:middle line:84% So now you can see, maybe you think, OK, 00:28:15.010 --> 00:28:18.400 align:middle line:84% so this is almost index because index language. 00:28:18.400 --> 00:28:21.910 align:middle line:90% Because at least this part-- 00:28:21.910 --> 00:28:30.490 align:middle line:84% this is clear for any index I. This is for any index I in K, 00:28:30.490 --> 00:28:31.670 align:middle line:90% there is something. 00:28:31.670 --> 00:28:33.830 align:middle line:84% So this is similar to our index language, 00:28:33.830 --> 00:28:36.250 align:middle line:90% but this part is not clear. 00:28:36.250 --> 00:28:43.480 align:middle line:84% So the reason is Q is very small, 00:28:43.480 --> 00:28:46.150 align:middle line:84% but the NP witness is very large. 00:28:46.150 --> 00:28:49.750 align:middle line:84% So if you treat this Q as an instance, 00:28:49.750 --> 00:28:53.950 align:middle line:84% then the witness size is K, because each column 00:28:53.950 --> 00:28:56.360 align:middle line:90% has K entries. 00:28:56.360 --> 00:28:59.680 align:middle line:84% So each column contains the PCP coordinate 00:28:59.680 --> 00:29:04.030 align:middle line:84% for each of the instance, so the column size is K. 00:29:04.030 --> 00:29:11.360 align:middle line:84% But if I treat this column, column Q, as a witness, 00:29:11.360 --> 00:29:14.680 align:middle line:84% then when I do the recursion, the proof size 00:29:14.680 --> 00:29:20.380 align:middle line:84% will grow with the size of K because, again, I 00:29:20.380 --> 00:29:26.900 align:middle line:84% will have this kind of hash value, some L prime. 00:29:26.900 --> 00:29:33.710 align:middle line:84% But those are H1 to L prime, H1 prime to L prime prime. 00:29:33.710 --> 00:29:37.160 align:middle line:84% So they are for the new protocol and the new instance. 00:29:37.160 --> 00:29:40.820 align:middle line:84% So they will grow with the size of K. So that's too large. 00:29:40.820 --> 00:29:43.310 align:middle line:90% We cannot afford that. 00:29:43.310 --> 00:29:49.210 align:middle line:84% So next, I will rewrite this instance 00:29:49.210 --> 00:29:52.360 align:middle line:90% as a batch of statements. 00:29:52.360 --> 00:29:54.590 align:middle line:84% And the statement size will be K, 00:29:54.590 --> 00:29:58.130 align:middle line:84% but the NP witness will be small. 00:29:58.130 --> 00:30:01.420 align:middle line:90% So how do I rewrite it? 00:30:01.420 --> 00:30:06.290 align:middle line:84% So let's look at what this do, this verification do. 00:30:06.290 --> 00:30:10.360 align:middle line:84% So for each of this verification, 00:30:10.360 --> 00:30:19.470 align:middle line:84% we have a column Q, and its size is K. 00:30:19.470 --> 00:30:22.470 align:middle line:84% So it will recompute this SSV hash 00:30:22.470 --> 00:30:28.200 align:middle line:84% and check if it is the same with some HQ, which is the hash that 00:30:28.200 --> 00:30:29.555 align:middle line:90% was sent in the first round. 00:30:29.555 --> 00:30:32.880 align:middle line:90% 00:30:32.880 --> 00:30:37.680 align:middle line:84% So the idea is that suppose this SSV hash, 00:30:37.680 --> 00:30:41.310 align:middle line:84% suppose we have some more structure of this SSV hash, 00:30:41.310 --> 00:30:44.050 align:middle line:90% then I can local verify it. 00:30:44.050 --> 00:30:57.420 align:middle line:84% So that means, for example, if the SSV hash 00:30:57.420 --> 00:31:02.880 align:middle line:84% is built as a Merkle tree, then I can replace this verification 00:31:02.880 --> 00:31:13.920 align:middle line:84% by verify that for each index I in K, 00:31:13.920 --> 00:31:19.490 align:middle line:84% there exists a local opening, rho IQ, 00:31:19.490 --> 00:31:22.470 align:middle line:90% so rho IQ is the local opening. 00:31:22.470 --> 00:31:29.490 align:middle line:84% You can think for each index I, I have an entry. 00:31:29.490 --> 00:31:35.400 align:middle line:84% The entry is column Q, the I-th position of column Q, 00:31:35.400 --> 00:31:40.430 align:middle line:84% and I have a local opening for that, rho IQ. 00:31:40.430 --> 00:31:43.610 align:middle line:84% So I only need to show there exists such a local opening 00:31:43.610 --> 00:31:45.560 align:middle line:90% for this hash. 00:31:45.560 --> 00:31:49.950 align:middle line:90% So here, HQ is the hash value. 00:31:49.950 --> 00:32:01.765 align:middle line:84% So for HQ, I only need to verify this. 00:32:01.765 --> 00:32:08.180 align:middle line:90% 00:32:08.180 --> 00:32:12.670 align:middle line:84% So now I get a batch of NP instance. 00:32:12.670 --> 00:32:23.950 align:middle line:90% 00:32:23.950 --> 00:32:25.350 align:middle line:90% So let me rewrite this. 00:32:25.350 --> 00:32:40.870 align:middle line:90% 00:32:40.870 --> 00:32:49.570 align:middle line:84% So suppose I have a SSV built in the Merkle tree way, 00:32:49.570 --> 00:32:52.520 align:middle line:84% so the protocol will work like this. 00:32:52.520 --> 00:33:04.360 align:middle line:84% So initially, we have H1 to HL, and we have this Q. 00:33:04.360 --> 00:33:09.460 align:middle line:84% So in the new protocol the prover 00:33:09.460 --> 00:33:16.590 align:middle line:84% is going to supply it with query the column for this Q, 00:33:16.590 --> 00:33:21.500 align:middle line:84% and also a bunch of local openings for each 00:33:21.500 --> 00:33:41.180 align:middle line:84% coordinates in this Q. So this protocol 00:33:41.180 --> 00:33:46.940 align:middle line:90% is a new index BARG protocol. 00:33:46.940 --> 00:33:52.260 align:middle line:84% It will prove for a new instance L for a new language L prime. 00:33:52.260 --> 00:33:54.260 align:middle line:90% Let's denote it. 00:33:54.260 --> 00:34:04.860 align:middle line:84% So L prime, it contains all the index I. And for each index I, 00:34:04.860 --> 00:34:14.830 align:middle line:84% I need to show there exist a witness which is column QI. 00:34:14.830 --> 00:34:23.110 align:middle line:90% 00:34:23.110 --> 00:34:27.639 align:middle line:90% So this is the I-th PCP answer. 00:34:27.639 --> 00:34:30.310 align:middle line:90% And they are corresponding. 00:34:30.310 --> 00:34:32.770 align:middle line:90% I also need this rho IQ. 00:34:32.770 --> 00:34:44.980 align:middle line:90% 00:34:44.980 --> 00:34:47.650 align:middle line:84% So first I need to verify the PCP answers. 00:34:47.650 --> 00:35:12.900 align:middle line:90% 00:35:12.900 --> 00:35:17.645 align:middle line:84% And second, I need to verify the local opening is correct. 00:35:17.645 --> 00:35:21.330 align:middle line:90% 00:35:21.330 --> 00:35:25.710 align:middle line:84% So there is some local opening verification algorithm. 00:35:25.710 --> 00:35:27.690 align:middle line:84% The local verification algorithm will 00:35:27.690 --> 00:35:34.470 align:middle line:84% take the hash root for each Q. And so I 00:35:34.470 --> 00:35:45.510 align:middle line:84% need to verify this for every Q. And this local verification 00:35:45.510 --> 00:35:48.290 align:middle line:84% algorithm of SSV will verify row IQ. 00:35:48.290 --> 00:36:10.250 align:middle line:90% 00:36:10.250 --> 00:36:11.240 align:middle line:90% Any questions? 00:36:11.240 --> 00:36:14.210 align:middle line:90% 00:36:14.210 --> 00:36:19.110 align:middle line:84% So this is the new instance, new L prime. 00:36:19.110 --> 00:36:23.780 align:middle line:90% 00:36:23.780 --> 00:36:25.590 align:middle line:90% So for each I-- 00:36:25.590 --> 00:36:29.030 align:middle line:90% 00:36:29.030 --> 00:36:33.860 align:middle line:84% so the prover need to prove 1, 2, et cetera, to K 00:36:33.860 --> 00:36:35.770 align:middle line:90% are all in this L prime. 00:36:35.770 --> 00:36:54.320 align:middle line:90% 00:36:54.320 --> 00:36:55.470 align:middle line:90% Any questions? 00:36:55.470 --> 00:37:09.060 align:middle line:90% 00:37:09.060 --> 00:37:11.410 align:middle line:84% AUDIENCE: I just think we're going to recurse with this? 00:37:11.410 --> 00:37:15.760 align:middle line:84% And the idea is that the number K has remained the same 00:37:15.760 --> 00:37:17.720 align:middle line:84% and the witnesses are not throwing anything. 00:37:17.720 --> 00:37:18.970 align:middle line:90% ZHENGZHONG JIN: Good question. 00:37:18.970 --> 00:37:21.630 align:middle line:84% So if you do this recursion, it will loop forever. 00:37:21.630 --> 00:37:25.477 align:middle line:84% Because from the beginning, we have K instances. 00:37:25.477 --> 00:37:27.310 align:middle line:84% And then in the next level of the recursion, 00:37:27.310 --> 00:37:29.730 align:middle line:90% we still have K instances. 00:37:29.730 --> 00:37:31.440 align:middle line:84% AUDIENCE: [INAUDIBLE] bunch it up, maybe, 00:37:31.440 --> 00:37:32.660 align:middle line:90% like, you do it [INAUDIBLE]. 00:37:32.660 --> 00:37:33.660 align:middle line:90% ZHENGZHONG JIN: Exactly. 00:37:33.660 --> 00:37:37.320 align:middle line:90% So that's what we will do next. 00:37:37.320 --> 00:37:38.020 align:middle line:90% Any questions? 00:37:38.020 --> 00:37:42.853 align:middle line:84% AUDIENCE: So HQ is a hash of statements? 00:37:42.853 --> 00:37:43.770 align:middle line:90% ZHENGZHONG JIN: Sorry? 00:37:43.770 --> 00:37:44.453 align:middle line:90% AUDIENCE: HQ. 00:37:44.453 --> 00:37:45.370 align:middle line:90% ZHENGZHONG JIN: Right. 00:37:45.370 --> 00:37:47.130 align:middle line:90% So HQ is part of the statement. 00:37:47.130 --> 00:37:53.940 align:middle line:84% AUDIENCE: Is it the hash of the statement X1 to XK? 00:37:53.940 --> 00:37:57.347 align:middle line:84% ZHENGZHONG JIN: You mean, where is HQ comes from? 00:37:57.347 --> 00:37:57.930 align:middle line:90% AUDIENCE: Yes. 00:37:57.930 --> 00:37:58.805 align:middle line:90% ZHENGZHONG JIN: Good. 00:37:58.805 --> 00:38:03.570 align:middle line:90% So HQ is the same as HQ here. 00:38:03.570 --> 00:38:08.030 align:middle line:84% So initially, we have a bunch of statements from 1 to K, 00:38:08.030 --> 00:38:12.030 align:middle line:84% and each of them has NP witness from omega 1 to omega K. 00:38:12.030 --> 00:38:17.210 align:middle line:90% And we compute this PCP matrix. 00:38:17.210 --> 00:38:20.200 align:middle line:84% And for each column, we hash it to H1 to HL. 00:38:20.200 --> 00:38:23.210 align:middle line:90% 00:38:23.210 --> 00:38:31.850 align:middle line:84% And HQ is just the Q's column of this H1 to HQ, 00:38:31.850 --> 00:38:35.490 align:middle line:84% the index Q among these H1 to HQ. 00:38:35.490 --> 00:38:39.639 align:middle line:90% 00:38:39.639 --> 00:38:42.530 align:middle line:84% AUDIENCE: Can I see the local opening version of the SSB 00:38:42.530 --> 00:38:45.335 align:middle line:84% is some variant of the FHE fitting with a Merkle tree size? 00:38:45.335 --> 00:38:46.460 align:middle line:90% ZHENGZHONG JIN: Good, good. 00:38:46.460 --> 00:38:50.480 align:middle line:84% So that's what I'm going to talk about next. 00:38:50.480 --> 00:38:55.940 align:middle line:84% So now you may ask, so how do we construct such a SSV 00:38:55.940 --> 00:39:02.210 align:middle line:84% with a Merkle tree-style construction, 00:39:02.210 --> 00:39:04.120 align:middle line:84% because the construction I just showed you 00:39:04.120 --> 00:39:06.100 align:middle line:90% doesn't satisfy this property? 00:39:06.100 --> 00:39:08.490 align:middle line:90% So this is SSV. 00:39:08.490 --> 00:39:17.560 align:middle line:90% 00:39:17.560 --> 00:39:23.470 align:middle line:84% So SSV with this local opening property, 00:39:23.470 --> 00:39:27.460 align:middle line:84% so the idea is, if we build a hash like a Merkle tree 00:39:27.460 --> 00:39:31.005 align:middle line:84% then we have this local opening, so for example. 00:39:31.005 --> 00:39:35.620 align:middle line:90% 00:39:35.620 --> 00:39:41.630 align:middle line:84% The issue is how do we still have somewhere-- this somewhere 00:39:41.630 --> 00:39:44.740 align:middle line:90% so that is a binding property. 00:39:44.740 --> 00:39:47.140 align:middle line:84% So at each node of the tree, we are 00:39:47.140 --> 00:39:53.050 align:middle line:84% going to peek under the hood of FHE one of its children. 00:39:53.050 --> 00:40:00.410 align:middle line:84% So you can think, initially, we have some X1 to XK in the clear. 00:40:00.410 --> 00:40:03.220 align:middle line:90% 00:40:03.220 --> 00:40:07.380 align:middle line:84% So at each level, we're going to pick either 00:40:07.380 --> 00:40:11.830 align:middle line:84% its left child or right child for each node in this level. 00:40:11.830 --> 00:40:16.740 align:middle line:84% For example, in this level, so suppose this is your index I, 00:40:16.740 --> 00:40:18.990 align:middle line:84% then what we can do is for each node 00:40:18.990 --> 00:40:22.425 align:middle line:84% in this level we're going to pick the left child. 00:40:22.425 --> 00:40:25.150 align:middle line:90% 00:40:25.150 --> 00:40:28.265 align:middle line:84% And at this level, we're going to pick the right child. 00:40:28.265 --> 00:40:32.640 align:middle line:90% 00:40:32.640 --> 00:40:43.170 align:middle line:84% So at each level, we're going to have some homomorphic encryption 00:40:43.170 --> 00:40:50.640 align:middle line:84% of some bit, so some bit, B1 and so let's say this is B2. 00:40:50.640 --> 00:40:53.310 align:middle line:84% And each level, we're going to homomorphically evaluate 00:40:53.310 --> 00:41:01.220 align:middle line:84% this using this B1 and B2 to pick 00:41:01.220 --> 00:41:05.900 align:middle line:84% the children under the hood of FHE in the same way as before. 00:41:05.900 --> 00:41:09.385 align:middle line:84% So this can give you SSV with local opening. 00:41:09.385 --> 00:41:13.100 align:middle line:90% 00:41:13.100 --> 00:41:18.530 align:middle line:84% So one property we further require about this SSV 00:41:18.530 --> 00:41:23.990 align:middle line:84% is the local opening correctness. 00:41:23.990 --> 00:41:26.840 align:middle line:84% So we require this property because, remember, 00:41:26.840 --> 00:41:33.080 align:middle line:84% in the soundness proof we need to ensure if the proof is 00:41:33.080 --> 00:41:37.640 align:middle line:84% accepted in the third round, then the proof contains 00:41:37.640 --> 00:41:40.400 align:middle line:90% some opening of the SSV. 00:41:40.400 --> 00:41:45.560 align:middle line:84% And we need to show this opening must be consistent with the SSV 00:41:45.560 --> 00:41:46.760 align:middle line:90% extracted value. 00:41:46.760 --> 00:41:51.680 align:middle line:84% So originally, this is easy to ensure because the verifier sees 00:41:51.680 --> 00:41:53.160 align:middle line:90% the entire opening. 00:41:53.160 --> 00:41:57.540 align:middle line:84% But now it's not clear whether this can still hold. 00:41:57.540 --> 00:42:03.010 align:middle line:84% So now the verifier only sees a local opening of the SSV. 00:42:03.010 --> 00:42:06.810 align:middle line:84% So it does not see all of the X1 to XK. 00:42:06.810 --> 00:42:11.520 align:middle line:84% It only sees the root-to-leaf path of some XI. 00:42:11.520 --> 00:42:16.420 align:middle line:84% So we need a further local opening correctness. 00:42:16.420 --> 00:42:28.080 align:middle line:90% 00:42:28.080 --> 00:42:30.300 align:middle line:84% So the correctness of local opening 00:42:30.300 --> 00:42:39.150 align:middle line:84% says this SSV with local opening has some local verification 00:42:39.150 --> 00:42:40.410 align:middle line:90% algorithm. 00:42:40.410 --> 00:42:45.600 align:middle line:84% So it will take the hash root of H 00:42:45.600 --> 00:42:50.820 align:middle line:84% and some index I, and XI, and the root-to-leaf path 00:42:50.820 --> 00:42:52.180 align:middle line:90% for this XI. 00:42:52.180 --> 00:42:56.640 align:middle line:84% And it can decide whether to accept or reject. 00:42:56.640 --> 00:43:00.800 align:middle line:84% And the local opening property says that for any index 00:43:00.800 --> 00:43:21.680 align:middle line:84% I, H, XI, and rho I, so if this local verification passes, 00:43:21.680 --> 00:43:36.020 align:middle line:84% then it must be case that the extracted value of the hash 00:43:36.020 --> 00:43:37.500 align:middle line:90% equals this XI. 00:43:37.500 --> 00:43:49.880 align:middle line:84% So here, so the local verification 00:43:49.880 --> 00:43:54.800 align:middle line:84% also need to use the SSV key to check this. 00:43:54.800 --> 00:43:57.940 align:middle line:90% 00:43:57.940 --> 00:44:03.550 align:middle line:84% So here, if this is true and the SSV key 00:44:03.550 --> 00:44:16.750 align:middle line:84% is generated for the index I, if the local replication passes, 00:44:16.750 --> 00:44:19.220 align:middle line:84% then the extracted value must be XI. 00:44:19.220 --> 00:44:21.650 align:middle line:84% So this is not trivially correct. 00:44:21.650 --> 00:44:24.970 align:middle line:84% This is not trivially hold if you use just this construction 00:44:24.970 --> 00:44:30.370 align:middle line:84% because a malicious file, it will 00:44:30.370 --> 00:44:34.300 align:middle line:84% contain the root-to-leaf path to this XI. 00:44:34.300 --> 00:44:38.060 align:middle line:84% But it also needs to contain the siblings of this. 00:44:38.060 --> 00:44:40.450 align:middle line:84% So in this authenticated path, it also 00:44:40.450 --> 00:44:44.780 align:middle line:84% need to contain the siblings of each node in the path. 00:44:44.780 --> 00:44:49.120 align:middle line:84% But those siblings may not be well-formed FHE ciphertext. 00:44:49.120 --> 00:44:53.035 align:middle line:84% So indeed, you need to further add some bootstrap mechanism 00:44:53.035 --> 00:44:53.535 align:middle line:90% here. 00:44:53.535 --> 00:44:57.160 align:middle line:90% 00:44:57.160 --> 00:45:00.940 align:middle line:84% So at each level of the FHE, you need to use a different FHE key. 00:45:00.940 --> 00:45:04.740 align:middle line:84% And at the next level, you need to homomorphically decrypt 00:45:04.740 --> 00:45:07.290 align:middle line:84% the FHE ciphertext at the previous level 00:45:07.290 --> 00:45:09.520 align:middle line:84% to ensure it's a well-formed ciphertext. 00:45:09.520 --> 00:45:13.500 align:middle line:84% So I'm not going to the details, but you can fix this easily 00:45:13.500 --> 00:45:14.230 align:middle line:90% by your own. 00:45:14.230 --> 00:45:18.930 align:middle line:90% 00:45:18.930 --> 00:45:25.516 align:middle line:84% So now, any question with this construction? 00:45:25.516 --> 00:45:31.650 align:middle line:84% AUDIENCE: Why are we now using SSV in a Merkle tree style 00:45:31.650 --> 00:45:33.710 align:middle line:90% instead of? 00:45:33.710 --> 00:45:34.960 align:middle line:90% ZHENGZHONG JIN: Good question. 00:45:34.960 --> 00:45:39.600 align:middle line:84% So if you directly use SSV in a Merkle tree style, 00:45:39.600 --> 00:45:44.460 align:middle line:84% maybe there are some ciphertext sites blow up. 00:45:44.460 --> 00:45:49.125 align:middle line:84% So each time the ciphertext size is lambda times larger than the. 00:45:49.125 --> 00:45:54.130 align:middle line:84% AUDIENCE: I mean, in this new version index BARG, 00:45:54.130 --> 00:45:56.870 align:middle line:90% why now when we hash the column? 00:45:56.870 --> 00:45:58.330 align:middle line:84% We hash it in the Merkle tree side 00:45:58.330 --> 00:46:03.640 align:middle line:90% instead of hashing it in one? 00:46:03.640 --> 00:46:07.790 align:middle line:84% ZHENGZHONG JIN: You mean, we don't hash it entirely. 00:46:07.790 --> 00:46:09.470 align:middle line:84% We hash in the Merkle tree style. 00:46:09.470 --> 00:46:09.910 align:middle line:90% AUDIENCE: Yes, yes. 00:46:09.910 --> 00:46:10.952 align:middle line:90% ZHENGZHONG JIN: Yes, yes. 00:46:10.952 --> 00:46:12.580 align:middle line:90% Yes, that's what we are doing. 00:46:12.580 --> 00:46:17.180 align:middle line:90% 00:46:17.180 --> 00:46:17.990 align:middle line:90% Any questions? 00:46:17.990 --> 00:46:25.210 align:middle line:90% 00:46:25.210 --> 00:46:27.160 align:middle line:84% So if you do this construction directly, 00:46:27.160 --> 00:46:29.830 align:middle line:84% then this construction will loop forever 00:46:29.830 --> 00:46:32.390 align:middle line:84% because the recursion will never end. 00:46:32.390 --> 00:46:34.040 align:middle line:84% So initially, we have K instances. 00:46:34.040 --> 00:46:36.550 align:middle line:84% And at the next level, it still has K instances. 00:46:36.550 --> 00:46:41.470 align:middle line:84% So next, what we will do is we will use a 2-to-1 trick 00:46:41.470 --> 00:46:44.095 align:middle line:84% to reduce the number of instances each time. 00:46:44.095 --> 00:47:06.210 align:middle line:90% 00:47:06.210 --> 00:47:08.380 align:middle line:90% So let's denote this circuit. 00:47:08.380 --> 00:47:14.380 align:middle line:84% So this part of the circuit has some C prime. 00:47:14.380 --> 00:47:18.490 align:middle line:84% So C prime will take some index I and the witness WI prime. 00:47:18.490 --> 00:47:21.610 align:middle line:84% So the witness WI prime corresponds to this part. 00:47:21.610 --> 00:47:29.290 align:middle line:90% So this part is the WI prime 00:47:29.290 --> 00:47:32.960 align:middle line:90% So the 2-to-1 trick is this. 00:47:32.960 --> 00:47:41.280 align:middle line:90% 00:47:41.280 --> 00:47:43.720 align:middle line:90% Suppose you have K instances. 00:47:43.720 --> 00:47:52.010 align:middle line:90% 00:47:52.010 --> 00:47:57.770 align:middle line:84% So now you want to verify all of them So you have instance from 1 00:47:57.770 --> 00:48:03.390 align:middle line:84% to K, and their witness are W1 prime to WK prime. 00:48:03.390 --> 00:48:06.680 align:middle line:84% So the prover wants to prove to the verifier that all of them 00:48:06.680 --> 00:48:10.760 align:middle line:84% are correct, are in this language L prime. 00:48:10.760 --> 00:48:19.790 align:middle line:84% So what do you do is you look at any two adjacent indices 00:48:19.790 --> 00:48:23.880 align:middle line:90% instances and just combine them. 00:48:23.880 --> 00:48:27.572 align:middle line:90% 00:48:27.572 --> 00:48:33.470 align:middle line:84% So now, the combined instance is still 1, 00:48:33.470 --> 00:48:37.950 align:middle line:84% but the witnesses are concatenated together. 00:48:37.950 --> 00:48:43.310 align:middle line:84% So you have this W1 prime and W2 prime. 00:48:43.310 --> 00:48:49.890 align:middle line:84% And the next two instances are 3 and 4. 00:48:49.890 --> 00:48:53.840 align:middle line:84% So you have these 3 prime and W4 prime. 00:48:53.840 --> 00:48:56.830 align:middle line:90% 00:48:56.830 --> 00:49:00.820 align:middle line:84% And the final one is the K and WK. 00:49:00.820 --> 00:49:06.270 align:middle line:84% So you combine each adjacent one to get the second instance. 00:49:06.270 --> 00:49:10.720 align:middle line:90% 00:49:10.720 --> 00:49:13.760 align:middle line:84% And you do this for any two of them. 00:49:13.760 --> 00:49:18.400 align:middle line:84% So in the end, you have K-by-2 instances. 00:49:18.400 --> 00:49:22.570 align:middle line:84% But the cost of doing this is the size of the witness 00:49:22.570 --> 00:49:24.835 align:middle line:90% will blow up by a factor of 2. 00:49:24.835 --> 00:49:29.690 align:middle line:90% 00:49:29.690 --> 00:49:35.050 align:middle line:84% So let's say the original language is L prime, 00:49:35.050 --> 00:49:40.220 align:middle line:84% so it contains of I such that there exists WI prime. 00:49:40.220 --> 00:49:50.380 align:middle line:90% 00:49:50.380 --> 00:49:53.860 align:middle line:84% So C prime is the verification circuit of L prime. 00:49:53.860 --> 00:50:00.520 align:middle line:84% Then here the new instances is the following. 00:50:00.520 --> 00:50:05.700 align:middle line:84% So it defines a new language, L double prime. 00:50:05.700 --> 00:50:08.910 align:middle line:84% So double prime is still contains of I, 00:50:08.910 --> 00:50:19.890 align:middle line:84% but the witness are 2I minus 1 and 2I and W2I, 2I prime. 00:50:19.890 --> 00:50:22.950 align:middle line:90% 00:50:22.950 --> 00:50:28.680 align:middle line:84% So this concatenation witness is the new NP witness 00:50:28.680 --> 00:50:30.270 align:middle line:90% for this L double prime. 00:50:30.270 --> 00:50:36.270 align:middle line:84% And then you need to verify C prime of this 2I minus 1, 00:50:36.270 --> 00:50:39.120 align:middle line:90% W2I minus 1 is 1. 00:50:39.120 --> 00:50:45.030 align:middle line:90% And also, 2I and the 2I is 1. 00:50:45.030 --> 00:50:49.210 align:middle line:90% 00:50:49.210 --> 00:50:54.790 align:middle line:84% So by doing this, the size of the number of the instances 00:50:54.790 --> 00:50:57.050 align:middle line:84% will halve each time when you do the recursion. 00:50:57.050 --> 00:51:01.550 align:middle line:90% 00:51:01.550 --> 00:51:05.690 align:middle line:84% So in fact, we will prove this for L double prime. 00:51:05.690 --> 00:51:11.150 align:middle line:84% And we only prove for 1 to K by 2. 00:51:11.150 --> 00:51:18.130 align:middle line:84% They are all in L double prime in the recursion. 00:51:18.130 --> 00:51:19.605 align:middle line:90% So that's what we will do. 00:51:19.605 --> 00:51:24.466 align:middle line:90% 00:51:24.466 --> 00:51:35.290 align:middle line:84% So now the question is, at each level of the recursion, 00:51:35.290 --> 00:51:36.830 align:middle line:84% the number of instances will halve. 00:51:36.830 --> 00:51:39.290 align:middle line:84% So at the end, there will only be one instance. 00:51:39.290 --> 00:51:41.775 align:middle line:84% So what will we do at that point? 00:51:41.775 --> 00:51:44.350 align:middle line:90% 00:51:44.350 --> 00:51:45.530 align:middle line:90% Anyone know? 00:51:45.530 --> 00:51:47.337 align:middle line:84% AUDIENCE: We wrap it and we use that? 00:51:47.337 --> 00:51:48.045 align:middle line:90% ZHENGZHONG JIN: ? 00:51:48.045 --> 00:51:48.560 align:middle line:90% Yes, yes. 00:51:48.560 --> 00:51:52.855 align:middle line:84% So we directly send the witness, and the verifier can verify it. 00:51:52.855 --> 00:52:00.130 align:middle line:90% 00:52:00.130 --> 00:52:04.480 align:middle line:84% So this is the construction, and let's calculate the proof size 00:52:04.480 --> 00:52:05.660 align:middle line:90% for this construction. 00:52:05.660 --> 00:52:19.240 align:middle line:90% 00:52:19.240 --> 00:52:26.230 align:middle line:84% So initially, we send this H1 to HL. 00:52:26.230 --> 00:52:38.650 align:middle line:84% So the size of that is poly C and lambda. 00:52:38.650 --> 00:52:45.865 align:middle line:84% And we have this Q computed by the CI hash. 00:52:45.865 --> 00:52:53.870 align:middle line:90% 00:52:53.870 --> 00:52:56.010 align:middle line:84% So at the next level of the recursion, 00:52:56.010 --> 00:53:02.270 align:middle line:84% we will also have this first round message for that. 00:53:02.270 --> 00:53:09.020 align:middle line:90% So let's denote it by HI prime. 00:53:09.020 --> 00:53:12.080 align:middle line:84% So what's the size of this message? 00:53:12.080 --> 00:53:16.550 align:middle line:84% So remember, this is the index BARG for L double prime. 00:53:16.550 --> 00:53:20.485 align:middle line:84% And it has the verification circuit, C double prime. 00:53:20.485 --> 00:53:25.250 align:middle line:90% 00:53:25.250 --> 00:53:28.090 align:middle line:84% So what is the size of this message? 00:53:28.090 --> 00:53:33.680 align:middle line:90% 00:53:33.680 --> 00:53:35.326 align:middle line:90% So this is efficiency. 00:53:35.326 --> 00:53:45.650 align:middle line:90% 00:53:45.650 --> 00:53:47.720 align:middle line:84% So in the next level of recursion, 00:53:47.720 --> 00:53:52.250 align:middle line:84% we will do the same using the same protocol. 00:53:52.250 --> 00:53:55.420 align:middle line:84% So originally, the NP verification circuit 00:53:55.420 --> 00:53:58.160 align:middle line:84% is C, so we have first round message this much. 00:53:58.160 --> 00:54:00.700 align:middle line:84% So in the next level, the NP verification circuit 00:54:00.700 --> 00:54:02.890 align:middle line:90% is C double prime. 00:54:02.890 --> 00:54:11.980 align:middle line:84% So the size of this message is poly C double prime lambda. 00:54:11.980 --> 00:54:16.340 align:middle line:84% But there is an issue if you do this recursion directly. 00:54:16.340 --> 00:54:21.495 align:middle line:84% So let's examine what is the size of C double prime. 00:54:21.495 --> 00:54:24.290 align:middle line:90% 00:54:24.290 --> 00:54:30.440 align:middle line:84% So each C double prime will contain two copy of C, C prime, 00:54:30.440 --> 00:54:33.555 align:middle line:90% so C double prime. 00:54:33.555 --> 00:54:45.440 align:middle line:90% 00:54:45.440 --> 00:54:50.040 align:middle line:90% So this is the C double prime. 00:54:50.040 --> 00:54:54.320 align:middle line:84% So it will take index I and this as the witness, 00:54:54.320 --> 00:54:56.100 align:middle line:90% and verify these two things. 00:54:56.100 --> 00:55:05.120 align:middle line:84% So the size of C double prime is roughly 2 times C. So 00:55:05.120 --> 00:55:07.450 align:middle line:90% what is the size of C prime? 00:55:07.450 --> 00:55:09.980 align:middle line:90% 00:55:09.980 --> 00:55:12.440 align:middle line:90% So C prime is here. 00:55:12.440 --> 00:55:17.130 align:middle line:84% So the first part of C prime is the PCP verification. 00:55:17.130 --> 00:55:23.150 align:middle line:84% So here we will have an issue because the PCP verifier 00:55:23.150 --> 00:55:25.200 align:middle line:84% need to know what is the NP relation. 00:55:25.200 --> 00:55:27.660 align:middle line:84% So the PCP verifier runs in C time. 00:55:27.660 --> 00:55:31.892 align:middle line:90% 00:55:31.892 --> 00:55:40.270 align:middle line:84% So we will have an issue here because the C prime is roughly 00:55:40.270 --> 00:55:44.050 align:middle line:90% C, at least C. 00:55:44.050 --> 00:55:49.250 align:middle line:84% So if we do this directly, so you can think, at the top level, 00:55:49.250 --> 00:55:54.670 align:middle line:84% we have this poly C. And at the next level we have this poly C 00:55:54.670 --> 00:55:57.610 align:middle line:90% prime, which is 2C. 00:55:57.610 --> 00:55:59.660 align:middle line:90% So this is 2C. 00:55:59.660 --> 00:56:02.920 align:middle line:84% And at next level of recursion, we'll have 4C. 00:56:02.920 --> 00:56:07.480 align:middle line:84% So we'll have log K level of recursion, 00:56:07.480 --> 00:56:09.765 align:middle line:84% because each time the number of instance halves. 00:56:09.765 --> 00:56:12.880 align:middle line:90% 00:56:12.880 --> 00:56:15.770 align:middle line:84% So the depth is log K. So in the end, 00:56:15.770 --> 00:56:19.630 align:middle line:84% we have K times C, which is large. 00:56:19.630 --> 00:56:25.630 align:middle line:84% So the proof will grow with K times C, which is large. 00:56:25.630 --> 00:56:28.780 align:middle line:84% So the final idea is we are going to use 00:56:28.780 --> 00:56:31.880 align:middle line:90% PCP with some special property. 00:56:31.880 --> 00:56:36.370 align:middle line:84% So this kind of PCP has this online/offline verification 00:56:36.370 --> 00:56:36.920 align:middle line:90% property. 00:56:36.920 --> 00:56:47.230 align:middle line:84% So this is called PCP with faster online verification. 00:56:47.230 --> 00:56:51.780 align:middle line:90% 00:56:51.780 --> 00:56:59.040 align:middle line:84% So this PCP has the property that, so for any PCP prover 00:56:59.040 --> 00:57:02.700 align:middle line:84% and verifier, so given any NP instance X and W, 00:57:02.700 --> 00:57:06.190 align:middle line:90% you can generate a long proof. 00:57:06.190 --> 00:57:10.620 align:middle line:84% So this is just a normal PCP, but the verification algorithm 00:57:10.620 --> 00:57:14.920 align:middle line:90% of the PCP has more structure. 00:57:14.920 --> 00:57:19.170 align:middle line:84% So the verification algorithm, so originally the PCP verifier 00:57:19.170 --> 00:57:24.600 align:middle line:84% need to verify for X, Q, and the PCP Q. 00:57:24.600 --> 00:57:30.250 align:middle line:84% So now the PCP verifier can be decomposed to two parts. 00:57:30.250 --> 00:57:34.470 align:middle line:84% So first, so there is an offline preprocessing phase. 00:57:34.470 --> 00:57:36.630 align:middle line:84% So the preprocessing phase only depends 00:57:36.630 --> 00:57:50.670 align:middle line:84% on this relation circuit C. So this is PCP for the language L. 00:57:50.670 --> 00:57:55.200 align:middle line:84% So the preprocessing phase will take the relation circuit 00:57:55.200 --> 00:57:56.110 align:middle line:90% as input. 00:57:56.110 --> 00:58:01.470 align:middle line:84% And it will use the query to generate some state. 00:58:01.470 --> 00:58:03.700 align:middle line:90% And this state will only grow-- 00:58:03.700 --> 00:58:09.585 align:middle line:84% the size of the state is polynomial in X. 00:58:09.585 --> 00:58:15.120 align:middle line:84% So the point is, so in some case when the relation circuit is 00:58:15.120 --> 00:58:18.270 align:middle line:84% very large, so the preprocessing phase 00:58:18.270 --> 00:58:21.520 align:middle line:84% will run in the size of the relation circuit, 00:58:21.520 --> 00:58:25.560 align:middle line:84% but it will output a very short state. 00:58:25.560 --> 00:58:28.450 align:middle line:84% And the secondly, in the online phase, 00:58:28.450 --> 00:58:30.780 align:middle line:84% there is an online verification part. 00:58:30.780 --> 00:58:32.490 align:middle line:84% So the online verification will only 00:58:32.490 --> 00:58:44.380 align:middle line:84% use such a short state and X and Q and the PCP answer 00:58:44.380 --> 00:58:47.450 align:middle line:84% to decide whether to accept or reject. 00:58:47.450 --> 00:58:54.640 align:middle line:84% So the point is, it's a polynomial time 00:58:54.640 --> 00:59:01.480 align:middle line:84% algorithm, which means it only depends on X and the size of Q. 00:59:01.480 --> 00:59:06.100 align:middle line:84% So you can imagine if C is a very big circuit 00:59:06.100 --> 00:59:08.860 align:middle line:84% and the X instance is small, then 00:59:08.860 --> 00:59:14.410 align:middle line:84% this means the preprocessing phase will take 00:59:14.410 --> 00:59:17.960 align:middle line:84% most of the time, but the online verification will be very fast. 00:59:17.960 --> 00:59:22.810 align:middle line:84% It only depends on the instance size and the size of the query. 00:59:22.810 --> 00:59:25.120 align:middle line:84% So this property is satisfied by most 00:59:25.120 --> 00:59:27.820 align:middle line:84% of the algebraic construction of PCP. 00:59:27.820 --> 00:59:32.980 align:middle line:90% So any questions? 00:59:32.980 --> 00:59:34.550 align:middle line:84% So I will not go into the detail. 00:59:34.550 --> 00:59:37.970 align:middle line:90% 00:59:37.970 --> 00:59:41.450 align:middle line:84% So in fact, this property is used in many practical SNARG 00:59:41.450 --> 00:59:42.290 align:middle line:90% construction. 00:59:42.290 --> 00:59:44.540 align:middle line:84% Because in the practical SNARG construction, 00:59:44.540 --> 00:59:48.230 align:middle line:84% they also need to use PCP or some form of the PCP, 00:59:48.230 --> 00:59:49.910 align:middle line:90% such as linear PCP. 00:59:49.910 --> 00:59:52.430 align:middle line:84% So in this construction, you also 00:59:52.430 --> 00:59:55.200 align:middle line:84% have the problem that the relation circuit is very large, 00:59:55.200 --> 00:59:57.360 align:middle line:84% but you want the verification to be small. 00:59:57.360 --> 01:00:00.020 align:middle line:84% So what they do is they can do some preprocessing 01:00:00.020 --> 01:00:04.530 align:middle line:84% on the relation to generate some short verification state. 01:00:04.530 --> 01:00:05.940 align:middle line:84% And given the verification state, 01:00:05.940 --> 01:00:08.485 align:middle line:84% you can verify the statement in a short time. 01:00:08.485 --> 01:00:14.711 align:middle line:90% 01:00:14.711 --> 01:00:23.875 align:middle line:84% So now we will use this PCP further with this property. 01:00:23.875 --> 01:00:29.570 align:middle line:90% 01:00:29.570 --> 01:00:33.640 align:middle line:84% Then we can further modify the construction 01:00:33.640 --> 01:00:37.010 align:middle line:84% to only do the online verification here in C prime. 01:00:37.010 --> 01:00:52.090 align:middle line:90% 01:00:52.090 --> 01:00:56.500 align:middle line:84% So what we will do here is we first generate the CI hash, 01:00:56.500 --> 01:00:59.290 align:middle line:84% using the CI hash to generate Q. And then 01:00:59.290 --> 01:01:03.195 align:middle line:84% we do the preprocessing to this Q to generate some short state. 01:01:03.195 --> 01:01:06.340 align:middle line:90% 01:01:06.340 --> 01:01:09.650 align:middle line:84% And this will use the relation circuit C. 01:01:09.650 --> 01:01:13.270 align:middle line:84% So we can do this because we use the same PCP 01:01:13.270 --> 01:01:16.650 align:middle line:90% query for all of the PCPs. 01:01:16.650 --> 01:01:19.600 align:middle line:90% 01:01:19.600 --> 01:01:22.880 align:middle line:84% So for all of the PCPs, they are using the same PCP query, 01:01:22.880 --> 01:01:25.040 align:middle line:90% so I can do this preprocessing. 01:01:25.040 --> 01:01:29.200 align:middle line:90% 01:01:29.200 --> 01:01:32.050 align:middle line:84% So once I have this a short state, 01:01:32.050 --> 01:01:35.230 align:middle line:84% I can hardcode it in this construction of C prime. 01:01:35.230 --> 01:01:40.560 align:middle line:84% So I will replace this with the online verification. 01:01:40.560 --> 01:01:41.440 align:middle line:90% Sorry. 01:01:41.440 --> 01:01:46.260 align:middle line:90% So this is a local verification. 01:01:46.260 --> 01:01:48.680 align:middle line:84% So this is online verification of the PCP. 01:01:48.680 --> 01:01:53.130 align:middle line:90% 01:01:53.130 --> 01:01:59.250 align:middle line:84% So it will take the state of the rest. 01:01:59.250 --> 01:02:02.400 align:middle line:84% So now this will solve this recursion issue, 01:02:02.400 --> 01:02:09.090 align:middle line:84% because now the circuit C prime will not depend on C. Instead, 01:02:09.090 --> 01:02:21.390 align:middle line:84% it will be polylog in C. So you can check here because C prime, 01:02:21.390 --> 01:02:24.510 align:middle line:84% it will only involve online verification. 01:02:24.510 --> 01:02:38.250 align:middle line:84% So it's a polynomial in the length of I, which is log K. 01:02:38.250 --> 01:02:43.080 align:middle line:84% And the local verification of the Merkle hash is also small. 01:02:43.080 --> 01:02:49.310 align:middle line:84% So it's also some polylog in K. So you can check. 01:02:49.310 --> 01:02:54.890 align:middle line:84% So this is a polylog of K and lambda. 01:02:54.890 --> 01:03:00.110 align:middle line:84% And you can take this recursion inside of this analysis 01:03:00.110 --> 01:03:16.040 align:middle line:84% and see, finally, the total proof size is poly log in C 01:03:16.040 --> 01:03:20.530 align:middle line:84% and poly log in K and polynomial in lambda. 01:03:20.530 --> 01:03:23.990 align:middle line:90% 01:03:23.990 --> 01:03:26.330 align:middle line:84% AUDIENCE: Plus, the length of one witness or-- oh, I 01:03:26.330 --> 01:03:29.640 align:middle line:84% guess it's also poly in C. Like the base case, 01:03:29.640 --> 01:03:31.200 align:middle line:90% you said the witness, right? 01:03:31.200 --> 01:03:32.280 align:middle line:90% ZHENGZHONG JIN: Yes, yes. 01:03:32.280 --> 01:03:33.738 align:middle line:84% AUDIENCE: That's already populated. 01:03:33.738 --> 01:03:37.770 align:middle line:84% ZHENGZHONG JIN: So in fact, after you do this once, 01:03:37.770 --> 01:03:40.080 align:middle line:84% at one level of the recursion the witness 01:03:40.080 --> 01:03:43.620 align:middle line:84% is already very small, because the witness is just 01:03:43.620 --> 01:03:44.770 align:middle line:90% the PCP opening. 01:03:44.770 --> 01:03:51.000 align:middle line:84% So it's polylog C. So finally, at the end the final level 01:03:51.000 --> 01:03:52.265 align:middle line:90% witness is also very small. 01:03:52.265 --> 01:04:05.250 align:middle line:90% 01:04:05.250 --> 01:04:09.520 align:middle line:84% So I probably don't have time to cover all of the security proof, 01:04:09.520 --> 01:04:12.370 align:middle line:84% but I will show you the most important part of it. 01:04:12.370 --> 01:04:16.620 align:middle line:90% 01:04:16.620 --> 01:04:23.070 align:middle line:84% So how do we prove the security of this construction? 01:04:23.070 --> 01:04:24.785 align:middle line:90% So now the construction is here. 01:04:24.785 --> 01:04:30.990 align:middle line:90% 01:04:30.990 --> 01:04:34.020 align:middle line:84% So suppose we have some security of this index BARG, 01:04:34.020 --> 01:04:35.930 align:middle line:84% then maybe we can use it recursively 01:04:35.930 --> 01:04:38.300 align:middle line:84% to prove the security of the entire construction. 01:04:38.300 --> 01:04:41.270 align:middle line:90% But we have an issue here. 01:04:41.270 --> 01:04:44.270 align:middle line:84% So the issue is L double prime, it 01:04:44.270 --> 01:04:46.295 align:middle line:84% will depend on the first message. 01:04:46.295 --> 01:04:49.776 align:middle line:90% 01:04:49.776 --> 01:04:54.050 align:middle line:84% So L double prime will use this L prime, so this C prime. 01:04:54.050 --> 01:04:58.110 align:middle line:84% So this C prime will use the hash root, this HQ. 01:04:58.110 --> 01:05:02.743 align:middle line:84% So this hash root comes from this hash value and of the H1 01:05:02.743 --> 01:05:04.730 align:middle line:90% to HL. 01:05:04.730 --> 01:05:11.540 align:middle line:84% So this means the adversary can potentially 01:05:11.540 --> 01:05:15.080 align:middle line:84% choose the next statement, depends on the CRS 01:05:15.080 --> 01:05:18.230 align:middle line:84% because CRS is first send to the adversary. 01:05:18.230 --> 01:05:21.870 align:middle line:84% So this is not captured by the non-adaptive soundness before. 01:05:21.870 --> 01:05:23.910 align:middle line:84% So we need a new definition of soundness. 01:05:23.910 --> 01:05:37.900 align:middle line:90% 01:05:37.900 --> 01:05:39.460 align:middle line:84% And the issue is that we don't know 01:05:39.460 --> 01:05:41.900 align:middle line:84% how to achieve fully adaptive soundness. 01:05:41.900 --> 01:05:45.280 align:middle line:84% So the adaptive soundness means that the cheating adversary 01:05:45.280 --> 01:05:49.630 align:middle line:84% can choose the instance, depending on the CRS. 01:05:49.630 --> 01:05:53.360 align:middle line:84% So what we prove is some semi-adaptive soundness. 01:05:53.360 --> 01:06:03.730 align:middle line:90% 01:06:03.730 --> 01:06:07.810 align:middle line:84% So this soundness notion is not only important in this security 01:06:07.810 --> 01:06:11.090 align:middle line:84% proof, but will also be crucial for your next lecture. 01:06:11.090 --> 01:06:19.120 align:middle line:84% So when you compile this batch index of SNARG for P. 01:06:19.120 --> 01:06:21.640 align:middle line:90% So it's defined as follows. 01:06:21.640 --> 01:06:24.900 align:middle line:84% So it says that it allows the cheating prover to choose 01:06:24.900 --> 01:06:29.550 align:middle line:84% the relation circuit, but it cannot choose which index 01:06:29.550 --> 01:06:30.690 align:middle line:90% to cheat. 01:06:30.690 --> 01:06:34.210 align:middle line:90% So let me define it. 01:06:34.210 --> 01:07:03.390 align:middle line:84% So we say, index BARG is sound if there exists if. 01:07:03.390 --> 01:07:07.980 align:middle line:84% So first, I need another key generation algorithm, 01:07:07.980 --> 01:07:10.350 align:middle line:90% CRS generator. 01:07:10.350 --> 01:07:14.760 align:middle line:90% So I'll call it generate bar. 01:07:14.760 --> 01:07:20.520 align:middle line:84% So it will take the security parameter as input and index I 01:07:20.520 --> 01:07:23.005 align:middle line:84% star, and will generate some CRS star. 01:07:23.005 --> 01:07:33.110 align:middle line:90% 01:07:33.110 --> 01:07:39.020 align:middle line:84% And this CRS generator is indistinguishable 01:07:39.020 --> 01:07:43.023 align:middle line:90% with the real CRS. 01:07:43.023 --> 01:07:46.580 align:middle line:90% 01:07:46.580 --> 01:07:53.510 align:middle line:84% And furthermore, for each non-uniform PPT adversary 01:07:53.510 --> 01:07:57.235 align:middle line:84% cheating prover, P star, we need to have the following property. 01:07:57.235 --> 01:07:59.930 align:middle line:90% 01:07:59.930 --> 01:08:13.160 align:middle line:84% So when P star receives the CRS generated by this generator 01:08:13.160 --> 01:08:21.660 align:middle line:84% star, it can choose as relation circuit C 01:08:21.660 --> 01:08:25.470 align:middle line:84% and a maliciously chosen relation circuit 01:08:25.470 --> 01:08:34.140 align:middle line:84% C and pi star such that the probability 01:08:34.140 --> 01:08:46.290 align:middle line:84% that the verifier, except for this K 01:08:46.290 --> 01:08:53.279 align:middle line:84% and the I star instance is not in the relation circuit defined 01:08:53.279 --> 01:08:57.490 align:middle line:90% by this C star is negligible. 01:08:57.490 --> 01:09:18.330 align:middle line:90% 01:09:18.330 --> 01:09:21.680 align:middle line:84% The intuition is that the SSV is binding for some location, 01:09:21.680 --> 01:09:23.460 align:middle line:90% for some instance. 01:09:23.460 --> 01:09:26.899 align:middle line:84% So you just set the generator bar 01:09:26.899 --> 01:09:30.569 align:middle line:84% as the generator that outputs that kind of SSV. 01:09:30.569 --> 01:09:33.390 align:middle line:84% So the SSV will be binding for the I star's position. 01:09:33.390 --> 01:09:35.770 align:middle line:84% Then you cannot cheat for the I star instance. 01:09:35.770 --> 01:09:39.860 align:middle line:90% 01:09:39.860 --> 01:09:45.800 align:middle line:84% So the cheating prover can choose a relation circuit C, 01:09:45.800 --> 01:09:49.315 align:middle line:84% but it cannot cheat for the I-th star's position. 01:09:49.315 --> 01:09:55.220 align:middle line:90% 01:09:55.220 --> 01:09:57.180 align:middle line:84% That's the semi-adaptive soundness. 01:09:57.180 --> 01:10:00.560 align:middle line:84% So to prove this soundness for this construction, 01:10:00.560 --> 01:10:06.530 align:middle line:84% the idea is that for any I star that is not in the language, 01:10:06.530 --> 01:10:11.810 align:middle line:84% you can see from the correlation intractability, 01:10:11.810 --> 01:10:15.390 align:middle line:84% essentially the idea is that if I star is not in the language, 01:10:15.390 --> 01:10:24.460 align:middle line:84% and for any cheating proof, you just 01:10:24.460 --> 01:10:29.830 align:middle line:84% switch this generator for this I star. 01:10:29.830 --> 01:10:34.510 align:middle line:84% And you can argue, if I star is not in the language, 01:10:34.510 --> 01:10:38.470 align:middle line:90% then I star over 2. 01:10:38.470 --> 01:10:42.100 align:middle line:84% Because we do the 2-to-1 trick, it will translate to a new 01:10:42.100 --> 01:10:53.830 align:middle line:84% instance at the next level, then it's also not in the L double 01:10:53.830 --> 01:10:54.550 align:middle line:90% prime. 01:10:54.550 --> 01:10:58.570 align:middle line:84% So if the adversary doesn't cheat for the CR hash. 01:10:58.570 --> 01:11:00.015 align:middle line:90% So that's the idea. 01:11:00.015 --> 01:11:20.160 align:middle line:90% 01:11:20.160 --> 01:11:26.040 align:middle line:84% So if the query and the hash values output by the cheating 01:11:26.040 --> 01:11:32.100 align:middle line:84% prover does not satisfy the CR hash relation R, 01:11:32.100 --> 01:11:34.320 align:middle line:90% then you have this. 01:11:34.320 --> 01:11:38.610 align:middle line:84% Then if I star's position is forced 01:11:38.610 --> 01:11:45.240 align:middle line:84% to translate to another new false statement, 01:11:45.240 --> 01:11:51.300 align:middle line:84% you can use this claim to inductively argue that, 01:11:51.300 --> 01:11:53.520 align:middle line:84% initially, if you have some fixed I star, 01:11:53.520 --> 01:11:58.320 align:middle line:84% then you can track this fixed I star at each level 01:11:58.320 --> 01:12:00.870 align:middle line:84% by dividing by 2 and round up to it. 01:12:00.870 --> 01:12:02.250 align:middle line:90% And finally, you can catch it. 01:12:02.250 --> 01:12:06.060 align:middle line:90% 01:12:06.060 --> 01:12:08.920 align:middle line:84% So in the last level of the recursion, 01:12:08.920 --> 01:12:11.320 align:middle line:90% we just send all the witness. 01:12:11.320 --> 01:12:14.670 align:middle line:90% So you must be able to catch it. 01:12:14.670 --> 01:12:16.720 align:middle line:90% So that's the idea. 01:12:16.720 --> 01:12:24.400 align:middle line:84% So that's all about the class today. 01:12:24.400 --> 01:12:25.520 align:middle line:90% Any questions? 01:12:25.520 --> 01:12:35.915 align:middle line:90% 01:12:35.915 --> 01:12:37.720 align:middle line:84% AUDIENCE: This is the full construction 01:12:37.720 --> 01:12:40.810 align:middle line:84% get any form of, like, the [INAUDIBLE] construction? 01:12:40.810 --> 01:12:43.120 align:middle line:84% AUDIENCE: Any sort of adaptive soundness? 01:12:43.120 --> 01:12:44.383 align:middle line:90% Or is it like a-- 01:12:44.383 --> 01:12:46.300 align:middle line:84% ZHENGZHONG JIN: Yes, so it only gets this kind 01:12:46.300 --> 01:12:47.355 align:middle line:90% of adaptive soundness. 01:12:47.355 --> 01:12:48.340 align:middle line:90% AUDIENCE: I see. 01:12:48.340 --> 01:12:53.207 align:middle line:84% Like, some notion of this for general BARGs [INAUDIBLE]. 01:12:53.207 --> 01:12:54.790 align:middle line:84% ZHENGZHONG JIN: So for the index BARG, 01:12:54.790 --> 01:13:02.500 align:middle line:84% we can get a semi adaptive soundness and for general BARGs, 01:13:02.500 --> 01:13:05.880 align:middle line:84% I think it also has some similar notion, I think. 01:13:05.880 --> 01:13:14.480 align:middle line:90% 01:13:14.480 --> 01:13:16.230 align:middle line:84% AUDIENCE: Is there some other construction 01:13:16.230 --> 01:13:17.310 align:middle line:90% that's adapted to sound? 01:13:17.310 --> 01:13:19.125 align:middle line:84% Or is it a very common thing to do? 01:13:19.125 --> 01:13:20.830 align:middle line:84% ZHENGZHONG JIN: That's a good question. 01:13:20.830 --> 01:13:23.590 align:middle line:84% So in general, given any non-adaptive sound SNARG, 01:13:23.590 --> 01:13:26.190 align:middle line:84% you can always upgrade it to adaptive sound 01:13:26.190 --> 01:13:29.476 align:middle line:90% by using complexity leveraging. 01:13:29.476 --> 01:13:34.410 align:middle line:84% But you will pay due to the instance size in the security 01:13:34.410 --> 01:13:36.768 align:middle line:90% proof. 01:13:36.768 --> 01:13:45.370 align:middle line:84% But in the BARGs, the total instance size is K times X. 01:13:45.370 --> 01:13:46.780 align:middle line:90% So it's very large. 01:13:46.780 --> 01:13:50.340 align:middle line:84% So I'm not sure you can really do that. 01:13:50.340 --> 01:13:51.370 align:middle line:90% AUDIENCE: I see. 01:13:51.370 --> 01:13:53.640 align:middle line:84% But is it clear priori, that [INAUDIBLE] 01:13:53.640 --> 01:13:55.660 align:middle line:84% only applies to adaptively sound? 01:13:55.660 --> 01:13:57.400 align:middle line:90% ZHENGZHONG JIN: So right, right. 01:13:57.400 --> 01:13:59.280 align:middle line:84% So there seems to be a gap, but I'm not 01:13:59.280 --> 01:14:00.825 align:middle line:90% sure how large is the gap. 01:14:00.825 --> 01:14:03.960 align:middle line:90% 01:14:03.960 --> 01:14:08.700 align:middle line:84% Maybe you can use it on clever complexity leveraging to almost 01:14:08.700 --> 01:14:11.780 align:middle line:90% close the gap, for example. 01:14:11.780 --> 01:14:14.000 align:middle line:90%