ゲーム理論に基づいた相互運用性プロトコルは信頼の難問を解決できるでしょうか?

著者: STANFORD BLOCKCHAIN CLUB 編集者: Cointime: QDD。
導入
未来はマルチチェーンです。スケーラビリティの追求により、イーサリアムはローリング ソリューションへと導かれます。モジュラー ブロックチェーンへの移行により、アプリケーション チェーンへの関心が新たに高まっています。近い将来、アプリケーション固有のローリング ソリューション、レイヤー 3 ソリューション、ソブリン チェーンの噂が聞こえてきます。しかし、これにはすべて断片化という代償が伴い、現在のブリッジは機能が制限されていることが多く、セキュリティの提供を信頼できる署名者に依存しています。
インターネット 3.0 における相互接続の最終形態はどのようなものになるでしょうか?私たちは、ブリッジが最終的にはクロスチェーン メッセージングまたは任意メッセージ パッシング (AMP) プロトコルに進化して、新しいユースケースを解放し、アプリケーションがソース チェーンとターゲット チェーンの間で任意のメッセージを受け渡すことができるようになると考えています。また、ビルダーが使いやすさ、複雑さ、セキュリティに関してさまざまなトレードオフを行う「信頼環境」の台頭も見られるでしょう。
すべての AMP ソリューションには、次の 2 つの重要な機能が必要です。
1. 検証: ターゲット チェーン上のソース チェーン メッセージの有効性を検証します。
2. 生存可能性: ソース チェーンからターゲット チェーンに情報を送信する能力。
残念ながら、100% トラストレス検証は非現実的であり、ユーザーは、検証がオンチェーンで行われるかオフチェーンで行われるかに応じて、コード、ゲーム理論、人間 (またはエンティティ)、またはそれらの組み合わせを信頼する必要があります。
この記事では、使用される信頼メカニズムと統合アーキテクチャに基づいて、全体的な相互運用性の状況を垂直方向と水平方向に分割します。
信頼メカニズム:
1. コードと数学を信頼する: これらのソリューションには、誰でも検証できるオンチェーン証明があります。これらのソリューションは、ターゲット チェーン上のソース チェーンのコンセンサスを検証したり、ターゲット チェーン上のソース チェーンの状態遷移の妥当性を検証したりするために、ライト クライアントに依存することがよくあります。ライトクライアントでの検証は、任意の長さの計算をオフラインで圧縮し、計算を証明するための簡単な検証をオンチェーンで提供するゼロ知識証明を通じてより効率的にすることができます。
2. 信頼ゲーム理論: ユーザー/アプリケーションがトランザクションの信頼性を保証するためにサードパーティまたはサードパーティのグループを信頼する必要がある場合、追加の信頼仮定があります。これらのメカニズムは、経済的インセンティブや楽観的セキュリティなどのゲーム理論と組み合わせたパーミッションレス ネットワークを通じて、より安全にすることができます。
3. 人間を信頼する: これらのソリューションは、大多数のバリデーターの誠実さ、またはさまざまな情報を提供するエンティティの独立性に依存しています。 2 つのインタラクティブ チェーンのコンセンサスを信頼することに加えて、サードパーティの信頼も必要です。ここでは参加団体の評判のみが関係します。十分な参加エンティティがトランザクションを有効とみなした場合、トランザクションは有効とみなされます。
すべてのソリューションには、コードと人間に対するある程度の信頼が必要であることに注意することが重要です。欠陥のあるコード ソリューションはハッカーによって悪用される可能性があり、すべてのソリューションにはコード ベースのセットアップ、アップグレード、保守に人的要素が含まれています。
統合アーキテクチャ:
1. ピアツーピア モデル: 各ソース チェーンと各ターゲット チェーンの間に専用の通信チャネルを確立する必要があります。
2. 中央ハブ モデル: ハブに接続されている他のすべてのブロックチェーンを接続できる中央ハブとの通信チャネルを確立する必要があります。
接続されたブロックチェーンごとに 1 対の通信チャネルが必要となるため、ピアツーピア モデルの拡張は比較的困難です。コンセンサスやフレームワークが異なるブロックチェーンにとって、これらのチャネルの開発は困難な場合があります。ただし、必要に応じて、中央ハブを介したマルチホップ ルーティングにチェーン間通信プロトコル (IBC) を使用するなど、ハイブリッド アプローチを採用することもできます。これにより、直接的なポイントツーポイント通信の必要性がなくなりますが、より多くの通信が必要になります。セキュリティ、レイテンシー、コストの観点から。
コードと数学を信頼する
信頼の仮定をコード/数学のみに依存するために、ライト クライアントを使用して、ターゲット チェーン上のソース チェーンのコンセンサスを検証できます。ライト クライアント/ノードは、フル ノードに接続してブロックチェーンと対話するソフトウェアです。ターゲット チェーン上のライト クライアントは通常、ソース チェーンのブロック ヘッダーを (順番に) 保存します。これはトランザクションを検証するのに十分です。同様に、ソース チェーン上のオフチェーン エージェント (リレーラーなど) はイベントを監視し、暗号化された包含証明を生成し、それらをブロック ヘッダーとともにターゲット チェーン上のライト クライアントに転送します。ライト クライアントはブロック ヘッダーを順番に保存するため、各ブロック ヘッダーに状態を証明するために使用されるマークル ルート ハッシュが含まれているため、トランザクションを検証できます。以下は、このアプローチの主な機能の概要です。
安全
信頼の仮定は、ライトクライアントの初期化中に導入されます。新しいライト クライアントが作成されると、特定の高さのブロック ヘッダーで初期化されます。ただし、提供されたブロック ヘッダーが間違っている可能性があり、偽造されたブロック ヘッダーで軽量クライアントを騙すことが可能になります。ライトクライアントの初期化が完了すると、それ以上の信頼仮定は導入されません。ただし、この初期化プロセスは誰でも検証できるため、より弱い信頼の前提に依存していることに注意してください。さらに、中継器は情報を送信する責任があるため、中継器の継続性も信頼の前提となります。
成し遂げる
ライト クライアントの実装は、認証に必要な暗号化プリミティブが利用できるかどうかに依存します。同じタイプのチェーンに接続している場合、つまり、同じアプリケーション フレームワークとコンセンサス アルゴリズムを共有している場合、双方のライト クライアント実装は同じになります。たとえば、すべての Cosmos SDK ベースのチェーンはブロックチェーン間通信 (IBC) プロトコルを使用します。一方、異なるアプリケーション フレームワークやコンセンサス タイプなど、2 つの異なるタイプのチェーンが接続されている場合、ライト クライアントの実装は異なります。一例として Composable Finance は、Cosmos SDK チェーンを IBC 経由で Polkadot エコシステムの Substrate に接続することに取り組んでいます。これには、Substrate チェーンに Tendermint ライト クライアントを追加し、Cosmos SDK チェーンに「強力な」ライト クライアントを追加する必要があります。最近、彼らはIBCを介してPolkadotとKusamaの間の最初の接続を確立しました。
チャレンジ
資源の集約度は大きな課題です。ブロックチェーンへの書き込みにはコストがかかるため、すべてのチェーンでライト クライアントのペアを実行するとコストがかかる可能性があります。さらに、イーサリアムなどの動的バリデーターセットを備えたチェーン上でライトクライアントを実行することはできません。
スケーラビリティもまた課題です。ライトクライアントの実装はチェーンのアーキテクチャに応じて異なるため、異なるエコシステムを拡張したり接続したりする際に困難が生じます。
コード内のエラーが脆弱性を引き起こす可能性があるため、コードの悪用は潜在的なリスクです。一例は、2022 年 10 月に発生した BNB チェーンの脆弱性です。これにより、すべての IBC 対応チェーンに影響を与える重大なセキュリティ脆弱性が明らかになりました [1]。
すべてのチェーンでライト クライアントのペアを実行するコストと実用性に対処するために、ゼロ知識 (ZK) 証明などの代替手段が、サードパーティへの信頼を排除する方法を提供します。
第三者の信頼のためのソリューションとしてのゼロ知識証明
ZK 証明を使用すると、ソース チェーン上の状態遷移の妥当性をターゲット チェーン上で検証できます。計算全体をオンチェーンで実行するよりも、計算の検証のみをオンチェーンで実行し、実際の計算プロセスをオフチェーンで実行する方が良いでしょう。この方法は、元の計算を再実行するよりも高速で低コストです。例としては、Polymer Labs の Polymer ZK-IBC や Succinct Labs の Telepathy などがあります。 Polymer は、接続性を強化し、必要なペアごとの接続の数を減らすために、マルチホップ サポートを備えた IBC を開発しています。
メカニズムの重要な側面は次のとおりです。
安全
zk-SNARK のセキュリティは楕円曲線に依存しますが、zk-STARK はハッシュ関数に依存します。 zk-SNARK では、検証に使用される証明用の初期キーが作成される、信頼できるセットアップ プロセスが必要になる場合があります。偽造検証によるトランザクションの実行を防ぐために、破壊セットアップ イベントのキーを秘密にしておくことが重要です。信頼できるセットアップが完了すると、それ以上の信頼の仮定は導入されません。さらに、Halo や Halo2 などの新しい ZK フレームワークにより、信頼できるセットアップの必要性が完全になくなります。
成し遂げる
ZK 証明スキームには SNARK、STARK、VPD、SNARG などのさまざまなスキームがあり、現在最も広く使用されているのは SNARK です。 Groth16、Plonk、Marlin、Halo、Halo2 などのさまざまな SNARK 証明フレームワークには、証明サイズ、証明時間、検証時間、メモリ要件、および信頼できるセットアップの必要性においてトレードオフがあります。再帰的 ZK 証明も登場し、証明ワークロードを 1 台だけではなく複数のコンピュータに分散できるようになりました。有効性証明を生成するには、次のコアプリミティブを実装する必要があります: バリデーターによって使用される署名スキームを検証し、チェーンに保存されているバリデーターセットコミットメントにバリデーターの公開鍵の証明を含め、バリデーターセットを追跡する変更が頻繁に発生する可能性があります。
チャレンジ
zkSNARKs でさまざまな署名スキームを実装するには、ドメイン外の算術演算と複雑な楕円曲線演算の実装が必要ですが、これは単純ではなく、チェーンのフレームワークとコンセンサスに基づいてチェーンごとに異なる実装が必要になる場合があります。 ZK 回路の監査は困難であり、エラーが発生しやすい作業です。開発者は、Circom、Cairo、Noir などのドメイン固有言語に精通しているか、単に回路自体を実装する必要がありますが、どちらも困難であり、導入が遅れる可能性があります。時間と労力が非常にかかることが判明した場合、専用のハードウェアを備えた専任チームのみが対応できる可能性があり、集中化につながる可能性があります。校正刷りの生成時間が長くなると遅延も発生します。 Incremental Verifiable Computation (IVC) などの技術は証明時間を最適化できますが、その多くはまだ研究段階にあり、実装を待っています。検証にかかる時間と労力が長くなると、オンチェーンのコストが増加します。
トラストゲーム理論
ゲーム理論に基づく相互運用性プロトコルは、参加エンティティによる誠実な行動をどのように奨励するかに基づいて、大きく 2 つのカテゴリに分類できます。
最初のカテゴリは経済的セキュリティであり、複数の外部アクター (バリデーターなど) が協力して、ソース チェーンの更新された状態についての合意に達します。バリデーターになるためには、参加者は一定量のトークンをステーキングする必要がありますが、悪意のあるアクティビティが発生した場合はトークンが削減される可能性があります。パーミッションレス設定では、誰でもステークを蓄積してバリデーターになることができます。さらに、バリデーターがプロトコルに従うための金銭的インセンティブがブロック報酬の形で提供され、誠実な行動に対する金銭的インセンティブが保証されます。ただし、盗まれる可能性のある金額が賭け金を超える場合、参加者は共謀して資金を盗む可能性があります。経済的セキュリティ メカニズムを使用するプロトコルの例としては、Axelar および Celer IM があります。
2 番目のカテゴリは楽観的セキュリティです。このソリューションでは、少数のブロックチェーン参加者だけが正直でプロトコルのルールに従っているという前提に基づいています。このアプローチでは、1 人の誠実な参加者が保証の役割を果たします。たとえば、最適なソリューションでは、誰でも詐欺の証拠を提出できます。金銭的なインセンティブはありますが、誠実な観察者は不正な取引を見逃す可能性があります。オプティミスティックロールアップもこのメカニズムを使用します。 Nomad および ChainLink CCIP は、オプティミスティック セキュリティを使用するプロトコルの例です。 Nomad の場合、この記事の執筆時点ではホワイトリストに登録されていましたが、観察者は詐欺を証明することができました。 ChainLink CCIPは、分散型オラクルネットワークで構成された不正行為防止ネットワークを利用して悪意のあるアクティビティを監視する計画ですが、CCIPの不正行為防止ネットワークの実装はまだ不明です。
安全
セキュリティの点では、どちらのメカニズムも、ゲーム理論の妥当性を確保するために、検証者とオブザーバーの許可のない参加に依存しています。経済安全メカニズムでは、約束された金額が盗まれる可能性のある金額よりも低い場合、資金はより脆弱になります。一方、楽観的なセキュリティ メカニズムでは、誰も不正の証拠を提出しない場合、または許可オブザーバーが危険にさらされたり削除されたりした場合に、少数派の信頼が悪用される可能性があります。対照的に、経済安全保障メカニズムは、治安維持において活気にあまり依存しません。
埋め込む
実装に関しては、1 つのアプローチには、独自のバリデーターを備えた中間チェーンが含まれます。この設定では、一連の外部バリデーターがソース チェーンを監視し、呼び出しが検出されたときにトランザクションの有効性について合意に達します。合意に達すると、ターゲットチェーンに関する証拠を提供します。バリデーターは通常、一定量のトークンをステークする必要がありますが、悪意のあるアクティビティが検出された場合はトークンが削減される可能性があります。この実装方法を使用するプロトコルの例には、Axelar Network や Celer IM などがあります。
別の実装方法には、オフチェーン プロキシの使用が含まれます。オフチェーン プロキシは、オプティミスティック ロールアップなどのソリューションを実装するために使用されます。事前に定義された時間枠内で、これらのオフチェーンエージェントは詐欺の証拠を提出し、必要に応じて取引を取り消すことができます。たとえば、Nomad は独立したオフチェーン プロキシを利用してヘッダーと暗号証明を中継します。一方、ChainLink CCIPは、既存のオラクルネットワークを活用してクロスチェーントランザクションを監視および認証することを計画しています。
利点と課題
ゲーム理論 AMP の主な利点はリソースの最適化です。通常、検証プロセスはオンチェーンで行われないため、リソース要件が軽減されます。さらに、コンセンサスメカニズムはさまざまなタイプのチェーンに対して不変のままであり、異種ブロックチェーンに簡単に拡張できるため、これらのメカニズムはスケーラブルです。
これらのメカニズムにはいくつかの課題もあります。バリデーターの大多数が共謀すると、信頼の仮定が悪用されて資金が盗まれる可能性があり、二次投票や詐欺の証拠などの対抗手段の使用が必要になります。さらに、楽観的なセキュリティに基づくソリューションでは、ユーザーとアプリケーションがトランザクションの有効性を確保するために不正行為のウィンドウを待つ必要があるため、ファイナリティとライブネスの点で複雑さが生じます。
人間を信頼する
人間の実体を信頼する必要があるソリューションは、大きく 2 つのカテゴリに分類できます。
1. レピュテーションのセキュリティ: これらのソリューションは、複数のエンティティがトランザクションを検証して署名するマルチ署名の実装に依存しています。最小しきい値に達すると、トランザクションは有効とみなされます。ここでの前提は、エンティティの大部分が誠実であり、これらのエンティティの大部分が特定の取引に署名した場合、その取引は有効であるということです。例としては、マルチチェーン (Anycall V6) やワームホールなどがあります。 2022 年初頭のワームホール ハッキングで実証されたように、スマート コントラクトの脆弱性は依然として悪用される可能性があります。
2. 独立性: これらのソリューションは、メッセージング プロセス全体を 2 つの部分に分割し、異なる独立したエンティティに依存して 2​​ つのプロセスを管理します。ここでの前提は、2 つのエンティティが互いに独立しており、共謀できないということです。 LayerZero はその一例です。ブロックヘッダーは分散型オラクルによってオンデマンドで送信でき、トランザクション証明はリレーを通じて送信されます。証明がブロックヘッダーと一致する場合、トランザクションは有効であるとみなされます。一致の証明はコード/数学に依存しますが、参加者はこれらのエンティティが独立したままであることを信頼する必要があります。 LayerZero 上に構築されたアプリケーションは、オラクルとリレーラーを選択する (または独自のオラクル/リレーラーをホストする) ことができ、個々のオラクル/リレーラーが共謀するリスクを制限します。エンドユーザーは、LayerZero、サードパーティ、またはアプリケーション自体がオラクルとリレーラーを独立して実行しており、悪意がないことを信頼する必要があります。
どちらのアプローチでも、参加しているサードパーティ エンティティの評判によって、悪意のある行為をするインセンティブが減少します。これらは通常、バリデーターおよびオラクルのコミュニティ内で尊敬されている存在であり、悪意のある行動をとった場合、評判が低下し、他の事業活動に悪影響が及ぶ可能性があります。
信頼の前提を超えて: AMP ソリューションに関する追加の考慮事項
AMP ソリューションのセキュリティと使いやすさを考えるときは、基本的な仕組みを超えた詳細も考慮する必要があります。これらは時間の経過とともに変化する可能性がある可動部品であるため、全体的な比較には含めていません。
コードの整合性
コーディングエラーを悪用する最近のハッキングは、信頼性の高い監査、バグ報奨金、および多様なクライアント実装の必要性を浮き彫りにしています。すべてのバリデーター (経済的/楽観的/評判的セキュリティーにおける) が同じクライアント (検証に使用されるソフトウェア) を実行すると、単一のコードベースへの依存が増大し、クライアントの多様性が減少します。たとえば、イーサリアムは、geth、nethermind、erigon、besu、akula などの複数の実行クライアントに依存しています。複数の言語で複数の実装を行うと、クライアントがネットワークを支配することなく多様性が高まるため、潜在的な単一障害点が排除されます。複数のクライアントを持つことも活性化に役立ちます。特定の実装の脆弱性/攻撃により少数のバリデーター/署名者/ライト クライアントがシャットダウンされた場合でも、他のクライアントは引き続き使用できます。
セットアップとアップグレード可能性
ユーザーと開発者は、バリデータ/オブザーバーが許可のない方法でネットワークに参加できるかどうかを理解する必要があります。そうしないと、選択した許可されたエンティティによって信頼が隠蔽されてしまいます。スマート コントラクトへのアップグレードにより、攻撃につながるバグが導入されたり、信頼の前提が変更されたりする可能性もあります。これらのリスクを軽減するために、さまざまなソリューションを実装できます。たとえば、現在のインスタンス化では、Axelar ゲートウェイはオフライン委員会の承認 (4/8 しきい値) に基づいてアップグレードできますが、近い将来、Axelar はゲートウェイへのアップグレードをすべてのバリデーターが集合的に承認することを要求する予定です。 Wormhole のコア コントラクトはアップグレード可能で、Wormhole のオンチェーン ガバナンス システムを通じて管理されます。 LayerZero は、アップグレードを回避するために不変のスマート コントラクトと不変のライブラリに依存していますが、新しいライブラリをロールアウトすることができ、デフォルト設定を使用している dApp は更新されたバージョンを取得し、手動でバージョンが設定されている dApp は新しいバージョンに設定する必要があります。
最大抽出可能値(MEV)
異なるブロックチェーンは共通のクロックによって同期され、ファイナリティ時間が異なります。したがって、ターゲット チェーンでの実行の順序とタイミングはチェーンごとに異なる場合があります。クロスチェーンの世界では、MEV を明確に定義するのは困難です。これにより、生存性と実行順序の間にトレードオフが導入されます。順序付けされたチャネルでは、メッセージの順序付けされた配信が保証されますが、メッセージがタイムアウトになると、チャネルは閉じられます。別のアプリケーションでは、他のメッセージの配信に影響を与えずに、並べ替えを必要としない場合があります。
ソースチェーンのファイナリティ
理想的には、AMP ソリューションは、ソース チェーンがファイナリティに達するまで待ってから、ソース チェーンから 1 つ以上のターゲット チェーンに状態情報を送信する必要があります。これにより、ソース チェーン上のブロックを元に戻したり変更したりすることがほぼ不可能になります。ただし、最高のユーザー エクスペリエンスを提供するために、多くのソリューションはインスタント メッセージングを提供し、ファイナリティ関連の信頼を前提としています。この場合、資金のメッセージングとブリッジング後にソース チェーンが状態のロールバックを受けると、資金が二重に使用される状況が発生する可能性があります。 AMP ソリューションは、チェーンごとに異なるファイナリティの仮定を使用したり、チェーンの分散度に基づいて速度とセキュリティをトレードオフしたりするなど、さまざまな方法でこのリスクを管理できます。 AMP ソリューションを活用したブリッジングでは、ソース チェーンがファイナリティに達する前にブリッジできるアセットの数に制限が設けられます。
動向と今後の見通し
カスタマイズ可能で追加可能なセキュリティ
さまざまなユースケースに適切に対応するために、AMP ソリューションは開発の柔軟性を高めるよう奨励されています。 Axelar は、アプリケーション層のロジックを変更せずにメッセージングと検証をアップグレードできる方法を導入します。 HyperLane V2 には、開発者が経済的セキュリティ、楽観的セキュリティ、動的セキュリティ、ハイブリッド セキュリティなどの複数のオプションから選択できるモジュールが導入されています。 CelerIM は、財務上のセキュリティに加えて、さらなる楽観的なセキュリティを提供します。多くのソリューションは、メッセージを送信する前に、ソース チェーン上で事前定義された最小数のブロック確認を待機します。 LayerZero を使用すると、開発者はこれらのパラメータを更新できます。一部の AMP ソリューションは今後もさらなる柔軟性を提供すると予想されますが、これらの設計の選択についてはある程度の議論が必要です。アプリケーションはセキュリティを構成できますか? どの程度まで構成できますか? アプリケーションが次善の設計で設計されている場合はどうなりますか?セキュリティの背後にある基本概念をユーザーが認識することは、今後ますます重要になるでしょう。最終的には、おそらく何らかの組み合わせまたは「追加」セキュリティの形で、AMP ソリューションの集約と抽象化が行われると予想しています。
「コードと数学を信頼する」メカニズムの成熟度
理想的な最終目標では、ゼロ知識証明の使用により、すべてのクロスチェーン メッセージの信頼性が最小化されます。 Polymer Labs や Succinct Labs などのプロジェクトで、この変化がすでに起こっているのを目の当たりにしています。 Multichain は、ZK プルーフによる相互運用性を可能にする zkRouter というホワイト ペーパーも発行しました。最近発表された Axelar Virtual Machine を使用すると、開発者は Interchain Amplifier を利用して、許可なく Axelar ネットワークへの新しい接続を確立できます。たとえば、強力なライト クライアントとイーサリアム状態の ZK プルーフが開発されると、開発者はそれらを Axelar ネットワークに簡単に統合して、既存の接続を置き換えたり強化したりできます。 Celer Networkは、dAppsとスマートコントラクトが複数のブロックチェーン上の任意のデータにアクセス、計算、利用できるようにするBrevisと呼ばれるZKクロスチェーンデータ証明プラットフォームを発表しました。 Celer は、ZK ライト クライアント回路を利用して、イーサリアム Goerli と BNB チェーン テストネットをブリッジするユーザーに表示される資産である zkBridge を実装します。 LayerZero はドキュメントの中で、将来的に新しい最適化耐性のあるメッセージング ライブラリを追加する可能性について述べています。 Lagrange のような新しいプロジェクトは、複数のソース チェーンから複数の証明を集約する可能性を模索しており、Herodotus は ZK 証明を使用してストレージ証明を可能にしています。ただし、このアプローチは、異なるコンセンサスメカニズムやフレームワークに依存するブロックチェーン間で拡張することが難しいため、この移行には時間がかかります。
ZK は比較的新しく複雑なテクノロジーであり、監査が困難であり、現在の検証と証明生成のコストは最適とは言えません。私たちは、長期的には、ブロックチェーン上で拡張性の高いクロスチェーン アプリケーションをサポートするために、次の理由から、多くの AMP ソリューションが信頼できる人間のエンティティと検証可能なソフトウェアを組み合わせると考えています。
1. 監査とバグ報奨金を通じて、コード悪用の可能性を最小限に抑えることができます。時間が経つにつれて、履歴が安全性の証拠となるため、これらのシステムを信頼することが容易になります。
2. ZK プルーフを生成するコストが削減されます。 ZKP、再帰的 ZK、プルーフ集約、フォールディング スキーム、および特殊なハードウェアの研究開発がさらに進むことで、プルーフの生成と検証にかかる時間とコストが大幅に削減され、よりコスト効率の高いアプローチになることが期待されます。
3. ブロックチェーンは ZK にとってよりフレンドリーになります。将来的には、zkEVM は実行の妥当性の簡潔な証明を提供できるようになり、軽量クライアントベースのソリューションはソースチェーンの実行とコンセンサスを簡単に検証できるようになります。イーサリアムの最終段階では、コンセンサスも含めて「すべてをzk-SNARKに変換する」計画もある。
人間性、評判、アイデンティティ
AMP ソリューションのような複雑なシステムのセキュリティは、単一のフレームワークだけではカプセル化できず、多層のソリューションが必要です。たとえば、Axelar は金銭的インセンティブに加えて、投票権がノードのサブセットに集中するのを防ぎ、分散化を促進するための二次投票メカニズムを実装しています。人間性、評判、アイデンティティの他の証明も、セットアップと許可のメカニズムを補完することができます。
結論は
Web3 のオープンな精神に基づいて、複数のアプローチが共存する未来が訪れるかもしれません。実際には、アプリケーションは、冗長的な方法で、またはユーザーがトレードオフに基づいて組み合わせて使用​​できるように、複数の相互運用性ソリューションを使用することを選択できます。ポイントツーポイント ソリューションは「トラフィックの多い」ルート間で優先される可能性が高く、ハブ アンド スポーク モデルはチェーンのロングテールで優勢になる可能性があります。最終的に、接続された Web3 のランドスケープを形成するのは、ユーザー、構築者、および貢献者のコミュニティとしての私たちにかかっています。
参考文献
https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702 
https://polymerlabs.medium.com/the-multi-hop-ibc-upgrade-will-take-ibc-to-ethereum-and-beyond-b4bee43523e 
https://cointelegraph.com/news/wormhole-hack-illustrates-danger-of-defi-cross-chain-bridges 
https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps 
https://ethresear.ch/t/bashi-a-principled-approach-to-bridges/14725 
https://twitter.com/MultichainOrg/status/1613830754458533888?s=20&t=MoDGESqOdcjMQDMFQqzTyQ
https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability 
https://twitter.com/CelerNetwork/status/1638330932603109379?s=20
https://axelar.network/blog/axelar-implements-quadratic-voting-with-maeve-upgrade  