Adapt to new libff multiexp interface & use faster methods #81
Conversation
Knowledge commitments now expose mixed addition-related methods, so libff code that relies on mixed addition being supported (e.g. multiexp with the djb method) can now be used.
| @@ -363,6 +363,9 @@ r1cs_ppzksnark_keypair<ppT> r1cs_ppzksnark_generator(const r1cs_ppzksnark_constr | |||
|
|
|||
| libff::enter_block("Compute the H-query", false); | |||
| libff::G1_vector<ppT> H_query = batch_exp(libff::Fr<ppT>::size_in_bits(), g1_window, g1_table, Ht); | |||
| #ifdef USE_MIXED_ADDITION | |||
There was a problem hiding this comment.
What's the story with all these new #ifdef USE_MIXED_ADDITIONs? Why needed now but not before? Any way to avoid them? What will happen if they're accidentally omitted?
There was a problem hiding this comment.
When libsnark is compiled with USE_MIXED_ADDITION, some functions (at least multi_exp_with_mixed_addition and multi_exp<..,..,multi_exp_method_djb>) assume that mixed addition can be performed between arbitrary group elements and the input elements. This means the input elements have to be in special form, and converting them to that form is what's happening in the #ifdefd blocks.
In one case, the existing code was already assuming that the input was in special form, even though it wasn't specifically converted. So the ifdef'd parts were actually already needed, and their absence was a bug. Unfortunately, I don't quite remember where that was.
In the rest of the cases, the conversion had to be added to switch from multi_exp_method_bos_coster to multi_exp_method_djb (because input in special form is needed by the latter, but not by the former).
If they are omitted, multiexponentiation might give wrong answers, but only when compiling with USE_MIXED_ADDITION.
multi_exp_method_djb could be modified to not assume that the input is in special form, but that would make provers a little bit slower. Given that there were already instances where input was being converted to special form like this (e.g. here), I figured it would not be a problem to add more.
|
Looks good to me, modulo the |
The method was renamed in libff.
pull request 10 in libff introduces a new interface for multiexponentiation and a faster multiexponentiation algorithm, djb.
This pull request first just adapts the libsnark code to use this new interface, fixing a couple include-related bugs in the process, and then, in commit 6137636, switches the multiexponentiation method to the djb in the cases where we've found it to be beneficial.
Specifically, we have observed the following improvements:
the prover in
./libsnark/profile_ram_ppzksnark 32 16 100 10 300(a sample TinyRAM ppzkSNARK, which is reduced to a R1CS with 999788 constraints and 745726 variables) runs 25% fasterthe prover in
./libsnark/profile_uscs_ppzksnark 1000000 20(1000000 constraints, 20 variables) runs 53% fasterthe prover in
./libsnark/profile_r1cs_gg_ppzksnark 1000000 700000(1000000 constraints, 700000 variables) runs 33% faster(all with
MULTICORE=off,USE_MIXED_ADDITION=on, on my personal machine with aIntel(R) Core(TM) i3-6100U CPU @ 2.30GHzCPU)