Skip to content
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update frame/executive/src/lib.rs
Co-authored-by: Keith Yeung <[email protected]>
  • Loading branch information
bkchr and KiChjang authored Nov 26, 2022
commit 3edcfaebe3d6ed16d3efb2146f1c1329b2afb6eb
2 changes: 1 addition & 1 deletion frame/executive/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -501,7 +501,7 @@ where
// Mandatory(inherents) are not allowed to fail.
//
// The entire block should be discarded if an inherent fails to apply. Otherwise
// it may opens some attack vector.
// it may open an attack vector.
if r.is_err() && dispatch_info.class == DispatchClass::Mandatory {
Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/// 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,
looks good or? :D

return Err(InvalidTransaction::BadMandatory.into())
}
Expand Down