feat: running balance calculations for optimistic proposals

[bmzig]

We need to know the pending root bundle's running balance totals, which is only retrievable by recomputing the pending root bundle's pool rebalance root.

[nicholaspai]

One q

[nicholaspai]

Ok I think this should work... best way to test is to wait until a new root bundle is proposed, then run the proposer locally using the same bundle block ranges.

Then, delete the ExecutedRootBundle events in the HubPoolClient locally so the just-recently executed bundle doesn't look like a "validated root bundle" and I think the running balances should match.

WDYT of this testing plan? I could be wrong

[bmzig]

Ok I think this should work... best way to test is to wait until a new root bundle is proposed, then run the proposer locally using the same bundle block ranges.

Then, delete the ExecutedRootBundle events in the HubPoolClient locally so the just-recently executed bundle doesn't look like a "validated root bundle" and I think the running balances should match.

WDYT of this testing plan? I could be wrong

I think this works. I will try to get some comparisons here and then will bump package one last time.

[bmzig]

Tested this with the above suggestion. I specifically indexed this by this.proposedRootBundles - 2, forced entry into this branch, and then overwrote latestMainnetBlock here to a block behind the l1 pool rebalance leaf execution which preceded the bundle I was trying to match.

Under this setup, I have been able to reproduce identical bundles as the one actually proposed.

[nicholaspai]

nit: consider refactoring this constructing leaf section into shared function if its clean, but perhaps you've thought of this

[bmzig]

I thought the cleanest way would be to make _buildHistorical... and _buildOptimistic... return runningBalances, chainWithRefundsOnly, and realizedLpFees back to _buildPoolRebalanceRoot so that it can centralize the building there, but the issue I ran into was calling _buildHistoricalPoolRebalanceRoot in _buildOptimisticPoolRebalanceRoot since that function actually needs to have the tree/pool rebalance leaves. I think that means we would need this function to be called in both _buildOptimisticPoolRebalanceRoot and _buildHistoricalPoolRebalanceRoot, and the issue with that is we need to pass in everything constructPoolRebalanceLeaves needs to have, so it would really just add to the diff by a decent amount.