 Hi, my name is Matteo Campanelli, and I'm going to talk about Eclipse. Eclipse is a better committed-approved snark with the Universal SRS. It's actually a family of committed-approved snarks. And this is a joint work with other researchers from all those universities, Concordium and Indian Institute of Science. Our setting can be split in three parts. So we care about succinct interactive zero-knowledge snarks. I'll tell you more about that. We want commit-improve clearly. I'll tell you more about that too. And we care about the setting where we have a universal trust set up of linear size. Now, succinct interactive zero-knowledge consists of the following setting. Imagine you have a relation R with a public input X and a witness W. For example, W could be a signature or which you want to prove knowledge with respect to a certain public statement. Then the prover can provide a very succinct certificate Pi. They can be verified by a verifier using X as a simple, using the following syntax. We call this a snark, if it's of knowledge. Now, this setting, we care about snarks that are zero-knowledge, is this standard zero-knowledge setting. So in the interactive case, Pi and V are two parties that interact. And at the end, V commits that some W satisfies certain properties known. Now, we're going to care about a more specific setting, what I'm calling commit-improve or CP zero-knowledge, which is when we trust data, we trust that Pi is knowledge of some data that can be pointed to. In particular, what Pi is going to do is going to commit here represented with an envelope to a witness W. It's going to be out there and V can have some guarantees about what properties holds for W. And so notice in particular that what we're proving is both that certain property holds. So these are, but also that the envelope opens to a witness W. So we prove the relation in this comment. Now, whether we care about this setting, there's many, many different scenarios. Anywhere we care about compression and fingerprinting. Imagine you have a hospital holding sensitive health data and want to train public machine learning model. So what's going to happen, what could happen possibly is that the data could be committed in a very succinct way. This commitment is public, it's authenticated by the government and such. And then we can publicly prove that a certain training procedure was executed on them. Other settings will commit ahead of time, which here, with this name, I'm calling any setting where we commit to a bunch of data, for example, my credentials, some data about me, my credit history, my passport and so on. And then later, even when after I've committed this, I can prove things about. And then we also know that CP commit and prove can be useful to obtain very efficient composition of proofs when we have proof system with different strands. Okay, so these settings, settings translate to your application, so anonymous credentials, blockchains with privacy properties. And then in general, anywhere we need data to be referenced in a certain manner in particular privately. So just going back to the syntax of SNARX versus CP SNARX to understand the difference. There's not really any difference here in the SNARX setting, we're proving relation R and in the CP SNARK, we're proving relation R and the consistency between W and certain public commitments. Here we have L commitments and are representing with this dotted, sorry, dashed lines, the open relation. So I say there's really no difference, but what do we care about the setting? Well, the reason is that there are some efficiency advantages. Efficiency advantages and interoperability properties we want to strive for. In particular, we want this augmented relation, this R plus opening to be efficiently provable and verifiable. We don't want these commitments to be interoperable and standard as possible. We want them to be interoperable among proof systems. And standard is in, there should be Parisian commitment with classic curves or Merkel trees and so on. There are unsatisfactory solutions, for example, that one can straightforwardly come up with. For example, use Merkel tree or Parisian inside the relation R and then open that in the circuit. This is the standard property, but it can be expensive. You need to do all this in the encoding of the relation. There are lots of tricks that the community came up with. And one of the most famous ones is the one deployed in C-Cache with the job job curve. There's Coco, backstop for bullet proofs. And these tend to be more efficient, but they're also curve dependent or they're dependent on different settings. We care about having this efficiency, but also in generality of sort. Now, before the last component of our setting is trust models. Real quick, we know that we always have some type of setup to achieve and track zero knowledge. Now, in the best possible case, this is transparent. We can sample a uniform string and this could work for that, especially no trusted setup. And then we have setting where this string is structured and it's dependent on the relation. And then we have settings where this string depends only on some type of bound on the size of the relation. And then can be usually specialized in deterministically depending on the relation. And this is the setting we're going to care about. Often this property is also paired with updateability, which is very useful. We're now ready to set our results. So in Eclipse, we provide new ways to construct efficient CPSenarchs with universal SRS. And our results are as generic as possible. We'll see a little bit more about them, in particular, breaking them down. We have a general compiler into CPSenarchs with universal SRS of linear size. So take your favorite snark and snark with the SRS and you can compile it into a CPSenarch. And now here I'm saying take your favorite snark and compile it. But really what I mean is take a snark in information threading form of sort. We're going to talk about that later. And you can convert it into a CPSenarch. Then we show how to concretely apply this compiler to three very efficient and popular systems. So they're Marlin, Plunk, and Sonic. And in particular, the type of commitment that we managed to obtain and managed to support is a person commitment. And we managed to do that. Importantly, because we care about efficiency in practice, we managed to do that with a small overhead. Concretely, overhead is this. So here I'm comparing Eclipse to other works in generic CPSenarchs with universal SRS and Eclipse in the first row. Other results, other works we can compare it to naturally are the Lunar paper and the LEGO snark paper, which is LEGO UAC. You can see how Eclipse obtains sublinear for size. Here L is the number of commitments we're committing to, and D is the size of the opening of each of the commitments. And when I say sublinear size, these rows refer to the applications of these pro-systems to constant, of the Eclipse compiler, the Lunar compiler, to constant-size-proof systems. And you can also see how we improve a Lunar improved size, and we obtain a trade-off in verification time. In particular, for example, Lunar achieves better verification time in case D can be a burden for the verifier. Now, I'm going to give a little bit more background about our techniques. And before that, I'm going to give you more background about how we construct the snarks with the universal SRS in general. And the way we construct them usually is from basically a recipe already mentioned. We use a compiler from an idealized information-theoretic object. So we take this information-theoretic object. If you're familiar with that, PCPs, HPs of Geo-Electro-Graphic, we take a cryptographic object, say, an electrical commitment, a polynomial commitment, and another collision-resistant dashboard, and we compile them into an object we can actually use as a snark. So what we obtain usually with examples of what we can obtain with these compilers are these constructions already mentioned, Sonic, Mark, and Planck. Here, I'm just showing a table to show a little bit what type of efficiency they achieve. It's not super important right now just to give an idea. You can see proof is constant here, and the columns I blocked. They're not for censorship, but they're just because they're not relevant. So we can achieve these proof systems through these compilers, and we're going to tweak this recipe, the recipe by which we shift them a little bit. The recipe is as follows. We take an algebraic holographic proof, which is-it doesn't matter what it is, exactly I'm going to give some intuition about it, but it's our idealized protocol. And you can think of it as an interactive idealized protocol where the prover holds polynomial encodings to the witness. So it takes the witness, it encodes that in a bunch of polynomials, and then it gives oracle access to the verifier to the evaluations of these polynomials. And the verifier can query the prover on these provers-the polynomial is provided by a prover in different points. More pictorially, you have your prover on the left, the prover here says PHP, but PHP is a different idealized protocol that generalizes AHP. But you can think of that as algebraic holographic proof. And the prover puts in the sky these polynomials, and the verifier sends challenges, sets. There are a few details I'm going to write here, but this is the main idea. And Q is a set of queries. The verifier is going to ask. And each query is going to look like that. So each query can be, for example, p1 x star equals t star. Prove it to me. In this idealized protocol, the verifier just receives an answer to this and you can check it. But in the real world, this doesn't happen. Also, one thing I ignore here, this is going to go up later. This is an interactive world, but then it's going to be de-interactiveized. It's going to be made known interactive for the future mirror. Okay, so if you have an AHP, how do you compile that to an SRS? It's not to an SRS-NARC. And what you need here is polynomial commitment. This is the main tool in some other compilers such as the Marlene Dark Lunar Plum Compilers. And by polynomial commitment, we mean a machinery that takes a polynomial and compresses it into a very short digest and allows to prove efficiently, assasinly, into your knowledge, and it will show the polynomial. Basically, the queries I mentioned earlier. But also, there are some other caveats. So for example, they should allow to prove some guarantees about the degree of the polynomial. We can ignore these details for this presentation. On popular polynomial commitment, we use in practice the KZG commitment, which looks roughly like that. Now, I'm going to introduce some notation. So I'm going to talk about commitments of different types with different geometric shapes. Earlier in the relation, I used these little squares, and now I'm going to introduce a circle notation to denote commitments to these encodings we're using in the idealized object. So the squares are the ones that are input to the relation, and the circles are the ones we use in the protocol. Okay, so I mentioned the protocol. What is this protocol? What is this recipe? We have our idealized object and want to convert it into a SRS-NARC. We have our polynomial commitment, and we use it to make each of these encodings P1, PN of the witness. Then the verifier, the AHP verifier, is going to make some queries. And we can use the polynomial commitment machinery to prove these queries are satisfied. Nothing super surprising at the high level. There's a lot of important details to take care of, which I'm going to ignore here. Now, this is the recipe for SNARCs in general. We care about CP SNARCs. Let's see what we should do for it. So one more thing to mention is Fisher-Mir, and why is the SRS universal before we move to CP SNARCs? And the reason why the structural reference string ends up being universal, so it's valid for any relation of a certain bound, is because the SNARC setup itself is the polynomial commitment setup, which itself just depends on the degree of the polynomial, and the polynomial degree is related to the size of the relation. So next, let's look at the actual recipe for CP SNARCs. Of course, we need to change our syntax a little bit here. So I'm introducing here the commitment C1 to per relation and its opening of C. I'm going to assume just for the time being that there's only one commitment or dog in the general case that are L. So we know by the earlier recipe that we can prove this dash part of the relation on the top left. So the actual relation, but what's left is to prove the connection between whatever the proven knows and these commitments that are also the public inputs to be verified. So we need some additional piece, intuitively. And remember, these C1, CN are here in the circles. They represent commitments to some encoding of the polynomial of the witness. So what we can do is we can show that they're linked to the witness, whatever string the square commitments are committed to. So intuitively, we can add the proof, this pie link over here, an additional object that can link the committed encodings, circles C1, circles CN to whatever is in the square C. So this linking proof, this is basically a specialized NARC, proofs linking for knowledge of certain W such that the square C opens to some parts of W. It's not going to be the whole witness. CIs opens to the polynomials encoding this witness and everything is consistent and nice. So this is the object we need, but of course it's not that simple. I mean, sure, this is what we need, but a few challenges to solve and this is what we do in Eclipse. The challenge one is we don't want to depend on the whole witness when we do this. So the commitment square C may only be part of the whole witness we are using in our relation. Are we paying for all of it when we are doing this proof? Hopefully not. So in order not to pay for it, we show that we can decompose each of these encodings in an additive manner in Marlin Planck-Sonic, the constructions we care about. And we define an appropriate abstraction that helps us doing this generically. And there is an important sub-challenge here which is proving that whatever word decomposing doesn't overlap because a dishonest prover may not be doing this decomposition as we expect. And then the second challenge we saw is that we want to have actually a concrete proof system for this linkage. So it's a little bit like a chicken and egg problem. What proof system are we going to use for this? This is a snag, we're trying to build a snag. A CP snag, we need a CP snag for doing this, but we need a CP snag that's simpler. And what we use is intuitively sigma protocols to prove this relation. Because everything you need in each of these construction reduces to proving that a certain commitment C, the upper case here on the left here, that commits to the whole witness, is basically equal to the concatenation of the openings or all these C-hat eyes, which are commitments to parts of the witness. One way to do this is through sigma protocols. But then this requires, naively, of size of the witness, size of each of these witnesses times number of commitments. And then we can compress that through compressing my protocol techniques from math and my grammar 2020 to look at the next slide. Okay, and I want to just make a couple words on the work that's very close in nature to Eclipse, Lunar, they both follow a similar blueprint of recipe, but Lunar has a quite different frame-based protocol for linking. They do share some intuitions at some point, but there are some technical differences. And Lunar, for example, doesn't use any of the compressing my protocol tricks we use here. And indeed, it ends up requires to pay a communication complexity that's linear in the number of commitments. And they show different rate of efficiency, especially very far time as I saw before, and I'm going to show in the next slide. Also Lunar uses a more general formalization, this PHPA, and that mentioning polynomial or graphic proofs, I believe. But our work can be easily formalized in the same way as the framework. Okay, that leads us to the last slide of this presentation with a couple open questions. So, so far, you can see how Eclipse and Lunar have these trade-offs in efficiency, but what's left is no problem with something that's not just sublinear or logarithmic, but is actually a constant size. We get it. An intuitive how we need to explore. There is some type of recursion, but to do that efficiently, maybe we need more specialized tricks of that. It'd be nice to see a CPSnark with a general and modular CPSnark with such features. And then it'd be interesting to explore different techniques for this linking module we have. And, or finding other applications for the ones we have. Thank you so much. This is my presentation. If you have any questions feel free to write to me or any of my co-workers. Thanks.