Polkadot <> Kusama Bridge

Ecosystem
26

Next steps focusing on post-launch

  1. Wallets to integrate these PAH <> KAH transfers, make it easy!
  2. Bring down that damn high bridge fee, more details here.
  3. Add permissioned way for parachains to open lanes between themselves without going through governance.
  4. [General XCM improvements] better XCM asset transfer UX overall, make it easy to send from any parachain on one side to any parachain on the other side, while transparently going through AssetHubs reserves under the hood :star_struck: .
24 Likes
27

Congrats! Nice work! :slight_smile:

3 Likes
28

Amazing to see. Congratulations to everyone involved!

1 Like
29

Awesome work guys!

1 Like
30

Awesome! Can you share the PAH to KAH Encoded call?

1 Like
31

I was playing around with the bridge today and got Dot from polkadot assethub > kusama assethub. I documented this here:

Video demo:

Pah > KAH call data:
0x1f08030202090300a10f03000101005400e2f7f5669b26998d8e4d3c1a2c8a2d0a9af827ca54a1cc3509105035c32e0304000100000700c817a8040000000000

Typescript generic xcm call for everyone that wants to check it out:

All the best,
~flipchan

5 Likes
32

Will XCM be generic (soon) or will it stay limited to limitedReserveTransferAsset?

If we’ll open a new lane between two parachains, will we be able to configure the Barrier and allow specific XCM messages like PalletXcm.send(
transact(encoded_call))

More concretely: Integritee decided to have the same TEER token on its Kusama and Polkadot chains. Transferring TEER from K->P should therefore not be a reserve transfer with a derivative issued on P, but instead TEER should be burned on K and minted on P such that the total supply of TEER matches the sum of the supply on P and K . AFAIU we could implement that if we had a custom lane and custom XCM msg.

33

If we’ll open a new lane between two parachains, will we be able to configure the Barrier and allow specific XCM messages like PalletXcm.send(
transact(encoded_call))

Definitely! Any XCM program can be sent over the bridge. This is even allowed for PAH<>KAH lane, DOT/KSM-only transfer artificial limitation comes from PAH and KAH having only KSM and DOT configured in their IsReserve filters.

Transferring TEER from K->P should therefore not be a reserve transfer with a derivative issued on P, but instead TEER should be burned on K and minted on P such that the total supply of TEER matches the sum of the supply on P and K . AFAIU we could implement that if we had a custom lane and custom XCM msg.

Yes, easiest setup is through dedicated bridge lane directly connecting your parachains. You don’t even need custom XCMs, you can use vanilla teleports and it’ll work beautifully.

1 Like
34

But to be clear, this is NOT possible yet, correct? Any estimate of timeline when this would be possible? We definitely are interested in setting up a lane between Moonriver and Moonbeam. :slight_smile:

35

But to be clear, this is NOT possible yet, correct? Any estimate of timeline when this would be possible? We definitely are interested in setting up a lane between Moonriver and Moonbeam.

Opening other para<>para lanes IS possible, but is an involved process:

  1. adding new lane id mapping to Bridge Hubs runtime code - lanes are currently hardcoded
  2. making the relevant XCM bridging configurations to your parachains
  3. run your own relayer (or rely on some community run one)

Once we will implement [V2 Bridges] Dynamic way of adding lanes (bridges between parachains) · Issue #2451 · paritytech/parity-bridges-common · GitHub, step #1 above where the parachains lane is hardcoded will be replaced by a runtime call requiring no dedicated code changes to BridgeHubs when opening/closing lanes.

1 Like
36

Amazing work @acatangiu and team, so excited to see this go live!

We’re currently working on implementing message tracking throughout the bridge journey and have a few questions:

  1. Would it be adequate to rely on lane ID and nonce to correlate bridged messages?

  2. Regarding the HRMP messages between Asset Hub <> Bridge Hub, could we presume that hashing the message ID of the XCM to be exported with ‘forward_id_for’ will result in the same ID used in the XCM in local consensus?

  3. Could you elaborate on the necessity of having different message IDs on the two consensus systems? It would simplify tracking to have a single ID for correlation purposes, so we’re curious why the ID is rehashed.

37

Thank you @acatangiu for the updates and the detailed tutorial.

Here is the PR on the Polkadot Wiki that provides an overview on Bridge Hub and Polkadot <> Kusama bridge. Bridge Hub preliminary docs by DrW3RK · Pull Request #5771 · w3f/polkadot-wiki · GitHub

@RustSyndicate Thanks for the video tutorial on BagPipes. I was successful in sending DOT to Kusama Asset Hub, but while selecting Kusama Asset Hub as the source chain, I do not see any assets listed in the dropdown. Is that a bug? Could you please resolve it so I can add the guide to the Polkadot Wiki? Thank you!

image
image811×977 59.2 KB

6 Likes
38

The Wiki docs on Bridge Hub, Polkadot < > Kusama Bridge are now live. Feel free to share widely and suggest changes/updates as needed, going forward!

5 Likes
39

hey @radha thanks for creating a wiki for bagpipes on the polkadot docs.

we will add kusama asset hub assets very shortly. :+1:

2 Likes
40

This weekend I built the PAPI Teleporter DApp, which can be used for teleporting DOT/KSM between Polkadot AH ↔ Kusama AH (among many other teleporting options). It’s also able to display the balances of those foreign assets, which I’m afraid that’s something that no other dApp is doing ATM.

The code of the DApp can be found here. I built this DApp because we needed a non-trivial example DApp for the imminent announce of the beta release of PAPI.

A few things about this DApp:

  • It only uses smoldot. Meaning, that it’s an actual decentralized application, which doesn’t rely on centralized servers.
  • It only uses the new JSON-RPC API, thanks to the fact that it’s built with Polkadot-API.
  • It’s an actual multichain dApp which is simultaneously connected to 8 different chains.
  • I have tested it quite a bit and I think that it works well. However, I have not tested all the possible permutations. So, please review your transactions before you sign/submit them. Please keep in mind that (for now) this is just a demo DApp built mostly during my spare time. It has not been properly tested (yet).
  • The connection with Rococo AssetHub is currently not working because I haven’t been able to find a single boot-node for Rococo AssetHub that runs over a TLS WebSocket connection. Unfortunately, Polkadot-SDK doesn’t yet support WebRTC connections, which means that the light-client (while running on the browser) can only communicate with WSS endpoints. I have reached to Parity to see if they can enable a WSS bootnode for Rococo AssetHub, and I think that this issue will be solved very soon.
  • We still don’t know how to properly calculate the fees for these kinds of teleported transactions. So, the fees that are displayed in the UI are the “normal” fees that we get by calling the TransactionPaymentCallApi_query_call_fee_details runtime-call. We would really appreciate some guidance on this matter. As as soon as we learn what is the proper way for calculating the fees of these “bridged teleported” transactions, we will update the UI accordingly. CC @acatangiu could you please help us out on this? :pray:

Please try it out and give us feedback! Thanks a lot!

24 Likes
41

@josep I can help test this and get the instructions added to the Polkadot Wiki.

FYI, withdrawals of wrapped DOT/KSM can only happen after 1.2 Bridge Hub preliminary docs by DrW3RK · Pull Request #5771 · w3f/polkadot-wiki · GitHub

1 Like
42

Ups! Well, then I will disable those right away. Thanks for letting me know that!

So, basically what you are saying is that I should temporarily disable the following 2 options:

  • Teleporting DOT from K-AH to P-AH
  • Teleporting KSM from P-AH to K-AH

I will keep those in the list, but I will disable the “Teleport” button with a message or something


Thanks!

PS: could we please not label them as “wrapped” :see_no_evil: :nerd_face:, though? IMHO they are not exactly “wrapped” :slightly_smiling_face:.

43

We added support in Ocelloids and our XCM tracker demo app for the P<>K bridge. We did some tests on Rococo<>Westend and here’s a screenshot of the full journey of the transfer:

rococo-westend-bridge
rococo-westend-bridge1326×968 148 KB

A short video with some simple explanations of the journey:

Happy bridging!

8 Likes
44

The tracker is awesome, and an important missing piece! Thank you @sodazone! :star_struck:

1 Like
45

Aaaaaand we found our first bug :see_no_evil: - don’t worry, it has no security implications :relieved:

Description

The on-chain GRANDPA light-client doesn’t correctly handle a corner case involving validator set changes that are triggered by validator slashing. Unfortunately, there is no validator slashing happening in Rococo or Westend so this bug surfaced only on the Polkadot <> Kusama deployment.

As a result of the bug, the Kusama GRANDPA light-client on Polkadot doesn’t recognize the Kusama validator set change and thus refuses to accept subsequent changes as well.

More technical details can be found in the PR description of the proposed fix.

Effect

Meaning the bridge is stuck for the Kusama → Polkadot direction.
Any transfer from AHK → AHP will get stuck in the bridge queues, but not lost.

Note: Polkadot → Kusama is (yet) unaffected.

Solution

The code fix has already been updated in polkadot-sdk.

To apply the fix on-chain we need to do a BH runtime upgrade so a runtime patch is being prepared in GitHub - polkadot-fellows/runtimes: The various runtimes which make up the core subsystems of networks for which the Fellowship is represented.

Unfortunately there is a Polkadot BH runtime upgrade (to 1.2.0) already under voting: https://polkadot.polkassembly.io/referenda/648, so we will have to wait for that to happen before applying a subsequent patch fix on top.

Solution ETA

ETA for deployment of fix. based on statistical duration of OpenGov upgrade path: 2-3 weeks.

UIs call-to-action

Please disable Kusama → Polkadot direction for your users, otherwise their funds will be stuck until the fix is deployed on-chain.

1 Like