* 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!
* Simpler Keccak pseudo-permutation
After rejecting a value, I think it's a little simpler to continue the hash chain vs retrying with an incremented nonce.
* PR feedback
* fix byte order
My goal is to make the FRI code independent of circuit objects like `CommonCircuitData`, so that it can be reused by STARK code which won't involve those objects.
A few changes here:
- Move `rate_bits` and `cap_height` into `FriConfig`.
- Move `degree_bits` into `FriParameters` (since it's instance size specific).
- Make `FriParams` contain `FriConfig`, so FRI methods can take just the former and access fields in both.
- Replace `CommonCircuitConfig` with `FriParams` in FRI prover methods.
The FRI verifier methods still involve circuit objects, as they have PLONK logic in `fri_combine_initial`. Will think about how to deal with that after this.
