[HRMP] Make max_message_size adjustable
#3145
Comments
|
Would those be XCM instructions? |
github-merge-queue bot
pushed a commit
that referenced
this issue
May 16, 2024
Re-applying #2302 after increasing the `MaxPageSize`. Remove `without_storage_info` from the XCMP queue pallet. Part of #323 Changes: - Limit the number of messages and signals a HRMP channel can have at most. - Limit the number of HRML channels. A No-OP migration is put in place to ensure that all `BoundedVec`s still decode and not truncate after upgrade. The storage version is thereby bumped to 5 to have our tooling remind us to deploy that migration. ## Integration If you see this error in your try-runtime-cli: ```pre Max message size for channel is too large. This means that the V5 migration can be front-run and an attacker could place a large message just right before the migration to make other messages un-decodable. Please either increase `MaxPageSize` or decrease the `max_message_size` for this channel. Channel max: 102400, MaxPageSize: 65535 ``` Then increase the `MaxPageSize` of the `cumulus_pallet_xcmp_queue` to something like this: ```rust type MaxPageSize = ConstU32<{ 103 * 1024 }>; ``` There is currently no easy way for on-chain governance to adjust the HRMP max message size of all channels, but it could be done: #3145. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]>
hitchhooker
pushed a commit
to ibp-network/polkadot-sdk
that referenced
this issue
Jun 5, 2024
Re-applying paritytech#2302 after increasing the `MaxPageSize`. Remove `without_storage_info` from the XCMP queue pallet. Part of paritytech#323 Changes: - Limit the number of messages and signals a HRMP channel can have at most. - Limit the number of HRML channels. A No-OP migration is put in place to ensure that all `BoundedVec`s still decode and not truncate after upgrade. The storage version is thereby bumped to 5 to have our tooling remind us to deploy that migration. ## Integration If you see this error in your try-runtime-cli: ```pre Max message size for channel is too large. This means that the V5 migration can be front-run and an attacker could place a large message just right before the migration to make other messages un-decodable. Please either increase `MaxPageSize` or decrease the `max_message_size` for this channel. Channel max: 102400, MaxPageSize: 65535 ``` Then increase the `MaxPageSize` of the `cumulus_pallet_xcmp_queue` to something like this: ```rust type MaxPageSize = ConstU32<{ 103 * 1024 }>; ``` There is currently no easy way for on-chain governance to adjust the HRMP max message size of all channels, but it could be done: paritytech#3145. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]>
4 tasks
Could be, for a start i would probably go with a new extrinsic + transact. |
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this issue
Aug 2, 2024
Re-applying paritytech#2302 after increasing the `MaxPageSize`. Remove `without_storage_info` from the XCMP queue pallet. Part of paritytech#323 Changes: - Limit the number of messages and signals a HRMP channel can have at most. - Limit the number of HRML channels. A No-OP migration is put in place to ensure that all `BoundedVec`s still decode and not truncate after upgrade. The storage version is thereby bumped to 5 to have our tooling remind us to deploy that migration. ## Integration If you see this error in your try-runtime-cli: ```pre Max message size for channel is too large. This means that the V5 migration can be front-run and an attacker could place a large message just right before the migration to make other messages un-decodable. Please either increase `MaxPageSize` or decrease the `max_message_size` for this channel. Channel max: 102400, MaxPageSize: 65535 ``` Then increase the `MaxPageSize` of the `cumulus_pallet_xcmp_queue` to something like this: ```rust type MaxPageSize = ConstU32<{ 103 * 1024 }>; ``` There is currently no easy way for on-chain governance to adjust the HRMP max message size of all channels, but it could be done: paritytech#3145. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]>
|
Easier way to do this is to first reduce the limit on the sender side and then on the receiver manually. Could be done by modifying |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
HRMP channels have a
max_message_sizeand will possibly trunc/drop messages that are longer than this.I order to prepare for the revival of #2302, there needs to be a way to reduce the
max_message_sizeof all open channels since the Message Queue would otherwise fail to enqueue them.One possible way to do this between
Alice(requesting a change to MMS) andBobcounter-party:Alice:RequestConfigUpdate(MaxMessageSize(123)). This will be calledReqIdfor brevity.Bob:Ok(ReqId)if the new MMS value is larger or equal to the old one.TentativeOk(ReqId, LatestRelayBlockNumber)otherwise and adjusts the limits locally.Alice: waits untilLatestRelayBlockNumberhas elapsed and adjusts the limits locally.The text was updated successfully, but these errors were encountered: