I don’t think there’s a way to calculate the “real cost of storage”. If there were, I would have replied to the first post with a simple formula :). We come up with deposit rates based on a rough idea of “reasonable” and high enough to deter abuse.
Rob makes a good point: Lower deposits in the beginning are essentially a subsidy for early adopters. If the state grows too fast and requires an increase, it’s the late comers who pay the higher price.
I don’t think deposit updates need to be so frequent that they can’t be done via runtime upgrade. I would not try to constantly react to changing market conditions.
Now, the reason I think that an RFC would be useful here is to put all the arguments in one place. We can say here there are arguments under:
- Technical: We want to prevent state bloat, therefore using state should have a cost associated with it.
- Business: People want low costs associated with deploying their collections.
- Economic: We want lower barriers to entry, but also an incentive to “think twice” before deploying. As in, don’t bloat state for testing, use a testnet.
Of course any group will have different answers. An engineer/auditor will say, “make the deposit 1 million DOT”. An NFT creator will say, “make it 0”. (In a similar example, I’ve had validator providers ask me if we could “just remove slashing” from Polkadot because they don’t like the risk).
My guess is that in an RFC we would come to the conclusion to dramatically reduce these deposits because subsidizing growth now is worth it. We also have the advantage that if this becomes so popular, we can just shard the chain and make a new NFT chain to run in parallel. It’s worth an RFC because the discussion would serve as precedent when choosing other deposits and choosing when to change this deposit due to popularity (too much NFT state) or due to market conditions (the current deposit becomes unaffordable).