Internet Computer Wiki - User contributions [en]

Internet Computer wiki

2021-11-26T08:23:51Z

Akhi:

<strong>Welcome to the Internet Computer Wiki!</strong> Feel free to join in. All are welcome!
== Topics Central ==

* [[Internet computer]]
* [[Internet Computer vision]]
* [[Index of dapps on the Internet Computer]]
* [[ICP token]]
* [[Internet Identity]]
* [https://dashboard.internetcomputer.org/ Internet Computer dashboard]
* [[Internet Computer Performance]]
* [[DFINITY]]
* [[Custody, Staking, and Voting]]
*[[Network Nervous System]]
*ICP is expected to outgrow every crypto in the known universe. ICP coins will be used to power the future of the world.
== For blockchain & crypto enthusiasts ==
* [[Myths and facts]]
* [https://www.reddit.com/r/dfinity/ r/dfinity]
* [[How to stake on the Internet computer]]
* [[Tokenomics of the Internet Computer]]
* [[Governance of the Internet Computer]]

== For dapp developers ==
* [[Internet Computer for dapp developers]]
* [[Canister smart contracts]]
* [https://forum.dfinity.org/ IC community developer forum]
* [[Best practices for a high traffic dapp launch]]
* [[Best practices for NFT drops]]
* [[Current limitations of the IC]]

== For computer scientists ==
* [[The Internet Computer for Computer Scientists]]

== For node owners ==
* [[Internet Computer for node owners]]

== FAQs ==

* [[FAQ]]
== How-To section ==
How-Tos are step-by-step instructions for specific, narrow goals.
* [[How-To: Claim neurons for seed participants]]

== Tutorial section ==
Tutorials are guided introductions to user stories, intended for first-time users and characterized by a shallow learning curve.
* [[Tutorial: Neuron control]]

== Contributors ==

=== Housekeeping Rules ===

* Please refrain from redundancy, such as referring to the Internet Computer in article titles. This is, after all, the Internet Computer Wiki.
* Please carefully consider your use of capitalisation. Most words in titles should be capitalised. DFINITY is always stylised in all-caps.

=== How to Contribute ===
Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

Use this page to test editing
* [[Test editing the Internet Computer Wiki]]

Number of articles: {{NUMBEROFARTICLES}}

Known limitations of the IC

2021-11-26T08:23:26Z

Akhi: Akhi moved page Known limitations of the IC to Current limitations of the IC

#REDIRECT [[Current limitations of the IC]]

Current limitations of the Internet Computer

2021-11-26T08:23:26Z

Akhi: Akhi moved page Known limitations of the IC to Current limitations of the IC

Below we list the common set of limitations that anyone developing on top of the IC should be familiar with. The team hopes to be able to address these limitations in the future. In some cases, it is not clear what is the best way to address the limitations and further design discussions are needed.

== Bugs in pre_upgrade hooks ==
If there is a bug in your pre_upgrade hook that causes it to panic, then the canister can no longer be upgraded. This is because the pre_upgrade hook is part of the currently deployed wasm module and the system will always execute it before deploying the new wasm module and if the pre_upgrade hook fails, then the system will fail the whole upgrade.

Currently we do not have a good mitigation around this issue other than urging developers to make sure that their pre_upgrade is bug free by doing a lot of testing.

== Long running upgrades ==
Generally speaking, when a canister is being upgraded, the logic in the pre_upgrade hook serialises state from the wasm heap to stable memory and the logic in the post_upgrade hook deserialises it from stable memory back to wasm heap. There is an instructions bound on how long the upgrade process can run for. So it is possible that if the canister has too much state or the [de]serialising logic is not very efficient, then the whole process does not finish in time.

The recommended mitigation here is to ensure that the state that needs to be persisted across upgrades does not exceed what the canister can [de]serialise during the upgrade process.

== [de]serialiser requiring additional wasm memory==
[https://github.com/dfinity/motoko/issues/2909 Related issue in Motoko]. Generally speaking, it is possible that the serialising logic requires some additional wasm heap to run. Let’s say that the canister has 3.5GiB of wasm heap and the serialising logic requires an additional 600MiB to serialise the data, given that the wasm heap is limited to 4GiB, the upgrade process will again fail. Note that this issue will also be present for canisters written in Rust.

The recommended mitigation here is to again ensure that the state that needs to be persisted across upgrades does not exceed what the canister can [de]serialise during the upgrade process.

== Only upgrading stopped canisters ==
Generally speaking, it is only safe to upgrade stopped canisters i.e. canisters that do not have any outstanding responses. This is because it is possible that the new wasm module will not be compatible with the response that refers to an earlier state of the canister and could corrupt the current state of the canister. The current implementation of the IC allows canisters that are not stopped to be upgraded (with the assumption being that the canister developer has taken sufficient precautions to ensure the above mentioned corruption cannot happen).

== Calling potentially malicious or buggy canisters can prevent canisters from upgrading ==
If a canister can only be safely upgraded when it is stopped, it can run into the follow issue. If a canister `A` sends a `Request` to another canister `B` and `B` is buggy or malicious, it can create a situation where it does not send a `Response` back to `A` for arbitrarily long time. `B` can keep the call context alive if it keeps sending out `Request`s of its own. As long as `A` has an outstanding `Response`, upgrading it may not be safe.

== Loops in call graphs ==
The current implementation of the IC allows canisters to be called in a loop. For example, A can B, B can call C, and C can call A. There can be subtle issues when one attempts to do canister management in a loop though. If A sends a request (Req1) to B, while processing Req1 from A, B sends a StopCanister message to stop A, the canisters will effectively deadlock. When the StopCanister message is processed, A will be put in the Stopping state. It will only fully stop, when it has received a response for Req1. It will not receive a response for Req1 till B gets a response for its StopCanister message, and B will not get that response till A is stopped.

Current limitations of the Internet Computer

2021-11-26T08:21:28Z

Akhi:

Current limitations of the Internet Computer

2021-11-22T11:24:43Z

Akhi: /* [de]serialiser requiring additional wasm memory */

Below we list the common set of limitations that anyone developing on top of the IC should be familiar with. The team hopes to be able to address these limitations in the future. In some cases, it is not clear what is the best way to address the limitations and further design discussions are needed.

== Bugs in pre_upgrade hooks ==
If there is a bug in your pre_upgrade hook that causes it to panic, then the canister can no longer be upgraded. This is because the pre_upgrade hook is part of the currently deployed wasm module and the system will always execute it before deploying the new wasm module and if the pre_upgrade hook fails, then the system will fail the whole upgrade.

Currently we do not have a good mitigation around this issue other than urging developers to make sure that their pre_upgrade is bug free by doing a lot of testing.

== Long running upgrades ==
Generally speaking, when a canister is being upgraded, the logic in the pre_upgrade hook serialises state from the wasm heap to stable memory and the logic in the post_upgrade hook deserialises it from stable memory back to wasm heap. There is an instructions bound on how long the upgrade process can run for. So it is possible that if the canister has too much state or the [de]serialising logic is not very efficient, then the whole process does not finish in time.

The recommended mitigation here is to ensure that the state that needs to be persisted across upgrades does not exceed what the canister can [de]serialise during the upgrade process.

== [de]serialiser requiring additional wasm memory==
[https://github.com/dfinity/motoko/issues/2909 Related issue in Motoko]. Generally speaking, it is possible that the serialising logic requires some additional wasm heap to run. Let’s say that the canister has 3.5GiB of wasm heap and the serialising logic requires an additional 600MiB to serialise the data, given that the wasm heap is limited to 4GiB, the upgrade process will again fail. Note that this issue will also be present for canisters written in Rust.

The recommended mitigation here is to again ensure that the state that needs to be persisted across upgrades does not exceed what the canister can [de]serialise during the upgrade process.

== Only upgrading stopped canisters ==
Generally speaking, it is only safe to upgrade stopped canisters i.e. canisters that do not have any outstanding responses. This is because it is possible that the new wasm module will not be compatible with the response that refers to an earlier state of the canister and could corrupt the current state of the canister. The current implementation of the IC allows canisters that are not stopped to be upgraded (with the assumption being that the canister developer has taken sufficient precautions to ensure the above mentioned corruption cannot happen).

== Loops in call graphs ==
The current implementation of the IC allows canisters to be called in a loop. For example, A can B, B can call C, and C can call A. There can be subtle issues when one attempts to do canister management in a loop though. If A sends a request (Req1) to B, while processing Req1 from A, B sends a StopCanister message to stop A, the canisters will effectively deadlock. When the StopCanister message is processed, A will be put in the Stopping state. It will only fully stop, when it has received a response for Req1. It will not receive a response for Req1 till B gets a response for its StopCanister message, and B will not get that response till A is stopped.

Current limitations of the Internet Computer

2021-11-22T10:55:54Z

Akhi: /* Loops in the call graphs */

Below we list the common set of limitations that anyone developing on top of the IC should be familiar with. The team hopes to be able to address these limitations in the future. In some cases, it is not clear what is the best way to address the limitations and further design discussions are needed.

== Bugs in pre_upgrade hooks ==
If there is a bug in your pre_upgrade hook that causes it to panic, then the canister can no longer be upgraded. This is because the pre_upgrade hook is part of the currently deployed wasm module and the system will always execute it before deploying the new wasm module and if the pre_upgrade hook fails, then the system will fail the whole upgrade.

Currently we do not have a good mitigation around this issue other than urging developers to make sure that their pre_upgrade is bug free by doing a lot of testing.

== Long running upgrades ==
Generally speaking, when a canister is being upgraded, the logic in the pre_upgrade hook serialises state from the wasm heap to stable memory and the logic in the post_upgrade hook deserialises it from stable memory back to wasm heap. There is an instructions bound on how long the upgrade process can run for. So it is possible that if the canister has too much state or the [de]serialising logic is not very efficient, then the whole process does not finish in time.

The recommended mitigation here is to ensure that the state that needs to be persisted across upgrades does not exceed what the canister can [de]serialise during the upgrade process.

== [de]serialiser requiring additional wasm memory==
Related issue in Motoko: GC: Reserve Wasm memory for upgrading canisters · Issue #2909 · dfinity/motoko · GitHub. Generally speaking, it is possible that the serialising logic requires some additional wasm heap to run. Let’s say that the canister has 3.5GiB of wasm heap and the serialising logic requires an additional 600MiB to serialise the data, given that the wasm heap is limited to 4GiB, the upgrade process will again fail. Note that this issue will also be present for canisters written in Rust.

The recommended mitigation here is to again ensure that the state that needs to be persisted across upgrades does not exceed what the canister can [de]serialise during the upgrade process.

== Only upgrading stopped canisters ==
Generally speaking, it is only safe to upgrade stopped canisters i.e. canisters that do not have any outstanding responses. This is because it is possible that the new wasm module will not be compatible with the response that refers to an earlier state of the canister and could corrupt the current state of the canister. The current implementation of the IC allows canisters that are not stopped to be upgraded (with the assumption being that the canister developer has taken sufficient precautions to ensure the above mentioned corruption cannot happen).

== Loops in call graphs ==
The current implementation of the IC allows canisters to be called in a loop. For example, A can B, B can call C, and C can call A. There can be subtle issues when one attempts to do canister management in a loop though. If A sends a request (Req1) to B, while processing Req1 from A, B sends a StopCanister message to stop A, the canisters will effectively deadlock. When the StopCanister message is processed, A will be put in the Stopping state. It will only fully stop, when it has received a response for Req1. It will not receive a response for Req1 till B gets a response for its StopCanister message, and B will not get that response till A is stopped.

Current limitations of the Internet Computer

2021-11-22T10:55:43Z

Akhi:

Below we list the common set of limitations that anyone developing on top of the IC should be familiar with. The team hopes to be able to address these limitations in the future. In some cases, it is not clear what is the best way to address the limitations and further design discussions are needed.

== Bugs in pre_upgrade hooks ==
If there is a bug in your pre_upgrade hook that causes it to panic, then the canister can no longer be upgraded. This is because the pre_upgrade hook is part of the currently deployed wasm module and the system will always execute it before deploying the new wasm module and if the pre_upgrade hook fails, then the system will fail the whole upgrade.

Currently we do not have a good mitigation around this issue other than urging developers to make sure that their pre_upgrade is bug free by doing a lot of testing.

== Long running upgrades ==
Generally speaking, when a canister is being upgraded, the logic in the pre_upgrade hook serialises state from the wasm heap to stable memory and the logic in the post_upgrade hook deserialises it from stable memory back to wasm heap. There is an instructions bound on how long the upgrade process can run for. So it is possible that if the canister has too much state or the [de]serialising logic is not very efficient, then the whole process does not finish in time.

The recommended mitigation here is to ensure that the state that needs to be persisted across upgrades does not exceed what the canister can [de]serialise during the upgrade process.

== [de]serialiser requiring additional wasm memory==
Related issue in Motoko: GC: Reserve Wasm memory for upgrading canisters · Issue #2909 · dfinity/motoko · GitHub. Generally speaking, it is possible that the serialising logic requires some additional wasm heap to run. Let’s say that the canister has 3.5GiB of wasm heap and the serialising logic requires an additional 600MiB to serialise the data, given that the wasm heap is limited to 4GiB, the upgrade process will again fail. Note that this issue will also be present for canisters written in Rust.

The recommended mitigation here is to again ensure that the state that needs to be persisted across upgrades does not exceed what the canister can [de]serialise during the upgrade process.

== Only upgrading stopped canisters ==
Generally speaking, it is only safe to upgrade stopped canisters i.e. canisters that do not have any outstanding responses. This is because it is possible that the new wasm module will not be compatible with the response that refers to an earlier state of the canister and could corrupt the current state of the canister. The current implementation of the IC allows canisters that are not stopped to be upgraded (with the assumption being that the canister developer has taken sufficient precautions to ensure the above mentioned corruption cannot happen).

== Loops in the call graphs ==
The current implementation of the IC allows canisters to be called in a loop. For example, A can B, B can call C, and C can call A. There can be subtle issues when one attempts to do canister management in a loop though. If A sends a request (Req1) to B, while processing Req1 from A, B sends a StopCanister message to stop A, the canisters will effectively deadlock. When the StopCanister message is processed, A will be put in the Stopping state. It will only fully stop, when it has received a response for Req1. It will not receive a response for Req1 till B gets a response for its StopCanister message, and B will not get that response till A is stopped.

Current limitations of the Internet Computer

2021-11-22T10:42:48Z

Akhi: Created page with "Below we list the common set of limitations that anyone developing on top of the IC should be familiar with. The team hopes to be able to address these limitations in the fut..."

Best practices for a high traffic dapp launch

2021-11-17T08:33:41Z

Akhi: Start describing stress testing.

==Summary==

==Starting the project==

===Choosing a programming language===

====Motoko====

====Rust====

==Writing the dapp==

==Getting help==

There are few resources where developers get help while building a dapp:

* [https://forum.dfinity.org/ Developer forum]
* Developer Discord

==Testing the dapp==

=== Stress testing ===
The IC does not have a testnet. Instead developers are encouraged to use the mainnet for test purposes. Before developers deploy the production ready dapp to mainnet and enable access to it to the world, they should first deploy test versions to mainnet. They should then stress it by emulating the anticipated load on it and see how well the dapp and the platform in general fares. If the desired performance is not achieved, developers are encouraged to get help by using the links provided above. Often times, the desired performance can be achieved by performing minor tweaks to the dapps.

==Deploying the dapp==

==Launching the dapp to the world==

==Monitoring the dapp==

==Lessons from past launches==

# Use most recent Motoko version
Motoko is a language being actively developed so it is recommended to use the latest version of Motoko to get maximal stability and performance.