-
Notifications
You must be signed in to change notification settings - Fork 2.7k
frame-executive: Reject invalid inherents in the executive #12365
Conversation
We already had support for making a block fail if an inherent returned, but it was part of the signed extension `CheckWeight`. Rejecting blocks with invalid inherents should happen on the `frame-executive` level without requiring any special signed extension. This is crucial to prevent any kind of spamming of the network that could may happen with blocks that include failing inherents.
|
Just verifying my understanding,
trying to find where this all orchestrated in the codebase, somewhere on the node level |
Exactly! Inherents will normally be rejected by
|
|
bot rebase |
|
Rebased |
Co-authored-by: Keith Yeung <[email protected]>
Co-authored-by: Keith Yeung <[email protected]>
| // | ||
| // The entire block should be discarded if an inherent fails to apply. Otherwise | ||
| // it may open an attack vector. | ||
| if r.is_err() && dispatch_info.class == DispatchClass::Mandatory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope there's some doc on top of DispatchClass::Mandatory saying this can only be applied to inherents.
Perhaps also a doc in the frame macros saying you cannot annotate any transaction with DispatchClass::Mandatory.
Or, we should just call this DispatchClass::Inherent 🤷
Kinda confusing now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
substrate/frame/support/src/dispatch.rs
Lines 145 to 158 in 78164d9
| /// A mandatory dispatch. These kinds of dispatch are always included regardless of their | |
| /// weight, therefore it is critical that they are separately validated to ensure that a | |
| /// malicious validator cannot craft a valid but impossibly heavy block. Usually this just | |
| /// means ensuring that the extrinsic can only be included once and that it is always very | |
| /// light. | |
| /// | |
| /// Do *NOT* use it for extrinsics that can be heavy. | |
| /// | |
| /// The only real use case for this is inherent extrinsics that are required to execute in a | |
| /// block for the block to be valid, and it solves the issue in the case that the block | |
| /// initialization is sufficiently heavy to mean that those inherents do not fit into the | |
| /// block. Essentially, we assume that in these exceptional circumstances, it is better to | |
| /// allow an overweight block to be created than to not allow any block at all to be created. | |
| Mandatory, |
|
bot rebase |
|
Rebased |
|
bot merge |
|
Waiting for commit status. |
…h#12365) * frame-executive: Reject invalid inherents in the executive We already had support for making a block fail if an inherent returned, but it was part of the signed extension `CheckWeight`. Rejecting blocks with invalid inherents should happen on the `frame-executive` level without requiring any special signed extension. This is crucial to prevent any kind of spamming of the network that could may happen with blocks that include failing inherents. * FMT * Update frame/executive/src/lib.rs Co-authored-by: Keith Yeung <[email protected]> * Update primitives/runtime/src/transaction_validity.rs Co-authored-by: Keith Yeung <[email protected]> Co-authored-by: parity-processbot <> Co-authored-by: Keith Yeung <[email protected]>
…h#12365) * frame-executive: Reject invalid inherents in the executive We already had support for making a block fail if an inherent returned, but it was part of the signed extension `CheckWeight`. Rejecting blocks with invalid inherents should happen on the `frame-executive` level without requiring any special signed extension. This is crucial to prevent any kind of spamming of the network that could may happen with blocks that include failing inherents. * FMT * Update frame/executive/src/lib.rs Co-authored-by: Keith Yeung <[email protected]> * Update primitives/runtime/src/transaction_validity.rs Co-authored-by: Keith Yeung <[email protected]> Co-authored-by: parity-processbot <> Co-authored-by: Keith Yeung <[email protected]>
We already had support for making a block fail if an inherent returned, but it was part of the signed extension
CheckWeight. Rejecting blocks with invalid inherents should happen on theframe-executivelevel without requiring any special signed extension. This is crucial to prevent any kind of spamming of the network that could may happen with blocks that include failing inherents.