 Hello, my name is Anais Gerol, and today I'd like to present to you Lunar, this is a toolbox for more efficient, universal, and updatable secrets and commit-improve extensions. This is joint work with Matteo Campanelli, Antonio Faonio, Dario Fiore, and Adrián Rodríguez. But first, let's explain what's a snark. It stands for succinct non-interactive arguments of knowledge, and the idea is that this is a tool that will allow you to convince someone of a statement in a very succinct manner. Okay? So, suppose, you know, suppose, alien sexists, and you want to convince someone about this claim, right? It's the one thing you cannot, of course, you can do if you have this all in. You can simply show this all in, right? And then this astronaut, he will be absolutely convinced about this, right? But what is the problem about this approach is, you know, perhaps you don't want to show the alien. Perhaps the alien is some sensitive information you don't want to filter. Well, then the kind of primitive that you want to use is a seronolite snark, okay? Here you only get to learn that the claim is true. You don't even have to show any very little piece of this alien to have someone convinced about the claim. But there's an issue that these primitives have been facing for some time, which is the setup. And this is a procedure whose goal is to create the keys that will be used to prove each relation. And this is executed by a third party. And I say this is a trusted setup because one needs to trust that this third party will be removing and deleting completely the randomness used to generate those keys. Otherwise, that third party could be computing proofs for four statements, which is something we really want to avoid. But luckily there's another type of setup, which is universal. And what we mean by that is that you only need to perform a one-time setup for any bounded relation, okay? So you can define some sizes, some bounds on the type of relation, and you can have a family of relations for which the same setup will be working just fine. And the very nice addition is updateability. So in this case, even if this setup is only run once for older relations in this box, you can have participants in this ceremony that will participate adding randomness. So as long as there is one of these entities that is honest and is not leaking this randomness, the randomness is preserved and then no one should be able to create fake proofs. Now let's look at the non-exhaustive timeline of these constructions. The first universal and updatable Seekiesnark appeared at crypto 18 and it had a quadratic size SRS. This is the size of the key that I was talking about. Then in CCS 19, two more candidates appeared and they were the first linear size SRS universal and updatable Seekiesnarks. Sonic had a constant size proof and a quasi-linear proof, whereas Lego UIC and Lego Snark had a polylogarithmic proof size and a linear proof. Some months later, Plunk and Marlene appeared and they were following the steps in Sonic. So they are also linear size SRS universal and updatable Seekiesnarks and they have constant size proof but shorter and quasi-linear proof but faster. And the way they obtained these constructions is by having an information theoretic object that is like an IOP object and it is combined with polynomial commitments. We will see how this works in a minute. And then in Lunar, what we are providing is a family of trade-offs of different linear size SRS universal and updatable Seekiesnarks. We are giving them more efficiency in the proof side and also the shorter proofs. And we are also giving efficient common and proof variants. So the way our compilation works is, well, you start with a more general IOP-like object that generalizes Plunks and Marlins and instead of having polynomial commitments, we have Seekiesnarks and gadgets in order to obtain our constructions. Next, I'd like to give some hints about how Plunk and Marlene work from a high level. So as I said, they both start from an information theoretic object. They are called idolized low-degree particles in Plunk or algebraic holographic proofs in Marlene and they are similar because they are both interactive oracle-proof flavored. So they run in rounds and in each of those rounds, the river sends some oracle polynomials and then the varifier answers with some randomness. So this object is then combined with polynomial commitments in order to produce those norcs. But this approach entails some problems and some limitations that we wanted to address in Lunar. So for instance, in Marlene, the way you would prove things like A times B equals C, where ABC are committed polynomials would be by performing some point evaluations. But the problem here is that this methodology requires sending one field element per each committed polynomial. So this has an impact on the proof length. Another limitation here regarding Plunk is that it lacks zero knowledge formalization within the abstraction. And for us, it was important to encompass these notions within our abstraction. And in general, this holds for both of them possible optimizations that we can do on the schemes deviate from the abstraction. Whereas in Lunar, we wanted to have all of these optimizations fully encompassed within our framework. Next, I'd like to explain you our information theoretic object that we call a polynomial holographic proof PHP. So those of you who are more familiar with ILDPs or HPs may find some similarities here. And this is because this notion tries to generalize Plunks and Marlins, yet including some additional features that make up PHP's a more interesting notion. So because we are building preprocessing snarks, we will have for efficiency reasons an offline phase that will be run by the indexer who will be receiving the relation. This is just public information. And we'll encode it as some polynomials to isolator on the very fire with havorical axis. So this is a deterministic algorithm that even the very fire could run by themselves in an offline manner. As I said, this is done for efficiency reasons. Then during the online phase between the prover and the very fire, this interaction flows very similarly to IOPs. So we need to run off interaction. The prover sends a series of polynomials to it again, the very fire will have oracle axis. Then the very fire will answer with some randomness that will be used by the prover to produce further polynomials in the coming rounds. So after these rounds are executed, the very fire needs to perform some checks and finally make a decision about whether to accept or not the prover's proof. So if we look more into the PHP verification procedure, there will be two types of checks involved. One of them is checking some bounds on the degree of the polynomials. This is done well for completeness and soundness of the protocol and also polynomial checks. And here we have been using Planck's equation identities and this together with our compilation technique allows us to have a shorter proof length. Also, as a side note, I wanted to say that for us it was very important to have a formalization, a fine-grained notion of zero-knowledge at the PHP level. So here I'm explaining bounded zero-knowledge. So this notion ensures that a PHP should still be zero-knowledge even after a bounded number of evaluations are filtered of the prover's oracle polynomials. So how is this possible? Well, the intuition behind this notion is that we will have to increase the degree of the oracle polynomials artificially. So just here, there's an example. So for instance, if we had an unbounded number of queries and still the PHP would remain zero knowledge, then it means that oracle polynomial is not filtering any information about the witness at all. So if it was related to the witness instead, this bounded number of evaluations should be smaller. The next thing that I'd like to talk about are CB Snarks. Remember our friend, this alien here? So in CB Snarks, we are introducing the notion of commitment. So a commitment, you can see it as an envelope and you can commit to some information by putting that information inside that envelope. So relations in commit and prove Snarks look as follows. They essentially have one additional input, this envelope, and relations in CB Snarks hold if two things happen. One thing the normal relation holds, and by opening this envelope, you will find the witness. So it's important to note here that this scenario is very well suited for several reasons. So first of all, this gives us the capability to have more modular types of proofs, because having this envelope provides you some interoperability between different gadgets. And at the end, it also provides some efficiency, because you can have gadgets that are very efficient for very specific relations, and you can link them together thanks to this envelope that opens to the same witness. And in our compiler, we are taking advantage of precisely these properties. Now sharing with you one of our compilers, it is the Snark compiler, because we have a second one to obtain commit and prove variants of our family of Snarks. But in this case, we will be looking at how to build our updatable and universal Snarks. So if you remember from the beginning of the slides, that used to be a one-time setup that was run for only once for no matter how many relations we will be proving, as long as they fit within some bounds, remember that box. So that box is precisely this big N, this is the bound, and then this algorithm will output this linear size SRS. So how this is done? Well, it first runs the setup of the commitment scheme with a certain degree bound. So this degree bound will determine the maximum degree of the polynomials that you can commit to. And then this produces a certain key for making these commitments. So then you run these key generation algorithms of two CP Snarks, CPPHP and CPOPENING. So these are two main ingredients of our compiler, one of them will prove the relation of a PHP and the other one proves the opening of a committed polynomial. And then on input this commitment key, it will output some evaluation keys and verification keys, which are essentially what's inside this SRS. But why is this scheme updatable? Well, because this commitment key only contains monomials in the exponent, so anyone can come and update the whole randomness of the setup by adding their own. Now moving on to the derivation algorithm, this is a deterministic algorithm that basically takes the input, the general SRS and the relation that we are going to prove, and it outputs a specific specialized SRS for that particular relation. And how it is done? Well, first we commit to the polynomials that are output by the indexer of the PHP. Remember that those were an encoding of the relation and the relation is public information. And then the evaluation key is updated with the actual polynomials, whereas the verification key is updated with these commitments to those polynomials. So it's important to note here that we are going to work with type-based commitment schemes, which means that depending on the type of the input that the commitment is receiving, the commitment will produce a different type of properties. So the relation type of properties means that since we're committing some public information, we don't need the hiding property. And then the somewhat hiding type of commitment that we introduce in Lunar is the type of commitments that we will be using for those polynomials that the prover will be sending. And what does it mean is that, well, these type of commitments leak at most one evaluation at a random point. Okay, so what this means is that this type of commitments can be deterministic. And this is very important for efficiency reasons, right? So moving on, if we go to the prover now, we will see that for each of the rounds, the prover will have to commit to the polynomials, the oracle polynomials, sent by the PHP prover at that round. And together with that, it will provide a proof of an opening of those polynomials, meaning that it knows the content of those envelopes, right? So the final proof will be formed by all those commitments, possible messages, all those opening proofs. And together with proof that the PHP verifier would be accepting. The way to make this more interactive is by running the fiascia nervistic. Now, for the verifier, it will receive as input this proof generated by the prover and will output either yes or no depending on the checks. So for the actual checks of the PHP, it will run the verification algorithm of these CVs, receiving as input some degrees, some equations, and the commitment to all of the oracle polynomials, including those from the indexer and those from the prover. Some of them are committed in the relation type, some others in the somewhat hiding type. And also, of course, this proof of the PHP. And then the verifier will run this verification algorithm inside the CVsnack for the opening, together with all of the oracles sent by the prover, committed, and the proofs of opening. So the result of all of these checks should give the verifier either an accept or a reject. Now let's dive into the details of the blocks that make up our compiler. So these are CVsnack for very specific relations that we can combine together. Remember here, the modularity and interoperability of CVsnack. So there are two main ingredients here, as you've probably seen. We have one CVsnack for proving the lots of an opening of a commitment polynomial. And then we have another one for proving the PHP relation. So if you can remember now where the steps in the verification process of a PHP, you'll then understand that this one at the same time is composed by two other CVsnack. We have one CVsnack for proving polynomial equations for committed polynomials, and another one for proving degree bounds for committed polynomials as well. And we have a number of instantiations of all of these gadgets. So for the opening of a relation, if you're engaging a model, just as in modeling a block, you can have an empty proof for proving the number of the opening. And here in this work, we introduce a batting technique to prove the opening of L-committed polynomials using only one repellent in the PK assumption. Now moving on to polynomial equations, suppose you have something like this, then using this principle, what we could do is just take a valuation on a random point of these polynomials and then having a proof of evaluation of this A polynomial. Then you could do that once again for this polynomial B. And then what you end up with is just a linear equation for which you can have a proof of evaluation. But now it's important to note here that this gadget is leaking some evaluations of the committed polynomials. And these committed polynomials will be oracle polynomials and very much likely related to the witness somehow. So because of this leakage, we will have to take this into account in order to design which is the appropriate additional degree that we will need to provide to our oracle polynomials. We will see how this connects in a minute. And also for polynomial equations, now when you only have quadratic equations, meaning they have this shape or a linear combination of this shape, what you can end up with is just an empty proof as long as one of those polynomials that are being multiplied is committed in G2. So the way we are using this approach in Lunar is sort of equations where one of the terms is always a relation polynomial. So we can decide in the derivation algorithm to commit to relation type of commitments in the G2 group. So why would this be empty? Well, because this would only cost one pairing to the verifier and no extra information would be needed. We have the gadgets for the checking the degree bound. So depending on the group of the commitments, you can have one or the other. And because of the way they work by committing to the shifted polynomial, this ends up being a polynomial check. And as long as these equations are quadratic, you can also use this quadratic equation gadget and then have empty proofs also for the degree checks. Now, let's take a look at how all of these gadgets connect with each other. So at this point, I really encourage you to pause the video for just a few seconds to really understand how these building blocks can connect to each other, because the goal of this picture is to really get to understand what are the possible combinations that lead to all of the members of the family of trade-offs that we have for all of our SNARCs in the lunar paper. So just to give you an example, I am showing in the following slide how to instantiate the three of our constructions that we promote the most throughout our document, which are Lunar Light, Lunar One CS Fast and Short, and Lunar One CS Short PK. Lunar One CS really works with the R1 CS constraint system, whereas in Lunar Light, we are introducing a more efficient type of constraint system that we call R1 CS Light that only contains two matrices, left and right, instead of the usual left-right output in R1 CS. So this picture is just for the interested viewer. I wanted to illustrate how all these zero-knowledge notions connect in Lunar. So remember we have these B-leaky zero-knowledge CP SNARCs. Think of this CP egg that was filtering some evaluations. Also, we had these somewhat hiding commitments where it was allowed to be deterministic and thus filtering at most one evaluation at a random point. And this together with a B plus one bounded zero-knowledge PHP in our compiler will give us fully zero-knowledge SNARCs. Next, in this table, I just wanted to show an overview of all the efficiency measures of the state of the art, one of our constructions, Lunar Light, but we have plenty of others, as I said, and also one very recent universal data about SNARC called Basilisk that was presented at crypto this year that was techniques stemmed from some techniques that we introduced in Lunar. So just to summarize some of the reasons of these efficiency improvements is the fact that we are using these somewhat hiding commitments. Also, we didn't talk about this sparse masking method for polynomials. Also, the compilation with efficient CP SNARCs instead of just polynomial commitments. And a new constraint system that only uses two matrices left and right called R1 CS Light. So that was all. I hope you liked it. And honestly, thank you for watching and see you next time. Bye-bye.