Rethink storage management

[bowenwang1996]

Currently NEAR uses storage staking, which means that an account needs to have 10^19 yoctoNEAR for every byte stored in the account state. However, on the transaction level, there is no way to attach deposit for storage specifically, which means that, unlike gas, storage needs to be payed by contracts. As a result, to avoid spamming attacks, contracts need to manage their storage by asking users to attach deposit to pay for the storage they occupy with their transactions. This is why we need to have the storage management standard. However, even with the existence of this standard, multi-contract interactions are still cumbersome, especially when we need to handle promise failures and how to return the deposit that is used to pay for storage.

It seems to me that this issue can be addressed on the protocol level, without changing the execution model (sync execution would also address it, but that is a much larger discussion). Some ideas that we have brainstormed so far:

• Merge storage cost into gas. This means that instead of staking tokens, we simply burn tokens. We also do it in such a way that only writes of new data are charged and overwrites of existing data does not incur this charge. If NEAR usage is going to be similar to that of Ethereum, then most writes will be overwrites rather than writes for new data and therefore the amortized cost of a transaction should not increase significantly. In addition, assuming that our gas price is 10^8 yotcoNEAR most of the time, writing 32 bytes of new data would cost an additional 3Tgas, which does not seem very bad.
• Keep storage staking but allow transactions to attach storage deposit which pays specifically for storage. Storage deposit will be in NEAR and it will be refunded similar to how gas is refunded. This way transaction costs will remain the same, but it may create additional cognitive load for developers and users.

[oysterpack]

Burning NEAR for storage allocation provides zero incentive to clean up storage. We shouldn't copy flaws and mistakes that were made on Ethereum and bring them over to NEAR - we need to learn from their mistakes and do better.

NEAR's storage staking is a superior model to Ethereum. Option #2 would solve the cross-contract issues due to NEAR's async nature. If you understand storage staking, then there is no additional cognitive load. In fact, I would say that adding explicit support for storage deposit that is managed at the protocol level eases cognitive load and makes it clear. It brings to attention the fact that storage is a resource that is not free and must be managed properly and efficiently.

[bowenwang1996]

Another idea came up during a discussion today: we change gas to an internal concept and function call transactions will attach NEAR rather than gas. The attached tokens will be used to pay for both gas and storage. In contracts, developers will specify, for each cross contract call, the amount of NEAR to attach rather than the amount of gas and gas will be purchased at the price of the block where the transaction or receipt is executed. The major issue with this approach is that it further breaks composability because now there is no guarantee that callbacks can be successfully executed because it depends on the gas price. If callbacks cannot be executed, promise results cannot be handled and cross contract calls will be completely broken. It also seems that unless we switch to synchronous execution, there is not a good solution to this issue without developers having to think about gas one way or another.

@ilblackdragon @SkidanovAlex @evgenykuzyakov

[MaksymZavershynskyi]

Let's close the discussion here and move it to: https://gov.near.org/t/attaching-near-instead-of-gas-to-transactions/1160