Pallet for committing outbound messages for delivery to Ethereum

Overview

Messages come either from sibling parachains via XCM, or BridgeHub itself via the snowbridge-pallet-system-v2:

1. snowbridge_outbound_queue_primitives::v2::EthereumBlobExporter::deliver
2. snowbridge_pallet_system_v2::Pallet::send

The message submission pipeline works like this:

1. The message is first validated via the implementation for snowbridge_outbound_queue_primitives::v2::SendMessage::validate
2. The message is then enqueued for later processing via the implementation for snowbridge_outbound_queue_primitives::v2::SendMessage::deliver
3. The underlying message queue is implemented by Config::MessageQueue
4. The message queue delivers messages to this pallet via the implementation for frame_support::traits::ProcessMessage::process_message
5. The message is processed in Pallet::do_process_message: a. Convert to OutboundMessage, and stored into the Messages vector storage b. ABI-encode the OutboundMessage and store the committed Keccak256 hash in MessageLeaves c. Generate PendingOrder with assigned nonce and fee attached, stored into the PendingOrders map storage, with nonce as the key d. Increment nonce and update the Nonce storage
6. At the end of the block, a merkle root is constructed from all the leaves in MessageLeaves. At the beginning of the next block, both Messages and MessageLeaves are dropped so that state at each block only holds the messages processed in that block.
7. This merkle root is inserted into the parachain header as a digest item
8. Offchain relayers are able to relay the message to Ethereum after: a. Generating a merkle proof for the committed message using the prove_message runtime API b. Reading the actual message content from the Messages vector in storage
9. On the Ethereum side, the message root is ultimately the thing being verified by the Beefy light client.
10. When the message has been verified and executed, the relayer will call the extrinsic submit_delivery_receipt to: a. Verify the message with proof for a transaction receipt containing the event log, same as the inbound queue verification flow b. Fetch the pending order by nonce of the message, pay reward with fee attached in the order c. Remove the order from PendingOrders map storage by nonce

Extrinsics

• Call::submit_delivery_receipt: Submit delivery proof

Runtime API

• prove_message: Generate a merkle proof for a committed message