 Hey, everyone this talk is about barriers for succinct arguments in the random oracle model My name is Alonio Gevin. This is joint work with Alessandro Chiesa Let me start with an informal overview of succinct arguments in this model So here we have we have a prover we have a verifier and They communicate in an interactive protocol to decide if X is in the language. They both have Access to a shared common resource and this is a truly random function What is magical about these protocols is that the communication complexity is what's called succinct It's extremely short and in particular much shorter than the size of the witness The soundness is computational Meaning the following two requirements. So we have completeness Which says that there exists an honest prover that can convince the verifier that X is in the languages or ability one and For some this it means that if X is not in the language Then no matter what adversary you choose if it makes up to t queries to the random oracle model The probability that it wins and convinces the verifier is at most epsilon in In general the definition talks about an interactive protocol and our results All of our results in this paper holds for interactive protocols But for simplicity most of the time i'm going to talk about succinct non interactive arguments or for short snarls So Why are we focused on this random oracle model? Well, it's a very elegant information theoretic model And because of such it lets you pull lower bounds Which is usually quite hard to do outside this model And is what we do in this work? Moreover, it supports well-known constructions of snarls in the random oracle model If you want to take your construction outside this model into the real model What you can do is you can heuristically implement the function. We have many such candidates They're usually They usually use Relatively lightweight cryptographic hash functions, and then you get a heuristic construction in the standard model These constructions are also plausibly post-quantum secure and actually for the constructions we have It has been explicitly shown that they are post-quantum secure in the random oracle model, of course So what are these constructions? We have two constructions. We have Micali at 94 and more than 20 years later BCS. This is Ventsa Sonchiasz and Spooner They both work in the same paradigm They take an information theoretic proof. This is a PCP or an IOP And just a short reminder A PCP is a proof that the approval provides And the verifier reads only locally so we don't need a small number of bits from the proof An IOP is simply an interactive Generization of PCP. So after this happens the Verifier can send some message back to the pover the pover sends another message and again the verifier only reads a few bits from this So they take this information theoretic proof. They combine it with a cryptographic commitment scheme that supports local opening These are usually what's called a Merkel tree And together they compile this into a non interactive succinct argument So our starting point of this work is looking at these state of affairs and asking Why aren't there other constructions? We have this Strong model. Why don't we have more constructions? Why do all of them rely on these relatively heavy machinery of a PCP or an IOP? So now let me state our results So first we show that you can take any succinct argument in the random oracle model And you can distill from it an interactive oracle proof an IOP This is our first result. Moreover the parameters of this IOP are going to be very closely related To the parameters of the succinct argument and we'll see more about this Then our second result shows that Gives limits on the soundness of interactive oracle proofs In particular, if you have a very good IOP you get a very fast algorithm for 3SAT Combining these we're able to show that If you start with some too good to be true snarg You get a too good to be true IOP which is a very fast algorithm for SAT And if you assume eth the exponential time hypothesis Which is a standard complexity assumption Then you get a contradiction ruling out the existence of this snarg to begin with So that was an overview of our results and now I want to tell you about them in slightly more detail so the first result IOPs are inherent for succinct arguments in the random oracle model So you start with an succinct argument And you can really distill an IOP And not only that the parameters that you're going to get here Are very closely related to the parameters of the succinct argument A few more terms mainly aimed for experts If you start with a preprocessing snarg you end up with a holographic IOP And if you start with a snarg with a stronger soundness notion that we introduce some called salted soundness Which mainly says that the cheating pover can query some x Get the response y and if he doesn't like it he can ask to resample this response So if you start with this strong notion you get the strong notion of state restoration soundness Which is the soundness notion you need when you compile IOP back to snargs So I want to go slightly deeper into the parameters. So just I want to We consider the pover adaptivity parameter This is the number of query rounds That the honest pover makes to the random oracle So of course the honest pover can make the queries one by one But in the constructions we have actually this is performed in a few rounds So in each round the pover can send List of queries so x1 to xn and then he gets back a list of responses y1 to ym and after seeing this responses he goes And decides on the next list of queries to ask the overkill So as I said in all known in constructions this adaptivity parameter, which denote by a is actually quite small It's log n. So now going back to our result If you start with a snarg with argument size a yes argument size Vq verifier queries pq pover queries and adaptivity a You end up with the following iop So I'm mainly going to talk about these two parameters. So what is the poof length? The poof length is pq plus as so as is the argument size So of course we're going to have the argument here But you cannot expect to have only this because the argument is succinct and you we do not expect the iop to be succinct So we have the poof queries here, which is some arbitrary polynomial in the witness length The more important parameter is the query complexity. So this we want to be We want this square parameter to be small So this is a yes. So The verifier would need to read a yes. So we need to read the argument itself Uh, so that's at least a yes bits or just one query if you consider a larger alphabet plus We need vq times a so for every query of the verifier to the random oracle we need to read a bits on the poof There is an incomparable result of rod blom badam. They showed that pcps are inherent in succinct arguments But they consider succinct arguments that were obtained by a black box reduction to falsifiable assumptions In particular, the result does not include constructions in the random oracle model And most constructions outside the random oracle model actually use non-facifiable assumptions But the two results somehow complete Compliment each other. So I want to move on to Theorem number two result number two. So this is limits on iop's and pcps Our main question here is how high can the soundness of an iop be? Okay, and the theorem says the following So suppose that threesat Over n variables has the following iop It has soundness error epsilon It has k rounds The poof length, the entire communication is l over some alphabets sigma And the query complexity is q. So these are just the parameters Such that this condition holds And this condition merely says that it's a non-trivial iop Because if you Will read n bits then really you could have just read the entire way Satisfying the sign. Okay, so just really saying that this is a non-trivial iop Then You cannot have too good Too high soundness. So the soundness error epsilon Cannot be smaller than two to the minus q log l if it is then eth is false Okay, and we just mentioned that we have an analog result for deterministic languages Okay, if you're interested you can look at the paper And this actually matches and generalizes the sliding scale conjecture Okay, so even for iop In particular it rules out constant query PCP or iop With two to the minus s soundness Okay, even if your alphabet has size Much larger. So polynomial index two to the o of s We said that our two results implied barriers for snogs in the random oracle module These barriers are going to be in the form of barriers on the verifier query complexity So let's think for a minute. How small can the verifier query complexity be? It would be really wonderful to have snogs Well, verifier makes 10 queries to the random oracle module This is in particular important when you make non-blackbox use of the verifier So you need the code of the verifier where you replace the random oracle With some instantiation Some hash function then every query really blows up the code to to be huge This is in particular important when we talk about recursive composition So our corollary says That is very unlikely to have such snogs where the verifier makes 10 or a small number of queries to the random oracle So let me state this slightly more formally So if you start with a snog with s bits of security And here this is really a shorthand just to say that If you make 2 to the s queries then The probability of winning is at most 2 to the s and our security parameter is o of s Okay, so think of s as like 128 bits of security And the verifier complexity is vq and the proved activity is a If this condition holds vq times a is little o of s Then you get a very very good iop Which implies a very fast algorithm for 3sat and this contradicts ath Actually Very recently We improved this to the mere condition that the query complexity of the verifier Is sublinear in s So this moves out snogs with a small number of queries Okay So that was an overview of our results And now I want to give an overview of a proof So this is the transformation from snog to iop So on the left hand, we have a snog here. So again, this is just one round Okay On the right hand, we have an iop And we want to transform this creature to this creature I notice the differences. So this creature has a random oracle and here we do not have any random oracle Okay, this is an information theoretic object Uh, this is short the messages here might be long, but the verifier reads only a small number of locations So i'm going to start with a strawman proof It will give us what we want with bad complexity measures and then we'll see how to improve them So we start with a snog. So this is how it looks like we want to get rid of this random oracle because an iop doesn't have a random oracle So we're gonna push this oracle to the verifier And so the verifier is gonna Have this oracle in his head and simulate it for the pulver So what does that mean the pulver whenever he wants to make a query? she She queries x1 and the verifier is gonna respond with y1 The pulver is going to take this as the answer of the random oracle and query x2 and so on Finally the pulver gets the final argument pi and sends it to the verifier Now what does the verifier do? Well, he got this argument pi. So he wants to run the argument verifier on this The only question is how to simulate queries for the argument verifier And the important thing is that we want to simulate queries Consistently with the queries that we gave to the pulver Okay, just simulating queries easy. We can just answer randomly, but we want this to be consistent with the answers we gave to the pulver So this is what we're going to do for suppose the argument verifier performs a query x We're going to find find around i Where xi equals x Okay, if no such round exists and we really can just answer randomly, that's fine But if we found such an around then we we're going to use yi as a response There is a small problem here by an important problem We must make sure that x was not queried twice Eh, so this is not allowed in the random overcount We do not want to allow the pulver to query x get a response say, hmm, you know what? I don't like this response so much. So let's query x again and get another response So the solution is to go over all other rounds Okay, and verify that what was queried there is not the query that we're looking at So at this point, let me just say this is a valid iop. Okay, we have completeness and we're going to have very good soundness The problem is its complexity. So first the query complexity. Well, we read the entire transcript So it's not a really an iop. It's a very laconic iop And second the round complexity is also huge. So we have around for every query So fixing the round complexity, that's actually easy Why if you go back you remember we talked about the pulver and the activity So we just use that and we let the pulver send many queries at once So he sends m queries at once and the very very far just responds with m answers Then when he gets that he can send the next list of the queries and so on So the round complexity is really going to be very close to the just the pulver and activity But here still the the verify reads the entire transcript So this is our main challenge now Okay, the main challenge to get small query complexity Is the following you're given x And we're given some round j. It doesn't matter And we need to verify that x was not issued in round j Okay, so think of this as round j. We want to verify that x is not here Verifying that x is here. That's easy. The pulver can just point us to the location of x and we can read it Okay, so we can just locally read it and we don't have to read the entire message But we want to make sure that x is not here and for that we're gonna have to ask the pulver for some additional help Okay, but that's fine because this is an iop and I can use the power of iop So we're gonna make use of a perfect hash function so This is a family a small family of hash functions from some universe to o of m for parameter m And we say that this is perfect if for every subset of size m There exists at least one hash function in the family that is perfect on s Okay, there's a famous construction the fks construction You might have learned it in undergrad. It uses two levels of hash functions You first have the first level then you hashed in you're hashed into some bucket And in that bucket you can read a secondary hash function Which solves any collisions The one thing that is important about this construction is that we observe it has an addition additional locality property So to evaluate h on any specific element x You only need to read a few bits from h and this is very important because h might be very big It's actually at least m bits. Okay, actually more than that But if I want to evaluate h on one location x, I don't need to read the entire description of h It's suffices to read a small number of bits from h and this is because of the two level of hashing So I only need to read the first level and then in the second level, which is huge I only need to read the hash function for my bucket So how do we use this we ask the pulver could you please Take the set of elements you want to query in the sound And just put them in a array of size o of n according to this perfect hash function So find a hash function that is perfect for the set of queries and you can actually find this very efficiently And then he takes x one computes h of x one and writes it in the in the correct location This gives local access to the pulver and also to the verifier So the verifier now if he wants to search for x one He directly goes to here to he reads a few bits from h to evaluate it and then directly directly goes here So let's see the entire protocol The pulver is gonna send h one and then an array with the queries that he wants Okay, many places in this array are going to be empty. That is totally fine. Okay, the array is larger than the the set itself The verifier does not look at this and just answer With an array of the same size size with completely random strings This is interpreted in the following way The response for x two for example is this y seven and the response for x one is this y three Okay, so just the same location the same index in the In the arrays So this would be called t and this is t prime And then we go into the next level. He finds the perfect hash for the next next set of queries This is t two we answer with t prime two and and so on So what do we do on a query x? We find a round i where We take the array of this round. We look at only this position h of x and we verify that x is written here Then we take the corresponding y so the same location the array only for t prime and this is the response y that we use And then we're going to verify That for all the other rounds This location in the array does not contain x So this will make sure that he didn't issue x twice So notice that we We are querying every round of the protocol But there are only a few rounds. Okay, this is the pover adaptivity and for every round we're only querying all of one Cyndals, okay per round So the the final query complexity Of the protocol is very small One thing to notice is the verifier does use a lot of randomness in this protocol and this is actually inherent But the important bit is That he has only local access to his own randomness. So he's going to read his own randomness only locally He never reads this entire long string Okay This completes the proof for our first result So let me just summarize We have shown that succinct arguments any succinct argument in the random protocol model implies an iop with corresponding parameters If the snar was too good to begin with the iop has too high sourness Which implies a fast algorithm for threesat Which possibly does not exist. So this gives barriers for the query complexity of the verifier In snar's and the random protocol model And let me end with an open problem Another very important complexity measure is the argument size Okay, the argument size of these snar's and We ask the question can our techniques be used to lower bound the argument size of any snar in the random protocol model And we actually believe the answer should be yes Thank you very much