dfinity · derlerd-dfinity · Nov 19, 2024 · Nov 8, 2024 · Nov 8, 2024 · Nov 11, 2024
@@ -14,7 +14,7 @@ image: /img/blog/async-performance-counter.webp
 
 ## Background
 
-The Internet Computer can host a full dapp — frontend, backend and data. Users can deploy their dapp as a canister (smart contract) on the Internet Computer. Each canister can store up to 400 GB of data and execute up to 20 Billion WebAssembly instructions per transaction.
+The Internet Computer can host a full dapp — frontend, backend and data. Users can deploy their dapp as a canister (smart contract) on the Internet Computer. Each canister can store up to 500GiB of data and execute up to 40 Billion WebAssembly instructions per transaction.
 
 Unlike other blockchains, the Internet Computer offers developers [enormous amounts of resources](/docs/current/developer-docs/smart-contracts/maintain/resource-limits). This poses a real challenge for canister developers: writing efficient canister code. The more efficient a canister is, the less cycles it pays.
 

@@ -46,7 +46,7 @@ An alternative to running the model onchain would be to download the model from
 
 A disadvantage of this workflow is that the model needs to be downloaded to the user's device, resulting in less confidentiality of the model and decreased user experience due to increased latency.
 
-ICP supports this workflow for most existing models because a smart contract on ICP can store models up to 400GiB.
+ICP supports this workflow for most existing models because a smart contract on ICP can store models up to 500GiB.
 
 ### Examples
 

@@ -32,7 +32,7 @@ This assumes that the model was trained off-chain and then uploaded onchain.
 Inference happens on the user's device after downloading the model.
 If the user trusts their own device, then they can trust that the inference ran correctly.
 A disadvantage here is that the model needs to be downloaded to the user's device with corresponding drawbacks of less confidentiality of the model and decreased user experience due to increased latency.
-ICP supports this use case for practically all existing models because a smart contract on ICP can store models up to 400GiB.
+ICP supports this use case for practically all existing models because a smart contract on ICP can store models up to 500GiB.
 See [an example](https://github.com/patnorris/DecentralizedAIonIC) of an in-browser AI chatbot that uses an open-source LLM model served from ICP.
 
 4. **Tokenization, marketplaces, orchestration**:

@@ -23,7 +23,7 @@ When a canister needs to be upgraded, the following workflow is used:
 
 ### Versioning stable memory
 
-Stable memory is a data persistence feature on ICP. Stable memory is used to store data that persists across canister upgrades. The maximum data storage size of stable memory is 400 GiB if the subnet can accommodate it.
+Stable memory is a data persistence feature on ICP. Stable memory is used to store data that persists across canister upgrades. The maximum data storage size of stable memory is 500GiB if the subnet can accommodate it.
 
 In comparison, heap memory (also referred to as "main memory") refers to the regular Wasm data storage for a canister. Heap memory is not persisted across canister upgrades and is limited to 4GiB.
 

@@ -133,7 +133,7 @@ These operations reserve some cycles by moving them from the main balance of the
 The amount of reserved cycles depends on how many bytes are allocated and on the current subnet usage.
 
 - If subnet usage is below `450GiB`, then the amount of reserved cycles per allocated byte is `0`.
-- If subnet usage is above `450GiB`, then the amount of reserved cycles per allocated byte grows linearly depending on the subnet usage, from `0` to `10` years worth of storage payments at the subnet capacity (which is currently `750GiB`).
+- If subnet usage is above `450GiB`, then the amount of reserved cycles per allocated byte grows linearly depending on the subnet usage, from `0` to `10` years worth of storage payments at the subnet capacity (which is currently `1TiB`).
 
 A controller of a canister can disable resource reservation by setting the `reserved_cycles_limit=0` in canister settings.
 Such opted-out canisters would not be able to allocate if the subnet usage is above `450GiB`.

@@ -300,7 +300,7 @@ Currently, subnets contain between 13 and 40 nodes, and most of them are geograp
 <tr>
   <td> Memory size </td>
   <td> Few KB </td>
-  <td> 404GiB (4GiB Wasm memory + 400GiB of stable memory) </td>
+  <td> 504GiB (4GiB Wasm memory + 500GiB of stable memory) </td>
 </tr>
 
 <tr>

@@ -34,7 +34,7 @@ Chain Fusion allows to build more powerful dapps combining non-ICP smart
 contracts with the decentralized compute power of ICP.
 
 - **Storage**: Using a competitive pricing model, a single smart contract on ICP
-offers up to 400GiB of storage, enabling all application data to be stored
+offers up to 500GiB of storage, enabling all application data to be stored
 onchain. Through Chain Fusion, these decentralized storage capacities are
 made available to non-ICP dapps.
 

@@ -14,11 +14,11 @@ There are two forms of storage available to ICP canisters: **heap memory** and *
 
 **Heap memory** is a canister's Wasm memory. This memory does not store data long-term. The heap memory is cleared each time a canister is upgraded. Heap memory is limited to 4GiB. It is used by default for data such as variable values, arguments passed to a canister, and the result of a method's execution.
 
-**Stable memory** is a secondary storage type that is used to store data long-term. Stable memory data is persisted throughout the canister's lifetime, including canister upgrades. Stable memory is limited to 400GiB. To use stable memory, you must anticipate which data you want to persist across different canister processes and states.
+**Stable memory** is a secondary storage type that is used to store data long-term. Stable memory data is persisted throughout the canister's lifetime, including canister upgrades. Stable memory is limited to 500GiB. To use stable memory, you must anticipate which data you want to persist across different canister processes and states.
 
 | Memory feature | Heap memory | Stable memory |
 |----------------|-------------|---------------|
-|Storage capacity| 4GiB        | 400GiB        |
+|Storage capacity| 4GiB        | 500GiB        |
 |Intended use    | Small datasets, frequently accessed data, temporary data | Large datasets, infrequently accessed data, important data that must persist |
 |Persistence     | Does not persist across upgrades | Data is preserved and persists across upgrades |
 |Performance     | Fast read/write operations | Slightly decreased read/write operations |
@@ -37,7 +37,7 @@ Heap data is better suited to be used for small data sets (under 4GiB) or data t
 
 ### Recommendation: Use stable memory for large datasets.
 
-Stable memory should be used for large data sets (More than 4GiB but less than 400GiB) or data that is infrequently accessed.
+Stable memory should be used for large data sets (More than 4GiB but less than 500GiB) or data that is infrequently accessed.
 
 Ultimately, the form of memory you choose to utilize for your canister will depend on the most optimal workflow for your project.
 
@@ -38,13 +38,13 @@ The limits depend on the message type as shown in the following table.
 
 | <Tooltip text="A collection of nodes that run their own instance of the ICP consensus algorithm.">Subnet</Tooltip> limits                                                                        | Constraint  |
 | ------------------------------------------------------------------------------------ | ----------- |
-| Subnet capacity (total memory available per subnet)                                  | 700GiB      |
+| Subnet capacity (total memory available per subnet)                                  | 1TiB        |
 | Maximum number of snapshot per canister                                              | 1           |
 
 | Memory resource limits                                                               | Constraint  |
 | ------------------------------------------------------------------------------------ | ----------- |
 | Wasm heap memory, per canister                                                       | 4GiB        |
-| Wasm stable memory, per canister                                                     | 400GiB      |
+| Wasm stable memory, per canister                                                     | 500GiB      |
 | Wasm stable memory, data access per replicated message                               | 2GiB        |
 | Wasm stable memory, data written per replicated message                              | 2GiB        |
 | Wasm stable memory, data access per upgrade message                                  | 8GiB        |

@@ -27,7 +27,7 @@ Stable memory is a feature unique to the Internet Computer Protocol that provide
 
 To use stable memory, you must anticipate which portions of the canister's data you want to persist across upgrades by indicating this within the canister code. More information about this can be found in the section below, [Storage handling in different languages](#storage-handling-in-different-languages).
 
-By default, a canister's stable memory is empty. The maximum storage limit for stable memory is 400GiB if the <GlossaryTooltip>subnet</GlossaryTooltip> the canister is deployed on can accommodate it. If a canister uses more than 400GiB of stable memory, the canister will trap and become unrecoverable.
+By default, a canister's stable memory is empty. The maximum storage limit for stable memory is 500GiB if the <GlossaryTooltip>subnet</GlossaryTooltip> the canister is deployed on can accommodate it. If a canister uses more than 500GiB of stable memory, the canister will trap and become unrecoverable.
 
 ## Storage cost
 

@@ -22,13 +22,13 @@ import { GlossaryTooltip } from "/src/components/Tooltip/GlossaryTooltip";
 
 The Internet Computer handles persistent data storage using a feature known as **stable memory**. **Stable memory** is a unique feature of the Internet Computer that defines a data store separate from the <GlossaryTooltip>canister</GlossaryTooltip>'s regular Wasm memory data store, which is known as **heap memory**. A canister's heap memory is not persistent storage and does not persist across canister upgrades; canister data and state stored in heap memory is removed when a canister is upgraded or reinstalled. For immutable canisters that use less than the heap memory limit of 4GiB, heap memory can be used. For larger canisters, and especially those that intend to be upgraded and changed over time, stable memory is important since it persists across canister upgrades, has a much larger storage capacity than heap memory, and is very beneficial for vertically scaling a dapp.
 
-To use stable memory requires anticipating and indicating which canister data you want to be retained after a canister upgrade. For some canisters, this data might be all of the canister's data, while for others it may be only certain parts or none. By default, stable memory starts empty, and can hold up to 400GiB as long as the <GlossaryTooltip>subnet</GlossaryTooltip> the canister is running on has the available space. If a canister uses more stable memory than 400GiB, the canister will trap and become unrecoverable.
+To use stable memory requires anticipating and indicating which canister data you want to be retained after a canister upgrade. For some canisters, this data might be all of the canister's data, while for others it may be only certain parts or none. By default, stable memory starts empty, and can hold up to 500GiB as long as the <GlossaryTooltip>subnet</GlossaryTooltip> the canister is running on has the available space. If a canister uses more stable memory than 500GiB, the canister will trap and become unrecoverable.
 
 ## Memory types and terms
 
 There are several terms associated with memory and storage on ICP. To avoid confusion between them, let's define them here.
 
-- **Stable memory:** Stable memory refers to the Internet Computer's long-term data storage feature. Stable memory is not language specific, and can be utilized by canisters written in Motoko, Rust, or any other language. Stable memory can hold up to 400GiB if the subnet can accommodate it.
+- **Stable memory:** Stable memory refers to the Internet Computer's long-term data storage feature. Stable memory is not language specific, and can be utilized by canisters written in Motoko, Rust, or any other language. Stable memory can hold up to 500GiB if the subnet can accommodate it.
 
 - **Heap memory:** Heap memory refers to the regular Wasm memory data store for each canister. This storage is temporary and is not persisted across canister upgrades. Data stored in heap memory is removed when the canister is upgraded or reinstalled. Heap memory is limited to 4GiB.
 

@@ -254,7 +254,7 @@ You can learn more about upgrading canisters in the documentation [here](/docs/c
 
 ### Stable memory
 
-Stable memory on ICP is a long-term data storage feature that can be utilized by canisters written in any language. Stable memory can hold up to 400GiB of data if the subnet the canister is deployed on can accommodate it. When a canister is upgraded, stable memory is not cleared, and anything stored in the canister's stable memory is persisted across the upgrade.
+Stable memory on ICP is a long-term data storage feature that can be utilized by canisters written in any language. Stable memory can hold up to 500GiB of data if the subnet the canister is deployed on can accommodate it. When a canister is upgraded, stable memory is not cleared, and anything stored in the canister's stable memory is persisted across the upgrade.
 
 In contrast to stable memory, heap storage refers to the regular Wasm data storage for a canister. Heap storage is temporary and does not persist across canister upgrades. When a canister is upgraded or reinstalled, the heap storage is cleared. Heap storage is limited to 4GiB.
 

@@ -7,7 +7,7 @@ slug: smart-contracts-serve-the-web
 
 # Smart Contracts serve the web
 
-The Internet Computer is the only blockchain that can host a full dapp – frontend, backend and data. Any user can deploy their dapp as a canister (smart contract) on the Internet Computer. Canisters are computational units that bundle together code and state. Canisters can store data, deliver HTML, CSS and Javascript pages, and answer API requests. Canisters are incredibly fast and can deliver webpages within 200ms. Canisters can store up to 400 GB of data at an incredibly low cost ($5 per GB per annum). Browsing dapps hosted on the Internet Computer is as seamless as browsing Web2 apps hosted on cloud. All these factors enable developers to deploy even large-scale social media applications entirely onchain without needing any cloud services. Try out a few [dapps deployed on the Internet Computer](https://internetcomputer.org/ecosystem/).
+The Internet Computer is the only blockchain that can host a full dapp – frontend, backend and data. Any user can deploy their dapp as a canister (smart contract) on the Internet Computer. Canisters are computational units that bundle together code and state. Canisters can store data, deliver HTML, CSS and Javascript pages, and answer API requests. Canisters are incredibly fast and can deliver webpages within 200ms. Canisters can store up to 500GiB of data at an incredibly low cost ($5 per GB per annum). Browsing dapps hosted on the Internet Computer is as seamless as browsing Web2 apps hosted on cloud. All these factors enable developers to deploy even large-scale social media applications entirely onchain without needing any cloud services. Try out a few [dapps deployed on the Internet Computer](https://internetcomputer.org/ecosystem/).
 
 ## Workflow
 

@@ -55,7 +55,7 @@ const trustCards = [
     imageAlt: "Scalability icon",
     title: "Scalable",
     description:
-      "ICP aims to give smart contracts near native performance and scalability. Currently, smart contracts can execute billions of instructions per message and use 4GiB of the main memory and 400GiB of stable memory. The future vision is to give smart contracts access to AI hardware such as GPUs.",
+      "ICP aims to give smart contracts near native performance and scalability. Currently, smart contracts can execute billions of instructions per message and use 4GiB of the main memory and 500GiB of stable memory. The future vision is to give smart contracts access to AI hardware such as GPUs.",
   },
   {
     imageSrc: "/img/decentralized-ai/trust-icon-5.svg",