[proof] converting vectors of F to single F element

[mimoo]

This PR removes vectors from several proof structs (e.g. ProofEvaluations). The vectors were initially used because some of the evaluations were "chunked", but we don't do this anymore. Proof:

[kimchi/src/verifier.rs:483] proof.evals[0].w[0].len() = 1
[kimchi/src/verifier.rs:484] proof.evals[0].z.len() = 1
[kimchi/src/verifier.rs:485] proof.evals[0].s[0].len() = 1
[kimchi/src/verifier.rs:486] proof.evals[0].generic_selector.len() = 0
[kimchi/src/verifier.rs:487] proof.evals[0].poseidon_selector.len() = 0
[kimchi/src/verifier.rs:488] proof.evals[0].[lookup.as](http://lookup.as/)_ref().unwrap().sorted[0].len() = 1
[kimchi/src/verifier.rs:489] proof.evals[0].[lookup.as](http://lookup.as/)_ref().unwrap().aggreg.len() = 1
[kimchi/src/verifier.rs:490] proof.evals[0].[lookup.as](http://lookup.as/)_ref().unwrap().table.len() = 1
[kimchi/src/verifier.rs:491] proof.evals[0].[lookup.as](http://lookup.as/)_ref().unwrap().[runtime.as](http://runtime.as/)_ref().unwrap().len() = 1

The changes are pretty straight forward: I simply change things like Vec<F> to F and remove code that's not relevant anymore.

There's one thing that seems like a logic change (but is not): I do not include a polynomial in the evaluation proof if its associated commitment in the verifier index is empty. This is because of the following:

so, ran into an interesting edge case in our codebase, for committing to the zero polynomial we just have an empty commit (literally an empty vec), and when we do the evaluation proof we just omit such zero polynomials from the combined inner product. So for example, if you don't use poseidon in your circuit, the poseidon selector will be all zero and we will not add it to the aggregated evaluation proof. It also means we can't hide such a polynomial commitment.

It sounds sensible since pedersen commitments work by doing an inner product of a polynomial coeff with the URS' generators, and so we would get the point at infinity (and we can't encode that since we're in affine coordinates). But that also means we have some issue if a private polynomial evaluates to all zeros (I think the codebase doesn't address that edgecase). Would a private polynomial ever evaluate to all zeros? I'm guessing not at least due to the random rows (the probability would be very low).

Note that it would be nice to have two follow up to this PR:

• refactor of the combine inner product function: https://github.com/o1-labs/proof-systems/pull/448
• make absorb_evaluations less error-prone by using a macro https://github.com/o1-labs/proof-systems/issues/221

[mimoo]

I think I narrowed the issue:

other:
[Fp256(BigInteger256([0, 0, 0, 0]))]
[Fp256(BigInteger256([0, 0, 0, 0]))]
orign:
[]
[]

the PCS doesn't like it when I pass [0] instead of []:

    for (evals_tr, shifted) in polys.iter().filter(|(evals_tr, _)| !evals_tr[0].is_empty()) {

https://github.com/o1-labs/proof-systems/blob/master/poly-commitment/src/commitment.rs#L434

[mimoo]

closes https://github.com/o1-labs/proof-systems/issues/231

[mimoo]

added an AbsorbableScalarField trait in the last commit (for lack of a better name)

[mimoo]

sounds like I can't get consensus on this PR. I still believe it's the best route, but at the very least I'll leave this open for when I have time to submit smaller PRs that implement some of the ideas here.

[github-actions[bot]]

Stale pull request message