zero balance account NEP

neps/nep-9999.md

@@ -0,0 +1,92 @@
+---
+NEP: 0
+Title: Zero-balance Accounts
+Author: Bowen Wang <bowen@near.org>
+DiscussionsTo: https://github.com/nearprotocol/neps/pull/0000
+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 three 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.
+
+## 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, 600 bytes of storage are reserved
+for the account itself + five keys. For function call access keys, the "free" ones cannot use `method_names` in order to
+reserve space. 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 6Tgas from 0.2Tgas
+* Storage staking check will not be applied if an account has <= 3 keys and does not have a contract deployed. If an
+account accrues more than 3 keys, however, it must pay for the storage of everything including those 3 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": 3000000000000,
+  "send_not_sir": 3000000000000,
+  "execution": 3000000000000
+},
+```
+* Change the implementation of `get_insufficient_storage_stake` to take into account the number of keys an account has
+and whether it already has a contract deployed.
+
+## 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)
+
+- We need to better understand the implication of increasing account creation cost. We should check whether any contract
+on mainnet would break because of this.
+
+## 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.
+
+## Copyright
+
+[copyright]: #copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).