Contract storage size panic on u32 overflow

[gui1117]

Storage size is u32, and has value of all values size + storage_size_offset. If this exceed u32::max_value() then it currently panics.

Even if chain like Ethereum storage might never reach 4GB it might be the case for some peculiar chain using our framework. Thus I would go to make storage_size being u64.

This would imply some more complex conversion in rent computation but nothing that complicated.

[gavofyork]

storage size should remain u32; if anyone ever manages to store more than 4GB of data on-chain, and pays for it, then it's fine to just saturate the total at 2**32-1.

[gui1117]

ok, implementation speaking it might not be easier because currently we only decrease/increase storage size on removed/inserted value. Thus we need to keep track of the real storage size otherwise a contract could go to a storage size of u32::max*2 and then remove u32::max size and he would have storage_size=0 but real_storage_size=u32::max. or find another implementation

[athei]

ok, implementation speaking it might not be easier because currently we only decrease/increase storage size on removed/inserted value. Thus we need to keep track of the real storage size otherwise a contract could go to a storage size of u32::max*2 and then remove u32::max size and he would have storage_size=0 but real_storage_size=u32::max. or find another implementation

So switching from checked_add to saturating_add would make things worse? With the current code that panics on overflow we are in a situation where any extrinsic that increases the storage size above 4GB is simply invalid. This is usually bad because then no one pays for that invalid transaction. However, in order to make that happen the contract needs to pay a lot of rent.

That said, it might be worthwhile to switch from panic to a regular DispatchError. Given that we agree that we want to cap contracts at 4GB for now.