Exceeding ICP Canister Storage Limits

Developers Programs & Applications
1

Currently ICP canister has 8 GB limit for stable memory and 4 GB heap limit. Since our audit and verification canister keep growing, there is a possibility of exceeding these limits.

We created a static principal controller and managed per day sub canisters using that. Those sub canisters are owned by the principal canister. The issue is we cannot upgrade the sub canisters owned by the principal canister with a new change (fields to the data model).

We found 3 ways to overcome it:

  1. Remove static principal controller, create multiple canisters for each day, and manage the mapping from our side database
    Cons - we need to manage all the canisters manually

  2. Maintain versioning at the principal container for each sub canisters, and without upgrading old sub canisters use updated smart contract only for newly create sub-canisters
    Cons - No backward compatibility

  3. Create a new instance of the new sub-canister and write a function to get a copy of data from the previous canister and copy that data to the newly create-canister
    Cons - High data transfers and processing on ICP, will increase the ICP cost

Any ideas and thoughts how to ensure future scalability in the most efficient way? Is there any other way?

4 Likes
2
  1. The Internet Computer Interface Specification :: Internet Computer

Internet Computer | Documentation

install_code : (record { mode : variant {install; reinstall; upgrade};

got the response from discord someone asked, but didn’t try it.

3 Likes
3

@bytesun is correct. Your principal canister actually can upgrade the sub canisters by sending messages to the IC management canister. You’ll first want to make sure the canister is stopped (using stop_canister and canister_status), and then do the upgrade with install_code.

6 Likes
4

@bytesun @abk thank you very much.

stop_canister and canister_status work fine with the IC management canister. But in the install_code method, we have to include wasm_module (web assembly file I guess) as a parameter.

Do you know how to attach that file to a Motoko canister as wasm_module?
Thank you again for your help.

1 Like
5

Yes the wasm_module argument is a blob containing the wasm code you want to install on the canister. Since you’re doing the upgrade from your controlling canister, it will need to get that wasm code somehow. So you’ll have to have some method on your controlling canister that lets you upload wasm code. Does that make sense?

6

I’m guessing you’ll have to serialize the compiled wasm module into a candid blob (perhaps using agent-rs?) that you’ll then need to pass as an argument when calling that “upload” method on your controlling canister. Probably need your own bash script for this…

2 Likes
7

I think this might help.

7 Likes
8

@abk @jzxchiang @paulyoung thank you for your help and suggestions, very much appreciated.

2 Likes