【UXDリサーチ】ブロックチェーンインターオペラビリティ(相互運用性)について
0. この記事は何？（前提）
この記事はUXD Protocolがクロスチェーン戦略について検討する過程で行った、インターオペラビリティプロトコルに関するリサーチを外部に公開したものです。
ブロックチェーンのインターオペラビリティ（相互運用性）は「異なるブロックチェーンの間でデータを交換・活用し、独自形式のデジタル資産をネットワーク内の相手チェーンへと移動する能力」のことを指しています。この能力が発展することで性質の違うブロックチェーンを簡単に接続し、互いに組み合わせられるようになると言われています。（Geminiより）
つまり、WormholeやHop Protocolのような私たちが普段使う「ブリッジ」もインターオペラビリティプロトコルだと言えるでしょう。
この記事では、そんなWormholeやIBC、LayerZeroなどといったクロスチェーンプロトコルの仕組みや技術的詳細、UXD Protocolが進むべき道などについて詳しく調査しています。
このリサーチは私たちの戦略担当・クオンツのDiracとEulerが主導して進めてくれました。翻訳はUXD日本チームが行いました。
1. 背景
クリプトが多くのユーザーを獲得するにつれて、ブロックチェーンの数も増加しており、本稿執筆時点でその数は数百に達しています。この増加は、ユーザー数、取引数、機能の増加に対応していますが、ブロックチェーンやエコシステム間で資本、ユーザー、開発者の断片化が進む結果にもなっています。
ブロックチェーンのインターオペラビリティという広範なテーマは、現在進行形で進化している研究分野です。初期のインターオペラビリティソリューションは、資産のブリッジといった比較的狭いタスクに焦点を当てていましたが、時間の経過とともに、よりブロックチェーンの利用が拡大するにつれ、チェーン間流動性供給にまで範囲が広がりました。
本稿執筆時点では、 チェーン間の一般的なメッセージパッシング（message passing）という課題を解決する目的で、ますます多くのプロトコルが登場しています。
この調査の目的は、UXDが広範なクロスチェーン戦略の一環として統合する可能性のある様々なプロトコルを調査することです。レポートでは、特に一般的なメッセージパッシングプロトコルを中心に、相互運用性に関する主要なプロトコルに関するいくつかの枠組みや分類メカニズムを提言します。
1.1 インターオペラビリティの問題
ブロックチェーンはある種のステート（「状態」のこと。UTXO、口座と残高、メモと所有者などを指します）を記録し、またネットワーク参加者の間でステート更新の有効性に関するコンセンサス（合意）の基礎を形成する一連の決定論的規則に従ってそのステートを更新する独立した台帳で、設計上「サイロ化したエンティティ」といえます。
しかし、これらのコンセンサスの仕組みは、それぞれ個々のステートのみに適用されるものです。 これは、レイヤー1によってセキュリティやコンセンサスのメカニズム（Proof of Work vs Proof of Stakeなど）、ステートの保存方法などが異なるためです。
異なる国家間で国境を越えて行う取引と同様に、あるブロックチェーンのユーザーが他のブロックチェーンのステートに影響を与える方法があるとすれば、取引を実行させる「通訳」が必要不可欠です。
インターオペラビリティは「オラクル問題」、すなわちブロックチェーンが外部システム、特に実世界にデータを引き込んだり公開したりできないという概念の下位問題として考えられることを常に念頭に置いておく必要があります。
インターオペラビリティは（Chainlinkの目標である）任意のデータの読み書きという課題を解決するのではなく、ブロックチェーン間のデータの受け渡しとその検証のみを解決することを目的としたプロトコルという意味で、メインの問題ではなく、サブの問題であると言えます。
しかし、オラクル問題と同様、定義上このような解決策はすべてチェーン外の当事者との相互のやり取りを必要とします。
ソースチェーン（Source、メッセージの送信側）とデスティネーションチェーン（Destination、メッセージの受信側）がある場合、チェーン間通信のシステムは大きく分けて3つの基本機能を実行する必要があります。
ソースチェーンにデスティネーションチェーンへの情報送信要求がないか聞く
送信するメッセージの正当性を確認し、その内容について他のネットワーク参加者と合意する
情報をデスティネーションチェーンが読み取り可能な形態でデスティネーションチェーンに中継する
これら3つの機能実装の選択は、特定のクロスチェーンプロトコルの【一般化可能性】【適応性】【信頼の前提】【セキュリティ】【資本効率】【ライブネス】に影響を与えます。
結局のところ、上記の特性のほとんどは、「クロスチェーン・オペレーター」、すなわちクロスチェーンプロトコルを実際に「制御」する当事者（マルチシグ委員会、分散したバリデーター群、分散型オラクル群、ライトクライアントなど）の構造から、論理的含意を得ることができます。
各クロスチェーンプロトコルの技術スタックに関しては、Axelarの分類を参考に【ベースレイヤー】【認証レイヤー】【トランスポートレイヤー】【インターフェースレイヤー】を評価します。
ここで、クロスチェーンプロトコルが必ずしも上記の技術スタックレイヤーをすべて持つ必要はないことに注意が必要です。
いくつかのプロトコル（LayerZeroなど）は、「他の部分の実装に対して両義的な」技術スタックの一部分として理解するのがベストです。これらの大まかな分類と評価基準を念頭に、次のセクションでは相互運用性を実現しようとするプロジェクトの現状を概観します。
1.2 一般化可能性
ブロックチェーンのインターオペラビリティプロトコルは、その特殊性や柔軟性に違いがあります。クロスチェーンプロトコルは、その柔軟性が最も低いものから最も高いものの順で並び替えて考えることができます。
最も特殊なプロトコルでは、完全に担保されたラップ資産をあるチェーンから別のチェーンに転送します。このようなブリッジは比較的簡単に実装することができます。しかし、より一般化されたプロトコルと比較するとセキュリティが犠牲になることが多く、また、接続したチェーンごとに別々の実装が必要になります。一般的にこれらのプロトコルは、性質が大きく異なるブロックチェーン同士をブリッジします（例えばBTCからETH、ETHからSOLのように）。
これに対しより一般的なのは、様々な資産やチェーンに対して特定の機能を実行することを目的としたアプリケーション特化型のプロトコルです。このカテゴリには、一般的なチェーン間スワップのために設計されたAnySwapとTHORChainが含まれています。
最も柔軟性が高いのは、汎用メッセージパッシングプロトコルです。これらのプロトコルは、接続されたチェーン間の任意のデータ転送をサポートすることを目的としています。最近はSynapseやAnySwapなど、以前はアプリケーションに特化していたプロトコルがこの分野への進出を発表しています。
接続されたチェーン上にエンドポイントを持つノードまたはバリデーターで構成されたネットワークという仕組み上、この種のプロトコルは一般に、規模が拡大するにつれてネットワーク効果の恩恵を受けることができます。
セキュリティ、スピード、柔軟性、分散性、範囲の間のトレードオフを管理するために、このカテゴリのプロトコルはさまざまなアプローチを取っています。例えば、IBCが対応するのはファイナリティが保証されたチェーンに限定されています。
AxelarやLayerZeroのような他のプロトコルは、より幅広いチェーンとの相互運用性をサポートすることを目的としています。第2章では、前のセクションのフレームワークを用いてこれらのプロトコルをより詳細に調査します。
2. セキュリティの仕組み
次に、このようなアプローチに共通するいくつかのカテゴリーについて説明します。ここで挙げるカテゴリーはあくまで単純化されたもので、各カテゴリー内のプロトコルはパラメータや実装に大きなばらつきがあり、それに応じてセキュリティや技術的な特性にも差異がみられます。
さらに、基礎となるメッセージングプロトコルが安全であっても、スマートコントラクトのバグは依然として大きなリスクをもたらす可能性があります。実際、NomadやWormholeのハッキングのような最近の「脆弱性の利用」は、根本的な合意メカニズムに対する攻撃ではなく、スマートコントラクトのエンドポイントにおける欠陥から発生しました。
また、多くのブリッジで発生する膨大な経済活動は、悪意あるアクターの格好のターゲットとなります。
2.1 ステート確認が可能なライトクライアント
このカテゴリは、ソースチェーンのステートトランザクションをデスティネーションチェーンで検証するプロトコルで構成されています。
一般的には、ZK proof（ゼロ知識証明）のような有効性証明を取引データと一緒にデスティネーションチェーンへ提供することで実現されます。また、ステートの正当性について異議申し立てができるよう、不正証明システムを採用するアプローチもあります。
これらのブリッジにおける信頼の前提は「信頼の最小化」タイプとなる傾向にあり、現在はすべてOptimistic Rollupとして実装されていることに注意してください。
2.2 コンセンサス検証を行うクライアント
この種のプロトコルはステートの有効性を直接的に証明したり、有効性に異議を唱えたりすることはありません。そのような手法を取る場合、それぞれのチェーンが互いのVMやゼロ知識証明システムを理解する必要が生じ、非常に複雑になってしまいます。
その代わりこの種のインターオペラビリティプロトコルは、ソースチェーンでコンセンサスが得られ、 デスティネーションチェーンがこのコンセンサスを検証できる場合に、メッセージを有効なものとして受け入れます。
これには、例えば直近のバリデーター委員会の署名を検証したり、最長のチェーンのステートをチェックしたりすることが含まれます。
このカテゴリの一例はCosmosのIBCであり、ライトクライアントを利用して他の統合Cosmosチェーンの署名を直接検証しています。
このタイプのプロトコルは不正や有効性の証明ではなくバリデーターのコンセンサスに直接依存するため、ソースチェーンのバリデーターのコンセンサスを侵害するあらゆる攻撃に対しては脆弱です。
また、この種のプロトコルの多くはハードフォークに対して脆弱ですが、Tendermintのような即時のファイナリティを提供するいくつかのコンセンサスアルゴリズムは、このリスクを制限することを目指しています。
これら最初の2つのカテゴリー（2.1と2.2）は、一般的にソースチェーンから保証を継承し、強力なセキュリティを確保しています。さらに、このタイプのプロトコルは資本効率に優れ（経済的な安全性に依存しない）、メッセージパッシングに柔軟性を持たせることができる傾向にあります。
しかし、この種のアプローチは拡張が困難な場合もあります。これは、ソースチェーンとデスティネーションチェーンに新たなスマートコントラクトを実装し、異なるコンセンサスのペアごとに特定の実装を行う必要があるためです。採用するコンセンサスメカニズムに応じてコントラクトを書き換える必要があることから、このようなアプローチの適応性はさらに制限されます。
2.3 Optimistic（楽観的な）外部バリデーション
前述のアプローチとは対照的に、このカテゴリのプロトコルは、セキュリティを確保するために外部のアクターを採用しています。
これらのプロトコルはOptimistic Rollupの機能に類似した方法を採用しており、メッセージの有効性をチェックして一定のチャレンジウィンドウ期間（通常約30分）内にFraud Proof（虚偽であることの証明）を提出する「ウォッチャー」という役割を設定しています。
この仕組みにおいては虚偽である証明を提出するウォッチャーが1人でもいれば十分であるため、n分の1の少数派の仮定（1-of-n honest minority assumption）を与えます。しかしこのモデルの支持者は、チャレンジウィンドウの間、少なくとも1人の正直なウォッチャーがオンラインである必要があることをはっきり言わない場合が少なくありません。
また、チャレンジウィンドウが比較的短いことを考慮すると、このモデルが実際にどの程度安全であるかはまだ分かりません。もちろんウォッチャーの数を増やし、チャレンジウィンドウを長くすればプロトコルの安全性は高まりますが、特に後者は代償としてレイテンシーが犠牲になります。参考までに、現在最も有力なOptimisticメッセージング・プロトコルであるNomadは、30分のチャレンジ・ウィンドウを採用しています。
2.4 コンセンサス付き外部バリデーター群
このカテゴリーは最も広がっており、現在のブリッジおよび相互運用性プロトコルの大部分はここに含まれています。このタイプのプロトコルは、セキュリティを確保し取引の正当性を検証するために、ソース・デスティネーションのチェーンの外側にある一連の外部アクターに依存しています。
このカテゴリには、中間チェーン（Axelar）からオフチェーンアクター群（Multichain、Synapse、LayerZero）、メッセージも検証する他チェーンの外部バリデーター（Wormhole）まで、さまざまなアプローチがあります。
外部アクターはマルチシグやしきい値署名などの方法によってコンセンサスを確立します。
このカテゴリのメンバーは、セキュリティを向上させるために経済的なインセンティブを用いることもあります。これには、保証と保険という2つの一般的な形態があります。保証タイプではバリデーターは何らかの担保を差し入れなければならず、不正を働いたことが証明された場合にはこの担保を没収されます。
この場合、一般的には担保はバーンされますが、よく考えてみるとこれはかなり奇妙なことです。この担保は、このバリデーターの不正によって損失を被ったユーザーへの弁済に使うこともできるはずだからです。保険タイプの場合、資金が失われたユーザーに対してはこの担保を切り崩して弁済します。
クロスチェーンプロトコルを攻撃することによる真の経済的利益を理解することは非常に困難ですが、UXD Protocolが定義するフレームワーク「Max Attackable Value（MAV）」を使うとある程度合理的な値を算出することができます。
MAV = max (Value that can be stolen at time t)
MAV = max (時間tに盗める価値)
MAVはフロー型プロトコル、すなわちプロトコル内でアイドル流動性を必要としないクロスチェーンメッセージやスワップでは低く、一方で資本を大量に保有しているストック型プロトコルでは高くなります。
特に、MAVの大きさは、経済的安全性を維持するためにバリデータが保有 / 保証しなければならない資本の大きさに影響します。したがって、MAV（＝保証済みの総資本）をチェーンの経済的安全性の近似解とすることが可能です。
また、ロック資産を持たない一般的なメッセージパッシングプロトコルの場合でも、送信されるメッセージの内容や各チェーン上で相互作用する相手やアプリケーションによっては、攻撃が発生する経済的インセンティブが残っている可能性があります。これらは関係するシステムが複雑であるため、定量化が困難な場合もあります。
したがって、オフチェーン・アクターの悪意ある行動を抑制するために保有すべき必要な資本量は簡単には決定できません。
トークンを担保にするプロトコルは、トークンの価値が急落した場合にデススパイラルに陥る可能性があり、さらに担保となる資産がチェーン間を移動する資産と異なる場合には、両者をつなぐ価格オラクルに対する攻撃によってさらなる脆弱性が生じる可能性があります。
また、トークンを担保とするこれらの方法は安全性を高める一方で、メッセージのスループットが高まるにつれて必要な担保の価値が大きくなり、資本効率を低下させることに留意する必要があります。
このカテゴリーに属するプロトコルは、採用している検証メカニズムによってその安全性が異なりますが、多くの場合仕組みを一般化可能で、かつスケーラブル・低遅延という特徴があります。
2.5 ローカルで検証された外部バリデーター群
最後に、外部バリデーター群に関する特殊なケースとして、ローカル検証プロトコルを挙げます。このようなプロトコルでは、ある取引に関与する当事者のみがその取引を検証する必要があります。これは外部のバリデーター群全体からの合意を必要とする、 これまでのタイプとは対照的です。
この分類においては、関係する2当事者について追加の仮定が導入されています。具体的には両者は(1.) お互いに敵対しており、共謀してプロトコルから資金を盗むことができない、経済的に採算が合わないか、(2.)彼ら自身のトランザクションから隔離されており、プロトコルの資金にアクセスすることはできないといういずれかの状態にあるというものです。
ConnextやHopなどのプロトコルはマーケットメーカーのような当事者とのOTC（店頭取引）と考えることができるため、一般に「流動性ネットワーク」と呼ばれています。
3. 現在のプロトコル
このセクションでは、ブロックチェーン・インターオペラビリティを実現しようとするいくつかの著名プロトコルを説明し、比較します。
3.1 Abacus
Abacusは開発中のチェーン間メッセージングプロトコルで、外部の委任型PoSバリデーター群に依存しています。Abacusは、チェーン間メッセージを送受信するためのシンプルなオンチェーンAPIを提供します。
このプロトコルは、「Outbox」と「Inbox」という2つのシンプルなスマートコントラクトに依存し、その後比較的シンプルな dispatch() 関数と handle() 関数を呼び出しています。特に、Abacusがサポートするすべてのチェーンにはメッセージの疎なマークルツリーを保存するoutboxコントラクトが存在します。
Abacusがサポートするすべてのチェーンにはn-1個のInboxがあり、サポートする他のチェーンにその1つずつが対応しています。メッセージは、それぞれのOutboxコントラクトに対して署名されたマークルルートに対するマークルプルーフを提供することにより、Inboxにリレイヤーを通して配信されます。リレイヤーの処理機能は、マークルルート、メッセージ、マークルプルーフを入力し、受信者にメッセージを送信するだけです。
セキュリティ面では、アプリケーションは外部のバリデーターを独自に指定することもでき、トランザクションを送信する際には両方のバリデーター群からの合意が必要です。これにより、ネイティブのバリデーター群が侵害された場合のセキュリティは向上しますが、この場合もネイティブのバリデーター群が取引に署名する必要があるため、ライブネスに関して追加の仮定が生じます。
さらに、Abacusがサポートする各チェーンには独自のバリデーター群が必要であり、 セキュリティが断片化する可能性があるほか、他すべてのチェーンのバリデーター群の構造を理解するために、常に情報を更新する必要があります。
バリデーターはABCトークンをステークする必要があり、ユーザーは同トークンを委任しなくてはなりません。バリデーターとユーザーのいずれにも21日間の引き出し制限があります。トークンをステークしたユーザーはABCトークンのインフレ新規発行分が報酬として付与されますが、バリデーターが正当なOutboxマークルルート以外に署名しようとするなど、メッセージを検閲しようとした場合にはトークンを没収されます。
また、不正なメッセージの証拠は誰でもネットワークに提出することができ、これを行うユーザーは「監視塔（Watchtower）」と呼ばれます。バリデーターやリレイヤーになるのにも制限はありません。
他のプロトコルとは異なり、バリデーターは個々のメッセージに署名するのではなく、チェックポイントに署名します。このチェックポイントは、接続されたチェーンのすべてのアプリケーションからのすべてのメッセージに対応するマークルルートにすぎません。
3.2 Axelar
Axelarは汎用メッセージパッシングプロトコルで、委任型PoSを用いたパーミッションレスのネットワークバリデーターの分散化セットに依存しています。
このプロトコルはコンセンサスメカニズムやメッセージペイロードに関係なく、あらゆる通信をサポートすると主張していますが、現在サポートされているのはEVMとIBCチェーンのみです。
本稿執筆時点ではAxelarは23のチェーンに接続されています。現在存在するバリデーター数は48、合計で$97.31MのTVLを保有しています。現在のステータスはこちらから確認できます。
バリデーターは、標準的なL1の上に載るマルチパーティ暗号プロトコルであるクロスチェーンゲートウェイプロトコル（各L1のしきい値署名アカウントを経由）を実行し、メッセージを読み書きしたり、コントラクトを呼び出したりすることができます。
基本的に「ゲートウェイ」コントラクトは各L1上に置かれ、 入ってくる取引を監視しています。バリデーターはそれを読み込んで検証を行い、相手チェーンのゲートウェイコントラクトに書き込みます。
オンチェーンのステートは、クロスチェーントランザクションとソース・デスティネーションチェーン上のアドレスで構成されています。
Axelarの構造上の制限事項の1つは、 _execute() 関数を呼び出すために、デスティネーションチェーンのコントラクトアドレスが IAxelarExecutable インターフェイスを実装する必要があることです。
この _execute() 関数の中で任意のロジックを定義することができます。
ゲートウェイ間の処理は、現在の実装では約120秒かかります。開発者はnonced cross-chain executionやsend-ackパターンなどの追加機能を実装することで、クロスチェーンのアトミック性などを解決し、コントラクト間でステートを同期させることが可能です。
図2に示すように、この仕組みは最終的に最適化されたチェーン上に中央のdAppロジックを構築し、他のチェーンのサテライトコントラクトとともに単純なハブ・スポークモデルを構成できると考えられます。
バリデーターはサポートするチェーンを選択しますが、ソースチェーンとデスティネーションチェーンの両方で明示的にノードソフトウェアを実行する必要があります。
バリデーターはソースチェーンのステートを監視し、ソースチェーンとデスティネーションチェーン、Axelarの3者間の取引を確立する投票を行うことで、すべてのクロスチェーンアクティビティを検証します。
バリデーターはAXLトークンをステークし、インフレ報酬と取引手数料を受け取ります（ただし、ここで支払われるトークンが明示的にAXLである必要はありません）。不正行為（ライブネスの喪失、二重署名など）があった場合、バリデーターの担保は没収される可能性があります。
Axelarはまた、投票を始める際のバリデーターの調整やオンチェーンアドレスの監視など、機密性の低いタスクを実行するオフチェーンリレーヤーの集合に依存しています。 リレーヤーのアーキテクチャは柔軟でパーミッションレスです。
3.3 Chainlink CCIP
Chainlinkは最近、CCIP（Cross-Chain Interoperability Protocol）と呼ばれる汎用クロスチェーンメッセージング用の分散型プロトコルを発表しました。CCIPはChainlinkがオフチェーンレポートプロトコル（OCR）に対して今後実行予定の、効率性アップグレード群に依存しています。
OCR 2.0と呼ばれるこの一連のアップグレードは、ネットワークがより多くのノードを実行できるようにするものです。
図4は、CCIPのハイレベル構造の概要を示しています。CCIPでは、メッセージはソース / デスティネーションチェーン上のスマートコントラクトからChainlinkのノードネットワークにルーティングされます。
入手可能なドキュメントによると、メッセージングは現在のChainlinkのオラクル送信モデルと同様に機能することになっています。このモデルではChainlinkはデータを読み取り、ノードネットワークに送信するために、オラクルと外部アダプターコントラクトを運用しています。
ノードは許可制で、LINKトークンをステークすることが要求されます。そしてメッセージがリレーされるとそこから手数料を得ることができます。
前述のOCRコンセンサス・メカニズムに加え、CCIPは「耐不正ネットワーク（Anti Fraud Network, AFN）」と呼ぶ二次セキュリティ・レイヤーを含める計画があります。このAFNは分散型オラクルノードの委員会として構成され、悪意のある活動がないかCCIPネットワークを監視し、システムが正常に動作している場合にはハートビート（心音）メッセージを送信します。CCIPにおける攻撃やハートビートの停止を検知すると、関連するクロスチェーンサービスを緊急停止させます。
AFNは当初Chainlinkノードで構成されますが、最終的には特定のステーキング基準を満たすdAppsが独自のノードを運営できるようになる予定です。プロトコルはソースチェーンから発信される証明とは対照的に、コンセンサスのためにオラクルに依存しているため、プロトコルのセキュリティは、基盤となるオラクルとAFNのセキュリティに依存します。
そのため、プロトコルはこれら2つのどちらかに対する攻撃や、それらの間の共謀に対しては脆弱なままです。
3.4 IBC
IBC（Inter-Blockchain Communication Protocol）はオープンソースのインターオペラビリティプロトコルであり、ブロックチェーン間の汎用メッセージングを即時のファイナリティとともに提供します。特筆すべきは、IBCがCosmosエコシステムに採用されていることです。
IBCプロトコルは、主に2つのレイヤーで構成されています。最下層はトランスポートレイヤーで、ブロックチェーン間の安全な接続を確立し、データパケットを認証します。この層の上にあるアプリケーションレイヤーは、データパケットの解釈と小分けを行うものとしてプロトコルによって定義されています。
図5 はIBC のメッセージライフサイクルの概要です。
トランスポートレイヤーにおける認証と検証は、接続チェーンのコンセンサスレイヤー上のバリデーターに接続されたライトクライアントによって処理されます。ソースチェーンのモジュールは、データパケットをデスティネーションチェーンに送信する際、まずパケット情報にリンクしたコミットメント証明をオンチェーンに保存します。
ライトクライアントは、接続チェーン間の接続ハンドシェイクを維持し、証明をデスティネーションチェーンに送信します。両チェーンのフルノードにアクセスできるオフチェーンリレーヤーは、各チェーンのIBCモジュール間でメッセージデータを伝送します。
デスティネーションチェーンがソースチェーンの証明を検証すると、ライトクライアントはメッセージ受信データを保存し、ソースチェーンに確認メッセージを送信します。最後に、送信されたメッセージに基づいてデスティネーションチェーンがロジックを実行します。
IBCはコンセンサスを直接検証するライトクライアントを利用しているため、現在のインターオペラビリティ・プロトコルの中では最も「トラストレスな」プロトコルの一つとなっています。
しかしこのようなセキュリティの保証は柔軟性を犠牲にしています。接続されたチェーンが互換性を持つためには、ベースレイヤーでライトクライアントを実行し、即時のファイナリティを持つ必要があります。この即時ファイナリティのため、ライブネスに対する攻撃はIBCの安全性を損ないません。しかし、リレイヤーが故障したり攻撃を受けたりした場合、IBCは一般にリレイヤー間の協調を必要とし、ライブネスを再確立する必要があります。
3.5 LayerZero
先に述べたプロトコルとは対照的に、LayerZeroはセキュリティのためにリレイヤーとオラクルの2種類のオフチェーン・エンティティに依存しています。
事実上、 この2つは2人で管理するマルチシグと同じように機能します。リレイヤーがチェーン間でメッセージ情報と取引証明を橋渡しするのに対し、オラクルはデスティネーション・ソースチェーン間でブロックヘッダーを渡し、オラクルとリレイヤーの合意を保証します。
オラクルとリレイヤーはセキュリティを保証するためにそれぞれ独立していなければなりませんが、具体的な実装についてはユーザーに任されています。理論的には、ユーザーとプロトコルはそれぞれ独自の実装を提供することができます。
リレイヤーもオラクルも、元チェーン上でユーザーが支払う取引手数料の一部を受け取ります。現在、オラクルはFTX、Sequoia、Polygonなどの企業によって集中的に管理・運営されていますが、LayerZeroは将来的にChainlinkをデフォルトのオラクルとして使用する意向を表明しています。
LayerZeroは1章で定義した技術スタックのうち、「ベースレイヤー」の具体的な実装として理解するのが最も適切です。なぜなら、LayerZeroはリレイヤーとオラクルの関係（デフォルト設定も存在はします）や送信するメッセージの形式をユーザーが指定することができるからです。
クロスチェーントークン転送プロトコルのStargateは、LayerZeroを低レベルのメッセージングプロトコルとして使用したアプリケーションです。
LayerZeroのインターフェースは、LayerZero Endpointと呼ばれるオンチェーン軽量クライアントです。このエンドポイントはサポートされる各チェーンに1つずつ存在します。エンドポイントはコミュニケーター、バリデーター、ネットワークモジュールの3つで構成されています。
柔軟性を高めるため、エンドポイントは「ライブラリ」と呼ばれるチェーン固有の通信プロトコルを内包するリンク済みスマートコントラクトを介して拡張することができます。
ライブラリは一度実装すると変更できませんが、アプリケーションが新しいライブラリを追加し、どのライブラリを使用するかを指定できるようにすることで、プロトコルは柔軟性を確保しています。
LayerZeroは一般的なメッセージパッシングをサポートしていますが、前述の通り、渡すべきInterface（メッセージの形式）は指定していません。アプリケーションは送受信機能に対応するメソッドを実装することで、LayerZeroと対話します。
LayerZeroのホワイトペーパーは2021年5月に最初に公開されたものの、エコシステムはまだ発展途上にあります。本稿執筆時点で、LayerZeroは7つのEVMチェーンに接続しており、CosmosやSolanaを含む他のチェーンに拡大する計画があることが明言されています。アプリケーションレイヤーでは、LayerZeroのdAppsエコシステムは現在、$468MのTVLを持つクロスチェーンルーティング・流動性プロトコルであるStargateによって構成されています。
オラクルとリレイヤーのノードやオペレータの数については、公表されているリソースから詳細な情報は得られませんでした。
LayerZeroへの批判で最もよく言われるのは、オラクルとリレイヤーのパーティーの実装に関して自由度の高い実装を認めることによって、ある意味デフォルトの実装が不明確となっているというものです。また、これら当事者間の談合をどのように防止するのかも不明瞭です。
3.6 Multichain
以前はAnySwapとして知られていたMultichainは、アセットブリッジおよびルーターとして2020年7月にローンチしました。
MultichainのセキュリティはオフチェーンMPCネットワークに依存しており、各ノードが独立して元チェーンのステートを検証し、しきい値コンセンサスアルゴリズムを使用しています。なお、このバリデーター群はパーミッションレスではないようです。
Multichainは従来のLock&BurnブリッジやanyTokens（anyUSDCなど）を仲介トークンとした流動性ルーター、チェーンをまたいだコントラクト呼び出しサービスのanyCallを提供しています。これらには、関連するスマートコントラクトとバリデーターのリスクが伴います。
anySwapの基礎となるメッセージパッシングプロトコル「anyCall」は、チェーンをまたいだメッセージパッシングを可能にします。メッセージはMPCネットワークを介し、接続されたチェーン上のエンドポイントによって送受信されます。上述のように、Multichainはソースチェーンの状態を監視するバリデータノードのMPC TSSスキームを使用しています。Axelarと同様、anyCallエンドポイントはanyCallプロトコルを通して送信される命令を実装する anyExec() 関数を含んでいます。
ワークフローは以下の通りです。
誰かが発信元チェーン上のSenderコントラクトの呼び出しを開始
=⇒ anyCall(source chain) が呼び出される
=⇒ MPCネットワークが anyCall(source chain) を確認
=⇒ anyExec(destination chain)
=⇒ anyCall(executor)
=⇒ anyExec(destination chain)
Multichainでは、ガス料金は発信元と発信先チェーンのどちらで支払ってもよいことになっています。
例えばanyCallが最初に統合したCurveのゲージ機構は、クロスチェーンでのCRVリワード展開を可能にすることで一般化されています。一例として、Ethereum上で処理される報酬引き換えリクエストを経由して、ラップされたCRVをFantom上で請求できます。
直感的にはanyCallとAxelarの（予想される）機能は非常に似ているように見えますが、 主な違いは
（i）Multichainはステーキングを必要としない（資本効率において優れているが、MPCノードの安全性はその評判に依存する）
（ii）Axelarはより多様でパーミッションレスなバリデーターセットを持つ（その分資本効率は悪く、経済的安全性を確保する必要がある）
といった点にみられます。
現在、Multichain SMPCネットワークは、EVMと非EVMの両方、63のチェーンに接続した23ノードで構成され、CurveやHundred FinanceなどのdAppsで使用されています。本稿執筆時点で、同ネットワークのTVLは$2.51B、日次の平均取引額は$54Mです。 最新の情報についてはこちらから確認できます。
3.7 Nomad
前述のプロトコルとは異なり、NomadはコンセンサスモデルではなくOptimisticモデルで動作します。これは、今日のOptimistic Rollupと同じように機能します。Nomadプロトコルは、オフチェーンリレーヤーとメッセージの送信・キュー作成を行うオンチェーンのエンドポイントコントラクトで構成されています。
図7は、Nomadメッセージングプロトコルの構造の概要を示しています。
メッセージは元チェーンからHomeコントラクトを介して送信され、そこでキューに入れられます 。Abacusと同様に、すべてのチェーンはHomeコントラクトを実装する必要があり、送信されるメッセージの最終的なソースはマークルツリーに格納されます。
n -1個のReplicaコントラクトは、n -1個存在する他の接続チェーンのHomeコントラクトにそれぞれ対応します。また、現在のステートルートとアップデータの詳細情報を保持します。
各Homeコントラクトはブロードキャスト用のチャンネルとして機能し、広範なイベントを発信します。つまり、そのHomeコントラクトを参照している他チェーン上のk個のReplicaコントラクト全てが、発信されたイベントについて一度に更新を受け取ることができます。この仕組みは通知システムのようなより広い用途で一対多ブロックチェーン間通信に活用できる可能性も秘めています。
現在、アップデータはNomadのガバナンスシステムを通じてのみ設定可能ですが、将来的にはよりトラストレスな方法で行われるようになると思われます。
Nomadのセキュリティモデルでは、アップデータによって署名されたメッセージは30分のチャレンジウインドウの間に虚偽であることの証明（Fraud Proof）を提出した監視者によって拒否される可能性があります。
この設定の下では1人の監視者が証明を提出すれば十分であるため、n分の1の少数派の仮定が成立します。しかしこのモデルの支持者は、チャレンジウィンドウの期間中、一人以上の正直な監視者が確実にオンラインでなくてはならないことを必ずしも明確にしていません。チャレンジウィンドウが比較的短いことを考えると、このモデルが実際にどの程度安全であるかはまだ不明です。
また、チャレンジウィンドウの計算は関係するブロックチェーンに依存しており、ブロックタイムと確認時間の違いにより、理論的にはそれぞれのチェーンのHome - Replicaペアを個別に調整する必要があるかもしれません。もし悪意ある行為者が監視者によるHomeチェーンへの虚偽証明の提出をこのウィンドウチャレンジ期間より長い間ブロックすることができれば、そのメッセージは差し止められないまま、Replicaチェーンで実行されてしまう可能性があります。
現在のシステムでは、「これが虚偽である」という証明を偽って提出すること（虚偽の虚偽証明）を防止する仕組みがないため、監視者は認可制で集中管理されています。不正は、アップデータがメッセージ付きの悪意のあるマークルルートに署名したときに発生します。
この不正は2つの異なる形で発生しえます。まずアップデータは、過去の同じルートに繋がる2つの新しいルートをコミットすることがあります（二重署名）。2つ目は、アップデータが無効なアップデートをコミットする場合です。
前者は発見が容易ですが、後者はHomeコントラクトのメッセージキューを参照し、当該ルートが提案・計算されたルートのキューに含まれていないことに気づく必要があります。しかしこの種の不正は、Homeコントラクト（メッセージの最初のソース）では証明できますが、Replicaコントラクトでは直接証明することができず、コントラクトを停止することもできないのです。
そこでNomadは、Replicaチェーン上でメッセージの受信を一時停止する権限を持つ監視者の集団を利用しています。不正行為が検出された場合、システムは処理に失敗したステートから再起動しなければなりません。経済的な安全性を確保するため、アップデータのステークを没収して、問題の根本原因がそのままにならないよう保護する必要があります。
2022年8月、Nomadは受信コントラクトがメッセージ検証メカニズムを回避できるというバグを悪用され、$190Mのハッキングを受けました。
3.8 Synapse
SynapseはクロスチェーンAMM・ブリッジプロトコルです。当初は資産のブリッジにフォーカスしてローンチされましたが、2022年7月により一般化されたメッセージパッシングへの移行を発表しました。
この移行の一環として、SynapseはETHに基盤を置く委任型PoSでOptimistic Rollupを採用したSynapse Chainを立ち上げる予定です。しかし、実装の仕様に関する情報はまだ散発的にしか出ていません。
Synapseは、SYNトークンがスタンドアロンのブロックチェーンを動かし、そのチェーンがOptimistic Rollupとしてそれ自体に経済的価値を発生させるという意味でユニークな存在です 。具体的なロールアップの実装は不明ですが、初期の資料を見る限り、当初は中央集権的なシーケンサーを採用し、ArbitrumやOptimismと同様のデザインを選択する可能性が高いと思われます。
チェーン間のトランザクションの伝送と検証を行うため、Synapseは4つのオンチェーン・アクターに依存する予定です。
公証人（Notaries） - 接続したチェーン上のマークルルートに署名し、SYNを担保として差し出す
ブロードキャスター - 更新情報をコントラクト間で転送する
ガーディアン - クロスチェーンメッセージを監視し、虚偽である場合はその証明を提出する
エグゼキュータ - 証明提出可能期間のあと、最終トランザクションをアップロードする
これらの設定は、Nomadの実装と基本的に同じように機能します。まず、ユーザーはソースチェーンのメッセージをルーターコントラクトに送り、中央集権的で許可制の「公証人」が更新されたマークルルートの証明に署名します。続いて、メッセージはデスティネーションチェーンのルーターコントラクトへと渡されますが、これが一対多の配信形式であるかどうかはまだ不明です。ガーディアンが不正をチェックし、何も検出されなかった場合、メッセージはデスティネーションチェーンのエクゼキュータによって実行されます。
クロスチェーンメッセージングに対する楽観的（Optimistic）方法による検証についてはまだ微妙な点もありますが、このセキュリティモデルが現在のSynapseのマルチシグモデルと比較して大きく改善されていることは確かです。
Synapseブリッジアプリケーションは現在16チェーンに接続されており、TVLは$206M、1日の出来高は$8.41Mです。詳細な情報についてはダッシュボードを確認してください。
本稿執筆時点では、より広範なメッセージングプロトコルの詳細や接続チェーンについてはまだ公開されていません。
3.9 Wormhole
Wormholeは、セキュリティを外部の検証機能に頼る汎用メッセージングプロトコルです。Wormholeのネットワークは「ガーディアン」と呼ばれる19のオラクルで構成されており、これらはそれぞれ接続された各チェーンのフルノードを運用する認可制のPoSバリデーターに相当します。
開発者はxDappコントラクトをソースチェーンにデプロイし、エンドユーザーからのトランザクションを受け取ります。これらのコントラクトはその後、ブリッジと汎用メッセージパッシング機能を含むソースチェーン上の Coreコントラクトとやり取りします。
ただし、汎用メッセージパッシングを扱うRelayコントラクトはまだ開発中です。現在、WormholeエコシステムにはNFTブリッジとPortalトークンブリッジが含まれており、執筆時点のTVLは$493.12Mとなっています。なお、WormholeはSolana、Terra、Ethereum、Binance Smart Chainをサポートしています。
図9はWormholeのプロトコル構造を示しています。
ガーディアンは接続されたすべてのブリッジのエンドポイントを監視し、トランザクションを検証する責任を負います。プロトコルによって中央集権的に選出されるガーディアンには平等な重みが与えられており、担保を預け入れる必要はありません。トランザクションはマルチシグ方式で確認され、執筆時点では2/3のしきい値が設定されています。
繰り返しになりますが、現在のWormholeは取引の検証を19のバリデーターのうち13の承認を必要とするマルチシグで行っており、これはつまりFigment、FTX、Stakedなどのガーディアンを運営する主体の評判に依存しているということです。
しかし、このトレードオフにも利点があります。Wormholeはシュノア署名（t-Schnorr signature）という非常にシンプルな技術を採用しているため、異なるコンセンサスタイプのチェーンとも迅速に統合することが可能です。また、リレイヤーはセキュリティモデルの一部として組み込まれる必要はなく、ブロックチェーンにメッセージを送信する機能を備えていればよいのです。
ガーディアンに加えてWormholeは、ガーディアンからデスティネーションチェーンのコントラクトへとメッセージを送信するために、一般によってトラストレスに運営されるリレイヤーも利用する予定です。本稿執筆時点では、この「汎用リレイヤー」はまだ開発中です。
2022年2月、WormholeはSolana上のエンドポイントコントラクトのバグによって$325Mのハッキング被害に遭いました。
4. 結論
以上のことからUXDでは、クロスチェーンのメッセージングプロトコルの多くは、ベースレイヤーのレベルでは基本的に類似していると認識しています。チェーンXとYにそれぞれ展開されたコントラクトがメッセージを受け付けた後、それを誰かが検証（あるいは無効化）してチェーンY上の姉妹コントラクトにメッセージを伝え、そのコントラクトが何らかの命令を実行するというものです。
一方認証レイヤーにおいては有意な差が見られ、ここには効率性や安全性の面で最適化の余地が残っていると思われます。例えば、LayerZeroは認証レイヤーに依存しないベースレイヤーとトランスポートレイヤーと考えることができ、任意の主体またはその集団がオラクルとリレイヤーの役割を果たすことができます。PoSバリデーターによって構成される分散型ネットワークは、それ自体がLayerZeroネットワークのリレイヤーとしても活動できます。
AxelarやWormholeのような他のプロトコルは、それぞれdPoSとマルチシグ認証レイヤーを選択します。それぞれのクロスチェーンプロトコルのドキュメントにはあまり書かれていませんが、一つだけ注意すべき点はレイテンシーです。なお、この遅延は チェーンXで1ブロック確認⇒メッセージを伝達⇒チェーンYで1ブロック確認 というプロセスにかかる時間となるので、そこには絶対的な最小値が存在します。したがってほとんどのチェーンでは、最小遅延は数秒から数分のオーダーということになります。
しかしクロスチェーンの世界では、プロトコルの性質上頻繁なやり取り（主に発行/償還、借入/貸出）は必要ないと思われるので、Optimisticモデルでの30分のチャレンジウインドウの待ち時間は許容範囲内かもしれません。私たちはクロスチェーン戦略を開発する中で、これらの選択肢を引き続き検討していきます。
UXDの目的には、独自のパラメータ（オラクル / リレイヤー、最小ブロック確認など）を設定できるLayerZeroモデルか、AxelarやNomadのような「導入してすぐに使える」ソリューションが適していると考えています。
5. 免責事項およびリスク
すべての分散型ステーブルコインは、その使用と価格の安定に関連するリスクを伴います。UXD Protocolの潜在的なリスクに関する詳細については、こちらのセクションをご覧ください。
またこの記事は情報提供を目的としており、いかなる行動を推奨するものでもありません。何らかの投資判断を行う際には十分な調査を行ったり、財務アドバイザーに相談したりした上で行動するようにしてください。また、記事の正確性には万全を期していますが、内容に何らかの瑕疵があった場合の責任を負うものではありません。
ここまでお読みいただきありがとうございました。以下のリンク先のサイトでは、UXD Protocolに関するより詳細な情報を掲載しております。
公式ウェブサイト：http://uxd.fi/
Twitterアカウント：https://twitter.com/UXDProtocol_JPN
Discordサーバー：https://discord.com/invite/BHfpYmjsBM
この記事が気に入ったらサポートをしてみませんか？