-
Notifications
You must be signed in to change notification settings - Fork 683
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
WIP: implement StorageWeightReclaim as wrapping transaction extension with weight #5234
WIP: implement StorageWeightReclaim as wrapping transaction extension with weight #5234
Conversation
b05e68c
to
76d3373
Compare
Very nice!
How would the two communicate? Would we need a new StorageItem for them to read and write? |
extending the dispatch context to transaction extension also or using a storage item. But wrapping type seems ok. |
Having a storage item and writing into it in |
I thought writing into a storage without reading it before would not leak anything into the proof. |
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.
First round of review, looking good so far 👍
@@ -945,6 +945,10 @@ impl pallet_xcm_bridge_hub_router::Config<ToWestendXcmRouterInstance> for Runtim | |||
type FeeAsset = xcm_config::bridging::XcmBridgeHubRouterFeeAssetId; | |||
} | |||
|
|||
impl cumulus_pallet_weight_reclaim_tx::Config for Runtime { | |||
type WeightInfo = (); |
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.
Would be nice to run a bot bench
on this new pallet and get some weights once we're set on a final version of the code. Same for other runtimes.
cumulus/parachains/runtimes/bridge-hubs/bridge-hub-rococo/tests/tests.rs
Outdated
Show resolved
Hide resolved
//! add [`StorageWeightReclaim`](cumulus_primitives_storage_weight_reclaim::StorageWeightReclaim) | ||
//! to that list. For maximum efficiency, make sure that `StorageWeightReclaim` is last in the list. | ||
//! set [`StorageWeightReclaim`](cumulus_pallet_weight_reclaim_tx::StorageWeightReclaim) | ||
//! as a warpper of that list. |
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'd add something like "in order to catch the whole PoV size, it's required that this extension wraps all the other transaction extensions of the runtime.
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.
done in ea81a0f
} | ||
} | ||
|
||
// Make this extension "invisible" from the outside (ie metadata type information) |
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.
Why would we not want this extension to show up in the metadata? Especially since this along with CheckMetadataHash
would alert us if something changes to the extension pipeline, this extension included.
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 know how UI code is written and if it expects a list of transaction extension or if it can handle more complex structure.
- I copied the design from
SkipIfCheckFeeless
which is also invisible from the outside.
I don't mind anything, but we must make sure UI knows how to handle nested transaction extensions.
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.
Until we can confirm the UI doesn't break or we get support in the UI, let's keep it invisible 👍
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.
How would an extension that has no implication on the signed and raw payload the tx break any UI?
As in, with our without this extension, the same bytes are a valid tx, so...?
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.
How would an extension that has no implication on the signed and raw payload the tx break any UI?
As in, with our without this extension, the same bytes are a valid tx, so...?
I expect UI frameworks to do some match on the transaction extension identifiers (which weight reclaim implements in an invisible way), but if they are doing some match on the transaction extension type to get information about what needs to be provided then it will break.
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.
As far as I'm aware, client libraries (like Subxt) mostly just match on the identifiers, since they usually need to implement some sort of custom logic for how to handle each extension anyway. So if this extension is "invisible" in that way then I don't see it causing an issue offhand!
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 fixed the implementation, it is still invisible, but should be correctly implemented. 375543d
// Trade-off: we could move it to `prepare` but better be accurate on reclaim than fast on | ||
// `validate` |
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.
👍
let inner_weight = | ||
S::post_dispatch_details(inner_pre, info, post_info, len, result, context)?; |
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.
This should be computed using post_dispatch
. The post_dispatch_details
function should not be used explicitly because, unlike post_dispatch
, it does not carry over the reduced weight through a mutable reference to the PostDispatchInfo
. It would return the correct actual weight used, but it wouldn't update the post_info
along the way, and some extensions rely on it, it's basically their weight meter.
For more info into the way it works, look at the TransactionExtension
impl at substrate/primitives/runtime/src/traits/transaction_extension/mod.rs:498
.
I wanted to make post_dispatch_details
take a mutable reference to post_info
as well, but I figured I would only encourage people to use it the unintended way.
The suggestion below can probably be nicer with a match
, but the inner_weight
calculation will change anyway once the post dispatch weight subtraction instead of accrual is implemented.
let inner_weight = | |
S::post_dispatch_details(inner_pre, info, post_info, len, result, context)?; | |
let mut actual_post_info = *post_info; | |
S::post_dispatch(inner_pre, info, &mut actual_post_info, len, result, context)?; | |
let inner_weight = actual_post_info | |
.actual_weight | |
.map(|actual_weight| actual_weight.saturating_sub(post_info.actual_weight.unwrap())); |
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 see, maybe the post_dispatch_details
implementation for tuples should log a warning, or have a debug error.
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.
Implementing post_dispatch_details
prevent us from returning the correct pays_fee
if a transaction extension modified it.
It may be more accurate to implement post_dispatch
I did at: 4d99a45
} | ||
|
||
#[derive_impl(frame_system::config_preludes::TestDefaultConfig)] | ||
impl frame_system::Config for Test { |
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 probably needs a custom MockWeights: frame_system::ExtensionsWeightInfo
that you can control and assert in tests for CheckWeight
's post_dispatch
. To make the tests more accurate, some mock weights can be used for this pallet as well, instead of ()
.
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 set up configuration for better tests in eb0cdff but I will wait for the deccumulating/refining post dispatch info implementation.
Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com>
This reverts commit 4d99a45.
…gui-storage-proof-size-reclaim-more-accurate
…gui-storage-proof-size-reclaim-more-accurate
…gui-storage-proof-size-reclaim-more-accurate
The CI pipeline was cancelled due to failure one of the required jobs. |
I propose to move PoV-reclaim to the next release. It can happen that the amount to reclaim is overestimated paritytech/polkadot-sdk#5229. Improvements (paritytech/polkadot-sdk#5281, paritytech/polkadot-sdk#5273) and a proper fix (paritytech/polkadot-sdk#5234) are in the works, but should be tested again. I expect the chances that the system-chains run into this scenario to be low, but it does not look like activity is so high that the inclusion of reclaim is urgent. --------- Co-authored-by: Bastian Köcher <git@kchr.de>
…gui-storage-proof-size-reclaim-more-accurate
…gui-storage-proof-size-reclaim-more-accurate
somehow I can't reopen it. Moved to #6140 |
Implement
StorageWeightReclaim
as a transaction extension that wraps around all the transaction extensions.This is because transaction extension weight is not part of base extrinsic weight. So we should trigger before all extensions and reclaim after all extensions to get accurate post info.
old
StorageWeightReclaim
is deprecatedTODO:
ProofSizeExt
is available or that the worst-case code is covered in some way