* Specialize `InterpolationGate`
To cosets of subgroups of roots of unity. This way
- `InterpolationGate` needs fewer routed wires, bringing our minimum routed wires down from 28 to 25.
- The recursive `compute_evaluation` avoids some multiplications, saving 100~200 gates depending on `num_routed_wires`.
* Update test
* feedback
For examlpe, if I change a test to use `ConstantArityBits(4, 5)`, I get
To efficiently perform FRI checks with an arity of 16, at least 152 wires are needed. Consider reducing arity.
* Replace `CrandallQuarticField` with a more generic `QuarticExtension`
And likewise for `CrandallQuadraticField`.
There are a few parameters which we can't automatically derive (in const Rust), so I specified them in a `AutoExtendable` trait.
This would make it fairly easy to add extension fields for `GoldilocksField` and any future fields.
* Attempt to derive 2-adicity, see Hamish's feedback
* Simplify TWO_ADICITY based on chat with Hamish
* PR feedback
* Merge AutoExtendable into Extendable (#235)
* 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
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).
* Have add_gate take a generic type instead of GateRef
There are a couple advantages
- Users writing their own gates won't need to know about the `GateRef` wrapper; it's more of an internal thing now.
- Easier access to gate methods requiring `self` -- for example, `split_le_base` can just call `gate_type.limbs()` now.
* Update comment
* Always insert
With this approach, we don't need `Target::PublicInput`; any routable `Target` can be marked as a public input via `register_public_input`. The circuit itself hashes these targets, and routes the hash output to the first four wires of a `PublicInputGate`, which is placed at an arbitrary location in the circuit.
All gates have direct access to the purported hash of public inputs. We could think of them as accessing `PI_hash_i(x)` (as in Plonk), but these are now (four) constant functions, so they effectively have direct access to the hash itself.
`PublicInputGate` checks that its first four wires match this purported public input hash. The other gates ignore the hash.
Resolves#64.
