Outbound queue v2

[yrong]

Resolves: https://linear.app/snowfork/issue/SNO-1205

• Remove Channel & Pricing params & Estimation logic on chain
• Global nonce
• Locked Fee
• abi encode new message format for V2(respect Contracts V2 Snowfork/snowbridge#1300)
• submit delivery proof
• Seperate message V1 & V2 with different routes/exporters
• Integration with Reward(design in https://linear.app/snowfork/project/polkadot-sdk-unified-rewards-718300ef867d/overview)
• Integration with XCMV5 with new instructions
• Multiple commands in one XCM message
• Transact support
• Move governance call to AH/Plaza

[yrong]

Workflow

1. on AH we add a custom exporter returns a lower fee(without the cost on Ethereum) charged from the user when exporting to Ethereum, essentially predict the route by content of XCM, more details in Predicate route table by Xcm paritytech/polkadot-sdk#6074

2. on BH route the new XCM(with V2 specific instructions) to the new pallet OutboundQueueV2, in which convert the XCM to Message structure as following:

pub struct Message {
    /// Origin
    pub origin: H256,
    /// ID
    pub id: H256,
    /// Fee
    pub fee: u128,
    /// Commands
    pub commands: BoundedVec<Command, ConstU32<5>>,
}

which means we can execute multiple commands on Ethereum in one message.

3. Then abi encode the message and store it into a merkle tree as before, meanwhile add the pending order into LockedOrder storage and increase the nonce. more detais here

4. add a new extrinsic submit_delivery_proof in which we verify the event log is truely happened on Ethereum side, and add the fee to RewardLeger.

[vgeddes]

This is now a V1-only type, so should go in core/src/v1/mod.rs.

[yrong]

850fe96
Actually it's V2 specific.

The usage in

polkadot-sdk/bridges/snowbridge/pallets/outbound-queue-v2/src/send_message_impl.rs

Lines 45 to 47 in ba03ae6

	if ticket.origin != primary_governance_origin() {
	ensure!(!Self::operating_mode().is_halted(), SendError::Halted);
	}

is to allow upgrading even when bridge is halted.

[vgeddes]

ditto

[yrong]

#4 (comment)

[yrong]

Check details in emulated tests how to construct transfer message for both ENA&PNA with XCMV5 instructions.

cargo test -p bridge-hub-westend-integration-tests --lib tests::snowbridge_v2  -- --nocapture

[vgeddes]

Alternatively can we reimplement the original register_token extrinsic to optionally use V2 protocol, depending on a config field in storage.

When the ethereum contracts have been upgraded to V2, we can configure register_token to use V2.

The benefit is that user-level apps won't need to change any code to register tokens using V2.

[vgeddes]

Actually, ignore my comment, I realize we need separate register extrinsics for V1 and V2 as they have different fee-taking behavior.

I see now there is also the problem of how to provide WETH as the fees for these governance calls. On BH users can only provide DOT

[vgeddes]

Maybe we need to make the rewards pallet support both WETH and DOT.

[yrong]

how to provide WETH as the fees for these governance calls.

Actually there is no fee charged for governance calls. So it's possible pendingOrder bound with zero fee and no need to reward in this case.

polkadot-sdk/bridges/snowbridge/pallets/outbound-queue-v2/src/lib.rs

Lines 278 to 281 in fb3b30c

	// No fee for governance order
	if !order.fee.is_zero() {
	T::RewardLedger::deposit(envelope.reward_address, order.fee.into())?;
	}

[vgeddes]

The problem is that then no off-chain relayer will be incentivized to deliver the message. Letting users optionally pay using DOT is a solution we should consider.

Another issue is that when we make register_token_v2 permissionless, there is still no way for many parachains to call the extrinsic since they won't have HRMP channels registered.

So I think we have to force users to route their governance calls through AH and provide DOT. In which case, BH will see message like:

AliasOrigin /Parachain/Hydra
ReceiveTeleportedAsset (DOT, 10)
DepositAsset (DOT, /Parachain/Hydra)
Transact(EthereumSystem.register_token_v2)

[yrong]

So I think we have to force users to route their governance calls through AH and provide DOT.

Agree. All calls should be through AH.

But I'd assume in this case the fee could also be swapped to WETH beforehand in AH so that in BH we only use WETH as fee for simplicity. Some todo logic here:

polkadot-sdk/bridges/snowbridge/primitives/router/src/outbound/v2/convert.rs

Lines 289 to 294 in cff1cba

	// Todo: Validate fee asset is WETH
	let fee_amount = match fee_asset {
	Asset { id: _, fun: Fungible(amount) } => Some(*amount),
	_ => None,
	}
	.ok_or(AssetResolutionFailed)?;

[claravanstaden]

I would also prefer a solution where we only have 1 asset type in the rewards pallet.

[vgeddes]

Yeah, that would be best.

If we move governance extrinsics such as register-token, create-agent to AH, then that would neatly solve the problem

As we could burn the WETH on AH and then send message to BH with the weth reward for the outbound message

Example flow:

1. User calls EthereumSystem.register_token extrinsic on AH, supplying WETH for reward
2. WETH is burnt, and AH sends Transact(EthereumSystem.register_token) XCM to BH
3. On BH, the low-level EthereumSystem.register_token adds burnt WETH to rewards pallet and queues outbound command

[vgeddes]

Is it possible to use modules as namespaces instead of appending Wrapper to the struct names? Thinking of this pattern:

mod abi {
	sol! {
		struct InboundMessageWrapper { ... }
	}
}

Then we can reference the type using abi::InboundMessage

[yrong]

83b6ff8

[vgeddes]

The point of adding the abi namespace is that we rename InboundMessageWrapper and CommandWrapper to InboundMessage and Command respectively

[yrong]

Yeah, it seems a bit cubersome with InboundMessage and InboundMessageWrapper.

The reason is that it's not allowed to add macro #[derive(Encode, Decode, RuntimeDebug, PartialEq,TypeInfo)] into InboundMessageWrapper which is required for storing the data on chain, or error as follows:

--> /Users/yangrong/Projects/polkadot-sdk/bridges/snowbridge/primitives/core/src/outbound/v2.rs:31:12
     |
  31 |         #[derive(Encode, Decode, RuntimeDebug, PartialEq,TypeInfo)]
     |                  ^^^^^^ the trait `WrapperTypeEncode` is not implemented for `alloy_primitives::FixedBytes<32>`, which is required by `alloy_primitives::FixedBytes<32>: Encode`
     |
     = help: the following other types implement trait `WrapperTypeEncode`:
               &T
               &mut T
               Arc<T>
               Box<T>
               Cow<'a, T>
               Rc<T>
               alloy_primitives::bytes::Bytes
               parity_scale_codec::Ref<'a, T, U>
             and 3 others
     = note: required for `alloy_primitives::FixedBytes<32>` to implement `Encode`
     = note: this error originates in the derive macro `Encode` (in Nightly builds, run with -Z macro-backtrace for more info)
  ...

So InboundMessageWrapper is the intermediate data structure only for abi encode, will be converted to InboundMessage here when storing on chain.

[vgeddes]

Seems like this logic should be inside XcmConverter

[yrong]

It's for compatible with V1, for xcm which does not contain AliasOrigin will fallback to EthereumBlobExporterV1.

polkadot-sdk/cumulus/parachains/runtimes/bridge-hubs/bridge-hub-westend/src/xcm_config.rs

Lines 220 to 224 in cff1cba

	type MessageExporter = (
	XcmOverBridgeHubRococo,
	crate::bridge_to_ethereum_config::SnowbridgeExporterV2,
	crate::bridge_to_ethereum_config::SnowbridgeExporter,
	);

[vgeddes]

I don't think its safe to just "jump" over instructions, we should validate each instruction in turn to see whether it matches expectations.

[yrong]

af928ba

[yrong]

Closed in favor of the upstream paritytech#6706