 Hello. Today I'll tell you about proof-carrying data without succinct arguments. My name is Benning Pyns and this is joint work with Alessandro Kese, Petrusz-Michel, William Lin, and Nick Spooner. So consider doing a long t-step computation. So the computation evolves in the following way. We go from step zi to step zi plus one, non-deterministically by applying a transition function f to zi and an optional witness wi. And say we want to outsource this computation to an untrusted server and we want that the server provides a proof to us that it did the computation correctly. Well, there's multiple ways to do this. One is we ask the server to just do the computation and afterwards provide one monolithic proof that it did the entire computation correctly. This works, but it has a few issues, namely that it would require the prover to store all of the intermediate states that it has when doing the computation in its memory in order to perform the proof. And the second issue is that if we did this for t-steps and then say we evolve the computation for one more step, well then this would require recomputing the entire proof. The second option resolves all of these issues and it's called incrementally verifiable computation or IVC for short. And the idea here is to interleave the evaluation with the computation of the proof. So what we'll do is at every step that we still have zi and wi, but we'll also have a proof pi i which asserts that all of the previous computations, so the first i-steps of the computation were done correctly. And then the IVC prover, pf here, can advance the computation, so compute zi plus one and additionally compute the next proof, pi i plus one, which now says that the computation was correct for the first i plus one step. And IVC is really for computations of a path grasp, but this has been generalized to more generic DAGs and we call this proof carrying data. And IVC and PCD, they have tons of applications. Some of them are around long everlasting computations such as succinct block chains or verifiable lay functions. There's also others that are more about multiple provers working together to combine to create one proof together, so zk cluster computing or verifiable image editing. So the interesting question though is how do we actually construct IVC? It's clearly a very powerful primitive and has a lot of applications. Well it turns out historically the way to construct it was from another very powerful primitive, namely snarks succinct non-interactive arguments of knowledge. And historically it was shown that you can construct IVC from snarks that have really efficient succincts or polylogarithmic verification time. And this can be efficiently realized using preprocessing snarks and cycles of elliptic curves. Then recently there have been more efforts in order to relax the requirement on the snark. So for example, cost 20 showed that it actually suffices to have a snark that has just sub-linear verification time. So for example, square root verification time. And then most recently BCMS 20 showed that it is actually okay to have a snark that does not have sub-linear verification time. But instead it has something called an accumulation scheme, a sub-linear accumulation scheme associated with it. And this builds on ideas originally proposed in Halo. But all of this leads to really naturally an important question, which is do we even require snarks in order to create IVC? Do we require the succinctness of the proofs, the proofs are being short in order to create IVC? And in this work we'll show that the answer is actually no, we can construct IVC from something that is qualitatively simpler than a snark. So more formally we say, we show, we introduce something called a split accumulation scheme. And we'll show that given a snark, so this is a non-interactive argument of knowledge, with such a split accumulation scheme, we can build IVC and PCD from it. And it's a snark, it's not a snark because there's no succinctness requirement on the snark itself. There's a small asterisk with it that we do require that the proofs of the accumulation scheme, if the accumulation scheme involves some proofs, then we require that those are succinct, but not the snark itself. And this isn't just sort of using the old tricks, and this is actually something new, and we'll show this in theorem two where we say there exists a snark that has really exciting properties, properties that we hadn't been able to achieve from a snark. So this snark is secure in the random orco model under just the discrete logarithm assumption, and it has a split accumulation scheme. And the accumulation verifier is really efficient, it only does a constant number of operations. And if we compare this to prior work, then the best we could do here for the accumulation verifier is a logarithmic number of operations. There's a small gap between these two theorems. So theorem one requires a snark and an accumulation scheme that is secure in the standard model, whereas this theorem two is in the random orco model, and we can prove it to be secure in the random orco model. So we need to do a small heuristic jump here between theorem two and theorem one, saying that our constructions are still secure if we replace the random orco with a secure cryptographic hash function. I also want to point out that split accumulation schemes are about accumulating verification, and they have nothing to do with set of chemo records. Our scheme has really interesting asymptotics. It has a very, very small recursive circuit, and it doesn't require a trusted setup. The setup is transparent. And additionally, all of these recursive circuits kind of constructions, they require cycles of curves. So we need to ellip the curves that are kind of cycles of each other in order to implement this efficiently. And historically, in the older construction, you needed cycles that are pairing both where both curves have a pairing or where there's some FFT friendliness. And this makes it actually very hard to find proper cycles with good properties. For us, it actually suffices to find any sort of cycle that has where we just believe that the discrete logarithm is secure in both of the groups or in all of the groups on the cycle. And this turns out is much easier to find than the other two. But the attractive asymptotics led us to the question of whether this is also completely efficient. And in order to test this, we implemented the accumulation scheme and the PCD construction in the artwork's ecosystem. So we added two libraries, ARC accumulation and ARC PCD, also implementing generic frameworks and some of the older schemes. And they are, of course, available open source and freely available and play into play nicely with all of the other great libraries in the artwork's ecosystem. We then measured the performance of our scheme. And you can see here at a very high level that our scheme does about five times better compared to the previous scheme. We measured this in terms of number of constraints in the recursive circuit. And this turns out to be the key performance metric. And the absolute numbers are already really good. We're about a 50,000 cycle gates. But, you know, there might be optimizations that you can apply, but they wouldn't, we assume that they wouldn't change the comparison because everything is implemented using the same library. So the optimizations which is move everything down. There's one small optimization that for the specific case of IVC, this is, we implemented it generically for PCD, but for the specific case of IVC, our scheme can do even better. We have a specialized construction that can do even better, but we did not implement it. So let's dive in or let's look at what this bit accumulation actually is and how we get PCD from it. But first, a small background on IVC. So in IVC, we have an IVC prover which performs a computation and so advances the computation from Z and W to Z prime. And it also takes as input the proof and advances it to a new proof pi prime. And it can do this over and over again. So you can feed the new state of the computation and the new proof into the IVC prover again. And the IVC verifier simply takes as input the current state of the computation and the proof at any point and either accept or reject. And we have adversarial completeness saying that if the verifier, if for any proof, even if it was adversarily created, an honest prover can advance the computation on it and proof of knowledge says that if we have a convincing prover, so if you can convince the verifier, then it is possible to extract the entire transcript of the computation from these valid proofs. A key efficiency requirement is that the size of the proof does not grow with any computation step. And this is important because it implies that the size of the proof is actually independent of the length of the computation. I also want to very quickly define NARCs. So we have NARCs and ZKNARCs and we define them for a circuit satisfiability. So we have a circuit that takes in a public input X and some private inputs W. And we say it accepts if the circuit evaluates to one on X comma W. And NARC is simply a protocol where the prover sends a proof that convinces the verifier that these private inputs exist. So the verifier does not have access to them. And it's a non-interactive protocol. So there's only a single message being sent from the prover and the verifier. And you can define completeness and proof of knowledge properties. So from the proof, you should be able to extract the witness. Additionally, if these proofs are sublinear, so they're really small, then we call this a snark. But they don't necessarily have to be. And if it's zero knowledge, then we can call this a ZKNARC or Nizake. Okay. So let's look at what atomic accumulation is. So this was something that was introduced in BCMS 20. And the idea here is that I can accumulate a bunch of predicate checks. So I have a set of FT inputs to a predicate. And I want to see whether the predicate evaluated on all of these predicate checks evaluates to one. And I do this by accumulating these checks. So we have some accumulation. We start with an empty accumulator state. And then we have a prover that keeps on adding things to the accumulator. So it keeps on adding these predicates to the accumulator. And the verifier, there's an accumulation verifier that can simply check whether the accumulation was done correctly. And then at the end, we have our final accumulator. And there exists a so-called decider that can check whether this final accumulator is valid. And what we would want as a property for this accumulation scheme is that if all of the verifiers accept, so the verifier accepts all of the accumulation set and the decider accepts, well, then we would want that this implies that this is equivalent to checking all of the predicates. And this makes sense, really, if the accumulation verifier is much more efficient than checking the predicate itself. Well, why is this a case? Well, it is the case because really then you have to do t-checks of the predicates here in the row below. And in the row above, you only have to do t-checks of the accumulation verifier. So if there's a gap here, well, then we're about t times faster than checking the predicate itself. Additionally, in order to prevent a trivial construction, we require that the accumulator does not grow with t. So you can't just simply append the predicate inputs to the accumulator, but this should be compressing. And BCMS-20 showed that you can construct IVC from the accumulation. And there's two things that I want to quickly point out here. I want to dive into the details. But what is the predicate? Well, the predicate is simply snark verification. And what we care about really here in this construction, what is going to be the key performance bottleneck is going to be the size of R. This is this recursive circuit over which you create a proof over. And it mainly consists of the accumulation verifier. So this is good because it doesn't actually consist of the snark verifier, because we know that the accumulation verifier, the whole idea is that it's more efficient than snark verifier. But the accumulation verifier has to read the entire proof, the IVC proof, and the old accumulators. So both of these feed into this accumulation verifier. So clearly this implies that if the accumulation verifier is sublinear, well, then the proof must be sublinear. So we actually do require a snark sear. So to get around this, we introduce a new tool, which is called split accumulation. And in split accumulation, the idea is that we perform split accumulation not for predicates. And we don't have predicate inputs, but we split them into two parts, an input instance and an input witness. And then we have a relation over this. And we say that there exists basically one to show that there exists Qwi, such that all of the phi Qxi comma Qwi evaluate to one. So now let's try to accumulate this. So again, we start with an accumulator, and we have an accumulation prover that keeps on adding things to the accumulator. But now the accumulation verifier is a little bit different in that it doesn't read the entire predicate input or the relation input. It just gets to see this instance here. So this input instance Qxi. And also we can split the accumulator in a very similar way into an accumulator instance and an accumulator witness. And the accumulation verified only needs to see the input and the instance. Additionally, the prover can provide a short proof. So this proof needs to be succinct to the accumulation verifier. So what we've saved here, and then at the end, we'll have a decider that still reads the entire accumulator. And we have a similar property, which is that we want, if all of the accumulation verifiers accept and the decider accept, this should imply that all of the relations exist. So the key difference here is that the prover can provide that we can split the accumulator and the queries, but now the prover can provide an additional proof to aid the verifier. But now the accumulation verifier could actually be sublinear in both the size of the accumulator and the size of the queries. And we still kind of get the same efficiency gain if this accumulation verifier now is sublinear in the size of the predicate. So how does this interact with IVC? Can we still construct IVC from it? Yes, the answer is yes. So now what we have here is basically our recursive circuit. Again, I won't dive into all of the details, but our recursive circuit now consists of the accumulation verifier. And again, we now set as our predicate to be not there's no snark anymore, but the nark verification where we split the proof into two parts, a short part and a long part. And basically the accumulation verifier only needs to read the short part of the proof and also the short part of the accumulator. So again, the accumulator also split into two halves, a short and a long part, and the proof split into a short and a long part. And the accumulation verifier, the prover gets to see everything, but the accumulation verifier only has access to the short part. So it can be much more efficient. And the soundness requirement really relies on the nark and the accumulations scheme having strong knowledge properties. So we need to be able to extract the entire transcript in the IVC. And in order to do that, we call the extractors of the nark and we call the extractor of the accumulations. And the efficiency of really is the size of r. And this is independent now of pi w and pi aw. So theorem one says to formalize this that this construction is actually secure. So given a nark and a split the accumulation scheme, we get IVC and PCD for and also some really nice properties persist. So if the nark and the accumulation scheme are zero knowledge and so is the PCD and if they're close quantum secure, then so is the PCD scheme as well. And this is the first construction of IVC that does not rely on snarks. It only relies on non sync narks. So that's really exciting. And now since we had this theorem, we went to look for a nark for R1CS that has a split accumulation scheme and has some exciting properties. So what is R1CS? Well, R1CS is an encoding of NP that is fairly simple but also widely used and it exists a free matrices A, B and C and a public vector X and the rank one constraint system satisfied if they exist the secret vector W such that R A times Z where Z is x concatenated with W times BZ equals CZ and times here is the element wise product. So and you can very easily transform an arithmetic circuit into such an R1CS constraint system and because of this nice balance between structure and exclusivity, this is actually extremely widely used. Also for the rest of the talk, we'll kind of ignore X which of course in reality you can do but it makes the presentation slightly simpler. So now we constructed a nark for R1CS and what is the simplest possible nark for R1CS? Well in general for any NP problem the simplest possible nark is just simply sending the witness and this is almost our nark. We just simply send Z the witness and but we sent a few things more actually. What we do send is that the commitments to AZ, BZ and CZ and the verifier simply checks that AZ times BZ is equal to CZ and that these commitments are correct. Additionally we have a linearly so the commitment itself is a linearly homomorphic commitment and so this is what we'll use later on. We'll use that the commitment scheme itself is homomorphic so we can just instantiate it with a Patterson commitment scheme which is secure under the discrete lockers assumption so this is where the only place really where the security assumption comes into play. And the reason for doing this is yeah the well the commitments allow us to accumulate the proof so we'll see that the commitments are the short part of the proof and see here this will be the long part of the proof. So let's look at our split accumulation scheme and it works in the following way. Well we start with exactly as I said the proof having being split into short parts CACB, CZ and a long part which is just Z and then we have our accumulator which looks very similar to our proofs. It just has one additional element C0 here or a C-circ and basically it turns out that this is not quite the accumulator is not quite an R1 CS instant so CACB is not quite equal to CZ but instead it is equal to whatever is committed to in C0. So this is the accumulator and then in order to combine these we'll simply take basically a random linear combination so if we take a random scalar field element that will be then generated by a random oracle in the actual construction then this gives us our new accumulator well plus some cross terms that will need to be able to it will need to be correct we need to correct for but this is possible by just having the prover send this proof element here and then we can correct for these cross terms. So we'll see that the accumulation proof is also extremely short and in the end this gives us a really nice construction that has some really interesting property namely the accumulation verify will only perform three scalar multiplications and also what is really interesting is that this doesn't require any FFTs or PCPs or or any other fancy machinery it really just relies on the dispute log assumption and a very similar homomorphism of our commitment scheme and yet it allows us to accumulate a proof with the previous accumulator and this is given our very powerful theorem one this is all we need in order to construct IVC from this and this is really where the power comes in you know now from something really simple we can construct something really really powerful. So now let me close with some takeaways and open problems and so as I already said is IVC is a very useful primitive and which we've constructed from us can now be constructed from a very simple ingredient NARC's with accumulation and we've constructed a very efficient NARC with accumulation and this is also very exciting because it's already being deployed in practice so there's a number of projects using accumulation based IVC so there's a lot of you know interesting open problems and details to work out and it really seems like a great time to work on this area and there's also a couple really interesting both theoretical and practical problems one of them is that we still use we have this heuristic gap where we use the random oracle or proof things in the random oracle model but really need them in the standard model so this uses the question is could we maybe really move the the use of the random oracle maybe with collision intractable hatchets or some other techniques and additionally the other question is if we can construct a post quantum secure accumulation schemes maybe using lattices but then there's of course interesting questions of how we deal with errors how do these errors accumulate and so on and so forth so this is the talk and I hope you come to the live session but you can also find the paper online and yeah thank you very much