b8cc9eee4b
## Polkadot upgrade 2503 In this PR, we upgrade form Polkadot SDK 2412 to Polkadot SDK 2503. In order to upgrade the SDK we need to upgrade some dependencies : StorageHub and frontier simultaneously. ## What changes ### Trivial changes * https://github.com/paritytech/polkadot-sdk/pull/7634 -> The new trait is required in all the pallets using scale encoding. * https://github.com/paritytech/polkadot-sdk/pull/7043 -> Remove deprecated `sp-std` and replace with `alloc` or `core`. * https://github.com/paritytech/polkadot-sdk/pull/6140 -> Accurate weight reclaim with frame_system::WeightReclaim ### Breaking changes * https://github.com/paritytech/polkadot-sdk/pull/2072 -> There is a change in `pallet-referenda`. Now, the tracks are retrieved as a list of `Track`s. Also, the names of the tracks might have some trailing null values (`\0`). This means display representation of the tracks' names must be sanitized. * https://github.com/paritytech/polkadot-sdk/pull/5723 -> adds the ability for these pallets to specify their source of the block number. This is useful when these pallets are migrated from the relay chain to a parachain and vice versa. (Not entirely sure it is breaking as it is being marked as backward compatible). * https://github.com/paritytech/polkadot-sdk/pull/6338 -> Update Referenda to Support Block Number Provider ### Notable changes * https://github.com/paritytech/polkadot-sdk/pull/5703 -> Not changes required in the codebase but impact fastSync mode. Should improve testing. * https://github.com/paritytech/polkadot-sdk/pull/5842 -> Removes `libp2p` types in authority-discovery, and replace them with network backend agnostic types from `sc-network-types`. The `sc-network` interface is therefore updated accordingly. ## What changes in Frontier * https://github.com/polkadot-evm/frontier/pull/1693 -> Add support for EIP 7702 which has been enable with Pectra. This EIP add a new field `AuthorizationList` in Ethereum transaction. Changes example : ```rust #[test] fn validate_transaction_fails_on_filtered_call() { ... pallet_evm::Call::<Runtime>::call { source: H160::default(), target: H160::default(), input: Vec::new(), value: sp_core::U256::zero(), gas_limit: 21000, max_fee_per_gas: sp_core::U256::zero(), max_priority_fee_per_gas: Some(sp_core::U256::zero()), nonce: None, access_list: Vec::new(), authorization_list: Vec::new(), } .into(), ``` ## ⚠️ Breaking Changes ⚠️ * Upgrade to Stirage hub v0.5.1 * Support for Ethereum latest upgrade (txs now have the `authoriation_list` for support EIP 7702) --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| fixtures | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
Ethereum Inbound Queue V2
Reads messages from Ethereum and sends them to intended destination on Polkadot, using XCM.
Architecture Overview
Message Flow
1. Ethereum Gateway Event: A message is first emitted by a GatewayProxy contract on Ethereum in an OutboundMessageAccepted event. This event contains:
- A nonce (for replay protection).
- Information about the originating address, asset(s), and XCM payload.
- Relayer fee and execution fee (both in Ether).
This event is emitted when the
v2_registerTokenandv2_sendMessageis called on Ethereum.
2. Relayer Submits Proof: A relayer gathers the event proof (containing the Ethereum event log and the proofs required:
receipts proof and execution header proof) and calls the submit extrinsic of this pallet.
3. Verification: The supplied proof is verified by an on-chain Verifier (configured in the runtime as the EthereumBeaconClient). The verifier checks that the header containing the message is valid. If verification fails, the submission is rejected.
4. Message Conversion: Once verified, the message data is translated into XCM via a MessageConverter implementation. This translation includes extracting payload details, XCM instructions, and bridging asset references.
5. XCM Dispatch: The resulting XCM message is dispatched to the target AssetHub parachain for further processing. Depending
on the xcm provided in the payload, more messages may be sent to parachains after AssetHub.
6. Relayer Reward: The relayer is rewarded with Ether (the relayer_fee portion), paid out by the configured RewardPayment handler, which accumulates rewards against a relayer account, which may be claimed.
Key Components
Verifier
A trait-based component (snowbridge_inbound_queue_primitives::Verifier) responsible for verifying Ethereum events and proofs. The implementation for the verifier is the Ethereum client.
Message Converter
Translates the Ethereum-provided message data (Message) into XCM instructions. The default implementation uses logic in MessageToXcm.
Reward Payment
Handles paying out Ether-based rewards to the relayer.
Operating Mode
A gating mechanism allowing governance to halt or resume inbound message processing.
Extrinsics
The pallet provides the following public extrinsics:
1. Message Submission: submit
Primary extrinsic for inbound messages. Relayers call this with a proof of the Gateway event from Ethereum. The process is described in message-flow.
pub fn submit(
origin: OriginFor<T>,
event: Box<EventProof>,
) -> DispatchResult
2. Governance: set_operating_mode
Allows governance (Root origin) to set the operating mode of the pallet. This can be used to:
- Halt all incoming message processing (Halted state).
- Resume normal operation or set other custom states.
pub fn set_operating_mode(
origin: OriginFor<T>,
mode: BasicOperatingMode,
) -> DispatchResult