Zero Balance Account

[bowenwang1996]

Today in order for an account to exist onchain, it must maintain a minimum balance due to storage staking. For an account with one key, the minimum balance is 0.0182N. This makes it difficult for applications or wallets to create account for their users because there is an upside to be had by attacking the faucet that does the account creation: by creating and deleting accounts, a malicious attacker can siphon 0.0182N per account off of the faucet. This was why the NEAR wallet (now MyNEARWallet) stopped creating accounts for new users, which made the onboarding experience much less pleasant for new users.

We can fix this problem by allowing zero balance accounts to exist on chain. More specifically, creating an account with one key does not require storage staking and instead the cost is merged into the transaction cost (~182Tgas and can potentially be lowered since this amount is fully burnt). If the account deploys a contract later and start to accrue data on the smart contract, the storage staking mechanism would kick in the same way as how it works today.

One open question is whether adding additional keys triggers storage staking.

[frol]

the cost is merged into the transaction cost (~182Tgas and can potentially be lowered since this amount is fully burnt).

So then the faucet could still be drained by creating a ton of accounts, and the only difference is that at least there is no incentive for the attackers to do this.

If the account deploys a contract later and start to accrue data on the smart contract, the storage staking mechanism would kick in the same way as how it works today.

Do you mean that it will suddenly count the account storage and the first access key into the storage cost and refund it on deletion? If so, it will negate the whole effort that malicious actors will just add a couple of extra steps of deploying an empty contract and then deleting the account.

[ryancwalsh]

the faucet could still be drained by creating a ton of accounts, and the only difference is that at least there is no incentive for the attackers to do this.

Attackers could still feel motivated / incentivized to do it (even if they won't directly collect the funds).

[akhi3030]

CC: @mm-near and @jakmeier

[jakmeier]

What would be the incentive to delete implicit accounts that are no longer needed? If there is none, and because deleting costs gas, an app that needs single-use implicit accounts for one or another reason would be rational to create but never delete implicit accounts. Thereby increasing the chain state potentially forever.

More specifically, creating an account with one key does not require storage staking and instead the cost is merged into the transaction cost (~182Tgas and can potentially be lowered since this amount is fully burnt).

Detail: I think we would be better off burning tokens rather than gas, in order to not reduce max throughput.

[mfornet]

What would be the incentive to delete implicit accounts that are no longer needed?

As I understand, the current state of affairs is that users are not deleting unused state to claim their tokens back. See first part of this comment. Still backing up this claim with data would be good.

On Ethereum they are using a different approach to solve this issue. Clients won't store all the state forever, but "old" parts are pruned away, and users can bring them to life again by providing proof of the data. Something similar can be done on NEAR.

Detail: I think we would be better off burning tokens rather than gas, in order to not reduce max throughput.

I agree with this suggestion. It affects throughput artificially, and it will be charging users depending on the current gas price for something that will be stored "forever" on-chain. It shouldn't matter the time you create the account.