refactor: generate public tail hints in noir #8113
Conversation
Changes to circuit sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
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 8 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
AVM SimulationTime to simulate various public functions in the AVM.
Public DB AccessTime to access various public DBs.
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 | | |
| // we're in a run, so this container must have a lower counter. | ||
| // note we don't check for overflow here, as the run_lengths array must be correct. | ||
| assert( | ||
| current_container.counter() <= original_array[i + 1].counter(), "Containers in a run must be sorted by counter" |
There was a problem hiding this comment.
The old code only checked that items in each run meet the requirement - same position with incrementing counters. But we can split items of the same position into two runs and it would pass.
| TestItem { value: 33, counter: 2 }, | ||
| TestItem::empty(), | ||
| TestItem::empty() | ||
| ]; |
There was a problem hiding this comment.
The previous code would reverse the ordering of items with the same counter. The result would be:
[
TestItem { value: 22, counter: 0 },
TestItem { value: 44, counter: 0 },
TestItem { value: 11, counter: 0 },
TestItem { value: 55, counter: 1 },
TestItem { value: 33, counter: 2 },
TestItem::empty(),
TestItem::empty()
]
Which would be wrong when sorting an array that has values emitted from private.
| // Ensure the array is sorted | ||
| // for i in 0..N - 1 { | ||
| // assert(ordering(result[i], result[i + 1])); | ||
| // } |
There was a problem hiding this comment.
We don't need this because of the assert and get_sorting_index above, IIUC?
There was a problem hiding this comment.
Yes! And this additional check prevents features that require keeping ordering unchanged. For example, in public land, the final array can contain items with 0 counter (emitted from private), and items with non-zero counter (emitted from public). We don't want to change the ordering of the items with 0 counter because they were already sorted in private.
So we need ordering(b, a) (run in get_sorting_index) to be false so the two items won't be swapped. But then it will fail the check if we apply the ordering again after they are "sorted".
And this is only used by unconstrained functions. We always use other constrained functions to check if the results are sorted correctly.
sort_by_counterandassert_deduped_array.assert_combined_sorted_transformed_value_arrayto check the output arrays from public tail that they are merged and sorted correctly.