Make accrueInterests public ?

[MerlinEgalite]

Based on #3

[MathisGD]

It was not settled right ?

[MerlinEgalite]

Ok added the question label. I thought you were in favor.

[MathisGD]

I said that I don't see any significant drawbacks, but we still need to make sure that it's useful in some way.

[MerlinEgalite]

Ok mb then

[QGarchery]

Because it's already basically available by doing small transactions but in a clunky way, I'm in favor of adding it. The use case for it would be to compound interests more precisely, which may be interesting in some cases (but maybe less relevant with #135)

[Rubilmax]

Referencing my comment for completeness: #3 (comment). I'll suggest a PR for this ASAP.

[Rubilmax]

Making accrueInterests public is actually not enough to expose a getter because the EVM reverts as soon as a staticcall changes the state. So we need to isolate the logic to a dedicated getter instead.

[Rubilmax]

It's a bit of a hack, but we can also simply expose the accrueInterests as public without a view in the main contract, and integrators can simply use a view modifier in their own interfaces when calling it to be able to static call.

It seems this doesn't work:

And it seems it is equivalent to having integrators staticcall(accrueInterests)

[pakim249CAL]

Ah yeah I'll hide my older comment. Seems like I'm wrong. I'll do a little more research on it.

[MerlinEgalite]

Yeah @adhusson remembered me that a staticcal reverts and there's an OPCODE modifying the state. So it's unfortunately not possible. Maybe the solution you told me about @adhusson would work here btw (even though a bit overkill here I think)!

[adhusson]

I’m scarce on context but here is what comes to mind:

• The scheme I have in mind is about adding arbitrary « semantically view » functions to a contract (I want it to reduce codesize). TLDR is make a contract delegatecall arbitrary code even hostile code, then revert and return the returned value.
• These functions cannot be syntactically view, and if you force them to be view by breaking the type system then you will get compiled a staticcall which is bad as explained by you guys above.
• However you can make them view in the abi destined to clients, they will do an eth_call and everything will work.
• I like the idea by @Rubilmax in Balance getter discussion #3 to split accrual computation from accrual update. On the surface it seems like a fine solution that is also simple?

[MerlinEgalite]

Juste to recenter the debate on this issue because I think it was not clear enough. The question is more the following: do we want to let people accrue interest by triggering a function without needing to supply/borrow/... ?

It seems that #135 fixes the pb for market with few interactions though

[pakim249CAL]

I think an accrue interest function could be very valuable to integrators based on our own experiences with integrating with other lending protocols. Even with my PR, the interest accrued cannot be predetermined exactly without some sort of lens. I think integrators should be able to accrue interest (or have some sort of getter) to ease exact computations for them if they need it.

[Rubilmax]

Supporting @pakim249CAL's POV, but I'd be ok to extract this to a library which can be embedded into every integrator's bytecode or made external and deployed.
In order to be fully convinced I'm ok with this alternative solution (instead of exposing a getter for accrued interests), I'd have to check the bytecode size of such a library. Let's say I'd be ok if it weighs less than 0.6kb.

EDIT: I read too fast. I now understand that @pakim249CAL suggests to have accrueInterests public so integrators can accrue interests before querying totalSupply/totalBorrow and don't have to calculate interests upfront. I agree.

[MerlinEgalite]

I also agree that it would be useful but I'm less convinced about the need of a getter now.

[Rubilmax]

I also agree that it would be useful but I'm less convinced about the need of a getter now.

So you essentially support #147 right? And we'd suggest integrators that don't want to trigger the public accrueInterests to use a library we develop, mimicking the interests accrual and fee calculation?

EDIT: I'd like to quantify the gas cost of accrueInterests and associated calculation in order to make a choice.

[Rubilmax]

This PR introduced it: #183