RFC - HackMD

# RFC-0000: Moving Assets Between AssetHubKusama <-> AssetHubPolkadot | | | | --------------- | ------------------------------------------------------------------------------------------- | | **Start Date** | 18 October 2023 | | **Description** | Moving assets between AssetHubKusama <-> AssetHubPolkadot | | **Authors** | Adrian Catangiu, Branislav Kontur, Norbert Tulbure | ## Summary This RFC proposes adding bridging capabilities to the Polkadot and Kusama Bridge Hub runtimes and XCM routing configuration for bridging between Polkadot Asset Hub <-> Kusama Asset Hub in order to allow asset transfer between Asset Hubs. ## Motivation Main goal of these changes is to setup bridge between system parachains Kusama Asset Hub vs Polkadot Asset Hub. We explicitly allow only reserve based transfer for KSM/DOT to cross-consensus AssetHubs and nothing else at first (start defensively). We can later allow whatever (ETH, TrustBackedAssets, ForeignAssets, PoolAssets ...). ## Stakeholders - Parachain Users - Ecosystem and communities ## Explanation #### Add congestion detection to the Bridge Hub runtimes and report congestion status to the sending chain. Bridge Hub's `ExportMessage` handling is extended with check if outbound message queue is congested, if so then `CongestedMessage` signal is sent to the sending chain's relevant `pallet-xcm-bridge-hub-router` pallet instance, where dynamic fees factor is processed. When then same Bridge Hub receives message delivery confirmation, there is a another check is outbound queue is still congested, if not then `UncongestedMessage` signal is sent to the sending chain's relevant `pallet-xcm-bridge-hub-router` pallet instance. `pallet-bridge-messages`'s `receive_messages_proof` does another check for congestion or back-preassure with checking status of underlaying XCMP queue (`cumulus_pallet_xcmp_queue::bridging::OutboundXcmpChannelCongestionStatusProvider`). If we cannot deliver a message to the target, then `receive_messages_proof` returns error and Bridge Hub does not allow to receive new bridged messages. More about congestion detection [here](paritytech/parity-bridges-common#2318) #### Add bridging pallets to Bridge Hub runtime configuration: - `pallet-bridge-grandpa` is an on-chain GRANDPA light client, used for verifying GRANDPA finality proofs on-chain. - `pallet-bridge-parachains` is a Parachain finality module. - `pallet-bridge-messages` module that allows sending and receiving messages using lane concept. - `pallet-bridge-relayers` module that is used to store relayer rewards. Kusma Bridge Hub and Polkadot Bridge Hub runtimes are configred with those pallets in the way that: - allows to verify bridged relay chain GRANDPA finality proofs, e.g. Kusama Bridge Hub can track and verify Polkadot relay chain GRANDPA proofs and Polkadot Bridge Hub can track and verify Kusama relay chain GRANDPA proofs. - allows to verify bridged parachain finality proofs e.g. Kusama Bridge Hub can track and verify Polkadot Bridge Hub proofs and vice versa. - allows to relay messages between them which can be verified with mentioned finality modules. #### Add tests for simulation: - handling `ExportMessage` on both sides - handling message dispatch and routing to target on both side - relayer can submit proofs with `submit_finality_proof` / `submit_parachain_heads` and relay messages with `receive_messages_proof` To the lane concept mentioned above, actual bridging configuration allows to send/relay/receive messages only with one hard-coded lane `[0, 0, 0, 0]`, which is dedicated lane for Kusama Asset Hub and Polkadot Asset Hub communication. Next stage will be focused on adding support to allow bridging between arbitrary parachains. More about [Bridges V2](https://github.com/paritytech/parity-bridges-common/milestone/17). #### Transfer reserve asset with dynamic fees and back-pressure. Change XCM routing configuration for bridging from unpaid to paid version. Paid version means that origin (besides extrinsic fees) pays delivery fees at source Asset Hub and also Asset Hub sovereign account pays for execution of `ExportMessage` instruction at local Bridge Hub. Change XCM bridging router from `UnpaidRemoteExporter` to `ToPolkadotXcmRouter` and `ToKusamaXcmRouter` which are pallet instances of new module `pallet-xcm-bridge-hub-router`. The main thing that the pallet `pallet-xcm-bridge-hub-router` offers is the dynamic message fee, that is computed based on the bridge queues state. It starts exponentially increasing if the queue between this chain and the sibling/child bridge hub is congested. More about dynamic fees and back-preasure for v1 can be found [here](paritytech/parity-bridges-common#2294). asset-hubs: transfer assets via bridge using pallet-xcm #### Add xcm routing configuration for bridging between Polkadot Asset Hub <-> Kusama Asset Hub. We explicitly allow only reserve based transfer for KSM/DOT to cross-consensus AssetHubs and nothing else at first (start defensively). We can later allow whatever (ETH, TrustBackedAssets, ForeignAssets, PoolAssets ...). ## Drawbacks Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy. ## Testing, Security, and Privacy Adds tests for simulation: * `limited_reserve_transfer_assets` with `pallet_xcm` both ways * handling `ReserveAssetDeposisted` on both sides * handling `ExportMessage` on both sides * handling message dispatch and routing to target on both side * relayer can submit proofs with `submit_finality_proof` / `submit_parachain_heads` and `relay messages` with `receive_messages_proof.` Adds local zombienet run for: * reserve based transfer of KSMs from AHK to AHP * reserve based transfer of DOTs from AHP to AHK [check parachains/runtimes/bridge-hubs/README.md in this PR](https://github.com/paritytech/cumulus/blob/master/parachains/runtimes/bridge-hubs/README.md) ## Performance, Ergonomics, and Compatibility Describe the impact of the proposal on the exposed functionality of Polkadot. ### Performance Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? ### Ergonomics If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? ### Compatibility Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. ## Prior Art and References Provide references to either prior art or other relevant research for the submitted design. ## Unresolved Questions Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. ## Future Directions and Related Material Next stage will be focused on adding support to allow bridging between arbitrary parachains More about [Bridges V2](https://github.com/paritytech/parity-bridges-common/milestone/17). More about dynamic fees and back-preasure for v1 can be found [here](https://github.com/paritytech/parity-bridges-common/pull/2294).