Decrease max_code_size on chain

[bkchr]

The max_code_size is currently set to 10MiB in Kusama and Polkadot. In the node we are currently assume that the MAX_CODE_SIZE is 3MiB.

As discussed with @eskimor on Tuesday, the max_code_size can not be bigger than the maximum block length/size of Polkadot itself. Otherwise we could not build a block that includes a parachain upgrade which code is bigger than the maximum block size.

We should check all the current active PVF and their size. I would propose we downgrade the max_code_size on Polkadot/Kusama to 4MiB or maybe 3MiB depending on what the biggest active PVF is.

CC @Sophia-Gold

[ggwpez]

I snug a change into #6271 since it already schedules a config upgrade in the runtime upgrade.
I will revert&cherry-pick it you are fine with the approach, as I dont want to hold up that MR any longer.

About the value: it was 4MiB previously, but i can do a sweep across the parachains to check the current max.

The migration output looks like this

Active HostConfig:

HostConfiguration {
    max_code_size: 10485760,
    max_head_data_size: 20480,
    max_upward_queue_count: 10,
    max_upward_queue_size: 51200,
    max_upward_message_size: 51200,
    max_upward_message_num_per_candidate: 10,
    hrmp_max_message_num_per_candidate: 10,
    validation_upgrade_cooldown: 14400,
    validation_upgrade_delay: 600,
    async_backing_params: AsyncBackingParams {
        max_candidate_depth: 0,
        allowed_ancestry_len: 0,
    },
    max_pov_size: 5242880,
    max_downward_message_size: 51200,
    hrmp_max_parachain_outbound_channels: 30,
    hrmp_max_parathread_outbound_channels: 0,
    hrmp_sender_deposit: 100000000000,
    hrmp_recipient_deposit: 100000000000,
    hrmp_channel_max_capacity: 1000,
    hrmp_channel_max_total_size: 102400,
    hrmp_max_parachain_inbound_channels: 30,
    hrmp_max_parathread_inbound_channels: 0,
    hrmp_channel_max_message_size: 102400,
    executor_params: ExecutorParams(
        [],
    ),
    code_retention_period: 14400,
    parathread_cores: 0,
    parathread_retries: 0,
    group_rotation_frequency: 10,
    chain_availability_period: 10,
    thread_availability_period: 10,
    scheduling_lookahead: 1,
    max_validators_per_core: Some(
        5,
    ),
    max_validators: Some(
        200,
    ),
    dispute_period: 6,
    dispute_post_conclusion_acceptance_period: 600,
    no_show_slots: 2,
    n_delay_tranches: 89,
    zeroth_delay_tranche_width: 0,
    needed_approvals: 30,
    relay_vrf_modulo_samples: 40,
    pvf_checking_enabled: true,
    pvf_voting_ttl: 2,
    minimum_validation_upgrade_delay: 20,
}
    
Apr 20 11:56:30.494  INFO runtime::configuration: Last pending HostConfig upgrade:

None
    
Apr 20 11:56:30.494  INFO runtime::configuration: post_upgrade    
Apr 20 11:56:30.494  INFO runtime::configuration: Last pending HostConfig upgrade:

Some(
    (
        6122,
        HostConfiguration {
            max_code_size: 4194304,
            max_head_data_size: 20480,
            max_upward_queue_count: 209715,
            max_upward_queue_size: 1048576,
            max_upward_message_size: 65531,
            max_upward_message_num_per_candidate: 16,
            hrmp_max_message_num_per_candidate: 10,
            validation_upgrade_cooldown: 14400,
            validation_upgrade_delay: 600,
            async_backing_params: AsyncBackingParams {
                max_candidate_depth: 0,
                allowed_ancestry_len: 0,
            },
            max_pov_size: 5242880,
            max_downward_message_size: 51200,
            hrmp_max_parachain_outbound_channels: 30,
            hrmp_max_parathread_outbound_channels: 0,
            hrmp_sender_deposit: 100000000000,
            hrmp_recipient_deposit: 100000000000,
            hrmp_channel_max_capacity: 1000,
            hrmp_channel_max_total_size: 102400,
            hrmp_max_parachain_inbound_channels: 30,
            hrmp_max_parathread_inbound_channels: 0,
            hrmp_channel_max_message_size: 102400,
            executor_params: ExecutorParams(
                [],
            ),
            code_retention_period: 14400,
            parathread_cores: 0,
            parathread_retries: 0,
            group_rotation_frequency: 10,
            chain_availability_period: 10,
            thread_availability_period: 10,
            scheduling_lookahead: 1,
            max_validators_per_core: Some(
                5,
            ),
            max_validators: Some(
                200,
            ),
            dispute_period: 6,
            dispute_post_conclusion_acceptance_period: 600,
            no_show_slots: 2,
            n_delay_tranches: 89,
            zeroth_delay_tranche_width: 0,
            needed_approvals: 30,
            relay_vrf_modulo_samples: 40,
            pvf_checking_enabled: true,
            pvf_voting_ttl: 2,
            minimum_validation_upgrade_delay: 20,
        },
    ),
)
    
Apr 20 11:56:30.494  INFO runtime::configuration: Checking config s=6122    
Apr 20 11:56:30.494 ERROR runtime::configuration: The ActiveConfig is inconsistent: MaxCodeSizeExceedHardLimit { max_code_size: 10485760 }. We tolerate this since there are pending consistent upgrades.

[ggwpez]

3 MiB would also be fine it seems, although the previous was 4. Current max across all paras is 1.70MiB. We should probably announce this in the Forum before proceeding.

Parachain Code Size

Relay	Para Name	Code Size [Byte]
kusama	Picasso	1780294
kusama	Genshiro	1728386
kusama	Genshiro crowdloan 2	1728386
kusama	Amplitude	1643834
kusama	Bifrost	1627241
polkadot	Composable Finance	1573213
kusama	Moonriver	1546666
kusama	Shiden	1489435
kusama	Karura	1482184
kusama	Parallel Heiko	1475447
polkadot	Acala	1474313
polkadot	Moonbeam	1469681
polkadot	Parallel	1462944
polkadot	Astar	1460806
kusama	Kintsugi BTC	1406672
polkadot	Bifrost	1402592
polkadot	Pendulum	1373998
kusama	Khala Network	1335992
polkadot	Clover	1318401
kusama	Darwinia Crab	1309678
polkadot	Phala Network	1293185
polkadot	Equilibrium	1281831
kusama	QUARTZ by UNIQUE	1202716
polkadot	Interlay	1173411
polkadot	Nodle	1151341
kusama	Altair	1134774
polkadot	Efinity	1121310
polkadot	Unique Network	1118146
polkadot	HydraDX	1105514
polkadot	Litentry	1094670
kusama	Mangata	1093053
kusama	Basilisk	1082842
kusama	subzero	1071064
polkadot	Bitgreen	1061442
polkadot	Zeitgeist	1057255
kusama	Tanganika	1031284
polkadot	Watr Network	1009246
polkadot	Centrifuge	1003614
polkadot	Hashed Network	992974
kusama	Crust Shadow	983685
polkadot	Aventus	980858
kusama	Turing Network	978139
polkadot	KILT Spiritnet	977736
polkadot	Crust	952317
kusama	Pichiu	936112
kusama	Bajun Network	917254
polkadot	OriginTrail	848760
kusama	Integritee Network	835723
kusama	InvArch Tinkernet	818355
kusama	DAO IPCI	809456
kusama	Robonomics	807109
kusama	Robonomics 2	807109
polkadot	Manta	771372
kusama	Dora Factory	762242
polkadot	Subsocial	752136
polkadot	Kylin	728780
kusama	Kabocha	720578
kusama	GM	711752
polkadot	t3rn	644599
polkadot	Kapex	633529
polkadot	Darwinia	600779
polkadot	Ajuna Network	582751
polkadot	Frequency	540935
kusama	SORA	516993
polkadot	Integritee Shell	412227
polkadot	Ares Odyssey	0
polkadot	Coinversation	0
polkadot	Darwinia Backup	0
polkadot	Geminis	0
polkadot	InvArch	0
polkadot	OAK Network	0
polkadot	OmniBTC	0
polkadot	peaq	0
polkadot	Polkadex	0
polkadot	SORA	0
polkadot	SubDAO	0
polkadot	SubGame Gamma	0
kusama	Aband	0
kusama	Bit.Country Pioneer	0
kusama	Calamari	0
kusama	Crust Shadow 2	0
kusama	Imbue Network	0
kusama	KICO	0
kusama	KICO 2	0
kusama	Kpron	0
kusama	Krest	0
kusama	Listen Network	0
kusama	Litmus	0
kusama	Loom Network	0
kusama	Mars	0
kusama	Parallel Heiko 2	0
kusama	PolkaSmith by PolkaFoundry	0
kusama	RioDeFi	0
kusama	Sakura	0
kusama	Shiden Crowdloan 2	0
kusama	SNOW Network	0
kusama	SubGame Gamma	0
kusama	SubsocialX	0
kusama	TrustBase	0
kusama	Unorthodox	0

(Chains with 0 could not be contacted. Either dead RPC or already off-boarded.)

[Sophia-Gold]

Would you like me to make a Polkadot forum post about this? It seems pretty straightforward.

[bkchr]

About the value: it was 4MiB previously, but i can do a sweep across the parachains to check the current max.

What you mean by previously?

Would you like me to make a Polkadot forum post about this? It seems pretty straightforward.

Not sure we need a forum post for this, mainly requires a governance proposal to set the value. IMO that should be enough.

[ggwpez]

About the value: it was 4MiB previously, but i can do a sweep across the parachains to check the current max.

What you mean by previously?

Ah nvm. I was a local change of mine 🤦‍♂️

Not sure we need a forum post for this, mainly requires a governance proposal to set the value. IMO that should be enough.

Just wanted to ensure that all the para-chain teams see it - just in case that they have a pending upgrade that would get invalidated. But a proposal should probably be enough.

Can we still get feedback from the @paritytech/parachains-core team on this?

[bkchr]

Just wanted to ensure that all the para-chain teams see it - just in case that they have a pending upgrade that would get invalidated. But a proposal should probably be enough.

Ahh yeah, good point. Anything above 5MiB would lead to issues right now any way.

[Sophia-Gold]

Can we still get feedback from the @paritytech/parachains-core team on this?

We (@eskimor and I) are already tagged here :)

[eskimor]

The 3MB limit is also enforced at the network level. Hence any runtime upgrade greater than 3MB could hardly make it anyway already. (It could technically if the backing validator is the block producer at the same time.)

[ggwpez]

Proposal is here https://kusama.polkassembly.io/referenda/173

[ggwpez]

Kusama executed successfully.

For Polkadot we can probably wait til OpenGov, to not block the current Referendum queue since it is not time-critical.

[shawntabrizi]

As discussed with @eskimor on Tuesday, the max_code_size can not be bigger than the maximum block length/size of Polkadot itself.

I have always imagined some extrinsic which would append data to some storage over multiple blocks, allowing some single file stored on chain greater than the block limit.

In this case, a chain could make multiple upload extrinsics to the preimage pallet, and then trigger an upgrade from the larger file, bypassing the per-block limit.

[ggwpez]

I have always imagined some extrinsic which would append data to some storage over multiple blocks, allowing some single file stored on chain greater than the block limit.
In this case, a chain could make multiple upload extrinsics to the preimage pallet, and then trigger an upgrade from the larger file, bypassing the per-block limit.

I think we can do this simply with sp_io::storage::append. But the problem is that once the preimage is uploaded, we need to move it to storage key :code:. And we dont have a "move data from one storage key to another" host call. So instead we have to read+write the value, thereby bringing it into the proof…

We could also try to change the format of the proof, to kind of do a matching against known values. Then it could realize that the written data is actually already in storage and can reference it instead of copying. But that would require some reverse lookup from value->key, or some matching of read+write ops. Sounds very hacky.

[shawntabrizi]

In this case, the limit is not the block size, but the PoV size.

For large items in PoV, we have this issue open which can solve that also using the preimage pallet: paritytech/polkadot-sdk#811

Yes, some engineering required, but I don't see a fundamental limitation here yet.

[ggwpez]

Polkadot proposal is here https://polkadot.polkassembly.io/referenda/9
Westend was done manually by devops Sudo.
Rococo is fine at 3 MiB.

[ggwpez]

Polkadot executed https://polkadot.subsquare.io/referenda/referendum/9 successfully.