 This talk is about a new family of zkSNARCs, which we call Spartan. Before I describe Spartan, let's recall what a zkSNARC is. A zkSNARC is an argument of knowledge, meaning that it's a protocol between a proer and a verifier. In this protocol, the proer wants to convince the verifier that it knows a witness to an NP statement by producing a proof. Specifically, given a circuit C with public input x, the proer wants to prove the knowledge of W such that the circuit C is satisfiable. Additionally, it's a zero-knowledge argument, meaning that the proof does not reveal anything about the witness beyond what is implied by the statement. A zkSNARC is non-interactive, meaning that the proer can produce its proof without interacting with a verifier. Finally, a zkSNARC is succinct. There are two forms of succineness. First, the size of the proof is sublinear in the size of the statement. Second, the cost of verifier proof is also sublinear in the size of the statement. We are interested in this primitive because there are many applications in practice. There are many approaches to build a zkSNARC in the literature, starting with the works of Kilian and McCauley in the 90s. Unfortunately, they rely on PCP, so they remain too expensive to be used in practice. A breakthrough result in this area was provided by the work of GGPR. The scheme supports proving the satisfiability of arbitrary circuits. More importantly, the scheme features near optimal asymptotics with good constants. Unfortunately, a major problem with the scheme is that it requires a per-circuit trusted setup to produce public parameters. The setup is trusted because it requires a trapdoor that must be kept secret to ensure soundness. This problem has motivated another class of works called zkSNARCs without trusted setup. There are several schemes in this class. Some of them even achieve better performance than GGPR-derived schemes. Unfortunately, these existing schemes that can support arbitrary circuits are a succinct verifier but not both. For example, HIRAX incurs a sublinear verification cost but it is restricted to data parallel circuits in a layered form. Similarly, STARK supports a succinct verifier, but it requires a sequence of repeated subcircuits. On the other side, ligero bulletproofs and Aurora target arbitrary circuits, but the verifier incurs costs that are linear in the size of the statement. In contrast, our work spotter can simultaneously support arbitrary circuits and a succinct verifier. This is actually very challenging because arbitrary circuits by definition have no structure. Also, the verifier must know the statement that it's verifying. What this means is that verification costs must be at least linear in the size of the statement. Spartan avoids this problem by pre-processing circuits without employing secret trapdoors. In particular, the verifier retains a short cryptographic commitment to the statement which we refer to as a computation commitment. Creating computation commit takes time linear in the size of the statement but it's amortized. This amortization is similar to that of ggpr. In more detail, Spartan is a new family of zk-SNARKs that supports arbitrary circuits. Specifically, they support the rank 1 constraint satisfiability which generalizes arithmetic circuit satisfiability. Spartan includes a new recipe for constructing zk-SNARKs which combines the sum-check protocol with polynomial commitments and computation commitments. By using this recipe, we design four zk-SNARKs. These schemes are not only asymptotically efficient but they're also concretely efficient. We implement a member of this family in about 8,000 lines of rust and compare it with five prior zk-SNARKs. We find that Spartan offers the fastest proer and verifier. Its proofs are shortest except when compared to bullet proofs but bullet proofs incur slower verification both asymptotically and concretely. Spartan also unifies different strands of theory from the perspective of zk-SNARKs. For example, with the work of Kilian and Mikali, we can combine short pcps of BFLS with miracle trees to obtain zk-SNARKs but these zk-SNARKs are not concretely efficient. They also achieve sublinear verification costs only for uniform circuits. Spartan can be seen as a way to compile the short pcps to zk-SNARKs by employing more powerful cryptographic machinery namely polynomial commitments and computation commitments. The resulting SNARKs are both concretely efficient and can support arbitrary circuits. Similarly, Spartan can also be seen as a way to compile two prover MIPs to zk-SNARKs. Prior compilers to achieve this use fully homomorphic encryption. So the resulting SNARKs are concretely inefficient and they only produce designated verifier proofs. Whereas Spartan produces publicly verifiable proofs that are also concretely efficient. Finally, Spartan can also be seen as a way to compile the doubly efficient interactive proofs of GKR. Prior compilers result in zk-SNARKs for low-depth uniform circuits. Whereas Spartan produces zk-SNARKs for arbitrary circuits without any depth or structure limitations. The rest of this talk is in two parts. First I'll provide an overview of Spartan and then I'll describe some experimental results. Spartan's foundation is the SUMCHEC protocol which is a seminal interactive proof protocol for. It's a proof system for proving statements of the form depicted on the slide where G is a multivariate polynomial over a finite field. This proof system does not require a trusted setup. It can also be made zero-knowledge and non-interactive using existing compilers. Unfortunately it does not lead to a zk-SNARK without trusted setup for two reasons. First we need an efficient reduction from R1CS instances to SUMCHEC instances. Second the proof system is not successful both in terms of proof sizes and verification times. The primary reason is that the verifier must evaluate this multivariate polynomial g at a random point in its domain. I'll now explain how Spartan addresses these two problems but first let's recall what R1CS is. Given three public matrices over a finite field does there exist a secret witness a z such that the equation on the slide holds. This is an NP-complete problem that generalizes arithmetic circuit satisfiability. This problem is implicit in the work of ggpr but is made explicit in subsequent works. We are interested in R1CS because there exist many compiler tool chains from high-level programs of interest to R1CS. To encode R1CS instances as SUMCHEC instances we can view the three matrices and the witness as functions. Here s is log m where m is the dimension of the matrix. In the paper we show that an R1CS instance is satisfiable if and only if the depicted sum on the slide sums to zero. Here eq is a special multilinear polynomial that evaluates to one if and only if the two arguments are equal otherwise it evaluates to zero. Also f is another polynomial depicted on the slide where a tilde is the unique multilinear extension of a. What this means is that a tilde is a multilinear polynomial that agrees with a over a boolean hyperq. To recap there were two problems so with using the SUMCHEC protocol to build z-case notes. We just described the solution to the first problem and the paper has more details on how to apply the SUMCHEC protocol to this specific polynomial. The second problem is that the protocol is not succinct. This is because the verifier has to evaluate four multilinear polynomials. Of these four one of them depends on the prover's witness and the other three depend only on the statement. At a high level our solution is to employ an extractable polynomial commitment scheme. In particular the prover commits to its witness before the SUMCHEC protocol. We then run the SUMCHEC protocol. At the end of the SUMCHEC the prover sends an evaluation along with the proof. The verifier checks the proof against the commitment and then uses the supplied evaluation to evaluate g. There are many suitable polynomial commitments in literature but the primary takeaway here is that the size of the evaluation proof and the cost to verify the proof are sub-linear in the size of the witness which itself is sub-linear in the size of the statement. Similarly for other three polynomials we can employ a polynomial commitment scheme. Since these depend only on the R1cs matrices in a preprocessing phase the verifier computes commitments to the three matrices. We refer to this commitment as a computational commitment. As in the previous slide the prover commits to its witness before the SUMCHEC protocol begins. We then run the SUMCHEC protocol. At the end of the SUMCHEC the prover sends four evaluations along with four proofs. The verifier checks all the four proofs against the corresponding commitments and then uses these four evaluations to evaluate g at a random point. Unfortunately this does not completely solve the problem because in our context the three R1cs matrices are sparse. In fact in practice the number of non-zero entries in this matrices is linear in the number of rows but the total number of entries in these matrices is quadratic in the number of rows. So if we apply existing polynomial commitment schemes the cost of creating commitments and producing evaluation proofs is quadratic in the size of the statement. So in theory this is efficient but in practice it's not. Our solution to this problem is called SPARK. It's a cryptographic compiler that transforms existing polynomial commitment schemes for multi-leaf polynomials to ones that handle sparse polynomials efficiently. At a high level there are two key ideas in SPARK. First we create commitments to dense representations of sparse polynomials. Specifically each sparse polynomial is encoded with three dense polynomials. Each dense polynomial is of size equal to the number of non-zero entries in the sparse polynomial which itself is linear in the matrix dimension. In this example we have three non-zero entries in the sparse polynomial. So in the dense representation each polynomial is of size three. The row and call polynomials contain the indices where the non-zero entries are present and the value polynomial contains the corresponding non-zero value. Our second idea in SPARK is in two subparts. First we design a linear sized uniform circuit for evaluating sparse polynomials. This circuit relies on offline memory checking techniques. Second we employ a tailored z-case knot to prove the satisfiability of this linear size circuit. So to summarize SPARK introduces a new technique to reduce R1CS instances to sum-check instances. We then employ the sum-check protocol in conjunction with polynomial commitments to get an interactive argument of knowledge. By using existing compilers we can transform the interactive argument to a NISIC which incurs linear time verification costs. We then combine such NISICs with complication commitments to get z-case nugs for R1CS. But complication commitments rely on polynomial commitments for sparse polynomials. So we design a compiler to transform existing polynomial commitments seems to ones that handles sparse polynomials efficiently. In the next part of the talk I'll describe some experimental results. We implemented a member of the SPARK family which is secure under the discrete log assumption. This took about 8,000 lines of rust. The code is open source and it's available from Github. In our experimental evaluation we focus on three evaluation metrics. We run our experiments on a Microsoft Surface Laptop 3 with 16 gigabytes of RAM. As baselines we use five schemes. Grot 16 is the state-of-the-art z-case knot with trusted setup based on ggpr. Legero, Aurora and Hyrax do not require a trusted setup but the inculinear time verification costs for arbitrary circuits. Finally fractal is a recent z-case knot that achieves sublinear verification costs for arbitrary circuits using computation commitments. Here is a graph that depicts the prover's cost for spartan and its baselines. For spartan we depict two variants, the Nizik variant and the snark variant. The key takeaway here is that spartan offers the fastest prover with speed-ups varying from a factor of two to two orders of magnitude. Here's another graph that depicts proof sizes and a spartan and its baselines. The key takeaway here is that spartan offers smallest proofs except when compared to grot 16. Here is another graph that depicts the verifier's cost under spartan and its baselines. As the proof sizes spartan's verifier is faster than all of its baselines except for grot 16. Another takeaway here is that spartan, that snark variant of spartan beats the nizik variant at about two to the 17 constraints. To summarize, spartan is a new family of z-case snarks without trusted setup. It is the first z-case snark to achieve sublinear verification costs for arbitrary circuits without requiring a trusted setup. It also features the linear time pool. Spartan introduces new techniques to achieve these results. Finally, from our concrete implementation we find that spartan offers excellent performance and proof sizes.