this is a pretty strong and debatable opinion, to be honest. Personally, i see the value of upgradeability and you raise fair points (although these points are becoming less and less relevant as the technology matures - they were much stronger 3/4 years ago, things are settling much quicker today). I also think that immutability CAN and SHOULD be aimed for, if the technology allows for it. There are amazing examples of protocols that have been immutable since the beginning of times, uniswap is one (and while V1/V2 are very simple from a design standpoint, V3/V4 are rather complex yet they are immutable and operate flawlessly). Would you call the uniswap labs team irresponsible? I don’t think that’s fair to them, they are amazing at what they do. While Aave is a different beast in general, and some Aave competitors have attempted the fully immutable route (including configuration) with mild success, i think an approach with immutable contracts and mutable configuration would strike the right balance, if done properly. Aave V4 has been designed with that in mind, being much smaller and easier to audit and yet packing more features than V3.
Anyway this is a bit off topic so i will not pollute the thread, but this is definitely a discussion the DAO needs to have, because imo seeing immutability as a bug and not a feature of blockchain development can be detrimental in the long run.
I don’t think these two points are even debatable, of course everyone here including me and others raising concern trust @bgdlabs and the proposed features sound definitely reasonable. Problem here is that even if i fully trust your development skills and security procedures, i am also realist and i know anyone can make mistakes, including me and you. Or maybe you can guarantee, with 100% certainty and past any shade of doubt, that it cannot happen and there will never be a mistake ever? If you can, hats off to you. Also, to your point “upgrades have been flawless until now” which is undeniably true, it’s also true that past performance is never guarantee of future results.
On the second point my concerns are
- how big is the impact on the codebase?
- Even if the features are good, and the risk is small, are they worth the even one in a hundred thousands chance of introducing a regression and losing 30b?
I can’t evaluate 1. at the moment, and the 2. quite frankly, to me feels like a no. Hence my doubt of being fully supportive of this upgrade.
Last thing on the broader topic of upgrades, i think i raised privately with @eboado already - the approach of upgrading all the markets at once without giving a production testrun on smaller ones always felt a bit far fetched. I think it would be safer for everyone if at least a subset of smaller, lower tvl markets were upgraded first and left in production for a few weeks before upgrading the biggest ones, in order to have slightly more guarantees that no regressions were introduced. If this doesn’t change i won’t be supportive of future upgrades, because i think it’s a small change in the deployment procedure that brings great additional security guarantees and i don’t see why it shouldnt be adopted.