-
Notifications
You must be signed in to change notification settings - Fork 694
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
Bridges - revert-back and improve congestion #6231
base: master
Are you sure you want to change the base?
Conversation
bot fmt |
/cmd prdoc --audience runtime_dev --bump patch --force |
659be89
to
b48b8a5
Compare
a663bc2
to
cbc6ae7
Compare
bot fmt |
c78f9bc
to
501a5c0
Compare
bot fmt |
c78e707
to
152389a
Compare
bot fmt |
900bbec
to
ca24d6c
Compare
/cmd fmt |
edd9c5c
to
38f1bb3
Compare
/cmd --help |
/cmd bench --runtime asset-hub-westend asset-hub-rococo --pallet pallet_xcm_bridge_hub_router |
bot bench cumulus-assets --runtime=asset-hub-westend --pallet=pallet_xcm_bridge_hub_router |
f06433a
to
d329dec
Compare
/cmd fmt |
bot bench -v PIPELINE_SCRIPTS_REF=bko-fix cumulus-assets --runtime=asset-hub-westend --pallet=pallet_xcm_bridge_hub_router bot bench -v PIPELINE_SCRIPTS_REF=bko-fix cumulus-bridge-hubs --runtime=bridge-hub-rococo --pallet=pallet_bridge_messages |
bot bench -v PIPELINE_SCRIPTS_REF=bko-fix cumulus-bridge-hubs --runtime=bridge-hub-rococo --pallet=pallet_bridge_messages |
/cmd fmt |
Command "fmt" has started 🚀 See logs here |
Command "fmt" has finished ✅ See logs here |
/// This function ensures that the `local_origin` matches the expected `Location::here()`. If | ||
/// the check passes, it updates the bridge status to congested. |
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 does this have to be Location::here()
?
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 bp_xcm_bridge_hub::LocalXcmChannelManager<BridgeIdOf<T, I>> for Pallet<T, I>
implementation only makes sense when the pallet_xcm_bridge_hub_router
instance is deployed in the same runtime as pallet_xcm_bridge_hub
and/or used with HereOrLocalConsensusXcmChannelManager
.
Essentially, this implementation will be used with HereOrLocalConsensusXcmChannelManager
when both pallets are deployed on AssetHubs:
pallet_xcm_bridge_hub
will serve permissionless lanes for sibling parachains and useReportBridgeStatusXcmChannelManager
(which sends XCM to the sibling) for congestion.- The deployed
pallet_xcm_bridge_hub_router
on the sibling will be sendingExportMessage
.
- The deployed
pallet_xcm_bridge_hub
will also serve permissionless lanes created for the AssetHub (Location::here()
) and use the router'sbp_xcm_bridge_hub::LocalXcmChannelManager<BridgeIdOf<T, I>> for pallet_xcm_bridge_hub_router::Pallet<T, I>
implementation for direct congestion management.- The deployed
pallet_xcm_bridge_hub_router
on the AssetHub will triggerpallet_xcm_bridge_hub
ExportXcm
withUnpaidLocalExporter
.
- The deployed
// if not congested anymore, we can start to decreasing fee factor | ||
if !bridge_state.is_congested { | ||
let previous_factor = bridge_state.delivery_fee_factor; | ||
let new_factor = previous_factor / EXPONENTIAL_FEE_BASE; |
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.
Is there some safe division we could use here? I'm a little bit spooked by the loop in on_initialize 😅
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.
We use this division by non-zero const for XCMP, UMP, DMP also.
I have another follow-up TODO for refatoring FeeTracker/PriceForDelivery
to reuse here, so I will check better saturating/checked_div there also
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
/cmd fmt |
Command "fmt" has started 🚀 See logs here |
Command "fmt" has finished ✅ See logs here |
Closes: #5551
Closes: #5550
Context
Before permissionless lanes, bridges only supported hard-coded, static lanes. The congestion mechanism was based on sending
Transact(report_bridge_status(is_congested))
frompallet-xcm-bridge-hub
topallet-xcm-bridge-hub-router
. Depending onis_congested
, we adjusted the fee factor to increase or decrease fees. This congestion mechanism relied on monitoring XCMP queues, which could cause issues like suspending the entire XCMP queue rather than just the affected bridge.Additionally, we are progressing with deploying bridge message pallets/routing directly on AssetHub, where we don’t interact with XCMP to perform
ExportXcm
locally.Description
This PR re-introduces and improves congestion for bridges:
Enhanced Bridge Congestion Mechanism: The bridge queue mechanism has been restructured to operate independently of XCMP, with a refined protocol for congestion detection and suspension management.
Bridge-Specific Channel Suspension:
pallet-xcm-bridge-hub
andpallet-xcm-bridge-hub-router
now useBridgeId
to identify specific bridges, enabling selective suspension and resumption of individual bridge channels.Dynamic Congestion Detection:
pallet-xcm-bridge-hub
now includes callbacks forfn suspend_bridge
andfn resume_bridge
based on congestion status:xcm::Transact(report_bridge_status(bridge_id, is_congested))
using the stored callback information.New Stop Threshold: A
stop_threshold
limit inpallet-xcm-bridge-hub
enables or disablesExportXcm::validate
, providing a fallback mechanism when the router does not adhere to thesuspend
signal.Flexible Message Routing:
pallet-xcm-bridge-hub-router
has been refactored to support message routing for both sibling chains (ExportMessage
) and local deployment (ExportXcm
).These updates improve modularity, allow more granular bridge congestion handling, and support diverse deployment scenarios.