[NEP-491] Non-refundable storage

[jakmeier]

Context

NEP: near/NEPs#491

• Please note that action name was not agreed upon (see the end of the NEP discussion for more details). For now, I've used NonrefundableStorageTransfer name that was proposed in NEP-491: Non-refundable storage NEPs#491 (comment).

Goal

We aim to enable the sponsorship of accounts with arbitrary storage (for example, with a contract that exceeds the zero balance account limit). Currently, there is a financial incentive to deplete such a sponsor by deleting the account and then cashing in.

Summary

This PR introduces a non-refundable balance, which is a type of balance that can only be transferred to an account at the time of its creation. It is burned upon account deletion. This change eliminates the possibility of cashing out sponsored accounts.

Changes

• Add protocol_feature_nonrefundable_transfer_nep491 and change nightly protocol version.
• Introduce AccountVersion::V2 as the new default version.
• Extend Account with a nonrefundable field that will only be used by accounts V2 or higher.
• Introduce NonrefundableStorageTransfer action that behaves similar to Transfer but it modifies the nonrefundable instead of the amount account field. Both nonrefundable and amount are used to calculate the storage allowance.
• Introduce new error type NonRefundableBalanceToExistingAccount that it is raised on an attempt to make a non-refundable transfer outside of a transaction that creates an account.
• Use serialization sentinel (u128::MAX) as a first field during Borsh serialization in case of V2 accounts, to distinguish between V1 and V2 accounts. From V2, the version field is Borsh serialized and subsequent versions can use that field.
• Add custom Serde deserialization that uses V1 version in case the version field is missing. This is required when we parse the mainnet genesis file, so that the mainnet genesis hash does not change.
• Add non-refundable transfer tests.
• Add serde/borsh (de)serialization tests for all types of account.
• Update balance checker, other_burnt_amount is updated when deleting an account that had a non-refundable balance. Update related tests.
• Minor refactors.

Original description of a draft implementation by @jakmeier

The purpose of this reference implementation is to show the proposed protocol changes in practice.
It should be sufficient to convince the reader that all technical challenges have been identified and that there is a solution.
(If that's your goal, I recommend looking at only the changes of the first two commits, as the following commits contain only non-essential changes, such as fixing tests.)

However, this is not a full implementation. (edit: finishing as much as possible has started, some items are done)

• tests are not fixed
• boilerplate code changes are still left as todo!()
• (rosetta) rpc node code does not compile
• changes are not behind feature flags
• some refactoring would make sense
• need to implement more tests for the new feature
• some questions regarding desired behavior need to be decided in NEP discussion (What happens on delete? Is a top-up after creation possible?)
• naming should be decided as part of the NEP discussion => might require variable renaming
• implementation details for ActionView / AccountView need to be decided (with whom?)
• Implementation details around account parsing of old/new versions and its error handling needs to be agreed upon. The PR contains a suggestion.

[jakmeier]

This PR replaces #9346 from a branch in nearcore, allowing @jbajic and others to contribute as well.

[akhi3030]

@jbajic: I will close this. We can reopen if and when we decide to progress on this approach for the NEP.

[jbajic]

@jbajic: I will close this. We can reopen if and when we decide to progress on this approach for the NEP.

@akhi3030 I should have updated the PR, but I will be working on it, as was decided in the conversation that happened online. Posting the relevant comment here near/NEPs#491 (comment)

[staffik]

@nagisa Could you take a look at this as a code owner?

[nagisa]

I wouldn't say I'm deeply familiar with any of the codebase areas touched by this PR, so this review is only a best effort outcome…

[nagisa]

I do not see any further problems with the implementation code. One non-trivial operational point is that the coverage report is not favourable to this PR – it would be ideal to make sure the uncovered lines get tests added for them. I don't expect a full coverage, but I see entire match branches not being covered, which ain't great.

We're also waiting on a resolution of that Coinbase question.

[staffik]

@nagisa The Coinbase question has been resolved: #9600 (comment)