c# Canonic GKR See XZZ+19, ZLW+20 for more details.

"Gate"-style layerwise relationship

Unlike the structured wiring pattern described in the previous section, "gate"-style layerwise relationships allow for an arbitrary wiring pattern between a destination layer and its source layer(s). In general, these layerwise relationships are defined via indicator functions (these function like the function in structured layerwise relationships, but allow for input wires whose indices have no relationship to those of the output wire). Consider, for example, the canonic layerwise GKR equation, which defines the relationship between a previous layer's MLE ( below) and the current layer's MLE ( below): We define three types of gate layers within Remainder, although they are all quite similar in spirit.

Notation

  • Let denote the number of variables the MLE representing layer has (in other words, layer of the circuit has values).
  • Let be the MLE corresponding to values in the layer of the circuit which is the "destination" of the gate polynomial relationship.
  • Let be the MLE corresponding to values in (one) layer of the circuit which is the "source" of the gate polynomial relationship. Note that always.
  • Similarly, let be the MLE corresponding to values in (another) layer of the circuit which is a second "source" of the gate polynomial relationship. Note that always.

Identity Gate

Identity gates are defined in the following way: In other words, is if and only if there is a gate from the 'th value in the 'th layer to the 'th value in the 'th layer. These can be thought of as "routing" gates or "copy constraints", as they directly pass a value from one layer to another. The MLE of the identity function above is defined as follows: The polynomial relationship between the "destination" layer 's MLE and the "source" layer 's MLE is as follows: Assuming that gets bound to during sumcheck, this layer produces two claims -- one on and one on . The former can be checked by the verifier directly (since it knows the circuit wiring and uses the definition of above), and the latter is proven by sumcheck over layer .

Example

We start with a "source" MLE over two variables with four evaluations, and wish to obtain a circular-shifted version of the evaluations of this MLE in layer , i.e. .

For example, let's say that the evaluations of are . We wish for those of to be e.g. . To do this, we can list the "nonzero" identity gate indices, i.e. , such that :

  • : the zeroth evaluation of layer is equivalent to the first evaluation of layer .
  • : the first evaluation of layer is equivalent to the second evaluation of layer .
  • : similar reasoning as above.
  • : similar reasoning as above.

For all other tuples over binary values we have that .

Costs

Over here, we go through some of the costs for the prover runtime, proof size, and verifier runtime when performing sumcheck over an identity gate layer. In order to provide some intuition, we analyze the costs of a particular example, which may not encapsulate the general example for identity gate layers.

Let us recall the identity gate sumcheck equation: We can rewrite this as: As observed in XZZ+19, we only need to sum over the wirings which are non-zero (i.e., there exists a re-routing from label in layer to label in layer ). Call the set of non-zero wirings as (here, we say that , i.e. a constant number of wires for each input layer and output layer value). We can rewrite the summation as:

The prover cost for sumcheck over an identity gate layer is as follows:

  • The prover must first compute the evaluations of . By summing over the non-zero wirings in , XZZ+19 shows us how to compute an MLE with evaluations of this product in time This involves first pre-computing the table of evaluations of using the dynamic-programming algorithm in Tha13, and then appropriately summing over to fold in the evaluations of
  • Next, the prover must compute sumcheck messages for the above relationship. The degree of each sumcheck message is , and thus the prover sends evaluations per round of sumcheck. Since we are sumchecking over , there are rounds of sumcheck and thus the prover cost is for the 'th round of sumcheck. The total prover sumcheck cost is thus
  • Letting be a constant, the total prover runtime (pre-processing + sumcheck) is

The proof size for sumcheck over identity gate is as follows:

  • There are total sumcheck rounds, each with the prover sending over evaluations for a quadratic polynomial. The proof size is thus field elements, plus extra for the final claim on .

The verifier cost for sumcheck over identity gate is as follows:

  • The verifier receives sumcheck messages with evaluations each, and each round it must evaluate those quadratic polynomials at a random point. Its runtime is thus with very small constants.

Add Gate

The concepts for addition and multiplication gates are very similar to that of identity gate above. For add gate, we have the binary wiring indicator predicate: Here, we have that if and only if the 'th value in the 'th layer and the 'th value in the 'th layer sum to the 'th value in the 'th layer. The MLE of is similar to that of : and the polynomial relationship is defined very similarly to that of identity gate: Assuming that gets bound to and gets bound to during sumcheck, a claim on this layer results in three total claims: one on (which the verifier can compute from the circuit description and therefore check on its own), one on , and one on .

Example

We start with two "source" MLEs, over two variables with four evaluations each, and wish to add each value in the first with its "complementary value" in the second. The result should be the MLE representing layer , i.e. .

For example, let's say that the evaluations of are and those of are . We wish to add to , to , and so on. Then our "nonzero gate tuples" are as follows:

  • : the zeroth value in the 'th layer is equivalent to the sum of the zeroth value in the 'th layer and the third value in the 'th layer.
  • : the first value in the 'th layer is equivalent to the sum of the first value in the 'th layer and the second value in the 'th layer.
  • : similar reasoning to the above.
  • : similar reasoning to the above.

For all other binary tuples we have that , and our resulting MLE's evaluations should be as follows: .

Costs

Over here, we go through some of the costs for the prover runtime, proof size, and verifier runtime when performing sumcheck over an add gate layer. In order to provide some intuition, we analyze the costs of a particular example, which may not encapsulate the general example for add gate layers.

Let us recall the add gate sumcheck equation: We can rewrite this as: As observed in XZZ+19, we only need to sum over the wirings which are non-zero (i.e., there exists a an addition from label in layer and label in layer to label in layer ). Call the set of non-zero wirings as . We can rewrite the summation as:

Mul Gate

Multiplication gate is nearly identical to addition gate. For mul gate, we have the binary wiring indicator predicate: Here, we have that if and only if the the 'th value in the 'th layer equals the product of the 'th value in the 'th layer with the 'th value in the 'th layer. The MLE of is identical to that of : and the polynomial relationship is defined nearly identically to that of gate: Assuming that gets bound to and gets bound to during sumcheck, a claim on this layer results in three total claims: one on (which the verifier can check on its own), one on , and one on .

Example

We start with two "source" MLEs, over two variables with four evaluations each, and wish to accumulate (add up) the product of the 0th and 2nd evaluations with that of the 1st and 3rd evaluations, and place this into the 0th evaluation in the resulting MLE. The result should be the MLE representing layer , i.e. , whose evaluations are all zero except for its 0th evaluation.

For example, let's say that the evaluations of are and those of are . We wish to multiply and , and and and have those be the zeroth evaluation of the resulting MLE, i.e. . We then wish to multiply and , and and and have those be the first evaluation of the resulting MLE, i.e. .

Then our "nonzero gate tuples" are as follows:

  • : The zeroth value in the 'th layer multiplied by the first value in the 'th layer contributes to the zeroth value in the 'th layer.
  • : The first value in the 'th layer multiplied by the zeroth value in the 'th layer contributes to the zeroth value in the 'th layer.
  • : similar reasoning to the above.
  • : similar reasoning to the above.

For all other binary tuples we have that , and our resulting MLE's evaluations should be as follows: . Note here for that we are able to add multiple products to each output value in the 'th layer, and that the same is true for both and . In other words, we actually have unlimited addition fan-in and degree-2 multiplication fan-in.

Costs

Over here, we go through some of the costs for the prover runtime, proof size, and verifier runtime when performing sumcheck over a mul gate layer (note that costs for add gate are very similar). In order to provide some intuition, we analyze the costs of a particular example, which may not encapsulate the general example for add gate layers.

Let us recall the mul gate sumcheck equation: We can rewrite this as: As observed in XZZ+19, we only need to sum over the wirings which are non-zero (i.e., there exists a an addition from label in layer and label in layer to label in layer ). Call the set of non-zero wirings as (we assume that there are at most nonzero mul gate values). We can rewrite the summation as:

The prover cost for sumcheck over a mul gate layer is as follows:

  • The prover must first compute the evaluations of for where . XZZ+19 splits this pre-processing into two phases (note that proving the gate layer follows the same strategy). First, we precompute (or stream) the values in in .
  • Next, we compute the "phase 1" preprocessing, where we sumcheck over the variables. Here, we can directly evaluate while "folding" by summing over the variables. Similarly, in the second phase, when we compute sumcheck messages over and already have evaluations for , we can "fold" by summing over the variables. Both of these preprocessing steps take time.
  • After preprocessing, the prover must compute sumcheck messages for the above relationship. Similarly to the preprocessing step above, sumcheck is done in two phases. First, the prover binds the variables, and then it binds the variables. The degree of each sumcheck message is , and thus the prover sends evaluations per round of sumcheck (this is the same for add gate). Since we are sumchecking over and , there are rounds of sumcheck and thus the prover cost is for the 'th round of sumcheck. The total prover sumcheck cost is thus
  • Letting be a constant, the total prover runtime (pre-processing + sumcheck) is

The proof size for sumcheck over mul gate layer is as follows:

  • There are + total sumcheck rounds, each with the prover sending over evaluations for a quadratic polynomial. The proof size is thus field elements, plus extra for the final claims on and .

The verifier cost for sumcheck over mul gate layer is as follows:

  • The verifier receives sumcheck messages with evaluations each, and each round it must evaluate those quadratic polynomials at a random point. Its runtime is thus with very small constants.