Investigation of deploying pallet-bridge-messages on the source/destination chain (without finality pallets) a.k.a. sync finality proofs service

[bkontur]

TL;DR:

The pallet-bridge-messages must validate received proofs from the bridged chain, which requires verified/proven bridged_header_hash and state_root by finality pallets. However, we don't want to deploy finality pallets everywhere.

Essentially, we need a solution that propagates (makes available) this information (bridged_header_hash and state_root) to the (para)chain where we want to deploy pallet-bridge-messages.

Description

The pallet-bridge-messages needs to validate received proofs from the bridged chain in verify_messages_proof. It only requires 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 on all source or destination chains. If we want to deploy only pallet-bridge-messages on a source or destination chain, we need to ensure or provide a mechanism to deliver a proven/verified state_root for the requested bridged_header_hash.

1. Solution

Sync parachain proofs from BridgeHub to AssetHub using XCM Transact.

• Deploy a new simple pallet, e.g., pallet-bridge-sync-proofs, on the AssetHub.
  • Expose one extrinsic: update_proofs(bridged_header_hash, state_root).
  • Implement the HeaderChain trait for verifying proofs.
• Deploy pallet-bridge-messages on the AssetHub using the HeaderChain implementation from pallet-bridge-sync-proofs to validate with synced proofs.
• Extend the pallet-bridge-parachains:
  • Subscription mechanism with exposed extrinsics for subscribe_for_proofs and unsubscribe_for_proofs.
  • Configuration with a callback that will trigger (immediately or on idle) XCM Transact(update_proofs(bridged_header_hash, state_root)) when new verified/proved data are produced, but only for the subscribed origins.

2. Solution

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.

3. Solution - sync state_root of BridgeHub to the AssetHub

So when we have state_root of BridgeHub at the AssetHub, we can prepare proofs and we don't need to sync it with HRMP.

#7445

Other solutions

Maybe BEEFY could be useful here?

TODO / Questions

• think about how other parachains would subscribe to the bridge-hub's finality proofs
• think about pruning stuff
• think about retry/resend finality proofs
• investigate also snowfork-inbound/outbound-queue possibilities