* Replace `proof_to_proof_target`
With a `add_virtual_proof_with_pis` method that uses the inner circuit data, but does not require constructing a proof.
Note that this doesn't support IVC yet. For that, I think we can add a variant of `add_virtual_proof_with_pis` that takes several parameters like FRI arities, but does not involve `CommonCircuitData` (since no circuit has been build yet). It might also be best to avoid large objects like `FriParams`, and pass just the data we need.
Then there will be some nontrivial work to do recursion with "estimated" parameters (degree, arities, etc), check if the estimates were correct, and try again if not.
* PR feedback
* Bit-order in-place reversal optimizations
* optimization/simplification
* Done modulo documentation and testing on x86
* Minor type fixes on non-ARM
* Minor x86
* Transpose docs
* Docs
* Make rustfmt happy
* Bug fixes + tests
* Minor docs + lints
It works fine if we bound recursion methods with `C::Hasher: AlgebraicHasher<F>`. This bound feels natural to me - it's like saying "the recursion methods assume the inner hasher has a circuit implementation".
FFTs became proper benches, while recursion became tests. We might consider having either bins or benches for recursion in the future, but the code in this old recursion bin won't be useful, so might as well delete it for now.
I.e. instead of opening `Z` at `zeta` and `g zeta` by running FRI on a quotient involving an interpolant, we just run FRI on two separate opening expressions, one for `zeta` and one for `g zeta`.
A few motivations for this:
- I think this will make it slightly easier to generalize our FRI code to work with STARKs. I.e. if we have an object representing the structure of polynomial openings in an IOP, that object will be slightly simpler.
- It's less code. We could potentially remove some more code, e.g. the generality of `compute_quotient` is no longer needed, but I left it for now.
- It saves 3 gates!
