1 Introduction

We revisit the problem of designing zero-knowledge succinct non-interactive arguments of knowledge (zkSNARKs)  [22, 48] for the complexity class NP: they enable a computationally-bounded prover to convince the membership of a problem instance in an NP language by producing a proof—without revealing anything besides the validity of the statement. Furthermore, the proof size and the verifier’s costs are sub-linear in the size of the statement. We are motivated to design zkSNARKs because they enable many applications that involve various forms of delegation of computation for scalability or privacy  [12, 26, 29, 31, 38, 39, 41, 46, 59, 61, 70, 73,74,75,76,77,78,79, 87].

Specifically, we are interested in zkSNARKs that prove the satisfiability of R1CS instances over a finite field \(\mathbb {F}\) (an NP-complete language that generalizes arithmetic circuit satisfiability; see Sect. 2.1 for details): given a problem instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\), we desire a proof that demonstrates the knowledge of a witness w such that \(\mathtt {Sat}_{\text {R1CS}}(\mathbb {x},w) = 1\).Footnote 1 We desire zkSNARKs for R1CS because there exist efficient toolchains to transform high-level applications of interest to R1CS  [13, 15, 18, 31, 60, 70, 73, 77, 83].

There are many approaches to construct such arguments in the literature, starting with the work of Kilian  [58] who provided the first construction of a succinct interactive argument protocol by employing probabilistically checkable proofs (PCPs)  [5,6,7, 42, 44, 54] in conjunction with Merkle trees  [67]. Micali  [68] made a similar protocol non-interactive in the random oracle model, thereby obtaining the first zkSNARK. Unfortunately, the underlying PCP machinery remains extremely expensive for the prover and the verifier—despite foundational advances  [14, 19,20,21].

Thus, the first works with an explicit motivation to make proof systems practical  [38, 74, 76, 77, 79] refine and implement interactive protocols of Ishai et al.  [55] and Goldwasser et al.  [49], which do not require asymptotically-efficient PCPs. The principal downside is that they achieve practicality for only a restricted class of NP statements.

Gennaro, Gentry, Parno, and Raykova (GGPR)  [47] address the above issue with a new characterization of NP called quadratic arithmetic programs (QAPs). By building on the work of Ishai et al.  [55], Groth  [50], and Lipmaa  [65], GGPR construct a zkSNARK for R1CS in which the prover’s running time is \(O(n\log {n})\), the size of a proof is \(O(1)\), and the verifier incurs \(O(|io|)\) computation to verify a proof, where n is the size of the statement, and io denotes the public input and output. Unfortunately, GGPR’s zkSNARK requires a per-statement trusted setup that produces an \(O_\lambda (n)\)-sized structured common reference string and the trapdoor used in the setup process must be kept secret to ensure soundness. Relying on such a trusted setup is often infeasible, especially for applications that do not have trusted authorities. There exist several advances atop GGPR, but they retain a trusted setup  [15, 18, 23, 51, 52, 70], or require interaction  [75].

The above state of affairs has motivated another class of works, called transparent zkSNARKs, that aim to eliminate the requirement of a trusted setup. They prove security in the random oracle model, which is acceptable in practice. First, Hyrax  [84] extends a line of work  [38, 78,79,80,81,82] that refines the doubly-efficient interactive proofs (IPs) of Goldwasser et al.  [49]. Second, STARK  [10] and Aurora  [16] build on interactive oracle proofs (IOPs)  [17, 71]. Third, Ligero  [3] builds on the “MPC in the head” paradigm  [56]. Fourth, Bulletproofs  [32] builds on the work of Bootle et al.  [27].

Unfortunately, they face the following problems.

  • The computational model of Hyrax  [83] is layered arithmetic circuits, where the verifier’s costs and the proof sizes scale linearly in the depth of the circuit. Converting an arbitrary circuit into a layered form can increase its size quadratically  [49],Footnote 2 so Hyrax is restricted to low-depth circuits. Also, Hyrax  [83] achieves sub-linear verification costs only for circuits with a uniform structure (e.g., data-parallel circuits).

  • STARK  [10] requires circuits with a sequence of identical sub-circuits, otherwise it does not achieve sub-linear verification costs. Any circuit can be converted to this form  [13, 15], but the transformation increases circuit sizes by 10–1000\({\times }\), which translates to a similar factor increase in the prover’s costs  [83].

  • Ligero  [3], Bulletproofs  [33], and Aurora  [16] incur O(n) verification costs.

Our work addresses these problems.

1.1 Summary of Contributions

This paper presents a new family of zkSNARKs, which we call Spartan, for proving the satisfiability of NP statements expressed in R1CS. Spartan offers the first transparent zkSNARK that achieves sub-linear verification costs for arbitrary NP statements.Footnote 3 Spartan also offers zkSNARKs with a time-optimal prover, a property that has remained difficult to achieve in nearly all prior zkSNARKs.

In a nutshell, Spartan introduces a new public-coin succinct interactive argument of knowledge where the verifier incurs sub-linear costs for arbitrary R1CS instances by employing computation commitments (which we describe below). Our argument makes a black box use of an extractable polynomial commitment scheme in conjunction with an information-theoretic protocol, so its soundness holds under the assumptions needed by the polynomial commitment scheme (there exist many polynomial commitment schemes that can be instantiated under standard cryptographic assumptions  [32, 84, 86]). The interactive argument is public-coin, so we add zero-knowledge using existing compilers  [84, 85, 88], which themselves build on prior theory  [9, 35, 40]. We then make the resulting zero-knowledge argument of knowledge non-interactive in the random oracle model using the Fiat-Shamir transform  [45]. Since our interactive argument employs a polynomial commitment scheme as a black box, we obtain a family of zkSNARKs where each variant employs a different polynomial commitment scheme.

In more detail, Spartan makes the following contributions.

(1) A new family of public-coin succinct interactive arguments of knowledge. Our core insight is that the sum-check protocol  [66], a seminal interactive proof protocol (where soundness holds unconditionally), when applied to a suitably-constructed low-degree polynomial yields a powerful—but highly inefficient—interactive proof protocol, but the inefficiency can be tamed with new techniques. Specifically, we introduce three techniques (Fig. 1 offers a visual depiction of how these techniques work together):

Fig. 1.
figure 1

Overview of our techniques for constructing zkSNARKs.

  1. (i)

    Computation commitments, a primitive for creating succinct cryptographic commitments to a mathematical description of an NP statement, which is critical for achieving sub-linear verification costs.

    Achieving sub-linear verification costs appears fundamentally unrealizable because the verifier must process an NP statement for which the proof is produced before it can verify a purported proof. Our observation is that this cost can be made sub-linear in the size of an NP statement by introducing a public preprocessing step.

    Specifically, our observation is that when verifying a proof under our interactive argument, the verifier must evaluate a low-degree polynomial that encodes the NP statement, which incurs \(O(n)\) costs to the verifier. Our primitive, computation commitments, enables verifiably delegating the necessary polynomial evaluations to the prover. Specifically, in Spartan, the verifier reads an R1CS instance (without the io component) for which the proof is produced and retains a short cryptographic commitment to a set of sparse multilinear polynomials that encode the R1CS structure. Later, when producing a proof, the prover evaluates the necessary polynomials and proves that the sparse polynomial evaluations are consistent with the commitment retained by the verifier. While the verifier incurs \(O(n)\) cost to compute a computation commitment, the cost is amortized over all future proofs produced for all R1CS instances with the same structure. This amortization is similar to that of GGPR  [47]. However, unlike GGPR’s trusted setup, creating a computation commitment does not involve any secret trapdoors. Section 6 provides details.

  2. (ii)

    spark, a cryptographic compiler to transform any existing extractable polynomial commitment scheme for multilinear polynomials to one that efficiently handles sparse multilinear polynomials. Using the compiler, we obtain schemes with time-optimal costs for both creating commitments to sparse multilinear polynomials and to produce proofs of evaluations of the committed polynomials. This compiler is crucial for achieving a time-optimal prover in Spartan. In more detail, spark employs an existing extractable polynomial commitment scheme as a black box, and uses it in conjunction with a special-purpose zkSNARK and a carefully-constructed circuit (that employs offline memory checking techniques  [4, 24, 37, 43, 73]) to efficiently prove evaluations of sparse multilinear polynomials. Section 7 provides details.

  3. (iii)

    A compact encoding of an R1CS instance as a degree-3 multivariate polynomial that can be decomposed into four multilinear polynomials. The decomposition into multilinear polynomials is critical for achieving a time-optimal prover in the sum-check protocol by employing prior ideas  [78, 85]. Section 4 provides details.

(2) An optimized implementation and experimental evaluation. We implement Spartan as a library in about 8,000 lines of Rust. We use the library to build a transparent zkSNARK that employs an extractable polynomial commitment scheme due to Wahby et al.  [84] where soundness holds under the hardness of computing discrete logarithms. Our experimental evaluation demonstrates that, among schemes without trusted setup, Spartan offers the fastest prover with speedups of 36–\(152{\times }\) depending on the baseline, produces proofs that are shorter by 1.2–416\({\times }\), and incurs the lowest verification times with speedups of 3.6–1326\({\times }\). When compared to the state-of-the-art zkSNARK with trusted setup, Spartan ’s prover is \(2{\times }\) faster for arbitrary R1CS instances and \(16{\times }\) faster for data-parallel workloads.

(3) A unified understanding of different strands of theory. Spartan exposes inter-connections among different lines of work on probabilistic proofs—from the perspective of zkSNARKs—including doubly-efficient IPs, MIPs, and short PCPs  [72, §3.2].

(4) Improvements in zkSNARKs with universal setup. While our focus is transparent zkSNARKs, Spartan improves on prior zkSNARKs with universal trusted setup.

By employing a different polynomial commitment scheme  [69, 87], which requires q-type, knowledge of exponent assumptions, in spark, Spartan offers an alternative to Libra  [85]; we refer to this variant as . Compared to Libra, supports arbitrary R1CS instances instead of layered arithmetic circuits. Furthermore, unlike Libra, the proof sizes and the verifier’s running times in do not scale linearly with the circuit depth. Finally, Libra achieves sub-linear verification costs only for low-depth uniform circuits whereas achieves sub-linear verification costs for arbitrary R1CS instances via computation commitments.

Fig. 2.
figure 2

A comparison of prior and recent zkSNARKs, where n denotes the size of the NP statement. For Hyrax  [84], we assume a layered arithmetic circuit \(\mathcal {C}\) of depth d, width g, and \(\beta \) copies (i.e., \(n = d \cdot g \cdot \beta \)); w denotes the size of a witness to \(\mathcal {C}\); and \(m=d \cdot \log {g}\). Hyrax and can achieve sub-sqrt proofs at the cost of increasing \(\mathcal {V}\)’s time. For Libra and Virgo, we assume a depth-d layered uniform circuit. The verifier incurs \(O(|io|)\) additional cost in all schemes where io denotes the public inputs and outputs of the NP relation being proved. Furthermore, all transparent zkSNARKs achieve non-interactivity in the random oracle model using the Fiat-Shamir heuristic  [45]. Private\(^\star \) means that the trusted setup is universal. Ligero, Virgo, STARK, Aurora, Fractal, and are plausibly post-quantum secure. Finally, applies spark to the commitment scheme of Bünz et al.  [32], but the commitment scheme requires an adaptation (Sect. 5.1).

1.2 Additional Related Work

Figure 2 compares the asymptotic costs of Spartan-based zkSNARKs with other schemes.

Recent schemes. Following our preprint, there are three transparent zkSNARKs: Fractal  [36], SuperSonic  [32], and Virgo  [86]. Virgo’s model of computation is same as Hyrax’s, so it achieves sub-linear verification costs only for low-depth, uniform circuits.

Fractal and SuperSonic achieve sub-linear verification costs for arbitrary NP statements. In these schemes, the verifier preprocesses an NP statement—without secret trapdoors—to create a commitment to the structure of the statement. In other words, they instantiate the computation commitments primitive. Unfortunately, both schemes incur orders of magnitude higher expense than Spartan  (Sect. 9).

2 Preliminaries

We use \(\mathbb {F}\) to denote a finite field (e.g., the prime field \(\mathbb {F}_p\) for a large prime p) and \(\lambda \) to denote the security parameter. We use \(\mathtt {negl}(\lambda )\) to denote a negligible function in \(\lambda \). Throughout the paper, the depicted asymptotics depend on \(\lambda \), but we elide this for brevity. We use “PPT algorithms” to refer to probabilistic polynomial time algorithms.

2.1 Problem Instances in R1CS

Recall that for any problem instance \(\mathbb {x}\), if \(\mathbb {x}\) is in an NP language \(\mathcal {L}\), there exists a witness w and a deterministic algorithm \(\mathtt {Sat}\) such that:

$$\begin{aligned} \mathtt {Sat}_\mathcal {L}(\mathbb {x}, w)&= \left. {\left\{ \begin{array}{ll} 1 &{} \text {if } \mathbb {x}\in \mathcal {L}\\ 0 &{} \text {otherwise} \end{array}\right. } \right. \end{aligned}$$

Alternatively, the set of tuples of the form \(\langle {}\mathbb {x},w\rangle {}\) form a set of NP relations. The subset of those for which \(\mathtt {Sat}_\mathcal {L}(\mathbb {x},w) = 1\) are called satisfiable instances, which we denote as: \(\mathcal {R}_\mathcal {L}= \{\langle {}\mathbb {x},w\rangle {} : \mathtt {Sat}_\mathcal {L}(\mathbb {x},w) = 1\}\).

As an NP-complete language, we focus on the rank-1 constraint satisfiability (R1CS). As noted earlier, R1CS is a popular target for compiler toolchains that accept applications expressed in high-level languages  [70, 75, 77, 83]. R1CS is implicit in the QAPs of GGPR  [47], but it is used with (and without) QAPs in subsequent works  [16, 64, 75].

Definition 2.1

(R1CS instance).  An R1CS instance is a tuple \((\mathbb {F},A,B,C,io,m,n)\), where io denotes the public input and output of the instance, \(A,B,C\in \mathbb {F}^{m \times m}\), where \(m \ge |io| + 1\) and there are at most n non-zero entries in each matrix.

Note that matrices ABC are defined to be square matrices for conceptual simplicity. Below, we use the notation \(z=(x,y,z)\) (where each of xyz is a vector over \(\mathbb {F}\)) to mean that z is a vector that concatenates the three vectors in a natural way. WLOG, we assume that \(n = O(m)\) throughout the paper.

Definition 2.2

(R1CS).  An R1CS instance \((\mathbb {F},A,B,C,io,m,n)\) is said to be satisfiable if there exists a witness \(w \in \mathbb {F}^{m-|io|-1}\) such that \((A \cdot z) \circ (B \cdot z) = (C \cdot z),\) where \(z=(io,1,w)\), \(\cdot \) is the matrix-vector product, and \(\circ \) is the Hadamard (entry-wise) product.

Note that R1CS generalizes arithmetic circuit satisfiability because the entries in matrices ABC can be used to encode addition and multiplication gates over \(\mathbb {F}\). Furthermore, they can be used to encode a class of degree-2 constraints of the form \(L(z) \cdot R(z) = O(z)\), where LRO are degree-1 polynomials over variables that take values specified by \(z=(io,1,w)\). In other words, R1CS supports arbitrary fan-in addition gates, and multiplication gates that verify arbitrary bilinear relations over the entire z.

Definition 2.3

For an R1CS instance \(\mathbb {x}= (\mathbb {F},A,B,C,io,m,n)\) and a purported witness \(w \in \mathbb {F}^{m-|io|-1}\), we define:

$$\begin{aligned} \mathtt {Sat}_\text {R1CS}(\mathbb {x}, w)&= \left. {\left\{ \begin{array}{ll} 1 &{} (A \cdot (io,1,w) \circ (B \cdot (io,1,w)) = (C \cdot (io,1,w)) \\ 0 &{} \text {otherwise} \end{array}\right. } \right. \end{aligned}$$

The set of satisfiable R1CS instances can be denoted as:

$$\mathcal {R}_\text {R1CS} = \{\langle {} (\mathbb {F},A,B,C,io,m,n),w\rangle {} : \mathtt {Sat}_\text {R1CS}((\mathbb {F},A,B,C,io,m,n),w) = 1\}$$

Definition 2.4

For a given R1CS instance \(\mathbb {x}= (\mathbb {F},A,B,C,io,m,n)\), the NP statement that \(\mathbb {x}\) is satisfiable (i.e., \(\mathbb {x}\in \mathcal {R}_{\text {R1CS}}\)) is of size O(n).

2.2 Polynomials and Low-Degree Extensions

Definition 2.5

(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.6

(Low-degree polynomial). A multivariate polynomial \(\mathcal {G}\) over a finite field \(\mathbb {F}\) is called low-degree polynomial if the degree of \(\mathcal {G}\) in each variable is exponentially smaller than \(|\mathbb {F}|\).

Low-degree extensions (LDEs). Suppose \(g: \{0,1\}^m \rightarrow \mathbb {F}{}\) is a function that maps m-bit elements into an element of \(\mathbb {F}\). A polynomial extension of g is a low-degree m-variate polynomial \(\widetilde{g}(\cdot )\) such that \(\widetilde{g}(x) = g(x)\) for all \(x \in \{0,1\}^m\).

A multilinear polynomial extension (or simply, a multilinear extension, or MLE) is a low-degree polynomial extension where the extension is a multilinear polynomial (i.e., the degree of each variable in \(\widetilde{g}(\cdot )\) is at most one). Given a function \(Z: \{0,1\}^m \rightarrow \mathbb {F}\), the multilinear extension of \(Z(\cdot )\) is the unique multilinear polynomial \(\widetilde{Z} : \mathbb {F}^m \rightarrow \mathbb {F}\). It can be computed as follows.

$$\begin{aligned} \widetilde{Z}(x_1, \ldots , x_m)&= \sum _{e \in \{0,1\}^m}{Z(e) \cdot \prod _{i=1}^{m}{(x_i \cdot e_i + (1-x_i) \cdot (1-e_i))}} \\&= \sum _{e \in \{0,1\}^m}{Z(e) \cdot \widetilde{\text {eq}}(x,e)} \\&= \langle (Z(0), \ldots , Z(2^m-1)), (\widetilde{\text {eq}}(x,0), \ldots , \widetilde{\text {eq}}(x,2^m-1)\rangle \end{aligned}$$

Note that \(\widetilde{\text {eq}}(x,e) = \prod _{i=1}^{m} (e_i \cdot x_i + (1-e_i)\cdot (1-x_i))\), which is the MLE of the following function:

$$\begin{aligned} \text {eq} (x,e)&= \left. {\left\{ \begin{array}{ll} 1 &{} \text {if x = e} \\ 0 &{} \text {otherwise} \end{array}\right. } \right. \end{aligned}$$

For any \(r \in \mathbb {F}^{m}\), \(\widetilde{Z}(r)\) can be computed in \(O(2^m)\) operations in \(\mathbb {F}\)  [78, 80].

Dense representation for multilinear polynomials. Since the MLE of a function is unique, it offers the following method to represent any multilinear polynomial. Given a multilinear polynomial \(\mathcal {G}(\cdot ): \mathbb {F}^m \rightarrow \mathbb {F}\), it can be represented uniquely by the list of evaluations of \(\mathcal {G}(\cdot )\) over the Boolean hypercube \(\{0,1\}^m\) (i.e., a function that maps \(\{0,1\}^m \rightarrow \mathbb {F}\)). We denote such a representation of \(\mathcal {G}\) as \(\mathtt {DenseRepr}(\mathcal {G})\).

Definition 2.7

A multilinear polynomial \(\mathcal {G}:\mathbb {F}^m \rightarrow \mathbb {F}\) is a sparse multilinear polynomial if \(|\mathtt {DenseRepr}(\mathcal {G})|\) is sub-linear in \(O(2^m)\). Otherwise, it is a dense multilinear polynomial.

2.3 A Polynomial Commitment Scheme for Multilinear Polynomials

We adopt our definitions from Bünz et al.  [32] where they generalize the definition of Kate et al.  [57] to allow interactive evaluation proofs. We also borrow their notation: in a list of arguments or returned tuples, variables before the semicolon are public and the ones after are secret; when there is no secret information, semicolon is omitted.

WLOG, below, when algorithms accept as input a multilinear polynomial, they use the dense representation of multilinear polynomials (Sect. 2.2).

A polynomial commitment scheme for multilinear polynomials is a tuple of four protocols \({\textsf {PC}} =({\textsf {Setup}},{\textsf {Commit}},{\textsf {Open}},{\textsf {Eval}})\):

  • \(pp \leftarrow {\textsf {Setup}} (1^\lambda , \mu )\): takes as input \(\mu \) (the number of variables in a multilinear polynomial); produces public parameters pp.

  • \((\mathcal {C}\text {; }\mathcal {S}) \leftarrow {\textsf {Commit}} (pp\text {; }\mathcal {G})\): takes as input a \(\mu \)-variate multilinear polynomial over a finite field \(\mathcal {G}\in \mathbb {F}[\mu ]\); produces a public commitment \(\mathcal {C}\) and a secret opening hint \(\mathcal {S}\).

  • \(b \leftarrow {\textsf {Open}} (pp, \mathcal {C},\mathcal {G},\mathcal {S})\): verifies the opening of commitment \(\mathcal {C}\) to the \(\mu \)-variate multilinear polynomial \(\mathcal {G}\in \mathbb {F}[\mu ]\) with the opening hint \(\mathcal {S}\); outputs a \(b \in \{0,1\}\).

  • \(b \leftarrow {\textsf {Eval}} (pp, \mathcal {C}, r, v,\mu {}\text {; }\mathcal {G},\mathcal {S})\) is an interactive public-coin protocol between a PPT prover \(\mathcal {P}\) and verifier \(\mathcal {V}\). Both \(\mathcal {V}\) and \(\mathcal {P}\) hold a commitment \(\mathcal {C}\), the number of variables \(\mu \), a scalar \(v \in \mathbb {F}\), and \(r \in \mathbb {F}^\mu \). \(\mathcal {P}\) additionally knows a \(\mu \)-variate multilinear polynomial \(\mathcal {G}\in \mathbb {F}[\mu ]\) and its secret opening hint \(\mathcal {S}\). \(\mathcal {P}\) attempts to convince \(\mathcal {V}\) that \(\mathcal {G}(r) = v\). At the end of the protocol, \(\mathcal {V}\) outputs \(b \in \{0,1\}\).

Definitions of properties of polynomial commitments as well as definitions of interactive arguments of knowledge are in an extended report  [72].

3 The Sum-Check Protocol: Opportunities and Challenges

An interactive proof is an interactive argument, where the soundness holds unconditionally. We now describe a seminal interactive proof protocol that we employ in Spartan, called the sum-check protocol  [66]. Suppose there is an \(\mu \)-variate low-degree polynomial, \(\mathcal {G}: \mathbb {F}^\mu \rightarrow \mathbb {F}\) where the degree of each variable in \(\mathcal {G}\) is at most \(\ell \). Suppose that a verifier \(\mathcal {V}_{SC}\) is interested in checking a claim of the following form by an untrusted prover \(\mathcal {P}_{SC}\):

$$T = \sum _{x_1 \in \{0,1\}}\sum _{x_2 \in \{0,1\}} \ldots \sum _{x_\mu \in \{0,1\}}{\mathcal {G}(x_1, x_2, \ldots , x_\mu )}$$

Of course, given \(\mathcal {G}(\cdot )\), \(\mathcal {V}_{SC}\) can deterministically evaluate the above sum and verify whether the sum is T. But, this computation takes time exponential in \(\mu \).

Lund et al.  [66] describe the sum-check protocol that requires far less computation on \(\mathcal {V}_{SC}\)’s behalf, but provides a probabilistic guarantee. In the protocol, \(\mathcal {V}_{SC}\) interacts with \(\mathcal {P}_{SC}\) over a sequence of \(\mu \) rounds. At the end of this interaction, \(\mathcal {V}_{SC}\) outputs \(b \in \{0,1\}\). The principal cost to \(\mathcal {V}_{SC}\) is to evaluate \(\mathcal {G}\) at a random point in its domain \(r \in \mathbb {F}^\mu \). We denote the sum-check protocol as \(b \leftarrow \langle {}\mathcal {P}_{SC},\mathcal {V}_{SC}(r)\rangle {}(\mathcal {G},\mu ,\ell ,T)\). For any \(\mu \)-variate polynomial \(\mathcal {G}\) with degree at most \(\ell \) in each variable, the following properties hold.

  • Completeness. If \(T = \sum _{x \in \{0,1\}^\mu }{\mathcal {G}(x)}\), then for a correct \(\mathcal {P}_{SC}\) and for all \(r \in \{0,1\}^*\), \(\Pr \{\langle {}\mathcal {P}_{SC}(\mathcal {G}),\mathcal {V}_{SC}(r)\rangle {}(\mu ,\ell ,T) = 1\} = 1\).

  • Soundness. If \(T \ne \sum _{x \in \{0,1\}^\mu }{\mathcal {G}(x)}\), then for any \(\mathcal {P}^{\star }_{SC}\) and for all \(r \in \{0,1\}^*\), \(\Pr _{r}\{\langle {}\mathcal {P}^{\star }_{SC}(\mathcal {G}),\mathcal {V}_{SC}(r)\rangle {}(\mu ,\ell ,T) = 1\} \le \ell \cdot \mu /|\mathbb {F}|\).

  • Succinctness. The communication between \(\mathcal {P}_{SC}\) and \(\mathcal {V}_{SC}\) is \(O(\mu \cdot \ell )\) elements of \(\mathbb {F}\).

An alternate formulation. In the rest of the paper, it is natural to view the sum-check protocol as a mechanism to reduce a claim of the form \(\sum _{x\in \{0,1\}^m}{\mathcal {G}(x)} \overset{?}{=} T\) to the claim \(\mathcal {G}(r) \overset{?}{=} e\). This is because in most cases, the verifier uses an auxiliary protocol to verify the latter claim, so this formulation makes it easy to describe our end-to-end protocols. We denote this reduction protocol with \(e \leftarrow \langle {}\mathcal {P}_{SC}(\mathcal {G}),\mathcal {V}_{SC}(r)\rangle {}(\mu ,\ell ,T)\).

3.1 Challenges with Using the Sum-Check Protocol for Succinct Arguments

To build a succinct interactive argument of knowledge for R1CS, we need an interactive protocol for the verifier \(\mathcal {V}\) to check if the prover \(\mathcal {P}\) knows a witness w to a given R1CS instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\) such that \(\mathtt {Sat}_\text {R1CS}(\mathbb {x},w) = 1\).

At first glance, the sum-check protocol  [66] seems to offer the necessary building block (it is public-coin, incurs succinct communication, etc.). However, to build a succinct interactive argument of knowledge (that can in turn be compiled into a zkSNARK), we must solve the following sub-problems:

  1. 1.

    Encode R1CS instances as sum-check instances. For any R1CS instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\), we must devise a degree-\(\ell \), \(\mu \)-variate polynomial that sums to a specific value T over \(\{0,1\}^\mu \) if and only if there exists a witness w such that \(\mathtt {Sat}_{\text {R1CS}}(\mathbb {x},w) = 1\), where \(\mu = O(\log {m})\) and \(\ell \) is a small constant (e.g., 3).

  2. 2.

    Achieve communication-succinctness. Although the sum-check protocol offers succinctness (if the first sub-problem is solved with constraints on \(\mu \) and \(\ell \) noted above), building a succinct interactive argument is non-trivial. This is because after the sum-check reduction, \(\mathcal {V}\) must verify \(\mathcal {G}(r) \overset{?}{=} e\). Unfortunately, \(\mathcal {G}(r)\) depends on the \(\mathcal {P}\)’s witness w to \(\mathbb {x}\). Thus, a naive evaluation of \(\mathcal {G}(r)\) requires O(m) communication to transmit w. Transmitting w is also incompatible with zero-knowledge.

  3. 3.

    Achieve verifier-succinctness. To compile an interactive argument to a zkSNARK, \(\mathcal {V}\)’s costs must be sub-linear in the size of an NP statement, but evaluating \(\mathcal {G}(r)\) requires O(n) computation if the statement has no structure (e.g., data-parallelism). A potential way around this fundamental issue is for \(\mathcal {V}\) to preprocess the structure of the R1CS instance to accelerate all future verification of proofs for different R1CS instances with the same structure. However, to avoid any form of trusted setup, the preprocessing must not involve secret trapdoors.

We describe prior solutions to the three sub-problems in an extended report  [72].

4 An Encoding of R1CS Instances as Low-Degree Polynomials

This section describes a compact encoding of an R1CS instance as a degree-3 multivariate polynomial. The following theorem summarizes our result, which we prove below.

Theorem 4.1

For any R1CS instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\), there exists a degree-3 \(\log {m}\)-variate polynomial \(\mathcal {G}\) such that \(\sum _{x\in \{0,1\}^{\log {m}}}{\mathcal {G}(x)} = 0\) if and only if there exists a witness w such that \(\mathtt {Sat}_{\text {R1CS}}(\mathbb {x},w)=1\) (except for a soundness error that is negligible in \(\lambda \)) under the assumption that \(|\mathbb {F}|\) is exponential in \(\lambda \) and \(m=O(\lambda )\).

For a given R1CS instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\), let . Thus, we can view matrices \(A,B,C \in \mathbb {F}^{m\times {}m}\) as functions with the following signature: \(\{0,1\}^s \times \{0,1\}^s \rightarrow \mathbb {F}\). Specifically, any entry in them can be accessed with a 2s-bit identifier (or two s-bit identifiers). Furthermore, given a purported witness w to \(\mathbb {x}\), let \(Z = (io,1, w)\). It is natural to interpret Z as a function with the following signature: \(\{0,1\}^s \rightarrow \mathbb {F}\), so any element of Z can be accessed with an s-bit identifier.

We now describe a function \(F_{io}(\cdot )\) that can be used to encode w such that \(F_{io}(\cdot )\) exhibits a desirable behavior if and only if \(\mathtt {Sat}_{\text {R1CS}}(\mathbb {x},w) = 1\).

$$F_{io}(x) = \left( \sum _{y \in \{0,1\}^s}{A(x,y) \cdot Z(y)}\right) \cdot \left( \sum _{y \in \{0,1\}^s}{B(x,y) \cdot Z(y)}\right) - \sum _{y \in \{0,1\}^s}{C(x,y) \cdot Z(y)}$$

Lemma 4.1

\(\forall x \in \{0,1\}^{s}\), \(F_{io}(x) = 0\) if and only if \(\mathtt {Sat}_{\text {R1CS}}(\mathbb {x},w) = 1\).

Proof

This follows from the definition of \(\mathtt {Sat}_{\text {R1CS}}(\mathbb {x},w)\) (Sect. 2.1) and of \(Z(\cdot )\).    \(\square \)

Unfortunately \(F_{io}(\cdot )\) is a function, not a polynomial, so it cannot be directly used in the sum-check protocol. But, consider its polynomial extension \(\widetilde{F}_{io} : \mathbb {F}^{s} \rightarrow \mathbb {F}\).

$$\begin{aligned} \widetilde{F}_{io}(x)&= \left( \sum _{y \in \{0,1\}^s}{\widetilde{A}(x,y) \cdot \widetilde{Z}(y)}\right) \cdot \left( \sum _{y \in \{0,1\}^s}{\widetilde{B}(x,y) \cdot \widetilde{Z}(y)}\right) - \sum _{y \in \{0,1\}^s}{\widetilde{C}(x,y) \cdot \widetilde{Z}(y)} \end{aligned}$$

Lemma 4.2

\(\forall x \in \{0,1\}^{s}\), \(\widetilde{F}_{io}(x) = 0\) if and only if \(\mathtt {Sat}_{\text {R1CS}}(\mathbb {x},w) = 1\).

Proof

For any \(x \in \{0,1\}^s\), \(\widetilde{F}_{io}(x) = F_{io}(x)\), so the result follows from Lemma 4.1.    \(\square \)

Since \(\widetilde{F}_{io}(\cdot )\) is a low-degree multivariate polynomial over \(\mathbb {F}\) in s variables, a verifier \(\mathcal {V}\) could check if \(\sum _{x \in \{0,1\}^{s}} \widetilde{F}_{io}(x) = 0\) using the sum-check protocol with a prover \(\mathcal {P}\). But, this is insufficient: \(\sum _{x \in \{0,1\}^{s}} \widetilde{F}_{io}(x) = 0\) does not imply that \(F_{io}(x)\) is zero \(\forall x \in \{0,1\}^{s}\). This is because the \(2^{s}\) terms in the sum might cancel each other making the final sum zero—even when some of the individual terms are not zero.

We addresses the above issue using a prior idea  [8, 25, 34]. Consider:

$$Q_{io}(t) = \sum _{x \in \{0,1\}^{s}}{\widetilde{F}_{io}(x) \cdot \widetilde{\text {eq}}(t,x)},$$

where \(\widetilde{\text {eq}}(t,x) = \prod _{i=1}^{s} (t_i \cdot x_i + (1-t_i)\cdot (1-x_i))\).

Observe that \(Q_{io}(\cdot )\) is a multivariate polynomial such that \(Q_{io}(t) = \widetilde{F}_{io}(t)\) for all \(t \in \{0,1\}^{s}\). Thus, \(Q_{io}(\cdot )\) is a zero-polynomial (i.e., it evaluates to zero for all points in its domain) if and only if \(\widetilde{F}_{io}(\cdot )\) evaluates to zero at all points in the s-dimensional Boolean hypercube (and hence if and only if \(\widetilde{F}_{io}(\cdot )\) encodes a witness w such that \(\mathtt {Sat}_{\text {R1CS}}(\mathbb {x},w) = 1\)). To check if \(Q_{io}(\cdot )\) is a zero-polynomial, it suffices to check if \(Q_{io}(\tau ) = 0\) where \(\tau \in _R \mathbb {F}^{s}\). This introduces a soundness error, which we quantify below.

Lemma 4.3

\(\Pr _{\tau }\{Q_{io}(\tau ) = 0 | \exists x \in \{0,1\}^s \text { s.t. } \widetilde{F}_{io}(x) \ne 0\} \le \log {m}/|\mathbb {F}|\)

Proof

If \(\exists x \in \{0,1\}^s\) such that \(\widetilde{F}_{io}(x) \ne 0\), then \(Q_{io}(t)\) is not a zero-polynomial. By the Schwartz-Zippel lemma, \(Q_{io}(t) = 0\) for at most \(d/|\mathbb {F}|\) values of t in the domain of \(Q_{io}(\cdot )\), where d is the degree of \(Q_{io}(\cdot )\). Here, \(d = s = \log {m}\).    \(\square \)

Proof of Theorem 4.1. For a given R1CS instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\), define, \(\mathcal {G}_{io,\tau }(x) = {\widetilde{F}_{io}(x) \cdot \widetilde{\text {eq}}(\tau ,x)}\), so \(Q_{io}(\tau ) = \sum _{x \in \{0,1\}^s}{\mathcal {G}_{io,\tau }(x)}\). Observe that \(\mathcal {G}_{io,\tau }(\cdot )\) is a degree-3 s-variate polynomial if multilinear extensions of ABC, and Z are used in \(\widetilde{F}_{io}(\cdot )\). In the terminology of the sum-check protocol, \(T=0, \mu =s=\log {m},\) and \(\ell =3\). Furthermore, if \(\tau \in _R \mathbb {F}^s\), \(\sum _{x\in \{0,1\}^s}{\mathcal {G}_{io,\tau }(x)} = 0\) if and only \(\widetilde{F_{io}}(x) = 0\) \(\forall x \in \{0,1\}^s\)—except for soundness error that is negligible in \(\lambda \) under the assumptions noted above (Lemma 4.3). This combined with Lemma 4.2 implies the desired result.

5 A Family of NIZKs with Succinct Proofs for R1CS

We first design an interactive argument with succinct communication costs and then compile it into a family of NIZKs in the random oracle model using prior transformations.

5.1 A New Public-Coin Succinct Interactive Argument of Knowledge

The following theorem summarizes our result in this section.

Theorem 5.1

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 \(|\mathbb {F}|\) is exponential in \(\lambda \) and the size parameter of R1CS instance \(n = O(\lambda )\).

To prove the above theorem, we first provide a construction of a public-coin succinct interactive argument of knowledge, and then analyze its costs and security. The proof of Theorem 4.1 established that for \(\mathcal {V}\) to verify if an R1CS instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\) is satisfiable, it can check if \(\sum _{x \in \{0,1\}^{s}}{\mathcal {G}_{io,\tau }(x)} = 0\). By using the sum-check protocol, we can reduce the claim about the sum to \(e_x \overset{?}{=} \mathcal {G}_{io,\tau }(r_x)\) where \(r_x \in \mathbb {F}^{s}\), so \(\mathcal {V}\) needs a mechanism to evaluate \(\mathcal {G}_{io,\tau }(r_x)\)—without incurring O(m) communication from \(\mathcal {P}\) to \(\mathcal {V}\).

Recall that \(G_{io,\tau }(x) = \widetilde{F}_{io}(x) \cdot \widetilde{\text {eq}}(\tau ,x)\). Thus, to evaluate \(G_{io,\tau }(r_x)\), \(\mathcal {V}\) must evaluate \(\widetilde{F}_{io}(r_x)\) and \(\widetilde{eq}(\tau ,r_x)\). The latter can be evaluated in \(O(\log {m})\) time. Furthermore, recall:

$$\begin{aligned} \widetilde{F}_{io}(r_x)&= \left( \sum _{y \in \{0,1\}^s}{\widetilde{A}(r_x,y) \cdot \widetilde{Z}(y)}\right) \cdot \left( \sum _{y \in \{0,1\}^s}{\widetilde{B}(r_x,y) \cdot \widetilde{Z}(y)}\right) - \sum _{y \in \{0,1\}^s}{\widetilde{C}(r_x,y) \cdot \widetilde{Z}(y)} \end{aligned}$$

To evaluate \(\widetilde{F}_{io}(r_x)\), \(\mathcal {V}\) needs to evaluate the following \(\forall y \in \{0,1\}^s\): \(\widetilde{A}(r_x,y)\), \(\widetilde{B}(r_x,y)\), \(\widetilde{C}(r_x,y)\), and \(\widetilde{Z}(y)\). However, the evaluations of \(\widetilde{Z}(y)\) for all \(y \in \{0,1\}^s\) is the same as (io, 1, w), so the communication from \(\mathcal {P}\) to \(\mathcal {V}\) is \(\ge O(|w|)\). We now address this issue.

Our solution is a combination of three protocols: the sum-check protocol, a randomized mini protocol, and a polynomial commitment scheme. Our first observation is that the structure of the individual terms in \(F_{x,y}(\cdot )\) evaluated at \(r_x\) are in a form suitable for the application of a second instance of the sum-check protocol. Specifically, let \(\widetilde{F}_{io}(r_x) = \overline{A}(r_x) \cdot \overline{B}(r_x) - \overline{C}(r_x),\) where

$$\begin{aligned} \overline{A}(r_x)&= \sum _{y \in \{0,1\}^s}{\widetilde{A}(r_x,y) \cdot \widetilde{Z}(y)} \\ \overline{B}(r_x)&= \sum _{y \in \{0,1\}^s}{\widetilde{B}(r_x,y) \cdot \widetilde{Z}(y)} \\ \overline{C}(r_x)&= \sum _{y \in \{0,1\}^s}{\widetilde{C}(r_x,y) \cdot \widetilde{Z}(y)} \end{aligned}$$

This observation opens up the following solution: the prover can make three separate claims to \(\mathcal {V}\), say that \(\overline{A}(r_x) = v_{A}\), \(\overline{B}(r_x) = v_{B}\), and \(\overline{C}(r_x) = v_{C}\). Then, \(\mathcal {V}\) can evaluate:

$$\mathcal {G}_{io,\tau }(r_x) = (v_{A} \cdot v_{B} - v_{C}) \cdot \widetilde{\text {eq}}(r_x,\tau ),$$

which in turn enables \(\mathcal {V}\) to verify \(\mathcal {G}_{io,\tau }(r_x) \overset{?}{=} e_x\). Of course, \(\mathcal {V}\) must still verify three new claims from \(\mathcal {P}\): \(\overline{A}(r_x) \overset{?}{=} v_{A}\), \(\overline{B}(r_x) \overset{?}{=} v_{B}\), and \(\overline{C}(r_x) \overset{?}{=} v_{C}\). To do so, \(\mathcal {V}\) and \(\mathcal {P}\) can run three independent instances of the sum-check protocol to verify these claims. Instead, we use a prior idea  [35, 84] to combine three claims into a single claim:

figure a

Lemma 5.1

\(\Pr _{r_A,r_B,r_C}\{ r_A \cdot \overline{A}(r_x) + r_{B} \cdot \overline{B}(r_x) + r_{C} \cdot \overline{C}(r_x)=c | \overline{A}(r_x) \ne v_A \vee \overline{B}(r_x) \ne v_B \vee \overline{C}(r_x) \ne v_C\} \le 1/|\mathbb {F}|\), where \(c = r_A\cdot v_A + r_y \cdot v_B + r_C \cdot v_C\).

Proof

The LHS is a polynomial in \(r_A, r_B, r_C\) of total degree 1; the same holds for the RHS. So, the desired result follows from the Schwartz-Zippel lemma.    \(\square \)

\(\mathcal {V}\) is not out of the woods. At the end of the second instance of the sum-check protocol, \(\mathcal {V}\) must evaluate \(M_{r_x}(r_y)\) for \(r_y \in \mathbb {F}^{s}\):

$$\begin{aligned} M_{r_x}(r_y)&= r_{A} \cdot \widetilde{A}(r_x,r_y) \cdot \widetilde{Z}(r_y) + r_{B} \cdot \widetilde{B}(r_x,r_y) \cdot \widetilde{Z}(r_y) + r_{C} \cdot \widetilde{C}(r_x,r_y) \cdot \widetilde{Z}(r_y) \\&= (r_{A} \cdot \widetilde{A}(r_x,r_y) + r_{B} \cdot \widetilde{C}(r_x,r_y) + r_{C} \cdot \widetilde{C}(r_x,r_y))\cdot \widetilde{Z}(r_y) \end{aligned}$$

Observe that the only term in \(M_{r_x}(r_y)\) that depends on the prover’s witness is \(\widetilde{Z}(r_y)\). This is because all other terms in the above expression can be computed locally by \(\mathcal {V}\) using \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\) in O(n) time (Sect. 6 discusses how to reduce the cost of those evaluations to be sub-linear in n). Our second observation is that to evaluate \(\widetilde{Z}(r_y)\) without incurring O(|w|) communication from \(\mathcal {P}\) to \(\mathcal {V}\), we can employ an extractable polynomial commitment scheme for multilinear polynomials (Sect. 2.3). A similar observation was made by Zhang et al.  [87] in a different context.

In more detail, \(\mathcal {P}\) sends a commitment to \(\widetilde{w}(\cdot )\) (i.e., a multilinear extension of its purported witness) to \(\mathcal {V}\) before the first instance of the sum-check protocol begins using an extractable polynomial commitment scheme for multilinear polynomials. To evaluate \(\widetilde{Z}(r_y)\), \(\mathcal {V}\) does the following. WLOG, assume \(|w| = |io| + 1\). Thus, by the closed form expression of multilinear polynomial evaluations, we have:

$$\begin{aligned} \widetilde{Z}(r_y)&= (1-r_y[0]) \cdot \widetilde{w}(r_y[1..]) + r_y[0] \cdot \widetilde{(io,1)}(r_y[1..])\text {,} \end{aligned}$$

where \(r_y[1..]\) refers to a slice of \(r_y\) that excludes the the first element.

Putting things together.  We assume that there exists an extractable polynomial commitment scheme for multilinear polynomials \({\textsf {PC}} =({\textsf {Setup}},{\textsf {Commit}},{\textsf {Open}},{\textsf {Eval}})\).

figure b

Choice of a polynomial commitment scheme. There exist many extractable polynomial commitment schemes for multilinear polynomials  [69, 84, 86, 87] that suffice for our purposes. The particular choice impacts the costs of our protocol as well as assumptions, so we review prior commitment schemes’ costs and assumptions (Fig. 3). An additional choice here is the scheme of Bünz et al  [32] instantiated with class groups, but it requires a modification for our setting where we represent multilinear polynomials using their evaluations over a Boolean hypercube (Sects. 2.2, 2.3).

Fig. 3.
figure 3

A comparison of candidate extractable polynomial commitment schemes for multilinear polynomials. Here, \(\Gamma =2^{\mu }\) where \(\mu \) is the number of variables in the multilinear polynomial. Hyrax-PC refers to the scheme of Wahby et al.  [84], which also supports shorter commitments at the cost of increasing the verifier’s time. vSQL-VPD refers to the zero-knowledge variant  [88] of the scheme of Zhang et al.  [87]. Virgo-VPD refers to the scheme of Zhang et al.  [86]. The communication column refers to the amount of communication required in the interactive argument for \({\textsf {PC}}.{\textsf {Eval}} \).

Analysis of costs. Note that the polynomials over which the sum-check protocol is run in our interactive argument decompose into several multilinear polynomials (four in the first sum-check protocol and two in the second sum-check protocol), so by employing prior ideas  [78, 82, 85] to implement a linear-time prover for the sum-check protocol, the costs of our interactive argument are as follows.

  • \(\mathcal {P}\) incurs: (1) O(n) costs to participate in the sum-check instances; (2) the cost of \({\textsf {PC}}.{\textsf {Commit}} \) and \({\textsf {PC}}.{\textsf {Eval}} \) for a \(\log {m}\)-variate multilinear polynomial \(\widetilde{w}(\cdot )\).

  • \(\mathcal {V}\) incurs: (1) \(O(\log {m})\) costs for the sum-check instances; (2) the cost of \({\textsf {PC}}.{\textsf {Eval}} \) for a \(\log {m}\)-variate multilinear polynomial; and (3) O(n) costs to evaluate \(\widetilde{A}(\cdot ),\widetilde{B}(\cdot ),\widetilde{C}(\cdot )\).

  • The amount of communication is: (1) \(O(\log {m})\) in the sum-check instances; (2) the size of the commitment to \(\widetilde{w}(\cdot )\) and the communication in \({\textsf {PC}}.{\textsf {Eval}} \) for \(\widetilde{w}(\cdot )\).

Fig. 4.
figure 4

Costs of our public-coin succinct interactive argument of knowledge instantiated with different polynomial commitment schemes. The depicted costs are for an R1CS instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\).

Proof of Theorem 5.1. The desired completeness of our interactive argument of knowledge follows from the completeness of the sum-check protocol and of the underlying polynomial commitment scheme. Furthermore, in all the four candidate constructions for polynomial commitment schemes, the communication from \(\mathcal {P}\) to \(\mathcal {V}\) is sub-linear in m (Fig. 4), which satisfies succinctness. Thus, we are left with proving witness-extended emulation, which we prove in the full version of the paper  [72].

5.2 A Family of NIZKs with Succinct Proofs for R1CS

The interactive argument from the prior subsection is public coin, so we add zero-knowledge using prior techniques  [9, 40]. There are two compilers that are particularly efficient: (1) the one employed by Hyrax  [84], which relies on a zero-knowledge argument protocol for proving dot-product relationships and other relationships in zero-knowledge (e.g., products); and (2) the compiler employed by Libra  [85] and Virgo  [86], which relies on an extractable polynomial commitment scheme. This transformation does not change asymptotics of \(\mathcal {P}\), \(\mathcal {V}\), or of the amount of communication (Fig. 4).

Finally, since our protocol is public coin, it can be made non-interactive in the random oracle model using the Fiat-Shamir transform  [45], thereby obtaining a family of NIZKs with succinct proofs for R1CS.

6 Computation Commitments: zkSNARKs for R1CS from NIZK

The previous section constructed a family of NIZKs but not zkSNARKs. This is because the verifier incurs costs linear in the size of the R1CS instance to evaluate \(\widetilde{A},\widetilde{B},\widetilde{C}\) at \((r_x,r_y)\). We now discuss how to achieve sub-linear verification costs. At first blush, this appears impossible: The verifier incurs O(n) costs to evaluate \(\widetilde{A},\widetilde{B},\widetilde{C}\) at \((r_x,r_y)\) (step 16, Sect. 5.1), which is time-optimal  [78, 80] if \(\mathbb {x}\) has no structure (e.g., uniformity). We get around this impossibility by introducing a preprocessing step for \(\mathcal {V}\). In an offline phase, \(\mathcal {V}\) with access to non-io portions of an R1CS instance \(\mathbb {x}=(\mathbb {F},A,B,C,io,m,n)\) executes the following, where \(pp_{cc} \leftarrow {\textsf {PC}}.{\textsf {Setup}} (1^\lambda ,2\log {m})\) and \({\textsf {PC}} \) is an extractable polynomial commitment scheme for multilinear polynomials.

figure c

\(\mathcal {V}\) retains commitments output by \({\textsf {Encode}} \) (which need not hide the underlying polynomials, so in practice \(\mathcal {S}_A=\mathcal {S}_B=\mathcal {S}_C=\bot \)). The interactive argument proceeds as in the prior section except that at step 16, instead of \(\mathcal {V}\) evaluating \(\widetilde{A},\widetilde{B},\widetilde{C}\), we have:

figure d

Lemma 6.1

The interactive argument from Sect. 5.1 where step 16 is replaced with the above protocol is a public-coin succinct interactive argument of knowledge assuming \({\textsf {PC}} \) is an extractable polynomial commitment scheme for multilinear polynomials.

Proof

The result follows from the knowledge soundness property satisfied by \({\textsf {PC}} \) scheme used in the \({\textsf {Encode}} \) algorithm.    \(\square \)

If \(\mathcal {V}\)’s costs to verify the three evaluations and the added communication are sub-linear in O(n), the modified interactive argument leads to a zkSNARK (if we add zero-knowledge and non-interactivity as before).

Unfortunately, existing polynomial commitment schemes do not satisfy the desired efficiency properties: (1) to participate in \({\textsf {Eval}} \) for any of \(\widetilde{A},\widetilde{B},\widetilde{C}\), \(\mathcal {P}\) incurs at least quadratic costs i.e., \(O(m^2)\); and (2) in some schemes (e.g., Hyrax-PC), the modified interactive argument does not offer improved asymptotics for the verifier.

The next section describes a scheme that meets our efficiency requirements and leads to asymptotics noted in Fig. 2.

7 The spark Compiler

This section describes spark, 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.

For ease of exposition, we focus on describing spark that applies to \(2\log {m}\)-variate sparse polynomials \(\widetilde{A},\widetilde{B},\widetilde{C}\) (where their dense representation is of size \(\le n\)) from Sect. 5.1, but our result generalizes to other sparse multilinear polynomials.

7.1 spark-naive: A Straw-Man Solution

To present our solution, we describe a straw-man that helps introduce the necessary building blocks as well as articulate difficulties addressed by spark. We recall Hyrax  [84], a zkSNARK that achieves sub-linear verification costs for uniform circuits, specifically data-parallel circuits. The prover’s costs in Hyrax can be made linear in the circuit size using subsequent ideas  [85]. Furthermore, the verifier’s costs are \(O(d\log {n} + e)\) where d is the depth of the circuit and e is the cost to the verifier to participate in \({\textsf {PC}}.{\textsf {Eval}} \) to evaluate a \(\log {|w}|\)-variate multilinear polynomial where w is a witness to the circuit.

Details. Let M denote one of \(\{A,B,C\}\) and let \(s=\log {m}\), so \(\mu =2s\). Recall the closed-form expression for multilinear polynomial evaluations at \(r\in \mathbb {F}^{\mu }\).

$$\begin{aligned} \widetilde{M}(r) = \sum _{i \in \{0,1\}^{\mu }\,{::}\, M(i) \ne 0}{M(i) \cdot \widetilde{\text {eq}}(i,r)} \end{aligned}$$
(1)

The above sum has at most n terms since \(M(i) \ne 0\) for at most n values of i. Also, each entry in the sum can be computed with \(O(\mu )\) multiplications. Consider the following circuit to evaluate \(\widetilde{M}(r)\).

figure e

Note that the above circuit is uniform: there are n identical copies of a sub-circuit, where each sub-circuit computes \(O(\mu )\) multiplications; the outputs of these sub-circuits is fed into a binary tree of addition gates to compute the final sum. Furthermore, there is no sharing of witness elements across data-parallel units, so it truly data-parallel.

Construction. Given an extractable polynomial commitment scheme \({\textsf {PC}} \) for multilinear polynomials, we build a scheme for sparse multilinear polynomials as follows.

figure f

Analysis of costs. Recall that computing \(\widetilde{M}(r)\) for \(M \in \{A,B,C\}\) and \(r\in \mathbb {F}^{\mu }\) takes O(n) costs. The principal downside of \({\textsf {PC}} ^{\text {naive}}\) is it imposes an asymptotic overhead over its underlying commitment scheme for dense multilinear polynomials.

For example, with Hyrax-PC as the underlying commitment scheme, the prover with \({\textsf {PC}} ^{\text {naive}}{}\) incurs \(O(n\log {n})\) costs to prove an evaluation of a committed sparse multilinear polynomial. This is because the prover must prove the satisfiability of a circuit of size \(O(n\cdot \mu )\) as well as prove the evaluations of a constant number of \((\log {(n\cdot (\mu +1))})\)-variate multilinear polynomials. This slowdown is also significant in practice (Sect. 8).

Lemma 7.1

\({\textsf {PC}} ^\text {naive}\) is a polynomial commitment scheme for multilinear polynomials with the costs noted above.

Proof

Completeness follows from the completeness of \({\textsf {PC}} \) and Hyrax. Binding follows from the uniqueness of the dense representation of a sparse multilinear polynomial. Knowledge soundness follows from the witness-extended emulation offered by Hyrax and \({\textsf {PC}}.{\textsf {Eval}} \). The claimed prover’s slowdown follows from the costs of Hyrax and \({\textsf {PC}} \) applied to a constant number of \((\log {(n\cdot (\mu +1))})\)-variate multilinear polynomials.    \(\square \)

7.2 Eliminating Asymptotic Overheads by Leveraging Memory Checking

We now improve on the straw-man scheme by devising an O(n)-sized circuit for sparse polynomial evaluation. Naturally, the size of the witness to the circuit is also of size O(n). This allows spark to achieve a linear-time prover if the underlying polynomial commitment scheme offers linear-time costs for the prover  [69, 84]. More generally, when transforming an existing polynomial commitment scheme that meets our requirements (Sect. 2.3), spark does not add asymptotic overheads to the prover for proving the evaluations of committed sparse multilinear polynomials.

Observe that for \(M \in \{A,B,C\}\), \(M \in \mathbb {F}^{m\times {}m}\) and any \(r \in \mathbb {F}^\mu \), we can rewrite the evaluation of \(\widetilde{M}(r)\) as follows. In our context \(\mu =2\log {m}\), interpret r as a tuple \((r_x,r_y)\) where \(r_x,r_y \in \mathbb {F}^{s}\) and \(s=\log {m}=\mu /2\). Thus, we can rewrite Eq. 1 as:

$$\begin{aligned} \widetilde{M}(r_x,r_y)&= \sum _{(i,j) \in (\{0,1\}^{s},\{0,1\}^s)\,{::}\, M(i,j) \ne 0}{M(i,j) \cdot \widetilde{\text {eq}}(i,r_x) \cdot \widetilde{\text {eq}}(j,r_y)} \end{aligned}$$

In our context, the above sum still contains n terms. Also, computing each entry in the sum still requires \((\mu +1)\) multiplications over \(\mathbb {F}\). However, it is possible to compute a table of evaluations of \(\widetilde{\text {eq}}(i,r_x)\) for all \(i\in \{0,1\}^s\) in \(O(2^s) = O(m)\) time. Similarly, it is possible to compute evaluations of \(\widetilde{\text {eq}}(j,r_y)\) for all \(j \in \{0,1\}^s\) in O(m) time.

Unfortunately, this observation is insufficient: even though these tables can be computed in O(m) time, the sum is taken over the list of \((i,j) \in (\{0,1\}^s, \{0,1\}^s)\) where \(M(i,j) \ne 0\) and for an arbitrary 2s-variate sparse multilinear polynomial, such a list has no structure, so computing the sum requires n random accesses into two tables each with m entries. We could attempt to build a circuit that supports RAM operations. Unfortunately, existing techniques to encode RAM in circuits incur a logarithmic blowup or constants that in practice are larger than a logarithmic blowup.

For m RAM operations over a memory of size m,

  • Pantry  [31], using Merkle trees, trees  [24, 67], offers a circuit of size \(O(m\log {m})\).

  • Buffet  [83], using permutation networks  [13], offers a circuit of size \(O(m\log {m})\) with constants smaller than the ones in Pantry.

  • vRAM  [89] offers an O(m)-sized circuit with a constant of \(\log {|\mathbb {F}|}\) (to encode consistency checks over a memory transcript), so, in practice, this does not improve on the straw-man. Other downsides: (1) it only supports 32-bit sized memory cells, whereas we need a memory over elements of \(\mathbb {F}\); (2) nearly all of the circuit’s non-deterministic witness must be committed by \(\mathcal {P}\) during circuit evaluation.

Our solution specializes and improves upon a recent implementation of offline memory checking techniques  [24] in Spice  [73], which builds circuits to encode operations on persistent storage with serializable transactions. The storage abstraction can be used as a memory abstraction where for m operations, the circuit is of size O(m), but the constants are worse than those of VRAM: \(\ge 1000\) (to encode an elliptic-curve based multiset collision-resistant hash function for each memory operation). We get around this issue by designing an offline memory checking primitive via a new randomized check that only uses public coins. Furthermore, unlike a vRAM-based solution, most of the non-deterministic witness needed by the circuit can be created by \({\textsf {PC}}.{\textsf {Commit}} \) (i.e., by the \({\textsf {Encode}} \) algorithm in the context of computation commitments).

7.2.1 An O(n)-sized Circuit for Evaluating \(\widetilde{M}\)

We now describe an O(n)-sized circuit to compute an evaluation of \(\widetilde{M}\). We prove that the circuit indeed computes the correct evaluation of the sparse polynomial in Lemma 7.5. In the description of the circuit, we assume hash functions H and \(\mathcal {H}\), which are defined below (Eqs. 2 and 3). Before we describe the circuit for polynomial evaluation, we specify an encoding of sparse polynomials that our circuit leverages.

Encoding sparse polynomials. Given a sparse polynomial \(\widetilde{M}\) (e.g., \(\widetilde{M} \in \{\widetilde{A},\widetilde{B},\widetilde{C}\}\)), we encode it using three vectors of size n as follows. Since \(\widetilde{M}\) is represented by n tuples of the form (ijM(ij)), where each tuple has 3 elements of \(\mathbb {F}\) such that \(M(i,j) \ne 0\). Note that this encoding differs from the encoding in the straw-man where each i and j were encoded using a vector of s elements of \(\{0,1\} \in \mathbb {F}\). The encoding here essentially packs s bits in i (or j) into a single element of \(\mathbb {F}\) in the obvious way, which works because \(s < \log {|\mathbb {F}|}\). In some canonical order, let rowcolval be three vectors that encode the above n tuples such that for \(k \in [0,n-1]\) \(row(k) = i, col(k) = j, val(k) = M(i,j)\).

Encoding metadata for memory checking: “Memory in the head”. The circuit below takes as witness additional metadata about \(\widetilde{M}\) (besides rowcolval introduced above). This metadata accelerates memory checking during the evaluation of \(\widetilde{M}(r)\).

The metadata is in the form of six vectors: \(read\text {-}ts_{row}\in \mathbb {F}^n,write\text {-}ts_{row} \in \mathbb {F}^n\), \(audit\text {-}ts_{row}\in \mathbb {F}^m\), \(read\text {-}ts_{col}\in \mathbb {F}^n,write\text {-}ts_{col} \in \mathbb {F}^n\), and \(audit\text {-}ts_{col}\in \mathbb {F}^m\). We specify how these are computed below with pseudocode. Note that computing this metadata only needs the following parameters: memory size (which is determined by \(2^s = m\)) and the sequence of addresses at which the memory is accessed (which are provided by row and col). In a nutshell, \(read\text {-}ts_{row}\) and \(write\text {-}ts_{row}\) denote the timestamps associated with read and write operations, and \(audit\text {-}ts_{row}\) denotes the final timestamps of memory cells in the offline memory checking primitive  [24, §4.1] for the address sequence specified by row over a memory of size \(m = O(2^s)\). Similarly, \(read\text {-}ts_{col},write\text {-}ts_{col}\), and \(audit\text {-}ts_{col}\in \mathbb {F}^m\) denote timestamps for the address sequence specified by col. They are computed as follows (vec! uses Rust notation).

figure g

Circuit description. The circuit below evaluates a sparse polynomial using the encoding and preprocessed metadata described above. It relies multiset hash functions, which we now define. Unlike ECC-based multiset hash functions in Spice  [73], we employ a public-coin hash function that verifies the desired multiset relationship. Specifically, we define two hash functions: (1) \(h_{\gamma }: \mathbb {F}^3 \rightarrow \mathbb {F}\); and (2) \(\mathcal {H}_{\gamma }: \mathbb {F}^* \rightarrow \mathbb {F}\), where \(\mathbb {F}^*\) denotes a multiset with elements from \(\mathbb {F}\) and \(\gamma \in _R \mathbb {F}\).

$$\begin{aligned} h_\gamma (a,v,t) = a \cdot \gamma ^2 + v \cdot \gamma + t \end{aligned}$$
(2)
$$\begin{aligned} \mathcal {H}_\gamma (\mathcal {M}) = \Pi _{e \in \mathcal {M}}{(e - \gamma )} \end{aligned}$$
(3)

Given \((A,V,T) \in (\mathbb {F}^\ell ,\mathbb {F}^\ell ,\mathbb {F}^\ell )\) for \(\ell > 0\), we define a map \(H_{\gamma }: (\mathbb {F}^\ell ,\mathbb {F}^\ell ,\mathbb {F}^\ell ) \rightarrow \mathbb {F}^\ell \):

$$H_\gamma (A,V,T) = [h_\gamma (A[0],V[0],T[0]), \ldots , h_\gamma (A[\ell -1],V[\ell -1],T[\ell -1])]$$

We capture the soundness errors of these hash functions in Lemma 7.2 and Lemma 7.3.

figure h

Lemma 7.2

For any two pairs \((a_1,v_1,t_1) \in \mathbb {F}^3\) and \((a_2,v_2,t_2) \in \mathbb {F}^3\), \(\Pr _\gamma \{h_\gamma (a_1,v_1,t_1) = h_\gamma (a_2,v_2,t_2) | (a_1,v_1,t_1) \ne (a_2,v_2,t_2)\} \le 3/|\mathbb {F}|\).

Proof

This follows from the Schwartz-Zippel lemma.    \(\square \)

Lemma 7.3

For any \(\ell > 0\), \((A_1,V_1,T_1) \in (\mathbb {F}^\ell ,\mathbb {F}^\ell ,\mathbb {F}^\ell )\) and \((A_2,V_2,T_2) \in (\mathbb {F}^\ell ,\mathbb {F}^\ell ,\mathbb {F}^\ell )\) \(\Pr _\gamma \{\exists i\,{::}\, H_\gamma (A_1,V_1,T_1)[i] = H_\gamma (A_2,V_2,T_2)[i] | (A_1,V_1,T_1) \ne (A_2,V_2,T_2)\} \le 3 \cdot \ell /|\mathbb {F}|\).

Proof

This follows from a standard union bound with the result of the Lemma 7.2.    \(\square \)

Lemma 7.4

For any two multisets \(\mathcal {M}_1,\mathcal {M}_2\) of size \(\ell \) over \(\mathbb {F}\),

Proof

This follows from the Schwartz-Zippel lemma.    \(\square \)

Lemma 7.5

Assuming that \(|\mathbb {F}|\) is exponential in \(\lambda \) and \(n = O(\lambda )\), for any \(2\log {m}\)-variate multilinear polynomial \(\widetilde{M}\) whose dense representation is of size at most n and for any given \(e_{row},e_{col} \in \mathbb {F}^n\),

where \(w = (row,col,val,e_{row},e_{col},{\textsf {MemoryInTheHead}} (m,n,row),{\textsf {MemoryInTheHead}} (m,n,col))\) and (rowcolval) denotes the dense representation of \(\widetilde{M}\).

Proof

This follows from the soundness of the memory checking primitive  [24] and the collision-resistance of the underlying hash functions used (Lemmas 7.4 and 7.3).    \(\square \)

7.2.2 Construction of a Polynomial Commitment Scheme

Given an extractable polynomial commitment scheme \({\textsf {PC}} \) for multilinear polynomials, we build a scheme for sparse multilinear polynomials as follows.

Note that our focus is on designing a polynomial commitment scheme for efficiently realizing computation commitments (Sect. 6). For this purpose, the Spartan verifier runs the \({\textsf {Commit}} \) algorithm (of the sparse polynomial commitment scheme) as part of the \({\textsf {Encode}} \) algorithm, so unlike the general setup of polynomial commitments, the entity creating a commitment is the verifier itself (not an untrusted entity). As a result, the additional memory-checking metadata about the sparse polynomial as part of \({\textsf {Commit}} \) is created by the verifier, so we do not need to verify that the timestamps are well-formed according to its specification in the MemoryInTheHead procedure as required by Lemma 7.5. This is only an optimization and not a limitation. In the general setting where \({\textsf {Commit}} \) (of the sparse polynomial commitment scheme) is run by an untrusted entity, we can require it to additionally produce a proof that proves that timestamps are well-formed. In the description below, given our focus on computation commitments, we omit those proofs.

figure i

Analysis of costs. \(Circuit_{\text {eval-opt}}\) is uniform because computing \(\mathcal {H}\) using a binary tree of multiplications  [78] constitutes nearly all of the work in the above circuit. Figure 5 depicts the costs of \({\textsf {PC}} ^{\textsc {spark}}\) with different choices for \({\textsf {PC}} \).

Fig. 5.
figure 5

Costs of \({\textsf {PC}} ^{\textsc {spark}}\) with different choices for \({\textsf {PC}} \). Here, n is number of entries in the dense representation of the multilinear polynomial.

Lemma 7.6

Assuming that \({\textsf {PC}} ^{\textsc {spark}}.{\textsf {Commit}} \) is run by an honest entity, then \({\textsf {PC}} ^{\textsc {spark}}\) is a polynomial commitment scheme for multilinear polynomials with the costs noted.

Proof

Completeness follows from the completeness of \({\textsf {PC}} \), Hyrax, and \(Circuit_\text {eval-opt}\). Binding follows from the uniqueness of the dense representation of the sparse multilinear polynomial as (rowcolval). Knowledge soundness follows from the witness-extended emulation offered by Hyrax and \({\textsf {PC}} \), and from the negligible soundness error of \(Circuit_{\text {eval-opt}}\) (Lemma 7.5). Finally, the claimed costs follow from the cost model of Hyrax and of \({\textsf {PC}} \) applied to a constant number of \(O(\log {n})\)-variate multilinear polynomials.    \(\square \)

7.2.3 Optimizations

We now describe many optimizations to spark to reduce constants.

  1. 1.

    Instead of using Hyrax as a black box, we tailor it for \(Circuit_{\text {eval-opt}}\) using prior ideas  [78]. This reduces overall costs significantly. We also do not need Hyrax’s zero-knowledge compiler for computation commitments.

  2. 2.

    For computation commitments, we build a single circuit that produces evaluations of \(\widetilde{A},\widetilde{B},\widetilde{C}\) at \((r_x,r_y)\). This enables reusing parts of the memory checking circuit (related to the state of the memory) across evaluations.

  3. 3.

    In our particular context, we can set \(\forall 0\le i < n\): \(write\text {-}ts_{row}[i] = read\text {-}ts_{row}[i] + 1\) and \(write\text {-}ts_{col}[i] = read\text {-}ts_{read}[i] + 1\). This is because unlike the traditional setting of offline memory checking, the read timestamps are not untrusted. This avoids having to commit to \(\widetilde{write\text {-}ts_{row}}\) and \(\widetilde{write\text {-}ts_{col}}\).

  4. 4.

    During \({\textsf {PC}} ^{\textsc {spark}}.{\textsf {Eval}} \), at the witness layer in Hyrax, \(\mathcal {V}\) needs to evaluate a number of multilinear polynomials at either \(r_{row},r_{col} \in \mathbb {F}^{\log {n}}\) or \(r_{mem} \in \mathbb {F}^{\log {m}}\). We avoid having to commit to them by leveraging their succinct representations.

    • \(\mathcal {V}\) can compute \(\widetilde{mem}_{row}(r_{row})\) and \(\widetilde{mem}_{col}(r_{col})\) in \(O(\log {m})\) as follows:

      $$\widetilde{mem}_{row}(r_{row}) \leftarrow \widetilde{\text {eq}}(r_{row},r_x)$$
      $$\widetilde{mem}_{col}(r_{col}) \leftarrow \widetilde{\text {eq}}(r_{col},r_y)$$
    • We leverage the following facts: (1) \(\widetilde{(0,1,\ldots ,m-1)}(r_{mem}) = \sum _{i=0}^{\log {m}}{2^i \cdot r_{mem}[i]}\); (2) \(\widetilde{(0,0,\ldots ,0)}(r_{mem}) = 0\).

  5. 5.

    It is possible to combine k \(\mu \)-variate multilinear polynomials into a single multilinear polynomial over \(\mu + \log {k}\) variables. We employ this technique to reduce the number of committed multilinear polynomials from 23 to 3.

8 Implementation and Optimizations

We implement Spartan as a modular library in about 8,000 lines of Rust including optimizations listed throughout the paper as well as optimizations from prior work  [78, 80, 82, 84, 85]. We find that the prover under spark outperforms the prover under spark-naive by \({>}10{\times }\) for R1CS instances with \(2^{20}\) constraints. We also implement spark with and without our optimizations. At \(2^{20}\) constraints, our optimizations reduce proof lengths from 3.1 MB to 138.4 KB, a improvement of \(23{\times }\); our optimizations also improve prover and verification times by about \(10{\times }\).

In the next section, we present results from spark instantiated with Hyrax-PC  [84] i.e., we evaluate a zkSNARK whose security holds under the discrete logarithm problem. For curve arithmetic, we use curve25519-dalek  [1], which offers an efficient implementation of a prime-order Ristretto group  [2, 53] called ristretto255. The scalar arithmetic in the library is however slow since it represents the underlying scalar elements as byte strings for fast curve arithmetic. To cope with this, we optimize the underlying scalar arithmetic by \({\approx }10{\times }\) by adapting other code  [28].

9 Experimental Evaluation

This section experimentally evaluates our implementation of Spartan and compares it with state-of-the-art zkSNARKs and proof-succinct NIZKs.

9.1 Metrics, Methodology, and Testbed

Our principal evaluation metrics are: (1) \(\mathcal {P}\)’s costs to produce a proof; (2) \(\mathcal {V}\)’s costs to preprocess an R1CS instance; (3) \(\mathcal {V}\)’s costs to verify a proof; and (4) the size of a proof. We measure \(\mathcal {P}\)’s and \(\mathcal {V}\)’s costs using a real-time clock and the size of proofs in bytes by serializing proof data structures. For Spartan, we use cargo bench to run experiments, and for baselines, we use profilers provided with their code.

We experiment with Spartan and several baselines (listed below) using a Microsoft Surface Laptop 3 on a single CPU core of Intel Core i7-1065G7 with 16 GB RAM running Ubuntu 20.04 atop Windows 10. We report results from a single-threaded configuration since not all our baselines leverage multiple cores. As with prior work  [16], we vary the size of the R1CS instance by varying the number of constraints and variables m and maintain the ratio n/m to approximately 1. In all Spartan experiments \(|io| = 10\).

Baselines. We compare Spartan with the following zkSNARKs and NIZKs.

  1. 1.

    Groth16  [51], the most efficient zkSNARK with trusted setup based on GGPR  [47].

  2. 2.

    Ligero  [3], a prior proof-succinct NIZK with a light-weight prover.

  3. 3.

    Hyrax  [84], a prior transparent zkSNARK that achieves sub-linear verification costs for data-parallel computations.

  4. 4.

    Aurora  [16], a prior proof-succinct NIZK.

  5. 5.

    Fractal  [36], a recent transparent zkSNARK that instantiates computation commitments to achieve sub-linear verification costs.

We provide a comparison with additional baselines in an extended report  [72].

Methodology and parameters. For , we report results from two variants: Spartan\({\textsc {snark}}\) (which incurs sub-linear verification) and Spartan\({\textsc {nizk}}\) (which incurs linear-time verification). This is because several baselines offer only a linear-time verifier. Also, for data-parallel workloads, the NIZK variant depicts the performance that Spartan\({\textsc {snark}}\) can achieve for the prover and proof sizes since Spartan\({\textsc {snark}}\) can amortize the costs of computation commitments across data-parallel units.

For Groth16, we benchmark its implementation from libsnark with bn128 curve  [64].

For Hyrax, we use its reference implementation with curve25519  [62]. To compare Spartan with Hyrax, we transform R1CS instances to depth-1 arithmetic circuits where the circuit evaluates constraints in the R1CS instance, and outputs a vector of zeros when all constraints are satisfied. For an arbitrary R1CS instance, this circuit has no structure, and hence Hyrax incurs linear-time verification costs.

For Ligero, Aurora, and Fractal, we use their implementations from libiop with a prime field of size \(\approx 2^{256}\)  [63]. The implementations of Aurora and Fractal support two sets of parameters: proven and non-proven (also known as heuristic). The default choice in their code is the heuristic parameters, which rely on non-standard conjectures related to Reed-Solomon codes (e.g., in the FRI protocol) for soundness  [10, Appendix B]. Concretely, the heuristic parameters use \({\approx }10{\times }\) fewer query repetitions of FRI compared to the proven parameters. As expected, the heuristic versions achieve \({\approx }10{\times }\) lower verification costs and proof sizes than the corresponding provable versions. Note that very recent work makes progress toward proving some of these heuristics  [11].

9.2 Performance Results

Prover. Figure 6 depicts the prover’s costs under Spartan and its baselines. Spartan outperforms all its baselines. When compared to the most closely related system, Spartan\({\textsc {snark}}\) is \(36{\times }\) faster than Fractal at \(2^{18}\) constraints.Footnote 4 When we compare Ligero, Aurora, and Hyrax with Spartan\({\textsc {nizk}}\) (since all of them are proof-succinct NIZKs and incur linear-time verification costs), Spartan\({\textsc {nizk}}\) is \(24{\times }\) faster than Ligero, \(152{\times }\) faster than Aurora, and \(99{\times }\) faster than Hyrax at \(2^{20}\) instance sizes. Finally, compared to Groth16, Spartan\({\textsc {snark}}\) is \(2{\times }\) faster and Spartan\({\textsc {nizk}}\) is \(16{\times }\) faster for \(2^{20}\) constraints.

Fig. 6.
figure 6

Prover’s performance (in seconds) for varying R1CS instance sizes under different schemes.

Proof sizes. Figure 7 depicts proof sizes under Spartan and its baselines. Although Spartan\({\textsc {snark}}\)’s proofs are asymptotically larger than Fractal (Fig. 2), Spartan\({\textsc {snark}}\) offers \({\approx }23{\times }\) shorter proofs at \(2^{18}\) constraints. When we compare the proof-succinct NIZKs, Spartan\({\textsc {nizk}}\) offers proofs that are 1.2–416\({\times }\) shorter than its baselines. All transparent zkSNARKs produce orders of magnitude longer proofs than Groth16.

Fig. 7.
figure 7

Proof sizes in KBs for various zkSNARKs. Entries with “M” are in megabytes. The proof sizes under Groth16  [51] is 128 bytes for all instance sizes.

Verifier. Figure 8 depicts the verifier times under different schemes. Groth16 offers the fastest verifier, but it requires a trusted setup. Among schemes without trusted setup, Spartan offers the fastest verifier. Specifically, Spartan\({\textsc {snark}}\)’s verifier is \(3.6{\times }\) faster than Fractal (at the largest instance size Fractal can run), and at \(2^{20}\) constraints, it is \(1326{\times }\) faster than Aurora, \(383{\times }\) faster than Ligero, and \(80{\times }\) faster than Hyrax. This type of performance is expected because Aurora, Ligero, and Hyrax incur linear costs for the verifier whereas Spartan\({\textsc {snark}}\) (and Fractal) incur sub-linear verification costs due to the use of computation commitments, which requires preprocessing the non-io component of an R1CS instance (we quantify the costs of that process below). Among proof-succinct NIZKs, Spartan\({\textsc {nizk}}\) is \(22{\times }\) faster than Hyrax, \(363{\times }\) faster than Aurora, and \(105{\times }\) faster than Ligero at \(2^{20}\) constraints.

Fig. 8.
figure 8

Verifier’s performance (in ms) under different schemes. Entries with “s” are in seconds. The verifier under Groth16  [51] takes \(\approx {}\)2 ms at all instance sizes.

Encoder. Figure 9 depicts the cost to the verifier to preprocess an R1CS instance (without the io component) under Spartan\({\textsc {snark}}\), Fractal  [36], and Groth16  [51]. We do not depict other baselines because they do not require any preprocessing. Spartan\({\textsc {snark}}\)’s encoder is up to \(52{\times }\) faster than Fractal’s encoder and about \(4.7{\times }\) faster than the trusted setup for Groth16 at the largest instance sizes.

Fig. 9.
figure 9

Encoder’s performance (in seconds) for varying R1CS instance sizes under different schemes.