diff --git a/neps/nep-0448.md b/neps/nep-0448.md new file mode 100644 index 000000000..6ecf862b5 --- /dev/null +++ b/neps/nep-0448.md @@ -0,0 +1,129 @@ +--- +NEP: 448 +Title: Zero-balance Accounts +Author: Bowen Wang +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/).