Investigation of deploying pallet-bridge-messages on the source/destination chain (without finality pallets)

[bkontur]

I am borrowing @jakoblell's great summary here:

The bridges pallets are pretty ready and could be moved directly to the asset hub without too much effort - and even a hybrid approach with grandpa on the bridge hub and parachains/messages on the target chains will be doable with a relatively manageable effort, for that the bridge hub could do the grandpa finality and send the finalized relay chain block hash/header to the relay chain via UMP, the relay chain could then put it in a storage value (accessable with a simple storage proof based on the relay parent storage root) or header digest so that other parachains can run their bridges based of that.

---

pallet-bridge-messages needs to validate received proofs from the bridged chain in verify_messages_proof. It only needs to know the state_root of the bridged chain for the verified bridged_header_hash:

• pallet-bridge-grandpa provides the bridged_header_hash and state_root for bridging to a GRANDPA chain through the HeaderChain implementation here.
• pallet-bridge-parachains provides the bridged_header_hash and state_root for bridging to a parachain through the HeaderChain implementation here.

It doesn't make sense to deploy pallet-bridge-grandpa or pallet-bridge-parachains to all source/destination chains. If we want to deploy only pallet-bridge-messages to a source/destination chain, we need to ensure or provide functionality that delivers a proven/verified state_root for the requested bridged_header_hash.

There are several possibilities we need to explore:

• The BridgeHub could continue syncing headers and state_root and send them to the source chain (perhaps via XCM Transact?).
  • maybe kind of subscription service?
  • basically we just need to sync-and-store ImportedParaHeads
• Store the bridged_header_hash and state_root on the relay chain.
  • Maybe BEEFY could be useful here?
• Other options?

As a result, we could simplify the control flow, congestion control, fees (avoiding additional HRMP to the BridgeHub)...

TODO

• think about pruning stuff
• investigate also snowfork-inbound/outbound-queue possibilities