Why is this true? It seems to significantly grow the programming complexity, as mentioned here:
I really think a good solution to this problem has to make the programming model much clearer. I don’t think “emitting separate contracts per contract for interacting as a contract, and then have to figure out how the contracts combine together in the permutation of cases of which contracts are down” is the clearest model.
I have an alternative proposal specified here: Ethereum 2.0 Data Model: Actors and Assets - #6 by fubuloubu
I think it makes the programming model clearer (per-user storage of assets) which the infinite mapping model typically aligns around in many cases. An addendum to that I just thought of now is deduct storage rent from your Ether holdings, which means your account can’t do anything if it’s unfunded. That’s a clear model with how actual rent works. And this also supports the “tip jar” that @MihailoBjelic mentioned, just add ETH to the contract!
I think this is a really interesting approach, because it makes rent a direct feature you have to plan for if you have custom logic that needs to be handled. It makes this complicated concept much easier to work with and plan for.
Whatever is planned, there would have to be a gradual introduction of these concepts. You could put legacy contracts on a different schedule for rent increases, putting them on a slower path towards what the general case would be, and then eventually making them more expensive in order to convince people to change to the new style. Dropping this all on Serenity doesn’t seem like the best way to have a smooth transition to highly-secure contracts, people need time to play with these concepts because they are quite complicated!