 OK, so welcome to the second session on zero knowledge. First paper is entitled on the size of pairing based non-interactive arguments by Jens Gold from UCL. Unsurprisingly, the talk is given by Jens Gold. So I'm going to talk about non-interactive zero knowledge proofs. So the idea is that we have a common reference string. The prover makes some statement that x belongs to a particular language. The prover holds a witness that x really is in this relation that defines the NP language. The prover then creates a proof, sends it to the verifier, and the verifier checks it and says, OK, so OK. And completeness says that if the prover really has a witness and the statement really does belong to the language, it should be possible to convince an honest verifier. Now we want two security properties from this non-interactive zero knowledge argument. First is soundness, that if the verifier accepts the statement, it's because the statement really is true, x really does belong to the language. And the second one is zero knowledge, that the proof does not reveal anything, but that the statement really belongs to the language. And we typically define that through having a simulator that could simulate proofs. And there are lots of applications of non-interactive zero knowledge arguments ranging from digital signatures and encryption to various forms of eCache, eVoting, internet voting, multipartic computation, verifiable cloud computing. So I'm going to talk today about very efficient non-interactive zero knowledge arguments. So they have to be very small size. They have to be very efficient to verify. One typical example mentioned this context is verifiable computation. So you imagine you have a weak client, outsources a computation to the cloud, gets a result back, and would like to get a proof that the result is correct. But here we want the proof to be compact, we want the verification to be very efficient, because we don't want the client to do the entire computation itself to verify that it's correct. There are also various suggestions for using these kind of very efficient non-interactive arguments of knowledge in connection with the eCache system, zero coin and Pinocchio coin, for instance. OK, so there are two contributions. The first one is a construction of a non-interactive zero knowledge argument. It has perfect completeness. So if the statement is true, the prover can convince and will always convince the verifier. It has perfect zero knowledge. So it does not leak any information whatsoever, except that the statement is true. And then we'll prove computational soundness. And there we'll be using very strong assumption. We'll essentially use the generic group model in a binomial group. So it's sort of very aggressive choice of parameters to get optimal efficiency. So we're going to work with type three pairings, asymmetric pairings, because those are the most efficient pairings. And the proof size will be three group elements. And we will also have fairly low computation for the prover and the verifier. So the very small size, I have to have the argument, makes this what is called a snark, a succinct, non-interactive argument of knowledge. The second contribution is sort of looking at, from the other side, and saying, how low can we go? What is the best possible efficiency? And we'll prove that you cannot have a one group element proof. So we'll look at pairing-based, non-interactive, zero-knowledge arguments. We don't care whether there's zero-knowledge or not, it holds regardless. So as long as you have an argument that's complete and sound, there's low bound holds. There'll be a few restrictions on the type of argument because we wanted to capture the essence of a pairing-based argument. And we'll prove then an asymmetric pairing setting that you cannot have one group element proof. It's an open question, so there's a gap here, right? I have a three group element construction. I have a one group element impossibility result. I don't know whether you can do it with two group elements or not enough. I've been trying to think about it. I really have no intuition one way or the other. So that's a nice open problem. So I'm going to work in a pairing-based setting. So I'll assume we have a bilinear group of prime order p. So we'll have three cyclic groups, g1, g2 are the source groups, and gt is the target group. And I'll have a pairing that maps pairs of elements from the first and the second source group into the target group. And I'll assume here that the generic group operation, so deciding group membership, doing multiplications of group elements, computing the pairing result efficiently doable. So the two types of groups, the symmetric groups, where g1 and g2, the two source groups, are identical. An asymmetric setting, where they're not identical, where there's actually no efficiently computable isomorphism in either direction between the source groups. And for efficiency reasons, to get optimal efficiency, I'll be working mostly in the type 3 setting with asymmetric pairings. And that's where the lower bounds will hold. But the construction can also be instantiated with symmetric bilinear groups with almost no change. So first, I'll change notation a little because I want to use additive notation for these groups because that's much more efficient, easier to do. So I'll use this notation where I put an element in the brackets. 1 as meaning this a is the discrete logarithm of the element in source group 1. And b in brackets with a subscript 2 means that b is the discrete logarithm of the element in source group 2 and so forth. So in particular, here we'll have the generators now can be written as 1s in brackets. The neutral elements will be 0s in brackets. And the advantage of this notation is that now we can sort of use standard linear algebra notation. So I can define a dot product. So if I take a vector of group elements and take the inner product with a vector of scalar errors, then I'll efficiently compute the resulting group element. I can take vectors of group elements in first source group and in second source group. And I can take this dot product. And what I'm really doing is I'm taking the first group element in the first vector and the first group element in the second vector and pairing them together. And then I'm doing the same thing with the second group elements in each vector. And then I'm multiplying all those pairings. And that allows me to compute this inner product in the target group. And now you can also do things like taking a vector of group elements and multiplying a matrix on that. And you'll get another vector of group elements. So that's nice. Now we'll be doing a lot of linear algebra. So let me define what I mean by a pairing-based snark. So the way these constructions typically work is that we have some NP relation R. It has some statements. It has some witnesses. And the common reference string, what the setup does, it generates vectors, sigma 1 and sigma 2. And then it bets that in group elements in the first source group and in group elements in the second source group. And that will be your common reference string. The proof typically also works in two steps. So typically what the prover does, it gets the statement of the witness and it computes a couple of matrices. And then the way it computes the proof is it takes the first matrix and multiplies it with all the group elements in the common reference string from the first source group and computes a bunch of group elements in the first source group, which is first half of the proof. And then it does the same thing in the second source group. So if you look at sort of all the snarks that have appeared in literature, they all follow this structure here. The essence is that you can compute the proofs with linear operations on the group elements in the common reference string. Okay. And finally verification always works something like this. So we have the verifier. Okay, it takes us input the statement and it produces a bunch of matrices. Okay. And then it uses those matrices, essentially these are pairing product equations. It takes elements from the common reference string, takes elements from the proofs and it computes some sort of pairing product equations of all these elements. And you can write it in this nice matrix form. Okay, so this is the structure of all the snarks that, pairing based snarks that have appeared in the literature. Okay, and the nice thing is of course that everything here can be done just with generic group operations. Okay, so I'll start with the lower bound, okay? So I'll consider a language that has a hard decisional problem. So the two sampling algorithms, yes and no. And the yes algorithm samples statements that are in the language. No algorithms say sample statements that are not in the language. And I'll assume that it's hard to distinguish whether it's been sampled as a yes or a no instance. Okay, and I'll prove this theory that if you have a pairing based snark in the asymmetric setting, then, and you want to look at a language which has these hard decisional problems, then you need at least two group elements in the proof. So the intuition here is that if you just have a single element in the proof, then it has to be either an element in source group one or it has to be an element in source group two, right? And if you remember the kind of the test the verifier does, it does pairings of elements in source group one with elements in source group one, in source group two, right? But if the proof is only one of them, essentially what you get is a linear equation in the verification, okay? And we can in generalize this theorem here to rule out any linear decision procedure for the verifier. So essentially, linear complexity and verification is not sufficient for languages with hard to decide relations, okay? So I'll give a sketch of this proof. I'll look at a very simple example. So I'll say, let's say I have the case where we have a proof that's just one group element, source group two, that's of course without loss of generality. And I'll also, for simplicity, say that we have just one verification equation. It's not too hard to generalize too many verification equations, okay? So if you have just one verification equation, it can be written as sort of a matrix A that does things with just elements in the common reference strings and then a vector B that does something with a proof. So I'll just, assuming that we have this type of verification equation, I'll construct a decision algorithm that decides whether a statement is in the language or not in the language. And the structure is less, there are sort of two phases. So in the first phase, what we do is we sample a lot of yes instances, okay? And then the algorithm constructs the corresponding matrices. In this case, it's just a vector because it's just one group element proof. It constructs the test matrices that the verify would use. And then we define a vector space that kind of takes all these good yes samples that would satisfy the verification equation, okay? So we'll generate a vector space, okay? And the idea is that if you sample enough, then we get sort of all possible solutions that you could think of in this vector space here, okay? Because, well, these matrices, they have polynomial dimensions. So eventually, if you keep sampling, you'll get more and more generators. At some point, they will start becoming linearly dependent and you've sampled all the solutions you could have in this space. Then in the second phase, the algorithm now looks at the statement that it wants to decide whether it's in language or not, right? And it simply samples this test equation and then it tries to solve whether it can find a solution in this vector space, okay? Is there some proof matrix or proof vector that will allow it to have something in the space? And if the answer is yes, it does find a solution. This is just a system of linear equations. So that's easy to solve, right? Then it will say yes. This is a statement in language. And if it cannot find a solution, it will say no, this is not in the language. So let's think about it. What if it's a yes sample? Well, there exists some witness. Prover doesn't know the witness, but by the existence of the witness, we could have constructed some proof vector. So there must be a solution, right? And the algorithm will find a solution. So it'll say yes. With high probability, it will be in the vector space and it will say yes. What if we are not in the language if Phi is not in the language? Well, by the completeness of the snark, then all these solutions that it samples will be correct. So anything it can find in the vector space corresponds to a solution to the verification equation, right? But by the soundness of the snark, if we have a statement none of the language should not be possible to find a solution, okay? And therefore, whatever it comes up with, any Pi vector it could think of, it must not lead to a solution, something that's in the vector space, and it should say no. So that gives us the lower bound that you cannot have one group element. You must have at least two group elements. Actually, you must have group elements both in source group one and in source group two because you cannot have a linear decision procedure, okay? Then I'll turn to the construction, okay? So I'll look at arithmetic circuit satisfiability. So I want to prove that I have some inputs and outputs to a circuit such that they respect all the multiplication and addition gates in the circuit, okay? And it will have perfect completeness that if the prover has a witness and it knows everything going on in the circuit, it's possible to convince the verifier. It'll have perfect zero knowledge that it does not leak any information about the witness that the prover has. And for soundness, I'll prove soundness in the generic group model. So I'll assume that we have an adversary that only uses generic group operation and show that such an adversary cannot break the scheme, okay? Again, for efficiency, I'm working in the asymmetric type three pairing setting and we'll get very low computation. We'll get very small proofs with just three group elements, okay? So let's look at an arithmetic circuit. So here's an example, right? It has some addition gates, it has some multiplication gates, okay? And you could think of maybe A1 is the statement, A2 is an output that's also part of the statement. What is the prover's witness? Well, that's A3 and A4, okay? Okay, so we can write this as a quadratic equation, okay? So this circuit is satisfied by all these A values if this equation here holds, okay? And notice here that it's very nice. We sort of get the addition gates for free. Actually, you just get one equation for every multiplication gate that you have. And generalize this a little, okay? So in general, we'll be looking at these sort of equations, quadratic equations that takes sums of the wire values with some weights, Ui, right? And then multiplies that to a sum of wire values with some weights, Vi, and hopes that the output is some sum of wire values with weights, Wi, okay? So in the equation before, the weights would be on the left-hand side, the Ui weights would be one for A1 and for A3 and zero for the other two, right? On the right-hand side, A3 would have weight, so V3 would be one, that's the weight of A3, right? And the other ones would be zero. And on the very right-hand side, we would have A2 has weight one and the other ones have zero. So that would give us this quadratic equation, okay? I'll use the convention that A0 is always one and that's to handle constants in these equations, okay? And an arithmetic circuit in this way defines an NP language that has statements A1 through AL and the rest of the wire values are witness values, okay? So I'll consider an equation then of this form here, okay? So we have a bunch of these equations. If we just look at one equation to start with, okay? I'll define these polynomials, so I'll pick some R, I'll define polynomials such that these polynomials evaluate in R actually give us exactly these values here, okay? And then you can see that this equation is actually satisfied if these polynomial equation holds modulo x minus R, R. Why is that? Well, because if you plug R into these polynomials here, you get exactly those weights that we want for this equation, right? So R is a root in this equation here, okay? Now we pick such R's for every single equation that we have in this arithmetic circuit, okay? And we get that this way all the equations hold if this thing here is zero module that the product of all these roots here, okay? So what this is is actually a quadratic arithmetic program, right? So this is sort of a standard transformation from arithmetic circuits to quadratic arithmetic programs. And general quadratic arithmetic program is defined as a bunch of polynomials with some statements, some witnesses that correspond to these A values, okay? And they have to satisfy this polynomial equation. So that's an NP complete language and now we have a very efficient transformation from arithmetic circuits to quadratic arithmetic programs. Okay, so now I'll give the construction. I don't know a better way to present it than just give you all the gory details here and excuse myself with that. At least this is much more efficient and easy to understand than all the other constructions in the literature. Okay, so the idea is that you'll have common reference strings containing a bunch of different group elements and coding these polynomials in random alpha, beta, gamma, delta and X chosen by the setup algorithm. The prover will then create three values, A, B and C and encode these as group elements. And it turns out that it can do this just with linear group operations on the elements in the common reference string provided that it knows the witness. And then the verifier is going to accept this if this last equation here holds. Okay, so the verify pairs together A and B. It has alpha and beta in the common reference string pairs those together. This equation here can be seen as sort of loading the statement. So it takes the statement values which everybody can compute. Okay, and then we have something here in the very end, the C value to balance out everything. Okay, and completeness. Well, you look at the proof, plug it into the verification equation and you check very carefully that everything works out. Okay, for zero knowledge, that's actually pretty easy to see. What the simulator does, it picks A at random, it picks B at random. And that's just like it would be in a real proof because we have the R, delta and S, delta here that makes these completely random group elements. Okay, and then it computes the C that matches the verification equation and solves the verification equation. And that's a good simulation. And then for soundness, I'm not going to talk much about that. The model is that we have a generic group adversary and by very careful analysis of all these details here, you see that it is actually sound against a generic group adversary. Efficiency is pretty good, right? Because the proof is just three group elements, two elements in source group one and one element in source group two. Okay, so what we get here, so here I have a comparison with prior work and we can see that we have a smaller proof size and we also have more efficient computation for the prover and the verifier and we have less verification equations than previous works. Okay, now it's interesting to think about what is it that gives us this efficiency and that's sort of two sources, okay? First of all, one reason is that we're just using a more aggressive compilation technique than prior works, right? We're just proving soundness in a generic group model whereas prior works relied on various knowledge of exponent assumptions. And this is something you could apply to the other schemes and you would also reduce the complexity of these schemes. Okay, the second source and this is sort of the contribution, the interesting part is that we actually have a carefully crafted verification equation that does sort of carefully map out things into the two source groups and splits them apart and gives us just one verification equation instead of having many verification equations and that's sort of where there's also a saving coming from. And Alessandro and Madras are very nice to implement this in Lipsnark and report about factor four to five saving compared to prior work on the provers time in computing this and of course smaller size and so forth. And with that, I'll conclude with a summary, right? So we have a lower bond now that a pairing based snark has to have at least two group elements and then a construction that gives us a three group element snark and unfortunately there's still this open question, can we do two group elements and I just don't know. Okay, thank you. Thank you, we are a bit late so we don't have time for questions actually. We're gonna have to continue with the next talk immediately. So we have to take questions offline by the end. One next speaker is setting up, I can tell you that the next talk is entitled, Efficient Serial Knowledge Arguments for Arithmetic Circuits in a Discrete Lock Setting. This is by Jonathan Buulu, Andrea Tiroli, Pyrrhus Scheiders, Jens Groth and Christoph Petit. And it looks like Pyrrhus is going to give the talk once he's set up.