The 2^12 change made this outdated. We no longer need to shrink degree (since normal recursive proofs are 2^12), so we can simplify a bit. We just boost the rate, then do a size-optimized proof. (Without doing the rate boost first, the final proof would be over 2^12.)
Configured for 93 bits security for now, but the PoW settings are low so that'll be easy to increase.
~45kb with current settings.
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.
Rather than creating arithmetic gates with potentially unique constants.
Should be strictly cheaper, though it only seems to save one gate in practice.
* 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.
