zero balance account NEP

[bowenwang1996]

NEP for #415. Implementation can be found in near/nearcore#8378

[render]

Your Render PR Server URL is https://nomicon-pr-448.onrender.com.

Follow its progress at https://dashboard.render.com/static/srv-cev4gip4reber7qq1lhg.

[bowenwang1996]

@frol @ori-near what are the next steps for this NEP?

[ori-near]

Hi @bowenwang1996 – thank you for starting this proposal. If you believe this NEP is ready for review, please turn the PR into "Ready for review" state and ping the @near/nep-moderators. Once you do that, the moderators will check that the NEP meets all the requirements and will then request the Protocol Working Group to assign 2 technical reviewers.

[ori-near]

Thank you @bowenwang1996 for submitting this NEP.

As a moderator, I reviewed this NEP and it meets the proposed template guidelines. I am moving this NEP to the REVIEW stage and would like to ask the @near/wg-protocol working group members to assign 2 Technical Reviewers to complete a technical review (see expectations). If you want to assign yourself, please mention that you are acting as the Technical Reviewers.

Please find some guidelines below for completing the technical review.

Technical Review Guidelines

• First, review the proposal within one week. If you have any suggestions that could be fixed, leave them as comments to the author. It may take a couple of iterations to resolve any open comments.
• Second, once all the suggestions are addressed, produce:
  • A recommendation for the working group if the NEP is ready for voting (it could be approving or rejecting recommendation)
  • A summary of benefits (example)
  • A summary of concerns and blockers that were identified on the way and their status (some will be resolved, others dismissed, etc) (example)

Please tag the @near/nep-moderators once you are done, so we can move this NEP to the voting stage. Thanks again.

[mfornet]

As a working group member, I'd like to nominate @mm-near and @DavidM-D (because his team is working on the onboarding experience) as Subject Matter Experts to review this NEP.

[ori-near]

Hi @DavidM-D and @mm-near! Thank you for agreeing to review this NEP. Per the NEP workflow, the expectation is for you to complete the review within one week (Tuesday, January 31). Please find additional guidelines below.

Technical Review Guidelines

• First, review the proposal. If you have any suggestions that could be fixed, leave them as comments to the author. It may take a couple of iterations to resolve any open comments.
• Second, once all the suggestions are addressed, produce:
  • A recommendation for the working group if the NEP is ready for voting (it could be approving or rejecting recommendation)
  • A summary of benefits
  • A summary of concerns and blockers that were identified on the way and their status (some will be resolved, others dismissed, etc)

## Example

### Recommendation
- Add recommendation

### Benefits

- Benefit
- Benefit

### Concerns

| # | Concern | Resolution | Status |
| - | - | - | - |   
| 1 | Concern | Resolution | Status |
| 2 | Concern | Resolution | Status |

Please tag the @near/nep-moderators once you are done, so we can move this NEP to the voting stage. Thanks again.

[frol]

As the moderator, I would like to thank the author @bowenwang1996 for submitting this NEP extension, and @mm-near @DavidM-D @jakmeier and @near/wg-protocol work group members for your review. Based on the voting indications above, and support from @bowenwang1996 it seems like this proposal is close to a decision. We are therefore scheduling the third Protocol Work Group meeting next week, where this NEP can enter the final voting stage. Anyone can discuss the technical details by adding your comments to this discussion. And join the call to learn about the final decision and how to get more involved.

Meeting Info
📅 Date: Thursday, Feb 9, 4 PM UTC
✏️ Register

[mfornet]

As a working group member, I lean towards approving this proposal.

[k3y0k3y]

I am in support of this proposal. Agree with the feedback that a UI design to indicate to a user when they are reaching key-limit and need NEAR to continue is needed. Also agree with the feedback that in documentation of using this service there should be clear indication to use it in limited use cases where meta-tx can cover the costs or show a clear on-ramp for earning NEAR.

[bowenwang1996]

Responding to a few concerns mentioned by various people:

• The number of access keys allowed is too small. @DavidM-D suggested having four full access keys instead of 2. This is actually something we could consider changing, as adding one more access key only adds 82 bytes to storage. @jakmeier do you know how much more can we increase account creation cost before something else breaks?
• No incentive for people to delete zero balance accounts. In general we observed very little deletion of data, let alone accounts. It doesn't appear that people are really incentivized to delete their account even with storage staking.
• The experience of "graduating" from a zero balance account is suboptimal as a user suddenly have to pay for the storage of all their keys. I'd argue that here the impact on UX is quite minimal since in our onboarding experience, a user graduates from a zero balance account either because they've earned NEAR, or because they decide to fund their account. In either case, paying for an additional <1000 bytes worth of storage (0.01N) doesn't seem to be too much of a problem.
• Increase of account creation cost may break some contracts. Thanks to the awesome work done by @jakmeier, we now know that only the contract on near needs to be upgraded for this change.
• Account creation throughput is lower due to increased cost. I don't think the throughput here is a big concern. Today with 4 shards we can create ~668 accounts per block and we plan to have even more shards in the future.
• Gas now can be burnt for storage (vs. before it is just about compute). Yes this is a conscious change and it feels to me that this is in the right direction of how storage should work. As mentioned in [Discussion] Removing storage staking for base account information #415, storage staking has a number of issues including the difficulty of storage management and bad ux for end users. In addition, people do not really delete data from storage anyways. We should think in general how storage management works, as suggested in Rethink storage management #185

[jakmeier]

This is actually something we could consider changing, as adding one more access key only adds 82 bytes to storage. @jakmeier do you know how much more can we increase account creation cost before something else breaks?

82 extra bytes, I assume the cost would still be < 7 Tgas, right? That seems completely fine.

If the total gas goes above 9Tgas, we have to look into the-auction-factory.near. But I think we could even go up to 20 Tgas and only need to quickly check 4 contracts that will probably turn out to be no problem anyway, as most of them allow to attach more gas by users to resolve the problem.

[bowenwang1996]

82 extra bytes, I assume the cost would still be < 7 Tgas, right? That seems completely fine.

If we want to have 4 full access keys, which is 2 more than the current design, then we need to add 164 bytes, which brings the account creation cost to 7.6Tgas

[jakmeier]

Oh, I see. 7.6 Tgas is also fine though, I just had to do some more checks.

Details

Only the-auction-factory.near falls in the problematic range and it seems all offending calls are to create_store, when it has only 100 Tgas attached. It will forward too much to on_create and not have enough to cover the extra account creation cost.
Luckily, this is a direct call and users can just attach 110 Tgas instead and it will work again.
Example: HtmRj7qbGofHmANWt9A6E2SpNjfzAWeQw6ZjxNJvSkmD

[frol]

Thank you to everyone who attended the third NEAR Protocol Working Group meeting! The working group members reviewed the NEP and reached the following consensus:

Status: Approved

• zero balance account NEP #448 (comment)
• zero balance account NEP #448 (comment)
• zero balance account NEP #448 (comment)

Meeting Recording:
https://youtu.be/ktgWXjNTU_A

@bowenwang1996 Thank you for authoring this NEP!

Next Steps:

• @bowenwang1996 to embed the benefits & concerns into the NEP document (see this example)
• @near/nep-moderators to approve and merge the NEP
• @near/wg-protocol to finalize the account creation cost
• nearcore team to stabilize the NEP implementation feat: add zero balance accounts nearcore#8378

Implementation Status: Implemented in nearcore, but not yet stabilized

[bowenwang1996]

Update: after a discussion with @k3y0k3y we decided to change the number of full access keys allowed to 4. This increases the account creation cost to 7.6Tgas. As we see in the discussion above, it won't break more contracts.

[jakmeier]

Today I learned: Every NEAR token transfer action to an implicit account costs transfer cost + account creation cost + add full access key cost. Even if the account already exists.

It makes sense in hindsight, we don't know if the account exists when we send the transfer. And for some reason NEAR uses transfer actions to create implicit accounts instead of create account actions, which I was long aware of. I just didn't connect the dots for what it means for normal transfers.

This has two consequences for the zero balance account feature which I haven't realized previously. Maybe the SMEs did think of it already, but to make sure we are not glancing over it, here are the implications:

• normal NEAR transfers to any implicit account address will now cost 0.23 Tgas + 0.2 Tgas + 7.6 Tgas = 8.03 Tgas
• If there are any contracts that use transfers to implicit accounts inside a indirect function call, it is possible they break with this change. My checks would not have covered these cases. I don't know an easy way to check for these either.
  But tbh, I am not sure why this pattern would be used in the first place. It is not inherently clear to me if it's even worth worrying about such cases.

@bowenwang1996 @mm-near @DavidM-D
Any thoughts on this? Do you think we can proceed as planned or does this substantially change the assumptions under which this has been accepted?

[frol]

@jakmeier That is a really good call. Exchanges heavily rely on implicit accounts as they own implicit accounts for each user, and now users will pay higher fees to top-up their CEX account balances, and CEX might also use implicit accounts internally for their cold wallets.

[bowenwang1996]

Updated the spec for zero balance account as per discussion here. @jakmeier I created #462 to document your concern, but as we discussed, it does not seem to be a blocker for this NEP. @firatNEAR we may want to check with partners who manage accounts on users' behalves and often do token transfers to implicit accounts.

[bowenwang1996]

@frol summary of benefits and concerns:

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

[frol]

As a NEP moderator, I am approving this PR following the Protocol Work Group approval and the decision context incorporated into the NEP document.