Sok: vector OLE-based zero-knowledge protocols

A zero-knowledge proof is a cryptographic protocol where a prover can convince a verifier that a statement is true, without revealing any further information except for the truth of the statement. This article is a survey of recent developments in building practical zero-knowledge proof systems using vector oblivious linear evaluation (VOLE), a tool from secure two-party computation. In this work, we attempt to systematize the recent works on VOLE-based Zero-Knowledge proofs and make the state of the art accessible in one document.


Introduction
A zero-knowledge proof is a cryptographic protocol where a prover can convince a verifier that a statement is true, without revealing any further information except for the truth of the statement.More precisely, if x is a statement from an NP language verified by an efficient machine M, then a zero-knowledge proof aims to prove to the verifier that there exists a witness w such that M(x, w) = 1, without revealing any further information about w.We say that the proof is a proof of knowledge, if the prover additionally convinces the verifier that it knows the witness w, rather than just of its existence.For example, a prover can use a ZK protocol to convince others that it knows an input that can cause stack overflow for some public program (e.g., when submitting a bug report to the Common Vulnerabilities and Exposures system) without revealing the input.
This article is a survey of recent developments in building practical zero-knowledge proof systems using vector oblivious linear evaluation (VOLE), a tool from secure two-party computation.This approach offers several advantages: Fast prover.VOLE-based proof systems are scalable, meaning that the computational resources required by the prover and verifier are not much larger than what's needed to verify the statement when given the witness in the clear. 1 Concretely, for statements given in a boolean circuit C, a multi-threaded prover incurs essentially no overhead in wall-clock evaluation time over a single-threaded evaluation of C in the clear.As a more concrete example, the authors of [2] recently demonstrated that evaluating AES as an optimized Cprogram (without using AES-specific CPU instructions) is 50x faster than evaluating AES in the ZK-proof system of [2].
Small memory.An attractive feature of many VOLE-based protocols is their low memory overhead: just as with plain computation, memory requirements are often only proportional to the cost of verifying the statement (given the witness).This is especially useful for complex statements, where for instance, the witness may be so large that it does not fit into memory, even though the proof can be verified efficiently in a streaming manner.
Post-quantum.With the possibility of large-scale quantum computing on the horizon, protocols based on traditional factoring or discrete log assumptions could become insecure to a quantum attacker.VOLE-based protocols, however, are instead based on variants of the learning parity with noise (LPN) assumption, which is related to the hardness of decoding random linear codes and currently believed to be resistant to quantum attacks.
Conceptual simplicity.VOLE-based protocols can be divided into two phases: a preprocessing phase, which usually consists of running the VOLE protocol on random inputs and which is essentially independent of the statement, and an online phase, where the proof takes place.By abstracting away the properties of the preprocessing, the online phase is very simple to describe, and can even be information-theoretically secure.As one of the simplest, practical ways of constructing zero-knowledge proofs for general statements, it may also be a valuable pedagogical resource.
These benefits also come with a few drawbacks, that can be seen as tradeoffs.Firstly, most VOLE-based ZK proofs have a large communication cost, that is, the amount of data sent between the prover and verifier often scales linearly with the size of the circuit that verifies the statement being proven.This inherently means that the runtime of the verifier must also scale linearly.Another possible drawback is that current constructions of VOLE-based ZK require a designated verifier.That is, the verifier must store a private state needed to verify a proof, which cannot be made public.It's therefore more difficult to prove the same statement to many different verifiers, or in public, with these techniques.

Overview of this survey
In this work, we attempt to systematize the recent works on VOLE-based Zero-Knowledge proofs and make the state of the art accessible in one document.
In Sect. 2 we will outline the notation and tools that are the foundation for all VOLEbased ZK.This includes how proven statements can be formalized, the definition of Zero-Knowledge that we achieve as well as an overview of VOLE.
We will then, in Sect.3, introduce a general abstraction that unifies the ideas behind the main VOLE-based ZK proofs into an Arithmetic Black Box, and how most of the ZK constructions follow given access to VOLE.
Section 4 is devoted to the main differences in which existing works implement the Multiplication in the Arithmetic Black Box, which is one of the main sources of interaction in the proof.Here, we give an introduction into how the Wolverine, Mac'n'Cheese, Line-Point ZK and QuickSilver protocols work.Section 5 will discuss how follow-up works have added different operations to the Arithmetic Black Box, thus allowing the prove certain statements more efficiently.This includes ideas such as more efficient proofs of polynomial evaluation, SIMD circuits, disjunctions, conversions or proofs over rings instead of fields.We will moreover consider proofs of RAM programs based on VOLE protocols.
Finally, we will mention some interesting open questions in Sect.6.

Related techniques in ZK
Zero-knowledge proofs were first introduced by Goldwasser, Micali and Rackoff in 1985 [30].Since then, there has been a vast body of research in both theoretical and applied settings.Below, we mention a few of the techniques that are most relevant for those in this survey.For a more in-depth coverage, the ZKProof Community Reference2 aims to give a comprehensive overview of the state-of-the-art.

Garbled circuits
Zero-knowledge proofs based on garbled circuits were first proposed by Jawurek et al. [35], with the key insight that garbled circuits already provide one-sided malicious security and ZK only needs one-sided privacy.It has many advantages of VOLE-based ZK but requires κ bits of communication per AND gate even after optimizations [27,53].More recent works have also expanded this approach to support more efficient disjunctive proofs [33].

MPC-in-the-head
MPC-in-the-head by Ishai et al. [34] is an elegant way of constructing ZK proofs based on secure multi-party computation.Its concrete efficiency was first studied by Giacomelli et al. [29], which has led to a long line of practical ZK proofs in recent years, particularly for designing digital signatures.It could be made non-interactive but often needs communication linear in the circuit size.

SNARKs
In recent years, there has been a large focus on Succint non-interactive arguments of knowledge (SNARKS) [28], which are protocols where the communication complexity, that is, the size of the proof, is very small, potentially even constant size or logarithmic in the witness length.A drawback of most SNARKs is that succinctness comes at the cost of a more expensive prover, which often has super-linear computational complexity (with a few exceptions [31,54]) and large memory requirements (linear to the statement size).

Applications
VOLE-based ZK proofs enjoy high efficiency and scalability: they could prove tens of millions of gates even under a small bandwidth connection and low-configured hardware.As a result, it has the potential to enable many exciting applications.

Proofs of program properties.
When expressing properties about a program formally, automated theorem provers can allow formally attesting the presence of certain properties using a proof π.By encoding the verification of a given proof for a public as the input to a ZK proof system, a prover can e.g.show that a program shows certain information leakage, without revealing the proof π that explains this behavior [43].2. Proofs of machine-learning tasks.Machine-learning tasks often involve sensitive data (e.g.biometric information) or valuable data (e.g., large models) where ZK proofs could help to enhance privacy.Until recent, ZK for ML is limited because statements on ML are usually large.Recent works have shown the feasibility of proving inference of deep neural networks in ZK [37,49].3. Proofs of signature validity on private messages.[45] considers a case where applicants would like to prove their medical qualification without revealing how they qualify and which healthcare provider signed the evidence.This requires proving that a private digital document is signed by someone from an public authorized list and that the same document implies medical validity.4. Proofs of unsatisfiability.The correctness verification of computer programs is commonly done by showing the unsatisfiability of a certain SAT formula, which is decided by the program and the property to be proven.Proving formula unsatisfiability in ZK [38] could enable applications like 1) showing the correctness of a public program without revealing why; and 2) showing the correctness of a private program.

The computational model: arithmetic circuits
The zero-knowledge proofs in this survey are used by a PPT prover P to convince a PPT verifier V that a certain statement is true, and furthermore, that P knows a witness for the statement.This means they are proofs of knowledge.Abstractly, both P and V consider a language L together with a relation R L .For a string x input to both P and V, P will convince V that it knows a w such that (x, w) ∈ R L , i.e. x ∈ L. Here, R L is an NP relation, which means that there exists a Turing Machine (TM) M which, on input x, w, accepts in time poly(|x|) iff x ∈ L. Instead of expressing computation as happening on a Turing machine M, we will require that each x can, in time poly(|x|), be converted into a circuit C over a ring (R, +, ×) whose gates correspond to efficiently computable3 functions defined over R.
We require that C(w) = 0 iff (x, w) ∈ R L , except with negligible probability in κ.This requirement is without loss of generality, as such a circuit can always be constructed using the Cook-Levin Theorem.More concretely, our statements are circuits C over a ring R. We define their semantics as follows: Consider the tuple C = (n in , n out , n g , I, G) where • n in ≥ 2 is the number of input wires, n out ≥ 1 the number of output wires and n g ≥ 1 the number of gates in the circuit.We let n w = n in + n g be the number of wires.• We define the sets I nputs ← {1, . . ., n in }, W ires ← {1, . . ., n w } as well as Out puts ← {n w − n out + 1, . . ., n w } and Gates ← {n in + 1, ..., n w } to identify the respective elements in the circuit.• The poly-time computable function I : Gates → 2 W ires\Out puts identifies the incoming wires for each gate, with the restrictions that: -∀g ∈ Gates : I(g) = ∅.
• The poly-time computable mapping G : Gates → R + → R determines the function that is computed by a gate.We require that 1. ∀g ∈ Gates : The input length of G(g) is identical to |I(g)|.
To obtain the outputs of the above circuit when evaluating it on an input We denote by C(w) the aforementioned evaluation of C on input w.

Zero knowledge proofs for circuits
We define Zero-Knowledge Proofs (of Knowledge) in the Ideal-Real paradigm.Let be an interactive protocol between two PPT interactive Turing Machines (iTMs) P, V.This means that parties might send messages to each other, as well as to idealized functionalities.Define the functionality F ZK as in Fig. 1.
Let A be a PPT iTM algorithm, called the adversary.A is allowed to corrupt either of the parties, or none at all.If a party is corrupted, then A will have full control over that party and be allowed to read all its secrets and send any messages on its behalf.It has to specify in the beginning which party, if at all, A will corrupt.
We define security with respect to a PPT iTM Z called environment.The environment provides inputs to and receives outputs from the parties.Furthermore, the adversary A will corrupt a party in the name of Z.To define security, let • A be the distribution of the output of an arbitrary Z when interacting with A in a real protocol instance .Furthermore, let S denote an ideal world adversary and F ZK • S be the distribution of the output of Z when interacting with parties which run with F ZK instead of and where S takes care of adversarial behavior.Definition 2.1 (Zero-Knowledge Proof of Knowledge) We say that is a Zero-Knowledge Proof of Knowledge if for every PPT iTM A that maliciously corrupts at most 1 party there exists a PPT iTM S (with black-box access to A) such that no PPT environment Z can distinguish • A from F ZK • S with non-negligible probability in κ.

Vector oblivious linear evaluation (VOLE)
A VOLE correlation is a pair of random variables (u, x) and (v, ), where x, u, v are vectors and is a scalar, which are all random subject to the constraint that One party, in our case the prover P, is given u, x, while the verifier V learns (v, ).
We model the generation of VOLE correlations as an ideal functionality F d VOLE , given in Fig. 2.Here d is the length of the vectors u, x, and v.The functionality works over a ring R; in most cases, we require that R is a finite field, but in Sect.5.5 we also discuss how to support non-field rings such as R = Z 2 k , the integers modulo 2 k .On initialization, the functionality samples a MAC key ∈ R t key , where R key ⊂ R for some parameter t ≥ 1 such Fig. 2 Functionality for VOLE over R t with a message from the ring R, and scalar from R t key , where R key ⊂ R that |R t key | is exponentially large in the security parameter.When R is a field, we typically choose R key = R.After initialization, the Extend command may be called repeatedly.On each call, it samples one more "element" of the VOLE correlation, which we view as a MAC M[x] on a random element x given to the prover, where the verifier learns only the corresponding key K [x] (as well as the global key ).
In the rest of this paper, we assume that such a functionality can be efficiently realized using a secure VOLE protocol.To justify this, we outline which approaches currently exist to implement F d VOLE efficiently with active security.

Instantiate F d VOLE directly
The two most popular approaches use linearly homomorphic encryption or OT extension protocols.For homomorphic encryption, the approach is usually that V samples a public key/private key pair, then sends an encryption of to P. P picks x, M[x] and, using the homomorphism, computes an encryption of K [x] that it sends to V. Finally, V can decrypt this result.While it is easy to achieve passive security by rerandomizing the ciphertext containing K [x] appropriately, achieving active security usually requires additional consistency checks such as specialized zero-knowledge proofs.See e.g.[3,20,21] for variants on this approach.An alternative solution is to use Oblivious Transfers to perform the multiplications, leading to highly efficient protocols such as [36,46], or [47] when R is a ring such as Z 2 k .The disadvantage of all these protocols is that the communication between P and V scales at least linearly in the number of VOLE correlations n, which can easily become a bottleneck when a large number of correlations are needed.

Extend VOLEs efficiently
Current state-of-the-art VOLE extension protocols all stem from the approach of Boyle et al. [10], which builds a pseudorandom correlation generator based on (variants of) the learning parity with noise (LPN) assumption.This approach exploits the fact that sparse LPN errors can be used to compress secret-sharings of pseudorandom vectors, allowing the two parties to generate a long, pseudorandom instance of a VOLE correlation in a succinct manner from a short vector of VOLE correlations.These protocols usually proceed along the following lines: Using this blueprint leads to (random) VOLE protocols with communication much smaller than the output length, which is sufficient to build Zero-Knowledge protocols as we shall see.It can be seen as a form of VOLE extension, where in the first step, a small "seed" VOLE of length m n is used to create the single-point VOLEs, and then extended into a longer VOLE of length n.In the Ferret protocol [51], it was additionally observed that when repeating this process, it can greatly help communication if m of the n extended outputs are reserved and used to bootstrap the next iteration of the protocol, saving generation of fresh seed VOLEs whose computation is usually more involved as outlined above.
To use VOLE as part of a ZK protocol, we will need that it is actively secure.If R is a field, then VOLE extension can efficiently be done by picking a protocol such as [11,48].These also allow the secret x to be from a subfield of R, which yields more efficient constructions when the proof circuit is defined over a small field such as F 2 .For R = Z 2 k , the recent work of [1] described how to adapt [10,48] with a consistency check that is secure if the underlying LPN instance tolerates a small amount of leakage on the noise vector.

Schwartz-Zippel Lemma
A crucial building block in all presented protocols is the Schwartz-Zippel Lemma over finite fields, which allows for efficient polynomial identity tests.The version which we use, proven by Ore [42], works as follows:

Homomorphic MACs from VOLE
VOLE can be used to build a simple, information-theoretic MAC scheme with useful homomorphic properties.Prior works have shown numerous MAC schemes with different properties that follow a similar paradigm [6,14,18,19].The MAC scheme is oblivious, in the sense that the prover will hold MACs on certain values, while only the verifier knows the corresponding MAC key.For example, consider running VOLE over a finite field F, i.e.

F d
VOLE with R = F, R key = R and t = 1.A single output from a random VOLE can be seen as a MAC on the value x ∈ F obtained by the prover.The prover also learns the MAC M[x], while the verifier holds the MAC key, which consists of a random K [x] ∈ F and the fixed key ∈ F, satisfying If the prover wants to send x to the verifier, this can be authenticated by additionally sending M[x]: the verifier simply checks the above equation holds.
The MAC cannot be forged with probability larger than 1/|F|.To see this, consider a cheating prover who sends x = x together with a MAC M This implies that the prover must have guessed , by coming up with x , M[x ] that pass the check.Crucially, this check relies on x − x being invertible, which in the given case 4 is of course always true.

Linear homomorphism
Since the MAC equation is linear, and is fixed for every VOLE output, it's easy to see that any public, linear function can be applied to MACs.The parties can also create a MAC on a public constant c ∈ F, by defining M[c] = 0 and K [c] = −c• ; this allows homomorphically computing affine functions.

Multiplicative homomorphism
The MACs are also multiplicatively homomorphic, with the caveat that the storage complexity increases.To see this, let (x, M[x]) held by the prover define a linear polynomial p(s) = M[x] + x • s in s.The verifier then holds the random key , and the evaluation p( ).Now consider a second such MAC on y, and polynomial q(s) = M[y]+ y •s.The product p(s)q(s) is now a degree-two polynomial, whose coefficients are held by the prover.
The drawback of homomorphically multiplying MACs is that the size of the resulting MAC scales with the number of multiplications (i.e. the degree of the function).However, this can still be exploited, as we see in Sects.4.3 and 4.3.3.

MACs over small fields
The approach outlined above does not achieve sufficient security if |F| is small.For example, when F = F 2 , the MAC only delivers 1 bit of security!Luckily, the approach generalizes to arbitrary t > 1. Namely, let R key = R t where R = F for an arbitrary finite field.The same security argument as before does apply: if a cheating prover who sends x = x together with a MAC M[x ] succeeds in verification, then we have M which can be computed over R t by coordinate-wise division by x − x .Therefore, a forgery can now only happen with probability 1/|F| t .F d VOLE for this setting can efficiently be instantiated by considering R as a subfield of R t using the machinery from [12].It also lends itself to updates on the MACed value x with low communication, since only a value over R but not R t must be communicated to do so.The linear homomorphism of the MAC scheme again follows directly from its setup.By considering R t as the degree-t extension field of R instead of just a vector space, the multiplicative homomorphism (and how it is exploited in this work) can also be recovered.
In Sect.5.5, we show how this type of homomorphic MAC can also be made to work over rings, with some differences to the soundness guarantees and repercussions on ring size.

Arithmetic black box for ZK
The functionality F ZK introduced in Fig. 1 is only able to process a circuit C over a ring in a block.However, VOLE-based ZK can often provide a more flexible functionality where parties can prove the circuit progressively in a gate-by-gate manner.This is crucial e.g. for memory-friendliness, since wires which are no longer needed can be dropped from memory.To abstract this capability in VOLE-based ZK, we now refine F ZK into F ABB in Fig. 3 which performs exactly this job.To use F ABB to realize F ZK , two parties can use the Input to obtain handles to the committed witness; then they can traverse the circuit following topological order: each linear gate can be computed using Affine combination and each non-linear gate can be computed using multiplication check.In the end, two parties hold a handle for the output wire which can be asserted using CheckZero.
This functionality F ABB is what protocols such as [2,48] and follow-ups actually implement.Their observation is that Vector-OLEs output by F d VOLE can be used to securely store inputs by P such that linear functions of secrets can be computed without interaction.In the following, whenever a value x is stored inside F ABB , then we denote it as [x].This is equivalent to the value x being MACed (as outlined in Sect.3.1), which is why the same notation is used.If R = Z s for some s ∈ N, then we write [x] s to clarify the modulus used in F ABB .We leave out the subscript if the ring is clear from the context.
To realize F ABB for the case where R = F, both parties initially call Init of F d VOLE to make commitments available.Then they proceed as follows.Random

The parties call Extend on F d
VOLE and assign the returned (r , ) the id id.
Check Zero If only one id needs to be checked, then this can be done as follows: If more than one id needs to be checked, then P, V can also apply a Collision-Resistant Hash Function to compress their values and save communication bandwidth.
If either of these is undefined, or id 0 is already defined, then abort.

P locally sets x
In the case where R = F then one can easily write a simulator, following Definition 2.1, to show that the aforementioned subprotocols implement the desired parts of the functionality F ABB securely.The main idea is that V does not learn any information, since the outputs of VOLE leak no information about the outputs given to P, while every input during Input is blinded using a uniformly-random value from F d VOLE .Affine Combination is entirely noninteractive, while the value that V obtains during Check Zero is predetermined.A cheating P can only change the outputs during Check Zero such that V accepts a non-zero value, but as shown in Sect.3.1, this reduces to P being able to guess .This value is never revealed to P by F d VOLE , which finishes the claim.The exact details are shown in the referenced works 5 .

Fig. 4 The Wolverine multiplication check protocol
What is left to implement is the Multiplication Check of F ABB .This is actually the core of much of the early work on VOLE-based Zero Knowledge.We will summarize the state-of-the-art in the following section.

Wolverine multiplication check
The Wolverine multiplication check protocol [48] can be viewed as a direct application of the bucketing technique introduced in the context of malicious secure computation [19,40,41].The only difference is that only the prover has a privacy requirement (i.e.zero-knowledge) and thus the bucketing only needs to be done for one layer.In more detail, the protocol proceeds in the following steps: 1. Given a list of authenticated tuples to be checked, two parties generate n B + c number of extra random authenticated multiplication tuples that are correct if the prover is honest.2. The verifier randomly picks c tuples out of the n B + c newly generated ones and checks if they have the correct relationship.If so, the remaining n B random authenticated multiplication triples must have a high proportion of good triples.Since all tuples are committed, the check can be done at the end of the protocol as well.
3. For the remaining n B triples, the verifier specifies a random permutation to group them randomly into n buckets each with B triples per bucket.4. For the i-th input triple, all triples in the i-th bucket are "sacrificed" to check the correctness one at a time.The sacrifice procedure does detect cheating unless both the "input" triple and the "sacrificed" triple are incorrect simultaneously.
Details of the protocol can be found in Fig. 4. A careful analysis shows that by setting c, B appropriately, we can ensure that the proportion of incorrect triples that survive after step 2 of the outlined protocol is low.Then, with overwhelming probability during Step 4 not all B "sacrificing" tuples in a bucket can be faulty, as the permutation is chosen at random.Therefore, if any "input" multiplication tuple was faulty, it would be detected during Step 4 and the check would fail.In summary: Theorem 4.1 For any field R = F and integer t and if c ≥ B, the protocol in Fig. 4 securely instantiates CheckMult in Fig. 3 with statistical error of 1/ B + O( /|F| t ).

Mac'n'Cheese multiplication check
The protocol from Sect.4.1 requires 3B sent ring elements per verified multiplication.We now discuss two different approaches.The first only sends 2 ring elements per multiplication check for large fields and builds on Beaver's circuit randomization technique [5].The second builds on a protocol from Boneh et al. [9], where the idea is to reduce proving n multiplicative relations to checking a dot product of length n.This comes at the cost of communicating n + O(log(n)) R-elements.In particular, for R = F p for p = 2 61 − 1 their protocol requires around 64.3 bits of communication per multiplication.

Warm-up: multiplication checks using circuit randomization
Consider P has created

Assume that e•[z]−[c]−ε[y]
is indeed a commitment to 0. Then once can easily show that this implies that eδ = γ , implying that e = γ /δ for γ, δ that P has to choose before it knows e.This in turn only succeeds with probability 1/ p k , as e is chosen uniformly at random.Therefore, for small fields this test has to be repeated multiple times to achieve low enough soundness error.

Multiplication checks via inner product checks
Boneh et al. [9] introduce a logarithmic-sized proof for "parallel-sum" circuits.In a "parallelsum" circuit, identical subcircuits C are evaluated in parallel on possibly different inputs, with the sum of the outputs of each C being the output of the overall circuit.The high-level idea of the proof protocol is to embed checks for different instances of C within a single polynomial, allowing V to verify n instances of C in parallel.When letting C be a single multiplication of its two inputs, can then be used to simultaneously verify the sum of n multiplications, which is equivalent to a dot product.Denote the protocol that checks the dot product AssertDotProduct.
The AssertDotProduct protocol works as follows.Suppose P wants to prove that . P begins by defining n polynomials f 1 , . . ., f n/2 , g 1 , . . ., g n/2 such that f i ( j) = x ( j−1)n/2+i and g i ( j) = y ( j−1)n/2+i for j ∈ {1, 2}, and then computing h = i∈[n/2] f i g i .P then commits to h by committing to its coefficients (denoted as [h]).V defines its own polynomials f i , g i over the values [x ( j−1)n/2+i ] and [y ( j−1)n/2+i ] that are stored in F ABB to check that i∈[n/2] f i g i = h.By Schwartz-Zippel, this can be done by checking that for a random r chosen by V. Here, observe that the evaluation of f i , g i , h in a public constant r boils down to multiplying the committed coefficients of each polynomial with appropriate powers of r and summing up the result, both of which are linear operations in F ABB that do not require any interaction.Then, verifying the above equation after fixing r is again a dot product check, although over vectors of length n/2, and we can recursively apply AssertDotProduct until n is of constant size.Note that only 4 R-elements are communicated during one iteration of AssertDotProduct: 3 when committing to h and one when sending r .See Fig. 5 for a formal presentation of the protocol.There, for the base-case of AssertDotProduct, one can e.g.use the multiplication checking procedure from Sect.4.2.1.
Given AssertDotProduct, we can batch-verify n multiplications as follows: 1. Assume that n tuples [x i ], [y i ], [z i ] have been committed by P.
2. V chooses a randomization factor r that it sends to P. 3.
This protocol, called AssertMultVec, is presented in Fig. 5.
It is clear that both AssertDotProduct and AssertMultVec are complete and zeroknowledge.The following theorem, proven in [2], shows they are also sound.The number of rounds of interaction in AssertDotProduct is logarithmic in the number of multiplications n. [2] also show that, using the Fiat-Shamir transform [25], the number of rounds can be made constant by assuming a random oracle.
An alternative version of AssertMultVec with a soundness error that is only logarithmic in n can be achieved as follows: One can easily show that AssertMultVec has the desired soundness, although at the expense of communicating more random elements from V to P. In practice, one can optimize this by having V choose a random PRG seed that it sends to P, with r 1 , . . ., r n derived deterministically from the seed.

LPZK multiplication check
The Line Point Zero Knowledge (LPZK) work of [23] introduces the concept of an LPZK proof system, where the prover constructs a line and the verifier queries a single point on Fig. 5 Protocols for efficient multiplications.See text for necessary notation that line, and determines from this point whether to accept or reject the proof (see Fig. 6).This geometric presentation emphasizes the simplicity and algebraic character of the VOLE commitment scheme, which will be used in a non-black box construction.
In the LPZK multiplication check, the witness and all intermediate wire values are stored in the vector a (see Fig. 6).The underlying intuition is that the verifier will perform a series of calculations on the vector v := aα + b and the prover will mirror the verifier by performing the same calculations on the vector of formal polynomial expressions given by at +b, treating t as an indeterminate.
The results of these calculations are a collection of values held by the verifier that are the evaluations at α of corresponding polynomials held by the prover.Conditions on the coefficients of these polynomials correspond to conditions on the vectors a, b, and so can be used to prove that the extended witness satisfies the desired relation.Concretely, the LPZK multiplication check builds a series of quadratic polynomials (one per multiplication gate) whose leading coefficients are zero if and only if the corresponding gates are evaluated correctly.The resulting "polynomial checks" we need to verify these coefficients are zero can be efficiently batched together, saving on communication.for the line held by the prover, and v = aα + b for the point received by the verifier, for a random α ∈ F. We likewise write the prover's view of the entries as and write v i for v i (α).The verifier now checks whether If the prover is honest, we have identically, as long as x y − z = 0.In other words, v 1 v 2 − αv 3 − v 4 is a quadratic in α that is identically zero if and only if the prover is honest.For a cheating prover, v 1 v 2 − αv 3 − v 4 will be equal to some nonzero polynomial in α, and so breaking the binding property would be equivalent to P guessing α, while breaking soundness would be equivalent to P constructing a polynomial of degree 2 which has α as a root, which gives binding and soundness error ≤ 2/|F|, by the Schwartz-Zippel Lemma, as desired.Note that this is a special case of the LPZK construction sketched above, since being identically zero is a stronger condition than having a zero leading coefficient.
When constructing LPZK from a random VOLE, this protocol requires communication for each entry of a and b which cannot be set randomly by the prover.Here, we require communication of five field elements: four elements for the values a 1 , . . ., a 4 and an additional element of communication for the value b 4 .

Polynomial checks
To emphasize the similarity of the one gate example to the IT-MAC that we defined in Sect.When extending this construction to a larger circuit, we generate an authenticated wire [w] for each input wire and each output wire of a multiplication gate, and get authentications of the remaining wires from affine transformations.There are then two variant LPZK protocols, one with information theoretic security without a random oracle, and one in the random oracle model, which we call IT-LPZK and ROM-LPZK.
In both protocols, the prover constructs some quadratic polynomial in for each multiplication gate, and the verifier learns the evaluation of those polynomials.The 2 coefficient of the polynomial is the value x y − z, so if the prover is honest, the polynomial will be degenerate.For IT-LPZK, the polynomial will also have zero coefficient, that is, the polynomial constructed by an honest prover is equal to a constant.For ROM-LPZK, the polynomial is linear.
For the ROM-protocol, the degenerate polynomial held by the prover is which will be linear if x y = z, with the prover holding the coefficients of the linear polynomial and the verifier holding the evaluation at .For the IT-LPZK protocol, we set from this polynomial, so that the prover and verifier hold the putative constant We therefore need two gadgets for ROM-LPZK and IT-LPZK that certify that a batch of quadratic polynomials are degenerate and actually of degree 1 or degree 0, respectively.In the IT-LPZK protocol, we treat multiplication gates in batches of size n, (not necessarily equal to the total number of multiplication gates in the circuit) resulting in a soundness error of 2n/|F|.For each batch of n gates x i y i = z i , the prover authenticates an additional , so that the prover holds (u i , M[u i ]) and the verifier holds The verifier then computes the product of n successive instances of the polynomial above where ι is the identity function on nonzero values, with ι(0) = 1 to ensure the product is nonzero.The prover sends the term m : , and the verifier aborts if m = m.
The value the verifier has computed is now the evaluation of a polynomial of degree 2n, which is a constant polynomial if and only if the prover acted honestly on each of the n gates Fig. 7 The LPZK and QuickSilver multiplication check protocols in the batch.Otherwise, a cheating prover must construct a non-constant polynomial that has as a root, and we can apply the Schwartz-Zippel lemma as above to bound the binding and soundness error.The correctness and security are proven in [23].

QuickSilver extension
The circuit-based QuickSilver [52] multiplication check can be viewed as an extension of the ROM version of the Line-Point ZK protocol [23] to support any field.We provide an overview of the protocol.The key idea to support any field size is by extending the checking on an extension field of the original field.We will abuse the notation and use F t to also refer to the extension field; this means that multiplications between two F t elements are performed according to field-extension multiplication.For each multiplication gate, the prover P has , ∈ F t such that the following four equations hold: If P is malicious, the first equation could potentially be incorrect and the main task is to check that this relationship holds for all multiplication gates.Although the last three equations are linear equations from the perspective of the verifier, the first equation is not linear.The crucial observation from line-point ZK is that it is possible to convert the non-linear checking to a linear checking.Specifically, for the i-th multiplication gate with wire values (x, y, z), if it is computed correctly (i.e., z = x • y), then we have: known to P denoted as A 0,i We can see that the above relationship is now linear and very similar to the IT-MAC relationship.What's more, if the underlying wire values (i.e., x, y, z) are not computed correctly, then the above relationship can hold only with probability 2/|F| t due to Schwartz-Zippel lemma: now it becomes a quadratic equation of , where there are at most two values of that satisfy the equation.Now when we look at a circuit with t multiplication gates, we can obtain one such relationship for each multiplication gate.Namely, for each i ∈ [n], P has A 0,i , A 1,i ∈ F t and V has B i ∈ F t such that B i = A 0,i + A 1,i • .We can check all t linear relations in a batch using a random linear combination.In particular, the verifier samples a uniform element χ ∈ F t after the above values have been defined, and then checks that the following relationship holds: By the verifier sending just one field element (i.e., χ), we are able to reduce checking t equations in the circuit to checking the above single equation, that is B = A 0 + A 1 • , where V has B and , while P has A 0 and A 1 .This could be easily checked by using a random linear relationship B * = A * 0 + A * 1 • with B * , A * 0 , A * 1 ∈ F t to mask field elements A 0 and A 1 , and then opening the masked elements.In particular, P sends U = A 0 + A * 0 and V = A 1 + A * 1 to V, who checks that B + B * = U + V • .Finally, this random linear relationship over F t can be easily obtained by generating subfield VOLE correlations on F p and packing them to F t .
The details of the protocol can be found in Fig. 7 and we have the following theorem.
Theorem 4.4 For any field F and integer t, the protocol in Fig. 7 using Step 2 securely instantiates CheckMult in Fig. 3 with statistical error of (n + 3)/|F| t .
Note that the online phase of the ZK protocol where the circuit and witness are known, can be made non-interactive by computing χ using a random oracle to hash the transcript up to that point when |F| t ≥ 2 κ .

Comparing the multiplication check protocols
To compare the different Multiplication check protocols presented in this section, we focus on the number of communication rounds as well as elements in R that have to be sent per verified multiplication.Moreover, since Wolverine and Mac'n'Cheese become more efficient as n increases, we assume n = 1, 000, 000.
In the arithmetic case, i.e. when R = Z p for a large p, Wolverine has to send 4 R-elements per multiplication, to achieve statistical security 2 −40 with B = 3.The warm-up version of Mac'n'Cheese (Sect.4.2) reduces this to 3 elements.The interactive versions of LPZK & QuickSilver only need to communicate 1 R-element per multiplication in 3 rounds of interaction, while the non-interactive and information-theoretic version of LPZK communicates 2 R-elements.In comparison, using the batch multiplication check in Mac'n'Cheese gives an amortized communication cost of 1 R-element per multiplication and requires 17 rounds with n = 1 000 000.Note that all of these protocols can be collapsed to be non-interactive (excluding the VOLE preprocessing) in the random oracle model using the Fiat-Shamir transform.The main advantage of Mac'n'Cheese over QuickSilver (which has better concrete and asymptotic performance) is that it supports so-called stacking proofs (see Sect. 5.3) which are not known to carry over to QuickSilver as easily.If R = Z 2 , i.e. for binary circuits, then Wolverine for n = 1, 000, 000 has to communicate 7 bits per proven multiplicative relation.In comparison, QuickSilver and Mac'n'Cheese both take approximately 1 bit.LPZK, on the other hand, only supports computations over large fields.
In terms of practical performance, [2] argue that QuickSilver shows approximately twice the throughput in proven multiplicative relations per time unit in comparison to Mac'n'Cheese.They caution, though, that the systems have not been compared on identical hardware.The benchmarking of [22] shows that the information-theoretic version of LPZK is twice as fast as the interactive version of LPZK in terms of online computational costs, perhaps due to eliminating the cost of invoking a hash function, and only around 2.5× slower than evaluating the circuit in the clear.

Extensions
In Sects. 3 and 4, we provided an overview how to efficiently prove any computation provided that it can be written as a circuit over a field with linear and degree-2 multiplication gates only.However, in many settings, representing the statement as a such a circuit may not be ideal: 1) this specific circuit representation may be huge and thus lead to high overhead in the proof as it has to fit into this specific representation; 2) it prevents us from designing customized gadgets and gates that exploit the semantics of the problem and could be potentially more efficient than degree-2 circuit-based protocols.
In this section, we discuss efficient gadgets that are out of the regular degree-2 circuitmodal computation.The modular design of our approach means that these gadgets can be integrated with the main protocol easily, and can e.g.be expressed as higher-degree gates which the model from Sect.2.1 permits.

Low-degree polynomials proofs
We introduce proofs for low-degree polynomials from [52].As a starter, let us first generalize the multiplication check in Sect.4.3.3 to prove an inner product between two vectors with communication of 1 field element.

Proving degree-2 polynomials
Let f be a degree-2 polynomial such that f (x 1 , . . ., Both parties hold authenticated values [w 1 ], . . ., [w n ], and the prover wants to prove f (w 1 , . . ., w n ) = 0. Using a circuit-based approach, this would need n/2 multiplication gates and thus at least n/2 communication.Here, we show a protocol that can use less communication: Observe that The last equation is due to the fact that f (w 1 , . . ., Reorganizing the above equation a bit, we can obtain the following: This is still a linear relationship B = A 0 + A 1 • , which could be proven just as in the Quicksilver protocol.Essentially, we can prove a degree-2 polynomial with n/2 multiplications with a communication cost of just O (1), in addition to the cost of committing the witness.This is independent of the number of multiplications in the polynomial, which could be as many as n/2 = O(n).One immediate observation is that if we have t such polynomials to be proven, the total communication cost is still O(1) rather than O(t), by using the same random-linear-combination idea to reduce all linear checks to a single check.

Generalizing to any low-degree polynomial
Now we generalize the above to support checking of low-degree polynomials.We assume that the witness is (w 1 , . . ., w n ) ∈ F n ; there are t polynomials to be proven and each multivariate polynomial f i (X 1 , . . ., X n ) over F has a degree at most d.The prover wants to prove that f i (w 1 , . . ., w n ) = 0 for all i ∈ [t].Below, we show how to prove such polynomial set in communication of d field elements over F t , in addition to the n field elements over F to commit the witness.For every n-variable d-degree where g h is a degree-h polynomial such that all terms in g h have exactly degree h.Here we assume that each polynomial f has been written in a "degree-separated" format, and thus do consider the computation of this decomposition to be beyond scope.
We write each polynomial in a "degree-separated" format and shift each sub-polynomial.The verifier now computes Here A j h is defined as above, and A h is the aggregated coefficient for all terms with h .Note that the prover with witnesses w i and MACs M[w i ] can compute all the coefficients locally.The coefficients A h are polynomial coefficients when we treat it as a single-variable polynomial on .Therefore, the prover can compute all A h efficiently by evaluating the polynomial on d + 1 points and then computing the polynomial coefficients using Lagrange interpolation.In many practical applications, the polynomial is usually simple and thus the coefficients can be derived without using the above generic approach.This relationship can be viewed as an oblivious polynomial evaluation (OPE), where the verifier has and the prover has a polynomial P(x) = h∈[0,d−1] A h • x h over F t .The verifier wants to check that the resulting evaluation in the above equation is the same as P( ).It is not hard to check the above polynomial relation, as sVOLE can be used to generate (V)OPE in an efficient way.Similarly, we can perform the checks for all t polynomials in a batch using a random linear combination.This results in a total communication of (n +dr) log |F| bits in the F d VOLE -hybrid model.When using the interpolation approach to compute the coefficients A h , we have that the computational cost of the prover and verifier is O(td 2 z + dn) and O(tdz) respectively, where z is the maximum number of terms in all t polynomials.

LPZKv2
The follow-up work to LPZK, [22], presents another extension of of VOLE-based ZK that uses an extension of the VOLE correlation and is specialized for particular circuit formats.LPZKv2 improves the online communication cost of LPZKv1 by a factor of roughly two for both the information-theoretic and random oracle variants (IT-LPZKv2 and ROM-LPZKv2, respectively).
There are two technical ideas that enable the improvements of LPZKv2 over LPZKv1.The first technical idea is to store the message in the constant term of the VOLE, instead of the linear term, i.e. to write Storing the value in the constant term instead of the linear term reduces the verifier's computation, since on the step Input of F ABB described in 3.2, when the P sends δ Because each multiplication gate requires an additional call to Input, this change reduces the verifier's computation by one multiplication per gate in both the information theoretic and random oracle variants.
The second technical idea is the use of an extension of VOLE, quadratically certified VOLE, or qVOLE, which allows for the imposition of additional quadratic relations on the entries of an instance of random VOLE.These quadratic relations essentially allow certain terms needed in LPZK to be precomputed, reducing the communication and computation required in the online step.For example, using qVOLE, we could generate three authenticated random values ([ p], [q], [r ]) with the guarantee that the quadratic relation is a polynomial with zero 2 coefficient.This property still holds after calling the modified Input protocol described above to shift ( p, q, r ) → (x, y, r ), a fact which we use extensively in the construction below.
The qVOLE functionality can be realized either by bootstrapping off of an existing instance of VOLE, which requires a linear amount of communication in the preprocessing phase (effectively pushing 50% of the communication of LPZKv1 to an offline phase).Alternatively, we can use ring-LPN to give a sublinear-communication qVOLE generation protocol that is concretely efficient in the SIMD setting or for circuits with repeated subcircuits (such as hash trees).

General circuits
The information-theoretic protocol IT-LPZKv2 can be used efficiently with general circuits by realizing the qVOLE functionality by bootstrapping off of an existing instance of VOLE.Then IT-LPZKv2 requires 1 + 1 n elements of communication in the online phase, nearly matching the communication cost of ROM-LPZKv1, Quicksilver or Mac'n'Cheese over large fields.Here n is a constant representing batch size, as in IT-LPZKv1.For a multiplication gate x y = z, we have where the leading coefficient can be pre-computed from the qVOLE functionality, and the constant coefficient x y = z is the constant coefficient of the authenticated output value z] will be a linear polynomial in with zero constant term, which can be checked using the same batched proof given in Step 3 of Fig. 7. Therefore the total online communication cost is 1 element for K * [z] and an amortized cost of 1/n per gate for the batched proofs.Additionally, 1 element of communication per gate is required in a preprocessing step for the generation of the values K * [r ].

Layered circuits and other specialized circuits
As mentioned above, both IT-LPZKv2 and ROM-LPZKv2 give efficiency gains in the SIMD setting or for circuits with repeated subcircuits, since then qVOLE functionality can be efficiently realized using Ring-LPN.Additionally, the polynomial techniques described above allow us to extend the LPZKv2 constructions from arithmetic circuits containing only fan-in 2 addition and multiplication gates to circuits with arbitrary degree 2 polynomial gates.
The ROM-LPZKv2 protocol offers some additional speed-up in online communication time for a broad class of circuits with a certain colorability property described below.
The key observation behind the ROM-LPZKv2 protocol change is that the expression K * [x]K * [y] − K * [ p] is a linear polynomial with constant term x y, and so already represents an authentication of x y without any communication required at all.However, for the authenticated value , which depends on the prover's input.Therefore if we wish to use z as the input wire to another multiplication gate with inputs z, t the prover can no longer compute the quadratic coefficient M * [z]M * [t] using only precomputed randomness.This is the motivation behind the colorability property.
For the coloring, we use the color red to denote wires for which the value M * [t] is determined purely by the correlated randomness, and use blue to denote wires for which the value M * [t] depends on the prover's input.Color the input wires red, then color the remaining wires of the circuit such that, for any degree 2 polynomial gate with all blue inputs, or a mix of blue and red inputs, the output wire is red, while for a gate with all red inputs, the output wire may be red or blue.Then the communication cost of ROM-LPZKv2 under this coloring is equal to the number of red wires.
For layered circuits, where each gate is assigned to some layer k, and all the inputs to gates at layer k are outputs to gates at layer k − 1, either all odd layers or all even layers can be colored red, so the amortized communication per degree 2 polynomial gate is at most 1  2 elements of communication per gate in a layered circuit.For a broad class of nonlayered circuits, substantial savings are also possible.For example, as described in [22], for a random circuit made up entirely of multiplication gates and colored with a greedy algorithm, approximately 38% of the wires will be blue, so that one can achieve an approximately 38% reduction in communication.

Disjunctions and r-out-of-n proofs
[2] consider the setting where both P and V agree on m circuits C 1 , . . ., C m that define protocols based on a committed vector [w].Let these protocols each be public coin HVZK proofs over the same field F p k .For this, they construct a communication-efficient protocol showing that from [w] one can extract a satisfying input w i * to at least one of the circuits.
The classic OR-proof technique by Cramer et al. [16] can be used to construct such a proof with message complexity ≈ i∈[m] α i where α i is the communication necessary for the proof i of C i .This would be done by running all m proofs for all circuits in parallel (which means sending messages for evaluating all of them) and having their outputs being committed as [y 1 ], . . ., [y m ].The prover would then show that at least one finished successfully with the expected output using the OR-proof of [16] on [y 1 ], . . ., [y m ]. [2] show how to reduce the message complexity of such a proof to 2mk + max{α i }, where the soundness error grows by an additional additive ≈ p −k .What is required for the technique of [2] to work is that all messages from the prover in each protocol i appear uniformly random.Moreover, they require that protocol messages in each round are of identical length, for any i , j .Towards this, observe that it is always possible to defer zero-tests in a protocol i that relies on F ABB to the end, as a verifier doesn't have a secret that could be leaked through late application of the zero check.Achieving messages of identical length (and same number of rounds in each i ) can be achieved using padding.At the same time, not all implementations of F ABB are compatible with the requirement that messages from the prover are uniform, even with padding: The multiplication checks from Sects.4.1 and 4.2 reduce to the prover making auxiliary commitments, the verifier sending random challenges and the prover then doing a zero-test.This can be made compatible with the desired protocol structure.Unfortunately, this is not true for the approach from Sect.4.3.3 as it works directly on a MAC level.
Assume that we start m proofs i , over F p k , proving the individual circuits C i .Note that p can be any prime power, with no restrictions on size.We make the simplifying assumption that each C i has the same number of linear gates and that each i has the same number of rounds of interaction and that prover messages in each round are of the same length.[2] show the more general case where these restrictions are not necessary.

Constructing the protocol
We construct a protocol OR , defined over F p k , for the aforementioned task as follows: 1. P, having only w i * for one of the circuits C i * , will commit to [w] such that i * can access w i * .It then in its head runs each of the i on inputs derived from [w].For this, it extends w i * with a random padding if necessary.2. P and V will simultaneously run all 1 , . . ., m , with the following modification: P's message c h to V in round h will be chosen as the message created from running i * , while V uses the same message from the prover in all instances.Since the messages of all protocols by assumption appear uniformly random and are therefore indistinguishable, V can now execute all instances in parallel but cannot tell which of these is the true one.3. Conversely, since all i are public coin, V sends a randomness string that is long enough for any of the m instances in round h.P uses this identical randomness string in all simulated proofs 1 , . . ., m .
The challenge now, is that V cannot simply perform the verification for all i using the CheckZero queries for each instance, since this would reveal the index i * of the true statement.Towards resolving this, we first observe that any "pure" zero-test can be turned into a -protocol-like argument as follows: 1.For each i ∈ {1, . . ., m}, let [μ i ] be the output of the circuit C i run on [w].Assume that there exists a uniformly random commitment [r i ], which can be generated without additional interaction from F d VOLE .2. P sends r i to V, but crucially does not open the commitment [r i ] yet.3. V sends a challenge f i to P. 4. P uses CheckZero to show that [r i ] + f i [μ i ] − r i opens to 0. This check, crucially, has a soundness error of 1/ p k , as any prover knowing f i in advance can generate r i appropriately in order to cheat during the sigma-protocol.
[2] now perform a [16]-style OR-proof to show that at least one of the outputs [μ i ] is zero, using the -protocol version of CheckZero.The basic idea behind [16] is that given m -protocols for proving relations, an OR proof can be done by having the prover choose the random challenge f i for m −1 of the instances, so it can simulate the correct messages r i to be sent in every false instance using the simulator for the sigma protocol.This makes the verifier accept for the "false" instances automatically.For the correct instance i * , P will choose r i as in the correct -protocol, which it can complete because the statement is actually true for one instance.Hence, after receiving the m initial messages of each -protocol (honest in one case, simulated in all others), the verifier picks a challenge f , which defines the challenge f i * = f − i =i * f i corresponding to the true instance i * .The prover sends all these f i to the verifier.
Finally, V checks that the f i add up to f and that each CheckZero test for each C i is indeed valid.

Threshold proofs
In [16] the authors describe how to additionally construct proofs of partial knowledge for any threshold, i.e., how to show that r out of the m statements are true.Their technique, together with a modification of OR , can be used to construct a proof in the VOLE setting where we implicitly only communicate the transcript of r statements, and not all m of them.
Towards this, OR can then be seen as a special case where r = 1.To generalize to arbitrary r one now simulates the m − r possibly false proofs using false challenges.The prover then, based on the challenge f , computes the unique degree-m − t polynomial s that evaluates to f at point 0 and to the simulated challenge f i for each i where the sigma-protocol was simulated.It then derives the honest challenges by evaluating this polynomial at their indices, and sends s to the verifier.Towards compressing the messages, [2] then consider the r messages for the true branches as evaluations of a polynomial t of degree r − 1. Namely, for each true evaluated branch i, they let t(i) be the message sent by i .The prover then computes this unique polynomial in canonical coefficient form and sends it to V, who derives the inputs to each simulated i from t. Since both s, t are of canonical form, they do not leak which of the branches are actually true.

log-overhead disjunctions
The drafted protocol OR has the drawback that to verify one out of m statements, we still need O(m) communication complexity in the OR-proof.One can construct an alternative protocol that obtains an overhead only logarithmic in m, as follows: where x = x mod 2 k , i.e. x is a representative of the corresponding congruence class of integers modulo 2 k .Then P gets x and M[x], whereas V receives and K [x].As before, linear operations can be applied in the same way.One can show that this again leads to P not being able to cheat, unless it can guess which only succeeds with probability 2 −s .Setting s = σ then achieves the required statistical security.
Observe that initially x may be chosen as x = x ∈ {0, . . ., 2 k − 1}.Applying arithmetic operations can result in larger values though, which do not get reduced modulo 2 k because all computation happens modulo 2 .Therefore, to safely open [x] or show that x = 0, first the upper s bits of x need to be randomized, by computing [z] ← [x] + 2 k • [r ] with random r ∈ R Z 2 and then opening [z].

Extending Line-Point Multiplication checks to Z 2 k
It is clear that Equation 4.3.3from the efficient multiplication check from Sect.4.3.3still holds.Therefore, one might hope that the same security argument still applies.Unfortunately, when just considering general quadratic equations f (x) = ax 2 + bx + c modulo 2 , then these may have many more than just 2 solutions.
It is clear that Equation 4.3.3from the efficient multiplication check from Sect.4.3.3still holds.Therefore, one might hope that the same security argument still applies.Unfortunately, when just considering general quadratic equations f (x) = ax 2 + bx + c modulo 2 , then these may have many more than just 2 solutions.
In [1] the authors observe that f (x) actually is constrained in the given setting, since a cannot be chosen from the entire ring by P, as a = 0 mod 2 k for P to successfully cheat.Moreover, P may have to guess a root of f (x) that comes from {0, . . ., 2 s − 1}.They therefore show the following: Lemma 5.1 Let f (x) ∈ Z[x] be a quadratic equation such that 2 r is the largest power of 2 dividing all coefficients.Then for any , s, s ∈ N such that − r > s there are at most 2 max{(2s−s )/2,1} solutions to f (x) = 0 mod 2 in {0, . . ., 2 s − 1}.This implies that by choosing = k + 2s, one can achieve the required bound on the number of solutions.

Amortizing multiplication checks in Z 2 k
Also with respect to checking many multiplications simultaneously, the solution of Quick-Silver from Equation 4.3.3does not directly carry over.[1] solve this by generalizing the techniques from [17] to their MAC scheme.

RAM-based Zero-knowledge Proofs
RAM-based zero-knowledge proofs have been studied in the context of zkSNARKs (starting from [7]).As we show below, the main components needed are zero-knowledge proofs of permutation, packing, and integer comparison.When representing the integers as a list of authenticated values in F 2 , proving integer comparison is a fair easy task since comparison becomes a straightforward circuit.For efficient permutation and packing, the problems are somewhat related.The folklore method to prove a permutation is by letting the prover commit to the permuted values and prove equality of the sets, which in turn can be converted to a polynomial identity check [39].When the field is large, it can be checked in linear time by checking the evaluation on a random point, where the soundness if ensured by the Schwartz-Zippel Lemma.However, converting between F 2 and a large field can be costly even after optimizations such as in Sect.5.4.
The key observation in [26] is that the Schwartz-Zippel Lemma works for any field as long as it is sufficiently large and thus one can choose a field that is friendly to conversions.In particular, we can embed a bit string either as F κ 2 or as F 2 κ .Their authentications are different: authenticating elements in F κ 2 requires IT-MACs on each F 2 value; authenticating F 2 κ only requires one IT-MAC for the whole element.Just like cleartext operation, conversions between authenticated elements in F κ 2 and F 2 κ can also be done efficiently with no communication: if we fix a degree-κ irreducible polynomial f (X ) and identify F 2 κ with F 2 [X ]/( f (X )), then it can be derived that x = i∈ [κ] x i • X i , where X ∈ F 2 κ denotes the element corresponding to X ∈ F 2 [X ]/( f (X )).The parties can compute [x] by having the prover compute M[x] = i∈[κ] M[x i ] • X i and the verifier compute This means that given a vector of bits, we can prove a Boolean predicate by treating them as authenticated bits and, without communication, we can prove arithmetic predicates on vectors of bits by treating vectors as extension field elements.Below we use ZK proof of read-only RAM as an example.

Read-only ZKRAM
Consider the case where the prover wants to prove in zero knowledge to the verifier that there exists an index i for which Mem i = t (where t is a public value).The protocol in this case roughly proceeds as follows: 3. The prover then sorts the tuples in L by their first entry, giving an updated list L , and commits to the tuples in that list.4. The prover proves that L is consistent, namely, that if two tuples in L agree in their first entry, then they also agree in their second entry.This can be done in a natural way by comparing all adjacent entries in L .All operations should be proven as a Boolean circuit over F 2 .5. The prover proves that L is a permuted version of L using the polynomial equality check ensured by Schwartz-Zippel.Specifically, let L = x 0 , . . .denote the tuples in L (where now we represent each tuple as elements in F 2 κ ), and let L = x 0 , . . .denote the tuples in L .If one defines the polynomials L(R) = i (x i − R) and L (R) = i (x i − R), then note that L and L are permutations of each other iff L(R) = L (R).The verifier can efficiently test the equality of these polynomials by choosing a uniform field element r and verifying that L(r ) = L(r ).
To extend the above idea to support write, one just needs to take the timestamp into consideration since a value can be updated in the middle of the execution.The sorting needs to respect both index and time stamp, and the consistency checks need to incorporate the update after the initialization.

Open questions
We will now mention some research directions which we believe are interesting to develop VOLE-based ZK protocols further.

Theoretical questions
There are many intriguing theoretical aspects of VOLE-based Zero Knowledge protocols that are yet unexplored.In the following, we provide a list of interesting theoretical research directions.
1. Using other correlations.The efficiency of VOLE-based Zero Knowledge protocols relies on the recent breakthroughs in efficient VOLE extension.But also other pseudorandom correlations (see e.g.[13]) can be efficiently generated.The question is if these, or other, correlations can benefit ZK proofs in a similar way.One step into this direction was already done in [22] (see Sect. 5.2) by using qVOLE.2. Sublinear communication and verification.The idea of ZK proofs with sublinear communication and verification has flourished in the past 10 years, starting from [8,28,44] and leading to recent Blockchain-optimized proof systems.In VOLE-based ZK, similar properties may be interesting although non-interactivity is less important.Having a verifier with sublinear (in |C|) computation while keeping a concretely efficient, linear prover has to the best of our knowledge not yet been achieved.For the special case of disjunctions one could achieve an asymptotic solution by extending the techniques of [32], but concrete efficiency is unclear.3. Sublinear communication, also in the input length.A recent work [50], which extends VOLE-based ZK, enables communication sublinear to |C|.Their protocol relies on vector oblivious polynomial evaluation (VOPE), an extension of VOLE.At the same time, it requires the proof to be of size at least |w| (i.e. the circuit input) for knowledge extraction.It would be interesting to explore if VOLE-based protocols can be both sublinear in |C| and |w| by introducing a knowledge assumption or using a random oracle, while keeping the concrete efficiency of [50].

Practical questions
VOLE-based ZK enjoys many advantages that are intriguing to practical deployment.Here we summarize a list of interesting practical future directions.
1.More efficient VOLE.The concrete efficiency of the whole proof system relies on efficient VOLE protocols.Thus it is crucial to design more efficient VOLE protocols with improved computation and communication overhead.2.More applications.State-of-the-art VOLE-based ZK can prove tens of millions of gates with ease.This opens the possibility of proving very large statements, something not feasible before this line of work.It would be interesting to explore the space of applications that need ZK but were limited so far by the scalability problems of existing schemes.The fact that this type of proof is designated-verifier could affect the design and thus poses new questions in designing ZK-based applications.3. Lowering the gap between Z 2 k and F p .In their work, [1] provide a software implementation of their instantiation of F ABB that operates over Z 2 k .Their implementation achieves 1mio multiplications over Z 2 64 , which is up to an order of magnitude slower than what the implementations of the protocols from Sect. 4 can perform in similar settings over fields of similar size.Lowering this gap may be helpful if Z 2 k proof systems should be used for proofs of programs on current hardware architectures.

Fig. 1
Fig. 1 Functionality for ZK proofs over the ring R

Lemma 2 . 1 ($
Schwartz-Zippel Lemma) Let F be a finite field, S ⊆ F and P ∈ F[X ] be a non-zero polynomial of degree d ≥ 0. Then Pr s

Fig. 3
Fig. 3 Functionality modeling an arithmetic black box over the ring R [x], [y], [z] and wants to show that z = x • y.To do so, first both P, V use F d VOLE to create a random [a].Additionally, P creates [c] where c = a • y.Upon obtaining a challenge e from V, both parties now compute [ε] = e • [x] − [a] and P sends ε to V.Then, P shows that both [ε] − ε and e • [z] − [c] − ε[y] are commitments to 0. Assuming that [ε] was indeed opened correctly, consider the case where [z] = [x • y+δ] for a non-zero δ, while [c] = [ay +γ ] for a possibly non-zero γ .

Theorem 4 . 2
If R = F p k and the protocol AssertMultVec passes, then the input commitments have the required relation except with probability n+4 log n+1 p k −2

Fig. 6
Fig. 6 Geometry of line point zero knowledge 3.1, we can instead write the triple (a, b, v) as (x, M[x], K [x]).Then setting values of a or x is accomplished by the Input step of F ABB , and setting values of b or M[x] is accomplished similarly by sending the difference between a random value M[r ] and the desired value M[x i ].