Add MLE eval constraints

[andrewmilson]

This change is 

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.35%. Comparing base (586ecf4) to head (4994125).

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #742   +/-   ##
=======================================
  Coverage   92.35%   92.35%           
=======================================
  Files          91       91           
  Lines       12450    12450           
  Branches    12450    12450           
=======================================
  Hits        11498    11498           
  Misses        846      846           
  Partials      106      106           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[andrewmilson]

• Add eval order and interpolate to SecureEvaluation #794
• Add MLE eval constraints #742 👈
• Add eq evals constraints #741
• Add benchmarks for GKR lookups #673
• Implement LogupOps for SIMD backend #641
• Implement GrandProductOps for SIMD backend #640
• Implement GkrOps for SIMD backend #630
• Implement MleOps for SIMD backend #629
• Add GKR implementation of Logup lookups #623
• Add GKR implementation of Grand Product lookups #620
• Implement GkrOps for CPU backend #621
• Add batch GKR prover and verifier #581
• Rename CPU* structs to Cpu* to conform to Rust's naming convention #617
• Remove AVX backend #616
• Convert wide_fibbonacci AVX backend example to SIMD backend #615
• Update CI to test Wasm simd128, avx2 and aarch64 neon #614
• Fix CirclePointIndex bug in debug mode for 32-bit archs #613
• Change opt-level in benchmarks script #612
• Add benchmarks for SIMD m31 #611
• Add benchmarks for SIMD merkle #610
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @andrewmilson and the rest of your teammates on Graphite

[spapinistarkware]

Reviewed 1 of 3 files at r1, 1 of 2 files at r3, all commit messages.
Reviewable status: 1 of 3 files reviewed, 4 unresolved discussions (waiting on @andrewmilson)

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 11 at r3 (raw file):

pub fn mle_eval_check<E: EvalAtRow, const N_VARIABLES: usize>(
    eval: &mut E,
    point_meta: PointMeta<N_VARIABLES>,

I think this can be named better. What exactly does this hold?
Is it some precomuptation regarding the MLE evaluation point in EF^N_VARS ?
If so, maybe MleEvalPoint ?

Code quote:

PointMeta

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 12 at r3 (raw file):

    eval: &mut E,
    point_meta: PointMeta<N_VARIABLES>,
    mle_coeff: E::EF,

What's this?

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 15 at r3 (raw file):

    mle_claim: SecureField,
    eq_evals_at: &EqEvalsMaskAt<E, N_VARIABLES>,
    eq_evals_is: &EqEvalsMaskIs<E, N_VARIABLES>,

I don't understand what these are. Can they have better names?

Code quote:

    eq_evals_at: &EqEvalsMaskAt<E, N_VARIABLES>,
    eq_evals_is: &EqEvalsMaskIs<E, N_VARIABLES>,

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 23 at r3 (raw file):

    eq_evals_check(eval, point_meta, eq_evals_at, eq_evals_is);
    let mle_term = mle_coeff * eq_evals_at.curr;
    inclusive_prefix_sum_check(eval, mle_term, mle_claim, eq_evals_is.first, prefix_sum_at);

Lior suggested another way to do the prefix check, without is_first. I implemented it in logup. The idea is to first subtract claimed_sum/N_ROWS from the values, so that their sum is 0. Now, we dont need is_first, because the diff constraint applies also at the transition from the last row to the first.

1. Consider using it.
2. Consider reusing code from logup.rs

Code quote:

inclusive_prefix_sum_check(eval, mle_term, mle_claim, eq_evals_is.first, prefix_sum_at);

[andrewmilson]

Reviewable status: 1 of 3 files reviewed, 4 unresolved discussions (waiting on @spapinistarkware)

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 11 at r3 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

I think this can be named better. What exactly does this hold?
Is it some precomuptation regarding the MLE evaluation point in EF^N_VARS ?
If so, maybe MleEvalPoint ?

Done.

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 12 at r3 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

What's this?

Added comment

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 15 at r3 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

I don't understand what these are. Can they have better names?

Refactored to just a single EqEvalsMask

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 23 at r3 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

Lior suggested another way to do the prefix check, without is_first. I implemented it in logup. The idea is to first subtract claimed_sum/N_ROWS from the values, so that their sum is 0. Now, we dont need is_first, because the diff constraint applies also at the transition from the last row to the first.

1. Consider using it.
2. Consider reusing code from logup.rs

Done 1.
Didn't do 2. as the code in logup.rs seems quite coupled to LogUp

[spapinistarkware]

Reviewable status: 0 of 4 files reviewed, 3 unresolved discussions (waiting on @andrewmilson)

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 7 at r4 (raw file):

use crate::examples::xor::prefix_sum_constraints::PrefixSumMask;

pub struct MleEvalMask<E: EvalAtRow, const N_VARIABLES: usize> {

1. Like before, do we really need a struct here?
2. Do we need PrefixSumMask to be a struct? (e.g. does it hold preprocessed data shared by all rows?)

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 7 at r4 (raw file):

use crate::examples::xor::prefix_sum_constraints::PrefixSumMask;

pub struct MleEvalMask<E: EvalAtRow, const N_VARIABLES: usize> {

This struct isn't really the Mask I believe, since you are not gonna use it externally as a mask item. It's only here to evaluate the constraints. Whether this stays a struct or becomes a function, rename it to something that conveys this evaluates constraints.

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 9 at r4 (raw file):

pub struct MleEvalMask<E: EvalAtRow, const N_VARIABLES: usize> {
    /// Mask item on the column that interpolates all MLE coefficients in the lagrange basis.
    mle_coeff: E::EF,

Is this a coeff or a mask item? Maybe it's a column value? whatever you chose, make the name and documentation consistent.

[andrewmilson]

Reviewable status: 0 of 4 files reviewed, 3 unresolved discussions (waiting on @spapinistarkware)

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 7 at r4 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

1. Like before, do we really need a struct here?
2. Do we need PrefixSumMask to be a struct? (e.g. does it hold preprocessed data shared by all rows?)

Removed.

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 7 at r4 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

This struct isn't really the Mask I believe, since you are not gonna use it externally as a mask item. It's only here to evaluate the constraints. Whether this stays a struct or becomes a function, rename it to something that conveys this evaluates constraints.

Thanks

---

crates/prover/src/examples/xor/mle_eval_constraints.rs line 9 at r4 (raw file):

Previously, spapinistarkware (Shahar Papini) wrote…

Is this a coeff or a mask item? Maybe it's a column value? whatever you chose, make the name and documentation consistent.

Done

[spapinistarkware]

Reviewed 1 of 3 files at r1, 3 of 3 files at r5, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @andrewmilson)