fix(crypt): Avoid expensive note commitment tree root recalculations in eq() methods

[teor2345]

Motivation

Re-calculating note commitment tree roots can take a long time if the root isn't cached in the state, or already calculated by Zebra.

Instead, it is cheaper to compare the tree frontier, which is at most 32 roots. (Less than 1 kB of byte comparisons.)

Specifications

https://docs.rs/incrementalmerkletree/0.4.0/incrementalmerkletree/frontier/struct.NonEmptyFrontier.html#impl-PartialEq%3CNonEmptyFrontier%3CH%3E%3E-for-NonEmptyFrontier%3CH%3E

Complex Code or Requirements

This fix helps avoid weird performance bugs in the next few state upgrades. We've already seen some performance issues in this code.

Solution

If both roots are cached, compare them. Otherwise, compare the whole frontier.

Review

This might be needed to get some tests for PR #7379 to pass.

Reviewer Checklist

• Will the PR name make sense to users?
  • Does it need extra CHANGELOG info? (new features, breaking changes, large changes)
• Are the PR labels correct?
• Does the code do what the ticket and PR says?
  • Does it change concurrent code, unsafe code, or consensus rules?
• How do you know it works? Does it have tests?

[upbqdn]

@Mergifyio update.

[mergify]

update .

✅ Branch has been successfully updated