Opening this thread to provide updates and gather ecosystem feedback on the incoming Polkadot <> Kusama bridge
- 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
- 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
R<>W asset transfer demo coming very soon.
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 for all the good progress here, with a very special thanks to @bkontur and @svyatonik for delivering by the truckload
As you already know we are now able to move assets between different (substrate2substrate) consensuses (reserve-based transfer).
Statemine runtime on
Rococo parachain), we can do asset transfer with dedicated extrinsic for bridge transfer (bridgeTransfer) using the
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
Rockmine2 we will see the events from the extrinsic: The fact that we reserved the assets, the amount, and that the transaction was initiated.
BridgeHubRococo accepts the message and places it in its outbound queue to be relayed to
Message is relayed and
BridgeHubWococo accepts the message and sends/dispatches it through xcmp to
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.
Note: Wrapped tokens (
ROCs) were created by
Wococo governance calls using the
forceCreate call on
foreignAssets extrinsic, so that
Wockmint can receive
Here is what we have been up to lately:
- P<>K Bridge audit In Progress
- Beefy audit In Progress
We are actively working on defining a Bug Bounty for P<>K Bridge.
We are preparing BEEFY to go live on Kusama: Enable BEEFY on Westend and Kusama by acatangiu · Pull Request #7591 · paritytech/polkadot · GitHub
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.
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.
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.
Dropping an update on what we’ve been busy with:
- We’re implementing fishermen for both bridges to watch for equivocations and enforce slashing
- Started efforts into moving our bridge overnight tests setup from Rialto<>Millau to Rococo<>Wococo, first critical step:
asset-hub-rococodedicated runtime based on
asset-hub-kusamaand add asset-bridging support to it (under review) (1215)
- Finished asset transfer using
- 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
pallet-xcmwith full support of reserve-based asset transfers (in progress) (1430)
- 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
- Security audit of the bridge (both transport protocol and XCM asset transfer functionality) is complete and all findings fixed
- Latest version of the code (containing above) PR#1215 should be merged any day now and then everything deployed to testnets
- Public Bug Bounty (running on testnets) will start shortly after
pallet-xcmreserve 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.
- Polkadot fellowship release of 1.1 runtimes is around the corner, BEEFY support on Kusama included.
- BEEFY gets support for slashing validators signing forking commitments critical for bridges.
- MMR gets ancestry proofs support - needs to be upstreamed to GitHub - nervosnetwork/merkle-mountain-range: A generalized merkle mountain range implementation.
- Work is under way for BEEFY BLS crypto support: 1705 and 1815.
- Bridge code-complete, XCM support over bridge code-complete, security audit complete
- Code mentioned above PR #1215 deployed and live on
WestendAssetHubs and BridgeHubs
- Reserve-backed asset transfer supported over bridge (at this stage, just for
AssetHubWestend. Supported using custom XCMs or by simply using
- Public Bug bounty will be launched in the next couple of weeks.
- [In-progress] adding required equivalent changes to
KusamaAssetHubs and BridgeHubs under polkadot-fellows/runtimes.
- Completed and merged enhancing
pallet-xcmto support remote reserves PR #1672
pallet-xcmagainst unintended side-effects on errors PR #2405
xcm-emulatorscenarios testing assets transfers over the bridge between Rococo and Westend PR #2251
- In-progress building docker containers with
substrate-relaybinaries that can automate bridge testing
- In-progress supporting fully versioned XCM flow over bridge PR #2719
- BEEFY deployed on-chain on
- 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.
- Rococo is now bridged to Westend. Wococo relay chain and its parachains were removed.
- Kusama/Polkadot bridging components were merged to fellowship/runtime repo, and included in Runtimes 1.1.0 release.
- ForeignAssets transfer support added to pallet-xcm.
- We implemented improved control of XCM version of messages over the bridge.
- We built a test framework based on Zombienet for testing Rococo <> Westend bridge and working to make it part of CI.
- Bridge send_message logic is more reliable.
- Divided into 2 phases:
- Send → Send is infallible so we do not have unexpected failures: https://github.com/paritytech/parity-bridges-common/issues/2776
- Divided into 2 phases:
- 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 client now works when the node is started with GRANDPA warp sync: https://github.com/paritytech/polkadot-sdk/issues/2627
- Validators can now Warp Sync while still running BEEFY.
- Tracking key rotation on Kusama
- BEEFY equivocation slashing is in review: https://github.com/paritytech/polkadot-sdk/pull/1903
- ECDSA/BLS pair signatures now use Keccak for hashing: Fix `ecdsa_bls` verify in BEEFY primitives by drskalman · Pull Request #2066 · paritytech/polkadot-sdk · GitHub
- PR to allow migration from ECDSA to (ECDSA, BLS) signatures in review: Make BEEFY client keystore generic over BEEFY `AuthorityId` type by drskalman · Pull Request #2258 · paritytech/polkadot-sdk · GitHub
Just curios, is Polkadot <> Kusama bridge live (either on testnet or mainnet).
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.
thanks for the info
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).
- Polkadot AssetHub
spec_version: 1001002and Polkadot BridgeHub
spec_version: 1001000containing bridging capabilities has been enacted on-chain today .
- Kusama AssetHub
spec_version: 1001002and Kusama BridgeHub
spec_version: 1001000containing bridging capabilities had been enacted on-chain since a couple of weeks .
- The two above combined means we can launch the bridge .
- Starting to prepare governance motions to configure and enable the bridge .
- Kusama: BEEFY consensus started today on Kusama, now live .
spec_version: 1001002containing BEEFY capabilities enacted on chain.
- Polkadot Validators need to rotate their keys to register their BEEFY keys.
- once we reach healthy percentage of validators with valid BEEFY keys, we can enable on Polkadot too.
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.