Beginner's Guide To Understanding NNS Proposal To Increase Canister Storage

What is the Network Nervous System (NNS)?

The Internet Computer is the world's first public blockchain with web-speed capacity, allowing smart contracts to safely deliver interactive web content precisely to the browsers of end-users. It extends the internet's ability to host smart contracts without any power limitations, turning it into a mass computer that expands the capabilities of creators and merchants worldwide. A key feature of the Internet Computer blockchain is the Network Nervous System (NNS), a disclosed algorithmic control system that controls the network and token economy. This enables DeFi and dapps, open internet services, and collaborative systems to operate at a hyper-scale.

The goal of the NNS is to allow a decentralized and harmless methodology to rule the internet computer network and to have absolute control over all qualities of the network.

4 GB Limit - Development Bottleneck

The Canister smart contract is limited to 4 GB of memory. There are a number of usage scenarios in which 4 GB of data is not enough, but the capacity of the current sub-networks (approx. 300 GB) is more than sufficient. These applications are now required to be split into a number of canisters, making it difficult to reconcile the data.

Most Development-Friendly Solution

If we allow canisters to increase their capacity to the capacity of an entire sub-network, it will make writing these applications more straightforward. Engineering manager Ahi Singhania suggests some upcoming configurations in the Internet computer, in which Canister smart contracts will be able to apply more than 4GB of memory up to the capacity of the entire subnet.

Memory has been designed with a 32-bit addressing scheme so that it can be swapped out with native Wasm functions over time. The 64-bit memory in Wasm makes some performance issues for the Internet Computer. Wasmtime can remove the limitations for 32-bit memory effectively. A similar optimization is unfeasible for 64-bit memory, which makes it more expensive. Not counting this, you must perform a tremendous amount of work to optimize the memory change before the implementation is ready.

Because implementing Memory64 in IC can take some time, and some canisters will need more memory right now, we recommend extending the sized API memory to 64-bit instead.

These are the risks in mixing canisters of 32-bit and 64-bit functions after the size memory exceeds 4GB. You can mitigate this risk somewhat by providing a trap for 32-bit functions so that the execution of the canister stops rather than prolongs and leads to the wrong result.

Alternatives

One alternative is to implement an entirely new 64-bit memory, separate from the existing 32-bit memory. But this is more of an unsophisticated design; it will complicate the canister update because the canisters will have to copy the current position from the 32-bit size memory into the 64-bit size memory.

The other option is to evaluate if the canister uses a 64-bit version for the API, then the implementation of any 32-bit API would lead to a trap. It would make it easier for the canister to detect tasks when switching between APIs, which could complicate the implementation.

The third option is to wait until the Memory64 and Multiple Memories are ready for production. During this time, sized memory can be represented as one of several 64-bit memories, eliminating the need for a new System API.

At present, canisters are practically limited to 4 GB memory size. This is because the size memory uses a 32-bit addressing scheme, and when a container is updated, its Wasm-memory is erased.

Many applications can benefit from access to additional memory without the need to partition it into several containers. The purpose of the proposal is to implement API memory that allows containers to operate with more than 4 GB of memory, limited [eventually] only by the actual size of the subnet.

Because the Memory64 proposal is not yet standardized, and its implementation in Wasmtime is not yet ready for production, this proposal allows for a performance boost by implementing a new API memory.

NNS Proposal ID - 18337

Significantly, the community controls all blockchain changes, and even DFINITY needs to submit a proposal, which will be implemented based on how ICP token holders vote on it.  Below is the proposal for increasing the memory from 4 GB to 300 GB subnet size.

Refer to the link for the progress  - NNS proposal

Resources

• Disclaimer: The views and opinions expressed on this website are solely those of the original author and other contributors. These views and opinions do not necessarily represent those of the Dfinity Community staff and/or any/all contributors to this site.