 Hi, my name is Jonathan Boutel and today I'm going to tell you about our work on linear time arguments with sublinear verification from tensor codes which is joint work with Alessandro Chiesa and Janskorp. Now in a setting of efficient arguments, a prover wants to convince a verifier that a statement is true, for example, that an N gate circuit over some finite field F is satisfiable and ideally the prover should convince the verifier sending only a polylogarithmic number of bits and neither the prover nor the verifier should do more than a linear amount of work in the size of the circuit. Now we can hope for even better verification time if we introduce an indexer who does a one-time preprocessing of the circuit so that the verifier doesn't have to read the circuit and then we can aim for polylogarithmic verification time but of course we still want the preprocessing done by the indexer to cost no more than a linear amount of time in the size of the circuit. Many existing argument systems use fast Fourier transforms or algebraic commitments and this is an obstacle to achieving the dream that we outlined above because if you use a fast Fourier transform on a polynomial of degree O of N, then it costs O of N log N field operations. On the other hand, if you use algebraic commitments such as the Pedersen Commitment Scheme, which requires O of N group exponentiation and appears to be a linear time operation, well actually on closer inspection, you'll see that the number of field operations that you have to do to compute a multi-exponentiation depends on the size of the group, so this isn't really a linear cost at all. Lots of exciting existing works which achieve excellent concrete efficiency actually fail to achieve the linear time call outlined above because they either use fast Fourier transforms or algebraic commitments and many of these works have eliminated the fast Fourier transform from their cryptographic arguments, but they still use algebraic commitments and still incur a linear number of group explanations. In order to achieve this holy grail, we'll need to drop the the use of algebraic commitments and fast Fourier transforms completely. There is one cryptographic argument, which was published in 2017 that does manage to achieve a linear time prover and index of complexity and has a sub-linear verification complexity and proof size. That's a square root in the size of the circuit and that work is based on an interactive oracle proof with similar parameters. Once they've designed this information theoretic interactive oracle proof, they note that you can compile it into a real cryptographic argument using a special hash function, which itself only incurs a constant computational overhead in the number of bits that you want to hash. So our challenge is to see if we can do better and reach our holy grail by constructing linear time IOPs with better query complexity and here are the results of our work. In this work, our main theorem is that for any epsilon and for any finite field with sufficiently many elements, we show that there's a point query IOP, which has a linear index of complexity and a linear prover complexity and then a sub-linear verifier complexity and sub-linear query complexity by using the linear time hash function and the same strategy as this 2017 work, we show that there is a corresponding linear time argument with very similar parameters. Our work is an interactive oracle proof. So I'm just going to briefly explain what that means. In the interactive oracle proof model, a prover will send proof oracles to a verifier who doesn't read the entire proof oracle but just has query access to each proof oracle. The prover and the verifier can interact and the verifier can send back challenge messages to the prover who can respond with more proof oracles over several rounds of interaction. And we can design interactive oracle proofs with different types of queries. For example, there are point queries which return one location of a proof oracle and our main result is going to be a point query IOP. There are also linear queries in which the verifier asks for a linear combination of elements in the proof oracle. And finally, there are tensor queries in which the verifier asks for especially structured linear combination of elements in the proof oracle where the linear combination has to be a tensor product of two different vectors. Our approach to proving the main theorem is actually not to directly construct a point query IOP but to start by designing a linear time tensor query IOP and then using a compiler which takes the tensor query IOP and a linear error correcting code and produces our point query IOP to prove our main theorem. In more detail, we start by showing that there's a tensor query IOP which has a linear prover time, linear indexer time, sublinear verification time and a constant number of queries and then using the code-based compiler, we convert this into the IOP for our main theorem. Now, note here that the tensor IOP had a constant number of queries whereas the point query IOP in our main theorem actually has a sublinear query complexity and in some sense, this is the cost of converting from tensor queries which are very powerful, more powerful than point queries, into point queries for which you can only see a single location. Now, if you look at the parameters for the inputs and output of the point query IOP that we produce, they're very closely related. In particular, the output point query IOP has indexer prover and verifier complexity which depend on the complexity of the prover indexer and verifier from the input IOP plus some additional overheads related to the encoding time of the error correcting code. In a particular, if we use a linear time encodable code C, then our code-based compiler actually preserves the complexity of the prover and the indexer and so if we use a linear time tensor query IOP as input, then the output is a linear time point query IOP. Our work's related to lots of different techniques in the field of probabilistic proofs. For example, the various linear time interactive proofs which have been published over the past 12 years or so. Holographic arguments, some of which have been published very recently, studying how the preprocessing can work, and code-based IOPs which act as compilers or give interesting IOPs of proximity. Now I'm going to say a few words about the techniques used in our code-based compiler. The first input to the code-based compiler is the tensor query IOP, in which the prover sends their proof oracles and the verifier can make tensor queries to those proof oracles. In the compiled point query IOP, we start off with a simulation phase which follows the same pattern as the tensor query IOP, except that instead of sending tensor IOP proof oracles, the prover sends encodings of those tensor IOP proof oracles to which the verifier can make point queries. And because the verifier isn't allowed to make tensor queries anymore, they send their tensor queries directly to the prover who computes the tensor query answers for themselves and sends those answers back to the verifier. This seems like it could be a problem because now we're trusting that the prover correctly computes the answers to each tensor query and sends the correct answers to the verifier. In fact, we're even trusting the prover to come up with valid encodings of tensor IOP proof oracles in the first place. So after the simulation phase, we introduce a tensor query consistency phase in which the prover verifier conducts a proximity test which checks whether the prover really sent encoded proof oracles and a consistency test which shows that the prover's tensor query answers must be consistent with the encoded proof oracles. This boils down to designing an efficient IOP of proximity to handle tasks one and two. Now, we want to be able to preserve the linear time property of an input tensor query IOP. And so we have to choose our encoding scheme very carefully to make sure that it not only preserves linear time of the underlying tensor IOP, but we have to be sure that the encoding scheme will admit efficient proximity and consistency tests. We choose tensor encodings. More precisely, we take a linear code C which doesn't need to have any special properties at all and we encode the tensor IOP proof messages using the tensor code C to the power T. If C is a linear time encodable code such as a Spiegelman code or a Drogelschei code, then the tensor code is also linear time encodable. So how does our consistency test work? Somehow we have to find a connection between tensor query answers and encodings of some piece of tensor IOP proof data. Of course, these are supposed to be connected by some tensor IOP proof oracle which has been encoded to get the tensor code word and queried to get the tensor query answer. So first, let's focus on how tensor queries can be computed from the tensor IOP proof oracles. First, I'll talk about a folding operation which is really simple. If we have a collection of different tensors or matrices or arrays A1, A2 and A3 and a vector of V1, V2 and V3, then the folding operation simply takes the linear combination of the As using the Vs. And using this folding operation, we can describe the computation of a tensor IOP query answer sequentially by folding the three-dimensional tensor proof data that you can see at the start of this slide. First with one component of the tensor query Q3 to get something two-dimensional, then with Q2 and then with Q1, and this procedure actually gives you the tensor query answer in the end. So the tensor IOP proof oracle is connected to the tensor query answer by this sequential folding operation. Now, what's about the tensor encodings? How can they be computed from the tensor IOP proof oracle? Now, by definition of the tensor encoding, we can actually consider the tensor encoding as a sequential computation too, where we encode different dimensions of this piece of tensor IOP proof data separately so we could encode horizontally first, for example, and then vertically to get our final tensor codeword. In order to perform the consistency check, we fill in an extra piece of this diagram, the green rectangle that you can see, and this is an encoding of a piece of tensor IOP proof data that's already been partially folded up, or alternatively, if you like, it's a folding of some tensor IOP proof data that's only been partially encoded. And the idea behind our consistency test is that we check consistency diagonally, so as every step we have something which has been partially folded up and less and less encoded compared with the original tensor codeword, and we want to check consistency between all of these intermediate values. In the actual IOP of proximity that we design, we make use of the fact that the folding operation and partial encodings can commute with one another, and so we check consistency between these intermediate values by encoding one and folding the other and checking that the two answers are equal to one another. At least this is the basis of the verification checks. In the actual consistency check IOP of proximity, the approval will send all of these intermediate values on the diagonal to the verifier, and now what the verifier wants to check is the collision between these encoding and folding operations. They want to check that those two values are equal, but this has to be done using just a small number of queries. So instead of reading the entire array in every case, the verifier makes spot checks using only a few queries. They just query these stripes of each of the arrays, and then the distance properties of the code C guarantee that any inconsistencies in the computation of the tensor query answer are caught by the verifier. Now, if we use Spiegelman codes or Drucker-Scheich codes, which are encodable in linear time, then since the original tensor query IOP had a linear amount of proof data and the codes are linear time encodable, all the steps at the top cost a linear amount of time for encoding, as well as for this folding operation. Now, after the first folding step, the prover is only dealing with proof data which has a sublinear size, and so the encoding and folding operations associated with the bottom part of the consistency test are sublinear. As for the proof size and the verifier complexity, the verifier only ever queries these one-dimensional stripes of each array. So for the running example on the board, this leads to a query complexity and a verifier complexity of O of n cubed. Now, of course, everything I've shown you generalizes to t dimensions and to approve size and verifier complexity of O of n to the power 1 over t in that case. Now, I'd like to conclude the talk by giving a summary of the approach used to prove our main theorem and describing once more our main results. In our paper, we show that given any tensor IOP and any linear code, we can use our code based compiler to convert the tensor IOP into a point query IOP. And then given any collision resistant hash function, we can compile the point query IOP into a cryptographic argument which has sublinear proof size. Now, if we instantiate the tensor IOP with our own linear time tensor IOP and we take linear time encodable codes such as the code Spiegelman or Drucker-Schei as inputs to our code based compiler. And finally, if we take linear time computable hash functions, then what we get in the end is a linear time computable cryptographic argument with sublinear proof size. Thank you very much for listening.