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.