Sending the the XCM script to the destination parachain.
This pallet is responsible for accepting outbound XCM messages to Ethereum. This involves the following:
Buffering the message in the MessageQueue pallet until as such as there is enough free weight in a future block to be able to process it.
When an XCM message is processed, it is assigned a nonce (sequence number), and converted to a simpler command which is more efficient to execute.
At the end of every block, a merkle root of all processed messages is generated and inserted into the parachain header as a digest item.
Processed messages are also temporarily held in storage so that they can be queried by offchain message relayers.
The merkle root in (3) is the commitment that needs to verified on the Ethereum side.
This pallet implements a light client that tracks Ethereum's Beacon Chain. It is used to verify inbound messages submitted to the InboundQueue pallet.
This pallet has overall responsibility for the bridge as well as providing basic system functionality for bridge operations.
The Ethereum side of the bridge is organised around a central gateway contract, responsible for the following:
Receiving, verifying, and dispatching inbound messages from Polkadot
Accepting outbound messages for delivery to Polkadot
Higher-level application features such as token transfers
Instances of the Agent contract act as proxies for consensus systems in Polkadot.
More concretely, they have a number of purposes in the bridge design:
When an ethereum user wishes to transfer ERC20 tokens over the bridge to the AssetHub parachain, the tokens are actually deposited into the agent instance corresponding to AssetHub.
When a Polkadot parachain sends a general-purpose message to a Solidity contract, on the Ethereum side, the message will be dispatched to the destination contract from the Agent instance corresponding to the origin parachain.
Offchain message relayers are incentivized by a fees & rewards system.
Users wanting to send outbound messages to Polkadot need to pay fees into the agent contract corresponding to the destination parachain
Relayers submitting messages to the Gateway are rewarded from the agent contract corresponding to the origin parachain.
The creation of new agents can be initiated permissionlessly by calling EthereumSystem::create_agent extrinsic on the BridgeHub parachain.