Over quartic field extension (for now). This would be used in our FRI recursive verifier later, for the consistency check.
To summarize the wires,
- `n` inputs for the `n` points to interpolate (don't need `4n` since they'll be in the subgroup of the base field)
- `4n` inputs for the `n` (extension field) values to interpolate
- `4` inputs for the point to evaluate the interpolant at (beta, which will be drawn from the extension field right?)
- `4` outputs for the interpolated value
- `4n` internal wires for the interpolant's coefficients
This definitely isn't the most optimal approach, e.g. we could route in a single "base" point and derive its neighboring points, but just wanted to keep it simple for now.
My recent change made `padded` panic if the padded length is less than the current length. I figured that might indicate that something unexpected was going on, so might be good to fail fast.
It looks like `inv_mod_xn` was relying on the old `padded` behavior, and it seems correct AFAIK, i.e. in this case it wasn't a symptom of anything going wrong.
We could also restore the old behavior of `padded` if you prefer; let me know if you have a preferennce.
- At least on my Linux machine, a signiciant amount of time (> 50%) was spent inside
OsRng.
- Likely due to blocking behaviour of the rng devices on Linux.
- thread_rng should not block, but at the same time should provide good
enough rng.
Porting over some code from `old_polynomial`, and changing `ListPolynomialCommitment` to use the newer API.
There's one remaining use of `old_polynomial` for long division; I think that can eventually go away when we switch to doing values-only FRI (unless another use comes up).
