Open quotient polynomials at gz

[Al-Kindi-0]

This leads to a simplification of the code and has a also a simplifying effect on recursive verification.

Note: Ran some benchmarks and it seems that there is no noticeable performance changes.

[adr1anh]

Looks good, just left very minor nits.

[adr1anh]

Maybe it doesn't make much sense to optimize the verifier here, but we could compute this more efficiently like the recursive verifier.

[Al-Kindi-0]

I thought about it but it seemed like a non-negligible amount of work for a marginal improvement in our current context.
We can come back to it if we need to optimize the verifier for whatever reason, if you agree.

[adr1anh]

LGTM (but can't approve)

[plafer]

LGTM! Left a nit

[plafer]

Instead of re-using i, I would use .into_columns().into_iter().enumerate() (as i is not needed in subsequent loops)

[Al-Kindi-0]

Good point, changed it now

[irakliyk]

Looks good! Thank you! I left a few small comments inline. Also, I'd like to clarify a couple of points:

My understanding is that we went from:

$$ Y(x) = \sum_{i=0}^k{( \alpha_i \cdot (\frac{T_i(x) - T_i(z)}{x - z} + \frac{T_i(x) - T_i(z \cdot g)}{x - z \cdot g}) )} + \sum_{j=0}^m{\beta_j \cdot \frac{H_j(x) - H_j(z)}{x - z}} $$

Where $T_i(x)$ are trace columns and $H_i(x)$ are constraint evaluation columns.

To something like:

$$ Y(x) = \sum_{i=0}^{k+m}{( \alpha_i \cdot (\frac{T_i(x) - T_i(z)}{x - z} + \frac{T_i(x) - T_i(z \cdot g)}{x - z \cdot g}) )} $$

Where the first $k$ columns of $T_i(x)$ are trace columns and the remaining $m$ columns are the constraint evaluation columns.

Is this correct? If so, this seems like a bit more work (we also need to merge the evaluations at $g \cdot z$ for constraint composition columns, but I guess the expression is more uniform and so this simplifies things a bit - right?

Another thing that wasn't clear to me: for constraint evaluations at $z$ we have a check that they match evaluating constraints against the trace frame. But we don't have any such check for constraint evaluation at $z \cdot g$ (at least as far as I could tell). What prevents a malicious prover from putting some arbitrary data in there? Basically, how does the verifier check that constraint evaluations at $z \cdot g$ included in the QuotientOodFrame are actual evaluations rather than some arbitrary data.

[irakliyk]

Why do we need to have num_quotients as a separate filed here? Isn't basically the same as current_row.len()?

[Al-Kindi-0]

Indeed, it is not needed. Removed now

[Al-Kindi-0]

Is this correct? If so, this seems like a bit more work (we also need to merge the evaluations at g ⋅ z for constraint composition columns, but I guess the expression is more uniform and so this simplifies things a bit - right?

Actually, if I am not missing something, this should be, algorithmically at least, better for the prover than before as we have removed the synthetic divisions, one per constraint composition polynomial, and just kept the original two divisions that were used for the trace columns, one for z and one for gz.
In practice, the difference is probably not noticeable and I haven't observed it on the benchmarks I ran (Lamport as it is the example with largest constraint degree).

Another thing that wasn't clear to me: for constraint evaluations at z we have a check that they match evaluating constraints against the trace frame. But we don't have any such check for constraint evaluation at z ⋅ g (at least as far as I could tell). What prevents a malicious prover from putting some arbitrary data in there? Basically, how does the verifier check that constraint evaluations at z ⋅ g included in the QuotientOodFrame are actual evaluations rather than some arbitrary data.

There are, at least, two points I believe:

1. The prover usually provides the minimal number of openings necessary for the verifier to run the constraints evaluation check, but providing more does not hurt, at least plain soundness.
2. The fact that the new opened values are part of the DEEP polynomial gives us that, if the DEEP polynomial passes the FRI check, then the opening is a legit opening, with high probability. So the prover cannot send any value or else FRI would not pass.

[irakliyk]

Actually, if I am not missing something, this should be, algorithmically at least, better for the prover than before as we have removed the synthetic divisions, one per constraint composition polynomial, and just kept the original two divisions that were used for the trace columns, one for z and one for gz.
In practice, the difference is probably not noticeable and I haven't observed it on the benchmarks I ran (Lamport as it is the example with largest constraint degree).

Makes sense!

There are, at least, two points I believe:

1. The prover usually provides the minimal number of openings necessary for the verifier to run the constraints evaluation check, but providing more does not hurt, at least plain soundness.
2. The fact that the new opened values are part of the DEEP polynomial gives us that, if the DEEP polynomial passes the FRI check, then the opening is a legit opening, with high probability. So the prover cannot send any value or else FRI would not pass.

Yes, makes sense that FRI guarantees that openings at $g \cdot z$ are for polynomials with the right degree bounds. But would it also guarantee that these openings are for evaluations of constraint polynomials? Basically, could the prover pick some random polynomials of the right degree, evaluate them at $g \cdot z$, and then send openings of these polynomials? Or maybe it doesn't matter?

It has also been a while since I thought about how this works - so, could be missing something simple.

[Al-Kindi-0]

Yes, makes sense that FRI guarantees that openings at g ⋅ z are for polynomials with the right degree bounds. But would it also guarantee that these openings are for evaluations of constraint polynomials? Basically, could the prover pick some random polynomials of the right degree, evaluate them at g ⋅ z , and then send openings of these polynomials? Or maybe it doesn't matter?

It has to be the same polynomial that was opened at z and committed to in the constraint composition polynomials trace as the expression appearing in the DEEP poly is
$$\left(\frac{h_i(x) - h_i(z)}{x - z} + \frac{h_i(x) - h_i(gz)}{x - gz}\right)$$
were $h_i$ is one of the constraint composition polynomials.
So in other words, FRI passing tells us that the degrees of the "alleged polynomials" committed to in the constraints composition polys trace are low and that they open at the provided values in the OOD frame at both z and gz

[irakliyk]

It has to be the same polynomial that was opened at z and committed to in the constraint composition polynomials trace > as the expression appearing in the DEEP poly is
$$\left(\frac{h_i(x) - h_i(z)}{x - z} + \frac{h_i(x) - h_i(gz)}{x - gz}\right)$$
were $h_i$ is one of the constraint composition polynomials.
So in other words, FRI passing tells us that the degrees of the "alleged polynomials" committed to in the constraints composition polys trace are low and that they open at the provided values in the OOD frame at both z and gz

Ah yes - makes sense! Thank you for explaining!

[Al-Kindi-0]

Hopefully all feedback is addressed now :)

[irakliyk]

All looks good! Thank you!