The cycles initiative should belong to Battery, not to child canisters

[vporton]

In my opinion, the logic of this package is wrong:

If a child canister happens to drain to zero, it can't request more cycles, because it can't do anything.

Therefore I propose the following idea:

Instead of child canisters requesting more cycles, let the Battery canister from time to time iterate through the list of all child canisters, and when it sees that a child has little cycles, give it cycles.

Do you agree with my idea?

[ByronBecker]

Good points @vporton

A few reasons why we decided to build the library this way.

1. To monitor a canister in the way you described, either:
   a. the battery must be a controller of the child canister
   b. the child canister must expose an endpoint that the battery calls into.

In the case of 1b), having the Battery canister call the child canister can be unsafe if the child canister has upgraded one of its APIs in a malicious manner (see https://github.com/nomeata/ic-barrier?tab=readme-ov-file#caution)

Assuming your child canisters are active, this library ensures that the child canisters will not run out of cycles as long as they receive an update call every n seconds.

Additionally, for inactive canisters instead of requiring the battery canister to make an inter-canister call every so often, you can include the cycles requester library logic inside of a timer in each of the child canisters. It will save you the cost of an inter-canister call.

I'm looking forward to https://forum.dfinity.org/t/canister-lifecycle-hooks/17089, specifically the canister_on_low_cycles hook, which DFINITY has on their roadmap and I expect to be released sometime this year. I'll update this library when that hook comes out 🙂