@@ -1018,33 +1018,37 @@ class ECCVMFlavor {
10181018 };
10191019
10201020 /* *
1021- * @brief When evaluating the sumcheck protocol - can we skip evaluation of all relations for a given row?
1021+ * @brief When evaluating the sumcheck protocol - can we skip evaluation of _all_ relations for a given row? This
1022+ * is purely a prover-side optimization.
10221023 *
10231024 * @details When used in ClientIVC, the ECCVM has a large fixed size, which is often not fully utilized.
1024- * If a row is completely empty, the values of z_perm and z_perm_shift will match,
1025- * we can use this as a proxy to determine if we can skip Sumcheck::compute_univariate_with_row_skipping
1025+ * If a row is completely empty, the values of `z_perm` and `z_perm_shift` will match,
1026+ * we can use this as a proxy to determine if we can skip `Sumcheck::compute_univariate_with_row_skipping`.
1027+ * In fact, here are several other conditions that need to be checked to see if we can skip the computation
1028+ * of all relations in the row.
10261029 **/
10271030 template <typename ProverPolynomialsOrPartiallyEvaluatedMultivariates, typename EdgeType>
10281031 static bool skip_entire_row ([[maybe_unused]] const ProverPolynomialsOrPartiallyEvaluatedMultivariates& polynomials,
10291032 [[maybe_unused]] const EdgeType edge_idx)
10301033 {
1031- // skip conditions. TODO: add detailed commentary during audit.
1034+ // SKIP CONDITIONS:
10321035 // The most important skip condition is that `z_perm == z_perm_shift`. This implies that none of the wire values
10331036 // for the present input are involved in non-trivial copy constraints. Edge cases where nonzero rows do not
10341037 // contribute to permutation:
10351038 //
10361039 // 1: If `lagrange_last != 0`, the permutation polynomial identity is updated even if
1037- // z_perm == z_perm_shift
1040+ // z_perm == z_perm_shift. Therefore, we must force it to be zero.
10381041 //
10391042 // 2: The final MSM row won't add to the permutation but still has polynomial identitiy
10401043 // contributions. This is because the permutation argument uses the SHIFTED msm columns when performing
1041- // lookups i.e. `polynomials. msm_accumulator_x[last_edge_idx] will change z_perm[last_edge_idx - 1] and
1042- // z_perm_shift[last_edge_idx - 1]
1044+ // lookups i.e. `msm_accumulator_x[last_edge_idx]` will change ` z_perm[last_edge_idx - 1]` and
1045+ // ` z_perm_shift[last_edge_idx - 1]`
10431046 //
1044- // 3. The value of `transcript_mul` can be non-zero at the end of an MSM of points-at-infinity, which will
1045- // cause `full_msm_count` to be non-zero while `transcript_msm_count` vanishes.
1047+ // 3. The value of `transcript_mul` is non-zero at the end of an MSM of points-at-infinity, which will
1048+ // cause `full_msm_count` to be non-zero while `transcript_msm_count` vanishes. We therefore force
1049+ // transcript_mul == 0 as a skip-row condition.
10461050 //
1047- // 4. For similar reasons, we must add that `transcript_op==0`.
1051+ // 4: We also force that `transcript_op==0`.
10481052 return (polynomials.z_perm [edge_idx] == polynomials.z_perm_shift [edge_idx]) &&
10491053 (polynomials.z_perm [edge_idx + 1 ] == polynomials.z_perm_shift [edge_idx + 1 ]) &&
10501054 (polynomials.lagrange_last [edge_idx] == 0 && polynomials.lagrange_last [edge_idx + 1 ]) == 0 &&
0 commit comments