By default, when opening an HRMP channel, the number of pending messages that can be queued on the relay chain for the channel is the one defined in the active host configuration (HostConfiguration::hrmp_channel_max_capacity).
The current value is 1000 and this referenda proposes to reduce it to 25.
A sending parachain can push at most 1 HRMP message to the relay chain per block while the receiving parachain processes all the pending messages at once. When the limit of pending messages is reached, the sending parachain can't forward any more HRMP message to the relay chain, having to queue them locally. The local queue also has a backpressure mechanism. Even if the receiving parachain has a delay of a couple of blocks in processing the pending messages, 25 pending messages should be enough for everything to work smoothly.
And if we're in a corner case where the receiving parachain is stalled, it's best to not have a lot of pending HRMP messages on the relay chain, since this will increase the load on the receiving parachain when it recovers.
The new limit will apply only to newly opened channels. This will not impact the channels that are already opened, which will keep the old limit.
Also this is just the default limit and it will apply to the channels opened via establish_channel_with_system for example. If a bigger limit is needed for an HRMP channel, there are extrinsics that can be used for setting a custom limit.
Whitelisting referenda: https://collectives.subsquare.io/fellowship/referenda/396
By default, when opening an HRMP channel, the number of pending messages that can be queued on the relay chain for the channel is the one defined in the active host configuration (HostConfiguration::hrmp_channel_max_capacity).
The current value is 1000 and this referenda proposes to reduce it to 25.
A sending parachain can push at most 1 HRMP message to the relay chain per block while the receiving parachain processes all the pending messages at once. When the limit of pending messages is reached, the sending parachain can't forward any more HRMP message to the relay chain, having to queue them locally. The local queue also has a backpressure mechanism. Even if the receiving parachain has a delay of a couple of blocks in processing the pending messages, 25 pending messages should be enough for everything to work smoothly.
And if we're in a corner case where the receiving parachain is stalled, it's best to not have a lot of pending HRMP messages on the relay chain, since this will increase the load on the receiving parachain when it recovers.
The new limit will apply only to newly opened channels. This will not impact the channels that are already opened, which will keep the old limit.
Also this is just the default limit and it will apply to the channels opened via establish_channel_with_system for example. If a bigger limit is needed for an HRMP channel, there are extrinsics that can be used for setting a custom limit.
Whitelisting referenda: https://collectives.subsquare.io/fellowship/referenda/396