@roman-kashitsyn I’m working on Kybra, a Python CDK, and unfortunately I just ran into the Wasm binary size limit again, even with gzip. When I include the stdlib for Python using the RustPython VM, the binary after optimization and gzipping is ~10mb and it gets rejected. I hope I can get around this by optimizing somehow, but here I am reaching the limit again as I’m trying to implement the same tech we have on Web2.
4 Likes
I believe the next step will be implementing a chunking protocol for the canister module installation. I created an IC feature for that in May, but there has been a lot of more urgent stuff on the execution’s team plate (DTS & scheduling, firefighting & squeezing perf, bitcoin integration, etc.).
5 Likes
I have being using ss uploader:
It creates chunks of the wasm module, works very well!
3 Likes
You’re able to initialize a canister with this? How large can the Wasm binary be? My understanding is that there’s still a ~10mb limit if you chunk the Wasm, is this true?
Is there a public ticket/issue that we can follow? And FYI if the limit can be increased significantly it would unlock a major blocker for Kybra, which is allowing the inclusion of the entire Python stdlib: stdlib · Issue #12 · demergent-labs/kybra · GitHub
1 Like
@roman-kashitsyn Is it true that there is a 10mb limit on cross-canister messages? Could you then install a canister with a Wasm binary up to 10mb in size if you first chunked the Wasm binary into a canister, and used that canister to call install on the management canister?
I thought I read this somewhere in the past, but I’m having a hard time finding that information.
1 Like
Currently, the inter-canister message limit within a single subnet is 10 MiB, while the limit on messages between subnets is 2 MiB.
This setup is very problematic because it breaks the transparency of XNet communication. Generally, canisters should not care about the destination’s subnet when they make the call, except for this difference in max message size. This difference also blocks subnets splitting work: separating canisters can break people’s code because they might be sending large payloads, and separating them will break the code.
I’m having a hard time finding that information.
Yes, the size difference is not documented anywhere, mainly because it’s a horrible hack that we don’t want people to use. I’m not sure why we raised the limit for inter-canister messages in the first place, my hunch is that someone really wanted to install a large canister 
6 Likes
Sory for the late message. The code I have mentioned create chunks so you can upload a large wasm file.
So the small Wasm binary limit is causing a lot of problems for Azle and Kybra, as documented and actively discussed here: Allow installation of large Wasm modules
We’re starting to explore an interim solution beyond Wasm binary optimization and gzipping, as that is no longer enough in all use cases we have come across. The only remaining solution before the protocol-level Wasm binary limit lift seems to be to chunk upload to an intermediate canister, and have that canister install the Wasm binary to the destination canister.
Currently, the inter-canister message limit within a single subnet is 10 MiB, while the limit on messages between subnets is 2 MiB.
My question is if this “hack” will hold until the Wasm binary limit can be lifted. Can we depend on this and introduce this as part of the official Azle/Kybra deploy process?
Also, how can I ensure that the intermediate canister and the destination canister are deployed into the same subnet? If they’re not, then this hack cannot be used as the 10MiB limit would be reduced to 2MiB for a cross-subnet call.
Perhaps this is the answer to ensuring subsequent canisters are deployed to the same subnet? Each canister deployed from the same cycles wallet is automatically deployed to the same subnet? Could we deploy a canister on a specified subnet? - #4 by alexa.smith
That’s correct. Every canister created through the management canister (as opposed to the CMC flow that uses ICP, not cycles) is created on the same subnet as the calling canister. This is the mechanism the cycles wallet uses. It doesn’t have any special permissions to achieve this.
I’m not sure what happens if the subnet is full, but I don’t expect that to be a problem
1 Like
Wait does the limit not include gzipping? I have a canister that is ~13MiB uncompressed, ~3MiB compressed but when installing from the intermediate canister using install_code I’m getting an error that it’s over the 10MiB limit.
I would think that a ~3MiB Wasm binary passed into install _code wouldn’t trigger the 10MiB limit…
That sounds really weird. I’ll ask the team about it.
Aside: Are you accidentally trying to install the non-gzipped one? That sounds like a mistake I could make…
1 Like
There’s an additional 10MiB limit for the Wasm module at the runtime level. You’re not hitting the inter-canister call limit here.
3 Likes