TL;DR
A recent significant increase in compute demand has maxed out capacities on several subnets, leading to increased message processing latency. In alignment with a recently approved motion, this forum post provides a detailed review of compute pricing to ensure that subnet revenues adequately reflect operational costs.
We evaluated various usage scenarios including handling multiple messages from many canisters, processing maximum instructions, and managing canister overhead. The analysis suggests the following pricing adjustments:
- Increase the message base fee from 590K to 5M cycles.
- Increase the instruction fee from 0.4 to 1 cycle.
- Increase the canister installation fee from 0.1 to 0.5 trillion cycles.
The estimated impact on selected applications suggests a total cost increase ranging from 15% to 70% based on the proposed new pricing, aligning with the increase proposed in the motion proposal.
Background
In recent weeks, a significant increase in the demand for computation on the Internet Computer Protocol has been observed. This growth, although very positive, has also highlighted several challenges. The maximum compute capacities have been reached in several subnets, resulting in canisters being delayed due to the need to wait for available compute resources, thereby increasing the latency of message processing. For more background information on this topic see here.
The focus of this post is on the review of compute pricing in the context of the observed high demand patterns. This is aligned with a community motion proposal that was recently approved.
The applied guiding principle is that the protocol should ensure that the pricing for subnet usage accurately reflects its operational costs. If revenue generated from a subnet aligns with its operational costs, additional subnets can be deployed to handle increased load. The eventual goal is that every reasonably loaded subnet burns more cycles than rewards allocated to node providers, such that every subnet helps offset the NNS voting rewards. Note that pricing should be reviewed periodically to account for future changes in protocol efficiency or varying operational costs.
Analysis of Usage Scenarios and Pricing Implications
We evaluate various usage scenarios to understand the generated revenue and recommend pricing adjustments that accurately offset subnet operational costs.
Subnet costs consist of node rewards, which vary depending on the hardware used and the geographic location of the nodes. Currently, the average reward per node is approximately 1,500 XDR per month. For a subnet comprising 13 nodes, this translates to monthly operational costs of 19.5K XDR, or 7.42 billion cycles per second.
Based on recent usage patterns and capacity constraints, we have identified three scenarios for detailed analysis:
- Multi-Message Many Canisters: A subnet handles numerous small messages from various canisters.
- Maximum Number of Instructions: A subnet processes the maximum number of instructions.
- Canister Limit: A subnet reaches the maximum number of canisters it can support, focusing on the overhead induced by high canister volumes.
Scenario: Multi-Message Many Canisters
Analysis:
Starting every distinct canister creates overhead. The base overhead is 2M instructions per message. The canister-specific overhead is 8M instructions for each new canister executed in a round. This results in a total overhead of 10M instructions per distinct canister message. Given a thread limit of 2 billion instructions, a single thread can process 200 messages. With four threads, this capacity is 800 messages per round. Anticipated short-term improvements to the execution protocol could potentially increase the capacity to 1500 messages.
Revenue:
In the current pricing model, the execution cost per message is calculated based on a base fee of 590,000 cycles plus an instruction fee of 0.4 cycles per instruction. Given the assumed low instruction count per message in this scenario, the current revenue is approximately 0.47 billion cycles per second (590K cycles Ă— 800 messages). With the anticipated increase in capacity, potential revenue could rise to 0.89 billion cycles per second (590K cycles Ă— 1,500 messages).
Conclusion:
To align revenue with operational costs under this scenario, the base fee for message execution needs to increase by a factor of approximately 8.4 (calculated as 7.42 billion cycles in costs divided by 0.89 billion in potential revenue). This suggests increasing the base fee from 590,000 cycles to around 5 million cycles.
Scenario Maximum Number of Instructions
Analysis:
A subnet on the IC is currently running on 4 threads, each of which is capable of processing 2 billion instructions per second.
Revenue:
Under the current pricing scheme, processing one instruction costs 0.4 cycles. Therefore, at full capacity, the subnet spends 3.2 billion cycles per second (0.4 cycles per instruction Ă— 8 billion instructions).
Conclusion:
To cover the subnet costs of 7.4 billion cycles per second, increasing the fee from 0.4 cycles per instruction to 0.925 cycles per instruction would be necessary (calculated as 7.4 billion total subnet costs divided by 8 billion instructions processed). For ease of billing, it is recommended to adjust the fee to 1.0 cycle per instruction.
Scenario Canister Limit
Analysis:
Subnets experience significant load when hosting a large number of canisters, even if these canisters are idle. To manage this load, a cap of 120,000 canisters per subnet has been implemented. Future protocol modifications aim to reduce the load from idle canisters. We analyze how a high number of canisters impacts subnet performance and adjust canister installation fees accordingly, to ensure they cover the full cost of canister loads.
To estimate the slowdown caused by many canisters, our focus is on subnets with low instruction loads but significant canister counts (more than 50,000). Data from October 24, 2024, shows:
- Subnets with ~50,000 canisters (e.g., o3ow2 and qdvhd) have a finalization rate of around 1.8, indicating execution round times of approximately 500ms.
- Subnets with ~90,000 canisters (e.g., eq6en and 2fq7c) display a finalization rate of around 1.1, indicating execution round times of 900ms.
Since none of these subnets process a very large number of instructions, the time spent in execution rounds can mostly be attributed to per-canister overhead.
Revenue:
The additional overhead for handling 40,000 more canisters (from 50k to 90k) is roughly 400ms. At the current subnet limit of 120,000 canisters, the overhead increases to 1200ms, more than doubling the typical execution round time of 1000ms to 2200ms. This equates to 55% of processing time being consumed by overhead, translating to 4.07 billion cycles per second (55% of the total 7.42 billion cycles per second). This results in a cost of approximately 34,000 cycles per canister per second.
Conclusion:
We propose incorporating the overhead that a canister incurs into the canister creation fee. Assuming a time period of 6 months, this adjustment would translate to a cost of 0.53 trillion cycles per canister. After rounding, we suggest a fee of 0.5 trillion cycles per canister. DFINITY anticipates protocol improvements that would significantly reduce the canister overhead, and if those improvements indeed take place, we recommend revisiting the canister creation fee.
Impact on Example Applications
Using the example presets defined in the ICP Pricing Calculator, we estimate the financial impact in USD of the proposed changes over a one-year period for both installation and usage.
Based on the previous analysis, we assume the following adjustments to pricing:
- Message Base Fee: Increases from 590K cycles to 5M cycles.
- Instruction Fee: Increases from 0.4 cycles to 1 cycle per instruction.
- Canister Installation Fee: Increases from 0.1 trillion cycles to 0.5 trillion cycles.
For the scenarios considered, we observe an overall cost increase ranging from 0% to 70% based on the proposed new pricing. This range is consistent with the motion proposal previously approved by the community. Please note that the biggest relative change of 70% for dapp #1b is primarily due to an increase in one-off costs.
Suggested Next Steps
Discuss the suggested pricing adjustments on the forum. Afterwards submit proposals for the suggested price changes.
