There is a function on the management canister called
canister_status which gives you information about the canister like its controllers, wasm hash, cycle balance. Currently this can only be called by the controllers of a canister. I propose we make this callable by anyone.
You can get some of the information from
canister_status off-chain already like the wasm hash, and the controllers of a canister.
The topic of getting this information on-chain has been raised on the forum multiple times, but always resulted in a discussion without a definitive answer on what to do next. (I hope we see a more formalized ICRC process soon!)
There is also this RFC but it seems like that never really made it farther then initial thoughts / MVP
I have seen people post hacks on how to get around this. Like using the outbound http requests or calling the
canister_status as a non controller and then parsing the error message to get the controllers. But needing to use these hacks is a horrendous dev experience.
During my time at DFINTY I was always in favor of making more canister info public, but now that I’m working on a DAO framework not being able to get this info easily on-chain is especially annoying.
Arguments in favor
Prevent incidents like the lost IC turtles NFT collection. With canister_status being public anybody could have monitored the cycles and could have warned the owners or send in some cycles themselves. Imagine this happening to a token with a huge market cap.
Being able to trust a canister by confirming it has no controllers, the hash matches the code you expect, and it won’t run out of cycles soon or that you know when to top it of yourself if the original devs abandon it.
- You can just use something like the blackhole canister to expose the
canister_statusif you want to expose it.
I personally find this again a terrible developer experience needing to manage an entire extra canister and making sure that doesn’t run out of cycles as well, just to expose this one call that I think should be public by default anyways.
- An attacker could use knowing the cycles balance to initiate a cycle drain attack right when it gets low.
I think the freezing threshold prevents this pretty well and I think important canisters running out of cycles because they get forgotten or nobody can monitor their cycles poses a far bigger risk to the ecosystem.
- option A : Making
canister_statuspublic to anyone.
- option B: Adding a new public API to the management canister that gives you the same information you can get off-chain like wasm hash, controllers, and running status without needing to resort to work arounds.
- option C: Make
canister_statussomething that the controller can choose to expose or not with a flag which is set to public by default
- option D: Make
canister_statussomething that the controller can choose to expose or not with a flag which is set to private by default
- option E: Do nothing
I suspect that option A would be the least engineering effort, but I would love to hear the opinion from the foundation as that is just a guess.
I can’t imagine anybody being against option B at the minimum, but I really hope we can just go with A and potentially add a private flag in the future if there is sufficient demand.
The first step is for devs to voice their opinions here about which option they would prefer and why. I would really appreciate it if an engineer DFINITY who knows the management canister well could offer their thoughts as well with regards to the engineering effort.
If we reach consensus on which option seems to be the most popular I would love it if one of the existing named neurons who is used to making proposals could do it for me. This way I don’t have to set up a 10 ICP neuron for making the proposal (I’d rather keep my personal one private). I can transfer the 10 ICP if it gets rejected.