 Our main result is a new sessing zero-knowledge argument where the running time and more importantly, the space of the pro-word is almost optimal. I am Prathik and this is joint work with Justin Holgrim, Alon Rosin, Ron Rockbloom and Alex Block who will take over for the second part of the talk. Let's begin by talking about arguments. An argument for a language L, accepted by some non-uniform random access machine or RAM for short is an interactive protocol between a pro-word and a verifier where the pro-word given input and instance from the language along with the witness attempts to convince a verifier that the instance is in the language. Standard arguments have two properties, completeness and soundness. But more relevant to this talk is a sickness which requires the proof size which is the transcript of the interaction to be significantly smaller than the running time of the RAM machine. Zero-knowledge snarks or ZK snarks for short which are the focus of this work are succinct arguments which in addition have a number of interesting properties like zero-knowledge and non-interactivity. ZK snarks enable a number of exciting applications like delegating computations to the cloud, cryptocurrencies with interesting properties like succinctness, privacy and a number of theoretical and practically relevant cryptographic protocols. The key challenge in scaling general purpose ZK snarks is the high complexity, computational complexity of generating proof strings which has been the focus of recent line of research. In terms of time complexity of the pro-word, we now know of ZK snark constructions where pro-words running time is both asymptotically and concretely optimal. But for all of these constructions, the pro-word ends up requiring space proportional to the running time of the RAM machine rather than its space. And this is in part because the pro-word arithmatizes the RAM program into a T-size circuit which it ends up storing in memory. This space in efficiency severely limits the size of statements we can prove using current constructions. As the step towards addressing this key challenge in this work, we focus on constructing ZK snarks where we want the pro-word running time and space to be as close to the time and space of the underlying RAM program. From now on, we will refer to these as complexity preserving ZK snarks. Certain applications impose stricter efficiency requirements even on the verifier which is clearly desirable, but our primary focus will be on pro-word efficiency. I want to emphasize that time and space of the pro-word are both very important and would be unfair to trade one over the other. But time overheads are often easier to manage. One can let the pro-word run for as much time as possible. But memory, comparatively, memory overheads are challenging. For example, expanding memory is non-trivial due to the hierarchical nature of memory architecture in modern computer systems. And often the overall running time ends up depending on parameters like cache efficiency, which are hard to tame. Hopefully by this point, you are convinced that the space of the pro-word is valuable resource to consider. And with that, now let's talk about what's known about building complexity preserving ZK snarks. The first approach is to compile information theoretic proofs like PCBs with cryptographic tools. An instantiation of this paradigm was first developed by Bitansky and Kiesa and later Holgram and Rockbloom, where the verifier encrypts PCB queries using homomorphic encryption, which the pro-word homomorphically transforms into encryptions of corresponding PCB responses. However, these schemes suffer from two limitations. One, FHG operations are concretely slow. Two, even more undesirable is that the verifier needs to keep the underlying FHG keys private for ensuring soundness. And hence, reserving proofs can only be verified by the specific verifier who is in possession of the keys. A feature undesirable for applications like blockchain, where we would like public verifiability. The only known approach to construct publicly verifiable complexity preserving ZK snarks is based on recursive composition introduced by Bitansky et al, wherein an inner snark is used to incrementally update state and proof in a verifiable manner. While recursive composition enables several powerful cryptographic primitives like IVC and PCBs, the concrete efficiency of the resulting snarks is rather poor due to the non-blackbox usage of the verifier. Even on the security front, the foundations are far from well understood. For example, recent works give constructions making non-blackbox use of hash functions, which however are modeled as random oracles in the proofs. So in this work, we ask whether we can construct ZK snarks which are publicly verifiable, complexity preserving, possibly from well-studied assumptions. We answer this in the affirmative by showing such a scheme in the random oracle model based on the hardness of discrete log. Specifically for language L accepted by time t and space s non-uniform RAM program, our proof length is polylogarithmic in t. The prover time and space incur only polylogarithmic in t overheads over t and s respectively. Our verifier requires only polylogarithmic space but runs in linear time. This limits our scheme to be used for applications like delegation, but is well-geared towards applications requiring zero knowledge. Finally, our scheme requires a CRS being set up beforehand and this contains t group elements, each defined by other random oracle, enabling prover and verifier to have random access to this t-sized list of generators without storing in memory. At a high level, our approach to constructing snarks follows a number of recent works which constructs a public coin succinct argument by compiling polynomial interactive oracle proofs or IOPs for short, which are information theoretic with polynomial commitments, which are cryptographic commitments. But even using polynomial commitments with optimal parameters, the prover of the resulting argument can at best be optimal in running time but will not be space efficient and hence not complexity preserving. This is true even if we start with complexity preserving IOPs. The main issue to achieving space efficiency is that the prover requires the committer to run in space sublinear in the size of the polynomial which seems impossible as the polynomial is the committer's input. Our key insight here is to note that the polynomials that arise in our context, in fact, can be generated as a stream in small space. We leverage this observation and initiate the study of streaming model for polynomial commitments and design a space efficient scheme in the random oracle model. Using the scheme in the transformation gives us complexity preserving arguments which are then compiled into snarks using Fiat-Chamis transform. For the rest of this talk, we will focus on our new polynomial commitment. So what are polynomial commitments? Polinomial commitment schemes were introduced by Cate, Zeburucha, and Goldberg are cryptographic commitments that allow to commit to polynomials. More formally, like standard commitments, they have a set of algorithm that generates public parameters, a commitment algorithm that generates commitment C to the polynomial say F and open algorithm that decommits the commitment to the polynomial. Additionally, there is an evaluation algorithm or more generally, an interactive protocol where in the committer sends evaluations Y of the polynomial F on points of verifiers choice and proves that Y is indeed F of X. These proofs are generally interactive. Generally, the commitment C and the proofs are required to be short, significantly smaller than F. And in terms of security, we require that commitments bind F, the polynomial, and the proofs produced by the eval phase be an argument of knowledge or satisfy extractability. Our focus is on multilinear polynomials, which are multivariate polynomials having degree exactly one in each variable. And these show up extensively while constructing arguments. So what's known here? A number of schemes providing trade-offs between proof size, prove time, verify time and assumptions. For example, bullet proofs, the first row, gives a scheme from discrete log with log in size proofs and order and prove and verify time where capital N denotes the size of the little n-variate multilinear polynomial. But the key question is the space of the prover. Certainly it has to be omega n as it takes as much space to even store the polynomial. But the center requirement for our complexity preserving snark requires the committer to only use logarithmic in n space which seems paradoxical. As mentioned earlier, to resolve this, we will have to revisit how the committer is given access to the polynomial. And to tell you more about it, I will hand it over to Alex. So, as was just stated, we are going to revisit p's access to the polynomial f. To do so, we are going to introduce the streaming model for multilinear polynomials. In this model, we are going to give the committer p multi-pass streaming access to the size capital N description of the multilinear polynomial f. So if we look at this picture we had before, the committer p, instead of having f as explicit input, we are going to instead give the committer p access to the stream of evaluations of f on the Boolean hypercube. And note that this uniquely defines the multilinear function f for any point on the field f. Okay, so what does streaming access look like? Well, at any particular time step, the committer p can ask for the next evaluation in the sequence. So to start, the committer is going to receive f zero then f zero zero one dot dot dot all the way up to f one one one. And in this model, since we are saying one time step corresponds to querying one element of the stream, one pass over the entire stream is going to correspond to linear time. So given this model, let's try and do a very basic task of evaluating f at any point x in the field. So we are going to understand the complexity of this. So for those familiar with multilinear polynomials, this is no surprise, but the function f is uniquely defined by this inner product. It's an inner product between a vector called yf and a vector called zx. Now the vector yf is something we've seen already. This is exactly the series of evaluations on the Boolean hypercube, which we have given the committer streaming access to. This is great. Now what about the vector zx? I'm not going to give the details of this vector, but just note that given x, any element of this vector can be computed in logarithmic time and logarithmic space, which is wonderful for our purposes. So now then, what is the complexity of computing f of x? Well, it's going to take exactly one pass over the stream yf to compute the same inner product. The space usage is going to be logarithmic number of elements in f, and the main dominating cost of computation is going to be the number of f multiplications, which is n log n. Okay, great. So we've done this very basic task in this streaming model of computing f of x. What else can we do? Well, the streaming model allows us to obtain our main technical result. So if we assume discrete log is hard for the group g, then there is a multi-linear polynomial commitment scheme in the random oracle model, such that the following happens. If we give the committer multi-pass streaming access to the sequence yf, we give all of these algorithms the setup, the commitment algorithm, the open algorithm, the eval algorithm, access to the random oracle. Well, then we're able to obtain a very succinct scheme where the commitment is of size a single group element, and the proof has logarithmic number of field and group elements. We obtain security via discrete log. So this is both binding and an argument of knowledge. And finally, we obtain great prover and verifier runtimes and space usage. So here we have n log n time for both receiver and committer, and the space usage is fantastic. We have log n. I just wanna note that the time here for both parties includes the number of random oracle queries, which is n log n, and the time of the committer p also includes the number of passes over the stream, which is log n. Okay. So for the remainder of the talk, we are going to discuss how we implement this space efficient scheme in our streaming model. We are going to examine both the commitment phase and the evaluation phase, beginning with the commitment phase now. So in the commitment phase, we have a random oracle RO floating up in the sky. We have the setup algorithm and we have the commitment algorithm. And of course, p is given streaming access to f on the Boolean hypercube. So what's the first thing that happens? Well, the setup samples generators GB according to the random oracle. Now, in practice, you should think the space to access such GBs is roughly equivalent to the space to evaluate a hash function, say shot 256. Okay. Now that we have our setup complete, how do we commit? We're just gonna use Peterson commitments. So Peterson commitment says, take the ith generator and raise it to the ith element of your sequence. And this unique, this defines the Peterson commitment. Okay. And again, if discrete log is hard in G, then this commitment binds f. So this is a more complicated function. We are going to now want to understand the complexity of computing C in the streaming model. And it's gonna be wonderful. So the number of passes over the stream yf is a single pass. I hope you can see this via, we have streaming access to f and random oracle access to G. Therefore, it's fairly straightforward to see how we can do this in one pass over f. The space is also super, super efficient. It's gonna be a constant number of spaces. This is just a tracker for the value C and a temporary value to compute the next GI to the fi. And as is defined in the Peterson commitment, we're gonna use n generators, which corresponds to n random oracle queries. And the number of operations here is dominated by the number of group exponents, which is also capital N. Okay, great. Moving on to the evaluation phase. Suppose we have this set of generators fixed, defined by the random oracle, and a commitment C already given to the verifier. So the evaluation phase, as a reminder, lets the verifier V open the point, open the polynomial f out of specific point x. So V sends over their value x and P responds with the claim y, which is the purported value of f of x. P and V then engage in a protocol for the following statement. I know a vector y such that this yf is consistent with C and the inner product of yf with zx, which is publicly known to everybody, is equal to the purported value little y. This is nothing new. This is just an inner product statement and there are wonderful proof schemes out there that allow us to prove such statements in the discrete log setting. In particular, there's a bootle et al, Buns et al and Wabi et al. And if we focus on the result of Buns et al, the well-known bullet proofs argument system, we obtain a proof size of log n, prover verifier time of linear and n, and logarithmic number of rounds. So one might wonder, can we just plug and play our streaming model with bullet proofs to obtain a space-efficient evaluation phase? Well, no. Unfortunately, naively just using bullet proofs will either require linear space or require linear passes over the stream. And as was mentioned before, each pass over the stream takes linear time, so this would result in a quadratic time, commit or p. So this is no good, but let's take a closer look at where this inefficiency comes from. So at the heart of bullet proofs is a two-move reduction folding phase. So at the core, bullet proofs takes a state, proving a statement of size n, and reduces it to proving a statement of size n by two. Okay, this reduction is given via a folding, quote-unquote, a folding of a vector. So if we take a size eight vector, let's examine what the bullet proofs protocol does. To define the first element of the sequence, it's gonna do a very natural folding. So one of the most natural ways to fold an n-size vector into a size n by two vector is to take the left half of the vector and fold it with the right half of the vector, where folding here means just taking linear combinations of point-wise linear combinations of these elements. So the first element here is defined by the first element of the left half of the sequence and the first element of the right half of the sequence, and so on and so on and so on, continuing recursively down the tree. This is what we refer to as the MSB folding, since folding elements via left-right vector corresponds to folding elements that differ in their most significant bits. So let's look at the complexity of simulating the n by two stream in small space, given streaming access to the size n stream. So the total passes here, as was hinted at before, is gonna be omega n. Why? Well, again, this is due to the very nature of the folding. We fold the left half of the vector with the right half of the vector. So to even compute the first element of the n by two sequence in this picture, y zero zero prime, we need the elements y zero zero zero and y one zero zero. And then in order to compute the next element, we have to restart the stream in order to get access to y zero zero one and so on and so forth. This is gonna result in a linear number of passes over the initial stream yf, which is gonna result in a quadratic time prover, which is not ideal for our situation. This will not give us complexity preserving arguments. So how do we fix this? Well, we do another very natural folding idea. Rather than folding left half right half, we're going to fold even odd pairs. So as you can see, the first element of the sequence is defined by y zero zero zero and y zero zero one, which correspond to the first element in the even half of the vector and the first element in the odd half of the vector and so on and so on and so on recursively down the tree. And this is what we refer to as the LSB folding because folding via even odd corresponds to folding elements via differing least significant bits. So again, let's examine the complexity of simulating the stream of size n by two, given this folding and given streaming access to the stream of size n. The total number of passes over yf is gonna be exactly one and this can be seen clearly by the tree we have pictured above. And in fact, for any depth k simulating the kth stream is going to require a single pass over the initial stream yf. This is fantastic. What this lets us achieve is a prover that runs in logarithmic space and n log n time. And this is sufficient for our application. With this, we are able to obtain complexity preserving zk snarks. Okay, so in summary, we introduced the streaming model for multi-linear polynomials. With this model, we obtain a space efficient polynomial commitment scheme for multi-linear polynomials in the random oracle model. We achieve this by using Peterson commitments and the bullet proofs in our product argument for our commitment and evaluation algorithms, respectively. And the key insight here in using bullet proofs is that in the streaming model, there's a space efficient implementation of this argument if we modify the core step of their protocol. This modification corresponds to folding vectors via even odd halves rather than left right halves. And then finally, by compiling our scheme with a complexity preserving clover IOP of Bloomberg et al, we obtain complexity preserving snarks and using, sorry, complexity preserving arguments and using the Fiat-Chemery transformation and standard techniques, we obtain complexity preserving snarks. And with that, the main portion of the talk is complete but for the next few minutes, I will briefly describe the clover IOP and how we obtain space efficient arguments in a bit more detail. So the clover IOP, which is due to Bloomberg et al, takes a public input. It's a time t, a space, time t, space s, RAM program M and an input X. The prover is given a witness W additionally as input such that M X W equals one. So the first thing that happens is the prover takes its machine and via an adaptation of the RAM to circuit transformation of Ben-Sassin et al computes an arithmetic circuit C M which describes the computation M X W. This induces a wire transcript F which gives exactly the wire values which is then sent to the verifier as an oracle to the multilinear extension of F. What follows is interaction via the classical sum check protocol over some polynomial H of F such that H of F is identically zero on the Boolean hypercube if and only if F is a correct wire transcript. The sum check induces some claims of the form Y equals F of R for some number of points R and then V figures out these claims if these claims are true by querying the oracle. So how do we obtain our argument scheme? We're going to do a classic compilation of an IOP plus a polynomial commitment scheme. To do so, first we get rid of the oracle to the multilinear extension of F and replace it with a commitment to the function F. So here we're going to use our, our polynomial commitment scheme using our commitment. The sum check remains the same but now V can't query the oracle because the oracle doesn't exist. So we replace this with the evaluation protocol. Now, if you remember for R space efficient implementation we need streaming access to the function F. Otherwise we will not have a space efficient implementation. Well, in fact, the Clover IOP is what I'll call a streaming IOP. In fact, this wire transcript is streamable value by value on the Boolean hypercube in time T poly log T and space S poly log T. This together with our space efficient polynomial commitment scheme gives us complexity preserving arguments. And then again via the Fiat-Schemar transformation and standard techniques we obtain complexity preserving ZK snarks. And with that, the talk is concluded. Thank you very much.