Extreme do/undo amounts tests

[elshan-eth]

Description

This test checks that the logic is not broken when do/undo tests with super large amounts.

Type of change

• Bug fix
• New feature
• Breaking change
• Dependency changes
• Code refactor / cleanup
• Optimization: [ ] gas / [ ] bytecode
• Documentation or wording changes
• Other

Checklist:

• The diff is legible and has no extraneous changes
• Complex code has been commented, including external interfaces
• Tests have 100% code coverage
• The base branch is either main, or there's a description of how to merge

Issue Resolution

Closes #359

[jubeira]

Good start; thanks for pushing this @elshan-eth !

I'd suggest some changes though. This test is more about pushing things to the edge attempting to break something in the process.

It is true that in testing environments we can just mint more initial funds, but in practice you can also trigger huge swaps by adding liquidity, using BPT in a swap, and then try to revert the trade. The steps would be something like this:

• Add huge liquidity amounts to pool A, get BPT A
• Swap BPT A for another token in composable pool B (in this test, that'd be WETH)
• Then, try to undo: swap WETH for BPT out, and exit

The attack vector here would be trying to exploit uncapped swap sizes back and forth in pool B. The concern is that you don't even need real reserves or an external flashloan, since calling addLiquidity is enough to get you BPT even without paying your debts. But to do this, you need to call the vault directly; that's not something you can achieve with the standard router.

The expectation is that either:

• pools will do their job, and doing / undoing big trades will just not be profitable. More or less what E2E swap test (Do/Undo ExactIn and ExactOut) #801 attempts to prove, but that PR is not focused on particularly large trades.
• pools will revert if they can't handle big trades

Pool B in this test can also be weighted or stable (or any other potential pool type). Ideally we'd test this against real pool types, not just mocks.

[EndymionJkb]

First pass, as it's still a draft (has debug code, etc.) I'm getting a test failure (see below). Numerical examples would help with understanding the intent.

[FAIL. Reason: Total amount out should be less than amount in: 153127065114322308282125714582882500795 >= 153127065114322308075208245550570587690; counterexample: calldata=0x25735054000000000000000000000000000000000000000000000000000000000000583a00000000000000000000000000000000000000000000000000000000000044d4 args=[[22586 [2.258e4], 17620 [1.762e4]]]] testAddUnbalancedAndRemoveLiquidityProportional_Fuzz(uint256[2]) (runs: 3, μ: 424959, ~: 425202)

[jubeira]

Thanks for pushing this @elshan-eth ! First pass done.

Overall it looks good. I have two general comments:

• Later on it'd be good to have a test that checks all of this against different pool types with different configurations. The base vault test architecture creates a single pool and runs the test, but that's not very representative. We can do that in a later stage.
• I think the assertion for _testAddUnbalancedAndRemoveLiquidityProportional is not strong enough to ensure that everything is OK. Let's leave a comment for now; we can check invariants in a follow-up.

Other than that, just minor suggestions and comment requests. Great job!

[EndymionJkb]

I'm no longer getting any test failures.

[jubeira]

Let's solve merge conflicts and proceed with this one; this is a good base that I'd like to extend a bit in a few cases.