Hey @Manu thanks for your interest in using CycleOps.
First off, I want to say that I 100% understand the hesitation behind adding a controller to any NNS-controlled or other high profile canisters (like ckBTC), and do not advise anyone adding a controller to a canister if they do not either know and trust the controller, or trust the underlying technology with which that controller or and canister is associated.
We started off on the “standards” route, but ran into issues around messaging guarantees, specifically if a malicious canister decides to put up a barrier, meaning that in this case our service canister would no longer be upgradeable.
Having named callbacks, as described here would allow us to modify our architecture to monitor 3rd party canisters without trust.
One potential work around would be to provide a 3rd-party library in Rust, Motoko, Azle, etc. that would allow us to one-shot (fire and forget) into a standardized endpoint API, and then have that endpoint fire back data. At this point though, we realized that we could run into issues since we would no longer be able to trust the protocol to control the data being passed back to us and it could potentially be forged to clog up canister ingress or manipulated to stage a cycle drain attack against our service.
So how did we eventually decide on a blackhole? Last year, I remember having a conversation with @jorgenbuilder and @kpeacock about the sparse use of blackholed canisters in the IC ecosystem, issues with trusting 3rd party canisters, and specific use-cases that require trustless interaction and would make a lot of sense for a blackholed canister.
The blackhole approach we landed on for CycleOps was actually inspired by @PaulLiu’s wonderful ic-blackhole application.
Blackholing our balance checker & leveraging the canister_status API of the IC management canister allows us to use the features and functionalities of the Internet Computer to securely monitor canisters dapps at scale without requiring that developers add a single line of code to their canisters. This monitoring feature that isn’t possible on other clouds or blockchains, so we decided to embrace no-code, IC native monitoring as a superpower of the IC and CycleOps.
Since the blackholed balance checker canister’s code and wasm running will never change, deciding to add it as a controller just requires a one-time code review of this canister. Additionally, the CycleOps monitoring solution allows developer teams to turn monitoring on or off at anytime with a simple shell command instead of requiring a full canister upgrade and the potential risks associated with canister upgrades.
To top it all of, since the CycleOps team trusts the IC and the canister management API, we know that the cycles balance data coming back from the canisters we monitor is legitimate and cannot be forged.
We 100% understand why there would be valid concerns around adding a controller to a canister, which why in addition to black-holing the balance checker, we open sourced its code and have provided steps one can use to verify the code, wasm hash, and controllers of that canister. We’ve also provided a GitHub action for this!
GitHub - CycleOperators/BalanceCheckerVerification: Blackhole and wasm verification of the CycleOps StatusChecker canister.
This all being said, we are in no way entrenched in our current monitoring approach, and would be happy to receive feedback from the DFINITY team regarding safe, trustless ways that we can monitor 3rd party canisters.