-
Notifications
You must be signed in to change notification settings - Fork 2.7k
add notes and warnings to ProvideInherent docs #9730
Conversation
frame/support/src/inherent.rs
Outdated
/// This check is not guaranteed to be run as part of consensus and cannot be relied upon for | ||
/// security. Run security relevant checks in [`Self::create_inherent`]. |
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.
security checks cannot be put in create_inherent AFAIK.
I don't really know the nature of the check that check_inherent
provide, but it is important for security reason otherwise there is no point to it, no ?
Some check for the validity of the timestamp is done in check_inherent
.
As far as I understand this: It is what other validator will use the check the validity of the inherents provided in comparison to some inherent data that the validator will provide.
For instance, a validator will check that the timestamp is not too much in the future compared to what he considers to be the present. (I.e. compared to the time he provided in his inherent data)
Co-authored-by: Bastian Köcher <[email protected]>
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
@bkchr @thiolliere What do you think of the rewording? |
frame/support/src/inherent.rs
Outdated
/// NOTE: All checks necessary to ensure that the inherent is correct and that can be done in | ||
/// the runtime should happen in the returned `Call`. | ||
/// E.g. if this provides a block producer, check in the returned extrinsic that the producer is | ||
/// eligible to create the block. |
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 don't very like this example, probably for the same reason as said above by Basti.
Like currently the block producer is passed by using digest, but I guess we could use an inherent.
Then the inherent could just write the author into a storage (which can be removed in on_finalize in order not to get into the block).
Later other pallets could check that the author is able to produce a block, and just panic in case he is not able to produce a block.
Thus the check whether the producer is eligible to create the block will not happen in the call, but later in the block production.
I think that this part:
/// NOTE: All checks necessary to ensure that the inherent is correct and that can be done in
/// the runtime should happen in the returnedCall
.
is good, but maybe as an example I would write:
E.g. if this provide the timestamp, the call will check that the given timestamp is increasing the old timestamp by more than a minimum and it will also check that the timestamp hasn't already been set.
Later in theon_finalize
hook, the pallet could also ensure that the timestamp is set.
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.
all good to me, except the example which I would prefer to be different https://github.com/paritytech/substrate/pull/9730/files#r758115926
/// If the inherent is not present, it will return `e`. | ||
/// | ||
/// - `Err(_)` indicates that this function failed and further operations should be aborted. | ||
/// | ||
/// NOTE: If inherent is required then the runtime asserts that the block contains at least | ||
/// NOTE: If the inherent is required then the runtime asserts that the block contains at least | ||
/// one inherent for which: | ||
/// * type is [`Self::Call`], | ||
/// * [`Self::is_inherent`] returns true. |
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'm not sure how to write it but this is_inherent_required
is currently only checked by other block producer same as check_inherent
, maybe we can change it to make it part of the execute_block
. But it is not the case currently.
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Co-authored-by: Bastian Köcher <[email protected]>
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
* add notes and warnings to ProvideInherent docs * rephrase ProvideInherent doc comments * more comment refinement * remove multiple inherents note * remove repetition Co-authored-by: Bastian Köcher <[email protected]> * replace inherent example in docs * add note about who checks is_inherent_required * Apply suggestions from code review Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
* add notes and warnings to ProvideInherent docs * rephrase ProvideInherent doc comments * more comment refinement * remove multiple inherents note * remove repetition Co-authored-by: Bastian Köcher <[email protected]> * replace inherent example in docs * add note about who checks is_inherent_required * Apply suggestions from code review Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
* add notes and warnings to ProvideInherent docs * rephrase ProvideInherent doc comments * more comment refinement * remove multiple inherents note * remove repetition Co-authored-by: Bastian Köcher <[email protected]> * replace inherent example in docs * add note about who checks is_inherent_required * Apply suggestions from code review Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
* add notes and warnings to ProvideInherent docs * rephrase ProvideInherent doc comments * more comment refinement * remove multiple inherents note * remove repetition Co-authored-by: Bastian Köcher <[email protected]> * replace inherent example in docs * add note about who checks is_inherent_required * Apply suggestions from code review Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
* add notes and warnings to ProvideInherent docs * rephrase ProvideInherent doc comments * more comment refinement * remove multiple inherents note * remove repetition Co-authored-by: Bastian Köcher <[email protected]> * replace inherent example in docs * add note about who checks is_inherent_required * Apply suggestions from code review Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
This PR makes some changes to the inherents docs to avoid misunderstandings.