Introduce `MaxParachainBlockWeight` and related functionality by bkchr · Pull Request #10315 · paritytech/polkadot-sdk

bkchr · 2025-11-13T16:05:00Z

This pull request introduces MaxParachainBlockWeight to calculate the max weight per parachain block. This is a preparation for Block Bundling which requires that the maximum block weight is dynamic. Block bundling requires a dynamic maximum block weight because it bundles multiple blocks into one PoV. Each PoV gets 2s of execution time and 10MiB of proof size. These resources need to be split up between all the blocks of one PoV. This doesn't require the weight to be dynamic. However, it gets complicated when a transaction should be applied that requires more resources than what one of these blocks can provide, e.g. for doing a runtime upgrade. In this case MaxParachainBlockWeight supports to increase the block weight of one block to take up the weight of the full PoV. The feature will not only be useful for things like runtime upgrade, but also could enable users to pay for running some huge contracts or whatever. For more information, please refer to the docs provided in the code of this pull request.

For MaxParachainBlockWeight to work correctly, it provides a pre-inherent hook and a transaction extension. Both are required to track the weight correctly.

This pull request introduces `MaxParachainBlockWeight` to calculate the max weight per parachain block. This is a preparation for [Block Bundling](#6495) which requires that the maximum block weight is dynamic. Block bundling requires a dynamic maximum block weight because it bundles multiple blocks into one `PoV`. Each `PoV` gets `2s` of execution time and `10MiB` of proof size. These resources need to be split up between all the blocks of one `PoV`. This doesn't require the weight to be dynamic. However, it gets complicated when a transaction should be applied that requires more resources than what one of these blocks can provide, e.g. for doing a runtime upgrade. In this case `MaxParachainBlockWeight` supports to increase the block weight of one block to take up the weight of the full `PoV`. The feature will not only be useful for things like runtime upgrade, but also could enable users to pay for running some huge contracts or whatever. For more information, please refer to the docs provided in the code of this pull request. For `MaxParachainBlockWeight` to work correctly, it provides a pre-inherent hook and a transaction extension. Both are required to track the weight correctly.

…ck-weight

…extension.rs Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

ggwpez

Seems quite complex to me, maybe we should do a tentative deployment to Westend from this branch with the extension included before merging.

ggwpez · 2025-11-14T09:56:52Z

+//! The [`MaxParachainBlockWeight`] provides a [`Get`] implementation that will return the max block
+//! weight as determined by the [`DynamicMaxBlockWeight`] transaction extension.
+//!
+//! [`DynamicMaxBlockWeightHooks`] needs to be registered as a pre-inherent hook. It is used to


Maybe we can somehow test this in the runtime integrity check, like the migrations pallet does for the MultiBlockMigrator hook.

Yeah I thought about this as well, but did not came up with any proper implementation I'm happy with.

ggwpez · 2025-11-14T10:56:49Z

+/// Transaction extension that dynamically changes the max block weight.
+///
+/// With block bundling, parachains are running with block weights that may not allow certain
+/// transactions to be applied, e.g. a runtime upgrade. To ensure that these transactions can still


If I want to send a big transaction, how do I tell the node to put into the first block of a batch? Or will it do that automatically?

The node is ordering based on priority. The runtime lays out priority based on the fees that you are going to pay. Fees are based on weight. There is generally no guarantee for the ordering. If a transaction does not fit, it will be tried at the next block.

ggwpez · 2025-11-14T11:33:13Z

+	/// The current block weight mode.
+	///
+	/// This is used to determine what is the maximum allowed block weight, for more information see
+	/// [`block_weight`].


Can you please explain here when it is set and when it is removed?

ggwpez · 2025-11-14T11:35:08Z

 			.saturating_add(T::DbWeight::get().writes((1_u64).saturating_mul(n.into())))
 	}
+	fn block_weight_tx_extension_max_weight() -> Weight {
+		Weight::zero()


Need to rebench

ggwpez · 2025-11-14T11:36:08Z

 	pub number_of_cores: Compact<u16>,
 }

+impl core::hash::Hash for CoreInfo {


This is for std only?

What exactly?

bkchr · 2025-11-14T12:30:59Z

Seems quite complex to me, maybe we should do a tentative deployment to Westend from this branch with the extension included before merging.

I don't want to directly deploy this to production. :) Not sure what you want to test there on Westend. I have also more tests in another branch where zombienet tests are running based on this stuff.

…tion.rs Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

…ck-weight' into bkchr-parachain-block-weight

bkchr · 2025-11-14T18:27:03Z

/cmd fmt

…ck-weight

bkchr · 2026-03-10T13:05:09Z

/cmd fmt

bkchr · 2026-03-10T21:43:05Z

/cmd fmt

This implements Block bundling aka 500ms on the node side. Right now the pull request also contains the runtime changes, but this is already its [own pull request](#10315). The main changes are in the slot-based collator. Instead of building one block per core, blocks will be build as requested and distributed over the available cores. Closes: #9080 Closes: #8963 Closes: #6495 --------- Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Sebastian Kunert <skunert49@gmail.com> Co-authored-by: Sebastian Kunert <mail@skunert.dev> Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>

bkchr requested a review from a team as a code owner November 13, 2025 16:05

bkchr added the T1-FRAME This PR/Issue is related to core FRAME, the framework. label Nov 13, 2025

Merge remote-tracking branch 'origin/master' into bkchr-parachain-blo…

e73e10e

…ck-weight

gui1117 reviewed Nov 14, 2025

View reviewed changes

Comment thread cumulus/pallets/parachain-system/src/block_weight/transaction_extension.rs Outdated

Comment thread cumulus/pallets/parachain-system/src/block_weight/transaction_extension.rs Outdated

Comment thread cumulus/pallets/parachain-system/src/block_weight/transaction_extension.rs Outdated

bkchr and others added 2 commits November 14, 2025 08:55

Update cumulus/pallets/parachain-system/src/block_weight/transaction_…

2712aef

…extension.rs Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

Update cumulus/pallets/parachain-system/src/block_weight/transaction_…

2917609

…extension.rs Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

redzsina added this to Security Audit (PRs) - SRLabs Nov 14, 2025

github-project-automation Bot moved this to Backlog in Security Audit (PRs) - SRLabs Nov 14, 2025

redzsina moved this from Backlog to Scheduled in Security Audit (PRs) - SRLabs Nov 14, 2025

ggwpez reviewed Nov 14, 2025

View reviewed changes

New test and some fixes

86ad20f

bkchr and others added 7 commits November 14, 2025 15:00

Ensure we ignore the block weight mode from the previous block

5b5190b

Update cumulus/pallets/parachain-system/src/validate_block/implementa…

a8641d6

…tion.rs Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Allow MBMs to take the full core

eba0d14

Fixes

9de019e

Merge remote-tracking branch 'refs/remotes/origin/bkchr-parachain-blo…

58620b1

…ck-weight' into bkchr-parachain-block-weight

Fix benchmark

8901237

FMT

ef27858

bkchr added 6 commits November 19, 2025 16:29

Support full core weight for pre transactions

066cd7c

Fix unsigned transactions

0b98e3f

Respect the dispatch class max weight

3499274

Fix on_idle

1cea268

Test on_poll

5ed9e29

More docs

3404f67

bkchr mentioned this pull request Nov 29, 2025

Block Bundling Node Side #10477

Merged

bkchr added 2 commits December 2, 2025 11:03

Merge remote-tracking branch 'origin/master' into bkchr-parachain-blo…

e262e6c

…ck-weight

Fix test

836b091

michalkucharczyk reviewed Jan 20, 2026

View reviewed changes

bkchr added 3 commits February 6, 2026 17:43

Review feedback

a92ca43

Merge remote-tracking branch 'origin/master' into bkchr-parachain-blo…

406d101

…ck-weight

Ensure UMP + HRMP messages fit into the limits

535054f

skunert approved these changes Mar 9, 2026

View reviewed changes

Merge remote-tracking branch 'origin/master' into bkchr-parachain-blo…

2c42cbb

…ck-weight

Also take the size into account for UMP messages

44911d4

Update from github-actions[bot] running command 'fmt'

3f04aaf

bkchr force-pushed the bkchr-parachain-block-weight branch from 57f8c74 to 3f04aaf Compare March 10, 2026 22:25

bkchr added 5 commits March 10, 2026 23:28

Prdoc + fixes

249b846

More fixes

39f6ffc

Fix errors

eacf91b

Better tracking

d3e8abb

Docs

9766f5d

bkchr added this pull request to the merge queue Mar 12, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Mar 12, 2026

bkchr added this pull request to the merge queue Mar 12, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Mar 12, 2026

Merge branch 'master' into bkchr-parachain-block-weight

0d96d86

bkchr enabled auto-merge March 14, 2026 21:02

bkchr added this pull request to the merge queue Mar 14, 2026

Merged via the queue into master with commit 2c5feef Mar 14, 2026
242 of 248 checks passed

bkchr deleted the bkchr-parachain-block-weight branch March 14, 2026 22:42

pgherveou added this to [preview] release tracker Mar 31, 2026

github-project-automation Bot moved this to Todo in [preview] release tracker Mar 31, 2026

github-project-automation Bot moved this from Todo to Done in [preview] release tracker Mar 31, 2026

Conversation

bkchr commented Nov 13, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ggwpez left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bkchr commented Nov 14, 2025

Uh oh!

bkchr commented Nov 14, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bkchr commented Mar 10, 2026

Uh oh!

bkchr commented Mar 10, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants