* Refactor GMiMC code
Adds a sub-trait of `Field` called `GMiMCInterface`, which is similar to `PoseidonInterface`.
This lets us have different fields with different GMiMC constants in a type-safe way.
* Remove `Interface`
* Const generic for width
* Move some Field members to a Field64 subtrait
I.e. move anything specific to 64-bit fields.
Also, relatedly,
- Tweak a bunch of prover code to require `Field64`, since 64-bit stuff is used in a couple places, like the FRI proof-of-work
- Remove `bits()`, which was unused and assumed a 64-bit field
- Rename a couple methods to reflect that they're u64 variants
There are no functional changes.
* Field64 -> PrimeField
* Remove `exp_u32`, `kth_root_u32`
* PrimeField: PrimeField
* Move `to_canonical_biguint` as well
* Add back from_noncanonical_u128
* Disable ZK in large_config
Speeds up the tests from ~6m to ~1m (debug mode). `large_config` is crate-private so I don't think we need to worry about real users forgetting ZK, and I don't think ZK seems important in these tests, though we should probably have ZK enabled for a couple tests.
A couple tests need ZK or they fail; I added a TODO to look later.
This led to a few other changes:
- Fixed a bug where `trim` could truncate the final poly to a non-power-of-two length. This was improbable when ZK is on due to randomization.
- Gave a few methods access to the whole `CircuitConfig` vs `FriConfig` -- sort of necessary for the above fix, and I don't think there's much downside.
- Remove `cap_height` from `FriConfig` -- didn't really need it any more after giving more methods access to `CircuitConfig`, and having a single copy of the param feels cleaner/safer to me.
* PR feedback
It's just a wrapper around `Target`, which signifies that the wrapped `Target` has already been range checked. Should make it easier to audit code that expects bools.
I sort of "shifted" the loop in `fri_verifier_query_round` so that `fri_combine_initial` is called before the loop, and all `compute_evaluation` calls are in the loop (rather than the final one being outside). This lines up with my mental model of FRI, and I think it's more natural as it results in a loop with no branches, no `i - 1`s, and less state stored between iterations. Also added some comments etc.
Should be functionally equivalent to the old version.
* Bit of refactoring in FRI code
- Inline `OpeningSet[Target]` and their `verify` methods, as they had become fairly trivial wrappers
- Have the challenger observe the openings and generate alpha inside `verify_fri_proof`. Conceptually I think of it as part of the batch-FRI protocol, and it minimizes redundancy.
* Fix tests
No functional changes here. The biggest change was moving certain files into new directories like `plonk` and `iop` (for things like `Challenger` that could be used in STARKs or other IOPs). I also split a few files, renames, etc, but again nothing functional, so I don't think a careful review is necessary (just a sanity check).
We have two division methods: one "unsafe" one, which permits 0/0 = anything, and one "safe" one, for which 0/0 results in an unsatisfiable instance. The latter is slightly more expensive.
I switched a few calls over to safe division, where unsafe division didn't seem sound (or at least it wasn't obvious). For calls where unsafe division did seem sound, I added comments explaining why.
Closes#97.
