ボカのクロスチェーン機能をさらに一歩進めたXCMPは、どのように設計され、実装されるのでしょうか？

Author: CoaX1d; Source: PolkaWorld

長い間お待たせしましたが、ついにエキサイティングなトピックが登場しました：XCMPの将来の形です。

ウェブ3ファウンデーションの研究チームは、XCMPテクノロジーの設計とプロトタイピングにここ数ヶ月を費やしてきました。これは、Polkadotのクロススプリット・メッセージング・システムを最適化するためのもので、現在のHRMP（Horizontal Relay Routed Messaging）システムに取って代わり、すべての計算とオンチェーン・リソースの消費をオフチェーンに移行します。消費はオフチェーンに移行します。

本稿では、XCMPの設計がBokaクロスチェーン・メッセージングという全体的な目標にどのように役立つかを説明します。

全体的な設計の考慮事項

• 順序付きまたは順序なしメッセージ配送

• メッセージが配送されることが保証されているかどうか

• メッセージが受信されず破棄された場合、送信者または受信者にどのような影響があるか

• メッセージ配信の速度と証明のサイズ

• 保守性、プロトコルの柔軟性

• 。セキュリティの前提

XCMPの目的

クロススプリット・メッセージングを最適化する。高速でスケーラブルな異種シャーデッドブロックチェーンシステムを可能にします。

現在、HRMP（Horizontal Relay Route Messaging）と呼ばれるクロスチェーンメッセージングの実装がありますが、Bocaリレーチェーンに多くの作業を強いることで不足しています。XCMPは、HRMPシステムを置き換え、すべての計算と以前のオンチェーン・リソース消費を完全にオフチェーンに移すことを目的としています。

XCMPの設計：メルクルのクローブモデル

XCMPの具体的な設計では、"Merkle Matryoshka Dolls" (マルクル・マトリョーシカ人形モデル)を使用し、ネストしてコンパクトなバイナリー・マルクル構造を使用することで、証明プロセスを最適化し、状態証明の使用を回避します。

ネスティングプロセス

• XCMPメッセージを最小のネスティングに入れます。-XCMPMessageMMR.

• すべてのXCMPMessageMMRルートを2番目のネストであるXCMPChannelTree.

• XCMPChannelTreeのルートはParachainHeaderに入る。

• ParachainHeaderは3番目の入れ子ツリー--ParaHeaderTree.

• ParaHeaderTreeのルートは最大の入れ子ツリーに入ります。--BEEFYMMR.

  
  

これがすべて終わると、すべての並列チェーンが他のすべての並列チェーンから送信したすべてのメッセージを含む、ウェハまたはルートハッシュ（つまりBEEFYルート）の単一セットが得られます。

検証プロセス

• ソースチェーンはターゲットチェーンにメッセージを送信し、ターゲットチェーンはBEEFY（Bridge Efficiency Enabling Finality Yielder）を通過します。Efficiency Enabling Finality Yielder）Merkleルートを通過させ、メッセージの真正性を証明する。

• ターゲットチェーンは、BEEFYルートを受け取ってメッセージを検証することで、ネストをレイヤーごとに解きほぐしていく。

実装/統合の方向性

XCMPはHRMPの直接的な代替として設計されており、シンプルなモジュールを通して既存のシステムに統合されます。strong>既存のBokaシステムに統合され、既存のXCMおよびパラレルチェーンモジュールとの互換性を維持します。

オンデマンド・コアタイムへの適応

XCMPは、将来のオンデマンド・コアタイムやコアジャムに適応するように設計されていますか？

Bokaネットワークでは、コアタイムはチェーン上の処理能力とリソースの割り当てを意味します。「オンデマンド」とは、ネットワークのパフォーマンスと効率を最適化するために、需要に基づいてリソースの割り当てを動的に調整することを意味します。

このため、メッセージ検証における時間感度の問題が浮上します。具体的には、ターゲットチェーンが一定期間ブロックを作成していない場合、その間にそのチェーンに送信されたメッセージは（ネスティングモデルでネストされた証明を通じて）、古いBEEFYルートハッシュに基づいて検証されます。ターゲットチェーンがタイムリーにBEEFYルートハッシュを更新しない場合、これらのメッセージの真正性を検証できない可能性があります。

この問題に対処するために、証明構造に追加のレイヤー（新しい入れ子レイヤー）を追加することが提案されています。この新しいレイヤーを追加することで、ターゲットチェーンのコレクターはまずこの証明が失敗することを認識し、次に新しいBEEFYルートに対応するために元の証明に小さな修正を加えることができる。こうすることで、ターゲットチェーンが新しいブロックを生成しない期間が長くなっても、古いメッセージを効率的に処理して検証することができる。この新しいレイヤーを追加することは、Relayerにとって小さなステップであり、宛先チェーンが追加するストレージスペースも必要ありません。

そのため、オンデマンドコアタイム機能はまだBokaネットワークに実装されていませんが、XCMPは将来を見据えて設計されており、オンデマンドコアタイムの追加的な複雑性に対処する方法を提供し、システムの柔軟性とメッセージの検証可能性を保証します。

結論

XCMPの設計とプロトタイプは、ローカルテストネットワーク上で最終決定され、さらに実装される予定です。

XCMPは、Pocaのクロスパーティション・メッセージング機能をさらに向上させ、相互運用性を強化します。