 Hello everybody. Welcome to the first session. I hope you've all recovered from whatever you did last night. And it's about zero knowledge and we can have families of snark-friendly two chains of elliptic curves. And the speaker's going to be Joseph. Over to you. It's noninteractive arguments of knowledge. So those are proofs. So they are complete sound, but only computationally sound. So with respect to a computationally bounded prover. And they are noninteractive. So there is no interaction between the prover and the verifier throughout the protocol. And succent, which informally puts, means that a proof is very short and easy to verify. Yeah. So among those ZK snarks, so there are pre-processing ZK snarks for NP language. So we will be proving statements about a word belongs to a non-deterministic polynomial language. So just to put some notations, so we have our NP program F with public input X and Z, a private input W, such as the relation is satisfied. So Z equal to F of X and W. So snark is typically consist typically in three algorithms. So set up. So it takes the program F, some security parameter lambda and output some key material. So PK is improving key and VK is in verification key. So the proof algorithm takes basically all the inputs. So the public input and the private input and PK, which encodes the program to the prover. And output some proof here denoted pi. And so the verification algorithm takes basically all the public input and the proof pi and outputs a body and whether the proof is verified or not. So the setup can be done by anyone or in some protocols, which are trapped or by a trusted party or in a multi-party computation way. The proof in algorithm is done by one, basically the one who knows the secret W and verify anyone who has access to this proof and the public inputs. So we've been talking about zero knowledge rules, ZK snarks as a subset and preprocessing ZK snarks. And those preprocessing ZK snarks are best instantiated with pairings over elliptic curves. So we need an elliptic curve. So here it's given in short wire transforms. So defined over a finite field of prime characteristic or prime power. So it has a subgroup of prime order r. So r divides q plus 1 minus t. So t is the fobidian's trace. And so for pairings, we need this embedding degree to be small enough. So the embedding degree k is like the smallest integer such as r, the subgroup order divides q to the k minus 1. And so a billionaire pair is this billionaire map that goes from g1 cross g2 to gt. So g1 and g2 and gt are groups of order r. So g1 is the group of points on the elliptic curve divided by the base field, g2 over an extension field. And gt is on an extension fq to the k. So it's the athical of unity. And those three groups are of the same order r. So I will just give an example of one of the pairing-based snarks that is widely used and implemented nowadays. So our relation is z equal to f of x and w. So x, z and w here I'm giving them in vectors. So the setup, so output of these key materials which are a bunch of elements in these groups, in these pairing groups, g1, g2 and gt. The proving algorithm outputs three points on the curve, so on g1 and g2. So we see that they are constant size with respect to some security parameter lambda. And what we are interested in is the verification algorithm. So the verification algorithm is where the pairing computation is needed. So to verify the proof, it's boils down to verify this pairing product check, which is a check off. So we just need to compute some pairings between the proof element and the verification element. And this is basically how we verify the proof. So why we are talking about this is because we need to do so in this talk recursive proofs. That is proofs, verifying other proofs. So there are a bunch of applications for this. One of them is the proof aggregation because we've seen here that the proof is constant size. So imagine you have like a thousand of proofs. And if you do a proof of a thousand of proofs, then the resulting proof will be constant size. So you have like a single constant size proof that verifies a thousand of proofs. There are other applications for recursive proofs such as space on time complexity as we will see in the next talk by Miguel. So what we want to do is a proof for proof. So in pairing based slacks, so our NP program F, so leaves, so the computations are performed in FR, without the subgroup order of the elliptic curve. And the previous algorithm is done in G1 and G2, in instance, for G16, which are of order R. But the verification algorithm is a pairing computation, which takes place in a different field which is sort of the GT target group or at least the extension field FP to the K. So if you want to create a proof that verifies another proof, then there is an arithmetic mismatch. The problem is you need to express the pairing computation as an arithmetic circuit in FR. And the pairing computation leaves in FQ, or at least FQ to the K. So one first attempt would be to have a curve, an elliptic curve that has Q equal to R. But this is like the kind of curves that we do not use in cryptography, because the discrete logarithm is working in this case. The second attempt would be to simulate or to emulate the operations FQ in FR. So Q is now equal to R. So R is the subgroup order, Q is the field, so the size of the base field. So this is theoretically possible, but it results in a huge overhead. And the third attempt would be not to use the same elliptic curves for the proof and for the recursive proof, but to change the elliptic curves in order to not have this arithmetic mismatch. And this is what we call chains or cycles of elliptic curves. So just to explain this, so we will have here what I'm calling a snark zero. So it has a pairing E, so three groups G1, G2 and GT of order R. And then we instantiate this with an elliptic curve that we call annular curve. So E0 defined over FQ of prime order R. And we need to have a second snark, so a snark one that verifies a pairing computation that takes place in FQ. So we will instantiate it with different elliptic curves. So with a pairing E, where the pairing groups are of order Q. So this is the outer curve, so E1 defined over a different field Fs, but it has an order equal to the base field of the previous one, or at least that divides, so we can unknown some cofactor. So if we make abstraction of these, so given some integer Q, we search for a pairing friendly curve E1 of order H times Q over any finite field Fs. So this is already known in the literature, but if we take a look back, what we need exactly for a snark is a curve that is pairing friendly. But there is a condition for efficient implementation, which is R minus one. So the subgroup order minus one should be a high E2 adequate, which means it should be divisible by a high power of two. This is for implementing efficient fast Fourier transform. So because as I told you, the computations of the prover take place in FR, and it is basically some polynomial arithmetic, which are best implemented using fast Fourier transforms. And fast Fourier transforms are best implemented using RADX to FFTs. So we need the subgroup order minus one to be highly to adequate. So this is just for slacks. We can pick any elliptic curves on the literature that is pairing friendly, and we can see if we can make the R minus one highly to adequate. But if we want to do two chains, so recursive two chains, we can look at cycles, which means basically two elliptic curves for which the subgroup order of one is equal to the finite field of the other one, and vice versa. But unfortunately, we know only MNT4 and MNT6 for these cycles, which are not quite efficient at 128-bit security, because basically the in-bidding degree is 4 and 6, which is small. But in recursive slacks with two chains, we can create or we can construct these elliptic curves in a sequential fashion. So we start by finding the first, so the inner elliptic curve, which has to be pairing friendly, R minus one to be highly to adequate. Also Q minus one, the base field characteristic minus one, because this base field characteristic will be the subgroup order of the next curve. So the next curve should be pairing friendly and should have a subgroup order precisely equal to the base field of the previous one. So we know new methods from the literature in order to find a pairing friendly elliptic curve with precisely, with a precise subgroup order, so for example the Cook-Spinch method. So in order to find a pairing friendly elliptic curve, we need the base field to be a prime or a prime power, the Frobenius trace to be a relatively prime to Q, so in order to allow super singular elliptic curves in this case, the subgroup order to be prime to divide Q plus one minus T. So this is the order of the curve and R divides Q to the K minus one, so this is the in-bidding degree, and the complex multiplication equation should be satisfied for not too big discriminant in order to find the coefficients of the curve. So here we just need to fix R, so first. So the Cook-Spinch method is basically just relies on the observation that T minus one is equal to Q modulo R, so we just need to find a generator of Z out of RZ and to raise it to R minus one out of Q, so that it is a kth root of unity. So there is like the translation, I just want to send this to this algorithm to the polynomial domain, so which is called, so it is due to Bresing-Weng and independently also to Barrett-Tolien and Scott, and the ratio of the sizes of the base field and the subgroup order is at least two in Cook-Spinch, but in Bresing-Weng is smaller strictly than two because we reason about degrees of polynomials. And also the polynomials here are expressed, so the parameters of the curves are expressed as polynomials, which help us have faster implementations. So there are a long line of research in order to optimize pairing implementations when parameters are given in polynomials. But the problem we have here, so in Bresing-Weng method we just look for our polynomial R of X, but in our case the polynomial R of X is already fixed because it is the polynomial P of X of the previous curve, of the inner curve, so we do not have any flexibility here. And in all the families we've looked at, so Barrett-Tolien, Scott, or Barrett-Tolien or even KSS families, the resulting polynomial Q of X, so the base field of the outer curve is never irreducible, which means that we can never, it can never output polynomials. So we're obliged to lift the polynomial parameters of the curves and here basically the formula stress and the complex multiplication equations with respect to this R in order to make Q an irreducible polynomial that satisfies the Buniekowski conjecture, but we can, so this polynomial can output primes. So we've in mind two applications which are two kind of snags, one is growth 16 and one I'm calling here is universal KZG snags. So universal snags are instantiated in the PIOP model with a polynomial commitment scheme and the polynomial commitment scheme here I'm taking the KZG polynomial scheme, which relies on pairings. So we have the same mismatch arithmetic than in growth 16, but look at what we want. So we want 128-bit security for both. We want the curve to be curves, so the first one and the second one to be pairing friendly, but here we're looking at the snags here, so the first one. And we want efficient, so for growth 16 we want efficient arithmetic over G1, G2, GT, so all the three groups, and the pairing. But for universal KZG snags, such as if you want, if you know Planck or Marlin or Sonic, we do not need G2 arithmetic and we do not need GT arithmetic. We just need efficient G1 arithmetic and efficient pairings. So we look for two families of elliptic curves for which we have these and we need p-1 and r-1, both to be divisible by a high power of two. So we looked at families from Barretto-Lean-Scott's family of curves of MPD degrees 12 and 24 and the kangaroo you can see that it needs to to satisfy is just the seed of the curve. So the value on which the polynomials are evaluated is a kangaroo to one more three times two to the L and L here is your input. It's just the power of two you need to divide both p-1 and r-1. But most interestingly is the second curve so the slack one. So we need it to be 128 bit secure, pairing friendly, efficient arithmetic for all the curves and the pairings and r to be equal to p. So we looked at Blazing-Wang families and Cox-Pinch families and we have some result that shows that you can have at most K equal to six so the MPD degree equal to six and so we arrived the formulas for arithmetic over the three groups and the novel pairing computations for this case just in terms of the seed X and the lifting cofactors HD and HY. So wherever the curve you start with the outer curve will always have the same formulas in terms of these parameters which gives us a family of two chains in this sense. So we looked also at Cox-Pinch curve of high MPD degrees so 8 and 12 for more conservative security. So we shortlist a bunch of curves of two chains that we spent to some form these families and so for Gorsuch we took so our method rediscovers some old curves proposed in the literature so namely BLS-12377 and BW-6761 and for universal KZG so we samples new curves based on the BLS-24 families and so the BW-6. So we showed that BW-6 is always faster than Cox-Pinch 8 or Cox-Pinch 12. So here I give the example of Gorsuch 16 and universal KZGs are one of the versions of Planck. So we see that the perver only so the computation of the perver only takes place in G1 and the for Gorsuch 16 takes place also in G2. So the FV program which is the program that verifies the old slag which basically verifies the parent computation so slag so reason about arithmetic circuit so the number of gates if we want to translate or to port a state-of-the-art implementation of BLS-12 curves into an arithmetic circuit it results in 80,000 constraints or 80,000 gates multiplication gates and we were able to reduce it to 19,000 and here are some benchmarks so for the shortlisted curves with respect to the algorithm we can just set up both and verify. So I don't think, I don't know if I have a connection here. So no, it's not shut. So this is a playground so we use the Gnarc ecosystem so an ecosystem where it can go for smart curves so it's already implemented Gorsuch 16 and then Planck and we implemented all the curves we shortlisted into this ecosystem and here there is a playground that creates a smart proof in the browser, so in WebAssembly so I have examples for so you can look at it on your browser so it is play.gnarc.io so I have one of the examples to create proof of proofs and basically you can create a proof on the browser and you can check the number of constraints and it prints all the so the arithmetic circuit in order to verify a pair. So yeah, so that's it so the pairing is, so the paper is on a print the implementations are open sourced under MIT license so it is written in Go we have also implementation in StageMath and Magma in order to verify the formulas we propose in the paper so which are basically this novel pairing computation some tricks for subgroup membership on all the groups and there is a follow-up work with Aurora and Igor Ania which is a survey of elliptic curves for proof systems and that is for me thank you Do we have any questions? I've got a question so you've got two elliptic curves that kind of relate to each other have you thought and you've got a lot of constraints in the system to make a match up so have you sort of actually making one like a curve of genus 2 and then using a pairing on a curve of genus 2 because that's going to have a smaller field it might be a bit more freedom I haven't looked at curves of genus 2 so the pairings on curves on genus 2 are efficient enough? Very nice I thought of the idea down there I have no idea because I will have the idea that the pairings is needed for the verification part which should be succinct otherwise It might give you more freedom Any other questions? Oh yeah, can you? I'll run down, hold on Hi, thanks for the talk You mentioned proof systems like Planck which have high touristy and lots of routes of unity How much easier does it get to come up with cycles and stuff? Would you had to do so much work if you didn't need all these routes of unity? So cycles if you do not need those of unity they are trivial to find from complex multiplication theory so if you do not no, I'm sorry if you need pairings then the only cycles we know about are MNT fund and MNT cycles so it's the same problem so maybe it will be just the size so for example in Nina protocol it's just 700 something bits and for 128 bits of security you need more than this you need a thousand of bits so it will be always the same problem if you need pairing friendliness so for example if you use a halo where it uses a polynomial that doesn't need pairings then cycles are easy to find Okay, no more questions we'll start the speaker again Thank you