Darlin: A proof carrying data scheme based on Marlin

07/09/2021 ∙ by Ulrich Haböck, et al. ∙ 0

In this document we describe the Darlin proof carrying data scheme for the distributed computation of block and epoch proofs in a Latus sidechain of Zendoo (arxive:2002.01847). Recursion as well as base proofs rest on Marlin (Chiesa et al. EUROCRYPT 2020) using the Pasta cycle of curves and the "dlog" polynomial commitment scheme from Bootle et al. We apply the amortization technique from Halo (Bowe et al., IACR eprint 2019/1021) to the non-succinct parts of the verifier, and we adapt their strategy for bivariate circuit encoding polynomials to aggregate Marlin's inner sumchecks across the nodes of the proof carrying data scheme. Regarding performance, the advantage of Darlin over a scheme without inner sumcheck aggregation is about 30 scenario as ours, and beyond when applied to linear recursion.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Arithmetization

We assume an arithmetic circuit over being represented by a quadratic rank-one constraint system (R1CS), i.e.

(9)

where , , are matrices over ,

is the vector matrix product and

denotes the entry-wise (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 two-adic 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 non-zero 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 non-zero 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 non-normalized 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 zero-knowledge. See the full version of the paper for a detailed treatment.

Initialization

In the first step the prover computes the polynomials444 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 non-zero 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 non-extension fields and the -Poseidon hash [Poseidon] with an internal state of field elements.)

polynomial arithm. commit
intial round
outer sumcheck
inner sumcheck
overall
Table 2: Computational effort of the (coboundary) zk-Marlin prover, using an elliptic curve based linear polynomial commitment scheme. We only count fast Fourier transforms in terms of their domain size , and elliptic curve multi scalar multiplications in terms of the number of scalars . (Without opening proof.)

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 ‘multi-point’, ‘multi-polynomial’ instance666 Here ‘multi-point’ refers to the different points , , and ‘multi-polynomial’ to the different polynomials defined by , . , to a single-point, multi-polynomial 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 single-point multi-polynomial instance is then reduced in batch to a single-point single-polynomial 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.

  1. Given , the random challenge from the outer sumcheck, the prover sends the oracles for the ‘bridging polynomials’

    on which the verifier responds with random .

  2. 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 stand-alone 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 ‘cross-circuit’ generalization is especially useful in ‘non-homogeneous’ 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 single-circuit setting we leverage linearity of the commitment scheme, and keep track of a single cross-circuit polynomial

(23)

by means of the cross-circuit coefficient vector . The cross-circuit 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 non-succinct 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:

  1. The verifier queries at for its value at from step (2) of 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 cross-circuit 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 straight-forward.

Protocol 4 (Complete recursive argument).

Given a previous composed accumulator , where is a cross-circuit 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.

  1. Intitialization for : The prover computes

    and sends their dlog commitments , , and to the verifier, who responds with .

  2. 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 .

  3. Inner sumcheck aggregation, Step 1: The prover computes the ‘bridging’ polynomials for

    and sends to the verifier, who answers with another random .

  4. Inner sumcheck aggregation, Step 2: The prover computes the cross-circuit 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 multi-point queries:

  • , at , as well as at ,

  • at , at , and , from at ,

  • at , and from at .

If the queried values pass the checks of the outer sumcheck, Protocol 2 and Protocol 3, and if match with the public input of the circuit, then the verifier accepts. The new accumulator is with

and from the above batch evaluation proof.

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

We will use the Fiat-Shamir transform to turn Protocol 4 into a non-interactive argument of knowledge as used in our Darlin PCD scheme. As the proof for Theorem 1 we postpone a security analysis in the random oracle model to the full version of the paper.

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
Table 3: Marlin prover with and without inner sumcheck aggregation in terms of FFT operations and multi-scalar multiplications. (Without opening proof.)

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 statement-witness 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 zero-knowledge does not make use of trapdoors.

Definition 3 (Perfect Honest Verifier Zero-knowledge).

An interactive argument system is perfect honest verifier zero-knowledge 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 witness-extended emulation [Lindell] for defining arguments of knowledge. An interactive argument system has witness-extended emulation if every computationally bounded adversary can be turned into a witness-extended emulator of comparable efficiency, which serves both transcripts indistinguishable from the interactions of , and a witnesses for whenever it is accepting.

Definition 4 (Witness-extended Emulation).

An interactive argument system has witness-extended emulation if for every p.p.t. adversary there is a p.p.t. algorithm with black-box access to the next-message functions of and such that

We note that any expected polynomial time emulator with non-negligible success probability can be turned into one with strict polynomial running time still having non-negligible 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, zero-knowledge and witness-extended 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 non-interactive 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 Pre-processing 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 pre-processing 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 so-called ‘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, zero-knowledge and witness-extended 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