WEBVTT 00:00:00.000 --> 00:00:07.275 align:middle line:84% [SQUEAKING] [RUSTLING] [CLICKING] 00:00:07.275 --> 00:00:12.463 align:middle line:90% 00:00:12.463 --> 00:00:13.380 align:middle line:90% ZHENGZHONG JIN: So OK. 00:00:13.380 --> 00:00:14.310 align:middle line:90% So let's start. 00:00:14.310 --> 00:00:16.379 align:middle line:90% So I'm Zhengzhong Jin. 00:00:16.379 --> 00:00:20.600 align:middle line:84% And so today I will give the lecture about SNARGs 00:00:20.600 --> 00:00:22.735 align:middle line:90% for Batch NP or batch argument. 00:00:22.735 --> 00:00:26.690 align:middle line:90% 00:00:26.690 --> 00:00:28.705 align:middle line:84% So this lecture is about batch argument. 00:00:28.705 --> 00:00:37.310 align:middle line:90% 00:00:37.310 --> 00:00:43.948 align:middle line:84% And it has many different names, such BARGs. 00:00:43.948 --> 00:00:47.040 align:middle line:84% Or you can also call it SNARGs for Batch NP. 00:00:47.040 --> 00:00:56.200 align:middle line:90% 00:00:56.200 --> 00:01:01.720 align:middle line:84% So batch is a very basic concept in computer science. 00:01:01.720 --> 00:01:04.379 align:middle line:84% So basically if you have multiple items 00:01:04.379 --> 00:01:06.160 align:middle line:84% and you want to collect them together, 00:01:06.160 --> 00:01:08.200 align:middle line:84% then you can call this collection a batch. 00:01:08.200 --> 00:01:13.150 align:middle line:84% So there are similar ideas in, for example, in programming. 00:01:13.150 --> 00:01:16.780 align:middle line:84% So there are concepts like batch processing. 00:01:16.780 --> 00:01:21.010 align:middle line:84% And so it's a very common concept. 00:01:21.010 --> 00:01:26.950 align:middle line:84% So in this lecture, we'll talk about the batch argument. 00:01:26.950 --> 00:01:30.960 align:middle line:84% So it's a notion of batch in the proof system. 00:01:30.960 --> 00:01:37.200 align:middle line:84% So firstly, let me define what is a batch argument. 00:01:37.200 --> 00:01:41.760 align:middle line:90% So definition-- so a BARGs-- 00:01:41.760 --> 00:01:47.326 align:middle line:90% a BARG is a tuple of algorithms. 00:01:47.326 --> 00:01:58.150 align:middle line:90% 00:01:58.150 --> 00:02:01.720 align:middle line:84% So it consists of a generator and the prover 00:02:01.720 --> 00:02:08.210 align:middle line:84% and a verifier algorithm with the following syntax. 00:02:08.210 --> 00:02:11.290 align:middle line:84% So at the very beginning, the generator 00:02:11.290 --> 00:02:13.460 align:middle line:90% will generate some series. 00:02:13.460 --> 00:02:15.880 align:middle line:84% So it will take some security parameter as input 00:02:15.880 --> 00:02:17.055 align:middle line:90% and generate some series. 00:02:17.055 --> 00:02:19.840 align:middle line:90% 00:02:19.840 --> 00:02:22.810 align:middle line:84% And both the prover and the verifier 00:02:22.810 --> 00:02:27.670 align:middle line:84% is given access to these series throughout of the protocol. 00:02:27.670 --> 00:02:30.560 align:middle line:84% So instead of proving one statement at a time, 00:02:30.560 --> 00:02:32.740 align:middle line:84% the batch proof allows the prover 00:02:32.740 --> 00:02:37.000 align:middle line:84% to convince the verifier that a batch of the statement is true. 00:02:37.000 --> 00:02:45.250 align:middle line:84% So for example, so let's fix a NP language L so 00:02:45.250 --> 00:02:47.280 align:middle line:90% that L is defined as follows. 00:02:47.280 --> 00:02:53.380 align:middle line:90% 00:02:53.380 --> 00:02:56.300 align:middle line:84% And the prover tries to convince the verifier 00:02:56.300 --> 00:03:01.850 align:middle line:84% that a list of instances from x1 to xk. 00:03:01.850 --> 00:03:04.950 align:middle line:84% So the prover has this list of statements, 00:03:04.950 --> 00:03:07.430 align:middle line:84% and he wants to convince the verifier 00:03:07.430 --> 00:03:15.410 align:middle line:84% that all of those statements are in this list MP language L. 00:03:15.410 --> 00:03:17.480 align:middle line:84% So this is the statement that the prover 00:03:17.480 --> 00:03:19.460 align:middle line:90% wants to convince the verifier. 00:03:19.460 --> 00:03:24.620 align:middle line:84% And the proof is a single random message, pi. 00:03:24.620 --> 00:03:28.040 align:middle line:84% And also, the prover also has the MP witness 00:03:28.040 --> 00:03:31.440 align:middle line:90% for this x1 to xk. 00:03:31.440 --> 00:03:35.090 align:middle line:84% So let's denote the NP witness as w1 to wk. 00:03:35.090 --> 00:03:37.820 align:middle line:90% So those are the NP witness. 00:03:37.820 --> 00:03:38.320 align:middle line:90% OK. 00:03:38.320 --> 00:03:43.340 align:middle line:90% 00:03:43.340 --> 00:03:50.090 align:middle line:84% So now, so we say such a BARG is succinct 00:03:50.090 --> 00:03:52.435 align:middle line:84% if it satisfies the following property. 00:03:52.435 --> 00:03:56.850 align:middle line:90% 00:03:56.850 --> 00:04:01.140 align:middle line:84% So succint is defined as the size of the proof 00:04:01.140 --> 00:04:06.390 align:middle line:84% is smaller than the total length of the witness. 00:04:06.390 --> 00:04:08.960 align:middle line:84% So can anyone see why we require this? 00:04:08.960 --> 00:04:12.600 align:middle line:90% 00:04:12.600 --> 00:04:13.717 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:04:13.717 --> 00:04:14.550 align:middle line:90% ZHENGZHONG JIN: Yes. 00:04:14.550 --> 00:04:15.010 align:middle line:90% Yes. 00:04:15.010 --> 00:04:15.510 align:middle line:90% Right. 00:04:15.510 --> 00:04:16.860 align:middle line:90% Exactly. 00:04:16.860 --> 00:04:22.920 align:middle line:84% So we require this is because a trivial proof system, 00:04:22.920 --> 00:04:25.830 align:middle line:84% we could have the prover to just send over 00:04:25.830 --> 00:04:27.430 align:middle line:90% the NP witness to the verifier. 00:04:27.430 --> 00:04:30.000 align:middle line:84% Then the proof will be k times w. 00:04:30.000 --> 00:04:31.890 align:middle line:84% So [INAUDIBLE] this requires this. 00:04:31.890 --> 00:04:35.790 align:middle line:84% And as any proof systems, we require the completeness 00:04:35.790 --> 00:04:37.090 align:middle line:90% and the soundness. 00:04:37.090 --> 00:04:46.020 align:middle line:84% So completeness requires, for any honestly-generated proof, 00:04:46.020 --> 00:04:47.620 align:middle line:90% it will always be accepted. 00:04:47.620 --> 00:04:55.410 align:middle line:84% And the soundness is defined as follows. 00:04:55.410 --> 00:04:59.920 align:middle line:90% 00:04:59.920 --> 00:05:05.180 align:middle line:84% So the soundness says, if the statement is not true, 00:05:05.180 --> 00:05:08.600 align:middle line:84% then any cheating prover shouldn't find a cheating proof. 00:05:08.600 --> 00:05:22.090 align:middle line:84% So it means, so if this is not true, then 00:05:22.090 --> 00:05:30.615 align:middle line:84% for any non-uniform PBT cheating prover, we have this property. 00:05:30.615 --> 00:05:38.560 align:middle line:90% 00:05:38.560 --> 00:05:41.500 align:middle line:84% So the cheating prover is given the CRS 00:05:41.500 --> 00:05:43.460 align:middle line:90% signed by the CRS generator. 00:05:43.460 --> 00:05:46.610 align:middle line:84% And we require it to send a proof pi star. 00:05:46.610 --> 00:05:48.380 align:middle line:84% So pi star is the cheating proof. 00:05:48.380 --> 00:05:51.450 align:middle line:84% And we require the probability that the proof is accepted 00:05:51.450 --> 00:05:53.650 align:middle line:90% by this verifier is negligible. 00:05:53.650 --> 00:06:00.420 align:middle line:90% 00:06:00.420 --> 00:06:03.900 align:middle line:84% So I guess you already learned about the concept, 00:06:03.900 --> 00:06:06.280 align:middle line:84% the definition of the proof systems. 00:06:06.280 --> 00:06:09.310 align:middle line:84% This is just a recap of the definition. 00:06:09.310 --> 00:06:18.120 align:middle line:90% 00:06:18.120 --> 00:06:21.040 align:middle line:84% So any questions about this definition? 00:06:21.040 --> 00:06:24.630 align:middle line:90% 00:06:24.630 --> 00:06:25.130 align:middle line:90% OK. 00:06:25.130 --> 00:06:30.780 align:middle line:90% 00:06:30.780 --> 00:06:32.310 align:middle line:84% Now, some of you might wonder why we 00:06:32.310 --> 00:06:33.880 align:middle line:90% care about such a proof system. 00:06:33.880 --> 00:06:36.970 align:middle line:84% Because such proof system is clearly a subclass. 00:06:36.970 --> 00:06:39.990 align:middle line:84% So such a statement is clearly a subclass of NP 00:06:39.990 --> 00:06:42.450 align:middle line:90% So why we care about them? 00:06:42.450 --> 00:06:46.210 align:middle line:84% So the reason is, as I just mentioned, 00:06:46.210 --> 00:06:49.280 align:middle line:84% so batch is a very basic concept. 00:06:49.280 --> 00:06:55.270 align:middle line:84% So this is just a notion of batch, the notion 00:06:55.270 --> 00:06:57.250 align:middle line:90% of batch in the proof systems. 00:06:57.250 --> 00:07:00.220 align:middle line:84% And a similar concept has been studied 00:07:00.220 --> 00:07:03.800 align:middle line:84% in other areas in cryptography, such as signatures. 00:07:03.800 --> 00:07:09.350 align:middle line:84% So there is a signature scheme called aggregated signature. 00:07:09.350 --> 00:07:11.920 align:middle line:84% So it allows you to aggregate multiple signatures 00:07:11.920 --> 00:07:14.060 align:middle line:90% together to a short signature. 00:07:14.060 --> 00:07:16.210 align:middle line:84% Then you only need to verify the short signature 00:07:16.210 --> 00:07:19.370 align:middle line:84% to ensure all the signatures can be verified. 00:07:19.370 --> 00:07:24.160 align:middle line:84% So there is also a similar notion 00:07:24.160 --> 00:07:26.510 align:middle line:90% studied in interactive proofs. 00:07:26.510 --> 00:07:31.090 align:middle line:84% And it's called batch interactive proof. 00:07:31.090 --> 00:07:35.780 align:middle line:84% And so such a scheme, such a BARG also has many applications. 00:07:35.780 --> 00:07:38.350 align:middle line:84% So in the next lecture, Yael will tell you 00:07:38.350 --> 00:07:42.970 align:middle line:84% how to use it to build SNARGs for all P. 00:07:42.970 --> 00:07:47.880 align:middle line:84% And in fact, there are many constructions of SNARGs 00:07:47.880 --> 00:07:49.780 align:middle line:90% for all of P up to now. 00:07:49.780 --> 00:07:52.545 align:middle line:84% So from various assumptions and-- 00:07:52.545 --> 00:07:53.920 align:middle line:84% there are different construction, 00:07:53.920 --> 00:07:57.570 align:middle line:84% but all of those constructions use these BARGs 00:07:57.570 --> 00:08:01.260 align:middle line:90% as a building block in it. 00:08:01.260 --> 00:08:03.157 align:middle line:90% And indeed-- yeah. 00:08:03.157 --> 00:08:05.490 align:middle line:84% AUDIENCE: Is there any hope for statistical sound BARGs, 00:08:05.490 --> 00:08:06.575 align:middle line:90% or is that a possibility? 00:08:06.575 --> 00:08:08.200 align:middle line:84% ZHENGZHONG JIN: That's a good question. 00:08:08.200 --> 00:08:14.040 align:middle line:84% So there is a recent work shows, if you can get statistical-- 00:08:14.040 --> 00:08:16.720 align:middle line:84% so you can get statistical BARGs, 00:08:16.720 --> 00:08:19.790 align:middle line:84% then you can build some witness, some statistical witness 00:08:19.790 --> 00:08:21.240 align:middle line:90% in distinguishibility. 00:08:21.240 --> 00:08:23.370 align:middle line:90% Yeah. 00:08:23.370 --> 00:08:26.930 align:middle line:84% So we don't know the exact answer yet. 00:08:26.930 --> 00:08:30.870 align:middle line:90% 00:08:30.870 --> 00:08:34.650 align:middle line:84% And actually, there is a technical reason 00:08:34.650 --> 00:08:37.480 align:middle line:84% why we study such a BARG, why we study BARGs. 00:08:37.480 --> 00:08:41.520 align:middle line:84% So I will briefly mention it, but I will not 00:08:41.520 --> 00:08:43.780 align:middle line:84% go into detail of this lower bound. 00:08:43.780 --> 00:08:45.995 align:middle line:84% So this is the work by Gentry and Wichs. 00:08:45.995 --> 00:08:49.140 align:middle line:90% 00:08:49.140 --> 00:08:51.150 align:middle line:90% So they show that-- 00:08:51.150 --> 00:08:55.720 align:middle line:84% I will not describe exactly the impossibility result. 00:08:55.720 --> 00:08:59.890 align:middle line:84% So they show some impossibility result about SNARGs in general. 00:08:59.890 --> 00:09:17.610 align:middle line:84% So they show it is impossible to build SNARGs for any T 00:09:17.610 --> 00:09:33.000 align:middle line:84% hard language with proof that is significantly less than log T. 00:09:33.000 --> 00:09:36.270 align:middle line:90% So what does it mean? 00:09:36.270 --> 00:09:39.510 align:middle line:84% So here, we say a language is T hard 00:09:39.510 --> 00:09:42.360 align:middle line:84% if it takes T time to decide this language. 00:09:42.360 --> 00:09:50.050 align:middle line:84% So for example, for general NP language with witness length w, 00:09:50.050 --> 00:09:52.780 align:middle line:84% then usually you will take 2 to the w time 00:09:52.780 --> 00:09:54.320 align:middle line:90% to decipher this language. 00:09:54.320 --> 00:09:57.610 align:middle line:84% So by this impossibility result, they 00:09:57.610 --> 00:10:01.690 align:middle line:84% are saying it is a very hard to build SNARGs for general NP 00:10:01.690 --> 00:10:07.180 align:middle line:84% language if the proof size is significantly less than w. 00:10:07.180 --> 00:10:10.240 align:middle line:84% So basically, SNARGs for NP is very hard to build. 00:10:10.240 --> 00:10:15.290 align:middle line:84% And here, the impossibility only holds for very good assumptions. 00:10:15.290 --> 00:10:18.820 align:middle line:84% So they call those assumptions falsifiable assumptions. 00:10:18.820 --> 00:10:23.050 align:middle line:84% And basically, good assumptions, such as learning with error 00:10:23.050 --> 00:10:25.150 align:middle line:90% assumption, are falsifiable. 00:10:25.150 --> 00:10:32.290 align:middle line:84% So I want to mention this because, indeed, 00:10:32.290 --> 00:10:33.380 align:middle line:90% if you want to-- 00:10:33.380 --> 00:10:40.205 align:middle line:84% so if we consider BARGs, then the language we are proving-- 00:10:40.205 --> 00:10:40.705 align:middle line:90% sorry. 00:10:40.705 --> 00:10:43.910 align:middle line:90% 00:10:43.910 --> 00:10:47.780 align:middle line:84% So if we want to consider BARGs, then the language we are proving 00:10:47.780 --> 00:10:50.090 align:middle line:84% is the following language, indeed. 00:10:50.090 --> 00:10:54.020 align:middle line:84% So the language the prover tries to convince the verifier 00:10:54.020 --> 00:10:58.440 align:middle line:84% is the language L or product k times-- 00:10:58.440 --> 00:11:06.440 align:middle line:84% so it simply contains all of x1 to xk such that all of x1 to xk 00:11:06.440 --> 00:11:08.570 align:middle line:90% is in this language L. 00:11:08.570 --> 00:11:11.995 align:middle line:84% So what's the time to decide this language? 00:11:11.995 --> 00:11:14.720 align:middle line:90% 00:11:14.720 --> 00:11:15.640 align:middle line:90% Do anyone knows? 00:11:15.640 --> 00:11:19.257 align:middle line:90% 00:11:19.257 --> 00:11:20.840 align:middle line:84% AUDIENCE: Would it be T times the time 00:11:20.840 --> 00:11:22.767 align:middle line:84% to decide each of those statements? 00:11:22.767 --> 00:11:23.600 align:middle line:90% ZHENGZHONG JIN: Yes. 00:11:23.600 --> 00:11:24.180 align:middle line:90% Yes. 00:11:24.180 --> 00:11:24.680 align:middle line:90% Right. 00:11:24.680 --> 00:11:26.460 align:middle line:90% Great. 00:11:26.460 --> 00:11:27.600 align:middle line:90% So that's correct. 00:11:27.600 --> 00:11:32.240 align:middle line:84% So to decide this language, we only need to take k times 2 00:11:32.240 --> 00:11:36.350 align:middle line:84% to the w because you only need to decide 00:11:36.350 --> 00:11:38.400 align:middle line:90% whether each xi is in L or not. 00:11:38.400 --> 00:11:43.040 align:middle line:84% And if one of them is not in L, then you 00:11:43.040 --> 00:11:45.690 align:middle line:84% know this instance is not in this language. 00:11:45.690 --> 00:11:54.210 align:middle line:84% So the point is, if you take this T into this Gentry-Wichs 00:11:54.210 --> 00:11:57.510 align:middle line:84% impossibility, it shows that it is very hard to build SNARGs 00:11:57.510 --> 00:12:02.430 align:middle line:84% for a proof size significantly less than log T. 00:12:02.430 --> 00:12:10.620 align:middle line:84% But log T is roughly the size of w 00:12:10.620 --> 00:12:15.810 align:middle line:84% So it only shows it is very hard to build a SNARG for proof 00:12:15.810 --> 00:12:17.860 align:middle line:90% size significantly less than w. 00:12:17.860 --> 00:12:20.260 align:middle line:90% But this is succint enough. 00:12:20.260 --> 00:12:24.210 align:middle line:84% So I mean, if we can build a SNARG with-- 00:12:24.210 --> 00:12:28.950 align:middle line:84% if we can build BARGs with proof size w, that doesn't contradict 00:12:28.950 --> 00:12:32.190 align:middle line:84% to Gentry-Wichs, but it is still succinct 00:12:32.190 --> 00:12:35.940 align:middle line:84% because w is already significantly less than k 00:12:35.940 --> 00:12:37.930 align:middle line:90% times w. 00:12:37.930 --> 00:12:39.470 align:middle line:90% OK. 00:12:39.470 --> 00:12:40.490 align:middle line:90% Any questions? 00:12:40.490 --> 00:12:43.710 align:middle line:90% 00:12:43.710 --> 00:12:44.210 align:middle line:90% OK. 00:12:44.210 --> 00:12:47.830 align:middle line:84% So in this lecture, the main theory we want to prove 00:12:47.830 --> 00:12:50.120 align:middle line:90% is the following. 00:12:50.120 --> 00:12:56.740 align:middle line:90% 00:12:56.740 --> 00:13:06.670 align:middle line:84% So there exists a contraction of BARGs from learning with arrow. 00:13:06.670 --> 00:13:20.735 align:middle line:90% And the proof size is poly of-- 00:13:20.735 --> 00:13:21.235 align:middle line:90% sorry. 00:13:21.235 --> 00:13:31.420 align:middle line:90% 00:13:31.420 --> 00:13:40.220 align:middle line:84% So the proof size is dominated by the by the relation circuit 00:13:40.220 --> 00:13:40.920 align:middle line:90% size. 00:13:40.920 --> 00:13:46.550 align:middle line:84% So roughly, you can think, if we consider 3 SAT instance, then 00:13:46.550 --> 00:13:52.310 align:middle line:84% almost this this C is almost the same as the length of w 00:13:52.310 --> 00:13:55.010 align:middle line:90% because the circuit is shallow. 00:13:55.010 --> 00:13:55.910 align:middle line:90% Yeah. 00:13:55.910 --> 00:13:58.290 align:middle line:90% And the verification time-- 00:13:58.290 --> 00:14:01.290 align:middle line:90% 00:14:01.290 --> 00:14:05.420 align:middle line:84% so the proof size is almost close to this w 00:14:05.420 --> 00:14:07.850 align:middle line:90% because the log k term is small. 00:14:07.850 --> 00:14:08.540 align:middle line:90% Yeah. 00:14:08.540 --> 00:14:10.413 align:middle line:90% And the verification time is-- 00:14:10.413 --> 00:14:17.840 align:middle line:90% 00:14:17.840 --> 00:14:19.460 align:middle line:90% yeah. 00:14:19.460 --> 00:14:22.730 align:middle line:84% So the verification time is k times 1 00:14:22.730 --> 00:14:29.850 align:middle line:84% of the instance plus some additional term. 00:14:29.850 --> 00:14:31.350 align:middle line:90% So the additional term-- 00:14:31.350 --> 00:14:34.430 align:middle line:84% so the first term only depends on the total length 00:14:34.430 --> 00:14:38.370 align:middle line:84% of the instance, which is k times x. 00:14:38.370 --> 00:14:41.940 align:middle line:84% So because we have k instances and each of the instances 00:14:41.940 --> 00:14:45.540 align:middle line:84% has length x, so the additional term 00:14:45.540 --> 00:14:49.050 align:middle line:84% does not depend on the instance size, the total length 00:14:49.050 --> 00:14:50.400 align:middle line:90% of the instance size. 00:14:50.400 --> 00:14:58.235 align:middle line:84% It only depends on log k, the size C, and the lambda. 00:14:58.235 --> 00:15:02.790 align:middle line:90% 00:15:02.790 --> 00:15:06.720 align:middle line:84% So in fact, there are more structure 00:15:06.720 --> 00:15:08.230 align:middle line:90% of the verifier algorithm. 00:15:08.230 --> 00:15:12.030 align:middle line:84% So indeed, the verification algorithm 00:15:12.030 --> 00:15:13.960 align:middle line:90% can be decomposed to two parts. 00:15:13.960 --> 00:15:17.490 align:middle line:84% The first part will only take all of the instances as input 00:15:17.490 --> 00:15:21.700 align:middle line:84% and pre-processing it to output some very small state. 00:15:21.700 --> 00:15:24.270 align:middle line:84% So after the pre-processing, the online phase 00:15:24.270 --> 00:15:27.640 align:middle line:84% will take the state from the pre-processing algorithm, 00:15:27.640 --> 00:15:30.190 align:middle line:84% and it will verify the proof in a very short time. 00:15:30.190 --> 00:15:36.620 align:middle line:84% So the online phase does not depend on k. 00:15:36.620 --> 00:15:39.860 align:middle line:90% I will come to this point later. 00:15:39.860 --> 00:15:41.800 align:middle line:84% So this is the main theorem we want to prove. 00:15:41.800 --> 00:15:53.180 align:middle line:90% 00:15:53.180 --> 00:15:54.836 align:middle line:90% So next-- yeah. 00:15:54.836 --> 00:15:57.500 align:middle line:90% AUDIENCE: So [INAUDIBLE] 00:15:57.500 --> 00:15:59.900 align:middle line:90% 00:15:59.900 --> 00:16:01.010 align:middle line:90% ZHENGZHONG JIN: Sorry. 00:16:01.010 --> 00:16:03.900 align:middle line:84% AUDIENCE: The [INAUDIBLE] of pi is poly [INAUDIBLE] circuits, 00:16:03.900 --> 00:16:06.450 align:middle line:84% size of circuits is like [INAUDIBLE]. 00:16:06.450 --> 00:16:07.950 align:middle line:84% ZHENGZHONG JIN: The number of lines? 00:16:07.950 --> 00:16:11.240 align:middle line:90% AUDIENCE: The [INAUDIBLE] of pi. 00:16:11.240 --> 00:16:12.068 align:middle line:90% X of pi. 00:16:12.068 --> 00:16:13.651 align:middle line:84% ZHENGZHONG JIN: Oh length of pi, yeah. 00:16:13.651 --> 00:16:15.920 align:middle line:84% AUDIENCE: So you want it to be less than k times w. 00:16:15.920 --> 00:16:18.320 align:middle line:84% So this k, like much larger than the size of-- 00:16:18.320 --> 00:16:21.263 align:middle line:84% is k much larger than length of w? 00:16:21.263 --> 00:16:22.430 align:middle line:90% ZHENGZHONG JIN: Length of w? 00:16:22.430 --> 00:16:23.570 align:middle line:90% Oh, right. 00:16:23.570 --> 00:16:27.020 align:middle line:84% You can think of k is a polynomial in w. 00:16:27.020 --> 00:16:27.830 align:middle line:90% Yeah. 00:16:27.830 --> 00:16:28.790 align:middle line:90% Usually, yeah. 00:16:28.790 --> 00:16:31.660 align:middle line:84% Because you want the prover to be a polynomial time algorithm. 00:16:31.660 --> 00:16:33.365 align:middle line:84% Then you can only consider polynomial k. 00:16:33.365 --> 00:16:37.032 align:middle line:90% 00:16:37.032 --> 00:16:38.940 align:middle line:84% AUDIENCE: So if k is polynomial w, 00:16:38.940 --> 00:16:43.920 align:middle line:84% then this construction is only succinct if the polynomial in C 00:16:43.920 --> 00:16:45.713 align:middle line:90% is a small polynomial? 00:16:45.713 --> 00:16:46.630 align:middle line:90% ZHENGZHONG JIN: Right. 00:16:46.630 --> 00:16:47.280 align:middle line:90% Yes. 00:16:47.280 --> 00:16:49.130 align:middle line:90% Yeah. 00:16:49.130 --> 00:16:49.630 align:middle line:90% Right. 00:16:49.630 --> 00:16:55.710 align:middle line:84% So in fact, there is a way to generically bootstrap 00:16:55.710 --> 00:17:00.240 align:middle line:84% this to remove the dependence on the size of the circuit 00:17:00.240 --> 00:17:03.300 align:middle line:84% to make it even smaller, to make it only depend 00:17:03.300 --> 00:17:04.450 align:middle line:90% on the witness size. 00:17:04.450 --> 00:17:09.450 align:middle line:84% But that will use the things in the next lecture by Yael. 00:17:09.450 --> 00:17:10.589 align:middle line:90% So you can-- yeah. 00:17:10.589 --> 00:17:15.569 align:middle line:90% 00:17:15.569 --> 00:17:16.150 align:middle line:90% OK. 00:17:16.150 --> 00:17:17.980 align:middle line:90% So any questions? 00:17:17.980 --> 00:17:25.319 align:middle line:90% 00:17:25.319 --> 00:17:31.725 align:middle line:84% So next I will show you how to construct these BARGs. 00:17:31.725 --> 00:17:34.780 align:middle line:90% 00:17:34.780 --> 00:17:37.040 align:middle line:84% So if I directly show you the construction, 00:17:37.040 --> 00:17:38.450 align:middle line:90% it will be very complicated. 00:17:38.450 --> 00:17:42.670 align:middle line:84% So I will show you a first initial attempt 00:17:42.670 --> 00:17:45.550 align:middle line:84% to do the construction and gradually add the building 00:17:45.550 --> 00:17:47.620 align:middle line:90% blocks to the construction. 00:17:47.620 --> 00:17:54.910 align:middle line:84% So our starting point is the Kilians protocol. 00:17:54.910 --> 00:17:57.210 align:middle line:84% Actually, it's a simplified version of Kilian. 00:17:57.210 --> 00:18:16.900 align:middle line:90% 00:18:16.900 --> 00:18:24.940 align:middle line:90% So initially, the prover has k-- 00:18:24.940 --> 00:18:28.500 align:middle line:84% so it has k instance and the witness. 00:18:28.500 --> 00:18:31.280 align:middle line:90% So w1 to wk-- 00:18:31.280 --> 00:18:35.090 align:middle line:90% sorry-- x1 to xk. 00:18:35.090 --> 00:18:41.060 align:middle line:84% And the prover is going to use PCP to generate the PCP for all 00:18:41.060 --> 00:18:45.950 align:middle line:90% of those instances. 00:18:45.950 --> 00:18:49.310 align:middle line:84% So he applied the PCP prover algorithm to it 00:18:49.310 --> 00:18:53.510 align:middle line:84% and obtained a PCP proof, which is a long string. 00:18:53.510 --> 00:18:59.030 align:middle line:84% So this is the first PCP proof for x1 and w1. 00:18:59.030 --> 00:19:02.000 align:middle line:84% And he does the same for the second instance and witness, 00:19:02.000 --> 00:19:04.610 align:middle line:90% et cetera-- 00:19:04.610 --> 00:19:06.960 align:middle line:90% so PCP k. 00:19:06.960 --> 00:19:10.700 align:middle line:90% 00:19:10.700 --> 00:19:13.910 align:middle line:84% So do any of you remember what is PCP? 00:19:13.910 --> 00:19:18.380 align:middle line:90% 00:19:18.380 --> 00:19:20.010 align:middle line:90% Or do I need to recall it? 00:19:20.010 --> 00:19:29.640 align:middle line:90% 00:19:29.640 --> 00:19:32.820 align:middle line:90% So a quick recall what is PCP-- 00:19:32.820 --> 00:19:34.305 align:middle line:90% so PCP is a-- 00:19:34.305 --> 00:19:41.040 align:middle line:90% 00:19:41.040 --> 00:19:47.310 align:middle line:90% so let's say PCP for NP. 00:19:47.310 --> 00:19:51.640 align:middle line:84% So PCP for NP is a pair of algorithms. 00:19:51.640 --> 00:19:53.610 align:middle line:84% So the prover has some x and a w, 00:19:53.610 --> 00:19:57.210 align:middle line:84% which is the NP instance and the witness. 00:19:57.210 --> 00:20:01.160 align:middle line:84% And he can generate a long proof, long PCP proof. 00:20:01.160 --> 00:20:03.690 align:middle line:90% 00:20:03.690 --> 00:20:06.750 align:middle line:84% So this is the prover algorithm for PCP. 00:20:06.750 --> 00:20:09.990 align:middle line:90% And there is a PCP verifier. 00:20:09.990 --> 00:20:12.150 align:middle line:90% So the verifier will read-- 00:20:12.150 --> 00:20:14.740 align:middle line:84% so this PCP string is some binary string. 00:20:14.740 --> 00:20:16.320 align:middle line:90% So it contains 0 and 1s. 00:20:16.320 --> 00:20:21.030 align:middle line:84% And the verifier will sample some random coordinates, 00:20:21.030 --> 00:20:26.350 align:middle line:84% Q. So let's say the size of the PCP is L, 00:20:26.350 --> 00:20:28.635 align:middle line:90% and Q is a subset of indices. 00:20:28.635 --> 00:20:32.980 align:middle line:90% 00:20:32.980 --> 00:20:37.185 align:middle line:90% So the PCP verifier will check. 00:20:37.185 --> 00:20:39.850 align:middle line:90% 00:20:39.850 --> 00:20:48.580 align:middle line:84% It will take the instance x and the query Q under the PCP 00:20:48.580 --> 00:20:57.490 align:middle line:84% in the subset Q. And then it decides to accept or reject. 00:20:57.490 --> 00:20:59.740 align:middle line:90% So that's the PCP. 00:20:59.740 --> 00:21:02.050 align:middle line:90% And we require the-- 00:21:02.050 --> 00:21:06.580 align:middle line:84% so the combinant says, if x and w is in the language, 00:21:06.580 --> 00:21:09.760 align:middle line:84% then the proof should be accepted by the verifier. 00:21:09.760 --> 00:21:19.400 align:middle line:84% And the soundness says, for any x-- 00:21:19.400 --> 00:21:29.070 align:middle line:84% so if x is not in L, then for any PCP string, PCP star, 00:21:29.070 --> 00:21:33.050 align:middle line:84% we have the probability that the verifier accepts 00:21:33.050 --> 00:21:35.800 align:middle line:90% is bounded by some constant. 00:21:35.800 --> 00:21:39.020 align:middle line:90% 00:21:39.020 --> 00:21:42.275 align:middle line:84% So the randomness is over Q and the-- 00:21:42.275 --> 00:21:51.470 align:middle line:90% 00:21:51.470 --> 00:21:53.010 align:middle line:90% is bounded by some epsilon. 00:21:53.010 --> 00:21:57.560 align:middle line:84% So here we can always do some parallel repetition 00:21:57.560 --> 00:21:59.540 align:middle line:90% to amplify the witness-- 00:21:59.540 --> 00:22:01.880 align:middle line:84% sorry-- to amplify the soundness. 00:22:01.880 --> 00:22:04.520 align:middle line:84% So if we do the parallel repetition lambda 00:22:04.520 --> 00:22:07.110 align:middle line:90% times, then any-- 00:22:07.110 --> 00:22:13.040 align:middle line:84% so we can amplify any constant soundness error to lambda, 00:22:13.040 --> 00:22:14.420 align:middle line:90% to epsilon lambda. 00:22:14.420 --> 00:22:21.720 align:middle line:84% So then we can set it to be 2 to the minus the order of lambda. 00:22:21.720 --> 00:22:27.390 align:middle line:84% And the cost of doing this is to blow up the size of the query 00:22:27.390 --> 00:22:30.300 align:middle line:90% by lambda. 00:22:30.300 --> 00:22:34.620 align:middle line:84% So we can always assume with all the generality 00:22:34.620 --> 00:22:40.350 align:middle line:84% that there exists a PCP for NP, where the query complexity is 00:22:40.350 --> 00:22:50.880 align:middle line:84% roughly lambda times poly log C. And the soundness error is 00:22:50.880 --> 00:22:52.590 align:middle line:90% 2 to the-- 00:22:52.590 --> 00:22:55.020 align:middle line:90% roughly 2 to the minus lambda. 00:22:55.020 --> 00:22:59.860 align:middle line:84% So we will use this kind of PCP with this query complexity 00:22:59.860 --> 00:23:00.750 align:middle line:90% and the-- 00:23:00.750 --> 00:23:01.320 align:middle line:90% yeah. 00:23:01.320 --> 00:23:04.200 align:middle line:84% AUDIENCE: I mean, there are PCPs with the size of QVO of lambda, 00:23:04.200 --> 00:23:05.760 align:middle line:90% right? 00:23:05.760 --> 00:23:07.655 align:middle line:90% Do we need the poly log C term? 00:23:07.655 --> 00:23:09.280 align:middle line:84% ZHENGZHONG JIN: Oh, you mean this term? 00:23:09.280 --> 00:23:10.920 align:middle line:90% AUDIENCE: Yeah. 00:23:10.920 --> 00:23:13.180 align:middle line:84% ZHENGZHONG JIN: So that's a good question. 00:23:13.180 --> 00:23:15.610 align:middle line:84% So it's possible that you can get rid of the-- 00:23:15.610 --> 00:23:18.810 align:middle line:84% so for example, if you have a very good query complexity, then 00:23:18.810 --> 00:23:20.590 align:middle line:90% maybe you don't have this term. 00:23:20.590 --> 00:23:23.200 align:middle line:84% But in this work, I only-- so we will 00:23:23.200 --> 00:23:25.300 align:middle line:84% need some additional structure about the PCP. 00:23:25.300 --> 00:23:26.770 align:middle line:90% And I only know-- 00:23:26.770 --> 00:23:30.310 align:middle line:84% at least I know it holds for the algebraic construction 00:23:30.310 --> 00:23:31.760 align:middle line:90% from this written numeric code. 00:23:31.760 --> 00:23:34.660 align:middle line:84% But I don't know if it holds for general other constructions 00:23:34.660 --> 00:23:36.670 align:middle line:90% of PCP. 00:23:36.670 --> 00:23:41.090 align:middle line:90% So all right. 00:23:41.090 --> 00:23:43.210 align:middle line:90% So I'll use this PCP. 00:23:43.210 --> 00:23:48.550 align:middle line:84% So now we have k PCP string, and we have our verifier. 00:23:48.550 --> 00:23:50.350 align:middle line:90% So-- 00:23:50.350 --> 00:23:54.130 align:middle line:84% AUDIENCE: Can you remind us how big [INAUDIBLE] are? 00:23:54.130 --> 00:23:57.280 align:middle line:90% ZHENGZHONG JIN: Good question. 00:23:57.280 --> 00:24:00.050 align:middle line:84% So let's say this is a PCP for NP language L, 00:24:00.050 --> 00:24:02.570 align:middle line:84% and the NP language is defined in this way. 00:24:02.570 --> 00:24:06.370 align:middle line:90% 00:24:06.370 --> 00:24:14.020 align:middle line:84% So it has a relation circuit C. And the length of the L-- 00:24:14.020 --> 00:24:21.260 align:middle line:84% so length of L is some poly in C, the circuit size. 00:24:21.260 --> 00:24:24.950 align:middle line:84% Again, it's possible that you can use some more efficient PCP 00:24:24.950 --> 00:24:26.420 align:middle line:90% construction to-- 00:24:26.420 --> 00:24:31.250 align:middle line:84% I think there exists a PCP such that this L is almost near 00:24:31.250 --> 00:24:32.930 align:middle line:84% linear in the size of the circuit. 00:24:32.930 --> 00:24:35.600 align:middle line:90% Yeah. 00:24:35.600 --> 00:24:36.715 align:middle line:90% So OK. 00:24:36.715 --> 00:24:39.290 align:middle line:90% 00:24:39.290 --> 00:24:45.720 align:middle line:84% So we will use this PCP, and so we'll use some hash function. 00:24:45.720 --> 00:24:48.540 align:middle line:84% And we will put the hash key in the CRS. 00:24:48.540 --> 00:24:50.840 align:middle line:84% So the CRS will contain the hash key. 00:24:50.840 --> 00:24:52.200 align:middle line:90% Let's say some hash key. 00:24:52.200 --> 00:24:56.750 align:middle line:90% 00:24:56.750 --> 00:25:01.400 align:middle line:84% And we are going to look at-- so this PCP are-- 00:25:01.400 --> 00:25:04.220 align:middle line:84% so they are binary strings for each coordinate. 00:25:04.220 --> 00:25:06.900 align:middle line:84% They are binary values in each coordinate. 00:25:06.900 --> 00:25:10.280 align:middle line:84% And we are going to use this hash function to hash 00:25:10.280 --> 00:25:12.830 align:middle line:90% each column of this PCP-- 00:25:12.830 --> 00:25:14.250 align:middle line:90% of those PCPs. 00:25:14.250 --> 00:25:18.810 align:middle line:84% So that means I will take the first bit of each PCP string 00:25:18.810 --> 00:25:22.290 align:middle line:84% and concatenate them together and hash 00:25:22.290 --> 00:25:26.190 align:middle line:90% them using a hash function. 00:25:26.190 --> 00:25:36.930 align:middle line:84% So I apply a hash function here, so to the first column. 00:25:36.930 --> 00:25:40.290 align:middle line:90% And I get some hash value, h1. 00:25:40.290 --> 00:25:42.755 align:middle line:84% And I will do the same thing for the second column. 00:25:42.755 --> 00:25:47.020 align:middle line:90% 00:25:47.020 --> 00:25:50.340 align:middle line:90% So I can get h2. 00:25:50.340 --> 00:25:52.540 align:middle line:84% So for each column, I will hash it. 00:25:52.540 --> 00:25:58.080 align:middle line:84% And so basically, for each column 00:25:58.080 --> 00:26:00.030 align:middle line:84% I will hash it to get some hash value. 00:26:00.030 --> 00:26:03.440 align:middle line:84% So if the length of the PCP is L, then I get L hash values. 00:26:03.440 --> 00:26:06.475 align:middle line:90% 00:26:06.475 --> 00:26:11.470 align:middle line:84% So under this variant of Kilians protocol, I work as follows. 00:26:11.470 --> 00:26:16.180 align:middle line:84% So I first will send all of the hash values, from h1 to hk-- 00:26:16.180 --> 00:26:19.370 align:middle line:90% 00:26:19.370 --> 00:26:23.990 align:middle line:90% sorry, h1 to hL for each column. 00:26:23.990 --> 00:26:27.020 align:middle line:84% And then I will have the verifier 00:26:27.020 --> 00:26:28.795 align:middle line:90% to send one single PCP query. 00:26:28.795 --> 00:26:33.560 align:middle line:90% 00:26:33.560 --> 00:26:38.260 align:middle line:84% So a PCP query, remember, is a subset of indices. 00:26:38.260 --> 00:26:40.940 align:middle line:90% 00:26:40.940 --> 00:26:44.870 align:middle line:84% So this is one single PCP query for-- 00:26:44.870 --> 00:26:47.300 align:middle line:84% so I mean, it's a PCP query for one 00:26:47.300 --> 00:26:50.870 align:middle line:84% of the state, one of the PCP string. 00:26:50.870 --> 00:26:56.300 align:middle line:84% And finally, I will open the query column 00:26:56.300 --> 00:26:58.420 align:middle line:84% for these hash function, for those hash function. 00:26:58.420 --> 00:27:09.530 align:middle line:90% 00:27:09.530 --> 00:27:12.510 align:middle line:90% So what do I mean? 00:27:12.510 --> 00:27:19.720 align:middle line:84% So this is so you can view this PCB string as a matrix. 00:27:19.720 --> 00:27:25.590 align:middle line:84% So this matrix has L columns and the k rows. 00:27:25.590 --> 00:27:29.536 align:middle line:90% 00:27:29.536 --> 00:27:32.550 align:middle line:84% And for this one, single PCP query, 00:27:32.550 --> 00:27:34.480 align:middle line:84% it will query some of the positions. 00:27:34.480 --> 00:27:37.620 align:middle line:84% So suppose it queries this second position 00:27:37.620 --> 00:27:40.650 align:middle line:90% and the last position. 00:27:40.650 --> 00:27:43.320 align:middle line:84% Then I will open the corresponding column 00:27:43.320 --> 00:27:46.200 align:middle line:90% for this query position. 00:27:46.200 --> 00:27:53.250 align:middle line:84% So let's denote the first column as a column 1 00:27:53.250 --> 00:27:58.560 align:middle line:84% and the second column as a column 2, et cetera. 00:27:58.560 --> 00:28:00.270 align:middle line:84% Then the third-round message will 00:28:00.270 --> 00:28:11.500 align:middle line:84% contain all of the column Q, where this Q is in this query, 00:28:11.500 --> 00:28:14.920 align:middle line:90% is in this subset. 00:28:14.920 --> 00:28:18.730 align:middle line:84% So this is essentially the same as Kilian, 00:28:18.730 --> 00:28:24.380 align:middle line:84% except that I don't use a Merkle tree to commit them. 00:28:24.380 --> 00:28:29.590 align:middle line:84% I use a hash function to directly hash 00:28:29.590 --> 00:28:31.760 align:middle line:90% each column separately. 00:28:31.760 --> 00:28:35.260 align:middle line:90% 00:28:35.260 --> 00:28:36.080 align:middle line:90% Yeah, question? 00:28:36.080 --> 00:28:40.210 align:middle line:84% AUDIENCE: Do we use Merkle tree to commit to the h1, h2? 00:28:40.210 --> 00:28:41.350 align:middle line:90% ZHENGZHONG JIN: h1? 00:28:41.350 --> 00:28:45.260 align:middle line:84% So at this point, I do not use the Merkle tree to commit them. 00:28:45.260 --> 00:28:48.010 align:middle line:84% So I directly send them to the verifier. 00:28:48.010 --> 00:28:49.230 align:middle line:90% So OK. 00:28:49.230 --> 00:28:51.760 align:middle line:90% 00:28:51.760 --> 00:28:54.020 align:middle line:84% So I send them in the first message. 00:28:54.020 --> 00:28:57.340 align:middle line:84% So by sending them, I already fixed the PCP matrix 00:28:57.340 --> 00:28:58.570 align:middle line:90% intuitively. 00:28:58.570 --> 00:29:06.430 align:middle line:84% So then after I fix them, I have the verifier send the PCP query. 00:29:06.430 --> 00:29:09.260 align:middle line:84% And I have the prover to answer the same PCP 00:29:09.260 --> 00:29:12.800 align:middle line:90% query for all of the PCP. 00:29:12.800 --> 00:29:13.610 align:middle line:90% Yeah. 00:29:13.610 --> 00:29:15.860 align:middle line:84% AUDIENCE: [INAUDIBLE] I follow, the third message here 00:29:15.860 --> 00:29:17.330 align:middle line:84% is the point that we [INAUDIBLE], 00:29:17.330 --> 00:29:19.477 align:middle line:90% like [INAUDIBLE] OK, right? 00:29:19.477 --> 00:29:20.310 align:middle line:90% ZHENGZHONG JIN: Yes. 00:29:20.310 --> 00:29:20.810 align:middle line:90% Yes. 00:29:20.810 --> 00:29:22.250 align:middle line:90% Good. 00:29:22.250 --> 00:29:23.040 align:middle line:90% Good observation. 00:29:23.040 --> 00:29:23.540 align:middle line:90% Yeah. 00:29:23.540 --> 00:29:27.980 align:middle line:90% 00:29:27.980 --> 00:29:30.730 align:middle line:90% So this is the initial protocol. 00:29:30.730 --> 00:30:02.240 align:middle line:90% 00:30:02.240 --> 00:30:03.210 align:middle line:90% So right. 00:30:03.210 --> 00:30:05.480 align:middle line:90% Yeah. 00:30:05.480 --> 00:30:09.905 align:middle line:84% AUDIENCE: Does the same thing, all those [INAUDIBLE], 00:30:09.905 --> 00:30:12.690 align:middle line:84% is that small enough for the verifier? 00:30:12.690 --> 00:30:14.940 align:middle line:90% ZHENGZHONG JIN: Oh, sorry? 00:30:14.940 --> 00:30:16.000 align:middle line:90% You mean k, this one. 00:30:16.000 --> 00:30:17.708 align:middle line:84% AUDIENCE: Yeah, when you open the column, 00:30:17.708 --> 00:30:19.640 align:middle line:84% is that's small enough for the verifier? 00:30:19.640 --> 00:30:21.640 align:middle line:84% ZHENGZHONG JIN: Is that enough for the verifier? 00:30:21.640 --> 00:30:22.680 align:middle line:84% AUDIENCE: No, small enough, small enough. 00:30:22.680 --> 00:30:23.555 align:middle line:90% ZHENGZHONG JIN: Yeah. 00:30:23.555 --> 00:30:24.820 align:middle line:90% So good. 00:30:24.820 --> 00:30:27.180 align:middle line:90% So the size of Q is only-- 00:30:27.180 --> 00:30:30.490 align:middle line:84% you can think it's almost a poly log in the size of the circuit 00:30:30.490 --> 00:30:34.600 align:middle line:84% C. So this Q is very small, you can think. 00:30:34.600 --> 00:30:40.110 align:middle line:84% So for each row, I'm going to open-- 00:30:40.110 --> 00:30:42.820 align:middle line:84% for each row, I'm going to open Q positions. 00:30:42.820 --> 00:30:44.110 align:middle line:90% So I have k rows. 00:30:44.110 --> 00:30:47.830 align:middle line:84% So the third row on the message is almost k times Q, 00:30:47.830 --> 00:30:50.130 align:middle line:90% which is almost k. 00:30:50.130 --> 00:30:52.360 align:middle line:90% It grows with k. 00:30:52.360 --> 00:30:52.860 align:middle line:90% Yeah. 00:30:52.860 --> 00:30:55.480 align:middle line:90% 00:30:55.480 --> 00:30:57.780 align:middle line:90% So what does the verifier do? 00:30:57.780 --> 00:31:01.180 align:middle line:90% So the verifier, it will first-- 00:31:01.180 --> 00:31:08.560 align:middle line:84% so the verifier will first verify the opening 00:31:08.560 --> 00:31:10.190 align:middle line:90% is consistent with the hash. 00:31:10.190 --> 00:31:12.150 align:middle line:90% So it will verify hash. 00:31:12.150 --> 00:31:15.760 align:middle line:90% 00:31:15.760 --> 00:31:18.430 align:middle line:84% And the verification process is-- 00:31:18.430 --> 00:31:22.660 align:middle line:84% the verify just recomputes the hash for these queried positions 00:31:22.660 --> 00:31:25.310 align:middle line:84% and see if they are consistent with the first round message. 00:31:25.310 --> 00:31:28.930 align:middle line:90% So it will hash the-- 00:31:28.930 --> 00:31:34.400 align:middle line:84% use some hash function applied to the query position 00:31:34.400 --> 00:31:38.590 align:middle line:84% and then check if it is the same as the hQ for each 00:31:38.590 --> 00:31:44.530 align:middle line:84% of the Q in this query, the subset. 00:31:44.530 --> 00:31:51.580 align:middle line:84% And secondly, the verifier also need to verify the PCP. 00:31:51.580 --> 00:31:54.370 align:middle line:84% So the verifier will run the PCP verification 00:31:54.370 --> 00:31:58.040 align:middle line:84% for each of the statement, from x1 to xk. 00:31:58.040 --> 00:31:59.860 align:middle line:84% So it will run the PCP verification 00:31:59.860 --> 00:32:09.480 align:middle line:84% for xi and for the same query Q and the PCP answer. 00:32:09.480 --> 00:32:14.090 align:middle line:84% PCP answer for the i-th row is the-- 00:32:14.090 --> 00:32:19.370 align:middle line:84% for i-th sigma xi is the i-th coordinate 00:32:19.370 --> 00:32:22.490 align:middle line:90% of this column vector. 00:32:22.490 --> 00:32:31.550 align:middle line:84% And you take the collection of all of the such position in Q. 00:32:31.550 --> 00:32:32.060 align:middle line:90% Yeah. 00:32:32.060 --> 00:32:35.390 align:middle line:90% So that's the initial protocol. 00:32:35.390 --> 00:32:37.980 align:middle line:84% But this protocol is an interactive protocol. 00:32:37.980 --> 00:32:43.890 align:middle line:84% So to build a SNARG, we need to make it non-interactive. 00:32:43.890 --> 00:32:48.440 align:middle line:84% So I think the last lecture before Thanksgiving, 00:32:48.440 --> 00:32:53.450 align:middle line:84% so that lecture is about the correlation-intractable hash 00:32:53.450 --> 00:32:56.330 align:middle line:84% and how to use it to build a non-interactive proof 00:32:56.330 --> 00:32:57.660 align:middle line:90% from interactive proof. 00:32:57.660 --> 00:33:00.610 align:middle line:84% So let me recall what is a correlation-Intractable hash. 00:33:00.610 --> 00:33:07.020 align:middle line:90% 00:33:07.020 --> 00:33:22.860 align:middle line:84% So correlation-intractable hash-- 00:33:22.860 --> 00:33:28.410 align:middle line:84% so I will call it a CI hash, a CI hash for a relation L-- 00:33:28.410 --> 00:33:34.980 align:middle line:84% for a relation-- for a relation R. 00:33:34.980 --> 00:33:39.040 align:middle line:90% So R is a subset of x times y. 00:33:39.040 --> 00:33:40.835 align:middle line:90% So x here is the-- 00:33:40.835 --> 00:33:44.490 align:middle line:90% 00:33:44.490 --> 00:33:54.900 align:middle line:84% so in some subset of x and y is a tuple of algorithms. 00:33:54.900 --> 00:34:00.880 align:middle line:84% So the tuple consists of a key generator and a CI hash. 00:34:00.880 --> 00:34:04.870 align:middle line:90% 00:34:04.870 --> 00:34:07.540 align:middle line:84% And it satisfies the following property. 00:34:07.540 --> 00:34:09.315 align:middle line:90% So for any. 00:34:09.315 --> 00:34:12.429 align:middle line:90% 00:34:12.429 --> 00:34:23.800 align:middle line:84% non-uniform PBT adversary, we need the following condition. 00:34:23.800 --> 00:34:32.020 align:middle line:84% So the adversary is first given the hash key generated by some-- 00:34:32.020 --> 00:34:37.780 align:middle line:84% let's say this is CI hash key generated by the key chain 00:34:37.780 --> 00:34:40.449 align:middle line:90% algorithm. 00:34:40.449 --> 00:34:43.630 align:middle line:84% And the adversary is required to find some input 00:34:43.630 --> 00:34:49.960 align:middle line:84% x such that the pair of the x and the hash 00:34:49.960 --> 00:35:00.220 align:middle line:84% of-- and the CI hash of x, so the pair of them is in R. 00:35:00.220 --> 00:35:05.910 align:middle line:84% So this event is bounded by some negligible amount. 00:35:05.910 --> 00:35:07.740 align:middle line:90% Yeah. 00:35:07.740 --> 00:35:11.980 align:middle line:84% So this is what you learned from the last lecture. 00:35:11.980 --> 00:35:15.510 align:middle line:90% So this is just a recap. 00:35:15.510 --> 00:35:19.025 align:middle line:90% And yes. 00:35:19.025 --> 00:35:25.170 align:middle line:90% 00:35:25.170 --> 00:35:29.700 align:middle line:84% And also recall, so given such a hash function, 00:35:29.700 --> 00:35:32.160 align:middle line:84% how do you compile an interactive proof 00:35:32.160 --> 00:35:33.790 align:middle line:90% to a non-interactive one? 00:35:33.790 --> 00:35:36.840 align:middle line:84% So the idea is, you start with some-- 00:35:36.840 --> 00:35:42.000 align:middle line:84% so given any three-round public coin interactive protocol. 00:35:42.000 --> 00:35:44.340 align:middle line:84% So public coin means second-round message 00:35:44.340 --> 00:35:46.710 align:middle line:90% is a uniform random string. 00:35:46.710 --> 00:35:49.150 align:middle line:84% So suppose you have such a protocol. 00:35:49.150 --> 00:35:52.920 align:middle line:84% Then you can compile it using this hash function to obtain 00:35:52.920 --> 00:35:53.960 align:middle line:90% a non-interactive one. 00:35:53.960 --> 00:35:58.690 align:middle line:90% 00:35:58.690 --> 00:36:02.690 align:middle line:84% So the proof consists of the transcript of the protocol. 00:36:02.690 --> 00:36:06.470 align:middle line:84% So the proof is just alpha and beta. 00:36:06.470 --> 00:36:11.710 align:middle line:84% So beta equals the CI hash of the CI hash key 00:36:11.710 --> 00:36:14.565 align:middle line:90% and the alpha and the gamma. 00:36:14.565 --> 00:36:24.105 align:middle line:90% 00:36:24.105 --> 00:36:25.480 align:middle line:84% And we need to recall, how do you 00:36:25.480 --> 00:36:29.010 align:middle line:84% prove the soundness of this non-interactive protocol? 00:36:29.010 --> 00:36:32.110 align:middle line:90% 00:36:32.110 --> 00:36:35.722 align:middle line:84% So to prove the soundness, how do we 00:36:35.722 --> 00:36:37.180 align:middle line:84% use this correlation-intractability 00:36:37.180 --> 00:36:38.480 align:middle line:90% to prove the soundness? 00:36:38.480 --> 00:36:40.930 align:middle line:84% So to prove the soundness, you need to, 00:36:40.930 --> 00:36:42.560 align:middle line:90% firstly, define a relation. 00:36:42.560 --> 00:36:45.520 align:middle line:84% And the relation is the relation R. 00:36:45.520 --> 00:36:48.580 align:middle line:84% So it consists of all of the first-round and second-round 00:36:48.580 --> 00:36:50.950 align:middle line:84% message, alpha beta, such that there 00:36:50.950 --> 00:36:52.900 align:middle line:84% exists a pseudorandom message that 00:36:52.900 --> 00:36:55.045 align:middle line:90% can make the verifier accept. 00:36:55.045 --> 00:36:58.520 align:middle line:90% 00:36:58.520 --> 00:37:01.640 align:middle line:84% So you define this relation for the interactive protocol. 00:37:01.640 --> 00:37:09.740 align:middle line:84% And then, so for any proof, for any-- 00:37:09.740 --> 00:37:11.480 align:middle line:84% so to prove the soundness, we need 00:37:11.480 --> 00:37:16.280 align:middle line:84% to consider this x, the case when x is not in L. 00:37:16.280 --> 00:37:21.960 align:middle line:84% And yes, for x is not in L. And suppose any cheating prover-- 00:37:21.960 --> 00:37:25.730 align:middle line:84% let's say we have a cheating prover with an output, 00:37:25.730 --> 00:37:26.610 align:middle line:90% a cheating proof. 00:37:26.610 --> 00:37:29.120 align:middle line:90% 00:37:29.120 --> 00:37:32.600 align:middle line:84% So let's say the cheating prover outputs a cheating proof, alpha 00:37:32.600 --> 00:37:35.930 align:middle line:90% star, beta star, and gamma star. 00:37:35.930 --> 00:37:40.070 align:middle line:84% And if the proof is accepted, then this means-- 00:37:40.070 --> 00:37:50.300 align:middle line:84% so if this proof is accepted, then this 00:37:50.300 --> 00:37:57.240 align:middle line:84% means this beta star equals the CI hash of alpha star 00:37:57.240 --> 00:37:59.440 align:middle line:90% under the CI hash key. 00:37:59.440 --> 00:38:03.270 align:middle line:84% So I ignore the CI hash key here. 00:38:03.270 --> 00:38:06.690 align:middle line:90% And also, this-- yeah. 00:38:06.690 --> 00:38:10.025 align:middle line:84% And also the original verification passes. 00:38:10.025 --> 00:38:12.660 align:middle line:90% 00:38:12.660 --> 00:38:15.040 align:middle line:84% So here is a different verification, 00:38:15.040 --> 00:38:24.300 align:middle line:84% so under the original verification passes, 00:38:24.300 --> 00:38:27.210 align:middle line:90% So this means this alpha-- 00:38:27.210 --> 00:38:31.020 align:middle line:84% alpha star and beta star is in this relation. 00:38:31.020 --> 00:38:35.640 align:middle line:84% And this is how you prove the soundness because-- 00:38:35.640 --> 00:38:40.980 align:middle line:84% so if a cheating prover exists, then you reach a contradiction 00:38:40.980 --> 00:38:42.640 align:middle line:84% with the correlation-in tractability 00:38:42.640 --> 00:38:45.570 align:middle line:84% because the cheating prover also outputs the input and output 00:38:45.570 --> 00:38:50.490 align:middle line:84% pair such that this such that this beta equals 00:38:50.490 --> 00:38:51.700 align:middle line:90% the hash of the alpha. 00:38:51.700 --> 00:38:56.230 align:middle line:84% But it satisfies this relation, R. 00:38:56.230 --> 00:38:59.560 align:middle line:84% So this is from the last lecture. 00:38:59.560 --> 00:39:02.770 align:middle line:90% Any questions? 00:39:02.770 --> 00:39:07.540 align:middle line:84% So here I want to emphasize here that there 00:39:07.540 --> 00:39:09.200 align:middle line:90% is a condition in this proof. 00:39:09.200 --> 00:39:11.680 align:middle line:90% So the condition is-- 00:39:11.680 --> 00:39:15.670 align:middle line:84% So we need this for such, say hash 2 exists, 00:39:15.670 --> 00:39:25.930 align:middle line:84% we need this relation R. R, It needs to be sparse. 00:39:25.930 --> 00:39:28.540 align:middle line:90% So what do I mean? 00:39:28.540 --> 00:39:35.890 align:middle line:84% Or evasive-- so sparse here means, for any fixed R, alpha, 00:39:35.890 --> 00:39:39.655 align:middle line:84% the fraction of the beta that can make this pair, alpha beta. 00:39:39.655 --> 00:39:43.370 align:middle line:84% It satisfies this relation is a negligible fraction. 00:39:43.370 --> 00:39:55.550 align:middle line:84% So it means, all of beta such that alpha beta is in this R. 00:39:55.550 --> 00:40:01.260 align:middle line:84% If you divide it by all the size of y, 00:40:01.260 --> 00:40:04.850 align:middle line:84% then we need this to be negligible. 00:40:04.850 --> 00:40:10.430 align:middle line:84% So this condition is crucial for the CI hash to exist. 00:40:10.430 --> 00:40:16.195 align:middle line:84% The reason is-- do anyone know why this is the case? 00:40:16.195 --> 00:40:21.500 align:middle line:90% 00:40:21.500 --> 00:40:24.960 align:middle line:84% So let's consider an extreme case. 00:40:24.960 --> 00:40:29.380 align:middle line:90% So let's say if there exists-- 00:40:29.380 --> 00:40:34.400 align:middle line:90% 00:40:34.400 --> 00:40:36.210 align:middle line:90% let's consider extreme case. 00:40:36.210 --> 00:40:39.710 align:middle line:84% So let's say if there exists some alpha, alpha 0, 00:40:39.710 --> 00:40:45.770 align:middle line:84% some fixed alpha 0, which is in the input space, 00:40:45.770 --> 00:40:54.450 align:middle line:84% such that for all of the beta, this alpha and beta is alpha 0, 00:40:54.450 --> 00:41:02.100 align:middle line:84% beta is in this R. Then it means that then for any hash function, 00:41:02.100 --> 00:41:04.530 align:middle line:84% it cannot be correlation-intractable for such 00:41:04.530 --> 00:41:08.370 align:middle line:84% R, because any hash function will output something, 00:41:08.370 --> 00:41:13.080 align:middle line:84% some beta, and it will satisfies this relation. 00:41:13.080 --> 00:41:17.460 align:middle line:84% So this condition, so at least we 00:41:17.460 --> 00:41:19.365 align:middle line:84% need this fraction to be less than 1. 00:41:19.365 --> 00:41:23.130 align:middle line:90% 00:41:23.130 --> 00:41:26.730 align:middle line:84% The problem is, if we want to apply the CI hash 00:41:26.730 --> 00:41:30.300 align:middle line:84% construction here, it's not clear 00:41:30.300 --> 00:41:33.990 align:middle line:84% whether we can define a relation that is sparse. 00:41:33.990 --> 00:41:39.180 align:middle line:84% So let's modify the construction using this CI hash 00:41:39.180 --> 00:41:48.670 align:middle line:84% paradigm So we will replace the second message, Q. 00:41:48.670 --> 00:41:51.320 align:middle line:84% So instead of having the verifier send the Q, 00:41:51.320 --> 00:41:56.145 align:middle line:84% we have the prover compute this Q by itself using the CI hash. 00:41:56.145 --> 00:42:00.190 align:middle line:90% 00:42:00.190 --> 00:42:04.840 align:middle line:84% And so now we apply the say hash to all of the first round 00:42:04.840 --> 00:42:07.994 align:middle line:90% message h1 to hQ-- 00:42:07.994 --> 00:42:11.710 align:middle line:90% sorry, h1 to hL. 00:42:11.710 --> 00:42:15.993 align:middle line:84% And then we put the CI hash key inside of the CRS. 00:42:15.993 --> 00:42:35.345 align:middle line:90% 00:42:35.345 --> 00:42:38.200 align:middle line:84% So next I will define the relation R 00:42:38.200 --> 00:42:40.100 align:middle line:90% and try to prove the soundness. 00:42:40.100 --> 00:43:23.030 align:middle line:90% 00:43:23.030 --> 00:43:24.500 align:middle line:90% So, yeah? 00:43:24.500 --> 00:43:26.960 align:middle line:84% AUDIENCE: Can you say what changes you made again? 00:43:26.960 --> 00:43:27.890 align:middle line:90% ZHENGZHONG JIN: Yes. 00:43:27.890 --> 00:43:30.590 align:middle line:90% Good. 00:43:30.590 --> 00:43:33.590 align:middle line:84% So the changes is instead of having 00:43:33.590 --> 00:43:37.700 align:middle line:84% the prover to send a message to the verifier 00:43:37.700 --> 00:43:40.760 align:middle line:84% and have the verifier send back a challenge, 00:43:40.760 --> 00:43:46.470 align:middle line:84% I'm going to have the prover not send this h1 to hL. 00:43:46.470 --> 00:43:50.280 align:middle line:84% So the prover directly applies a CI hash to h1 00:43:50.280 --> 00:43:53.160 align:middle line:90% to hL and obtain some query. 00:43:53.160 --> 00:43:55.440 align:middle line:84% So the prover can proceed to the third round 00:43:55.440 --> 00:43:57.790 align:middle line:90% and finish the third round. 00:43:57.790 --> 00:43:59.850 align:middle line:84% So the proof will consist of the transcript 00:43:59.850 --> 00:44:04.350 align:middle line:84% of the protocol, which is all of the h1 to hL 00:44:04.350 --> 00:44:05.280 align:middle line:90% and the third-round. 00:44:05.280 --> 00:44:06.450 align:middle line:90% Message. 00:44:06.450 --> 00:44:07.320 align:middle line:90% OK. 00:44:07.320 --> 00:44:08.640 align:middle line:90% Yeah? 00:44:08.640 --> 00:44:11.490 align:middle line:84% AUDIENCE: What assumption are we making for-- 00:44:11.490 --> 00:44:13.500 align:middle line:84% we need the output phase of the CIh 00:44:13.500 --> 00:44:17.430 align:middle line:84% to be subsets that the verifier would query or something? 00:44:17.430 --> 00:44:18.450 align:middle line:90% ZHENGZHONG JIN: Right. 00:44:18.450 --> 00:44:19.090 align:middle line:90% Good question. 00:44:19.090 --> 00:44:23.230 align:middle line:84% So, in fact, we need the PCP to be a public coin. 00:44:23.230 --> 00:44:25.380 align:middle line:90% So, yeah. 00:44:25.380 --> 00:44:27.100 align:middle line:90% That's the implicit condition. 00:44:27.100 --> 00:44:29.835 align:middle line:90% 00:44:29.835 --> 00:44:32.250 align:middle line:84% So in the general case, the PCP query 00:44:32.250 --> 00:44:36.120 align:middle line:90% may not be uniformly random. 00:44:36.120 --> 00:44:41.057 align:middle line:84% So in fact, there is some PCP, some query sampler that 00:44:41.057 --> 00:44:42.640 align:middle line:84% takes take some uniform random string, 00:44:42.640 --> 00:44:46.690 align:middle line:84% and it will compute the actual PCP query. 00:44:46.690 --> 00:44:47.965 align:middle line:90% So, yeah. 00:44:47.965 --> 00:44:50.590 align:middle line:84% AUDIENCE: So we're also kind of assuming that the output of CIh 00:44:50.590 --> 00:44:52.990 align:middle line:84% is kind of uniformly distributed, 00:44:52.990 --> 00:44:54.245 align:middle line:90% or pseudorandomness? 00:44:54.245 --> 00:44:55.120 align:middle line:90% ZHENGZHONG JIN: Yeah. 00:44:55.120 --> 00:45:02.080 align:middle line:84% I mean, so in the general case-- so in fact, 00:45:02.080 --> 00:45:07.330 align:middle line:84% this is just some succinct way to describe 00:45:07.330 --> 00:45:08.630 align:middle line:90% how you generate the query. 00:45:08.630 --> 00:45:10.690 align:middle line:84% So in fact, the PCP query is generated 00:45:10.690 --> 00:45:17.710 align:middle line:84% by using some query generator or some sampler. 00:45:17.710 --> 00:45:20.740 align:middle line:84% So the sampler will take some uniform randomness R 00:45:20.740 --> 00:45:22.130 align:middle line:90% and generate the PCP query. 00:45:22.130 --> 00:45:26.680 align:middle line:84% So what you do is you take the output of the CI hash 00:45:26.680 --> 00:45:30.610 align:middle line:84% as the randomness, and then you generate it from it 00:45:30.610 --> 00:45:34.550 align:middle line:90% to get a PCP query. 00:45:34.550 --> 00:45:35.050 align:middle line:90% Yeah. 00:45:35.050 --> 00:45:43.250 align:middle line:90% 00:45:43.250 --> 00:45:48.230 align:middle line:84% OK, so next I will try to prove the security 00:45:48.230 --> 00:45:52.800 align:middle line:84% of this construction, try to prove the soundness. 00:45:52.800 --> 00:45:55.550 align:middle line:90% So completeness is easy to show. 00:45:55.550 --> 00:45:59.840 align:middle line:90% You just can do it yourself. 00:45:59.840 --> 00:46:02.430 align:middle line:84% I will only prove the soundness here. 00:46:02.430 --> 00:46:03.615 align:middle line:90% AUDIENCE: [INAUDIBLE] 00:46:03.615 --> 00:46:04.490 align:middle line:90% ZHENGZHONG JIN: Yeah. 00:46:04.490 --> 00:46:08.840 align:middle line:84% AUDIENCE: For [INAUDIBLE] whatever indices for PCP 00:46:08.840 --> 00:46:14.210 align:middle line:84% we generate this probability 1, [INAUDIBLE] 00:46:14.210 --> 00:46:23.150 align:middle line:84% verify those [INAUDIBLE] So for the PCP itself, 00:46:23.150 --> 00:46:24.210 align:middle line:90% is complete this one? 00:46:24.210 --> 00:46:24.600 align:middle line:90% ZHENGZHONG JIN: Oh, right. 00:46:24.600 --> 00:46:25.050 align:middle line:90% Yes. 00:46:25.050 --> 00:46:25.220 align:middle line:90% Good. 00:46:25.220 --> 00:46:25.970 align:middle line:90% Yeah. 00:46:25.970 --> 00:46:27.600 align:middle line:90% We assume that there-- 00:46:27.600 --> 00:46:30.930 align:middle line:84% yeah, we choose a PCP with perfect correctness. 00:46:30.930 --> 00:46:31.610 align:middle line:90% Yeah. 00:46:31.610 --> 00:46:32.592 align:middle line:90% Yeah. 00:46:32.592 --> 00:46:33.175 align:middle line:90% Good question. 00:46:33.175 --> 00:46:40.270 align:middle line:90% 00:46:40.270 --> 00:46:46.306 align:middle line:84% So let's first try to prove the soundness. 00:46:46.306 --> 00:46:54.340 align:middle line:90% 00:46:54.340 --> 00:46:56.530 align:middle line:84% So the initial attempt is to define 00:46:56.530 --> 00:47:00.200 align:middle line:84% a relation R similar to the relation R as before. 00:47:00.200 --> 00:47:04.450 align:middle line:84% So we just define it as the relation R consists 00:47:04.450 --> 00:47:09.220 align:middle line:84% of all the pairs of h1 to hL and the query 00:47:09.220 --> 00:47:15.380 align:middle line:84% set Q such that there exists a pseudorandom message. 00:47:15.380 --> 00:47:24.222 align:middle line:84% So gamma here is the pseudorandom message, 00:47:24.222 --> 00:47:26.430 align:middle line:90% such that the verifier accept. 00:47:26.430 --> 00:47:50.240 align:middle line:90% 00:47:50.240 --> 00:47:54.930 align:middle line:84% So this is the initial attempt to prove the soundness. 00:47:54.930 --> 00:47:56.160 align:middle line:90% So we'll do the same thing. 00:47:56.160 --> 00:47:58.250 align:middle line:84% So this R is the same as the relation 00:47:58.250 --> 00:48:01.520 align:middle line:84% R we defined for the CI has here, 00:48:01.520 --> 00:48:03.330 align:middle line:84% except that I just replaced the alpha, 00:48:03.330 --> 00:48:06.660 align:middle line:90% beta, gamma with this protocol. 00:48:06.660 --> 00:48:09.570 align:middle line:84% But the issue is, with this relation, 00:48:09.570 --> 00:48:12.010 align:middle line:84% it's not clear whether this relation is a sparse relation. 00:48:12.010 --> 00:48:21.090 align:middle line:90% 00:48:21.090 --> 00:48:24.680 align:middle line:84% The reason is that this hash function must 00:48:24.680 --> 00:48:26.490 align:middle line:90% be a compressing hash function. 00:48:26.490 --> 00:48:30.710 align:middle line:84% So if we choose a compressing hash function, then 00:48:30.710 --> 00:48:33.230 align:middle line:84% for any hash value, h1 to hL, there 00:48:33.230 --> 00:48:36.120 align:middle line:84% might be multiple preimages of the PCP. 00:48:36.120 --> 00:48:39.300 align:middle line:84% So for one PCP, so let's say we have 00:48:39.300 --> 00:48:44.370 align:middle line:84% one preimage of the PCP, which is PCP1 to PCPk. 00:48:44.370 --> 00:48:49.750 align:middle line:84% Then for those PCP, you may have a Q that can make them accept. 00:48:49.750 --> 00:48:52.300 align:middle line:84% You may have a one Q to make them accept. 00:48:52.300 --> 00:48:55.030 align:middle line:84% But for other preimage of the PCP, 00:48:55.030 --> 00:48:59.710 align:middle line:84% it may have another Q that can make the query accept. 00:48:59.710 --> 00:49:03.990 align:middle line:84% So now this relation will take the union 00:49:03.990 --> 00:49:06.880 align:middle line:90% of all of those PCP queries. 00:49:06.880 --> 00:49:10.710 align:middle line:84% So it's not clear if this relation 00:49:10.710 --> 00:49:13.170 align:middle line:90% has sparsity less than 1. 00:49:13.170 --> 00:49:15.660 align:middle line:90% Yeah. 00:49:15.660 --> 00:49:19.330 align:middle line:84% So what we will do is we will choose a special hash function. 00:49:19.330 --> 00:49:24.270 align:middle line:84% And so this special hash function is still compressing, 00:49:24.270 --> 00:49:29.260 align:middle line:84% but it will show us some information about its preimage. 00:49:29.260 --> 00:49:33.060 align:middle line:84% So now I will define this a special hash function. 00:49:33.060 --> 00:49:40.780 align:middle line:90% 00:49:40.780 --> 00:49:45.400 align:middle line:84% So the hash function is called somewhere 00:49:45.400 --> 00:49:47.245 align:middle line:90% statistical binding hash. 00:49:47.245 --> 00:50:05.590 align:middle line:90% 00:50:05.590 --> 00:50:06.950 align:middle line:90% I will call it SSB. 00:50:06.950 --> 00:50:10.300 align:middle line:90% So it's a SSB. 00:50:10.300 --> 00:50:15.070 align:middle line:84% So such a function is defined as follows. 00:50:15.070 --> 00:50:19.806 align:middle line:84% So SSB is also a tuple of algorithms. 00:50:19.806 --> 00:50:24.730 align:middle line:90% 00:50:24.730 --> 00:50:29.920 align:middle line:84% So it has a key generator and some SSB hash algorithm 00:50:29.920 --> 00:50:32.660 align:middle line:90% with the following syntax. 00:50:32.660 --> 00:50:38.160 align:middle line:84% So the key generation algorithm will sample some key. 00:50:38.160 --> 00:50:41.990 align:middle line:90% 00:50:41.990 --> 00:50:47.300 align:middle line:84% And the key generator will will take some security parameter 00:50:47.300 --> 00:50:53.240 align:middle line:84% lambda as input, and also it will take some index I as input, 00:50:53.240 --> 00:50:57.350 align:middle line:90% such that-- 00:50:57.350 --> 00:51:05.630 align:middle line:84% and then the SSB hash algorithm will use the SSB key 00:51:05.630 --> 00:51:11.000 align:middle line:84% and it will take some message, x1 to xn, as input and output 00:51:11.000 --> 00:51:12.380 align:middle line:90% some hash. 00:51:12.380 --> 00:51:14.990 align:middle line:84% And we require the following two properties. 00:51:14.990 --> 00:51:20.240 align:middle line:84% So the first property is called the key indistinguishability, 00:51:20.240 --> 00:51:25.141 align:middle line:84% or key hiding, so key indistinguishability. 00:51:25.141 --> 00:51:32.370 align:middle line:90% 00:51:32.370 --> 00:51:40.710 align:middle line:84% So it says that for any two indices, so i1 and i2 in this n. 00:51:40.710 --> 00:51:48.450 align:middle line:84% So the key generated by using the first indices 00:51:48.450 --> 00:51:54.330 align:middle line:84% is indistinguishable with the key 00:51:54.330 --> 00:51:57.390 align:middle line:90% generated by the second index. 00:51:57.390 --> 00:52:02.030 align:middle line:84% And the second property is called statistical binding. 00:52:02.030 --> 00:52:12.990 align:middle line:90% 00:52:12.990 --> 00:52:20.850 align:middle line:84% So statistical binding basically says the hash function 00:52:20.850 --> 00:52:24.880 align:middle line:90% is binding for the position i. 00:52:24.880 --> 00:52:38.560 align:middle line:84% So it says for any x1 to xn and x1 prime to xn prime. 00:52:38.560 --> 00:52:59.380 align:middle line:84% So if the SSB hash of them is the same, 00:52:59.380 --> 00:53:06.400 align:middle line:84% then we have this xi equals xi prime. 00:53:06.400 --> 00:53:09.640 align:middle line:84% So it says the hash value will bind the value 00:53:09.640 --> 00:53:13.630 align:middle line:84% at the i-th position of its input, xi. 00:53:13.630 --> 00:53:21.555 align:middle line:84% So here the k is generated in this way for this index i. 00:53:21.555 --> 00:53:44.510 align:middle line:90% 00:53:44.510 --> 00:53:46.160 align:middle line:90% Any question? 00:53:46.160 --> 00:53:46.850 align:middle line:90% Yeah. 00:53:46.850 --> 00:53:49.220 align:middle line:84% AUDIENCE: Could you explain why that relation might not 00:53:49.220 --> 00:53:50.847 align:middle line:90% be sparse? 00:53:50.847 --> 00:53:51.930 align:middle line:90% ZHENGZHONG JIN: Oh, right. 00:53:51.930 --> 00:53:56.620 align:middle line:84% So it's not clear whether this is sparse or not. 00:53:56.620 --> 00:54:02.600 align:middle line:90% 00:54:02.600 --> 00:54:07.400 align:middle line:84% The reason is that because this hash, so h1 to hL, 00:54:07.400 --> 00:54:08.350 align:middle line:90% are the hash values. 00:54:08.350 --> 00:54:11.210 align:middle line:90% 00:54:11.210 --> 00:54:13.940 align:middle line:84% So initially, we have this PCP1 to PCPk, 00:54:13.940 --> 00:54:20.570 align:middle line:84% and we hash them to a succinct hash value, h1 to hL. 00:54:20.570 --> 00:54:25.260 align:middle line:84% But the size of the hash is much smaller than the preimage. 00:54:25.260 --> 00:54:31.600 align:middle line:84% So for a fixed h1 to hL, there might be multiple preimages. 00:54:31.600 --> 00:54:36.090 align:middle line:84% And for one per image, it may have some-- 00:54:36.090 --> 00:54:38.550 align:middle line:84% for example, for this fixed one preimage, 00:54:38.550 --> 00:54:43.170 align:middle line:84% it may have some query set Q that can make all of the query 00:54:43.170 --> 00:54:44.730 align:middle line:90% be accepted. 00:54:44.730 --> 00:54:47.790 align:middle line:84% But there might be some other PCP 00:54:47.790 --> 00:54:50.530 align:middle line:90% preimage for the same h1 to hQ. 00:54:50.530 --> 00:54:54.030 align:middle line:84% So let's say it's some PCP1 PCPk prime. 00:54:54.030 --> 00:54:56.590 align:middle line:90% 00:54:56.590 --> 00:55:00.960 align:middle line:84% And they may also hash to the same hash value. 00:55:00.960 --> 00:55:08.130 align:middle line:84% So if this is the case, then for those set of PCP1 PCPk prime, 00:55:08.130 --> 00:55:10.620 align:middle line:84% they may have some other query set 00:55:10.620 --> 00:55:17.790 align:middle line:84% Q prime that can make each of the PCP1 prime to PCPk prime 00:55:17.790 --> 00:55:20.550 align:middle line:90% be accepted. 00:55:20.550 --> 00:55:26.420 align:middle line:84% But if this is the case, then this Q and Q prime need to be-- 00:55:26.420 --> 00:55:28.220 align:middle line:84% so they are also in this relation. 00:55:28.220 --> 00:55:37.090 align:middle line:84% R. So if this is the case, then both of these, this h1 to hL-- 00:55:37.090 --> 00:55:46.330 align:middle line:84% hL and Q is in this R. And the Q prime is also in R. 00:55:46.330 --> 00:55:48.820 align:middle line:84% So you can do this do this argument for each 00:55:48.820 --> 00:55:50.710 align:middle line:90% of the preimage of this H1. 00:55:50.710 --> 00:55:51.680 align:middle line:90% To hQ. 00:55:51.680 --> 00:55:55.490 align:middle line:84% And the issue is that there are many, many, many preimages. 00:55:55.490 --> 00:55:58.610 align:middle line:90% So it's very compressing. 00:55:58.610 --> 00:56:01.690 align:middle line:84% So the number of preimages is much larger 00:56:01.690 --> 00:56:08.633 align:middle line:84% than the size of the Q, all possibilities of Q. So, yeah. 00:56:08.633 --> 00:56:10.300 align:middle line:84% AUDIENCE: In order for a cheating prover 00:56:10.300 --> 00:56:13.030 align:middle line:84% to take advantage of this [INAUDIBLE], 00:56:13.030 --> 00:56:15.520 align:middle line:84% they would have to find a collision like that. 00:56:15.520 --> 00:56:17.530 align:middle line:84% So why are we worried about this? 00:56:17.530 --> 00:56:19.760 align:middle line:90% ZHENGZHONG JIN: Good question. 00:56:19.760 --> 00:56:22.660 align:middle line:84% So for example, if you take a specific hash function, 00:56:22.660 --> 00:56:25.230 align:middle line:84% it's not clear whether the prover can 00:56:25.230 --> 00:56:26.860 align:middle line:90% leverage this kind of attack. 00:56:26.860 --> 00:56:29.980 align:middle line:84% But it's also not clear how to prove the soundness. 00:56:29.980 --> 00:56:30.490 align:middle line:90% So, yeah. 00:56:30.490 --> 00:56:30.990 align:middle line:90% Sorry. 00:56:30.990 --> 00:56:39.440 align:middle line:90% 00:56:39.440 --> 00:56:39.940 align:middle line:90% OK. 00:56:39.940 --> 00:56:43.080 align:middle line:84% So next I will show you how to build such a-- 00:56:43.080 --> 00:56:44.390 align:middle line:90% yeah, any question? 00:56:44.390 --> 00:56:44.890 align:middle line:90% OK. 00:56:44.890 --> 00:56:51.180 align:middle line:84% So next I will show you how to build such a SSB from FHE. 00:56:51.180 --> 00:57:02.190 align:middle line:84% So the construction is very simple. 00:57:02.190 --> 00:57:05.280 align:middle line:90% So do you remember what is FHE? 00:57:05.280 --> 00:57:09.600 align:middle line:84% So FHE is some public key encryption, 00:57:09.600 --> 00:57:13.150 align:middle line:84% where you can, given a ciphertext of M 00:57:13.150 --> 00:57:16.500 align:middle line:84% you can homomorphically evaluate on the ciphertext 00:57:16.500 --> 00:57:20.120 align:middle line:84% for any function F and to get a ciphertext of F of M. 00:57:20.120 --> 00:57:21.640 align:middle line:90% So that's the FHE. 00:57:21.640 --> 00:57:26.290 align:middle line:84% So to build SSB we do the following. 00:57:26.290 --> 00:57:28.660 align:middle line:90% So from the FHE-- 00:57:28.660 --> 00:57:35.650 align:middle line:84% so for the key generation, so for the index i, 00:57:35.650 --> 00:57:39.940 align:middle line:84% we're going to generate a FHE ciphertext of i. 00:57:39.940 --> 00:57:45.430 align:middle line:90% 00:57:45.430 --> 00:57:51.610 align:middle line:84% And we define this ciphertext as the SSB key 00:57:51.610 --> 00:57:59.470 align:middle line:84% And to use this ciphertext to hash x1 to xn, 00:57:59.470 --> 00:58:02.830 align:middle line:84% the idea is we're going to homomorphically pick 00:58:02.830 --> 00:58:08.410 align:middle line:84% the i-th position under hood of FHE for those x1 to xn. 00:58:08.410 --> 00:58:18.140 align:middle line:84% So what we will do is we will do the homomorphic evaluation 00:58:18.140 --> 00:58:23.300 align:middle line:84% of some function F. And F has x1 to xn hardwired in it. 00:58:23.300 --> 00:58:30.010 align:middle line:84% And we'll do this [INAUDIBLE] on the ciphertext of i. 00:58:30.010 --> 00:58:32.660 align:middle line:90% 00:58:32.660 --> 00:58:34.700 align:middle line:90% And this is our hash value. 00:58:34.700 --> 00:58:37.740 align:middle line:84% So here, this f is defined as follows. 00:58:37.740 --> 00:58:43.080 align:middle line:84% So F x1 to xn, given index i, it will output of i as-- 00:58:43.080 --> 00:58:44.850 align:middle line:90% i as coordinate. 00:58:44.850 --> 00:58:49.520 align:middle line:84% So intuitively, we just pick the xi under the hood of FHE. 00:58:49.520 --> 00:58:56.730 align:middle line:90% 00:58:56.730 --> 00:58:58.790 align:middle line:84% So here, so this is a hash function 00:58:58.790 --> 00:59:03.150 align:middle line:84% because the size of the hash value is just a ciphertext. 00:59:03.150 --> 00:59:07.015 align:middle line:84% So the size of the hash value is poly lambda. 00:59:07.015 --> 00:59:10.880 align:middle line:90% 00:59:10.880 --> 00:59:15.330 align:middle line:84% And the key indistinguishability follows from the security of FHE 00:59:15.330 --> 00:59:17.520 align:middle line:90% because the index i is hiding. 00:59:17.520 --> 00:59:22.980 align:middle line:90% 00:59:22.980 --> 00:59:26.220 align:middle line:84% So the second property, this statistical binding, 00:59:26.220 --> 00:59:29.520 align:middle line:84% you can show it directly because the hash 00:59:29.520 --> 00:59:34.530 align:middle line:84% value contains the homomorphic encryption of xi. 00:59:34.530 --> 00:59:40.620 align:middle line:90% 00:59:40.620 --> 00:59:41.740 align:middle line:90% Any questions? 00:59:41.740 --> 00:59:48.120 align:middle line:90% 00:59:48.120 --> 00:59:51.360 align:middle line:84% So later, we will use this SSB, but we will 00:59:51.360 --> 00:59:53.290 align:middle line:90% use an additional property. 00:59:53.290 --> 00:59:57.030 align:middle line:84% So this property is called extraction. 00:59:57.030 --> 01:00:03.150 align:middle line:84% So intuitively, this hash value, it 01:00:03.150 --> 01:00:05.200 align:middle line:90% contains the ciphertext of xi. 01:00:05.200 --> 01:00:10.500 align:middle line:90% So in fact, it contains FHE. 01:00:10.500 --> 01:00:14.410 align:middle line:90% 01:00:14.410 --> 01:00:17.120 align:middle line:84% And if you know the secret key of FHE, 01:00:17.120 --> 01:00:20.930 align:middle line:84% you can even decrypt this i from the hash value. 01:00:20.930 --> 01:00:23.450 align:middle line:90% So we need the extraction. 01:00:23.450 --> 01:00:27.460 align:middle line:90% 01:00:27.460 --> 01:00:32.470 align:middle line:84% So the extraction property says that there exists an extractor. 01:00:32.470 --> 01:00:34.760 align:middle line:84% So extractor is a polynomial time algorithm. 01:00:34.760 --> 01:00:41.080 align:middle line:84% And moreover, so in the key generation algorithm 01:00:41.080 --> 01:00:43.180 align:middle line:90% I will add a trapdoor in it. 01:00:43.180 --> 01:00:46.370 align:middle line:84% So the key generator will also output some trapdoor. 01:00:46.370 --> 01:00:52.300 align:middle line:84% And there is some extractor such that the extractor will 01:00:52.300 --> 01:00:57.410 align:middle line:84% take the trapdoor as input and also the hash value as input, 01:00:57.410 --> 01:01:00.760 align:middle line:90% and it will extract something. 01:01:00.760 --> 01:01:04.450 align:middle line:84% And we further require the extractor 01:01:04.450 --> 01:01:11.140 align:middle line:84% has correctness, which means, for any x1 to xn, 01:01:11.140 --> 01:01:13.715 align:middle line:90% if you hash it under a P k-- 01:01:13.715 --> 01:01:17.840 align:middle line:90% 01:01:17.840 --> 01:01:23.140 align:middle line:84% so let's say S. S is the hash of the x1 to xn. 01:01:23.140 --> 01:01:28.430 align:middle line:90% 01:01:28.430 --> 01:01:32.360 align:middle line:84% Then the extracted value is consistent with the xi, with xi. 01:01:32.360 --> 01:01:42.230 align:middle line:90% 01:01:42.230 --> 01:01:46.160 align:middle line:84% So this is the extraction correctness-- 01:01:46.160 --> 01:01:55.320 align:middle line:84% so if the key, if this hash key is for the i, s position, 01:01:55.320 --> 01:01:57.445 align:middle line:84% if the hash key is generated for the i, s position. 01:01:57.445 --> 01:02:07.700 align:middle line:90% 01:02:07.700 --> 01:02:13.320 align:middle line:84% So now we will go back to the construction. 01:02:13.320 --> 01:02:17.940 align:middle line:84% So now we have this SSB hash from FHE. 01:02:17.940 --> 01:02:19.950 align:middle line:84% We'll go back to this construction 01:02:19.950 --> 01:02:25.110 align:middle line:84% and modify this hash function we use. 01:02:25.110 --> 01:02:33.120 align:middle line:84% So the hash function we use, we will use a SSB hash. 01:02:33.120 --> 01:02:39.840 align:middle line:84% And the SSB key, we will move it to the-- 01:02:39.840 --> 01:02:42.480 align:middle line:84% we'll add the SSB key to the CRS. 01:02:42.480 --> 01:02:46.360 align:middle line:90% So this is SSB key. 01:02:46.360 --> 01:02:51.450 align:middle line:90% 01:02:51.450 --> 01:02:56.520 align:middle line:84% So now we will use this SSB hash to hash each column of the PCP 01:02:56.520 --> 01:02:58.760 align:middle line:90% matrix to this PCP matrix. 01:02:58.760 --> 01:03:03.690 align:middle line:90% 01:03:03.690 --> 01:03:07.680 align:middle line:84% And all the other things are the same as before. 01:03:07.680 --> 01:03:09.050 align:middle line:90% Any questions? 01:03:09.050 --> 01:03:12.640 align:middle line:84% OK, yeah, maybe we also need to-- 01:03:12.640 --> 01:03:17.740 align:middle line:84% when we verify the hash, we also use SSB to recompute each column 01:03:17.740 --> 01:03:18.690 align:middle line:90% and verify it. 01:03:18.690 --> 01:03:30.940 align:middle line:90% 01:03:30.940 --> 01:03:33.820 align:middle line:84% AUDIENCE: [INAUDIBLE], when you're doing the SSB hash, 01:03:33.820 --> 01:03:35.920 align:middle line:90% what i are you putting in? 01:03:35.920 --> 01:03:37.443 align:middle line:90% Or you just don't even need one? 01:03:37.443 --> 01:03:38.360 align:middle line:90% ZHENGZHONG JIN: Right. 01:03:38.360 --> 01:03:38.860 align:middle line:90% Exactly. 01:03:38.860 --> 01:03:41.830 align:middle line:84% So in fact, in the actual construction, 01:03:41.830 --> 01:03:43.630 align:middle line:84% in fact, you don't even need the i 01:03:43.630 --> 01:03:46.840 align:middle line:84% because this FHE ciphertext, in the actual construction, 01:03:46.840 --> 01:03:47.930 align:middle line:90% is a pseudorandom. 01:03:47.930 --> 01:03:52.220 align:middle line:84% But you can put any index i there. 01:03:52.220 --> 01:03:52.720 align:middle line:90% Yeah. 01:03:52.720 --> 01:03:57.050 align:middle line:90% 01:03:57.050 --> 01:04:04.452 align:middle line:84% So now if we use the SSB hash to hash each column of this matrix, 01:04:04.452 --> 01:04:05.160 align:middle line:90% what will happen? 01:04:05.160 --> 01:04:10.850 align:middle line:90% 01:04:10.850 --> 01:04:15.290 align:middle line:84% So let's say if the SSB hash is generate-- the hash key 01:04:15.290 --> 01:04:18.980 align:middle line:84% is generated for some index i star. 01:04:18.980 --> 01:04:26.075 align:middle line:84% So then intuitively, this means this SSB is binding for the i, 01:04:26.075 --> 01:04:29.930 align:middle line:90% s row of this matrix. 01:04:29.930 --> 01:04:36.300 align:middle line:84% The reason is that, for each hash value, we hash it by-- 01:04:36.300 --> 01:04:42.470 align:middle line:84% we obtain it by hashing some column of this matrix. 01:04:42.470 --> 01:04:43.850 align:middle line:84% For example, the first hash value 01:04:43.850 --> 01:04:46.950 align:middle line:84% is obtained by hashing the first column of this matrix. 01:04:46.950 --> 01:04:51.120 align:middle line:84% And now, if the SSB is binding for the i, s coordinate. 01:04:51.120 --> 01:04:53.510 align:middle line:84% So the i, s coordinate now corresponds to the i, s 01:04:53.510 --> 01:04:56.600 align:middle line:84% row of this matrix, the first coordinate of the i, 01:04:56.600 --> 01:04:58.310 align:middle line:90% s row of this matrix. 01:04:58.310 --> 01:05:00.390 align:middle line:84% And the same is true for other columns. 01:05:00.390 --> 01:05:06.150 align:middle line:84% So for each column, we will bind the i, s position. 01:05:06.150 --> 01:05:09.470 align:middle line:84% And that means this SSB is binding for the i, 01:05:09.470 --> 01:05:17.280 align:middle line:90% s row, so for the i stars row. 01:05:17.280 --> 01:05:21.390 align:middle line:84% And intuitively, you can think h1 01:05:21.390 --> 01:05:25.560 align:middle line:84% to hL will contain the full information about the i, s 01:05:25.560 --> 01:05:31.110 align:middle line:84% row of this matrix because the h1 to hL, 01:05:31.110 --> 01:05:33.850 align:middle line:90% they are just FHE ciphertext. 01:05:33.850 --> 01:05:40.635 align:middle line:84% So it contains the actual value of the i, s row. 01:05:40.635 --> 01:05:44.190 align:middle line:90% Any questions? 01:05:44.190 --> 01:05:47.543 align:middle line:84% AUDIENCE: How does that help make a relation [INAUDIBLE] 01:05:47.543 --> 01:05:48.460 align:middle line:90% ZHENGZHONG JIN: Right. 01:05:48.460 --> 01:05:49.380 align:middle line:90% A good question. 01:05:49.380 --> 01:05:55.055 align:middle line:90% So let's continue this proof. 01:05:55.055 --> 01:06:17.500 align:middle line:90% 01:06:17.500 --> 01:06:21.140 align:middle line:84% So we want to prove the soundness of this SNARG. 01:06:21.140 --> 01:06:23.680 align:middle line:90% So how do we prove it? 01:06:23.680 --> 01:06:25.480 align:middle line:84% So to prove the soundness, we need 01:06:25.480 --> 01:06:40.330 align:middle line:84% to show for any x1 to xk such that x1 to xk 01:06:40.330 --> 01:06:42.120 align:middle line:90% is in L doesn't hold. 01:06:42.120 --> 01:06:45.190 align:middle line:90% 01:06:45.190 --> 01:06:48.315 align:middle line:84% Then no cheating prover can break the SNARG. 01:06:48.315 --> 01:06:51.838 align:middle line:90% 01:06:51.838 --> 01:06:54.490 align:middle line:84% So we start with the statement x1 01:06:54.490 --> 01:06:57.350 align:middle line:84% to xk all in language L doesn't hold. 01:06:57.350 --> 01:06:59.590 align:middle line:90% But what does this mean? 01:06:59.590 --> 01:07:05.950 align:middle line:84% So the key observation here is that, so if this doesn't hold, 01:07:05.950 --> 01:07:09.000 align:middle line:90% then there exists some index i. 01:07:09.000 --> 01:07:11.100 align:middle line:90% Let's say it's index i star-- 01:07:11.100 --> 01:07:18.330 align:middle line:84% some index i star such that this xi star is not in L. 01:07:18.330 --> 01:07:25.390 align:middle line:84% So it means that, if you want to prove the soundness, 01:07:25.390 --> 01:07:28.750 align:middle line:84% there is one statement xi star that is not in this language. 01:07:28.750 --> 01:07:32.350 align:middle line:84% And the goal is to just catch this i star. 01:07:32.350 --> 01:07:34.360 align:middle line:90% Then we can prove the soundness. 01:07:34.360 --> 01:07:36.940 align:middle line:90% 01:07:36.940 --> 01:07:39.330 align:middle line:84% So we only need to use the one statement is not 01:07:39.330 --> 01:07:40.650 align:middle line:90% in this language. 01:07:40.650 --> 01:07:43.710 align:middle line:90% And that's how we use SSB. 01:07:43.710 --> 01:07:48.450 align:middle line:84% So remember, SSB can bind the i, s position, 01:07:48.450 --> 01:07:50.350 align:middle line:90% i, s row of this PCP matrix. 01:07:50.350 --> 01:07:54.510 align:middle line:84% So the i, s row of the PCP matrix is the PCP for xi. 01:07:54.510 --> 01:07:57.580 align:middle line:90% 01:07:57.580 --> 01:07:59.320 align:middle line:90% So that gives us soundness. 01:07:59.320 --> 01:08:00.860 align:middle line:90% So that's the intuition. 01:08:00.860 --> 01:08:03.640 align:middle line:90% 01:08:03.640 --> 01:08:09.520 align:middle line:84% AUDIENCE: My belief is that the image that you're binding 01:08:09.520 --> 01:08:11.940 align:middle line:84% is the one that's not in the language. 01:08:11.940 --> 01:08:13.190 align:middle line:90% ZHENGZHONG JIN: Good question. 01:08:13.190 --> 01:08:17.120 align:middle line:84% So the proof, so the formal proof goes like this. 01:08:17.120 --> 01:08:20.200 align:middle line:90% 01:08:20.200 --> 01:08:21.020 align:middle line:90% Good question. 01:08:21.020 --> 01:08:23.930 align:middle line:84% So the formal proof works as follows. 01:08:23.930 --> 01:08:31.930 align:middle line:84% So in the first hybrid h0, we have an adversary. 01:08:31.930 --> 01:08:36.100 align:middle line:84% So suppose we have some adversary, P star, that 01:08:36.100 --> 01:08:39.040 align:middle line:84% can break the construction, break the soundness 01:08:39.040 --> 01:08:39.950 align:middle line:90% of the construction. 01:08:39.950 --> 01:08:43.000 align:middle line:90% So what it will receive? 01:08:43.000 --> 01:08:49.850 align:middle line:84% So P star will receive the CRS, some CRS. 01:08:49.850 --> 01:08:53.800 align:middle line:84% And it will output some cheating proof pi star. 01:08:53.800 --> 01:08:56.820 align:middle line:84% And the verification of the proof will be accepted. 01:08:56.820 --> 01:09:05.930 align:middle line:90% 01:09:05.930 --> 01:09:10.260 align:middle line:84% So the verification of the proof will be accepted. 01:09:10.260 --> 01:09:13.640 align:middle line:84% And this happens with probability 01:09:13.640 --> 01:09:14.800 align:middle line:90% greater than some epsilon. 01:09:14.800 --> 01:09:26.270 align:middle line:90% 01:09:26.270 --> 01:09:29.499 align:middle line:90% So in the next hybrid, I will-- 01:09:29.499 --> 01:09:45.649 align:middle line:90% 01:09:45.649 --> 01:09:50.640 align:middle line:84% so in the next hybrid, I know there is an index i star. 01:09:50.640 --> 01:09:55.890 align:middle line:84% And the xi star is not in the language. 01:09:55.890 --> 01:09:58.990 align:middle line:90% So this i star is fixed. 01:09:58.990 --> 01:10:01.540 align:middle line:90% So I can switch the CRS. 01:10:01.540 --> 01:10:10.470 align:middle line:84% So in the hybrid h1, I will switch the CRS 01:10:10.470 --> 01:10:22.380 align:middle line:84% to this CRS generated by SSB generation, using the i star. 01:10:22.380 --> 01:10:26.805 align:middle line:90% So let's denote this by SSB. 01:10:26.805 --> 01:10:29.820 align:middle line:90% 01:10:29.820 --> 01:10:48.600 align:middle line:84% Sorry-- this to ki star, SSB ki star. 01:10:48.600 --> 01:10:52.850 align:middle line:84% And I can argue, if this is the case, then we still have-- 01:10:52.850 --> 01:10:55.690 align:middle line:90% 01:10:55.690 --> 01:10:59.140 align:middle line:84% so this new CRS, let's call it CRS star. 01:10:59.140 --> 01:11:04.960 align:middle line:84% So CRS star will contain this SSB ki star in it. 01:11:04.960 --> 01:11:09.670 align:middle line:84% And it will generate some pi, pi star. 01:11:09.670 --> 01:11:20.950 align:middle line:84% And it still has the property S. So this is greater than 1 minus 01:11:20.950 --> 01:11:22.750 align:middle line:90% negligible. 01:11:22.750 --> 01:11:27.520 align:middle line:90% So this is true because-- 01:11:27.520 --> 01:11:30.710 align:middle line:84% so this is just follows from the key indistinguishability 01:11:30.710 --> 01:11:31.915 align:middle line:90% because the key is hiding. 01:11:31.915 --> 01:11:42.100 align:middle line:90% 01:11:42.100 --> 01:11:45.280 align:middle line:84% So now in this hybrid, we switch the-- 01:11:45.280 --> 01:11:51.740 align:middle line:84% so intuitively, you can think given-- 01:11:51.740 --> 01:11:56.240 align:middle line:84% so given any cheating proof, in fact, the i, s row of the PCP 01:11:56.240 --> 01:11:58.070 align:middle line:90% is already fixed. 01:11:58.070 --> 01:12:00.770 align:middle line:84% So next we will reach a contradiction using 01:12:00.770 --> 01:12:02.095 align:middle line:90% correlation-intractable hash. 01:12:02.095 --> 01:12:12.740 align:middle line:90% 01:12:12.740 --> 01:12:21.470 align:middle line:90% So if the verifier is accepted-- 01:12:21.470 --> 01:12:28.100 align:middle line:84% so the claim is for any proof, for any cheating proof, 01:12:28.100 --> 01:12:32.780 align:middle line:84% the cheating proof has this h1 star 01:12:32.780 --> 01:12:39.350 align:middle line:84% to hL star and Q star and gamma star. 01:12:39.350 --> 01:12:41.390 align:middle line:84% So gamma star is the pseudorandom message 01:12:41.390 --> 01:12:44.150 align:middle line:90% I denoted as gamma star. 01:12:44.150 --> 01:12:46.670 align:middle line:84% So this is information threshold claim. 01:12:46.670 --> 01:12:51.180 align:middle line:84% And the claim is just if the cheating proof is accepted-- 01:12:51.180 --> 01:12:54.190 align:middle line:90% 01:12:54.190 --> 01:13:06.760 align:middle line:84% oh, sorry-- then it must be the case that this Q star-- 01:13:06.760 --> 01:13:13.330 align:middle line:84% sorry-- then it must be the case that this h1 to hL star-- 01:13:13.330 --> 01:13:19.880 align:middle line:90% Q star is in this relation R. 01:13:19.880 --> 01:13:27.760 align:middle line:84% So R is almost the R above, but I will redefine a new R. 01:13:27.760 --> 01:13:42.310 align:middle line:84% So R, it will contain all of the h1 to hL and Q. 01:13:42.310 --> 01:13:47.230 align:middle line:84% So given h1 to hL, I can use the extractor 01:13:47.230 --> 01:14:01.240 align:middle line:84% to extract a PCP because that's from the extraction of the SSB. 01:14:01.240 --> 01:14:07.060 align:middle line:84% So this PCP is the PCP for the i star position. 01:14:07.060 --> 01:14:11.810 align:middle line:84% And then I define this R as follows. 01:14:11.810 --> 01:14:22.090 align:middle line:84% So I require the PCP is accepted for xi. 01:14:22.090 --> 01:14:37.280 align:middle line:90% 01:14:37.280 --> 01:14:42.910 align:middle line:84% So in this definition of R, I first extract the i, s PCP. 01:14:42.910 --> 01:14:48.410 align:middle line:84% And then I check if the query Q can 01:14:48.410 --> 01:14:52.370 align:middle line:84% make this PCP be accepted for the i, 01:14:52.370 --> 01:14:55.380 align:middle line:90% s star statement, xi star. 01:14:55.380 --> 01:14:58.220 align:middle line:90% 01:14:58.220 --> 01:15:02.136 align:middle line:90% So any questions? 01:15:02.136 --> 01:15:05.690 align:middle line:90% 01:15:05.690 --> 01:15:06.460 align:middle line:90% Is this clear? 01:15:06.460 --> 01:15:14.600 align:middle line:90% 01:15:14.600 --> 01:15:20.870 align:middle line:84% So intuitively, in the third round message, if the proof is 01:15:20.870 --> 01:15:23.300 align:middle line:90% accepted, then anything-- 01:15:23.300 --> 01:15:25.910 align:middle line:84% so in the third-round message, the prover 01:15:25.910 --> 01:15:28.800 align:middle line:84% needs to give some columns of the queried position. 01:15:28.800 --> 01:15:32.780 align:middle line:84% So for all of those columns, if you 01:15:32.780 --> 01:15:36.530 align:middle line:84% look at the i star row of it, it must 01:15:36.530 --> 01:15:42.410 align:middle line:84% be consistent with the extracted PCP 01:15:42.410 --> 01:15:45.780 align:middle line:84% because we have the SSB extraction correctness. 01:15:45.780 --> 01:15:52.740 align:middle line:90% 01:15:52.740 --> 01:15:54.520 align:middle line:90% So we define the R in this way. 01:15:54.520 --> 01:15:57.185 align:middle line:84% So in fact, it's the same as the R above. 01:15:57.185 --> 01:15:59.970 align:middle line:90% 01:15:59.970 --> 01:16:05.700 align:middle line:84% So now to prove this claim is just-- 01:16:05.700 --> 01:16:09.460 align:middle line:84% the proof of this claim is just the argument I set up just now. 01:16:09.460 --> 01:16:14.370 align:middle line:84% So for any cheating proof, if the verification of the proof 01:16:14.370 --> 01:16:18.210 align:middle line:84% is accepted, then from the correctness of the extraction-- 01:16:18.210 --> 01:16:22.920 align:middle line:90% 01:16:22.920 --> 01:16:27.330 align:middle line:84% from the correctness of the extraction-- 01:16:27.330 --> 01:16:29.250 align:middle line:90% maybe let me write it. 01:16:29.250 --> 01:16:44.900 align:middle line:84% So if pi star is accepted, then from the SSB extraction 01:16:44.900 --> 01:17:01.580 align:middle line:84% correctness we know this PCP i star. 01:17:01.580 --> 01:17:10.550 align:middle line:84% So the PCP i star, we extracted from this h1 to hQ-- 01:17:10.550 --> 01:17:11.845 align:middle line:90% sorry, h1 to hL. 01:17:11.845 --> 01:17:30.980 align:middle line:90% 01:17:30.980 --> 01:17:35.450 align:middle line:84% So let's say it's some PCP i star-- 01:17:35.450 --> 01:17:36.110 align:middle line:90% PCP star. 01:17:36.110 --> 01:17:44.670 align:middle line:90% 01:17:44.670 --> 01:17:53.940 align:middle line:84% If you look at the Q's coordinate, then it must-- 01:17:53.940 --> 01:17:55.810 align:middle line:90% OK, so let me write in this way. 01:17:55.810 --> 01:18:05.160 align:middle line:90% 01:18:05.160 --> 01:18:09.090 align:middle line:84% The column star-- so column star. are-- 01:18:09.090 --> 01:18:23.280 align:middle line:84% yeah Q-- so where the third-round messages are just 01:18:23.280 --> 01:18:23.780 align:middle line:90% the columns. 01:18:23.780 --> 01:18:44.590 align:middle line:90% 01:18:44.590 --> 01:18:46.320 align:middle line:90% So that's the soundness proof. 01:18:46.320 --> 01:18:49.760 align:middle line:90% 01:18:49.760 --> 01:18:52.660 align:middle line:84% So that's the proof of the claim. 01:18:52.660 --> 01:18:55.000 align:middle line:90% Yeah, any question? 01:18:55.000 --> 01:18:59.230 align:middle line:84% AUDIENCE: In the hybrid, how do you 01:18:59.230 --> 01:19:04.960 align:middle line:84% identify which i star because you need to know which statement 01:19:04.960 --> 01:19:05.890 align:middle line:90% was right [INAUDIBLE]. 01:19:05.890 --> 01:19:06.340 align:middle line:90% ZHENGZHONG JIN: Right. 01:19:06.340 --> 01:19:06.923 align:middle line:90% Good question. 01:19:06.923 --> 01:19:10.280 align:middle line:84% So this soundness proof is non-uniform. 01:19:10.280 --> 01:19:11.990 align:middle line:90% So it's a non-adaptive. 01:19:11.990 --> 01:19:16.070 align:middle line:84% So the soundness proof starts with a fixed x1 to xk. 01:19:16.070 --> 01:19:20.810 align:middle line:84% So for any fixed x1 to xk, you know there exists an i star. 01:19:20.810 --> 01:19:23.320 align:middle line:90% That xi star is false. 01:19:23.320 --> 01:19:28.060 align:middle line:84% So there exists a fixed i star such that xi star is false, 01:19:28.060 --> 01:19:32.203 align:middle line:90% is not in L. 01:19:32.203 --> 01:19:33.370 align:middle line:90% AUDIENCE: So that's a given? 01:19:33.370 --> 01:19:34.953 align:middle line:84% ZHENGZHONG JIN: Yeah, so that's given. 01:19:34.953 --> 01:19:37.960 align:middle line:84% So you can think it's a given to the reduction 01:19:37.960 --> 01:19:39.370 align:middle line:90% in a non-uniform way. 01:19:39.370 --> 01:19:39.870 align:middle line:90% Yeah. 01:19:39.870 --> 01:20:04.510 align:middle line:90% 01:20:04.510 --> 01:20:07.866 align:middle line:90% So this is from the extracted. 01:20:07.866 --> 01:20:11.400 align:middle line:90% 01:20:11.400 --> 01:20:14.340 align:middle line:84% So this is from the SSB extraction correctness. 01:20:14.340 --> 01:20:15.330 align:middle line:90% You have this. 01:20:15.330 --> 01:20:21.030 align:middle line:84% We have the consistency between this PCP extracted 01:20:21.030 --> 01:20:24.430 align:middle line:84% and the proof in the third round. 01:20:24.430 --> 01:20:27.390 align:middle line:84% And if the proof, if this cheating proof, pi star, 01:20:27.390 --> 01:20:31.950 align:middle line:84% is accepted, then we can use the fact 01:20:31.950 --> 01:20:35.130 align:middle line:90% that this pi star is accepted. 01:20:35.130 --> 01:20:39.750 align:middle line:84% So if it is accepted, then we know 01:20:39.750 --> 01:20:46.100 align:middle line:84% this Q. This Q can make this PCP star be accepted. 01:20:46.100 --> 01:20:49.590 align:middle line:90% 01:20:49.590 --> 01:20:55.260 align:middle line:84% So then that completes this claim. 01:20:55.260 --> 01:20:59.790 align:middle line:84% And finally, from this claim you can 01:20:59.790 --> 01:21:01.290 align:middle line:84% use the correlation-intractability 01:21:01.290 --> 01:21:04.530 align:middle line:90% of the CI hash. 01:21:04.530 --> 01:21:15.550 align:middle line:84% So pi star-- so if the proof is accepted, 01:21:15.550 --> 01:21:25.580 align:middle line:84% then this is the extracted PCP from here. 01:21:25.580 --> 01:21:28.380 align:middle line:90% 01:21:28.380 --> 01:21:31.090 align:middle line:84% It will make this a PCP verification accepted. 01:21:31.090 --> 01:21:32.940 align:middle line:90% Yeah. 01:21:32.940 --> 01:21:34.260 align:middle line:90% OK. 01:21:34.260 --> 01:21:35.790 align:middle line:90% Let's have a break. 01:21:35.790 --> 01:21:37.340 align:middle line:90% Yeah.