ナビゲーションをスキップ
XChain ドキュメント

4 · クロスチェーン・モデル

最終更新: 2026/08/07読了目安 1 分

多くのクロスチェーン設計は、あらゆる相互作用を 1 種類のトラフィックとして扱うことで失敗します。XChain は READ(状態を変えない)と WRITE(状態を変える)の間に固い線を引きます——モデル全体がこの 1 つの基本的な区別にぶら下がっています。クロスチェーンの需要のほとんどは「X がチェーン A で起きた」ことの検証にすぎません——これは READ で、Interchain Queries(ICQ)を通り、安く事実上無制限です。原子的な状態変更だけが WRITE であり、IBC v2/Eureka + Interchain Accounts(ICA)を通り、意図的に希少に保たれます。

なぜ READ はほぼ無料なのか

この非対称性は料金表から来るのではなく、それぞれの操作が実際に何をしなければならないかから来ます。READ は問い合わせる側のチェーンがすでに追跡している root に対して包含証明を検証します——Settlement Layer が PAI を通じて維持しているのと同じ root です。新たに合意すべきものはなく、コンセンサスのラウンドも開かれず、状態にも触れません。仕事は証明の検証 1 回であり、そのコストは読まれる状態の大きさとともに増えません。10 億件のログの中の 1 件だと証明するのは、1,000 件の中の 1 件だと証明するのと同じ費用です。

これを単に安いだけでなく安全にしているのは 2 つの硬い規則です。READ は状態を変えてはならず、READ は冪等でなければなりません——だから再試行は無害で、問い合わせが重複しても何も変わらず、リレーヤーが古い問い合わせを再送しても損害を与えられません。READ の予算を事実上無制限にしておけるのは、まさにそのためです。何も変えられない操作は、何かを変えるように悪用することもできません。

種類仕組みコスト予算
READICQ — 既存の root に対して証明を検証安い(検証 1 回)事実上無制限
Cell 内の WRITE共有シーケンサ(原子的な取り込み)低い状態を持つトラフィックの大半
Zone/Region をまたぐ WRITEXMP + ZK ライトクライアント + pessimistic proof高い、非同期< 0.1%
全域の原子的 WRITESettlement Layer(Tier T0)のみ。intent/solver が引き受ける非常に高い< 0.01%

WRITE は実際に何を支払うのか

WRITE が希少なのは、それが本当に高価だからであり、その代金は明確な検査の集合を買っています。ライフサイクルは固定です:SendPacket → メッセージが送信メッセージ Merkle ツリーに書き込まれる → リレーヤーが証明とともに運ぶ → RecvPacket証明と再送防止 nonce を検証 → メッセージが実行される → Ack または Timeout。ここにリレーヤーを信頼している箇所は 1 つもありません。リレーヤーはバイトを運ぶだけで、嘘をつく・壊す・落とすことをすれば証明の検査が失敗するかタイムアウト経路が動きます。リレーヤーは WRITE を遅らせることはできますが、偽造はできません。

3 つの義務が MUST として規定されており、これがチェーンを増やしてもモデルが崩れない理由です:

  • nonce は (送信元, 宛先) の組ごとに単調増加でなければならない —— これが再送を「起こりにくい」ではなく構造的に不可能にします。
  • 資産を動かす WRITE は必ず **UAC.checkPlacement** を呼ばなければならない —— したがって 2 ドメインの境界は発行時だけでなく、移転のたびに再確認されます。
  • 地域をまたぐ WRITE は必ず pessimistic-proof の会計を伴わなければならない —— 遠隔地の障害を上限のある損失に変える仕組みです。

参照データ経路——「いいね」を記録し、再実行なしにチェーンをまたいで証明する:

図 4 — 参照データ経路:追記し、錨づけ、チェーンをまたいで包含を証明する。

何が壊れ、何が保たれるのか

クロスチェーン系は順調な経路ではなく障害モードで評価されるべきです。だから重要なものを挙げます——XChain があえてしない保証も含めて:

何が起きるかどうなるかそれでも保たれるもの
リレーヤーが落ちる、または検閲するWRITE が遅れ、やがて Timeout が発動する部分適用はありません。メッセージは有効な証明とともに実行されるか、タイムアウトするかのどちらかです。誰でもリレーヤーを動かせるので、検閲は安全性ではなくライブネスの問題です
メッセージが再送されるRecvPacket が nonce の段階で拒否する組ごとに単調増加する nonce が、再送を「ありそうにない」ではなく不可能にします
チェーンが乗っ取られ、預けた以上に引き出そうとするpessimistic proof が超過分を拒否する損害はそのチェーン自身の取り分の中に封じ込められます——これはまさに受け入れ基準 MVC-4 ではなく MVC-3 が、故障を模したチェーンで確かめている点です(ノードを動かす
誰かが高価値の資産をデータドメインへ移そうとするUAC.checkPlacement がその WRITE を拒否するドメイン境界は発行時だけでなく、移転のたびに強制されます
地域をまたぐ WRITE が半分だけ完了する防げません。 独立したコンセンサス圏をまたぐ原子性に、信頼不要の構成法はありません封じ込めと経済的な引き受けが損失に上限をかけます。これは未解決の問題として明記してあり、ごまかしてはいません——未解決の問題 を参照

最後の行がこの設計の正直な縁です。XChain は全域の原子性を主張しません。誰もそれを信頼不要で構成できていないからです。主張するのは、障害はそれが起きた地域の内側に留まること、そして損失の大きさが後から判明するのではなく前もって分かっていることです。

要点: 別のチェーンが証明チェック 1 回で「いいね」が起きたことを証明します——状態を持つメッセージも再実行もなしに。地域をまたぐ原子的 WRITE は、プロトコル層で全か無かを約束するものではありません。pessimistic proof と経済的な引き受けによって封じ込めを達成します。ただし、ほぼ無料の読み取り経路が安全でいられるのは、読み取る対象の境界を越えて価値が漏れ得ない場合だけです——これはセキュリティの問いで、次の節が答えます。