nep-0448.md

NEP	Title	Author	Status	DiscussionsTo	Type	Created
448	Zero-balance Accounts	Bowen Wang <[email protected]>	Final	#448	Protocol Track	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, 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 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 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:

/// 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).

Benefits

• Users can now onboard with having to acquire NEAR tokens
• Together with meta transactions, 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 #462 for more details)	Resolved

Copyright

Copyright and related rights waived via CC0.