Setup permissionless lanes for AssetHubs - heads/state-roots sync#8326
Setup permissionless lanes for AssetHubs - heads/state-roots sync#8326bkontur wants to merge 18 commits intobko-permlanes-on-ahs-2-on-new-headfrom
Conversation
bkontur
changed the title
…on-ahs-3-heads-sync
|
/cmd fmt |
…ad' into bko-permlanes-on-ahs-3-heads-sync
…on-ahs-3-heads-sync
…on-ahs-3-heads-sync
Relates to: #8326 Relates to: #6675 (Extracted from #8325) This PR introduces a new `OnNewHead` hook for `pallet-bridge-parachains`, which is triggered when a new parachain head is relayed. It will be used in conjunction with the [syncing mechanism](#8326), which sends relayed AssetHubRococo headers with `state_root`s to AssetHubWestend for message proof verification. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Left just a few comments.
Overall I think I understood the idea at least for the asset hubs. But it would still be good if we could have a call with the team and if you could give an overview of the entire architecture. I'm not sure if I understand exactly what a non-system parachain would need to do in order to open a bridge and what pallets it needs to deploy. Not sure if it would be exactly like the asset hubs or if it would be different and I would be interested in knowing this in detail.
Anyway, the general feeling is that the configuration is fairly complex.
| // Remove from the front up to the `T::RootsToKeep` limit. | ||
| let max = T::RootsToKeep::get(); | ||
| while roots.len() > (max as usize) { | ||
| let _ = roots.pop_front(); | ||
| } |
There was a problem hiding this comment.
I saw something similar done also in #8324 in do_note_new_roots. Maybe we can deduplicate this.
| impl pallet_bridge_proof_root_sync::OnSend<ParaId, ParaHead> for ToAssetHubRococoProofRootSender { | ||
| fn on_send(roots: &Vec<(ParaId, ParaHead)>) { | ||
| // For smaller messages, we just send minimal data. | ||
| let roots = roots | ||
| .iter() | ||
| .filter_map(|(id, head)| { | ||
| let header: HeaderOf<bp_asset_hub_westend::AssetHubWestend> = | ||
| match Decode::decode(&mut &head.0[..]) { | ||
| Ok(header) => header, | ||
| Err(error) => { | ||
| log::warn!( | ||
| target: "runtime::bridge-xcm::on-send", | ||
| "Failed to decode parachain header - skipping it! head: {:?}, para_id: {:?}, error: {:?}", | ||
| head, | ||
| id, | ||
| error, | ||
| ); | ||
| return None; | ||
| }, | ||
| }; | ||
| // We just need block_hash and state_root. | ||
| Some((header.hash(), *header.state_root())) | ||
| }) | ||
| .collect::<Vec<_>>(); | ||
|
|
||
| // Send dedicated `Transact` to AHW. | ||
| let xcm = Xcm(vec![ | ||
| UnpaidExecution { weight_limit: Unlimited, check_origin: None }, | ||
| Transact { | ||
| origin_kind: OriginKind::Xcm, | ||
| fallback_max_weight: None, | ||
| call: bp_asset_hub_rococo::Call::AssetHubWestendProofRootStore( | ||
| bp_asset_hub_rococo::ProofRootStoreCall::note_new_roots { | ||
| roots: roots.clone(), | ||
| }, | ||
| ) | ||
| .encode() | ||
| .into(), | ||
| }, | ||
| ExpectTransactStatus(MaybeErrorCode::Success), | ||
| ]); | ||
| if let Err(error) = PolkadotXcm::send_xcm(Here, AssetHubLocation::get(), xcm) { | ||
| log::warn!(target: "runtime::bridge-xcm::on-send", "Failed to send XCM: {:?}", error); | ||
| } | ||
| } |
There was a problem hiding this comment.
This logic is duplicated for BHR and BHW. Even though there are some differences, I think some deduplication should be possible.
There was a problem hiding this comment.
This logic is duplicated for BHR and BHW. Even though there are some differences, I think some deduplication should be possible.
Yes, thank you, you're right, I did some refactoring and now it is much more simpler now and easy to reuse the same stuff (polkadot-sdk, fellows, ...). Fixed by 8d6f747
cumulus/parachains/runtimes/bridge-hubs/bridge-hub-rococo/src/bridge_common_config.rs
Outdated
Show resolved
Hide resolved
…on-ahs-3-heads-sync
…on-ahs-3-heads-sync
…on-ahs-3-heads-sync
bkontur
force-pushed
the
bko-permlanes-on-ahs-3-heads-sync
branch
from
3cf9819 to
a246572
Compare
…on-ahs-3-heads-sync
@serban300 please, I updated description and also attached high-level diagram.
The current simplest expectation or assumption is that they could open a bridge/lane directly on the AssetHubs and use |
…on-ahs-3-heads-sync
…on-ahs-3-heads-sync
…ad' into bko-permlanes-on-ahs-3-heads-sync
@serban300 Please, check now: Fixed by 8d6f747 :) |
…on-ahs-3-heads-sync
paritytech#8326 paritytech#8325 Add proof root sync (`pallet-bridge-proof-root-sync`) as an ring buffer with on_idle callback Add `OnNewHead` to `pallet-bridge-parachains`
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
Relates to: #8326 Relates to: #6675 (Extracted from #8325) This PR introduces a new `OnNewHead` hook for `pallet-bridge-parachains`, which is triggered when a new parachain head is relayed. It will be used in conjunction with the [syncing mechanism](#8326), which sends relayed AssetHubRococo headers with `state_root`s to AssetHubWestend for message proof verification. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
6 participants
Implements: #5827
Relates to: #8325
Relates to: #8324
Relates to: #6675
Relates to: #5827
This PR introduces
pallet-bridge-proof-root-sync, which allows scheduling and sending arbitrary data (e.g.,para_id/HeadDatawithstate_root) using theon_idlehook.The pallet implements the
OnNewHeadhook for new AssetHubRococo parachain heads and is used to send and sync these headers from BridgeHubWestend to AssetHubWestend, where we need to validate message proofs from AssetHubRococo. This header data is sent to thepallet-bridge-proof-root-storedeployed on AssetHub see #8324.Note: This is a phase1 with XCM, later as phase2, we can do this off-chain with proofs, but for that we need: #7445 or other #5827 - for example to add a new extrinsic to
pallet-bridge-messageswhich will have two proofs:Parasblock/state root, for which we can generate proof of local BridgeHub'spallet-bridge-parachains'sImportedParaHeadsthat it contains bridged header hash / state rootThere are multiple alternatives for syncing parachain finality from BridgeHub to AssetHub, collected here: #5827. We chose the XCM approach because it is the simplest and doesn't require additional changes — such as custom
RelayChainStateProofdata or inherent providers for sibling para heads. Additionally, thepallet-bridge-proof-root-store, implemented as a simple ring buffer, is also useful for D-Day governance.High-Level Context Diagram