Hi Bryan, the Polkadot <> Kusama bridge is still in development, with this high-level roadmap/milestones (you can drill-down on milestones for more details). I’ll try to answer most of your questions here too.
The Bridge Hub will have all required bridge pallets in its runtime. We hope that later, other teams will be able to use our bridge hubs too and have their pallets there.
What does exactly this mean? Presumably bridge hub is willing to accept more bridge pallets but only bridge pallets?
Right, bridge-hub parachain plans to host multiple trustless bridges from Polkadot/Kusama to other chains. AFAIK the only bridges in dev planned to be deployed on Bridge Hub paras are Polkadot<>Kusama bridge and Snowfork Polkadot<>Ethereum bridge (probably initially Snowfork Kusama<>Ethereum bridge?).
Here is the referenda for adding BH on Kusama with more details around the topic.
How does a parachain to establish HRMP channel with bridge hub? The way that we need governance action to setup HRMP connect to Statemine/t is just bad. Please provide a better alternative. e.g. when a parachain sent open request, automatically accept it and send open request back.
For initial deployment it’ll be the same with BH: governance action to HRMP connect. Future upgrades could add a dynamic mechanism like the one you describe, if that’s what the network decides (again through governance).
How does lane got allocated?
Initial deployment has static lane allocation. New lanes can be opened through governance. Dynamic lanes addition is on the roadmap for future upgrades.
This reads like it is the receiving chain paying for rewards, which make sense but how does the receiving chain prevent abuse / spam? e.g. Is it possible for someone to DoS a parachain by send spam messages to drain the rewards? Can parachain do anything about it?
It is actually the sending chain that is paying for rewards. It is paying at both ends of the bridge from sovereign accounts on each BH.
For example Statemint → Statemine transfer will involve relayers getting some rewards/cost-refunds on BHP from Statemint sov account on BHP and some on BHK from Statemint (again) sov account on BHK.
Regarding the DoS/spam - this is protected against. It is a longer explanation with multiple mechanisms in place. Some relevant issues/PRs for further research on how:
- Only refund relayer if all bundled messages have been delivered/confirmed by svyatonik · Pull Request #2019 · paritytech/parity-bridges-common · GitHub
- https://github.com/paritytech/parity-bridges-common/pull/2021
- Boost message delivery transaction priority by svyatonik · Pull Request #2023 · paritytech/parity-bridges-common · GitHub
- https://github.com/paritytech/parity-bridges-common/pull/2025
- Better bridge asset transfer user fees · Issue #2434 · paritytech/parity-bridges-common · GitHub
Are there any docs for parachain teams? Showing how does one integrate their parachain with bridge hub?
AFAIK not yet
What are the exact steps to bridge DOT from Statemint to Statemine? What’s the XCM going to look like? What is the reserve chain for DOT on Statemine?
This warrants its own post maybe - Asset transfer is in development here. Mechanism for dynamically wrapping assets is here and here.
Maybe @bkontur or @Vincent can summarize the mechanism on this thread seeing how the code/PRs are hard to read for the general audience.