Closed moCello closed 8 months ago
I would even go for both fixes:
add_assign
and sub_assign
to truncate leading zeros before returningleading_coefficient
to not return an unexpected zero coefficientAdditionally I propose to also truncate the leading zeros before returning a Polynomial::from_slice
in 'fft/polynomial.rs' line 47.
Summary
Polynomials are stored as a vector of
BlsScalars
. A polynomial is the zero polynomial if 1) it is empty or 2) all coefficients in the vector are zero. We don’t want to store extra zero coefficients if we don’t need to, so almost every function on polynomials makes sure to callself.truncate_leading_zeros()
after each operation.However, there are two exceptions: in
add_assign
and insub_assign
, if two polynomials have the same degree, thentruncate_leading_zeros()
is not called. It’s possible for the highest coefficients to cancel out, leaving us with a non-zero polynomial that still has a “zero” leading coefficient.In 'fft/polynomial.rs', the
leading_coefficient()
function should return the largest non-zero coefficient of the polynomial. Currently, this function is marked as dead_code and not used anywhere in the repository, but future developers of this library could easily make a mistake here. Recommendation: Either fixleading_coefficient()
to ignore leading zeros, or changeadd_assign
andsub_assign
to calltruncate_leading_zeros
in the case of two polynomials with the same degree.Relevant Context (optional)
Finding 1 of the plonk audit.