feat: ClientIvc recursive verifier #6721
Conversation
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Proof generationEach column represents the number of threads used in proof generation.
L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.
Stats on running time collected for app circuits
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contract classes are registered in the tx.
Transaction size based on fee payment method | Metric | | |
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'C++ Benchmark'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.05.
| Benchmark suite | Current: fd1ba5f | Previous: 7b420cd | Ratio |
|---|---|---|---|
nativeconstruct_proof_ultrahonk_power_of_2/20 |
6036.137139999993 ms/iter |
5497.058484000007 ms/iter |
1.10 |
This comment was automatically generated by workflow using github-action-benchmark.
CC: @ludamad @codygunton
|
|
||
| namespace bb::stdlib::recursion::honk { | ||
|
|
||
| void ClientIvcRecursiveVerifier_::verify(const ClientIVC::Proof& proof, VerifierInput& data) |
There was a problem hiding this comment.
I think we settle on either IVC or Ivc when it comes to naming
There was a problem hiding this comment.
updated to IVC
| // Perform recursive folding verification | ||
| FoldingVerifier folding_verifier{ builder, data }; | ||
| auto recursive_verifier_accumulator = folding_verifier.verify_folding_proof(proof.folding_proof); | ||
| auto native_verifier_acc = std::make_shared<VerifierInput::Instance>(recursive_verifier_accumulator->get_value()); |
There was a problem hiding this comment.
thinking out loud: if these two would share the same builder we wouldn't have to call get_value here. But probably not worth investing time atm, especially since we're not sure what's gonna happen when adding ZK
There was a problem hiding this comment.
Yeah not a top priority but I agree, might make sense to have these two more integrated. Currently we might be duplicating the final accumulator in the witness doing it this way
| #include "barretenberg/stdlib/honk_recursion/verifier/decider_recursive_verifier.hpp" | ||
|
|
||
| namespace bb::stdlib::recursion::honk { | ||
| class ClientIvcRecursiveVerifier_ { |
There was a problem hiding this comment.
I wonder whether we should template this by builder.. unlikely we're going to use MegaCircuitBuilder but it's worth having the mechanism to quickly switch
There was a problem hiding this comment.
I don't think this is worth doing, at least not until we need it. Using mega requires using Goblin so it changes the whole dynamic of what this class does
| // Generate the recursive verification circuit | ||
| verifier.verify(proof, verifier_input); | ||
|
|
||
| EXPECT_TRUE(CircuitChecker::check(builder)); |
There was a problem hiding this comment.
can you also make sure we can do full proving and verification of the client ivc recursive verifier in this test
There was a problem hiding this comment.
I can but ideally we won't do full proof construction in these test since it'll be very time consuming. CheckCircuit should be nearly just as good and a couple orders of magnitude faster
…/aztec-packages into lde/clientivc_rec_verifier
Changes to circuit sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
Adds a ClientIvc recursive verifier which currently consists only of a PG rec verifier and Decider rec verifier. A goblin recursive verifier will be implemented in a separate PR then added to this work to complete the ClientIvc recursive verifier.