Polkadot XCMP MMD — Minimal POC (merged)

Consolidated from earlier split posts (1‑pager, POC2 spec, implementer checklist, source outbox). Master copy lives in Obsidian: Polkadot XCMP MMD — Minimal POC (kept in sync with this article).

Forum background: XCMP Design Discussion (Polkadot).

POC design revamp (vs forum MMD): the forum sketch uses one XcmpMessageMMR per channel and an XcmpChannelTree over those MMR roots. For this minimal POC we drop that split: a single append-only global XcmpOutboxMmr on the source commits all outbound messages; the header digest carries XcmpOutboxMmrRoot only. Each leaf still names dest (and nonce + payload_hash), so there is no loss of routing identity—only a shorter proof path and less on-chain bookkeeping. A future scale-out version can shard back into per-channel MMRs + channel tree.

Read more...

Polkadot validate_block, PVF, and relay validators

Companion to Polkadot HRMP protocol (implementation guide).

What implementation.rs is

cumulus/pallets/parachain-system/src/validate_block/implementation.rs implements validate_block: take the PoV’s storage proof, build a sparse in-memory trie, override sp_io::storage (and related) host functions so validation runs inside the Wasm instead of calling the node’s DB, execute the parachain block, then return ValidationResult — head data, horizontal_messages, hrmp_watermark, upward messages, processed downward message count, optional new validation code.

The helper run_with_externalities_and_recorder wraps Substrate Externalities (Ext over proof + OverlayedChanges) so pallet storage reads/writes during execute_verified_block and the follow-up reads for the result see consistent state. That is production PVF behavior, not limited to tests.

Read more...

Polkadot HRMP protocol (implementation guide)

Implementation-oriented notes from the Polkadot SDK: relay pallet polkadot/runtime/parachains/src/hrmp.rs, inclusion wiring, and Cumulus parachain-system. See also validate_block and PVF.

What HRMP is

HRMP (Horizontally Relay-routed Message Passing) lets parachains send bytes to each other using the same conceptual model as XCMP (channels, queues), but full message payloads live in relay-chain storage. That keeps semantics simpler and makes relay resource use higher. It is described as an interim mechanism until XCMP is fully available.

Read more...

solidity patterns

Solidity 设计模式汇总笔记

本笔记总结了用于优化 Gas 消耗、增强安全性以及改善开发体验的核心 Solidity 编程模式。

  1. 重入保护模式 (Reentrancy Protection) 问题: 当合约发起外部调用时,执行控制权会转移给另一方。攻击者可以利用此机会在原始操作完成前再次调用合约函数,从而导致资产被超额提取。 检查-效果-交互 (CEI) 模式: Checks:验证输入参数和初始状态。 Effects:在进行任何外部调用之前,更新所有的状态变量。 Interactions:最后再执行外部调用或资产转移。 重入卫兵 (Reentrancy Guards/Mutex): 使用一个布尔标志(如 nonReentrant 修饰符)在函数进入时加锁,结束后解锁。如果函数在锁定状态下再次被调用,则交易回滚。

Read more...

Terminology in Polkadot

Terminology

PoV (Proof of Validity)

The PoV is the data package produced by parachain collators and sent to Relay Chain validators.

  • Purpose: It acts as the “argument” or evidence that a parachain has transitioned its state correctly

  • Contents: It typically includes the L2’s state proof and the witness data (extra data needed for verification)

  • Size: A PoV block is often around 5MB of untrusted data provided to the validator group

Read more...

Light client bridge

Light client bridge

Light client bridge will relay every block from source chain to target chain, normally for asset transfer just need to lock asset in some backing module or smart contract in source chain and mint the mapping asset in target chain

Components

Since the chain cannot directly access each other, the cross-chain data submission needs to be completed by a third party. This third party is the bridge relayers. Anyone can become a bridge relayer, and the bridge relayer obtains income by completing the relay task between the bridges. This incentive can promote the stable existence of bridge relayers to ensure the bridge’s regular operation.

Read more...

xcmp research

XCMP Research

workflow

xcm types

transact

call data(pallet & call index required)

#[derive(Encode, Decode)]
pub enum RelayTemplatePalletCall {
	#[codec(index = 100)] // the index should match the position of the module in `construct_runtime!`
	DoSomething(DoSomethingCall),
}

#[derive(Encode, Decode)]
pub enum DoSomethingCall {
	#[codec(index = 0)] // the index should match the position of the dispatchable in the target pallet
	Something(u32),
}

#[derive(Encode, Decode)]
pub enum CrowdloanPalletCall {
	#[codec(index = 27)] // the index should match the position of the module in `construct_runtime!`
	CrowdloanContribute(ContributeCall),
}

#[derive(Debug, PartialEq, Encode, Decode)]
pub struct Contribution {
	#[codec(compact)]
	index: ParaId,
	#[codec(compact)]
	value: BalanceOf,
	signature: Option<MultiSignature>,
}

#[derive(Encode, Decode)]
pub enum ContributeCall {
	#[codec(index = 1)] // the index should match the position of the dispatchable in the target pallet
	Contribute(Contribution),
}

format

let call = RelayTemplatePalletCall::DoSomething(DoSomethingCall::Something(some_value)).encode();

let msg = Xcm::Transact {
    origin_type: OriginKind::SovereignAccount,
    require_weight_at_most: u64::MAX,
    call: call.into(),
};

asset transfer

DepositReserveAsset

 Xcm::WithdrawAsset {
 assets: vec![MultiAsset::ConcreteFungible {
     id: location,
     amount: amount.into(),
 }],
 effects: vec![
     Order::BuyExecution {
        fees: MultiAsset::All,
        weight: 0,
        debt,
        halt_on_error: false,
        xcm: vec![]
    },
     Order::DepositReserveAsset {
         assets: vec![MultiAsset::All],
         dest: MultiLocation::X1(
             Junction::Parent,
         ),
         effects: vec![
              Order::DepositAsset {
              assets: vec![MultiAsset::All],
              dest: MultiLocation::X1(Junction::AccountId32 {
                    network: NetworkId::Any,
                    id: T::AccountId32Converter::convert(account),
              }),
          }],
     }],
}

Teleport

let msg = Xcm::WithdrawAsset {
    assets:vec![MultiAsset::ConcreteFungible { id: MultiLocation::Null, amount: some_value }],
    effects: vec![
        Order::BuyExecution {
            fees: MultiAsset::All,
            weight: 0,
            debt,
            halt_on_error: false,
            xcm: vec![]
        },
        Order::InitiateTeleport {
            assets: vec![MultiAsset::All],
            dest: MultiLocation::X1(Junction::Parachain(para_id)),
            effects: vec![
                Order::BuyExecution {
                    fees: MultiAsset::All,
                    weight: 0,
                    debt,
                    halt_on_error: false,
                    xcm: vec![]
                },
                Order::DepositAsset {
                    assets: vec![MultiAsset::All],
                    dest: MultiLocation::X1(account_32.clone()),
                },
            ]
        }
    ]
};

test code

relax xcm filter

Read more...

Darwinia Bridge

Theory

White Paper

Principle

Darwinia-Ethereum Bridge

Projects Navigation

Darwinia Bridge

cross-chain overview

Background

ERC223

ERC721

Patricia Merkle Trees

Mining difficulty calculate

mmr

relay game

Bridger

Relayers (aka. Bridgers) in Darwinia Network are offchain worker clients which help relay the headers and messages between source chains and target chains

Background

actix

deprecated dj

Shadow

Services for bridger which retrieve header data from public chains and generate mmr proof

Background

ffi

Wormhole

Background

wiki

Read more...