StrategyBase - Inflation Attack Prevention Can Lead to Stuck Funds
As a defense against what has come to be known as inflation or donation attack in the context of ERC-4626, the `StrategyBase` contract - from which concrete strategy implementations are supposed to inherit - enforces that the amount of shares in existence for a particular strategy is always either 0 or at least a certain minimum amount that is set to 10^9. This mitigates inflation attacks, which require a small total supply of shares to be effective.\\n```\\nuint256 updatedTotalShares = totalShares + newShares;\\nrequire(updatedTotalShares >= MIN\\_NONZERO\\_TOTAL\\_SHARES,\\n    "StrategyBase.deposit: updated totalShares amount would be nonzero but below MIN\\_NONZERO\\_TOTAL\\_SHARES");\\n```\\n\\n```\\n// Calculate the value that `totalShares` will decrease to as a result of the withdrawal\\nuint256 updatedTotalShares = priorTotalShares - amountShares;\\n// check to avoid edge case where share rate can be massively inflated as a 'griefing' sort of attack\\nrequire(updatedTotalShares >= MIN\\_NONZERO\\_TOTAL\\_SHARES || updatedTotalShares == 0,\\n    "StrategyBase.withdraw: updated totalShares amount would be nonzero but below MIN\\_NONZERO\\_TOTAL\\_SHARES");\\n```\\n\\nThis particular approach has the downside that, in the worst case, a user may be unable to withdraw the underlying asset for up to 10^9 - 1 shares. While the extreme circumstances under which this can happen might be unlikely to occur in a realistic setting and, in many cases, the value of 10^9 - 1 shares may be negligible, this is not ideal.
It isn't easy to give a good general recommendation. None of the suggested mitigations are without a downside, and what's the best choice may also depend on the specific situation. We do, however, feel that alternative approaches that can't lead to stuck funds might be worth considering, especially for a default implementation.\\nOne option is internal accounting, i.e., the strategy keeps track of the number of underlying tokens it owns. It uses this number for conversion rate calculation instead of its balance in the token contract. This avoids the donation attack because sending tokens directly to the strategy will not affect the conversion rate. Moreover, this technique helps prevent reentrancy issues when the EigenLayer state is out of sync with the token contract's state. The downside is higher gas costs and that donating by just sending tokens to the contract is impossible; more specifically, if it happens accidentally, the funds are lost unless there's some special mechanism to recover them.\\nAn alternative approach with virtual shares and assets is presented here, and the document lists pointers to more discussions and proposed solutions.
```\\nuint256 updatedTotalShares = totalShares + newShares;\\nrequire(updatedTotalShares >= MIN\\_NONZERO\\_TOTAL\\_SHARES,\\n    "StrategyBase.deposit: updated totalShares amount would be nonzero but below MIN\\_NONZERO\\_TOTAL\\_SHARES");\\n```\\n