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.
* 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
If we did it all with `ArithmeticGate`s, the main loop (with ~101 iterations of cubing and a couple adds) would be fairly expensive, so this uses a (much smaller) custom gate called `GMiMCEvalGate` which does all the computations for one iteration of that loop.
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).
