Yesterday and today I was involved in two cases where individuals have deployed workloads with a small number of tokens in their wallets and the wallets ran dry of tokens. The unfortunate situation is that when a wallet runs dry (eg. zero tokens left) the contract is canceled and the workloads/deployments are deleted.
The grid is made up of a (growing) number of farmers who own and operate 3nodes. Funding wallets for overage is prone to abuse and allowing workloads to exist for longer than feasible based on the wallet balance will also attract smart cookies that will find a way to get “free” capacity.
So this post is here to source smart ideas from the community on how to deal with this issue. The current implementation is clearly not ready to go mainstream and be accepted.
Possible solution avenues.
Based on the total value of the wallet at the start of a contract there is a certain percentage of time (which translates easily into tokens as the contract subtract x TFT’s per hour from the wallet) that the workload can overrun. This sounds like an idea that could work, but it only pushes the same issue out. What do we do it the extra time is used. Do we then delete?
Make the workload in-accessible when the wallet runs out of tokens, but keep all the data and configuration work done. This can be done in a number of ways:
- just retain the data, on SSD volumes and Quantum Safe Storage ZDB’s but stop the processing (CU capacity)
- freeze / hibernate the whole architecture / solution until the wallet is funded again
- just make the architecture inaccessible.
Challenge here is that while this workload is inaccessible the resources used are still in play and we need to fund somehow the workload to continue to exist.
So what do you think is a smart way to deal with this situation?