zkStudyClub: Pratyush Mishra and Nick Spooner discuss recent work on accumulation schemes

Transcript

record to this computer so i think we're started very cool welcome everybody to the study club to the zk study club um for this edition or this episode we're going to have pratush mishra and nick spooner sadly benedict wasn't able to make it he was supposed to be on this as well but they're going to be discussing their recent work on accumulation schemes and how these can be used to construct more efficient recursive snarks but before we kick off i want to very quickly remind everyone in the group that the zk summit is coming up and if you're thinking of speaking or if you just want to give us some feedback i'm going to add the link to the form in the chat and i'll also add it to anyone watching after

in the show notes of the youtube video so please do submit your talk soon because we're going to be doing the programming in the next like couple days um yeah so nick is going to start off nick feel free to take it away thanks um yeah so i'm gonna be talking about uh a paper that i wrote with uh benedict uh alessandro and pratice um i am actually now a postdoc at uh bu so this is a bit uh out of date but um the title of the paper is proof carrying data from accumulation schemes uh but you may be more familiar with sort of the related notion of recursive composition of snarks

um this is actually what this talk is about this is just sort of the the more like uh proper title um so the motivation at least sort of the from a very uh phenomenal more more academic cryptographic perspective you're delegating a non-determinancy computation um so so whenever i say non-deterministic computation you can always just like think of a blockchain if that if that helps um but basically you have like a long-running computation uh where you have sort of inputs and and witnesses um and uh there is there is sort of kind of two options that you have and

and delegating this computation so and like you're going to ask someone to do it for you you want them to prove that they did it correctly um so the first one is the sort of monolithic proof so you you get your favorite snark or whatever and you uh you write down the computation you write down like the entire transcript and then you prove that the the computation was was done correctly right um so uh oh i should mention sorry that when i when i'm talking about like uh like a long-term computation i mean that kind of you uh have a sequence of of steps um should it be looking in the in the chat okay uh you have a sequence of steps that are all the same

they're like there's like a single sort of uh step function that takes you from one step step one computation state to another this is f and you apply the function f t times uh to itself um so one way you can do this is you can just write down this entire transcription you can prove this is sort of like stocks and things like this you can prove that uh this computation was done correctly um this works but it has a couple of uh caveats so firstly uh you require sort of a large amount of proven memory uh so this is uh like the proven the generally the memory requirement for the approver in this uh system is gonna be like this the state width times the

time right so this is the this is the space this space needs to compute f times the time right because you have to write down this entire computation table um this even if kind of the yeah so this can be much much bigger than that the space required to uh compute the computation which is just s um the other thing is that if you have a proof of t steps and you want to prove like the next step you want to prove t plus one steps then you have to do the entire thing again um so in some situations this is uh this is very undesirable um and so the alternative which is uh uh originally proposed by valiant in 2008 is this thing called incrementally

verifiable computation and what it says basically is that rather than uh recon rather than computing everything and proving everything in one go what you do is you prove an application of f at one application of f at a time so you know i take in the first input and the first uh witness and i run like i turn the hat the crank and i i get out like the first output and the first proof um and then i plug this in to like another instance of my prover and i do this over and over again um and in the end i i end up uh so i do this over and over again in the end i end up with the with

the output which is this uh zt and the proof pi t which could attest to the the correctness of the entire computation um so this is the kind of thing that is used uh like this is the kind of setting for fixing blockchains right because you can think about uh this this uh pf this f as being the the transition function for the blockchain um and this is very useful in this in the setting because uh the blockchain is kind of a uh like an evolving computation right so it's not like you have you run t steps and then you're done uh you're gonna like continuously run this computation you're interested in its correctness at every time step um so are there any questions about the

the motivation and how this relates to using blockchains um yeah just in general i mean given the the way just for every all the participants if anyone has questions or ideas i know nick you're gonna kind of stop along the way so you can add some of the questions into the chat if you just want to like remember them we'll revisit that um otherwise yeah yeah it's just it's difficult for me to look at the chat and do the thing so if you ideally just stop me no problem yeah okay cool [Music] uh okay great um all right uh okay so uh just

sort of quickly about about applications of this thing so one of them obviously said uh sort of why we're talking about it in this in this uh ck study club but uh you can also use them to build more efficient snarks in some sense so you the this is the sort of the original uh like it's so called bootstrapping for snacks um this is not really something that is done because it doesn't actually lead to practically efficient things but at least for uh uh for asymptotically you get sort of maximum efficiency um you can also use them to do use this to do verify both of the functions because you you uh if you think about this f as being like a

something that like takes a little bit a little while to compute um then you apply it many many times um then you can prove this uh that you replied this thing many many times uh in a way that you could verify much more efficiently um there's also like not so much things like this um so this is a you know this is a great primitive um the question is how do we actually build this thing um and the original construction uh which is from this 2013 paper uh says that basically snarks with poly logarithmic verification imply idc and pcd and we'll see like how that works in a sec

um and uh oh sorry i should say pcd is ivc but uh rather than just a just a like a a line like a path of computation you can have like an arbitrary uh directed acyclic graph so like a tree or some some more complicated graph um so this sort of models rather than like just a linear computation more like a distributed computation um but every time i say vcpc you can just think about ibc if you want um and uh okay so so this was extended more recently to uh to building this thing out of snarks with sub-linear verification so this is

like not polylog but like anything that's like below linear um and also we showed that uh we showed in this paper that uh if the snark you start with is post quantum then so is the resulting scheme uh in case you're interested in that um unfortunately this sublime verification requirement is like pretty strong um so it restricts the like snarks that you can use and particularly you might want to use snarks that have desirable properties but have like linear verification time um and so the question that we ask in this paper is like is subliminal verification required for ibcpcd and uh there is some some evidence to

suggest that that's that's not the case so there's this halo work um this is beau greg and hopwood uh and what they do is they show that uh they like propose a way that you could do recursive composition for like a specific snob which is the like bulletproofs type snark which has linear verification um but you can like do some special trick that that allows you to nonetheless recursively compose it to sort of get around this sublime verification requirement and so they do a bunch of uh they do a bunch of uh work in sort of the practical aspects of this like how you would implement this um but they what they don't do is they

don't describe in detail the the way that you would construct ibc uh and they don't prove it secure um so we sort of plug this pog this gap in this paper nick i have a quick question um the essence star snarks stand for succinct right so what is this knock with linear verification so okay so succinct can mean two different things uh so i'm looking at the very broad definition of snarks where succinct means that the proof is small uh whereas the the verification may be maybe linear yeah uh so yeah there are there is a some people when you when when you say stock it means

like uh also the verification is short but in this case i'm going to be more permissive okay uh so what do we do so we introduced this new notion this cryptocurrencies called accumulation schemes and we show that if you have a snark when the accumulation scheme then you can get this ibc pcd even if the snog does not actually have similar verification so even if it yeah it's linear or worse secondly we can obtain snarks with accumulation schemes by basically combining a stock with where the verification is efficient relative to some primitive when the accumulation scheme for that primitive and pratush will talk more about this it might not be very

clear what that means at the moment and finally we should show that you know you can instantiate this in the case of polyglot schemes um so there is sort of one uh big caveat here uh which is important from a cryptographic perspective um which is that theorem one holds in the standard model so this is where there is no random article um and it doesn't hold in the random oracle model whereas theorem three we don't know how uh to instantiate in the standard model uh theorem two actually is black box so it holds in both um and so you have to move from one model to the other in order to sort of

stick all the stuff together and get the the final scheme that you want um so this is something that you know we believe to be fine from a security perspective but it's unsatisfying uh as a cryptographer finally you may have heard of things called set accumulators uh these are different this has nothing to do with that accumulators whatsoever do not think about set accumulators um okay uh so here's like a more more pictographic presentation of the results so what you want is you know in the end you want this pcd and the way that you build it by ethereum one is uh using it by using a snogwritten

accumulation scheme and the way you can get this is you apply theorem two to a snark which is uh efficient so relative to some predicate um and an accumulation scheme for that predicate oh sorry it's not which is uh uh we yeah which has been written into some predicate and accumulations give it to that predicate um and uh you know as an aside you also get something verified snacks this is sort of what you would like to do in in principle uh except that we don't know how to build these accumulation schemes uh uh in the standard model so actually you sort of have to start with some accumulation scheme uh in the random oracle model

and the snark which in this case is also in the random market model um then you apply theorem two to obtain a snug within the accumulation scheme this is again in the randomical model and then you apply some some heuristics so this is like the the step that is like not necessarily cryptographically justified uh this gives you a snogwritten accumulation scheme which you can then uh apply theorem one two to obtain new constructions of pcd and ivc with uh with new properties uh okay there are more questions i have a quick question on this one so if you start with a snark in in the in the rom um and you do something very simple just a single layer of recursion nothing fancy

like ibc or whatnot do you do do we still have these kind of problems even with just one layer of recursion uh i guess it depends on what you want to get out of it um so i think you can so so so the the problem is right the that i at some point i'm going to have to start proving things about the oracle uh so whenever i have to prove anything about the oracle i have to break the abstraction and instantiate the the oracle with a with a hash function if i can get around this like with one one level of recursion you might be able to say well i don't need to prove anything about the oracle i could just sort of save all my oracle queries for later and then and then do them at the

end uh so it's possible that you could get something um meaningful in actually in the random oracle model um but you can't do this like good it's like big depth recursion one layer of recursion you can just um basically as nick said you can just sort of save the queries and evaluate the random article outside uh the recursion and just feed in the results as sort of public input into the recursive snap and then inside the snark you only you assume that the random article queries around so honestly and then outside the snark the verifier actually runs around the marker on the queries yeah that seems like that should work

okay great thank you okay uh so i'm gonna quickly now go through sort of the a bit of the history of this so i don't know if you if people have seen uh the construction of recursive composition from snarks before um but i will uh sort of go through it very quickly um so firstly this is the the blueprint for ibc right so you have these two algorithms there is a proof algorithm and a verify algorithm the prover takes in uh like a an input which is the current state of the computation z uh along with a witness for this step uh and a proof pi and then outputs uh the

next stage of the computation is at prime along with the proof pipeline and then the verifier uh he at any point he can like come in and try and verify the computation so he like takes the this uh z and pi and uh and up output zero one depending on whether he thinks it's uh it's correct or not um and you can see that kind of this allows you to to do this uh comp this sort of stepwise proving because i can just sort of feed the answer of the prover back into itself and get a get a new proof um so i won't go through the the definitions uh i think that probably i don't know if there are if there are any questions about this setup like why this is the definition of ibc

uh then go ahead and ask but i'm not gonna go into detail on the definitions otherwise okay um so one important part actually i do have one one quick question sorry yeah um so i'm interested in the the vdf use case okay and in that use case you only need soundness you don't need knowledge soundness so does this simplify anything well or does it yield you know better results in some way uh that's an interesting question uh at the moment we don't uh we don't know of any

like we don't know that it helps to only target samus um so in the proof that this is secure you need to use proof of knowledge and then you kind of obtain proof of knowledge sort of for free um it might be the case that there are if you're only interested in soundness there are other ways to do it but we don't know okay thank you yeah uh so was i saying oh yeah so crucially for the efficiency of the scheme it needs to be the case that the size of the proof never changes right so you could uh you could imagine like a sort of rubbish ibc scheme where the proof grows with t right so every time you apply the the prover like the proof gets a little bit bigger this would be no good because because

then you would have a proof which is like of size t uh at the end and this would not be succinct um so we're just gonna enforce uh that the proof stays the same size um one other thing about this definition i guess that is important to note uh is that we don't make any assumptions about where the previous proof comes from so the previous proof could be adversarially generated like it doesn't have to come from an honest application of the approver uh and the system should still be like should still work even if you throw in proofs that were adversarially generated okay um so uh let me quickly define a stock i

guess everyone has probably seen this so this is a uh so we're gonna think about stocks with pre-processing uh so there is a setup which uh takes in the in the circuit and now puts like a proving and verification keys for the circuit um and you know we have uh we have the naturals of completeness and adaptive proof of knowledge properties sublinear proofs so this is like the thing that i'm insisting on is that the size of the proof is much more than the size of the circuit and then i'm going to say it's optional whether you have to lay verification or not [Music] okay so let's see quickly how we build ibc from recursive composition of stocks uh so

uh so that i'm going to describe first the the approver and then the verifier so uh the prover if you remember from the picture so i've dropped this w but uh just to simplify things so you have the just a z and a pi coming in and uh z and the pi coming out which is of the the this is the step function of the computation and uh we can just sort of fill in what ought to happen in order to go from zt to the t plus one and from pi t to pi t plus one so obviously if you go from z to z d plus one you apply the the function f right this is the step function of the computation um now we have this proof pi t which we uh would like to make sure is correct

and so we are going to apply the verifier to the snark verify this if we compose these two things together this is a this gives us a circuit r which is the uh sort of the the recursive circuit um so this is the thing we're actually going to prove um it also takes in uh itself it takes in a description of itself as a as a verification key um and then in order to generate the new proof all i have to do is i have to just prove that the recursive circuit would accept so that it would sort of output the the this uh zt plus one um that you told me and also that the previous proof would verify

okay so that's the this is like the basic recursive composition prover uh and the recursive composition verifier is really just the snob verifier um so it's going to take in you know the initial state and the final state and the the final proof and uh just decide whether it accepts or not but just by running the snog verifier on this um uh with respect to this this uh so the circuit that is that's verifying is the circuit this recursive circuit r um so i won't do the completeness proof uh but basically the uh the completeness follows from the start completing this and the soundness what you do is you do this sort of recursive extraction this is actually

where the proof of knowledge comes in so you need to sort of go back in time and you need to extract the previous proof and you do this over and over again until you until you get back to time one um so are there any questions about about this like uh does this make sense why this works quick question nick sorry um yeah just to make it clear the instance here like the public inputs in some sense are are they all of the zt plus eyes or is it just oh i can see sorry z1 and zt yeah yeah so the so the z's have this property that like the you know they're determined by

uh by doing the steps so you only need to know z1 and zt and then you can well you only need to know z1 you can figure out everything in the middle but you you're interested in zt so you know big t is the last it's the last step yeah exactly it's like the output of the computation at time t yeah thanks um so the nice thing here is that this efficiency property appears to be satisfied because the size of a snark proof so the size of the proof here is that just the size of a snark proof for the recursive circuit are which is some effects in circuit um but this is worth diving into a little bit more because it is the actual reason why why you need something verification um so the basic thing is that the

the verifier circuit v needs to be able to check its own circuit like you need you need to be able to feed the description of the verified circuit into itself um so okay so i wouldn't i wouldn't spend much time on this but basically the the the point is that uh i need that the size of the verifier circuit for a circuit of size and star is at most n star minus something and so this means that the verifier the size of the circuit to verify a circuit of size n still has to be smaller than n star and this is sort of where the sublinear verification comes in um so what about if you don't have it uh so this is where we introduced this

thing called an accumulation scheme and uh i have like a a picture which uh sort of explains what an accumulation scheme is and then i'll explain how you get pcd from it um so imagine that you have a sequence of uh inputs like this this like a stream of data coming in um q1 up to qt and you have a predicate uh you have a predicate phi which uh you apply to each of these qi's and you're interested in what is the conjunction of the phase applied to all of the qis that are coming in right so i'm interested in like this

this big hand over here um so one way that i could do that is i could just evaluate phi of uh q i for every q i and then take that out right so this this uh this is kind of the basic way that i can do this um and we want to do something more efficient uh with the help of approver and what we're going to do is we're going to build this thing called an accumulator which allows us to essentially capture this this uh the truth value of this this statement uh with the help of approver so what the prover does is he takes in each of these qi's and he uh in each step he he takes in the accumulator uh and applies his proven function to the accumulator and the

q i to get the next accumulator and so he keeps doing this um and what the verifier does is so that there's like this algorithm the accumulation verifier and what this does is it checks that the prover did his work correctly so it it takes in the the queue it takes in the a0 it takes in the a1 and it checks that the prover did this accumulation step correctly so you have one of these also at every time step and then finally there is an algorithm called the decider which takes in just the accumulator at say at some time um and it decides to whether whether the accumulator is valid or not um and if i take the conjunction of all of these things so all of these

verifiers and the decider and i get one this implies that uh that the and of all of the qis uh was the end of all of the fake uis was indeed one so why is this helpful well if uh if the verifier if this little verify guy the accumulation verifier is relatively efficient uh compared to evaluating the predicate then i've saved computation because i only had to do uh like one big decision at the end and then t little verifications um and i sort of uh delegated everything else to the

approver um okay so this is nice but i you know it doesn't immediately seem to give you uh ibc um oh sorry that's the one thing the size of the simulator should also not grow with the the time t right so this would be trivial if it did um but it doesn't so sorry here the approver is is trying to logically prove file the predicate so he's trying to prove uh like this conjunction the the conjunction of all the all the fights um right so he uh he's trying to yeah so in each step that that all of the previous uh fires

were satisfied and also the new one uh you know there's also is also satisfied by this qi okay yeah so instead of i mean what what would be really the difference between that and just approver proving phi on every q i and then the verifier just verifying every proof uh so this would be like the so this would be like more work for the for the verify i think um yeah what are the mini verifiers doing here that like so the mini verifiers are just checking the accumulation step i guess let's see so the so you're saying maybe i just

i proved that phi is satisfied like all that what the verifier does is just it's just uh it's just check a proof that fires is satisfied right like if i'm if i'm delegating the work to the approver anyway yeah and i use the succinct uh proving system might as well right right so we're talking about that it's not a sublinear verification yeah exactly so i don't have a succinct proving system yeah so this uh i guess i should say this this this like one way to build this is to use a stock this is like a weaker thing than a stock um so it might be easy to construct um okay so so i guess the the interesting thing is you know we can

attain a snog from this like weaker object um and the theorem says that if i take a stock and i i uh have an accumulation scheme for the predicate which is just not verified then i get uh abc pcd4 uh and i get ibc or pcd um so here the the verifier doesn't need to be sublinear but the accumulation verifier has to be and so it's sort of important here that the accumulation is like an easier task than uh incubation verifying is an easier task than verifying basically uh because i want this uh accumulation verified to be to be sublime um then uh okay so as i

uh as sort of i alluded to if if the verifier is already sublinear then you can sort of use this trivial accumulation scheme where like the decider does nothing and the the verifier is just the stock verifier um and so we also get some some nice security properties um so this is the construction basically looks very similar it's just that you have this extra this extra thing so uh the ibc proof now consists of a snort proof pie um which is still small but it's not easy to verify and an ivc proof and an accumulation an accumulator uh a and you you want to apply the this uh

this prover and you you go from uh like z i pi a to z i plus one pi plus one a plus one um so again we can just fill in what sort of logically has to happen so f takes you from z i to z i plus one um to go from a i to a plus one you apply the accumulation scheme improver uh because the this is an accumulation scheme for the snark verifier and the stock verifier is going to take in uh zi and pi um and then the the other thing that you need for an accumulation scheme is to take in the previous accumulator and this gives you the next accumulator then i'm going to want to check that the prover did its job correctly so i'm going to feed the necessary things into the accumulation verifier

and finally uh i like the thing that i need to do is i need to attest to the fact that i checked this um and so this is done by using the uh using the snark prover so this you build this this recursive circuit r um and you apply the star prover and this gives you the next proof step um now the verifier just consists of the decider algorithm right so it needs to check that the accumulator was computed correctly at the end uh along with the snark verifier which is potentially uh remembers potentially linear time but this is fine because i only do it like right at the end um so why did we save here like why did we not need

the snark verifier to be linear to be sublinear it's because the recursive circuit now doesn't contain the snap verify it contains this other thing the accumulation verifier which is doing something that is potentially easier um okay so soundness i will skip because it's uh it's basically worked by this by the same principle you sort of extract backwards in time but now you also need to use the uh the soundness of the accumulation scheme to make sure everything works out um and uh so that is sort of it for this half of the talk this is the the theorem that you get um and i will uh hand over to practice who will answer the question of how we can start snarks from accumulation schemes

and maybe while we're doing that if there are any thoughts questions comments yeah feel free to ask let's look and see if there's anything i i had a question about one of the last slides i don't know if it's uh the same presentation or not but uh i was just um thinking like i don't know i didn't get this time to see it but was there any recursive uh part because it seems like the pi i plus one was sent to the verifier of the snark um right so there is recursion right um so we do have this in the end the snark

approver right which some record but the point of this recursive circuit does not contain the snark verifier it only contains the accumulation scheme verifier um so you're really just generating two okay so like okay so like in the previous picture let me try to go back to wherever that was okay yeah so in this picture you can see the recursive circuit contains the snark verifier right and the problem is that now like we're trying to construct things with this snark clarifier is like quite large it's like linear so it's a size of you can think of this box as being the same size as r right so you can't like keep doing it because r will keep growing as you like go down your time steps right so

so what we do is that we sort of kick the snark verifier out of the recursive circuit and we replace it with this accumulation scheme verifier and now what we say but now because this knock verifies no longer inside the circuit it doesn't have to be sublinear because r like this recursive circuit does not the size of that does not depend on the stock verifier anymore instead of you require the accumulation scheme verifier must be sublinear you're essentially showing a one one level recursion here though right that's that was my confusion i think yeah so there's a one level recursion you can just imagine that you know you can sort of copy adding provers yeah yeah have more copies of the ibc prover in the middle and in the end it'll just be one obviously verified that verifies the final like key step proof perfect thanks for that

clarification there was one question also in the chat from srikar who's who asked if there's a concrete example of this accumulation scheme and i guess i mean halo uses something like this yeah so in this yeah so halo for exam they didn't phrase it as such because i mean not paper was not out when they released their paper um but yeah so halo like if you viewed in the right way like it is an accumulation like the key idea there is to construct an accumulation scheme for one specific snack and we'll go over like you know how that construction looks there's also like you can sort of plug in different underlying components with accumulation schemes and get different uh snacks with a different sort of properties which

we'll see okay any other questions about this part like so as nick said basically recursion is just it's very similar to the recursion for uh inside the soundness for this is very similar to soundness for um so the standard recursive composition but additionally you have to rely on soundness of the accumulation scheme not normally extraction just soundness which is i think a cool thing okay is there another question in the chat i don't know uh no you just said thanks right okay so the question is now how do we construct these snacks which have accumulation schemes

right all right so our starting point uh we'll basically like we'll show how to construct accumulation schemes for a certain class of snacks and these are so-called predicate efficient snacks and okay let me define what this is so snack is said to be predicate efficient with respect to some predicate if you can take the snack verifier and decompose it into two parts an expensive part which corresponds to the predicate and a cheap part which i'll denote by vpe standing for predicate efficient right so diagrammatically what this looks like is that you can sort of take your snark verifier and it into the small box which is vpe which outputs you know some decision bit either whether to accept or not

and it also outputs a sort of set of queries which go into like copies of this predicate file each of which is potentially expensive right and the idea is that the stock verifier v as a whole accepts if bpe equals one so if the the sufficient the cheap part accepts as well as if all of these predicates accept like these small like these fives except they're not actually small they can be expensive right and yeah so this is basically the definition of a predicate efficient snack the idea that you can take your verifier and chop it up into some very efficient small portion vpe and some like more uh like expensive portion called uh which we'll just call

generically like a predicate file here right okay so uh yeah this is supposed to be cheaper compute on each of these files is expensive to compute all right so what we show is that for this class of snacks if you have an accumulation scheme for the predicate right then you can additionally get an accumulation scheme for the snark as a whole right so let's see how this construction looks like it's very very simple for the prover for the accumulation scheme approval for the snark what you do is um okay so you have these three algorithms um the approval verifier and decider the proverb takes in like some proof and instance pair and along with like a past

accumulator and outputs a new accumulator the verifier takes in this you know proof instance pair along with the old accumulator and checks a new accumulator and the slider just checks the final accumulator okay so let's see what all of these algorithms look like so the decider this approval is very simple right it computes the predicate efficient portion of the of the snark verifier right so it computes this vpe on x comma pi and gets out um this decision bit and the set of queries and then it invokes the accumulator accumulation prover for the for this predicate phi right so you can see here it invokes p5 right and so you get yeah on on this query set that is output by vpe so essentially what we're doing

is we're sort of accumulating all of the um uh queries that that would have been sort of input to phi we're just accumulating them away into this a prime right and okay so i think in the talk so far we only mentioned like accumulating one input or like one query at a time you can actually so generalize the definition to accumulate multiple inputs and multiple accumulators at a time um so that's what we do here so in sort of if it's if it makes in things simply you can just imagine queue as consisting of just one input um okay so this is a very simple like what the prover does the verifier is also similarly you know uh easy to reduce to

uh v5 so what the snark accumulation verifier does is it computes uh this verification predicate uh sorry this predicate efficient uh portion of the snark verifier on x comma pi it gets out the bit and the query set so remember this vpe is cheap right so it the snark this accumulation verifier can always run vppe okay um it checks that this bit is one and then it invokes the accumulation verify for the inner predicate and checks that you know on that set of on the query and the old accumulator and the new accumulator sort of this accumulation happened correctly right and the decider is just one step it just invokes the decider for the for the predicate

so nothing fancy there any questions on like on the predicate efficient snack definition as well as this construction so i haven't mentioned like what the predicate can be we'll see in a moment just what these predicates can be uh but sort of assuming like you know there is there exists such snacks does this construction make any sense are there any questions about it did i mention did i explain anything not clearly okay uh if not then we'll go on yeah basically the idea is that you sort of accumulate away the expensive part of the snark verifier instead of computing it just accumulated away for future people to check in like some future time

all right okay so at high level the security and because the construction is simple it's like fairly straightforward to reduce security of the accumulation scheme for the snuck to the accumulation scheme for the predicate and additionally we can get some nice properties that if uh this accumulation scheme is the inner accumulation scheme is quantum secure then so is the outer one and so similarly for zero knowledge right okay so sort of the yeah and efficiency is yeah the efficiency for the you know thing along with the efficient along with the time taken to run this um cheap portion of the snack verified that vpe okay so sort of the takeaway from this part is that um

uh like why did we go through this like you might think or we started started off with you know a goal to construct an accumulation scheme and now we're still left with a goal to construct an accumulation scheme but the idea is that now we sort of reduced our uh like the work that we have to do the idea being that sort of five should be like a simpler predicate than the snark verifier as a whole so now we've taken we've gone from you know constructing a communication scheme for a complex predicate which is the uh it's not verified to construct an accumulation scheme for a potentially simpler predicate which is this file right and we'll see how we can actually leverage this this is exactly what happens so there's a question in the chat um so the quantum secure properties

basically uh we don't do like anything like in this reduction that's happening here oops there we go this reduction is happening there are a class of rsa and other structure based accumulators so if i understand that correctly then it doesn't have qc resistance right or do we have no properties for accumulators uh so get two things so i think as an extent like this has nothing to do with uh set accumulators right so they're enough are for set accumulation right they check membership understand so that's like a separate concept um like unfortunately we tried to like reason about different names but sort of accumulation scheme was the best uh most apt name that we could

come up with that's like one thing so there's like there's no uh this is nothing to do with set accumulators right and as a second thing um uh like this reduction only talks about like some abstract things right it says if you give me an abstract snark which has some is predicate efficient with respect to some predicate five right and as long as i have an accumulation scheme for that predicate and and then i can construct an accumulation for the final scenario is quantum secure and sort of the accumulation scheme for this inner predicate is quantum secure then the accumulation scheme for the snack is awesome and the idea is that at this point we

haven't instantiated any of these components so like you know it's sort of a abstract statement saying if you give me quantum secure ingredients i can get other quantum security there we go that's all as yet we don't have any sort of interesting quantum secure accumulation schemes um just because of the the things that uh like the the nature of the construction so far we've been mostly interested in in uh these like level commitments um and we don't really we don't have post quantum secure constructions of those is that because um uh quantum secure algorithms um tend to have less structure and you need the

structure in order to produce a polynomial commitment scheme or yeah that's basically it i mean you can get like like lattice-based primitives do have structure but not as rich as structure or as like useful a structure as like uh as you know bilinear groups and things like that is it right if i said lattice groups do have some structure that's so well structured that they can actually have some attacks versus you know linear groups that's the structure but the structure is slightly different gives us some uh you know proofs of randomness in that sense uh can i do it that way no i actually i would say that lattice

lattices have sort of less structure so lattices have the sort of usually linear homomorphisms which which also you know groups have um yeah but the lattice basically your homomorphisms are sort of less flexible uh you like their only bounded uh you know you can only apply them badly many times uh there's no pairings you know so yes okay thank you and also in lattices you you do get like a very large dimension and it's harder to actually identify a structure yeah and you have to deal with things like noise growth and stuff but in general like sort of yeah as soon as it was saying so i did mention that everything here is abstract but like unfortunate and this sort of theorem

holds you know this is a true statement but we don't yet have ingredients which are you know namely the accumulation schemes are quantum secure so we can't sort of plug those in and get like something that's quantum secure but when those things come out in the future i'm sure they will then if you plug it in here then you'll get a accumulation quantum secure accumulation scheme for that snap so so on the the third point uh um so a distinction between hiding and zero knowledge for any communication scheme or is that just one definition so sort of i guess zero knowledge may be i'm not sure that's like the most

accurate term to describe the property basically the idea is that you sort of can't distinguish like a if i give you just an accumulator um like you can't uh what does exactly probably forget um you can't sort of distinguish yeah even if you're yeah you can't distinguish like a sort of an only generated accumulator from like a sort of randomly sampled one sort of is the uh definition so it's not exactly like zero knowledge in the sense of um so it is in some things you know you just sort of hide the graph before behind you in some sense like of like what you accumulated in the past but so so this is whether the commitment is hiding and there's also whether the

opening proofs are zero knowledge is that right okay so that like that's when you sort of get into like the concrete instantiations with pc schemes right right yeah okay but at this point you're still on the the more abstract concept okay got it yeah so essentially like we as we get in the pc schemes we will see that it does depend on the pc scheme like what sort of properties required for the pc scheme um so yeah i'll go into that a bit more if i forget just please remind me at that and i get there okay i'm sorry i wasn't able to join earlier i had another um classroom meeting well no worries uh yeah if you if i can just uh but in a six of the the

definition of zero knowledge that we have is a simulation based definition as for accumulation schemes so it is zero knowledge in in that sense um we actually didn't explore really uh whether uh an indistinguishability based definition would have worked um i maybe it would have i'm not sure uh but yeah uh but it is a like a simulation based definition basically that you can come up with an accumulator that sort of looks the the same as you can you can come up with the accumulator out of nothing that looks the same as an accumulator that you was honestly generated yep yes so if the accumulation scheme uh relies on um

a common reference string then you're allowing the simulator to pick the common reference string is that right all right yes yes okay so yeah for concrete pcs for the pc scheme that you'll see like for the ones based on the street logs uh yeah for example you would have to use some allow the accumulation scheme simply to sample the trapdoor i think but that's like yeah so yeah we'll get into that later okay so the efficiencies as i said basically what we've done in this section is to go from the task of designing accumulations looking for a complex predicate namely a snark verify to designing an accumulation scheme for a

potentially simpler predicate this five thing okay so let's see what like what you know this phi can actually be right so where do you find these predicate efficient snacks okay and uh okay so the starting point is like so in in the past few years people have introduced i guess in the past year people have introduced uh sort of this methodology for constructing snacks where you take in two components some information theoretic component like a polynomial iop or ahp along with uh commitment a polynomial commitment or a pc right and you sort of plug these into standard compilers like um like what we have in mullein or what um co worked on and so if you get out of snack uh pre-processing snack in this setting

and uh yeah we know of various ways to instantiate both of these components so like for the top thing you can look inside sonic plonk marlin and other works as well and so these give you these information theoretical parts and for the polymer movement schemes we also know quite a few things by now which is the original paper was the kcg10 paper there's these uh commitment schemes based on groups of fun and order there's the one described in halo and others as well in time senses right and so this methodology has already been used to construct many popular snacks such as sonic blanc marlin um also in halo and others as well right so any questions about this methodology

this is not like something that we introduced in this work this is all basically prior work okay so if not okay so the key thing inside this compiles to notice is that if you look at the verify for the snark that you that this compiler spits out right the it consists of one cheap portion which corresponds in some sense to the verifier for this information theoretic component for the ahp right and one expensive component which corresponds to uh checking some stuff relating to the polynomial commitment scheme so we'll see what these are in a second but basically this is what the verifier looks like there's some small component for the hp and one expensive component for the pc scheme um so there are some questions

in chat we try to look at them no questions nick just had to bounce um all right so yeah so i guess the thing to notice here is that if you look at this diagram here it's very similar to the diagram that we had before right where you can think of so what what this means is that this verifier is predicate efficient with respect to uh this predicate phi which is pc check right so vpe is now this vahp and phi is pc check right so now if we can construct an accumulation scheme for this predicate pc check right then perhaps we can then we can apply our theorem from the previous section and construct an accumulation scheme for the uh

snark as a whole [Music] okay so right so what we do so yeah basically this is sort of the diagram the thing that we trying to do right so we can apply theorem two and then we can get out thank you mission scheme for the stop right so this basically means that now we have to try to construct accumulation schemes for polynomial commitments okay so just a quick recap of what a polynomial commitment scheme is so in a polynomial scheme there's like two parties a sender and a receiver the sender has some polynomial in mind over some finite field right it uh commits to this polynomial using this pc commit algorithm right it sends this commitment c to the receiver

and what the receiver now says is that give me the opening of a prove to me that the polynomial that is committed inside c evaluates to something at uh yes it says yeah please provide me with the evaluation of this committed polynomial at some point z of my choice right so the receiver sends this to the to the sender and the sender sort of plugs this point z along with the original polynomial into this pc open algorithm which outputs the evaluation as well as a proof that this evaluation is correct so what this means is that this proof asserts that f of z equals v right okay and so the receiver then plugs

these the commitment the evaluation point and the evaluation and the proof into pc check and decides whether or not to accept so sorry this is the diagrammatic overview of a pc scheme any questions about this okay so then we can go on um yeah so what we show in this paper is basically how to construct accumulation schemes for two popular polynomial commitments right so the first one is uh pckcg which is a polynomial commitment scheme based on the construction and the kcc 10 paper okay and this is used you know uh for example

it's one underlies modern it was on what yeah the original plonk paper uses pckg sonic as well or variance of the scheme right so it's a very popular scheme in the literature right and this is sort of a quick recap of the scheme you won't need to know about it for what i'm going to tell you next but yeah it's sort of simple enough to fit in sort of this diagram okay so the properties of the scheme are that uh checking an evaluation proof takes two pairings right and the proof size is just two group elements um right and what we show is that there is there exists an accumulation scheme in the random oracle model for this construction right which has the following properties

so the accumulation scheme the accumulation verifier requires no pairings right so so you only do some scalar multiplications the accumulator size is still the same it's still two group elements no matter how many proofs you're accumulating and the decider now has to do one pairing at the end right so this is nice because um yeah so now at each since like if you're verifying n proofs instead of being like n pairings you can sort of uh accumulate them and then just do one um start uh yeah you can just scale the multiplications instead of pairings uh and by the way um it's not just that pairings are inefficient it's um but they're really complicated um to do well yeah you're likely to have

security uh security problems if you try to do that and it's not yeah yeah that's a very good point you sort of reducing the complexity inside you know your snack inside your recursive circuit which is always good because it makes it easy to audit and um yeah just simpler to reason about and and cheaper in this case okay so as we'll see like in the app in the final like when you sort of plug in the entire things you'll see like you got out a uh ibc scheme which has no uh recursion inside the no pairings inside that recursion right okay so that's one any questions about um about these results so i won't go into the details here but roughly the idea is that instead of doing uh pairing you sort of um

take a random linear combination of the inputs through the pairings and sort of that's your accumulator thing this randomly combined um yeah the randomly combination of the inputs that becomes your accumulator at a very high level okay so no questions i will go on okay so what we show that's that's uh for inside of the pairing setting in the discrete log setting what we show is that you know if you have pcdl which is a polynomial commitment scheme based on the so-called inner product argument which has you know underlies many works including bullet proofs and halo right so there's this pc scheme and so this was described

um also in halo and the idea is that the security of pcdl relies only on discrete logs and random articles so there's no pairings anywhere right so you can implement this with you know standard elliptic curves such as sec p2 256 um as well as you know curve 35519 any any standard elliptic curve and you don't need pairings anywhere right and again this is sort of a recap of the scheme you won't need to know it but the idea is that the pc open algorithm invokes the inner product argument for proving and pc check invokes the verification uh for the inner product argument okay so this scheme has like the following efficiency properties so pdc check like if you're committing

to a polynomial of degree d right pc check takes uh d uh scalar multiplications right and proof sizes of log d right so the problem is that pc check is expensive so it's linear in the size of the polynomial that is committed to right so the cool thing is that halo recently described a protocol for uh accumulating pcdl so it shows that you can take pcdl and construct them and not in the same words but yeah they show how to construct a accumulation scheme for pctr and what we show is that a variant of their protocol is actually an accumulation scheme in the random oracle model for pcdr uh with the following properties right so the accumulation verifier

now only requires log d scalar multiplications not d right the accumulator size is still the same log d as the proof right and the decider now is the one doing the expensive heavy lifting of um uh the d scaler multiplications right and tonight the sort of the takeaway is that verifying this accumulation is exponentially faster than sort of verifying in an evaluation proof inside pc check right and so this is what we leverage uh and this is what halo leverages to construct sort of ivc end-to-end using pcdl okay so any questions about this portion because i again i won't go over the details of this construction but

the paper has more details the halo paper has more details there's been a few talks about it about you know how this is achieved so yeah yeah there's a recent talk on the zk soul meetup um about this yeah yeah so yeah so there's lots of resources um so if you're interested in the details on this i would encourage you to go over that um okay so that sort of wraps up um what we've gone through far so what theorems one and two tell us is that you can construct ivc from a snack with an accumulation scheme even if that's not is uh does not have subliminal verification right and theorem 2 tells us how to construct these accumulation schemes or these

knots of accumulation schemes from two ingredients this predicate efficient snack where the verifier is cheap except for this expensive uh portion 5 right along with an accumulation scheme for the expensive portion 5 right and this allows us to like when we plug in the pc kcg and pc dl what this allows us to do is if you take your predicate efficient snark which is efficient with respect to the pc check right you know whatever goes into the you know like sonic plonk male in all of these sort of they fall into this category so you take that snark and you take an accumulation scheme for pc kcg right and you apply theorem two along with random oracle heuristic and theorem one blah blah that you sort of instantiate the entire chain what you get out is pcd and ivc from

bilinear groups where you have to set up which is unfortunate but you have tiny proofs just constant size and there are no pairing pairings in the recursive circuit as jared mentioned right so this is this we didn't know before all sort of prior constructions of recursive composition from pairing based snarks required doing pairings in the circuit okay so this is a cool new result on the other side if we sort of do the same thing but plug in our accumulation scheme for pcdl right we get out um pcda and ivc from standard groups with no pairings right and they have transparent setup which is nice and compared to like the prior work

which constructs um you know transparent set up ivc uh the proof sizes are much smaller and proving time in general is better um that would that cost 20 is that fractal yeah that's fractal okay and that side has no trusted setup i guess yeah this side has no trusses uh this is transparent setup so there's like no trusses set up anywhere so sort of the cost that you pay compared to this is that the proofs are larger so they're like um you know instead of being uh yeah kilobytes uh like less than a kilobyte maybe 500 bytes or so there are proof is on this side maybe like you know two three four kilobytes or something like that and verification time

like for the end like so the final verification for the ivc is still linear whereas here the verification time is uh is constant that's of one yeah it turns that turns out you can get the proof size down to about i think it's 1.5 k if you use a um a more efficient um polynomial layout like blanc for example yeah yeah so yeah i think yeah that that sounds correct um i guess the the yeah it just sort of scales logarithmically still with the circuit size right so you would uh yeah it's exactly a logarithmic yeah so as you get like larger circuits you still have to suffer from like an increase in proof

size but yeah you can use sticks as you've mentioned in the past era you can do like tree based composition because composition and so on and so forth um which can help you keep the proof size under control um yeah sort of yeah so both of these things we didn't know how to do before so you know recursion with pairing this stuff without pairings in the circuit and i guess we knew how to do pcdwc from you know with transparency but we didn't know how to do it like with standard elliptic curve groups sufficiently um and with sort of these small proofs that this side of the construction gets you okay um right so okay so i guess so that summarizes um the paper uh and sort of

all of the results in the paper and uh so there's like lots of open questions right now so first of all is how do you construct more accumulation schemes for different kinds of polynomial commitments with different assumptions and different kinds of properties um can you improve on um you know yeah for example in the discrete log setting can you construct accumulation schemes that don't have this sort of logarithmic overhead or don't require yeah this logarithmic overhead inside the circuit for example or can you as you discussed earlier can you construct polynomial commitments and accumulation schemes from lattices can you accumulate yeah can you con another question is can you even construct accumulation schemes that don't rely on this random oracle in the middle

um and so maybe that helps one part of reducing the reliance on this random oracle heuristic and so on and there's like lots of interesting questions there yeah a nice particular question is can you construct an accumulation scheme from dory which is a very recent um transparent polynomial i think i think you can just because i mean they already mentioned in the paper they have this sort of accumulation this aggregate checking verification right so that it seems as though you should be able to do that yeah but like the sort of benefits there are somewhat less clear because in the end you're still doing

logarithmic work but it's maybe slightly less slogan's network man you might not have to do like the some gt yeah it would be in the constants that the um yeah that improvement yeah um yeah i mean i think generally like these inner product documents they all have this nice the similar structure to what pcdl has where in the end you're essentially checking a uh polynomial commitment or like evaluating a polynomial and so you can apply the same techniques there as well um okay so sorry that summarizes the thing any questions on you know any of these past three slides about pck gpc dl and this sort of summary here

let me check the chat i think it it's good okay [Music] sorry the key takeaway is that sort of what we do in this paper is which halo had this idea that you can use some necessary dynamization um to construct ibc and so if we sort of take that and i guess formalize or extract it into a primitive and prove properties about it and we show how to construct it for different sort of pc schemes and yeah this allows us to obtain new constructions of pct and advocacy that we didn't know how to do before to instantiate construction on the left is half pairing cycle enough so we don't

need to use some integers for that right so what you still okay so if you just wanted to use just this left hand side then you would still need to use mnt curves but the nice thing is that you can sort of because you have efficient instrumentations of the right hand side what you can do is you can mix and match you can have one side use um this pc kcg based accumulation and you can have the other cycle of the carbon cycle and be non-pairing friendly and rely on pcbi based accumulation and i believe this is like what koda was initially going to do i think since then they have switched to just doing pcdl based uh recursion but yeah so you can definitely uh sort of mix and match these these two

sides of the uh these two halves and uh if you have like a half pair so i guess for the other people in the chat a half pairing okay so existing pairing based recursion required ellipticals which have um sort of this cyclical nature where the base field of one curve is the scalar field of the other curve and vice versa right and the only way we knew how to construct these special curves is via sort of this family of curves called m t cards and these are like unlike you know things you might have heard of like the bls 12 381 377 all these clubs they're quite inefficient um when you have to achieve 128 bit security so basically all pairing based recursion that we knew

how to do so far was quite inefficient because of this reliance on these very heavy curves but what we do know how to do is construct um elliptic curve cycles where only one curve in the in the in the cycle has to be pairing friendly so this can be something like you know bn like a retina curve right and only so only that one curve has to be pairing friendly and the other curve can be non-pairing friendly and we know how to find such cycles very easily so what this allows you to do is now you can on the pairing friendly side you can use pckcg and on the non-pairing friendly side you would use pcdl and you can sort of mix and match these to get much more efficient recursion than you would with the mnt world yeah and you don't have to do pairings

in the circuit on either side yeah on the on the pairing side you inherit inherit the benefits of this on the other side you inherit the benefits of this and that's i think the i think the um the downside is that you you still have to do the linear work for the decider um because right so what you can do with that yeah you can set up so that the pcdl side is only tasked with doing um right exactly uh sort of checking the accumulation for the for pc kcg and you do all your heavy work on pckg so this means that pcdl thing is always like a fixed

circuit so it's always like i mean in some sense it's constant work but yeah because the circuit is like you know only the recursive circuit then it's always the same amount of work on pcdl right even the logarithmic work you only do on the so it takes log work to do the pcdl accumulation but you're doing that on the uh on the uh pairing so on the pairing side right right so i mean you did the constant work for for doing the accumulation for pc kggt and you'd be doing that inside your uh yeah yeah inside the recursive circuits on each side um so okay so on the recursive circuit on this left half you're checking the accumulation scheme verifier for

pcdl so you're doing log work on this side and on the pcbl side the recursive circuit is checking the accumulation for pc kcg which is of one work right and basically what this means is that when in the end you have to run the decider for sort of this side right it'll be for like a constant size circuit and that's what i meant um so it'll be like linear in that size in the size of that circuit but that circuit the size of that circuit is always some fixed constant so it won't grow it like the you know the computation that you actually perform at each step of the ivc or pct there was one question in the chat unless

alan did you want to ask something first sorry i have a question as well about the random oracle heuristic uh that's about your verifier requires the evaluation of a hash function but you're implementing this as part of the circuit correct yeah so the problem is that um inside the recursive circuit you have to either uh you have to like put either the snark verifier or the accumulation verify right and both of these things in all of the constructions we know so far uh require random oracles so when you express it as a circuit you have to instantiate the random oracle heuristically with some hash function and um yeah so that's where sort of this random article heuristic comes in

so i guess it's a question in the chat let me take a look how do i go back there i can actually just say it um again from streetcar it was what would you say is a major open problem emerging from this work or any good directions i think uh yeah i think we went over quite a few of these like one of these for example is constructing more accumulation schemes so different polynomial commitments with different properties the other thing is so this paper does not do like a concrete instantiation of you know implementation of all of any of these things um so halo does it for this left hand or the right hand side uh but uh yeah i would be interesting to see anything like koda they started doing stuff for uh like doing this mix and

match approach where you do pck gpcdl so you're seeing the concrete costs of doing the mix and match approach um and you know what that even makes sense because you actually use like a larger curve size or that even makes sense to do this mix and match approach um compared to the pcds approach i think the motivation for um coda which is now called mina um to drop that approach is that they wanted to go to a completely um transparent setup right yeah that's one that's the main thing and i think they also considered the the concrete costs and it it turned out that the so further use case the um the concrete costs of halo were not

um were completely fine yeah right so yeah so yeah there's like a there's some tradeoffs there um to be mentioned to be figured out i'm like you know whether it makes sense to use mix and match um other interesting things that i mentioned was trying to get rid of the random oracle at least in parts of these ingredients like i mean at least like all of the snacks we know of we still need it on like the snark side even but at least can you get rid of it on the accumulation scheme side um or maybe like an impossibility result there um yeah maybe constructing accumulation schemes for different uh primitives like for signatures like what would that look like off of other things

we have like a verification algorithm um well does that lead to anything interesting in terms of applications i think yeah there's quite a few sort of open questions there's another thing that um i was thinking about um which is can you construct a shark um from using this mix and match approach so if you just apply it in the straightforward way then you're relying on the trusted setup at each step in the um the recursion can you sort of move that reliance um on the trusted setup to just the decider step so that

you can take any of the intermediate proofs and if the if the trusted setup were broken you could then um sort of regenerate the shark from any intermediate proof um yes yes i guess for the other people in the chat um uh shark is a kind of snack where you have sort of two verification modes one is uh sort of uh optimistic verification where like you verify using the trusted setup portion and there's like a inefficient uh like slower verification mode where you don't rely on the trusted

setup and you check everything very carefully um uh and this basically allows you to you know check if the trusted setup was ever compromised because you always have sort of a fallback to the uh slower verification mode which does not use the trusted setup and so there i was asking whether i think so there i am not sure about and then questions like what exactly meant like do you mental like do you mean like recursion and maybe like ivc which has this sort of hybrid verification property is that what you meant uh yes yeah so we are basically the where the final ibc verifier also has this sort of two two mode verification where one is optimistic and one is uh i guess yeah more paranoid and yeah i think i think

that's also interesting i think even just the question of just constructing sharks using this concept um i feel like there might be something maybe even without talking about the recursion idea just constructing sharks um using just this idea could be interesting um cool yeah well i think on that oh unless is there one more question okay one more the other thing i'm interested in is um this theoretical question of the uh the extractor blow up so um if you just um use um ivc in a train um then the um

the size of the extractor increases at each step so one way of getting around that is just to apply it to a fixed depth tree um but um so say you're doing a blockchain protocol that the natural way of using recursion is just to um to apply to the previous block um so is there a way of getting around this theoretical problem and getting a satisfying security proof for ivc for arbitrary length trains yeah yeah so yeah that's certainly very it's certainly very interesting question also applies not only to this sort of ibc that we construct in this paper but also

sort of the previous way to do ibc which is um using uh sort of just standard snacks without accumulation schemes anywhere um but maybe maybe along using accumulation schemes might allow you to sort of make uh yeah like a breakthrough and try to because you're not like really running the snark verify each each step maybe that allows you to do something better you're still learning the snark extractory step unfortunately in the at least in the current proof yeah but maybe there's something but there's no obvious way of doing it doesn't this this random oracle you're using to combine these things isn't that something you need to rewind in the extractor right so if you if you go back

so keep going back back okay so all the way back okay so summary of results right so uh yeah okay so maybe this this slide the previous slide is clearer so basically inside this theorem which allows us to go from snot to accumulation schemes to snacks with uh to to pcd right this thing is can is also like it works in standard model also it's just that we don't know how to construct you know things which are snarks with accumulation schemes without random

oracles but like if you just assume that you have a snack with an accumulation scheme which for example you can like sort of sort of construct one for gross 16 also um so in that sense you would have in stock with an accumulation scheme uh in the standard model uh like you could plug that into this theorem one and get out a snack with an accumulation scheme in every you can get like ivc from these things in the standard model but sort of this this sort of theorem one isn't a standard model it doesn't uh it requires sort of your snark verifier circuit to be not like an oracle circuit or something um so by the time you get to like the recursion like you've already instantiated your hash function

in some sense and sort of yeah you were yeah so then like your assumption of rewinding the random article like programming around a moral it doesn't quite make sense because you've only instantiated it so sort of that's the irritating step right now um that makes sense cool all right i think i think if it's okay we're gonna we're gonna wrap it up here but thank you so much pratush thank you to nick who bounced off a little bit earlier but thanks for for doing this presentation and thanks to everyone who uh who joined yeah thank you anna and thank you everybody else as well thanks so much cool thanks for watching

until next time everyone else thanks