I believe I was mistaken earlier, and hash-based commitments actually call for `r = 2*security_bits` bits of randomness.
I.e. I believe breaking a particular commitment requires `O(2^r)` work (more if the committed value adds entropy, but assume it doesn't), but breaking one of `n` commitments requires less work.
It seems like this should be a well-known thing, but I can't find much in the literature. The IOP paper does mention using `2*security_bits` of randomness though.
* Automatically select FRI reduction arities
This way when a proof's degree changes, we won't need to manually update the `FriConfig`s of any recursive proofs on top of it.
For now I've added two methods of selecting arities. The first, `ConstantArityBits`, just applies a fixed reduciton arity until the degree has shrunk below a certain threshold. The second, `MinSize`, searches for the sequence of arities that minimizes proof size.
Note that this optimization is approximate -- e.g. it doesn't account for the effect of compression, and doesn't count some minor contributions to proof size, like the Merkle roots from the commit phase. It also assumes we're not using Merkle caps in serialized proofs, and that we're inferring one of the evaluations, even though we haven't made those changes yet.
I think we should generally use `ConstantArityBits` for proofs that we will recurse on, since using a single arity tends to be more recursion-friendly. We could use `MinSize` for generating final bridge proofs, since we won't do further recursion on top of those.
* Fix tests
* Feedback
* Derive challenges from other proof fields
* Delete failing test
Seems really hard to get the challenges right with the new model.
* Move PoW check
* Other feedback
* 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
Very minor things:
- A few renames
- Instead of having two constructors call a third constructor, just have one constructor call the other.
- Invoke FFT with the option that specifies the inputs are mostly zero, as a (minor) optimization
- Remove unused field
* 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
* Add a reduce_polys_base
Reducing the polynomials in `open_plonk` was taking ~100ms on my machine. It was converting BF polynomials to the EF early on; by doing more work in the BF we can reduce it to ~20ms.
* PR feedback
* Add a tree of scopes for proving times
To replace the old `timed!` macro, which had no hierarchy.
It's similar to `ContextTree`, which tracks gate counts of circuit operations.
This gives a more organized output, with indentation levels based on scope depth, parent durations listed before child durations, etc.
* PR feedback
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).
