Limit draining testnet account tokens from helper account

[ChaoticTempest]

Was thinking about this the other day and opened an issue on workspaces-rs side (near/near-workspaces-rs#215), but feels like this could just be implemented directly in the helper itself.

The idea is to slow down the draining of testnet tokens for dev accounts by scheduling a deletion of the dev account after a certain amount of time using something like cron.cat and return the funds to the helper account. To me, it feels like a lot of dev accounts that get created just become one off experiments that are forgotten about. So what would be cool is if our default behavior for creating accounts through the helper contract is to set a time limit till deletion, but if its an account created through wallet, we have an additional parameter where we set the time limit to be indefinite or do not schedule the deletion at all. We'll definitely have to warn users afterwards that when doing dev-deploy, their account will be deleted after a certain amount of time.

And on top of the scheduling, we can have some sort of smart scheduling where we have cron.cat check every set interval to see if the account is active or not, then if its not, proceed to delete.

This isn't going to fix the whole problem of complete drainage of the helper contract funds, but slows it down so we potentially don't have to do a hard fork of the chain to increase the overall testnet token supply.

What does everyone think about this?

[idea404]

Fully support having a timed function delete the dev accounts after a given time frame. I do think that if we were to do this, we should also add disclaimers whenever these accounts are created, and also in the function descriptions that create these accounts, and the docs.

As for how, I would prefer the machine hosting the helper service to have its own cronjob that goes through the dev accounts, looks at how old they are, then deletes depending on age. This since the croncat service would also need to be topped up in $NEAR periodically as to keep it running, which would also require a cron in the helper's machine I think. But I'm not precious about this.

[ChaoticTempest]

As for how, I would prefer the machine hosting the helper service to have its own cronjob that goes through the dev accounts, looks at how old they are, then deletes depending on age. This since the croncat service would also need to be topped up in $NEAR periodically as to keep it running, which would also require a cron in the helper's machine I think. But I'm not precious about this.

That works too. I initially suggested cron.cat so we could keep it decentralized, and also not need to potentially maintain extra state for these account keys that we would have to keep track of to do the deletion. cron.cat might need to be topped off, but think we could top it off every single time we schedule to avoid having to periodically refill the task balance

[volovyks]

• In a standard workflow, dev acc is not generated on each dev-deploy call, it is reused. Let's delete it after X time of inactivity.

• check if NEAR CLI and other tools logic work (if somebody left the laptop for a year and then came back, it should recreate an account saved in his env)

• this time should not be short, I'm voting for 30+ days

[austinabell]

I initially suggested cron.cat so we could keep it decentralized, and also not need to potentially maintain extra state for these account keys that we would have to keep track of to do the deletion.

The issue with this is if you want it to be handled by inactivity, you would still need a separate process to track this and modify the scheduled transaction, would you not? Croncat wouldn't be able to check activity from their contracts, do they?

check if NEAR CLI and other tools logic work (if somebody left the laptop for a year and then came back, it should recreate an account saved in his env)

Would you assume this re-deploys previous code and sets state to what it was before?

Generally, these ideas seem nice in theory, but add a lot of complexity and would be a frictional point if someone is expecting their dev account to remain active and not have to continually check and ping it. I personally have deployed some test contracts and gone back months later to re-use or check back in on how it's been used.

[volovyks]

Would you assume this re-deploys previous code and sets state to what it was before?

Yes... but it seems magical and can lead to unpredictable behavior from the developer's point of view. Maybe it's better to postpone this decision and look for non-breaking transparent solutions.

[ChaoticTempest]

The issue with this is if you want it to be handled by inactivity, you would still need a separate process to track this and modify the scheduled transaction, would you not? Croncat wouldn't be able to check activity from their contracts, do they?

that is true, unless there's some magical oracle out there that gives us transaction data 😅 .

Generally, these ideas seem nice in theory, but add a lot of complexity and would be a frictional point if someone is expecting their dev account to remain active and not have to continually check and ping it. I personally have deployed some test contracts and gone back months later to re-use or check back in on how it's been used.

Then how about just have it be scheduled to be deleted after X amount of time. No need for this smart scheduling then since it adds all this complexity with tracking for inactivity. Users will be forced to set a flag if they want to keep their dev accounts longer, with a gigantic warning in the CLI/Workspaces/WhateverTooling(TM) that their account will be deleted within a certain amount of time.

Maybe it's better to postpone this decision and look for non-breaking transparent solutions.

There were a couple discussed last I heard:

• forking testnet to increase the token supply but that had some caveats to them (@mm-near you said a couple things at nearcon about the disadvantages here).
• Staking the testnet tokens to steadily increase the supply in the helper contract was another potential solution but that also had potential problems if dev-accounts being created outpaced the staked generated tokens.

[volovyks]

@ChaoticTempest all 3 options will not guarantee the outpacing problem. It means that we can implement all of them. Probably 1 by 1, maybe we will be lucky. I like the staking approach, then - account deletion.