Spartan
Presentation: https://www.youtube.com/watch?v=adsGo7DvkJ8
Introduction
Various constructions for zkSNARKs over R1CS exist—GGPR’s approach, for instance, achieves proving time and proof size, but requires a per-statement trusted setup with a large common reference string. Recent transparent zkSNARKs, such as Hyrax, STARK, Aurora, Ligero, and Bulletproofs, eliminate the need for trusted setups yet often impose limitations like circuit restrictions or linear verification costs. In Spartan, a new zkSNARK for arbitrary R1CS instances with sub-linear verification cost is introduced.
Background
Problem statement
Prior works are still lacking to achieve truly succinct SNARK without any trusted setup.
The computational model of Hyrax is layered arithmetic circuits, where the verifier’s costs and the proof sizes scale linearly in the depth of the circuit. For a depth- circuit, converting to a layered form increases the circuit size by a factor of , so Hyrax is restricted to low-depth circuits. Also, Hyrax achieves sublinear verification costs only for circuits with a uniform structure (e.g., data-parallel circuits).
STARK requires circuits with a sequence of identical sub-circuits, otherwise it does not achieve sublinear verification costs. Any circuit can be converted to this form, but the transformation increases circuit sizes by 10–1000×, which translates to a similar factor increase in the prover’s costs (ref).
Ligero, Bulletproofs, and Aurora incur verification costs.
So to summarize, there is two main challenges with achieving succinct verification:
Arbitrary circuits have no structure.
The verifier must know what statement is being proven. Because of these challenges, the verification must have complexity of at least where implies circuit size.
Spartan solution: Verifier preprocesses the circuits - without secret trapdoors to avoid any form of trusted setup.
Verifier retains a commitment to the circuit.
Preprocessing incurs costs but is amortized.
The amortized cost here implies that even though the upfront computational or resource expense might be high, when spread over a large number of operations or over time, the average cost per operation becomes more manageable or efficient.
Succinct interactive arguments of knowledge
From this paper, we adopt the notation to denote the random variable representing the local output of machine when interacting with the machine on common input , when the random tapes for each machine are uniformly and independently chosen, and and has auxiliary inputs and , respectively.
Let denote a pair of PPT algorithms and denotes an algorithm that outputs public parameters given as input the security parameter .
Definition 2.5 from the paper. A protocol between a pair of PPT algorithms is called a public-coin succinct interactive argument of knowledge for a language if:
Completeness. For any problem instance , there exists a witness such that for all , .
Soundness. For any non-satisfiable problem instance , any PPT prover , and for all , .
Knowledge soundness. For any PPT adversary , there exists a PPT extractor such that for any problem instance and for all , if , then .
Succinctness. The total communication between and is sublinear in the size of the NP statement .
Public coin. 's messages are chosen uniformly at random.
The sumcheck protocol
Using sumcheck, a prover can prove statements of the form:
We can denote the sumcheck protocol as for any -variate polynomial with degree at most in each variable. This is typically reduced to the claim and using round interactive protocol which can be denoted as
This proof system does not require a trusted setup. It can be made zero-knowledge and non-interactive with existing compilers but still cannot be used as a zkSNARK. The main two reasons for this are:
We need an efficient reduction from R1CS statements to sumcheck instances.
The proof system is not succinct (both proof sizes and verification times).
Generally, the verifier must evaluate at some random point in its domain .
Multilinear polynomial extension
Definition 2.8. (Multilinear polynomial) A multivariate polynomial is called a multilinear polynomial if the degree of the polynomial in each variable is at most one.
Definition 2.9. (Low-degree polynomial) A multivariate polynomial over a finite field is called low-degree polynomial if the degree of in each variable is exponentially smaller than .
Low-degree extensions (LDEs). Suppose is a function that maps -bit elements into an element of . A polynomial extension of is a low-degree -variate polynomial such that for all .
Multilinear extension (MLE) is a LDE where the extension is a multilinear polynomial. Given a function , the MLE of is the unique multilinear polynomial . It can be computed as follows:
Note that is the MLE of the following function:
Polynomial commitment scheme for multilinear polynomials
A polynomial commitment scheme for multilinear polynomials is a tuple of four protocols .
: takes as input (the number of variables in a multilinear polynomial); produces public parameters .
: takes as input a -variate multilinear polynomial over a finite field ; produces a public commitment and a secret opening hint .
: verifies the opening of commitment to the -variate multilinear polynomial with the opening hint ; outputs a boolean .
is an interactive public-coin protocol between a PPT prover and verifier . Both and hold a commitment , a scalar , and . additionally knows a -variate multilinear polynomial and its secret opening hint . attempts to convince that . At the end of the protocol, outputs .
Protocol Explanation
R1CS as a multivariate function
Theorem 4.1 from the paper. For any R1CS instance there exists a degree-3, -variate polynomial such that if and only if there exists a witness such that (except for a soundness error that is negligible in ). Here, is the upper bound on the non-zero entries in the matrices.
If we denote for the sake of simplicity, for a given , we can view them as functions with the following signature: . Furthermore, given a witness to instance , let . Then we can also view as a function mapping .
We define that can be used to encode as:
Lemma 4.1 from the paper. if and only if .
Proof. This follows from the definition of (Section 2.1) and of .
Functions to polynomials
Unfortunately, is a function, not a polynomial, so it cannot be directly used in the sumcheck protocol. But, consider its polynomial extension :
Lemma 4.2 from the paper. Then, if and only if .
Proof. For any , , so the result follows from Lemma 4.1.
Since is a low-degree multivariate polynomial over in variables, a verifier could check if using the sumcheck protocol. But the sum being 0 doesn't exactly mean that each of them was 0 since some of the terms in the sum may cancel each other out. This is addressed using a prior idea from LegoSNARK by taking:
Observe that:
is same as over the boolean hypercube.
is -variate multilinear polynomial
, . Therefore, Since it has solutions, it has to be a 0 polynomial over the if and only if .
This implies that is zero-polynomial if and only if and to check if is a zero-polynomial, its enough with a single random challenge where (this will introduce soundness error .
Proof of Theorem 4.1. For a given R1CS instance , define, , so . Observe that is a degree-3 -variate polynomial if multilinear extensions of , and are used in . In the terminology of the sumcheck protocol, , , and . Furthermore, if , if and only , —except for soundness error that is negligible in under the assumptions noted above (Lemma 4.3). This combined with Lemma 4.2 implies the desired result.
Theorem 5.1 from the paper. Given an extractable polynomial commitment scheme for multilinear polynomials, there exists a public-coin succinct interactive argument of knowledge where security holds under the assumptions needed for the polynomial commitment scheme and assuming is exponential in and the size parameter of R1CS instance .
Theorem 4.1 established that for to verify if an R1CS instance is satisfiable, it can check if . By using the sumcheck protocol, we can reduce the claim about the sum to where , so needs a mechanism to evaluate —without incurring communication from to .
So let's denote it as the following:
Now, the prover can make three separate claims and verifier can check:
Of course, the verifier still needs verify the claims and to do so, it can run three independent instances of sumcheck protocol but instead, we can use a prior idea to combine these into a single claim:
Verifier samples and computes .
Let . Then:
Verifier uses sumcheck to verify:
Still there are some problems left. To verify the last sumcheck , the verifier has to evaluate at some random :
Observe that the only term in that depends on the prover’s witness is . This is because all other terms in the above expression can be computed locally by using in time (Section 6 in the paper discusses how to reduce the cost of those evaluations to be sub-linear in ).
To evaluate , does the following. WLOG, assume . Thus, by the closed form expression of multilinear polynomial evaluations, we have:
If you recall that and :
Similar technique is also used by vSQL under the section Avoiding Relaying the Inputs.
Putting them together for NIZK
We assume that there exists an extractable polynomial commitment scheme for multilinear polynomials .
and send to .
and send to
Let .
Sample
Sumcheck #1:
Compute and send .
Abort with if
Sample and send them to .
Let .
Sample
Sumcheck #2:
and send to .
if , abort with .
Abort with if
return
Cost Analysis

Prover:
for each sumcheck instances
Cost of and for -variate multilinear polynomial .
Verifier:
for each sumcheck instances
Cost of for -variate multilinear polynomial
to evaluate at
Communication cost:
for each sumcheck instances
The size of the commitment to and the communication in

Computation commitments: zkSNARK from NIZK
The protocol described above is not succinct yet since the verifier incurs costs linear in the size of the R1CS instance to evaluate at on step 16. We can get around this by introducing an offline preprocessing step for . In this offline step, with access to non- portions of an R1CS instance executes the following, where and PC is an extractable polynomial commitment scheme for multilinear polynomials.
After encoding, retains the commitments and instead of evaluating at step 16, it verifies the opening proof of at . Unfortunately, existing polynomial commitment schemes are not efficient enough to be practical. Since, the number of variables in is , existing polynomial commitment schemes incur cost for the prover side. Furthermore, in schemes such as Hyrax-PC, incurs costs. This problem is addressed by introducing a new cryptographic compiler to transform an existing extractable polynomial commitment scheme for dense multilinear polynomials to one that can efficiently handle sparse multilinear polynomials.
Experimental Results
According to the table below, which is taken from the paper, among the proof-succinct NIZKs, SpartanNIZK is 100× faster than Hyrax, 113× faster than Aurora, and 22× faster than Ligero at constraints. The commitment scheme used for this benchmark is Hyrax-PC over curve25519 (ref).

References
Written by BATZORIG ZORIGOO from A41
Last updated