Decide on interest rates being in library or contract (for V3)

[pakim249CAL]

I created this topic to discuss the two potential solutions we have for interest rate models that I think is unresolved.

1. Use a library to do the interest rate models.
2. Put the interest rate models into the contracts themselves and have external getters.

[pakim249CAL]

I present the arguments for both solutions as I understand them.

First we can establish some things that we agree on how things should be implemented.

1. There should be minimal code duplication.
2. There should be sufficient getters to ease integrations.

For using libraries:

• Libraries are the standard way to share functionality across contracts. Librarifying the interest rate model allows us and integrators to use functions in the library without having to inherit a contract.
• Libraries are a natural fit for managing small components of code.

For keeping the logic in the contracts (Please add to this if I'm not getting all the arguments) :

• This is simpler to review because there are less jumps in code.
• No need to update multiple contracts.

My personal arguments:

It is much more natural in a library to componentize small calculations and procedures. This would improve testing, as each component can be tested much more thoroughly rather than our current paradigm which I would argue is mostly integration testing. Integration testing is important, but it is not sufficient.

Also, using libraries does not eliminate the possibility to have only one contract to update. Even if we don't plan on sharing the functionality between contracts, I still believe in using libraries for the reasons listed above. It allows us to completely separate the logic of the interest rates from any side effects, and is therefore much more ideal to develop and test in this paradigm. We use this principle with the data structures, so I'm not entirely sure why there is skepticism to do this with interest rates, as it seems clear to me that interest rates are a concept that can be separated from the rest of the logic.

[MerlinEgalite]

I think the last paragraph is a good point.

[QGarchery]

We use this principle with the data structures, so I'm not entirely sure why there is skepticism to do this with interest rates

For the reasons you mentioned: no need to update contracts twice so we are sure they are in sync, and readability (even though I agree that this is debatable). Libraries make it easy to introduce bytecode duplication, and for me the arguments "standard way" and "natural fit" are a bit weak. For the data-structure it makes sense, because you want to componentize: the reader does not need to know how Morpho works to understand the heap library. For interest rates I'm less convinced: you would have to deeply understand how Morpho works (index cursor, reserve factor, delta) to understand the library. Plus we can already separate the code into another file as it is done right now

[Rubilmax]

If I'm not mistaken then, writing the logic into a library, used inside a single contract, exposed by public functions, is a middleground?

[QGarchery]

This is a central point in the discussion for me. I honestly don't see the benefits of a library in this case, one internal function could be tested just as easily without requiring to jump to another file.

[Rubilmax]

Here is a PR illustrating this: #1584

There 2 things to take away:

1. As I imagined it, we don't want to expose rates from the InterestRatesManager. so I designed it this way: keep everything related to rates/indexes inside InterestRatesModel; make InterestRatesManager depend on InterestRatesModel to expose indexes; make IndexesLens no longer depend on InterestRatesModel, but rather call InterestRatesManager to get indexes; keep RatesLens depending on InterestRatesModel, because rates calculations are not exposed by InterestRatesManager (but should still be not far from indexes calculations, because they are very very similar - they rely on the same concept)
2. Something that is obvious now but that I was not aware of: if Morpho is supposed to delegatecall the InterestRatesManager, we cannot rely on the Lens calling it to expose the indexes (because the InterestRatesManager is stateless). So the InterestRatesManager must either be stateful, or be a library-like contract, exposing pure functions...

[MerlinEgalite]

Do we agree that the Lens calling the RIM directly does not work?

Moving the state to the IRM works but would cost more gas though..

[Rubilmax]

With the current state of the code, agreed
The POC I showcase was aiming to illustrate my first point (1), but I accidentally faced the second point (2) - because I didn't think about it at first