Bridges - revert-back and improve congestion #6231
Conversation
|
bot fmt |
bkontur
force-pushed
the
bko-bridges-congestion
branch
2 times, most recently
from
659be89
to
b48b8a5
Compare
bkontur
force-pushed
the
bko-bridges-congestion
branch
from
a663bc2
to
cbc6ae7
Compare
|
bot fmt |
bkontur
force-pushed
the
bko-bridges-congestion
branch
from
c78f9bc
to
501a5c0
Compare
|
bot fmt |
bkontur
force-pushed
the
bko-bridges-congestion
branch
7 times, most recently
from
c78e707
to
152389a
Compare
|
bot fmt |
bkontur
force-pushed
the
bko-bridges-congestion
branch
3 times, most recently
from
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 |
bkontur
force-pushed
the
bko-bridges-congestion
branch
from
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 |
bkontur
force-pushed
the
bko-bridges-congestion
branch
from
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 |
bkontur
added
the
A4-needs-backport
| { | ||
| break; | ||
| } | ||
| bridges_to_update.push((bridge_id, previous_factor, bridge_state)); |
There was a problem hiding this comment.
Why not process it on the spot ?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Oh, yes, you're right. How about translate() ?
There was a problem hiding this comment.
hmm, it says that translate() iterates all elements (removes for None), so then we would not need this weight metering, which @franciscoaguirre reported here: #6231 (comment).
I think I've seen translate used only for migrations, I don't know :)
@serban300 so what do you suggest? if I want to also trigger events, should I do it inside translate function?
There was a problem hiding this comment.
I think I've seen
translateused only for migrations, I don't know :)
I don't know either. I never used translate. It just seemed to permit editing items on the spot.
@serban300 so what do you suggest? if I want to also trigger events, should I do it inside
translatefunction?
I guess so. I don't know. Is there a reason not to do it ?
| pub fn open_bridge( | ||
| origin: OriginFor<T>, | ||
| bridge_destination_universal_location: Box<VersionedInteriorLocation>, | ||
| maybe_notify: Option<Receiver>, |
There was a problem hiding this comment.
maybe_notify doesn't seem very suggestive. Maybe something like congestion_notif_receiver would be better.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
As far as I understand, the mechanism definitely works. It solves the congestion problem. But I don't like that it adds complexity and in some aspects we have to duplicate the XCMP congestion ideas.
Personally, I liked more the idea of adding XCMP logical channels and rely on the XCMP congestion logic. Not sure if it's still applicable or what happened to it.
Well, before the permissionless lanes PR, we used this exact mechanism with
Yes, we discussed HRMP/XCMP logical channels, but I think this is not part of the near, short or mid-term plan. Similarly, we discussed HRMP/XCMP protocol credits, but implementing that would require reworking the HRMP/XCMP queue system, which I would also say is not on the near, short or mid-term plan. Handling bridge congestion over XCMP is only half the story. The other important aspect is that we also want (and need) to manage bridge congestion beyond XCMP. We are moving towards deploying permissionless lanes directly on AssetHub (with just the messaging pallets). This approach would mean the following:
This PR essentially:
|
|
/cmd fmt |
|
Command "fmt" has started 🚀 See logs here |
|
Command "fmt" has finished ✅ See logs here |
…(check Xcmp, check UMP, ..)
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
|
/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-hubtopallet-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
ExportXcmlocally.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-hubandpallet-xcm-bridge-hub-routernow useBridgeIdto identify specific bridges, enabling selective suspension and resumption of individual bridge channels.Dynamic Congestion Detection:
pallet-xcm-bridge-hubnow includes callbacks forfn suspend_bridgeandfn resume_bridgebased on congestion status:xcm::Transact(report_bridge_status(bridge_id, is_congested))using the stored callback information.New Stop Threshold: A
stop_thresholdlimit inpallet-xcm-bridge-hubenables or disablesExportXcm::validate, providing a fallback mechanism when the router does not adhere to thesuspendsignal.Flexible Message Routing:
pallet-xcm-bridge-hub-routerhas 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.