is_zero_hole is intended for proactive randomization, but there is a (miniscule) chance that sum of two polynomials will have lower degree

[bennetyee]

https://github.com/oasisprotocol/oasis-core/blob/b0e6bc88be7a3fe051ea1d35b06e8d33691d5aec/secret-sharing/src/poly/univariate.rs#L85

The is_zero_hole and to_zero_hole methods are used for proactive polynomial randomization. however, we aren't doing anything to ensure that h(x) = f(x) + g(x) where g(x) is a zero hole polynomial would yield deg h = deg f. a suggestion is to normalize the polynomial representation to require the leading coefficient to be 1. The roots of a polynomial f(x) and the monic version derived by multiplying the coefficients with the multiplicative inverse of the leading coefficients will be the same, and when we add two polynomials in this representation, we just have to multiply by TWO_INV, which is required by ff::PrimeField, through the coefficient sums.

While the probability of polynomial degree reduction is miniscule, this should be an easy change to avoid the possibility altogether. It would also be reasonable to just comment and say that we're aware of the possibility and that the probability (1/p) of occurrence is deemed sufficiently small / negligible.

[bennetyee]

nb: let to-monic(f) be a function on polynomials that does what the name suggests.

let f(x) and g(x) be any degree d polynomial. in general, to-monic(to-monic(f) + to_monic(g)) \ne to-monic(f+g), i.e., to-monic and + do not commute.

however, there exists g' such that to-monic(to-monic(f) + to-monic(g')) = to-monic(f + g), so the space of all possible polynomials is reachable.