-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stateful-storage: check hash in signed extension #2137
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
|
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.
Only a couple of little things for comments, not worth doing a CI round trip unless you are already going to change those files.
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.
Read through, looks good
Do we need to update any weights (overhead) ?
.unwrap_or_default() | ||
.try_into() | ||
.unwrap_or_default(), | ||
_ => 255u8, |
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.
It seems we could end up with an error code that’s not entirely accurate, particularly in the case where zero is returned. Using unwrap_or_default() might not be the best approach here, as falling back to the default value could potentially introduce a bug. That said, I might be overlooking something.
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.
Also, just a note: the "Custom Error" code that we get as part of the RPC "1010" error is entirely arbitrary, and does not indicate the pallet. So a code of 9
(StalePageHash) is not meaningful to the end user, because they don't know what pallet enum that comes from. I do think somewhere there is an enum of custom RPC error codes for Frequency; perhaps we should map to that instead? Sadly Polkadot/Substrate does not give us a way to propagate anything more than an integer value for custom RPC errors.
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.
@enddynayn The first unwrap_or_default()
tries to convert encoded error value (coming from the position of error in the Error enum in the pallet) to u32
which means it can not fail. The second unwrap_or_default()
tries to convert u32 to u8 but that would only fail if we have more than 256 errors in the same pallet which is highly unlikely.
@JoeCap08055 Since this is coming from validate
it means that after submission you would immediately get that error back. And for any individual extrinsic since the client knows what type of extrinsic they are submitting it is obvious what that error would mean. I have to look into the batch usecase since that would be trickier.
In any case since we only have 256 unique values for different errors we might be able to create a universal custom error enum which would be different between the errors in different pallets but that does not seem to scale based on the total number of pallets and errors. I'm open to suggestions.
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.
Interesting approach but works.
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.
Probably a wider issue than this PR, but the universal enum idea might not be so bad; we wouldn't need to map every error from every pallet; only the ones that can happen in a SignedExtension check. There shouldn't be that many.
Anyway, this approach works for now; maybe it's worth a backlog issue to revisit how we do this across all of our signed extensions, or maybe not.
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.
👍 great!
I calculated the overhead benchmark and it didn't change. My guess is that since we don't have anything inside |
Code is refactored
}) => Self::extract_hash_data(call), | ||
RuntimeCall::FrequencyTxPayment( | ||
FrequencyPaymentCall::pay_with_capacity_batch_all { calls, .. }, | ||
) => calls.iter().flat_map(|c| Self::extract_hash_data(c)).collect(), |
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.
👍
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.
Nice! I like this refactor.
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.
Great! 👍 I also suggest adding some unit tests to the signed extension.
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.
Nice rework.
- Pulled & built branch
- Ran unit tests
- Ran e2e tests
Looks good!
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.
Looks good to me. I think it's good to go and if it can be done the same way as CapacityEligibleCalls I think it can be revisited later.
Refactor issue is created #2145 |
Goal
The goal of this PR is to check the hash for stateful storage transactions and fail early.
Closes #1860
Checklist