Repository navigation
Gate count jumps after finalization #875
Description
Activity
Ended up tracking this back to a discrepancy in the non-native-field gate count produced by
get_num_gates()and the actual number of nnf gates that are produced infinalize_circuit()and added to thenum_gatestotal. Note thatget_num_gatesdoes not account for "de-duplications" in nnf gates, whereasfinalize_circuit()does. So before finalization,get_num_gates()overestimates how many nnf gates we'll need. During finalization we actually add fewer than expected due to duplicates. When we call get_num_gates a second time, it doesn't compute it, it just returnsnum_gatesdirectly, and thus the total is lower. (I suspect this is showing up for the first time or at least more prominently in these IVC tests because our mock circuits are stupid and are probably performing lots of duplicate operations).One solution could be to add some kind of deduplication logic to
get_num_gates. Another could be to simply add an assert that makes sure you've finalized before checking the number of gates.- added a commit that references this issue
on Feb 29, 2024 - added a commit that references this issue
on Mar 1, 2024 Perhaps this is resolved by AztecProtocol/aztec-packages#5211
@codygunton I don't think so but I'd have to dig in to be sure. The Pr you linked was an ECCVM optimization but the num_gates issue is purely an Ultra issue, i.e. unrelated to Goblin altogether
This was resolved with the introduction of
get_num_finalized_gates_inefficient()which simply performs finalization. The issue was in the method for estimating finalized gates without actually doing it which has been removed.
While creating instance during IVC, if we compare the number of gates before and after finalization, we'll get the following:
So there's obviously some bug