NNS Proposal: Make canister_status public to anyone

Governance
66

Following this poll from @domwoe, it seems as if there is universal support to provide an opt-in (optional) ability to make a canister’s metric data via canister_status public.

From our experience building CycleOps, and as shown by the adoption of both CycleOps and CanisterGeek, developer teams generally want a readily available monitoring tool or service instead of having to build one themselves. It saves developers time in not having to reinvent the monitoring wheel, and allows them to focus their time instead on building great apps.

The ability to monitor canisters through the protocol via canister_status gives 3rd party applications a frictionless and smooth path for integrating monitors with developers and project teams. However, the approach of needing to verify & add a blackhole as controller to start monitoring - even with open sourced code, a mechanism for verifying the legitimacy of the blackhole, and social trust of other applications using the blackhole, is a point of friction for many.

I’d therefore like to suggest moving this proposal forward with some rough, but concrete ideas for how it can be implemented.

  1. Provide the ability for a controller to make the canister_status of a specific canister id public. This can be done through a set_canister_status_public API on the management canister, where the controller of a canister can choose to make that canister status public or not.
type SetCanisterStatusPublicArgs = record {
  // is the canister' status currently public?
  is_public : bool;
  // if not public, this is ignored, if public defaults to Exact unless specified
  cycles_granularity : opt variant {
    Exact;
    Fuzzy;
  };
};
type SetCanisterStatusPublicResult = variant { Ok; Err : PossibleErrorVariants };
set_canister_status_public: (SetCanisterStatusPublicArgs) -> (SetCanisterStatusPublicResult);
  1. Add the canister’s is_public status, as well as the canister’s current cycles_granularity to the response that comes from the current canister_status endpoint on the management canister.

    This way, a controller of the canister can easily check to see if they’ve made their canister status public, and any 3rd party that calls canister_status on a public canister is informed that the cycles balance returned is fuzzy or exact, and can then reliably surface that information.

Addressing security concerns by providing the ability to surface fuzzy or exact cycles balances

Some in this thread, such as @ulan have brought up potential inference attack vulnerabilities with making a cycles balance public. This is a valid concern, where the attacker could potentially bypass an poorly secured conditional statement by probing an API with different parameters and checking the cycles balance difference in order to probe an internal variable or equivalence in a conditional statement and bypass the check or extract the value of the internal variable.

Therefore, I think it’s beneficial to give the developers the option of not just making their canister status public or not, but providing the ability to choose between Exact or Fuzzy cycles granularity, with a default of Exact if the canister_status has been made public (see proposed variant above).

Ideally, a Fuzzy cycles balance would randomly oscillate between +/- 1000 cycles of the true cycles balance, with over time the average of all deviations approaching zero.

I’m curious if anyone has any suggestion as to the actual implementation of how the deviation is calculated, as well as figuring out what the best and most efficient form of randomness to use in the deviation calculation, so as to not slow down the canister_status API (i.e. maybe the management canister holds a new random value or seed each round of consensus and then transforms the exact responses of all canisters).

3 Likes