add bytes calculation

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
 }
 ```