From 87f54d8bde5885ebaed26c368baf8419f1badeee Mon Sep 17 00:00:00 2001 From: Bowen Wang Date: Thu, 12 Jan 2023 14:51:42 -0800 Subject: [PATCH] add bytes calculation --- neps/nep-0448.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/neps/nep-0448.md b/neps/nep-0448.md index 165cc6cdd..95f035d55 100644 --- a/neps/nep-0448.md +++ b/neps/nep-0448.md @@ -13,7 +13,7 @@ Created: 10-Jan-2023 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 +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 @@ -25,7 +25,8 @@ browser and directly starts using it without worrying about registration. Under 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. +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 @@ -41,15 +42,22 @@ and more costly for users (around 0.006N per account creation). 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 + three 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) +for the account itself + two 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 126 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 + (126 + 40) * 2 + (42 + 40) * 2 = 596`. + + 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 +account accrues more than 3 keys, however, it must pay for the storage of everything including those 4 keys. This makes the implementation simpler and less error-prone. ## Reference Implementation (Required for Protocol Working Group proposals, optional for other categories) @@ -78,10 +86,7 @@ fn check_for_zero_balance_account(account_id: &AccountId, state_update: &TrieUpd return false; } let keys = get_all_access_keys(account_id, state_update); - if keys.len() > 3 { - return false; - } - true + num_full_access_key(keys) <= 2 && num_function_call_access_key <= 2 } ```