sameh-farouk
commented
1 year ago I would like to share my opinion on how this pallet stored data on chain. First of all, I think the basic rule for blockchain runtime storage is to keep the data items as few and as small as possible. Storing arbitrary data on blockchain seems unnecessary, since it has no function in the runtime. It would be better to store this data somewhere else and remove this pallet. But if you decide to keep this pallet, here is my two cents:
Higher one-time fees are not enough to motivate users to cleanup unused storage items later.
so Besides what Dylan said, I recommend limiting the storage for each account, so that no one can have too many names/keys (restrict the number of key-value pair per account).
Moreover, I suggest looking into one of these two common methods to ensure economic security, storage deposit and storage rent:
- Storage deposit: ask the user to pay a deposit (some fees that can be refunded later) when they use storage. the deposit should scale with the size of the storage items – the more bytes are stored persistently, the higher the deposit. If they free up storage later, they can get their deposit back. This way, users have an incentive to clean up their data when they don’t need it anymore.
- Storage rent: this might sound complicated, but sometime this maybe needed to ensure that old data is removed over time. The rent is based on the size of the data and deducted from the user’s account balance periodically. If the user runs out of balance, the data can be evicted.
This is not only relevant to this pallet, but to all extrinsics that allow users to write to persistent storage. Users should be encouraged to clear up storage by paying a sufficient storage deposit. Otherwise, this could pose a security risk.
Currently the weight is set to take into a account the cost of writing one entry to the DB. I think the better thing to do here is to scale the weight based on the size of the data stored. This will also make sure the fee is higher when the stored data size is high.