State object cleanup questions.

[bedeho]

Background

We are currently taking the following approach to incentivizing actors to remove stale objects from storage. We have a module specific account taking the role of a treasury which accumulates bounties submitted for state objects, which are then later released during a cleanup operation triggered by the owner. Importantly, we are also tracking the individual reward in each object, so we have

struct Thread {
...
    /// Pay off by deleting
    pub cleanup_pay_off: Balance,
}

and the amount required for the bounty is a runtime constant, e.g. type StartingCleanupPayOff: Get<Self::Balance>;.

Questions

1. The only reason to track individual cleanup_payoff: Balance, rather than just computing the payoff as a function of the size of thread (in so far as we even care about this, and not have a fixed payoff per thread), is because one anticipates that the StartingCleanupPayOff will vary over time, which requires runtime upgrades. Is this correct?
2. What if there is a need to increase the overall fee/weight rate of all extrinsics, for example because the fiat value of the token has depreciated, presumably through a runtime upgrade? This would leave lots of old cleanup_pay_off values which now cannot be economically recovered, because the tx fee of the recovery action costs more. Is this a big problem? Do we then have to do a migration where we adjust up all these values and credit the treasury?

[conectado]

1. We need to charge for both thread and post creation because of Pallets where there is no deposit charged for filling up the storage #2196 and No deposit is charged for creating forum posts and threads audits#5 but I don't see why we can't burn the post creator's or thread creator's tokens and then calculate the pay off once we delete the thread. This would mean that if there is a runtime-upgrade there could be more tokens burned or more minted.
2. I think this is a problem, taking into account that the fee/weight auto-adjust this probably will happen. And I think it can fill-up a big chunk of storage over time. So if we go with the approach of burning/minting tokens we could fix this by updating the initial thread and post deposit value and perhaps we could put those value in the storage to be updated through proposals. otherwise I think we need to do that migration to adjust the values.

[shamil-gadelshin]

If we implement any strategy that separates the initial thread creation cost from the future pay-off, we could incentivize the weird type of "forum thread" investing before the runtime upgrade when the runtime upgrade contains thread cost parameter adjustments. Could we solve the "thread cleanup pay-off inflation" problem using the thread moderation by a leader with its working group budget?

[conectado]

If we implement any strategy that separates the initial thread creation cost from the future pay-off, we could incentivize the weird type of "forum thread" investing before the runtime upgrade when the runtime upgrade contains thread cost parameter adjustments.

I talked it over with @bedeho, to fix this problem we will go with the following solution:

• Keep the pay off for thread deletion the accumulation of the post/threads deposits so that there is no incentive to create threads before a runtime-upgrade.
• If the deposit ever gets too small to prevent spam, a runtime-upgrade is needed to update the deposit amount(We could also move these constants to the storage to update through proposal).
• Accept that some threads might not be deleted by the thread author since the bounty for thread deletion might get too low compared to transaction fee. For this a moderator could delete the thread either through funding request or for their reputation.