Scalable Zero Knowledge with No Trusted Setup

Abstract

One of the approaches to constructing zero knowledge (ZK) arguments relies on “PCP techniques” that date back to influential works from the early 1990’s [Babai et al., Arora et al. 1991-2]. These techniques require only minimal cryptographic assumptions, namely, the existence of a family of collision-resistant hash functions [Kilian, STOC 1992], and achieve two remarkable properties: (i) all messages generated by the verifier are public random coins, and (ii) total verification time is merely poly-logarithmic in the time needed to naïvely execute the computation being verified [Babai et al., STOC 1991].

Those early constructions were never realized in code, mostly because proving time was too large. To address this, the model of interactive oracle proofs (IOPs), which generalizes the PCP model, was recently suggested. Proving time for ZK-IOPs was reduced to quasi-linear, even for problems that require nondeterministic exponential time to decide [Ben-Sasson et al., TCC 2016, ICALP 2017].

Despite these recent advances it was still not clear whether ZK-IOP systems can lead to concretely efficient succinct argument systems. Our main claim is that this is indeed the case. We present a new construction of an IOP of knowledge (which we call a zk-STIK) that improves, asymptotically, on the state of art: for log-space computations of length T it is the first to $O(T \log T)$ arithmetic prover complexity and $O(\log T)$ verifier arithmetic complexity. Prior IOPs had additional $\mathsf{poly} \log T$ factors in both prover and verifier. Additionally, we report a C++ realization of this system (which we call libSTARK). Compared to prevailing ZK realizations, it has the fastest proving and (total) verification time for sufficiently large sequential computations.

A Standalone Construction

In this section we give an overview of the process leading to the main theorems specified above (Sect. 2.3). For didactic reasons we accompany our description with a simple and concrete “toy” computation as an example, marked in boxed texts, and gloss over some of the (numerous) technicalities (a few examples are discussed in the last part in this section); nevertheless, the same steps apply to more complex computations. Further details and formal definitions appear in the full version of this paper [12].

Many ZKsystems (including ours) use arithmetization, a technique introduced to prove circuit lower bounds [66, 75] and adapted later to interactive proof systems [4, 59]. Arithmetization is the reduction of computational problems to algebraic problems, that involve “low degree” polynomials over a finite field $\mathbb {F}$; in this context, “low degree” means degree is significantly smaller than field size.

The start point for arithmetization in all proof systems is a computational integrity statement which the prover wishes to prove, like the following instance of the CI language (see Remark 1):

For our ZK-STIK and for related prior systems [9, 25, 27], the end point of arithmetization is a pair of Reed-Solomon (RS) proximity testing (RPT) problems⁹, and the scalability of our ZK-STIK relies on a new solution to it—the FRI protocol discussed below [11]. For $S\subset \mathbb {F}$ and rate parameter $\rho \in (0,1)$, the RS code with evaluation domain S and rate $\rho$ is the space of evaluations of low-degree functions over S,

$$\mathsf{RS} [\mathbb {F},S,\rho ]=\left\{ f:S\rightarrow \mathbb {F} \mid \deg (f)<\rho |S|\right\} .$$

The RPT problem for $\mathsf{RS} [\mathbb {F},S,\rho ]$ is one of deciding, with a small number of queries, whether a function $f:S\rightarrow \mathbb {F}$ is a member of $\mathsf{RS} [\mathbb {F},S,\rho ]$ or far from all members of the code in relative Hamming distance.

Our process has 4 parts (see Fig. 5). When reading the description below, the main thing to notice is that from start to end, verification costs are logarithmic in $\mathsf{T}$ (and polynomial in the description of the computation ${\mathsf{C}}$). To see this it is useful to think informally of $\mathsf{T} \gg |{\mathsf{C}}|$, like $\mathsf{T} =2^{|{\mathsf{C}}|}$. In each of the reductions, the verifier receives only an instance (denoted ) as its input, whereas the prover additionally receives a witness (denoted ) for membership of in the relevant language.

Fig. 5.

The reduction from an AIR instance to a pair of RPT problems, solved using the FRI protocol, explained later in this section. Briefly, the Algebraic Intermediate Representation (AIR) is converted via the Algebraic Placement and Routing (APR) reduction to an APR instance. This is reduced via the Algebraic Linking IOPP (ALI) protocol to a pair of RPT problems, which are solved using two applications of the FRI protocol.

Part I. The starting point is a natural algebraic intermediate representation¹⁰ (AIR) of and , denoted . The verifier receives and the prover also receives . Informally, corresponds to the statement (*) and corresponds to an execution trace witnessing correctness of (*), i.e., is a $\mathsf{T} \times \mathsf{a}$ array in which the ith row describes the state of the computation at time i and the jth column tracks the contents of the jth register over time (this column will later give rise to $f_j$). Each entry of this array is an element in the field $\mathbb {F}$. The transition relation of the computation is specified by a set of multi-variate polynomials over variables $X_1,\ldots ,X_\mathsf{a}, Y_1,\ldots , Y_\mathsf{a}$ that correspond to the current state registers (X variables) and next state registers (Y variables). These constraints enforce the validity of the transition from one state to the next.

Notice that can be much smaller than ; this is crucial for (full) scalability because $\mathsf{tv}$ must be bounded by a polynomial in and $\log \mathsf{T}$. Another point to bear in mind is that constructing an AIR for simple computations is straightforward (as shown in our toy example); additional examples appear in Vitalik Buterin’s blog posts I and III on STARKs [32], in the examples in libSTARK [10], and in previous works like [9, Appendix B] and [65].

Part II. We reduce the AIR representation into a different one, in which states of the execution trace are “placed” on nodes of an affine graph, so that consecutive states are connected by an edge in that graph. Informally, an affine graph is a “circuit” that has “algebraic” topology. The process of “placing” machine states on nodes of a circuit is roughly analogous to the process of placement and routing which is commonly used in computer and circuit design, although our design space is constrained by algebra rather than by physical reality. We refer to this particular transformation as the algebraic placement and routing (APR) reduction, and the resulting representation is an APR instance/witness pair . The affine graph will necessarily be quite large, larger than , but the verifier requires only a succinct representation of this graph, via a constant size set of (edge) generators. This succinct representation is crucial for obtaining verifier scalability and avoiding the “computation unrolling” costs incurred by other ZKapproaches. We first explain how a prover computes this transformation, and then address the verifier’s transformation.

The (honest) prover interprets the jth column of the algebraic execution trace as a partial function $\hat{f}_j$ from a domain that is a subset of $\mathbb {F}$ and which maps into the field $\mathbb {F}$. Thus, the prover now interpolates this function $\hat{f}_j$ to obtain a polynomial $P_j(X)$, and then evaluates this polynomial on a different domain $S\subset \mathbb {F}$ of size $|S|=\beta \cdot \mathsf{T}$, to obtain a function $f_j$. The final step of this stage on the prover-side is providing the verifier with oracle access to the sequence $\mathbf {f}=(f_1,\ldots , f_\mathsf{a})$ where $f_i:S\rightarrow \mathbb {F}$, noticing this sequence is an encoding of columns (registers) of the execution trace via RS codewords. (in the ZK-STARK, this oracle access will be realized via Merkle-tree commitments to $\mathbf {f}$).

The verifier, on receiving , computes the size $\beta \cdot \mathsf{T}$ and picks the same domain $S\subset \mathbb {F}$ as the prover (notice S does not depend on ). Then, the verifier computes the succinct set of affine transformations that correspond to edges in the affine graph, and obtains an APR instance, denoted .

The reduction in this step is deterministic on the verifier side, i.e., involves no verifier-side randomness and no interaction; as such, it also has perfect completeness and perfect soundness. On the prover side, randomness is used to create a zero knowledge version of the execution trace, by allowing the prover to use polynomials of degree slightly greater than $\mathsf{T}$, as to allow for Shamir-style secret sharing techniques to hide individual entries of the execution trace.

Part III. The APR representation is used to produce, via a 1-round IOP, a pair of instances of the Reed-Solomon proximity testing (RPT) problem. In our case, the two codes resulting from the reduction are over the same field $\mathbb {F}$ but may have different evaluation domains and different code rates. To maintain verifier scalability, we point out that specifying the code parameters—S and $\rho$, will be done in a succinct manner, one that requires space $\log |\mathsf{T} |$; thus, this part of our construction also supports verifier-side scalability.

The witness in this case is a pair of purported codewords (${f^{(0)}}, {g^{(0)}}$). The first function ${f^{(0)}}$ is simply a random linear combination of $\mathbf {f}$ to which the prover committed in the previous step. The second function ${g^{(0)}}$ is obtained after the various constraints that enforce execution trace validity are randomly “linked” into a single (random) constraint. We thus refer to this step as the algebraic linking IOP (ALI) protocol.

Part IV. In the last step of our reduction, for each of the two functions (oracles) ${f^{(0)}}, {g^{(0)}}$, the prover and verifier interact according to the fast RS IOP of proximity (FRI) protocol from [11] (cf. [12, Appendix B.6]). That protocol has a scalable verifier and query complexity that is logarithmic in the size of the evaluation domain of the code, further establishing verifier scalability. And thus, from start to end, verifier side complexity remains scalable—logarithmic in $\mathsf{T}$ (and polynomial in $|{\mathsf{C}}|$).

Regarding prover scalability, inspection reveals that the main bottleneck in the process is the low-degree extension part, in which each function $\hat{f}_j$ that encodes a register gets interpolated and then evaluated on a domain of size $\beta \cdot \mathsf{T}$. For this part we use so-called additive FFTs; in particular, libSTARK uses the recent innovative algorithm of [56] that performs this computation with $O(\beta \mathsf{T} \log (\beta \mathsf{T}))$ arithmetic operations. All other steps of the prover’s computation are merely linear in $|\mathsf{T} |$; in particular, the FRI computation is such.

In closing we briefly mention some of the subtle issues that were glossed over in our toy example and are discussed at length in our formal proofs, and implemented in the code:

• 1. The toy construction is not zero knowledge, because each entry of $\mathbf {f}$ does reveal some information about $y_0,y_1$. To achieve zero knowledge we slacken the degree constraint on $f_0,f_1$, allowing the prover to sample a random polynomial that agrees with $\hat{f}_0,\hat{f}_1$ on G, and thus hide information regarding $y_0,y_1$ for query-limited verifiers (in a manner resembling Shamir secret sharing [74]).

• 2. We did not enforce the boundary condition stating that the last entry is z. To enforce this, the verifier interpolates a polynomial corresponding to all boundary constraints (in our toy example there is only one such constraint) and “incorporates it” in the proof oracle $\mathbf {f}$.

• 3. Verifier scalability requires that $\mathsf{Zero} _G$ be computed efficiently. This is indeed the case (because G is a subgroup of $\mathbb {F}$), and holds also for additive subgroups (as implemented by libSTARK [10]).

• 4. The toy computation does not make use of random memory access (RAM); maintaining scalability for programs that make significant use of RAM complicates the construction, requiring more elaborate affine graphs that embed DeBruijn switching networks; these issues are addressed by Theorem 2 and its proof.