-
Notifications
You must be signed in to change notification settings - Fork 699
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
beefy: put not only lease parachain heads into mmr #4751
Conversation
let mut heads: Vec<(u32, Vec<u8>)> = | ||
Heads::<T>::iter().map(|(id, head)| (id.into(), head.0)).collect(); | ||
heads.sort_by_key(|(id, _)| *id); | ||
heads.truncate(MAX_PARA_HEADS); |
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.
Works for Snowbridge, since BridgeHub with ID 1002 will be sorted before all the other non-system parachains 👍
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.
Ideally we would truncate before sorting. Although it sounds unlikely that someone registers so many parachains that sorting becomes a real problem. Nice thing about sorting first is that system chains will be preferred.
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! Thanks @ordian ! I would have been even more conservative by not even iterating more heads than the limit, but realistically your approach should be safe enough and is even less problematic when the limit is hit.
let mut heads: Vec<(u32, Vec<u8>)> = | ||
Heads::<T>::iter().map(|(id, head)| (id.into(), head.0)).collect(); | ||
heads.sort_by_key(|(id, _)| *id); | ||
heads.truncate(MAX_PARA_HEADS); |
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.
Ideally we would truncate before sorting. Although it sounds unlikely that someone registers so many parachains that sorting becomes a real problem. Nice thing about sorting first is that system chains will be preferred.
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.
Code changes look good! 👍
Regarding benchmarking, the extra_data()
is computed on_initialize
of each block in pallet-mmr
:
let data = T::LeafData::leaf_data(); |
It is currently using pallet "static" weight:
fn on_initialize(peaks: u64) -> Weight { |
configured here: https://github.com/polkadot-fellows/runtimes/blob/0185f7c1740a3b6edb7f8dbb6be541cfcb26ace6/relay/polkadot/src/lib.rs#L360
To include the parachain heads processing cost too, it'd have to be covered by runtime-specific benchmarking (using a high number of registered parachains)
Co-authored-by: Adrian Catangiu <adrian@parity.io>
* master: (120 commits) network/tx: Ban peers with tx that fail to decode (#5002) Try State Hook for Bounties (#4563) [statement-distribution] Add metrics for distributed statements in V2 (#4554) added sync command (#4818) Bridges V2 refactoring backport and `pallet_bridge_messages` simplifications (#4935) xcm-executor: Improve logging (#4996) Remove usage of `sp-std` on templates (#5001) fixed cmd bot commenting not working (#5000) Explain usage of `<T: Config>` in FRAME storage + Update parachain pallet template (#4941) Expose metadata-hash feature from polkadot crate (#4886) Add `MAX_INSTRUCTIONS_TO_DECODE` to XCMv2 (#4978) add notices to the implementer's guide docs that changed for elastic scaling (#4983) `polkadot-parachain` simplifications and deduplications (#4916) Update Templates README docs (#4980) allow clear_origin in safe xcm builder (#4777) litep2p/peerstore: Fix bump last updated time (#4971) Make `tracing::log` work in the runtime (#4863) sp-core: Improve docs generated by `generate_feature_enabled_macro` (#4968) [Backport] Version bumps and prdocs reordering from 1.14.0 (#4955) Assets: can_decrease/increase for destroying asset is not successful (#3286) ...
…ritytech/polkadot-sdk into ao-paraheadrootsprovider-coretime-fix * 'ao-paraheadrootsprovider-coretime-fix' of github.com:paritytech/polkadot-sdk: Update polkadot/runtime/parachains/src/paras/mod.rs
bot bench help |
bot bench substrate-pallet --pallet=pallet_mmr --runtime=westend |
bot bench polkadot-pallet --pallet=pallet_mmr --runtime=westend |
bot bench polkadot-pallet --pallet=pallet_mmr --runtime=westend |
@ordian Command
|
@ordian Command |
* master: add elastic scaling MVP guide (#4663) Send PeerViewChange with high priority (#4755) [ci] Update forklift in CI image (#5032) Adjust base value for statement-distribution regression tests (#5028) [pallet_contracts] Add support for transient storage in contracts host functions (#4566) [1 / 5] Optimize logic for gossiping assignments (#4848) Remove `pallet-getter` usage from pallet-session (#4972) command-action: added scoped permissions to the github tokens (#5016) net/litep2p: Propagate ValuePut events to the network backend (#5018) rpc: add back rpc logger (#4952) Updated substrate-relay version for tests (#5017) Remove most all usage of `sp-std` (#5010) Use sp_runtime::traits::BadOrigin (#5011)
Benchmarking looks good! 👍 |
|
||
<<T as pallet::Config::<I>>::BenchmarkHelper as BenchmarkHelper>::setup(); | ||
for leaf in 0..(leaves - 1) { | ||
Pallet::<T, I>::on_initialize((leaf as u32).into()); | ||
} | ||
}: { | ||
Pallet::<T, I>::on_initialize((leaves as u32 - 1).into()); |
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 was benchmarking leaves * on_initialize
previously instead of just one iteration of on_initialize
The CI pipeline was cancelled due to failure one of the required jobs. |
This reverts commit 94d1a48.
Looks like merge is blocked on 1 more approval. |
ping @eskimor |
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.
Weight looks off. Rest looks good.
// Measured: `2140817` | ||
// Estimated: `7213082` | ||
// Minimum execution time: 20_387_000_000 picoseconds. | ||
Weight::from_parts(223_625_477_528, 0) |
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.
Do I read this right as 223ms? This seems excessive 😨
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.
IIRC, these number are old before I fixed the bench to measure only on_initialize
instead of leaves * on_initialize
. Also with testnet
profile.
need to rerun the bench before the release, but that is done as part of the release AFAIK.
// Measured: `1071043 + x * (39 ±0)` | ||
// Estimated: `3608787 + x * (39 ±6)` | ||
// Minimum execution time: 11_102_000_000 picoseconds. | ||
Weight::from_parts(21_772_042_215, 0) |
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.
Here it is "only" 20. Still a lot, but 10x better than 200.
Short-term addresses paritytech#4737. - [x] Resolve benchmarking I've digged into benchmarking mentioned paritytech#4737 (comment), but it seemed to me that this code is different proof/path. @acatangiu could you confirm? (btw, in this [bench](https://github.com/paritytech/polkadot-sdk/blob/b65313e81465dd730e48d4ce00deb76922618375/bridges/modules/parachains/src/benchmarking.rs#L57), where do you actually set the `fn parachains()` to a reasonable number? i've only seen 1) - [ ] Communicate to Snowfork team: This seems to be the relevant code: https://github.com/Snowfork/snowbridge/blob/1e18e010331777042aa7e8fff3c118094af856ba/relayer/cmd/parachain_head_proof.go#L95-L120 - [x] Is it preferred to iter() in some random order as suggested in paritytech#4737 (comment) or take lowest para ids instead as implemented here currently? - [x] PRDoc ## Updating Polkadot and Kusama runtimes: New weights need to be generated (`pallet_mmr`) and configs updated similar to Rococo/Westend: ```patch diff --git a/polkadot/runtime/rococo/src/lib.rs b/polkadot/runtime/rococo/src/lib.rs index 5adffbd7422..c7da339b981 100644 --- a/polkadot/runtime/rococo/src/lib.rs +++ b/polkadot/runtime/rococo/src/lib.rs @@ -1307,9 +1307,11 @@ impl pallet_mmr::Config for Runtime { const INDEXING_PREFIX: &'static [u8] = mmr::INDEXING_PREFIX; type Hashing = Keccak256; type OnNewRoot = pallet_beefy_mmr::DepositBeefyDigest<Runtime>; - type WeightInfo = (); type LeafData = pallet_beefy_mmr::Pallet<Runtime>; type BlockHashProvider = pallet_mmr::DefaultBlockHashProvider<Runtime>; + type WeightInfo = weights::pallet_mmr::WeightInfo<Runtime>; + #[cfg(feature = "runtime-benchmarks")] + type BenchmarkHelper = parachains_paras::benchmarking::mmr_setup::MmrSetup<Runtime>; } parameter_types! { @@ -1319,13 +1321,8 @@ parameter_types! { pub struct ParaHeadsRootProvider; impl BeefyDataProvider<H256> for ParaHeadsRootProvider { fn extra_data() -> H256 { - let mut para_heads: Vec<(u32, Vec<u8>)> = parachains_paras::Parachains::<Runtime>::get() - .into_iter() - .filter_map(|id| { - parachains_paras::Heads::<Runtime>::get(&id).map(|head| (id.into(), head.0)) - }) - .collect(); - para_heads.sort(); + let para_heads: Vec<(u32, Vec<u8>)> = + parachains_paras::Pallet::<Runtime>::sorted_para_heads(); binary_merkle_tree::merkle_root::<mmr::Hashing, _>( para_heads.into_iter().map(|pair| pair.encode()), ) @@ -1746,6 +1743,7 @@ mod benches { [pallet_identity, Identity] [pallet_indices, Indices] [pallet_message_queue, MessageQueue] + [pallet_mmr, Mmr] [pallet_multisig, Multisig] [pallet_parameters, Parameters] [pallet_preimage, Preimage] ``` --------- Co-authored-by: Adrian Catangiu <adrian@parity.io>
Short-term addresses #4737.
I've digged into benchmarking mentioned offchain XCMP: Merkle tree of para headers in beefy ignores Coretime chains #4737 (comment), but it seemed to me that this code is different proof/path. @acatangiu could you confirm? (btw, in this bench, where do you actually set the
fn parachains()
to a reasonable number? i've only seen 1)This seems to be the relevant code: https://github.com/Snowfork/snowbridge/blob/1e18e010331777042aa7e8fff3c118094af856ba/relayer/cmd/parachain_head_proof.go#L95-L120
Updating Polkadot and Kusama runtimes:
New weights need to be generated (
pallet_mmr
) and configs updated similar to Rococo/Westend: