NEP-491: Non-refundable storage

README.md

@@ -30,6 +30,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement
 | [0399](https://github.com/near/NEPs/blob/master/neps/nep-0399.md) | Flat Storage                             | @Longarithm @mzhangmzz                      | Review |
 | [0448](https://github.com/near/NEPs/blob/master/neps/nep-0448.md) | Zero-balance Accounts                    | @bowenwang1996                              | Final  |
 | [0455](https://github.com/near/NEPs/blob/master/neps/nep-0455.md) | Parameter Compute Costs                  | @akashin @jakmeier                          | Final  |
+| [0491](https://github.com/near/NEPs/blob/master/neps/nep-0491.md) | Non-Refundable Storage Staking           | @jakmeier                                   | Review |
 | [0514](https://github.com/near/NEPs/blob/master/neps/nep-0514.md) | Fewer Block Producer Seats in `testnet`  | @nikurt                                     | Final  |
 
 

neps/nep-0491.md

@@ -0,0 +1,381 @@
+---
+NEP: 491
+Title: Non-Refundable Storage Staking
+Authors: Jakob Meier <jakob@near.org>
+Status: Draft
+DiscussionsTo: https://gov.near.org/t/proposal-locking-account-storage-refunds-to-avoid-faucet-draining-attacks/34155
+Type: Protocol Track
+Version: 1.0.0
+Created: 2023-07-24
+LastUpdated: 2023-07-26
+---
+
+
+## Summary
+
+Non-refundable storage allows to create accounts with arbitrary state for users,
+without being susceptible to refund abuse.
+
+This is done by tracking non-refundable balance in a separate field of the
+account. This balance is only useful for storage staking and otherwise can be
+considered burned.
+
+
+## Motivation
+
+Creating new accounts on chain costs a gas fee and a storage staking fee. The
+more state is added to the account, the higher the storage staking fees. When
+deploying a contract on the account, it can quickly go above 1 NEAR per account.
+
+Some business models are okay with paying that fee for users upfront, just to
+get them onboarded. However, if a business does that today, their users can
+delete their new accounts and spend the tokens intended for storage staking in
+other ways. Since this is free for the user, they are financially incentivized
+to repeat this action for as long as the business has funds left in the faucet.
+
+The protocol should allow to create accounts in a way that is not susceptible to
+such refund abuse. This would at least change the incentives such that creating
+fake users is no longer profitable.
+
+Non-refundable storage staking is a further improvement over
+[NEP-448](https://github.com/near/NEPs/pull/448) (Zero Balance Accounts) which
+addressed the same issue but is limited to 770 bytes per account. By lifting the
+limit, sponsored accounts can be used in combination with smart contracts.
+
+## Specification
+
+Users can opt-in to nonrefundable storage when creating new accounts. For that,
+we use the new action `ReserveStorage`.
+
+```rust
+pub enum Action {
+    ...
+    ReserveStorage(ReserveStorageAction),
+    ...
+}
+```
+
+To create a named account today, the typical pattern is a transaction with
+`CreateAccount`, `Transfer`, and `AddKey`. To make the funds nonrefundable, we
+can use action `ReserveStorage` like this:
+
+```json
+"Actions": {
+  "CreateAccount": {},
+  "ReserveStorage": { "deposit": "1000000000000000000000000" },
+  "AddKey": { "public_key": "...", "access_key": "..." }
+}
+```
+
+Adding a `Transfer` action allows the combination of nonrefundable balance and
+refundable balance. This allows the user to make calls where they need to attach
+balance, for example an FT transfer which requires 1 yocto NEAR.
+
+```json
+"Actions": {
+  "CreateAccount": {},
+  "ReserveStorage": { "deposit": "1000000000000000000000000" },
+  "Transfer": { "deposit": "100" },
+  "AddKey": { "public_key": "...", "access_key": "..." }
+}
+```
+
+To create implicit accounts, the current protocol requires a single `Transfer`
+action without further actions in the same transaction and this has not changed
+with this proposal:
+
+```json
+"Actions": {
+  "CreateAccount": {},
+  "ReserveStorage": { "deposit": "1000000000000000000000000" },
+  "Transfer": { "deposit": "0" },
+}
+```
+
+If a non-refundable transfer arrives at an account that already exists, it will
+fail and the funds are returned to the predecessor.
+
+Finally, when querying an account for its balance, there will be an additional
+field `nonrefundable` in the output. Wallets will need to decide how they want
+to show it. They could, for example, add a new field called "non-refundable
+storage credits".
+
+```js
+// Account near
+{
+  "amount": "68844924385676812880674962949",
+  "block_hash": "3d6SisRc5SuwrkJnLwQb3W5pWitZKCjGhiKZuc6tPpao",
+  "block_height": 97314513,
+  "code_hash": "Dmi6UTRYTT3eNirp8ndgDNh8kYk2T9SZ6PJZDUXB1VR3",
+  "locked": "0",
+  "storage_paid_at": 0,
+  "storage_usage": 2511772,
+  "formattedAmount": "68,844.924385676812880674962949",
+  // this is new
+  "nonrefundable": "0"
+}
+```
+
+
+## Reference Implementation
+
+On the protocol side, we need to add new action:
+
+```rust
+enum Action {
+  CreateAccount(CreateAccountAction), 
+  DeployContract(DeployContractAction),
+  FunctionCall(FunctionCallAction),
+  Transfer(TransferAction),
+  Stake(StakeAction),
+  AddKey(AddKeyAction),
+  DeleteKey(DeleteKeyAction),
+  DeleteAccount(DeleteAccountAction),
+  Delegate(super::delegate_action::SignedDelegateAction),
+  // this gets added in the end
+  ReserveStorage(ReserveStorageAction),
+}
+```
+
+and handle the new action in the `apply_action` call.
+
+Further, we have to update the account meta data representation in the state
+trie to track the non-refundable storage.
+
+```rust
+pub struct Account {
+    amount: Balance,
+    locked: Balance,
+    // this field is new
+    nonrefundable: Balance,
+    code_hash: CryptoHash,
+    storage_usage: StorageUsage,
+    // the account version will be increased from 1 to 2
+    version: AccountVersion,
+}
+```
+
+The field `nonrefundable` must be added to the normal `amount` and the `locked`
+balance calculate how much state the account is allowed to use. The new formula
+to check storage balance therefore becomes
+
+```rust
+amount + locked + nonrefundable >= storage_usage * storage_amount_per_byte
+```
+
+For old accounts that don't have the new field, the non-refundable balance is
+always zero. Adding non-refundable balance later is not allowed. If a transfer
+is made to an account that already existed before the receipt's actions are
+applied, execution must fail with
+`ActionErrorKind::OnlyReserveStorageOnAccountCreation{ account_id: AccountId }`.
+
+Conceptually, these are all changes on the protocol level. However,
+unfortunately, the account version field is not currently serialized, hence not
+included in the on-chain state.
+
+Therefore, as the last change necessary for this NEP, we also introduce a new
+serialization format for new accounts.
+
+```rust
+// new serialization format for `struct Account`
+
+// new: prefix with a sentinel value to detect V1 accounts, they will have
+//      a real balance here which is smaller than u128::MAX
+writer.serialize(u128::MAX)?;
+// new: include version number (u8) for accounts with version 2 or more
+writer.serialize(version)?;
+writer.serialize(amount)?;
+writer.serialize(locked)?;
+writer.serialize(code_hash)?;
+writer.serialize(storage_usage)?;
+// new: this is the field we added, the type is u128 like other balances
+writer.serialize(nonrefundable)?;
+```
+
+Note that we are not migrating old accounts. Accounts created as version 1 will
+remain at version 1.
+
+A proof of concept implementation for nearcore is available in this PR: 
+https://github.com/near/nearcore/pull/9346
+
+
+## Security Implications
+
+We were not able to come up with security relevant implications.
+
+## Alternatives
+
+There are small variations in the implementation, and then there are completely
+different ways to look at the problem. Let's start with the variations.
+
+### Variation: Allow adding nonrefundable balance to existing accounts
+
+Instead of failing when a non-refundable transfer arrives at an existing
+account, we could add the balance to the existing non-refundable balance. This
+would be more flexible to use. A business could easily add more funds for
+storage even after account creation.
+
+The problems are in the implementation details. It would allow to add
+non-refundable storage to existing accounts, which would require some form of
+migration of the all accounts in the state trie. This is impractical, as we have
+to iterate over all existing accounts and re-merklize. That's infeasible within
+a single block time and stopping the chain would be disruptive.
+
+We could maybe migrate lazily, i.e. read account version 1 and automatically
+convert it to version 2. However, that would break the assumption that every
+logical value in the merkle trie has a unique borsh representation, as there
+would be a account version 1 and a version 2 borsh serialization that both map
+to the same logical version 2 value. This could lead to different
+representations of the same chunk in memory, which might be used in attacks to
+force a double-sign by innocent validators.
+
+It is not 100% clear to me, the author, if this is a problem we could work
+around. However, the complications it would involve do not seem to be worth it,
+given that in the feature discussions nobody saw it as critical to add
+non-refundable balance to existing accounts.
+
+### Variation: Allow refunds to original sponsor
+
+Instead of complete non-refundability, the tokens reserved for storage staking
+could be returned to the original account that created the account when an
+account is deleted.
+
+The community discussions ended with the conclusion that this feature would
+probably not be used and we should not implement it until there is real demand
+for it.
+
+### Alternative: Don't use smart contracts on user accounts
+
+Instead of deploying contracts on the user account, one could build a similar
+solution that uses zero balance accounts and a single master contract that
+performs all smart contract functionality required. This master contract can
+implement the [Storage Management]
+(https://nomicon.io/Standards/StorageManagement) standard to limit storage usage
+per user.
+
+This solution is not as flexible. The master account cannot make cross-contract
+function calls with the user id as the predecessor.
+
+### Alternative: Move away from storage staking
+
+We could also abandon the concept of storage staking entirely. However, coming
+up with a scalable, sustainable solution that does not suffer from the same
+refund problems is hard.
+
+One proposed design is a combination of zero balance accounts and code sharing
+between contracts. Basically, if somehow the deployed code is stored in a way
+that does not require storage staking by the user themself, maybe the per-user
+state is small enough to fit in the 770 bytes limit of zero balance accounts.
+(Questionable for non-trivial use cases.)
+
+This alternative is much harder to design and implement. The proposal that has
+gotten the furthest so far is [Ephemeral
+Storage](https://github.com/near/NEPs/pull/485), which is pretty complicated and
+does not have community consensus yet. Nobody is currently working on moving it
+forward. While we could wait for that to eventually make progress, in the
+meantime, the community is held back in their innovation because of the refund
+problem.
+
+### Alternative: Using a proxy account
+
+As suggested by [@mfornet](https://github.com/near/NEPs/pull/491#discussion_r1349496234)
+another alternative is using a proxy account approach where the business creates
+an account with a deployed contract that has Regular (user has full access key) 
+and Restricted mode (user doesn't have full access key and cannot delete 
+account).
+
+In restricted mode, the user has a `FunctionCallKey` which allows the user to
+call methods of the contract that controls the `FullAccessKey` and allows the
+user some functionality but not all, e.g. not allowing account deletion. The
+user in restricted mode could also upgrade an account by sending the initial
+amount of NEAR deposited by the account creator and will attach a new
+`FullAccessKey`.
+
+The downside of this idea is additional complexity on the tooling side because
+actions like adding access keys to the account need to be converted to function
+calls instead of being direct actions. And the complexity on the business side
+is that it needs to include the proxy logic with their business logic in the
+same contract, increasing the complexity of development.
+
+## Future possibilities
+
+- We might want to add the possibility to make non-refundable balance transfers
+  from within a smart contract. This would require changes to the WASM smart
+  contract to host interface. Since removing anything from there is virtually
+  impossible, we shouldn't be too eager in adding it there but if there is
+  demand for it, we certainly can do it without much trouble.
+- We could later add the possibility to refund the non-refundable tokens to the
+  account who sent the tokens initially.
+- We could allow sending non-refundable balance to existing accounts.
+- If (cheap) code sharing between contracts is implemented in the future, this
+  proposal will most likely work well in combination with that. Per-user data
+  will still need to be paid for by the user, which could be sponsored as
+  non-refundable balance without running into refund abuse.
+
+
+## Consequences
+
+
+### Positive
+
+- Businesses can sponsor new user accounts without the user being able to steal
+  any tokens.
+
+### Neutral
+
+- Non-refundable tokens are removed from the circulating supply, i.e. burnt.
+
+### Negative
+
+- Understanding a user's balance become even more complicated than it already
+  is. Instead of only `amount` and `locked`, there will be a third component.
+- There is no incentive anymore to delete an account and its state when the
+  backing tokens are not refundable.
+
+
+### Backwards Compatibility
+
+We believe this can be implemented with full backwards compatibility.
+
+## Unresolved Issues (Optional)
+
+All of these issues already have a proposed solution above. But nevertheless,
+these points are likely to be challenged / discussed:
+
+- Should we allow adding non-refundable balance to existing accounts? (proposal:
+  no)
+- Should we allow adding more non-refundable balance after account creation?
+  (proposal: no)
+- Should this NEP include a host function to send non-refundable balance from
+  smart contracts? (proposal: no)
+- How should a wallet display non-refundable balances? (proposal: up to wallet
+  providers, probably a new separate field)
+
+## Changelog
+
+### 1.0.0 - Initial Version
+
+> Placeholder for the context about when and who approved this NEP version.
+
+#### Benefits
+
+> List of benefits filled by the Subject Matter Experts while reviewing this
+> version:
+
+- Benefit 1
+- Benefit 2
+
+#### Concerns
+
+> Template for Subject Matter Experts review for this version: Status: New |
+> Ongoing | Resolved
+
+|   # | Concern | Resolution | Status |
+| --: | :------ | :--------- | -----: |
+|   1 |         |            |        |
+|   2 |         |            |        |
+
+## Copyright
+
+Copyright and related rights waived via
+[CC0](https://creativecommons.org/publicdomain/zero/1.0/).