I think it should start with `standard_recursion_config`, since the goal of the test is to start with a regular speed-optimized recursive proof and shrink it.
The final proof is a bit larger now, mainly because of the update to 100 bits, and partly (less importantly) because it starts with the now-standard arity 16. We could maybe switch from arity 16 to 8 somewhere in the chain, but I think that might require another proof layer, and didn't want to complicate it too much.
This results in 8 constant polynomials, which means our Merkle tree containing preprocessed polynomials has leaves of size 80 + 8 = 88. A multiple of 8 is efficient in terms of how many gates it takes to hash a leaf. Saves 17 gates.
* Suppress warnings about use of unstable compiler features.
* Remove unused functions.
* Refactor and remove PolynomialCoeffs::new_padded(); fix degree_padded.
Note that this fixes a minor mistake in the FFT testing code, where
`degree_padded` value was log2 of what it should have been, preventing
a testing loop from executing.
* Remove divide_by_z_h() and related test functions.
* Only compile check_{consistency,test_vectors} when testing.
* Move verify() to test module.
* Remove unused functions.
NB: Changed the config in the gadgets/arithmetic_extension.rs::tests
module which may change the test's meaning?
* Remove unused import.
* Mark GMiMC option as allowed 'dead code'.
* Fix missing feature.
* Remove unused functions.
* cargo fmt
* Mark variable as unused.
* Revert "Remove unused functions."
This reverts commit 99d2357f1c967fd9fd6cac63e1216d929888be72.
* Make config functions public.
* Mark 'reduce_nonnative()' as dead code for now.
* Revert "Move verify() to test module." Refactor to `verify_compressed`.
This reverts commit b426e810d033c642f54e25ebc4a8114491df5076.
* cargo fmt
* Reinstate `verify()` fn on `CompressedProofWithPublicInputs`.
For now, we can do shrinking recursion with 93 bits of security. It's not quite as high as we want, but it's close, and I think it makes sense to merge this and treat the 2^12 circuit as our main benchmark, as we continue working to improve security.
The effect on soundness error is negligible for our current field, but this introduces an assertion that could fail if we changed to a field with more elements in the "ambiguous" range.
* 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
* 2 challenges, 28 routed wires
2 challenges gives certain checks approximately (field_bits - degree_bits) * 2 bits of security, so we maintain our target of 100 bits for circuits with 2^14 gates or fewer.
28 routed wires is the min for `InterpolationGate`. A lower number helps reduce proof sizes. We can go back to a high number if there's any strong reason to reduce our gate count (e.g. if we were trying to hit 2^12).
* Check FRI conjectured security
* Fix
* Refactor recursion tests
E.g. the main part of `test_recursive_recursive_verifier` is now
```rust
let (proof, vd, cd) = dummy_proof::<F, D>(&config, 8_000)?;
let (proof, vd, cd) = recursive_proof(proof, vd, cd, &config, &config, false)?;
let (proof, _vd, cd) = recursive_proof(proof, vd, cd, &config, &config, true)?;
```
Also adds a new `test_size_optimized_recursion` to see how small we can make the final proof in a recursion chain. The final proof is ~74kb (depending on compression luck) and takes ~20s to prove on my M1 (depending on PoW luck).
* Refactor serialization
* Don't log timestamps
* 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
* Split up `PartitionWitness` data
This addresses two minor inefficiencies:
- Some preprocessed forest data was being cloned during proving.
- Some of the `ForestNode` data (like node sizes) is only needed in preprocessing, not proving. It was taking up cache space during proving because it was interleaved with data that is used during proving (parents, values).
Now `Forest` contains the disjoint-set forest. `PartitionWitness` is now mainly a Vec of target values; it also holds a reference to the (preprocessed) representative map.
On my laptop, this speeds up witness generation ~12%, resulting in an overall ~0.5% speedup.
* Feedback
* No size data (#278)
* No size data
* feedback
* Some changes to generator_indices_by_watches
- Index generators by the representatives (in disjoint-set forest terminology) of their watched targets, rather than the watched targets themselves. Enqueuing generators based on their watch lists then works correctly, so we no longer need the step where we reenqueue all generators.
- In #195, it was pointed out that this slows down witness generation a bit. I moved the indexing code to preprocessing, so the prover is a bit faster (~7ms for me).
* Outdated comment
* Panic instead of infinite loop if we get stuck
* BTree
* fmt
* 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
* Field: Default
It's done for primitive types like `u64`, so seems conventional, and some code in mir-core expects it.
* HashOut::ZERO
* Default for HashOut
* fmt
* pub elements
* Debug
* rand_from_rng
- Made some methods public, if they seemed like they'd be useful crates that depend on plonky2, and seemed like good/stable APIs
- Deleted a few things I didn't think seemed very useful
- Left a few for now that I was on the fence about
* 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
