* Draw challenge points from the extension field
* Now building
* Misc
* Default eval_unfiltered_base
* fmt
* A few field settings
* Add to Sage
* Display tweak
* eval_filtered_base
* Quartic in bench
* Missing methods
* Fix tests
* PR feedback
This is mostly copy/pasted from plonky1, although there are some differences. E.g. in plonky2 virtual targets are not routable, so they're no longer added as partitions.
Before it was storing leaf data and Merkle roots, but nothing in between, since it wasn't yet interacting with intermediate layers (but it will once we hook up the FRI code).
As discussed, it seems like the batch opening argument will be a significant cost, and we can reduce that cost by not including shifted openings (except for `Z`s which need them).
I think this is the recommended way to apply Fiat-Shamir, to avoid any possible attacks like taking someone else's proof and using it to prove a slightly different statement.
When we had a large field, we could just pick random shifts, and get disjoint cosets with high probability. With a 64-bit field, I think the probability of a collision is non-negligible (something like 1 in a million), so we should probably verify that the cosets are disjoint.
If there are any concerns with this method (or if it's just confusing), I think it would also be reasonable to use the brute force approach of explicitly computing the cosets and checking that they're disjoint. I coded that as well, and it took like 80ms, so not really a big deal since it's a one-time preprocessing cost.
Also fixes some overflow bugs in the inversion code.
