feat: compute account delta commitment before fee

[PhilippGackstatter]

Computes the account delta commitment before the fee, following the motivation from #1698 and builds on top of that PR.

Also updates the bench-tx, but I haven't looked into which changes went into this since last time.

part of #1688

[PhilippGackstatter]

(Force-pushed to rebase after merging the base PR).

[PhilippGackstatter]

As mentioned in #1698, in a follow-up PR, I would add caching to account::compute_current_storage_commitment. That way, we can pre-compute the storage commitmen before compute_fee is called, and when we call it again as part of account::compute_current_commitment (to compute the final account commitment) we are guaranteed to hit the cached value because storage doesn't change as part of the fee code. That way, the call to account::compute_current_commitment should always take a constant number of cycles. Then, overall, all procedures that run after compute_fee should take a constant number of cycles. I think we can then hardcode that number in epilogue.masm and assert in tests that accounts with different number of storage slots (and different vault sizes for good measure) take the same number of cycles after compute_fee. If we change anything about the epilogue, this should notify us of this change and we can update the hardcoded number.

That should be true, except we're also calling account::remove_asset_from_vault... Because it tracks the asset being removed as part of the delta, it calls into the link_map, which will take a different number of cycles depending on what the map layout looks like, which we could technically predict, but is unnecessary. Because the account delta in the tx kernel doesn't commit to the removed fee asset anyway (what is done in this PR), I think we can avoid this by not using account::remove_asset_from_vault and instead calling asset_vault::remove_asset directly with memory::get_acct_vault_root_ptr. That results in the same outcome, except it doesn't track the fee asset in the delta, which is not actually committed to anyway and is therefore a useless operation. As a bonus, this saves 750 cycles without loosing any functionality. So this is a bit more manual, but that should then actually make all operations after compute_fee take a constant number of cycles.

[mmagician]

The code looks good - that said, I'm not entirely convinced about the approach, specifically offloading the delta manipulations to the host. It does break some assumptions, like the kernel no longer outputs the true commitment?

I've suggested another approach in #1688 (comment). I'm not yet sure whether that proposed approach would even work, and if it would, if it'd be better, as I'm definitely less familiar with the internals of the kernel.

[PhilippGackstatter]

Merged in latest next and resolved conflicts, so this should be ready for another review.

[bobbinth]

Looks good! Thank you! I left some more comments inline.

[bobbinth]

Looks good! Thank you!