-
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
Bridges - revert-back and improve congestion #6231
base: master
Are you sure you want to change the base?
Conversation
bot fmt |
659be89
to
b48b8a5
Compare
a663bc2
to
cbc6ae7
Compare
bot fmt |
c78f9bc
to
501a5c0
Compare
bot fmt |
c78e707
to
152389a
Compare
bot fmt |
edd9c5c
to
38f1bb3
Compare
/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
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 |
21baa7f
to
c00ff6b
Compare
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 --subcommand=xcm --runtime=bridge-hub-rococo --pallet=pallet_xcm_benchmarks::generic bot bench -v PIPELINE_SCRIPTS_REF=bko-fix cumulus-assets --runtime=asset-hub-westend --pallet=pallet_xcm_bridge_hub_router |
/cmd --clean |
bot clean |
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.
Did just a first pass
{ | ||
break; | ||
} | ||
bridges_to_update.push((bridge_id, previous_factor, bridge_state)); |
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 not process it on the spot ?
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 not process it on the spot ?
Well, at least for bridges_to_remove
I can't/shouldn't do that according to the documentation:
/// Enumerate all elements in the map in no particular order.
///
/// If you alter the map while doing this, you'll get undefined results.
I don't know, maybe inserting the same key with different value while iter
would work (I didn't try), but I assume that it is also "alter the map", so I better used the same pattern for bridges_to_update
.
// handle congestion and fee factor (if detected) | ||
let increased = | ||
Bridges::<T, I>::mutate_exists(&bridge_id, |bridge_state| match bridge_state { | ||
Some(ref mut bridge_state) if bridge_state.is_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.
Nit: Something like
if !bridge_state.is_congested
return None;
seems easier to follow
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 here: 416e2e0 to process everything on the spot as you requested in the previous comment.
@serban300 I am not sure how to fix this, is this still relevant? Could you please provide more verbose suggestion?
/// Notification about congested bridge queue. | ||
#[pallet::call_index(0)] | ||
#[pallet::weight(T::WeightInfo::report_bridge_status())] | ||
pub fn report_bridge_status( |
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.
Nit: Would update_bridge_status()
be more suggestive ?
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.
report_bridge_status
is the original name, which I am reverting back (it was removed here: https://github.com/paritytech/polkadot-sdk/pull/4949/files#diff-9c9793c594a3cd93997c4b8fb651bd250d49b1b85068cd555aaf8c0809b500e1L158).
Well, I am ok with "report" in this case - somebody (pallet_xcm_bridge_hub
) is just telling us that it has problem with congestion or not. Actually, yes, the pallet_xcm_bridge_hub_router
updates some state, but it is just implementation detail. The pallet_xcm_bridge_hub
does not need to reason about this if it is update or whatever.
pub fn open_bridge( | ||
origin: OriginFor<T>, | ||
bridge_destination_universal_location: Box<VersionedInteriorLocation>, | ||
maybe_notify: Option<Receiver>, |
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.
maybe_notify
doesn't seem very suggestive. Maybe something like congestion_notif_receiver
would be better.
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.
Well, actually, I re-used maybe_notify
name/pattern from the pallet_xcm's QueryStatus
maybe_notify: Option<(u8, u8)>,
:), which does exactly the same, Receiver
is basically the same as (u8, u8)
.
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.