The new implementation will be gated behind a feature flag. This means:
- On mainnet, the new instrumentation is not enabled and will not influence your existing canisters until an NNS motion proposal is voted in by the community to enable it.
- There will be a new dfx version with the new instrumentation enabled for local deployment. You can experiment with it to understand its impact on your canisters. Please report back any discrepancies or large regressions.
- Once all feedback from the community is addressed, we will submit an NNS motion proposal to enable the feature on mainnet.
- If the NNS motion proposal passes, then DFINITY will propose a replica version with the feature enabled for rollout on mainnet.
The IC instruments Wasm binaries by injecting tiny snippets of code in order to count the number of executed instructions. This is needed to ensure that canister execution terminates and is fairly charged for.
The current instrumentation algorithm works well, but is inefficient for certain kinds of applications such as language interpreters. The new Wasm instrumentation addresses these inefficiencies and achieves an order of magnitude better performance for such applications, allowing developers to run their canisters more efficiently and possibly cheaper.
This proposal significantly revamps the way the IC performs instrumentation, modifying its core algorithm as well as important algorithm parameters, such as weights to be taken into account for Wasm instructions and system calls. The end result will be more efficient execution of user code, more stable block rate, and fair resource sharing between IC users.
Whereas the old instrumentation treats all instructions as equal in terms of cost, the actual cost of an instruction depends on its type. For example, division is more expensive than addition. The standard practice in the blockchain world is to have different costs for different instructions, for example varying gas costs per opcode in the EVM, as specified in the Yellow Paper. Therefore, in the reworking of the instrumentation component we propose to take instruction weights into account when doing instruction counting. This leads to a non-uniform instruction cost model that might affect the total cycle consumption of certain workloads.
Below you can find several examples of how applications can be impacted by the new instrumentation’s initial prototype. While this is no exhaustive list, it gives an indication of what canister developers can expect for different types of applications. Once the dfx distribution including the new instrumentation is available, we invite you all to experiment with it and report back any corner cases, which are possible.
|No. of Instructions Counted
|-97% (30x less instructions, cheaper)
|-47% (2x less instructions)
|+17% (more instructions, costlier)
|NNS voting reward distribution
(Note that a X% increase in the number of instructions does not directly translate to an X% increase in overall cost. This does not include ingress and message execution fees.)
A more detailed timeline plan will follow.
Article with contributions also from Andriy, Maciej and Ulan.