Polkadot <> Kusama Bridge

Ecosystem
1

Opening this thread to provide updates and gather ecosystem feedback on the incoming Polkadot <> Kusama bridge :bridge_at_night:

3 Likes
2

Some P<>K bridge updates

Rococo<>Wococo

  • BridgeHubRococo parachain (BHR) and BridgeHubWococo parachain (BHW) merged to cumulus and live on Rococo and Wococo - the live runtimes include all bridge pallets with full functionality
  • Bridge Relayers are deployed and live for bridging BHR<>BHW
  • Asset transfer fully working between Rockmine2 and Wockmint - not yet merged because Rockmine2 is actually Statemine runtime code deployed on Rococo so we will only be able to merge this after full audit - but the custom runtimes are deployed on live R<>W from this branch
  • Bi-directional asset transfers use XCM Reserve Asset Transfer underneath, but are exposed through transfer_asset_via_bridge extrinsic/call from the bridge-transfer pallets deployed on both Rockmine2 and Wockmint
  • TLDR is R<>W bridge fully up and running, including asset transfer between Rockmine2<>Wockmint
  • Security audit is under way; once we finish that, we want to run a public bug bounty on R<>W bridge

Polkadot<>Kusama

  • BHP and BHK system parachains are live producing empty blocks (no bridging pallets deployed yet)
  • BHP and BHK runtimes full bridging configuration is done (PR here) currently pending review and security audit
  • Statemine and Statemint runtime changes are also ready (PR here) currently pending review and security audit
  • Full BHP & BHK development & deployment plan is detailed under this milestone
  • TLDR is once we complete R<>W security audit and Bug Bounty we’ll start deploying P<>K bridge

Demo

R<>W asset transfer demo coming very soon.

Roadmap

We have created this roadmap where each card is an important milestone containing all the juicy details within.

Big shout-out to the bridges team :heart: for all the good progress here, with a very special thanks to @bkontur and @svyatonik for delivering by the truckload :metal:

18 Likes
3

As you already know we are now able to move assets between different (substrate2substrate) consensuses (reserve-based transfer).

On Rockmine2 (Statemine runtime on Rococo parachain), we can do asset transfer with dedicated extrinsic for bridge transfer (bridgeTransfer) using the transferAssetViaBridge call.
We need to choose what kind of asset we want to transfer (in this case Concrete representing the Source Asset), the amount and the destination account - in this case Wockmint, a parachain on Wococo (cross-consensus transfer) - and specifying the AccountId of our Wockmint user.

ASTT - Rockmine 2
ASTT - Rockmine 21348Ă—931 70.1 KB

On Rockmine2 we will see the events from the extrinsic: The fact that we reserved the assets, the amount, and that the transaction was initiated.

ASTT - ROCKMINE EVENTS
ASTT - ROCKMINE EVENTS847Ă—196 21 KB

BridgeHubRococo accepts the message and places it in its outbound queue to be relayed to BridgeHubWococo.

ASTT - RBH
ASTT - RBH847Ă—196 12.1 KB

Message is relayed and BridgeHubWococo accepts the message and sends/dispatches it through xcmp to Wockmint.

ASTT - WBH
ASTT - WBH840Ă—164 17.4 KB

In Wockmint we will see the events from the extrinsic: transfer succeeded, Message was received, assets have been placed in the asset trap and foreignAssets (wrapped Source chain assets) were issued.

ASTT WOCKMINT
ASTT WOCKMINT840Ă—164 12.5 KB

Note: Wrapped tokens (ROCs) were created by Wococo governance calls using the forceCreate call on foreignAssets extrinsic, so that Wockmint can receive ROCs from Rockmine2.

5 Likes
4

Hi everyone,

Here is what we have been up to lately:

Audit

  1. P<>K Bridge audit In Progress
  2. Beefy audit In Progress

Bug Bounty

We are actively working on defining a Bug Bounty for P<>K Bridge.

BEEFY On Kusama

We are preparing BEEFY to go live on Kusama: Enable BEEFY on Westend and Kusama by acatangiu · Pull Request #7591 · paritytech/polkadot · GitHub

Asset Transfer

We took the decision of extending the functionality of pallet_xcm:reserve_transfer_asseets to work for different consensus. Instead of having a dedicated extrinsic we will now be using the standard way of how to do “reserve based transfer assets” in “polkadot” between xcm-capable chains (like AH on Polkadot and AH on Kusama).

As mentioned above we extended xcm routing configuration for AssetHubs to be able to do this kind of transfer over bridge to different consensus, so for end user nothing is changed, they use “reserve based transfer” like they are used to, but now they have possiblity to choose destination from different consensus.

Dynamic Fees

We have been working on implementing dynamic fees. Why?

Fees are paid to avoid spam. If the fees are large, the bridge is unusable. If fees are small, then anyone can send multiple messages with relatively small cost and fill up the bridge queues. That means we needed something that adapts to the state of the bridges queues.

If they are not congested, we want smaller fees and if there’s a lot of messages in the queues, we want larger fees for further messages.

Acronyms:

Source - source relay chain;
Target - target relay chain;
Source Parachain and Target Parachain - parachain within the Source/Target relay chain consensus;
AH - asset hub;
BH - bridge hub.

Let’s consider the only bridge we’ll have initially - the bridge that allows messages exchange between two asset hubs.
There are following queues in the over-bridge message pipeline:

Source AH → Source BH HRMP queue;
Source BH → Target BH bridge queue;
Target BH → Target AH HRMP queue.

Our initial plan was to use the backpressure mechanism - if at least one of queues in the pipeline is congested, we start piling up messages at the previous queue.
So eventually messages will start piling up at the Source AH. When Source AH sees that, it’ll start raising the fee for every following message. Eventually, queues become uncongested (because the old messages are delivered and new messages become more expensive), when the uncogenstion happens, fees will start lowering again.

To realize that, we’ve added the backpressure mechanism to the Source BH → Target BH bridge queue: if there’s a lot of messages in the Target BH → Target AH, we stop accepting new messages.

Delivery transaction and messages are piling up at the Source BH. Once there’s a lot of messages there, we suspend processing inbound messages from the Source AH.

This will eventually lead to Source AH → Source BH HRMP channel suspension, which is the goal. Detailed picture: BridgeQueuesPicture · GitHub

However, it doesn’t work well if we’ll have the Ethereum bridge, or other bridges enabled. Then e.g. if Source BH → Target BH relayer is not working, then the Ethereum bridge also halts.
That’s because Source AH → Source BH channel is used by both bridges and we are suspending this channel.
The “proper” fix for that is to implement logical channels over single physical HRMP channel, but we don’t want to do that now.

So the alternative idea is not to suspend the Source AH → Source BH channel, but instead when the Source BH realizes that the bridge queue is congested, it sends the “congested” XCM message to the Source AH.
Once Source AH receives the message, it starts increasing the fees for further messages.

Let us know if you have any questions.

4 Likes
5

Hi all,

Dropping an update on what we’ve been busy with:

  • We’re implementing fishermen for both bridges to watch for equivocations and enforce slashing
    • P<>K GRANDPA fishermen are merged pending audit verification (2338, 2348, 2367, 2507, 2555)
    • P<>ETH BEEFY new equivocation API + (basic) fishermen implementation PR is up and pending review (1329)
  • Started efforts into moving our bridge overnight tests setup from Rialto<>Millau to Rococo<>Wococo, first critical step:
    • Add asset-hub-rococo dedicated runtime based on asset-hub-kusama and add asset-bridging support to it (under review) (1215)

P<>K bridge & asset transfer

  • Finished asset transfer using pallet-xcm (2762)
  • Implemented dynamic fees using back pressure and congestion messages (2294)
  • Integrated dynamic fees into cumulus PRs (2997, 3001)
  • Integrated all the above in consolidated polkadot-sdk PR (1352) - we are now code-complete and undergoing new round of audit
  • Enhancing pallet-xcm with full support of reserve-based asset transfers (in progress) (1430)

BEEFY

  • BEEFY audit is complete with no security issues
  • Merged support for BEEFY on Kusama & Westend (7591)
  • Awaiting new node release and new Kusama runtime release
    • then will coordinate with validators to register their BEEFY keys
    • then will submit governance motion to enable/start BEEFY consensus on Kusama
6 Likes
6

Progress update:

P<>K bridge & asset transfer

  • Security audit of the bridge (both transport protocol and XCM asset transfer functionality) is complete and all findings fixed :tada:
  • Latest version of the code (containing above) PR#1215 should be merged any day now and then everything deployed to testnets :bridge_at_night:
  • Public Bug Bounty (running on testnets) will start shortly after :mag_right::beetle:
  • Enhancing pallet-xcm reserve transfers to support remote reserves PR#1672 - needs reviews
  • Polkadot & Kusama (and their system parachains) runtimes have moved to polkadot-fellowship - meaning we need to migrate all bridge changes there.

BEEFY

8 Likes
7

P<>K Bridge & asset transfer

  • Bridge code-complete, XCM support over bridge code-complete, security audit complete
  • Code mentioned above PR #1215 deployed and live on Rococo & Westend AssetHubs and BridgeHubs
  • Reserve-backed asset transfer supported over bridge (at this stage, just for ROC and WOC) between AssetHubRococo <> AssetHubWestend. Supported using custom XCMs or by simply using pallet_xcm::limited_reserve_transfer_assets() extrinsic.
  • Public Bug bounty will be launched in the next couple of weeks.
  • [In-progress] adding required equivalent changes to Polkadot and Kusama AssetHubs and BridgeHubs under polkadot-fellows/runtimes.

Related or in-progress

  • Completed and merged enhancing pallet-xcm to support remote reserves PR #1672
  • Hardened pallet-xcm against unintended side-effects on errors PR #2405
  • Added xcm-emulator scenarios testing assets transfers over the bridge between Rococo and Westend PR #2251
  • In-progress building docker containers with zombienet + polkadot, polkadot-parachain and substrate-relay binaries that can automate bridge testing
  • In-progress supporting fully versioned XCM flow over bridge PR #2719

BEEFY

  • BEEFY deployed on-chain on Kusama
  • Helping and monitoring for 2/3 of the validators to rotate their keys.
  • Once we get healthy threshold above, BEEFY will be enabled.
  • Also working on performance improvements for MMR ancestry proofs
  • BLS crypto support is merged: PR #1705 and PR #1815, support for it to be later added to BEEFY.
3 Likes
8

Polkadot <> Kusama Bridge

P<>K bridge launch

  • Security Audit on final configurations in Polkadot and Kusama runtimes is under way.
  • We need to do runtime upgrades:
    • BridgeHub Kusama upgrade to spec version 1001000,
    • AssetHub Kusama upgrade to spec version 1001000,
    • BridgeHub Polkadot upgrade to spec version 1001000,
    • AssetHub Polkadot upgrade to spec version 1001000.
  • We will start on governance proposals for configuring bridge parameters then enabling it.

Beefy

5 Likes
9

Just curios, is Polkadot <> Kusama bridge live (either on testnet or mainnet).

10

Yes, the bridge is live bridging Rococo <> Westend testnets. It is deployed on Rococo Bridge Hub and Westend Bridge Hub chains, and is configured to bridge XCM messages between Rococo Asset Hub and Westend Asset Hub. Meaning you can use XCM to transfer ROC and WND from AHR to AHW and vice-versa.

The same capabilities will be deployed on Polkadot and Kusama as soon as the on-chain runtimes are upgraded to Release Runtimes 1.1.2 · polkadot-fellows/runtimes · GitHub releases.
Configuring and enabling the bridge on Polkadot and Kusama also requires governance calls which add some time.
My estimate for being live is within first half of March.

1 Like
11

thanks for the info :slight_smile:

13

I full heartedly agree with all that you said, with the correction that it is not using IBC.

The underlying transport protocol used by the P<>K bridge is similar to IBC in that it’s completely trustless (based on on-chain light clients), but the upper application protocol is using the more generic and extensible XCM protocol which allows generic cross-chain programs to be remote executed.
This makes the P<>K bridge (and other XCM powered bridges) much more useful in terms of what can be done over them (beyond token transfers).

18

Updates

P<>K Bridge

  • Polkadot AssetHub spec_version: 1001002 and Polkadot BridgeHub spec_version: 1001000 containing bridging capabilities has been enacted on-chain today :bridge_at_night: .
  • Kusama AssetHub spec_version: 1001002 and Kusama BridgeHub spec_version: 1001000 containing bridging capabilities had been enacted on-chain since a couple of weeks :bridge_at_night: .
  • The two above combined means we can launch the bridge :rocket: .
  • Starting to prepare governance motions to configure and enable the bridge :judge:.

BEEFY

  • Kusama: BEEFY consensus :cut_of_meat: started today on Kusama, now live :tada: .
  • Polkadot spec_version: 1001002 containing BEEFY capabilities enacted on chain.
  • Polkadot Validators :construction_worker_man: need to rotate their keys to register their BEEFY :cut_of_meat: keys.
    • once we reach healthy percentage of validators with valid BEEFY keys, we can enable on Polkadot too.

FAQs

Answering some FAQs here:

only KSM & DOT supported initially - how are additional assets added? What is the time frame for such additions? would be excellent to get USDT (Polkadot AH) on Kusama ASAP

Other assets can be easily (but has to go through governance) added and they will be added on a per-request basis after the bridge launch - USDT to Kusama is high on our list and will be among the first to be added.

the cost to send XCMs across bridge is 2.4 DOT or 0.4 KSM (depending on direction) - that seems rather high, is there a TLDR as to why its much higher than e.g. standard XCM and if there’s scope for that being lowered long term?

There is a cost analysis available here.

The high cost is coming from the trustless property of the bridge - all the proofs required to be submitted on-chain are pretty big and thus pretty costly.
The cost of a single XCM sent across has some “bridge transport base” + XCM costs, where the bridge base is a big chunk (all the state/consensus proofs required) which is also rather fixed - so a simple XCM costs approximately the same as a complex/big XCM.
So one of the first workarounds available to users since Day 1 is to try to batch multiple operations in single XCM, thus lowering per-operation cost.

There is definitely scope to lower costs long term, but no work is scheduled/budgeted on this topic yet.
We’re looking to You - the Polkadot community - to decide where to focus our resources. Improvements in this area come with non-negligible development cost, so we first want to see how much of a pain point the current (high) fees really are, and make a data-driven cost-benefit analysis.

3 Likes
19

Initialization proposal is on OpenGov: Initialize Kusama GRANDPA light-client running on Polkadot BridgeHub | Polkassembly

1 Like
20

Yes, public referendums for initializing the P<>K bridge are up:

21

The activation proposals passed! What’s the next steps?

22

There refs up to fund both sides

Fund system chains sovereign accounts on Polkadot BridgeHub for Polkadot<>Kusama bridge | Polkassembly (deciding)
Fund system chains sovereign accounts on Kusama BridgeHub for Polkadot<>Kusama bridge | Polkassembly (already passed)

Once these are both executed it should be ready - however I don’t believe there is a UI yet to facilitate use transfers of assets.

1 Like
23

image :smirk:

1 Like
24

image
the horror

2 Likes
25

Bridge is running LIVE! :rocket: :bridge_at_night: :tada:

Polkadot Bridge Hub <> Kusama Bridge Hub transport protocol

GRANDPA light-clients of both Polkadot and Kusama running on the two BridgeHubs have been initialized and are currently being synced live by a Parity-run permisionless relayer :mailbox_with_mail: .

The consensus proving logic (light clients), parachain heads proving logic and messages proving logic are all running on-chain in BridgeHubs runtimes, controllable exclusively by Polkadot/Kusama Governance :judge: .

This means Polkadot and Kusama are currently following each other’s chain progress and importing messages from the other side in a trustless manner :muscle: .

The relayer protocol and its incentivization mechanism are meant to encourage and foster community-run permisionless relayers, targeting a decentralized and robust relayer network :capital_abcd:.

In fact, :index_pointing_at_the_viewer: can run a relayer yourself by following this guide.

Initially the bridge has a single opened “lane” servicing XCM communication between Polkadot Asset Hub and Kusama Asset Hub. However, it supports opening other lanes between other parachains on opposite sides of the bridge (you can conceptually think of a bridge lane, like an HRMP channel between two parachains, but from different consensus systems).

Polkadot Asset Hub <> Kusama Asset Hub XCM asset transfers

The PAH<>KAH bridge lane supports basically any XCM, but PAH and KAH runtimes have been configured to only accept DOT & KSM transfers back and forth (for now) :handshake: .
Soon enough, stablecoins will be allowed as well. Then later, opened up to any Asset owner to register their asset as a ForeignAsset on the remote Asset Hub just as they would on the local Asset Hub.

DEMO: KSM transfer from KAH to PAH

On Day 1, only UIs available:

  • Manual crafting of XCM transfer :nerd_face: :face_with_raised_eyebrow:
  • PJS pallet_xcm extrinsic (hey, it’s better than nothing :man_shrugging: )

Crafting the transfer from KAH to PAH

  • Destination (dest) is Polkadot Asset Hub: { parents: 2, X2(GlobalConsensus(Polkadot), Parachain(1000)) },
  • beneficiary is my account on PAH,
  • assets is KSM: { parents: 1, Here },
  • using same KSM for fees.

E.g. Encoded call: 0x1f08030202090200a10f03000101002cb783d5c0ddcccd2608c83d43ee6fc19320408c24764c2f8ac164b27beaee370304000100000700e87648170000000000

1-transfer-xt-1
1-transfer-xt-11047Ă—1230 86 KB

1-transfer-xt-2
1-transfer-xt-21044Ă—1025 78.1 KB

Following execution of above:

on Kusama Asset Hub:

  • KSM transferred from my account to PAH sovereign account on KAH :bank:
  • (Expensive) Bridge transfer fees paid from my account to Treasury :money_with_wings:

2-KusamaAssetHub-events-list
2-KusamaAssetHub-events-list1494Ă—584 86.6 KB

2-KusamaAssetHub-events-details
2-KusamaAssetHub-events-details480Ă—660 41.5 KB

on Kusama Bridge Hub

  • Message added to outbound queue for exporting to Polkadot Bridge Hub

3-KusamaBridgeHub-events-details
3-KusamaBridgeHub-events-details1103Ă—588 55.8 KB

on Polkadot Bridge Hub

  • Message imported/received, then sent over XCMP to destination: Polkadot Asset Hub

4-PolkadotBridgeHub-events-details
4-PolkadotBridgeHub-events-details1077Ă—1210 119 KB

on Polkadot Asset Hub (intended destination)

  • Foreign asset KSM issued to my account :moneybag:

5-PolkadotAssetHub-events-details
5-PolkadotAssetHub-events-details999Ă—823 64.6 KB

Finally, after all this time, I have Liquid status for KSM on Polkadot Asset Hub :cowboy_hat_face: :joy:

6-PAH-final-balance
6-PAH-final-balance1463Ă—927 99.8 KB

49 Likes