BridgeHub related issues

[hqwangningbo]

1. Will parachain be able to open hrmp with BridgeHub in the future?
2. Do cross-assets between parachains of kusama and polkadot have to go through AssetHub?

It seems to me that if parachain and BridgeHub opened hrmp, this would allow direct cross-chaining like AssetHub does.

[bkchr]

Cc @acatangiu

[svyatonik]

TLDR: Yes, in the future by opening HRMP channels with sibling Bridge Hub (BH) and by doing some additional actions there (at BH), you will be able to connect two parachains together, without requiring your messages/funds to go through the Asset Hub (AH). However, initially (in upcoming initial deployment) you won't be able to do that - we'll only have a hardcoded communication channel (bridge) between two AHs. So all communication in the beginning is the communication between two AHs, no other paracahains allowed.

You can track the progress here: paritytech/parity-bridges-common#2451

---

Some details on how we currently plan to implement that (BTW, some code is already available in 'bridges v2' branch, which is just our master: https://github.com/paritytech/parity-bridges-common/blob/master/modules/xcm-bridge-hub/src/lib.rs). To open bridge between some Kusama Parachain KP and Polkadot Parachain PP, you'll need to:

0. open HRMP channels between your parachains and sibling BHs (KP <> Kusama BH and PP <> Polkadot BH);
1. agree on opening the bridge offchain. We do not manage that, but in order your bridge to work, you'll need to talk to the other side and coordinate your actions;
2. put enough funds on sovereign accounts of KP on Kusama BH and of PP on Polkadot BH. When you'll open the bridge, we'll reserve those funds. They'll stay reserved until you'll close the bridge or violate some bridge rules (the set or rules is not yet properly designed, but think of it as: you keep sending messages, theu pile up at BH and are not relayed to the other side of the bridge). In the latter case, we'll slash reserved funds and close the bridge. In the former case, you'll simply get your funds back when the bridge is oficially closed (closing procedure is also a bit WIP);
3. call the open_bridge function over XCM and make sure your counterpart does the same;
4. make sure someone runs a relayer (an offchain process, which delivers messages from one chain to another) for your bridge. We have some incentivization for relayers (paid by the bridge owner), so it can be you, your counterpart or someone else. But you need to make sure that such relayer exists. Not runnning a relayer for a while (design wip) is a violation of bridge rules;
5. at this point, you may start safely sending messages between KP and PP.

Once you don't want the bridge, you and/or your counterpart may call the close_bridge function at their sibling BH and eventually (when we see that there are no more queued messages left), you'll get your reserved funds back.

As you see, most of yet WIP things ^^^ is about designing and implementing a set of "bridge rules". The main goal here is to ensure that parachains are using bridge hub responsibly (e.g. not flooding BH with thousands of messages and hence bloating its runtime storage size) and care about their own messages delivery (running a relayer). Other than that, everything is pretty clear.

[hqwangningbo]

@svyatonik Thanks for the answer, is there support for tokens across parachain possible between the two AssetHubs then? Only DOT and KSM are supported as far as I can remember.

[svyatonik]

@svyatonik Thanks for the answer, is there support for tokens across parachain possible between the two AssetHubs then? Only DOT and KSM are supported as far as I can remember.

Yes, DOT and KSM initially with USDT addition soon after that. Re other tokens - IIRC we've been working on sufficient token transfers so far, so there's not much other tokens to support left (to my knowledge). But in any case until 'bridges v2' adding more tokens will be a manual process, which would require BH runtime upgrades and (maybe) some changes to xcm pallets/infrastructure. It may also interfere with upcoming liquidity pools (don't know when they'll be added to K/P runtimes), so it could be even harder than just doing some code changes.

But in any case - please let us know how you're planning to use the bridge and, if that's just some tokens, which tokens exactly you want to see supported. Thank you!

[hqwangningbo]

Both Bifrost kusama and Bifrost polkadot network tokens are BNC, at the moment our cross-chain solution is only available via CEX, now we want to do it via BridgeHub custom XCM messages (Withdraw---Deposit).
Do you have any suggestions on how to do this, we want to get rid of CEX as soon as possible, even if we can't use BridgeHub for a while, AssetHub would be a good choice.

[svyatonik]

Do you have any suggestions on how to do this

Yeah, as I said above, you won't be able to do that after initial deployment (KSM <> DOT and USDT soon). But thank you for letting us know your case - we'll need to talk about that within a team to maybe rearrange our priorities.

If you want to experiment yourself locally , you may tweak Polkadot and Kusama Asset Hubs runtime configs meanwhile. In particular, you may be interested in XCM + bridges configuration (e.g. Kusama AH: https://github.com/polkadot-fellows/runtimes/blob/main/system-parachains/asset-hubs/asset-hub-kusama/src/xcm_config.rs#L746-L815), which holds the set of tokens you may transfer between Asset Hubs.

[hqwangningbo]

Thanks, I'll do a local test.

[acatangiu]

Thanks for the answer, is there support for tokens across parachain possible between the two AssetHubs then? Only DOT and KSM are supported as far as I can remember.

KSM and DOT are configured in Asset Hubs to go over bridge, we will run with this for a short while to see everything works well. Afterwards, it's just a matter of Asset Hub configuration to allow other assets as well.

Both Bifrost kusama and Bifrost polkadot network tokens are BNC, at the moment our cross-chain solution is only available via CEX, now we want to do it via BridgeHub custom XCM messages (Withdraw---Deposit). Do you have any suggestions on how to do this, we want to get rid of CEX as soon as possible, even if we can't use BridgeHub for a while, AssetHub would be a good choice.

You will be able to do that soon(ish) through AssetHubs. Shortest path I see is register BNC on AssetHubs as ForeignAssets. AH can then act as reserve of BNC over the bridge. BNC will be teleportable between local Bifrost and local AssetHub.

https://polkadot.network/blog/fungible-assets-on-asset-hub

[hqwangningbo]

@acatangiu If BNC is used as ForeignAssets on AssetHubs, which method will be used to cross-chain between AssetHubs (teleports or reserves)?
We hope that BNC of the two networks will be fungible token, both use Balances module. Can the following two paths be achieved?

1. Bifrost Polkadot ->(teleport to) AssetHub Polkadot ->(teleport to) AssetHub Kusama -> (teleport to) Bifrost Kusama
2. Bifrost Kusama ->(teleport to) AssetHub Kusama ->(teleport to) AssetHub Polkadot ->(teleport to) Bifrost Polkadot

[hqwangningbo]

I once tested it locally. Bifrost sent XCM messages directly to BridgeHub, which enabled Bifrost Kusama and Bifrost Polkadot to cross BNC (teleports). The results were great. So I hope it can also be achieved with AssetHub.

[acatangiu]

@acatangiu If BNC is used as ForeignAssets on AssetHubs, which method will be used to cross-chain between AssetHubs (teleports or reserves)?

All transfers between the two asset hubs are reserve-based. The reason for that is we do not want (yet) to completely trust the other AssetHub (e.g. any Kusama Asset Hub issue or security problem should not extend blast radius to Polkadot Asset Hub).

We hope that BNC of the two networks will be fungible token, both use Balances module.

From Kusama/Polkadot AH point of view, the two are not/cannot be fungible, they are coming from different chains on different ecosystems. BUT, you can definitely treat them as fungible in Kusama/Polkadot Bifrost chains.

Can the following two paths be achieved?

1. Bifrost Polkadot ->(teleport to) AssetHub Polkadot ->(teleport to)  AssetHub Kusama -> (teleport to) Bifrost Kusama

2. Bifrost Kusama ->(teleport to) AssetHub Kusama ->(teleport to) AssetHub Polkadot ->(teleport to) Bifrost Polkadot

I think this would be a better possible path/flow:

1. Bifrost Polkadot ->(teleport pBNC to) AssetHub Polkadot ->(reserve-transfer pBNC to) AssetHub Kusama -> (teleport pBNC to) Bifrost Kusama (here pBNC is recognized/treated same as kBNC, both managed by pallet-balances)
2. Bifrost Kusama ->(teleport kBNC to) AssetHub Kusama ->(reserve-transfer kBNC to) AssetHub Polkadot ->(teleport kBNC to) Bifrost Polkadot (here kBNC is recognized/treated same as pBNC, both managed by pallet-balances)

Ultimately, I think you can hide the difference between pBNC and kBNC in your chain so, on Bifrost chains, users see everything as BNC (on AHs they still see them as different pBNC and kBNC).

[acatangiu]

If you open direct channel/lane over the bridge between Bifrost chains (not go through AH), you can directly teleport between your two chains and have single asset everywhere.

1. Bifrost Polkadot ->(teleport to) Bifrost Kusama
2. Bifrost Kusama ->(teleport to) Bifrost Polkadot
   (actual XCM goes through BHs, but that's just backend implementation details)

[hqwangningbo]

@acatangiu Thanks for your answer, I understand. I will continue to pay attention to the progress of the bridge and hope to realize it as soon as possible.

[lurpis]

If you open direct channel/lane over the bridge between Bifrost chains (not go through AH), you can directly teleport between your two chains and have single asset everywhere.

1. Bifrost Polkadot ->(teleport to) Bifrost Kusama
2. Bifrost Kusama ->(teleport to) Bifrost Polkadot
   (actual XCM goes through BHs, but that's just backend implementation details)

@acatangiu Thank you for your assistance. This is the ideal solution for BNC to cross-chain between Bifrost Kusama <> Bifrost Polkadot, and we have tested it in the local env successfully, but the current problem is the unexpected launch point of bridge hub v2. We hope it will be pushed to launch soon.

[acatangiu]

It is planned for Q2 this year: https://github.com/orgs/paritytech/projects/27/views/11