Fixing incorrect compute allocation fee

Developers
1

Background

Compute allocation is a feature that allows a canister to get higher priority in scheduling for execution. The details on how it works currently are described in this forum post. Canisters that do not have any compute allocation run according to a fair best-effort schedule.

As of writing, canisters do not use compute allocation except for one canister. That canister has the minimal possible 1% compute allocation. Effectively, compute allocation is an unused feature.

The current fee for compute allocation was set before network Genesis. It was calculated based on the instruction throughput of a single execution core:

compute_percent_allocated_per_second
= instructions_per_second * instruction_cost / 100% / discount_factor
= 10^9 * 0.4 / 100% / 40 = 10^5 cycles

The discount factor was chosen tentatively under the assumption that a canister with compute allocation would likely pay other fees.

The problem

The reasoning behind the formula above has a major flaw: compute allocation should be considered much more valuable than the corresponding number of executed instructions because compute allocation provides low latency.

For example, a canister with 100% compute allocation runs every round. On the other hand, a canister that executes the maximum number of instructions might not get scheduled to run every round. Its latency depends on how busy the subnet is.

Besides that, the total compute allocation is limited. A canister with 100% compute allocation effectively makes one execution core unavailable for other canisters regressing their performance. In summary, the current fee is set orders of magnitude lower than the fair fee.

The fix

There is ongoing work on a holistic, economically-driven, pricing model that accounts not only for the node provider rewards, but also for other key factors such as voting rewards. This model will allow for a future equilibrium of minted and burned ICP assuming certain IC size and utilization.

Until that model is ready, we take a more ad-hoc approach. The first adjustment is to remove the 40x discount factor so that compute allocation matches the instruction throughput. This gives the fee of 4M cycles per one percent of compute allocation per second.

Additionally, the scarcity and impact on other canisters should be somehow factored in the fee. Until we have the holistic model, we set the fee to 10M cycles per one percent of compute allocation per second.

The impact

Since all canisters except one do not have any compute allocation, they will not be affected by this change. The compute allocation of the affected canister will be set to 0% and that canister would need to opt-in to use compute allocation with the new fee after the change is rolled out.

The rollout plan

The rollout will be done over two replica versions.

Version 1:

  • Disable changing of compute allocation in canister settings.
  • Set compute allocation to 0% for all canisters, so that no canister is impacted by the fee change.
  • Update the compute allocation fee.

Version 2:

  • Enable changing of compute allocation so that canisters can opt-in to use compute allocation with the new fee by updating the canister settings.
10 Likes