Why is the Rococo `maxCodeSize` too small to do adequate incremental runtime upgrades? [closed]

Question

If we want to connect a parachain to Rococo's 'rococo-local' relay chain we follow this Cumulus tutorial using polkadot-launch. Part of the pre-launch steps mentioned here is to minimize your runtime size by pruning the functionality, and to then do incremental upgrades using the generated /target/release/wbuild/parachain-template-runtime.compact.wasm file when the parachain is live to include the missing pallets again.

However, Rococo's relay chain currently has a maxCodeSize of only ~3.15 MB, and if you build the substrate-parachain-template using branch 'polkadot_v0.9.17' with cargo build --release it generates that file parachain-template-runtime.compact.wasm that is ~2.9 MB. If you add the Sudo pallet to it so you can do the incremental upgrades then building it generates an even larger file of ~3.0 MB, which may not allow enough space for you to do the incremental upgrades to include the missing pallets again during your launch simulation on the Rococo production testnet before launching on Kusama's production mainnet.

If you add more pallets than just Sudo and the Scheduler pallet by following Substrate's Forkless Upgrades tutorial then you might exceed the maxCodeSize and Polkadot.js Apps may generate an error Bytes:: Maximum call stack size exceeded or Invalid Transaction: Transaction would exhaust the block limits that prevents the runtime upgrade.

Meanwhile, Kusama's relay chain currently has a larger maxCodeSize of ~10.5 MB, which may be sufficient to include all your pallets. There would be a requirement for an initial 3.0 MB for the genesis build of substrate-parachain-template branch 'polkadot_v0.9.17' (plus Sudo pallet to allow you to perform runtime upgrades), then a further 1.5 MB for the 1st runtime upgrade to add ~15 pallets like preimage, scheduler, democracy, referenda, conviction voting, council collective, technical collective, elections phragmen, tips, treasury, bounties, child bounties, assets, multisig, identity, proxy, and recovery, and then a further 1.5 MB for a 2nd runtime upgrade to add ~25 of our own custom pallets to increase it a total code size of the parachain-template-runtime.compact.wasm file to ~6 MB, which would still be less than Kusama's maxCodeSize.

Note that Chachacha relay chain is alternative production testnet for parachains. But that does not provide an alternative, as it also has the same maxCodeSize of as Rococo of ~3.15 MB when you query it here with Polkadot.js Apps by choosing "Developer > Chain state > Storage > configuration (for "selected state query") > activeConfig()" and then clicking the (+) icon.

Question: If Rococo's maxCodeSize only allows you to make some small runtime upgrades, but isn't large enough for you to add all your missing pallets when your parachain is live on it as incremental upgrades after pruning them all to minimize the runtime size for genesis, should you just assume that the remaining runtime upgrades will work on Kusama and proceed to doing it on Kusama instead?

Answer 1

Generally, you should use the x_runtime.compact.compressed.wasm which is about a factor of 3 smaller than the compact wasm. This runtime is compressed with zlib and the node knows to decompress it before execution. Using the compressed Wasm saves space on-chain and over the network.

As for Rococo configuration, that's something that'd be up to the Parity team in charge of the testnet.