Gas reductions + AaveV2

[alsco77]

Description

1. Major gas reductions in mUSD by adding a 'cache' as described in MIP-3
2. Modifying interest collection mechanism to reduce SAVE deposit gas costs as described in MIP-4
3. Adding a PlatformIntegration for Aave V2 and the ability to move assets between Integrations

Affected files:

• Masset.sol: Major changes to depositing and withdrawing tokens (1) and tracking fee collection (2)
• BasketManager.sol: Minor changes to accomodate (1) and (3), also ability to collect system revenue to recipient (to support buy and make)
• AaveIntegration.sol, CompoundIntegration.sol: Major changes to accommodate new cache functionality (1) and maintain backwards compatibility
• SavingsManager.sol: Extension of current streaming functionality to accomodate (2)

New files:

• AaveV2Integration.sol: New contract

Minor changes:

• Changed default swapFee and redemptionFee from 40bps and 0bps to 6bps and 3bps respectively, as this is what is currently active on the mainnet mUSD contract. Note these changes don't have any knock on effect to mainnet and are used to simulate live environment as accurately as possible
• Lowered minimum savingsRate from 90% to 70%. Having a savingsRate of 70% would mean that 70% of system revenue is sent to SAVE and the other 30 is redistributed to a specified address. This is now more in line with general standards

Upgrade plan

Integration files are all backwards compatible, as is the BasketManager and SavingsManager. Therefore it would be possible to upgrade all these contracts without completing (1), (2) or (3). The below plan iteratively moves towards full completion.

1. Upgrade AaveIntegration, CompoundIntegration and BasketManager. Deploy AaveV2Integration. Complete (3) - migration of funds from AaveIntegration to AaveV2Integration
2. Upgrade SavingsManager (first, ensure that there is no residual mUSD from the Liquidator stream here)
3. Upgrade Masset and set cache size to finalise (1) and (2)

Low level

• Resolve remaining TODO's (removing console logs & review withdrawRaw)
  • Account for AAVE yield farming distribution?
• Deploy all contracts
• Propose upgrades
• Accept and complete step 1
• Accept and complete step 2
• Accept and complete step 3

Implementation details

1 - Cache

Details in MIP-3.

There are a number of concerns in accounting for tokens with transfer fees enabled. If we were to use the cache with these assets then it may be possible to churn funds at both a cost to the attacker and to the system. It is highly unlikely for this to happen, but the require(transferred == _quantity, "Asset not fully transferred"); in _depositTokens should protect against this churn, and also ensure that when we deposit into the cache, we are minting the correct amount of mAsset.

Some properties:

• if a given bAsset has txFees enabled (e.g. USDT turns on), then there should be 0 in the cache

2 - Swap fee accrual and interest collection batching

Details in MIP-4.

Adds a new surplus variable to the Masset.sol. This always remains at 1 base unit or higher to limit the cost to Swap/Redeem.
Note: the fees do not get minted until collected by the SAVE contract. Technically speaking, the sum of the vaultBalances should equal totalSupply + surplus.. so with that being the case, this is what is sent to the ForgeValidator to use in weight checking.

3 - Aave V2 and migration

Aave are releasing V2. Instead of upgrading the existing migration and then doing some sort of migration script, it's much less error prone to simply create a second platform integration contract and move the funds about.

Upgrades the Aave Integration to accommodate Aave v2 - docs here.

V2 Spec

V1 -> V2 changes:

• New LendingPoolAddressesProvider that gives out all different module addresses
• LendingPool.zip interface changes: deposit adds an _onBehalfOf arg
• aToken addresses change
• LendingPoolCore (ILendingPoolAddressesProvider(platformAddress).getLendingPoolCore();) is no longer the contract to approve - now simply LendingPool
• Redeem and Withdraw via LendingPool, not aToken

Assumptions:

• The AToken interface will stay the same
• The AToken still passively increases in balance
• The decimals on AToken will remain the same
• The referral code will stay the same