feat: Poseidon2 gates for Ultra arithmetisation - #7494
Conversation
68bf98a to
1d86341
Compare
5304c7e to
f1edf5f
Compare
| void set_fixed_size(uint32_t size_in) { fixed_size = size_in; } | ||
| }; | ||
|
|
||
| class TranslatorArith { |
There was a problem hiding this comment.
This could just be moved to Translator, randomly stumbled across it
fe9b300 to
83ecd92
Compare
left a comment
•
There was a problem hiding this comment.
Nice work. Would like to see the before and after difference in the number of gates for the ultra recursive verifier as well if possible.
also a 650k gate difference in the tube circuit seems insane if its just from hashing. That's like 10000 calls to hash()
| using Verifier = UltraVerifier_<UltraFlavor>; | ||
| Prover tube_prover{ *builder }; | ||
| // Print the number of gates post finalisation for a precise result | ||
| info("num gates in tube circuit: ", builder->get_num_gates()); |
There was a problem hiding this comment.
Erm I guess it's good info generally when running e2e tests
There was a problem hiding this comment.
note that it calls get_num_gates() and not builder.num_gates. As a sidenote, maybe we can change the name of get_num_gates() to estimate_num_finalized_gates()
| @@ -1 +1 @@ | |||
| barretenberg_module(commitment_schemes_recursion commitment_schemes stdlib_primitives) No newline at end of file | |||
| barretenberg_module(commitment_schemes_recursion commitment_schemes stdlib_poseidon2) No newline at end of file | |||
There was a problem hiding this comment.
why do we need stdlib poseidon and not primitives for commitment schemes?
There was a problem hiding this comment.
the module doesnt link without poseidon now that it's enabled and stdlib_poseidon2 already includes stdlib_primitives
| # np.set_printoptions(formatter={'int': hex}) | ||
|
|
||
| EXTENDED_RELATION_LENGTH = 13 | ||
| EXTENDED_RELATION_LENGTH = 12 |
There was a problem hiding this comment.
A prior line of work decreased it (using different etas rather than powers of eta) but because nothing in the logic changed, that PR could just remove one value in the combiner tests and this file wasnt modified. Now I had to rerun the script and realised we have one extra eval, but my PR didnt specifically decreased this
| EXPECT_TRUE(CircuitChecker::check(*builder)); | ||
|
|
||
| // Print the number of gates post finalisation | ||
| info("Recursive Verifier: num gates = ", builder->num_gates); |
There was a problem hiding this comment.
maybe could have both actually and mark which one is pre/post finalization
| alpha[idx] = transcript->template get_challenge<FF>("alpha_" + std::to_string(idx)); | ||
| } | ||
|
|
||
| // TODO(https://github.com/AztecProtocol/barretenberg/issues/1041): Once hashing produces constraints for Ultra in |
There was a problem hiding this comment.
I'm not opposed to sprinkling TODOs in the code FWIW it helps keep them top of mind (as long as they link an issue that can then be used for cleanup)
There was a problem hiding this comment.
this TODO is supposed to be resolved by this PR
|
|
||
| bool broke(false); | ||
| auto check_eq = [&broke](auto& p1, auto& p2) { | ||
| EXPECT_TRUE(p1.size() == p2.size()); |
There was a problem hiding this comment.
also could have checked that the circuit sizes of the vks were the same, but this works.
| if (sumcheck_verified.has_value() && !sumcheck_verified.value()) { | ||
| info("Sumcheck verification failed."); | ||
| return false; | ||
| // return false; |
There was a problem hiding this comment.
wopsie, leftover from debugging, thanks for spotting
…hing is still not working
| builder->add_recursive_proof(current_aggregation_object); | ||
|
|
||
| info("num gates in tube circuit: ", builder->get_num_gates()); | ||
| info("num gates in tube circuit: ", builder->num_gates); |
There was a problem hiding this comment.
maybe say that this is num prefinalized gates in tube circuit
| stdlib::field_t b(stdlib::witness_t(&builder, fr::random_element())); | ||
| stdlib::field_t c(&builder); | ||
| size_t passes = (1UL << log2_num_gates) / 4 - 4; | ||
| size_t passes = (1UL << log2_num_gates) / 4 - 8; |
There was a problem hiding this comment.
I will add a comment, the function fills a circuit up ot the desired numbers of gates for the benchmark, ensuring finalisation and the add gates to ensure non zero polys method wont cause it to go to the next power of 2 (or at least that was my deduction). Because we enabled poseidon add gates to ensure non zero polys will add more gates so i need to lower a bit the number of passes
…n-ultra' into mm/poseidon-relation-ultra
Add Poseidon2 gates to the
UltraCircuitBuilderwhich now ensures that recursive verifier instantiated with the Ultra arithmetisation produce the correct number of constraints.Updates required:
Tube circuit changes in # of gates (post finalisation):
Closes AztecProtocol/barretenberg#1041