fix: fix assert_split_transformed_value_arrays conditional access index underflow

[MirandaWood]

Closes #10592

Bug

We previously commented out the array checks for private logs in tail to public (#10593) because a constraint was mysteriously failing (#10530).

It failed because of an attempted underflow array access e.g. array[i - 1] where i = 0. The thing is that the array access shouldn't have been called because it was wrapped in an if statement.

I don't think this has anything to do with logs, it just so happened that logs were the first tx effect array to have num_non_revertibles = 0 in the above bot run.

Fix

In this case we had a private log with .counter() = 8, split_counter = 3, and num_non_revertibles = 0. However the constraint failure* was coming from sorted_array[num_non_revertibles - 1] below:

 if num_non_revertibles != 0 {
        assert(
            sorted_array[num_non_revertibles - 1].counter() < split_counter,
            "counter of last non-revertible item is not less than the split counter",
        );
    }

I added a hacky fix which prevents the constraint failure by simply multiplying the LHS by zero if the array access will fail:

   if num_non_revertibles != 0 {
        let is_non_zero = (num_non_revertibles != 0) as u32;
        assert(
            sorted_array[num_non_revertibles - 1].counter()*is_non_zero < split_counter,
            "counter of last non-revertible item is not less than the split counter",
        );
    }

*(If we had incorrectly entered the if statement and the assertion failed, the error would be Assertion failed, but the error was Constraint failure).

Repro

I included the Prover.toml which came from the above failure - it's valid and should pass. To see the failure remove is_non_zero from the above code (in assert_split_transformed_value_arrays.nr), then run:

nargo execute --package private_kernel_tail_to_public

Add back the fix and run the same to see it passing.

[LeilaWang]

Thanks for tracking this down!

[asterite]

@MirandaWood Do you know if the bug still exists? When I follow the "Repro" steps, running nargo execute --package private_kernel_tail_to_public works fine for me. Could you try the repro steps on your machine to see if it fails?

[MirandaWood]

@MirandaWood Do you know if the bug still exists? When I follow the "Repro" steps, running nargo execute --package private_kernel_tail_to_public works fine for me. Could you try the repro steps on your machine to see if it fails?

Hi, I believe it does since we saw it today in another if statement (#12711). Which prover.toml did you use? It may have been updated since this PR to one that doesn't reach this code, or one that does not lead to num_non_revertibles = 0

edit: using the prover.toml on this PR fails on my side when removing the fix

[asterite]

@MirandaWood Thank you, that was it! I didn't realize Prover.toml might have been changed since this PR. Using the one in this PR I was able to reproduce the issue.