zero balance account NEP

neps/nep-0448.md

@@ -0,0 +1,129 @@
+---
+NEP: 448
+Title: Zero-balance Accounts
+Author: Bowen Wang <bowen@near.org>
+DiscussionsTo: https://github.com/nearprotocol/neps/pull/448
+Status: Draft
+Type: Protocol Track
+Created: 10-Jan-2023
+---
+
+## Summary
+
+A major blocker to a good new user onboarding experience is that users have to acquire NEAR tokens to pay for
+their account. With the implementation of [NEP-366](https://github.com/near/NEPs/pull/366), users don't necessarily have
+to first acquire NEAR tokens in order to pay transaction fees, but they still have to pay for the storage of their account.
+To address this problem, we propose allowing each account to have free storage for the account itself and up to four keys
+and account for the cost of storage in the gas cost of create account transaction. 
+
+## Motivation
+
+Ideally a new user should be able to onboard onto NEAR through any applications built on top of NEAR and do not have to
+understand that the application is running on top of blockchain. The ideal flow is as follows: a user hear about an interesting
+application from their friends or some forum and they decide to give it a try. The user opens the application in their
+browser and directly starts using it without worrying about registration. Under the hood, a keypair is generated for the
+user and the application creates an account for the user and pays for transaction fees through meta transactions. Later on,
+the user may find other applications that they are also interested in and give them a try as well. At some point, the user
+graduates from the onboarding experience by acquiring NEAR tokens either through earning or because they like some experience
+so much that they would like to pay for it explicitly. Overall we want to have two full access keys for recovery purposes
+and two function call access keys so that users can use two apps before graduating from the onboarding experience.
+
+## Rationale and alternatives
+
+There are a few alternative ideas:
+* Completely disregard storage staking and do not change the account creation cost. This makes the implementation even
+simpler. However, there may be a risk of spamming attack given that the cost of creating an account is around 0.2Tgas.
+In addition, with the current design, it is easy to further reduce the cost. Going the other way is more difficult.
+* Do not change how storage staking is calculated when converting to gas cost. This means that account creation cost would
+be around 60Tgas, which is both high in gas (meaning that the throughput is limited and more likely for some contract to break)
+and more costly for users (around 0.006N per account creation).
+
+## Specification
+
+There are two main changes to the protocol:
+* Account creation cost needs to be increased. For every account, at creation time, 770 bytes of storage are reserved
+for the account itself + four full access keys + two function call access keys. For function call access keys,
+the "free" ones cannot use `method_names` in order to minimize the storage requirement for an account.
+The number of bytes is calculated as follows:
+  - An account takes 100 bytes due to `storage_usage_config.num_bytes_account`
+  - A full access key takes 42 bytes and there is an additional 40 bytes required due to `storage_usage_config.num_extra_bytes_record`
+  - A function call access key takes 131 bytes and there is an additional 40 bytes required due to `storage_usage_config.num_extra_bytes_record`
+  - Therefore the total the number of bytes is `100 + (131 + 40) * 2 + (42 + 40) * 4 = 770`.
+
+  The cost of these bytes is paid through transaction fee. Note that there is already [discussion](https://github.com/near/NEPs/issues/415)
+around the storage cost of NEAR and whether it is reasonable. While this proposal does not attempt to change the entire
+storage staking mechanism, the cost of storage is reduced in 10x when converting to gas. A [discussion](https://gov.near.org/t/storage-staking-price/399)
+from a while ago mentioned this idea, and the concerns there were proven to be not real concerns. No one is deleting
+data from storage in practice and the storage staking mechanism does not really serve its purpose. That conversion means
+we increase the account creation cost to 7.7Tgas from 0.2Tgas
+* Storage staking check will not be applied if an account has <= 4 full access keys and <= 2 function call access keys 
+and does not have a contract deployed. If an account accrues more than full access keys or function call access keys,
+however, it must pay for the storage of everything including those 6 keys. This makes the implementation simpler and less error-prone.
+
+## Reference Implementation (Required for Protocol Working Group proposals, optional for other categories)
+
+Details of the changes described in the section above:
+* Change `create_account_cost` to
+```
+"create_account_cost": {
+  "send_sir": 3850000000000,
+  "send_not_sir": 3850000000000,
+  "execution": 3850000000000
+},
+```
+* Change the implementation of `get_insufficient_storage_stake` to check whether an account is zero balance account.
+Note that even though the intent, as described in the section above, is to limit the number of full access keys to 4
+and the number of function call access keys to 2, for the ease of implementation, it makes sense to limit the size of 
+`storage_usage` on an account to 770 bytes because `storage_usage` is already stored under `Account` and it does not
+require any additional storage reads. More specifically, the check looks roughly as follows:
+```rust
+/// Returns true if an account is a zero balance account
+fn check_for_zero_balance_account(account: &Account) -> bool {
+    account.storage_usage <= 770 // 4 full access keys and 2 function call access keys
+}
+```
+
+## Drawbacks (Optional)
+
+- Reduction of storage cost when converting the storage cost of zero balance accounts to gas cost may be a concern. But
+I argue that the current storage cost is too high. A calculation shows that the current storage cost is around 36,000 times
+higher than S3 storage cost. In addition, when a user accrues any contract data or has more than three keys on their account,
+they have to pay for the storage cost of everything combined. In that sense, a user would pay slightly more than what
+they pay today when their account is no longer a zero-balance account.
+
+## Unresolved Issues (Optional)
+
+## Future possibilities
+
+- We may change the number of keys allowed for zero-balance accounts in the future.
+- A more radical thought: we can separate out zero-balance accounts into its own trie and manage them separately. This
+may allow more customization on how we want zero-balance accounts to be treated.
+
+## Decision Context
+
+### 1.0.0 - Initial Version
+
+The initial version of NEP-448 was approved by Protocol Working Group members on February 9, 2023 ([meeting recording](https://youtu.be/ktgWXjNTU_A)).
+
+#### Benefits
+
+- Users can now onboard with having to acquire NEAR tokens
+- Together with [meta transactions](https://github.com/near/NEPs/pull/366), this allows a user to start interacting with an app on NEAR directly from their device without any additional steps
+- Solves the problem of meta transaction for implicit accounts
+
+#### Concerns
+
+| # | Concern | Resolution | Status |
+| - | - | - | - |
+| 1 | The number of full access keys allowed is too small | Could be done in a future iteration. | Resolved |
+| 2 | No incentive for people to remove zero balance account. | Very few people actually delete their account anyways. | Resolved |
+| 3 | UX of requiring balance after a user graduate from zero balance account to a regular account | The experience of graduating from zero balance account should be handled on the product side | Resolved |
+| 4 | Increase of account creation cost may break some existing contracts | A thorough investigation has been done and it turns out that we only need to change the contract that is deployed on `near` slightly | Resolved |
+| 5 | Account creation speed is slower due to increased cost | Unlikely to be a concern, especially given that the number of shards is expected to grow in the future | Resolved |
+| 6 | Cost of transfers to implicit account increases | Unlikely to break anything at the moment, and could be addressed in the future in a different NEP (see https://github.com/near/NEPs/issues/462 for more details) | Resolved |
+
+## Copyright
+
+[copyright]: #copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).