What happens to a canister if i don't have enough tokens to pay?

sorry noob question : i know for sure that no code would be executed but lets say i have a canister with 4gb of data, would the subnet delete my canister? aso are canisters forced to be open source?

1 Like

you asked two questions and you might want to seperate them - on the second one check

and there are some other posts addressing this. So you can control access to the canisters.

On the what happens if you run out of token in a canister - this is a quite interesting one where I have no answer for…

The garbage collector will delete it.

2 Likes

On the what happens if you run out of token in a canister - this is a quite interesting one where I have no answer for…

Still somewhat in the air. One plausible option is that the canister will be emptied (i.e. your GBs of state, and also the code, will be removed), but an empty canister remains, and you can reactive it – this may be important if the canster’s id is associated with something worth keeping. These empty canisters are just a few bytes, neglectible next to GBs-sized canisters, so can hopefully stick around for longer than you have to worry about.

This touches the very hart of any business model someone would like to build an app on. Code and Data are one but code is easy to recover - data not.
The need of pre-provisioning of token - which some people might consider a step back - might be difficult to monitor and manage in a fast growthing app.
I would expect at least some clear defined grace periods etc. Consider you just lost some TB of data…

1 Like

Agreed! One thing I could imagine helping with this would be that the emptied canister would contain a hash of the data that was deleted from it. This way you could perhaps backup the data outside the network and reupload it if the hash matches

Sounds like a DDoS vector, no?

1 Like

It should not be possible to perform computation, store data, or consume bandwidth for free. If you give an attacker an inch they will take a mile.

1 Like

It’s not free; it’s paid for during canister creation. Consider this back of the envelope calculation: The storage cost of 50MB for two months is the same as the cost for one months of 50MB and 8000 years of 50 bytes…

Did not realize that’s what you were suggesting. Seems worth a conversation with developers. Such a scheme would highly disincentive creating temporary or short lived actors for one-time use.

It seems so at first, but if you do the math it suddenly looks quite appealing.

Let’s assume that “10MB for 2 months” is “pretty cheap”. Then “50 bytes for for 100 years” is “neglectible” (less than 1% of the former). It might be less than the cost of a inter-canister message (which you’d also have to pay to create a short-termed canister)…

But consider the alternative: Assume you had a canister and it’s id is valuable (holds tokens of some sort, is registered with some other service, or has a well-known id that other people or canisters are trying to use). It would be quite annoying if you could permanently lose control of that canister id, just because you were on vacation while suddenly your canister started burning through its cycle balance like crazy.

I predict that the ahead-of-time-cost for “we promise keeping a shadow of the canister alive forever” will disappear in the noise of MB-sized installation messages and actually running a canister, and nobody will notice. While losing access to tokens or services (which this is of course only one way) will be noticed quite painfully :slight_smile:

2 Likes

I see, I see. These are very good points. I think you are right. The cost seems justified then.

2 Likes