1 Arithmetization
We assume an arithmetic circuit over being represented by a quadratic rankone constraint system (R1CS), i.e.
(9) 
where , , are matrices over ,
is the vector matrix product and
denotes the entrywise (Hadamard) product of vectors. The witness vector is composed of a public part and a private part , i.e.. Assuming quadratic matrices is no loss in generality, as the constraint system may be always padded with dummy constraints or variables. Moreover, we presume that
is divisible by a high power of two, assuring the existence of sufficiently large multiplicative subgroups of twoadic order. Subgroups of such smooth order allow for a fast Fourier transform which runs in time
, where is the order of the subgroup. (In the sequel we call such subgroups FFT domains.)In Marlin the R1CS equations are expressed over using Lagrange encoding. That is, given an arbitrary enumeration of a vector is associated with the polynomial . In other words, is the vector of coordinates with respect to the Lagrange basis . Therefore is a solution of (9) if and only if its associated polynomial satisfies
(10)  
where  
(11)  
(12) 
In these equations, , , are the bivariate polynomials having the matrix entries of , , respectively as Lagrange coordinates,
(13) 
for . The double sum in (13) is made amenable to a univariate sumcheck by indexing its nonzero terms over yet another FFT domain , again assuming the existence of such sufficiently large multiplicative subgroup. In practice are sparse, yielding that is about to times larger than , see Section 3. As in Marlin, we denote by
the polynomials of degree which index ’s nonzero values, their row and column indices (the latter two regarded as points from , as in (13)), so that
Since for every in , , we have
(14) 
This representation, which is slightly different to that of [Marlin], is the one we use for the second sumcheck arguemnt, the ‘inner sumcheck’. We assume that for , the precomputed polynomials
(15)  
(16) 
regarded of degree , are also part of the verifier key.
2 The protocol
In Marlin, the prover provides the oracles for , , and convinces the verifier of the ‘R1CS identities’ (10), (11), (12). For efficiency reasons these three identities are reduced to a single one by building a random linear combination based on a challenge , i.e.
(17) 
with
and
(We notice that using the powers of slightly differs from choosing arbitrary random scalars , , as in [Marlin].) Equation (17) is reduced to a sumcheck over by sampling a polynomial using a suitable kernel , , and applying it via scalar product to both sides of the equation. This yields
and hence
(18) 
We choose the Lagrange kernel for , instead of a nonnormalized variant as in [Marlin]. Since is of degree less than , it holds that (see Appendix E), and equation (18) is equal to
(19) 
Equation 19 is the central identity to be proven by the protocol.
We give only an informal description of the main steps of the protocol, and skip the discussion on zeroknowledge. See the full version of the paper for a detailed treatment.
Initialization
In the first step the prover computes the polynomials^{4}^{4}4 Unless stated otherwise we assume polynomials from of reduced form, i.e. of degree .
from their Lagrange represenations, and sends their oracles , , to the verifier, who returns the randomnesses and for equation (19).
Outer sumcheck
To prove equation (19) we apply the coboundary argument from Section Darlin: A proof carrying data scheme based on Marlin (Extended abstract) to . For this the prover computes
satisfying
(20) 
where is generator of , and sends their oracles, together with that of , to the verifier. The verifier samples another random challenge and queries the oracles for , which are used for checking the identity (20) at .
Inner sumcheck
To prove that the value provided by the oracle in fact stems from the circuit polynomials , we adapt Marlin’s inner sumcheck to our slightly different representation 14. Using these we obtain
(21) 
where . We apply the coboundary sumcheck to
regarded as reduced element from . The prover computes from satisfying
and then multiplies both sides with the denomiator
where are the precomputed products (15) from the prover key. This yields the inner sumcheck identity
(22) 
where is a generator of and . The prover sends the oracles and to the verifier, who samples a random challenge , on which the oracles are queried for , , where , and . These values are used by the verifier to check the identity (22) at .
3 A note on performance
Marlin’s outer sumcheck takes place over the FFT domain , the size of which covers the number of constraints/variables of the constraint system. In practice circuits yield about the same number of variables as constraints, hence it is reasonable to take the number of constraints as measure for the computational effort of the outer sumcheck, assuming a sufficiently smooth order of to optimally match . The inner sumcheck runs over the FFT domain of size ( is the number of nonzero entries in ), again under the assumption of sufficient smoothness. This domain is by the factor
larger, where is the R1CS density of the circuit. The R1CS density is the average number of variables per constraint, and in practice we observed values between between and for the circuits we target. (These circuits implement elliptic curve arithmetics over nonextension fields and the Poseidon hash [Poseidon] with an internal state of field elements.)
polynomial arithm.  commit  

intial round  
outer sumcheck  
inner sumcheck  
overall 
4 Inner sumcheck aggregation
Here, the accumulator consists of a commitment and the succinct description of the circuit polynomial intended to be represented by , i.e. the point and the randomnesses ,
The corresponding predicate is satisfied if and only if is the commitment of (using commitment randomness zero).
The prover reduces the correctness of several accumulator instances to that of a single new one, and the verifier validates the correctness of this reduction while keeping track of the polynomial descriptions (i.e. the and ) by herself. We sketch the strategy assuming a single previous accumulator. There, a previous instance is ‘merged’ with of the current outer sumcheck. In a first step, the prover reduces the ‘multipoint’, ‘multipolynomial’ instance^{6}^{6}6 Here ‘multipoint’ refers to the different points , , and ‘multipolynomial’ to the different polynomials defined by , . , to a singlepoint, multipolynomial instance
with random , by providing the commitments to these new polynomials and proving consistency via polynomial testing: If the old polynomials evaluate at the challenge to the same values as the new polynomials at the old point, respectively, then correctness of the new polynomials overwhelmingly implies that of the old ones. Using the same principle once again, correctness of the singlepoint multipolynomial instance is then reduced in batch to a singlepoint singlepolynomial instance
where are random. Note that the resulting polynomial is again of the form with . For the reduction, the prover shows that the linear combination opens at the new challenge to the same value as the new polynomial at the old point . Again, correctness of the new polynomial overwhelmingly implies correctness of the old ones.
Protocol 2 is regarded as a subprotocol of our complete recursive argument Protocol 4, right after the outer sumcheck. We formulate it as an algebraic oracle protocol, considering its commitment as oracle.
Protocol 2 (Inner sumcheck aggregation).
Suppose that is a previous accumulator, intended to represent an oracle for , and is as provided by the prover in the current outer sumcheck, intended to represent an oracle for , with . Aggregation of and is done according to the following steps immediately processed after the outer sumcheck.

Given , the random challenge from the outer sumcheck, the prover sends the oracles for the ‘bridging polynomials’
on which the verifier responds with random .

Given from the verifier, the prover ‘responds’ with the oracle for
The verifier queries , for their corresponding values , at and , and checks them against the values of , at , respectively. It also queries at and checks its value against that of the linear combination at . If these checks succeed, then the verifier accepts and the new accumulator is
A formal analysis of Protocol 2 is given in the full version of the document. As a standalone argument having its own opening proof, the protocol defines a (perfectly) complete and sound accumulation scheme for the predicate in the sense of [Buenz]: If both and satisfy the predicate , so does . And if
, then with overwhelming probability both
and .5 Generalization to several circuits
The aggregation strategy from Section 4 is easily extended to serve multiple circuits simultaneously. This ‘crosscircuit’ generalization is especially useful in ‘nonhomogeneous’ recursive schemes such as our Darlin PCD scheme from Section Darlin: A proof carrying data scheme based on Marlin (Extended abstract) . Lets assume that the R1CS matrices of the circuits , , are padded to the same square dimension so that we may regard
, as bivariate polynomials over the same domain . As in the singlecircuit setting we leverage linearity of the commitment scheme, and keep track of a single crosscircuit polynomial
(23) 
by means of the crosscircuit coefficient vector . The crosscircuit accumulator for the collection is of the form
with , coefficient vector , and an element from the commitment group. The corresponding predicate is satisfied if and only if is in fact the dlog commitment of , using blinding randomness zero.
6 Accumulating the dlog hard parts
The aggregation strategy for the nonsuccinct part of the dlog verifier is identical to that in [Buenz]. The opening proof for the dlog commmitment is an inner product argument which uses the repetitive folding technique from [BootleGroth] to gradually reduce the opening claim on the initial full length polynomial to one of half the size, until ending up with the opening claim of a single coefficient polynomial. The final committer key of the opening proof is a single group element which is the result of a corresponding folding procedure on the full length committer key of the dlog scheme. It equals the commitment of the succinct reduction polynomial
(24) 
where is the number of reduction steps and their challenges. The dlog accumulator is of the form
where and is a commitment, and the corresponding accumulator predicate is satisfied if and only if is the commitment of , using blinding randomness zero.
As Protocol 2, the aggregation strategy is regarded as a subprotocol of the complete recursive argument Protocol 4, and for efficiency reasons we reuse the challenge from the inner sumcheck aggregation. We again restrict to the case of a single previous accumulator.
Protocol 3 (dlog hard parts aggregation).
Suppose that is a previous dlog accumulator, with representing an oracle for . The following step is part of the complete recursive argument and processed immediately after Protocol 2:
If then the verifier accepts. The new accumulator is the one from the dlog opening proof at the end of the complete protocol.
7 Putting the pieces together
The complete recursive argument is a composition of Marlin’s outer sumcheck for the ‘current’ circuit, the aggregation rounds from the crosscircuit variant of Protocol 2, and Protocol 3. As in Section 5 we assume that the bivariate circuit polynomials are over the same domain , where . The query phases of these subprotocols are gathered at the end of the protocol, which is then concluded by the batch evaluation argument from [HaloInfinite].
We formulate the complete argument with oracles for polynomials replaced by their dlog commitments, while keeping with the same notation . For simplicity, we again restrict to the case of a single previous accumulator. The general case is straightforward.
Protocol 4 (Complete recursive argument).
Given a previous composed accumulator , where is a crosscircuit accumulator for the collection , and is a dlog accumulator. The recursive argument for an instance of the ‘current’ circuit from is composed by the following steps.

Intitialization for : The prover computes
and sends their dlog commitments , , and to the verifier, who responds with .

Outer sumcheck for : The prover computes
of the current circuit, with , the boundary polynomial
according to the outer sumcheck identity (20). It then sends their commitments to the verifier, who returns another random challenge .

Inner sumcheck aggregation, Step 1: The prover computes the ‘bridging’ polynomials for
and sends to the verifier, who answers with another random .

Inner sumcheck aggregation, Step 2: The prover computes the crosscircuit linear combination
and sends and to the verifier.
After these steps, both prover and verifier engage in the batch evaluation argument from [HaloInfinite] for the dlog commitment scheme, applied to the following multipoint queries:

, at , as well as at ,

at , at , and , from at ,

at , and from at .
A detailed security analysis of Protocol 1 is given in the full version of the document. We summarize its result in the following theorem.
Theorem 1.
If the dlog commitment scheme is computationally binding (Definition 7) then Protocol 4, extended by the predicate verification on the resulting inner sumcheck accumulator , is an argument of knowledge (Definition 5) for the relation
indexed by the circuit collection . Here, denotes the R1CS relation given by the circuit , and and are as in Section 5 and Section 6
8 A note on performance
Inner sumcheck aggregation is particularly effective when the number of previous accumulators is low, as can be seen from the operations counts in Table 3. For previous accumulators representing the case of linear recursion, the prover effort for the recursive argument is comparable to that of standard Marlin for a circuit of R1CS density . Having previous accumulators, as in our Darlin PCD scheme, the equivalent density is about . Compared to a standard Marlin prover for circuits with density the perfomance improvement is about , cf. Table 1.
polynomial arith.  commit  

intial round  
outer sumcheck  
aggregation rounds  
overall  
without aggregation 
References
Appendix A Notation
We denote the security parameter by , where we throughout consider it in unary representation. A function is negligible if for every polynomial , it holds that , or in short . Two functions and are computationally indistinguishable, denoted by , if their difference is negligible in .
Probabilistic algorithms are denoted by capital letters , etc., and we write if an algorithm a ouputs a string given an input string while using some internal random coins uniformly sampled from . Whenever we need to refer to the used random coins , we will explicitly write . We say that is probabilistic polynomial time (p.p.t.), if its run time on input and internal random coins is bounded by some fixed polynomial independent of the random coins, where denotes the length of its input. We say that is expected polynomial time if the expected run time , where the expectation is taken over all random coins , is bounded by some polynomial in the length of the input. The interaction of two interactive probabilistic algorithms and is denoted , where we explicitly clarify what are the inputs and outputs of both algorithms.
Appendix B Interactive arguments
Let be a polynomial time decidable binary relation. An interactive argument system for consists of three probabilistic polynomial time algorithms
Given the security parameter in unary representation, outputs a common reference string which supports all statementwitness pairs up to a certain maximum length , which we write in short . Given , the algorithms and are used to interactively reason about whether belongs to the language defined by or not. We denote their interaction by with as the transcript of the interaction, and we assume that both algorithms have access to the without explicitly declaring them as inputs. After at most polynomially many steps the verifier accepts or rejects, and we say that is accepting or rejecting.
Definition 2 (Perfect completeness).
An interactive argument system , satisfies perfect completeness if
As we will not require any trust assumptions for the setup, our definition of zeroknowledge does not make use of trapdoors.
Definition 3 (Perfect Honest Verifier Zeroknowledge).
An interactive argument system is perfect honest verifier zeroknowledge if there is a p.p.t. algorithm with access to the common reference string and such that for every p.p.t. algorithm ,
Since we intend to use arguments as components of larger cryptographic schemes, we follow [BootleGroth], [Halo] and use the notion of witnessextended emulation [Lindell] for defining arguments of knowledge. An interactive argument system has witnessextended emulation if every computationally bounded adversary can be turned into a witnessextended emulator of comparable efficiency, which serves both transcripts indistinguishable from the interactions of , and a witnesses for whenever it is accepting.
Definition 4 (Witnessextended Emulation).
An interactive argument system has witnessextended emulation if for every p.p.t. adversary there is a p.p.t. algorithm with blackbox access to the nextmessage functions of and such that
We note that any expected polynomial time emulator with nonnegligible success probability can be turned into one with strict polynomial running time still having nonnegligible success probability, hence our variant of Definition 4 is equivalent to the ones from [BootleGroth], [Halo].
Definition 5.
We say that an interactive argument system for is an argument of knowledge, if it is perfectly complete and knowledge sound. It is said to be succinct, if the size of the transcript is sublinear in the size of .
Appendix C Polynomial commitment schemes
We regard a polynomial commitment scheme consisting of four p.p.t. algorithms
Given the security parameter , generates a common reference string consisting of a committer key and a verifier key supporting polynomials over some finite field having degree of at most , where is polynomial in . Given the committer key , the commitment of a polynomial of degree at most is computed by , where denotes the used random coins. (We again omit from the inputs for brevity.) We regard as succinct interactive argument system for the relation
and call the polynomial commitment scheme to satisfy completeness, zeroknowledge and witnessextended emulation if the interactive argument system does. We refer to the interaction as opening proof for the polynomial at the point .
The security notions computational binding and perfect hiding are as for general noninteractive commitment schemes . For the sake of brevity, we directly cite them applied to polynomial commitment schemes:
Definition 6 (Perfect Hiding).
We say that a polynomial commitment scheme is perfectly hiding if every polynomial adversary has no advantage over pure guessing when distinguishing the commitments of two adversarily chosen polynomials,
Definition 7 (Computational Binding).
A polynomial commitment scheme is computationally binding if for every p.p.t. adversary , the probability to find two different messages , , having the same commmitment is negligible:
We further make use the notion of a homomorphic schemes, again directly applied to polynomial commitment schemes:
Definition 8 (Homomorphic commitment).
A polynomial commitment scheme , with commitments in a commitment group is homomorphic, if
Appendix D Preprocessing arguments with universal SRS
An indexed relation is a collection of binary relations where the index ranges over some index set . In our context, will be set of all R1CS systems over the family of fields given by a polynomial commitment scheme (see Appendix C) and so that the sizes of the R1CS matrices are polynomial in the security parameter. We consider a universal setup preprocessing argument system
for an polynomial decidable binary indexed relation as an interactive argument system in which the setup is divided into phases. Given the security parameter , generates the universal part of the common reference string, which we again denote by . This is the universal setup, and done in the socalled ‘offline’ phase. In a subsequent ‘online’ phase, the indexer is used to generate the index specific part of the common reference string, which consists of a prover and a verifier key for a given index , .
The security definitions completeness, zeroknowledge and witnessextended emulation are as Definition 2, Definition 3 and Definition 4, with the following minor differences: We replace by , hence the adversary is allowed to chose the index , , followed by computing . Although we consider as part of the common reference string, we will explicitly state and as inputs for the prover and the verifier, respectively, e.g. .
Appendix E Lagrange kernel
Let be an order
Comments
There are no comments yet.