triage(AztecNr): Investigate gate usage for the library

[LHerskind]

Investigate the "gate usage" of the aztec nr library. Create issues under optimisations in #7071 for heavy library functions such that it can be properly investigated how to optimise it.

Example output from the task:

• BalancesMap.sub is expensive, since it is nullifying a lot of many notes

[benesjan]

Note: I am starting profiling transfer function of Token and I'll be posting insights in individual comments.

1) compute_note_hash_for_read_request costs 148k gates because there is an ugly if else which results in us having gates there from both compute_unique_note_hash and compute_inner_note_hash functions. Both of these do multiple rounds of hashing (currently pedersen).

This function is called whenever we are fetching any notes (which is very common) so trying to optimize that seems to make sense.

Because of the if else we have there gates for compute_inner_note_hash twice:

The compute_unique_note_hash branch is triggered when nonce is non-zero.

Could we get rid of the if-else and always hash with nonce (even when zero)?

[benesjan]

Note: The optimization proposed below was tackled in this PR.

2) destroy_note costs 557k gates (33% of total current cost).

There is one obvious optimization to be done which was spotted a long time ago and is tracked in this issue - we compute note hash twice: once in compute_nullifier and once in the function itself when.

The solutions proposed in https://github.com/AztecProtocol/aztec-packages/issues/1718 seems too complex to me (maybe because they were assessed a long time ago). A more obvious way to do it would be to expose both values from compute_nullifier function. It would make the API uglier but generally the function is not really called directly by devs in the majority of usecases (we call that directly only in the Claim contract):

So the ugliness might be fine.

compute_note_hash_for_consumption costs 235k gates so not calling that twice would be significant.

Update: Lasse and Nico pointed out in scrum that the gate count of the function is so large because in the transfer function it's summed over 32 notes (which are iterated over). So the gain will be much smaller in cases working with individual notes.

[benesjan]

Outdated so closing