feat(flash-loan): add flash loan

[Rubilmax]

• Fixes Implement flashloans #16

[makcandrov]

I'd argue that #167 or #166 (from #120) already implements flashloans

I still think it is better to implement a separate flashLoan function. It is more intuitive, elegant, and gas-efficient (gas refunds are capped at 20%, so not really useful).

[Rubilmax]

I still think it is better to implement a separate flashLoan function. It is more intuitive, elegant, and gas-efficient (gas refunds are capped at 20%, so not really useful).

Just realized that anyway callbacks limit flash loans to a single market's liquidity, which is not enough. So there's no alternative to flash loans actually.

[makcandrov]

I thought so too, but in fact, you're not capped by the liquidity because you initially "virtually supplied" the liquidity to the market, so there won't be any liquidity issue when withdrawing

[Rubilmax]

Pushed a new, non-ERC3156-compliant version. I find it weird that we ignore the input of one of our expected integrator: Contango. Their usecase seems to be generalizable and cannot actually be solved using transient storage. Currently, they are required to use storage, which costs a lot compared to their suggested solution, that we refuse to implement for the sake of minimalism.

[makcandrov]

If we are not ERC3156 compliant (which I'm in favor of), I think it's better to change the flashloan function name and the callback name so that they are not misleading and no mistakes can be made by the integrators

[Rubilmax]

Pushed a new, non-ERC3156-compliant version. I find it weird that we ignore the input of one of our expected integrator: Contango. Their usecase seems to be generalizable and cannot actually be solved using transient storage. Currently, they are required to use storage, which costs a lot compared to their suggested solution, that we refuse to implement for the sake of minimalism.

Also note that if we apply this to flash loans, we should apply this to callbacks for #120 too (usecases are equivalent).

If we are not ERC3153 compliant (which I'm in favor of), I think it's better to change the flashloan function name and the callback name so that they are not misleading and no mistakes can be made by the integrators

Note that signatures are different! But I'm ok with both solution.

[makcandrov]

Also note that if we apply this to flash loans, we should apply this to callbacks for #120 too (usecases are equivalent).

I agree that we could do that, although I'm not sure if everyone is okay with returning an additional variable that is almost always empty.

Note that signatures are different! But I'm ok with both solution.

The signature is different, but the flashloan function's selector is still the same (the return type doesn't influence the selector).

[Rubilmax]

Just realized other protocols expose a function where you can input multiple tokens to flash loan across multiple assets at once. What do you think about this? Should we do the same? What are the downsides?

[MathisGD]

Im against at a first sight. It adds complexity to the function / interaction for unknown usecases, that you can quite easily cover by just calling an other flashloan in your callback function.

[Rubilmax]

Im against at a first sight. It adds complexity to the function / interaction for unknown usecases, that you can quite easily cover by just calling an other flashloan in your callback function.

I didn't get your point, can you elaborate/rephrase it pls? What other flashloan would you call in which callback function?

[MathisGD]

If you need to flashloan 2 tokens you can just call an other flashloan in your callback of the first one.

[pakim249CAL]

If you need to flashloan 2 tokens you can just call an other flashloan in your callback of the first one.

This would incur gas costs in multiple loops of calls between contracts though, which can add up quickly if there is a desire to flashloan many tokens.

[MathisGD]

A warm call is only 100. We don't even have one usecase in mind for flash loaning multiple tokens (right ?). I'm strongly against.