ebfull
commented
2 years ago What's really going on is that the eval function inside of the groth16 prover was assuming that any term existing inside a linear combination (even ones with zero coefficients) increased the query densities, meaning that the multiexp later would assume a group element exists in the SRS with respect to that variable. In fact, a group element doesn't exist because a zero coefficient causes the QAP polynomial to be the zero polynomial for that element, and points at infinity are not stored in the proving key for efficiency purposes. This directly caused the error you were seeing ("expected more bases from source").
The fix is to ensure the prover skips over coefficients of zero as if they did not appear at all in the linear combination, so that it doesn't mistakenly increase the query density and assume that a group element will exist in the SRS.
The groth16 prover and generator can sometimes get out-of-sync.
Without the included patch, the included test cases error with
"expected more bases from source".I did not dig closely, but I think the problem is a disagreement about how to handle zero-coefficients in linear combinations.
Since such monomials are dead weight anyway, the included patch just filters them out.
Feel free to dig deeper or implement a different patch!
P.S.: linear combinations depend only on the (public) circuit, which is why variable-time zero testing does not leak secret data.