原作者: Shi Khai Wei、Raghav Agarwal
オリジナルコンピレーション: Kxp、BlockBeats
＃＃＃ 序章
マルチチェーンは今後の開発トレンドであり、スケーラビリティの追求によりイーサリアムはロールアップ技術の構築に至りました。モジュラーブロックチェーンへの移行において、Liskに再び注目が集まっています。そして、そう遠くない将来、アプリケーション固有のロールアップ、L3、ソブリン チェーンに関する噂を耳にします。しかし、これにはすべて断片化という代償が伴い、現在のクロスチェーンブリッジは多くの場合機能が制限されており、セキュリティを信頼できる署名者に依存しています。
では、接続された Web3 は最終的にどのようなものになるのでしょうか?私たちは、クロスチェーン ブリッジが最終的にはクロスチェーン メッセージングまたは「任意メッセージング」(AMP) プロトコルに進化して、新しいアプリケーション シナリオを解き放ち、アプリケーションがソース チェーンとターゲット チェーンの間で任意のメッセージを受け渡すことができるようになると考えています。また、構築者が使いやすさ、複雑さ、セキュリティの間でさまざまなトレードオフを行う「信頼メカニズムのランドスケープ」の出現も目撃するでしょう。
すべての AMP ソリューションでは、次の 2 つの主要な機能を実装する必要があります。
残念ながら、100% トラストレス検証は現実的ではありません。ユーザーは、検証がオンチェーンかオフチェーンかに応じて、コード、ゲーム理論、人間 (またはエンティティ)、またはこれらの組み合わせを信頼することを選択する必要があります。
このペーパーでは、相互運用性ドメイン全体を信頼ベースのメカニズムと統合ベースのアーキテクチャに垂直に分割します。
信頼メカニズム:
コードと数学を信頼する: これらのソリューションには、誰でも検証できるオンチェーンの証明があります。これらのソリューションは通常、ライト クライアントに依存して、ターゲット チェーン上のソース チェーンのコンセンサスを検証したり、ターゲット チェーン上のソース チェーンの状態遷移の妥当性を検証したりします。ライトクライアントを介した検証は、ゼロ知識証明を通じて効率を向上させ、オフラインで実行される任意の長さの計算を圧縮すると同時に、計算結果を証明するためのシンプルなオンチェーン検証を提供します。
信頼ゲーム理論: ユーザー/アプリケーションがトランザクションの信頼性を保証するためにサードパーティまたはサードパーティのネットワークを信頼する必要がある場合、追加の信頼仮定が関係します。これらのメカニズムのセキュリティは、許可のないネットワークと、経済的インセンティブや楽観的セキュリティなどのゲーム理論を採用することで向上できます。
人間への信頼: これらのソリューションは、さまざまな情報を伝達する大多数のバリデーターの誠実さまたは独立性に依存しています。 2 つのインタラクティブ チェーンのコンセンサスを信頼することに加えて、サードパーティも信頼する必要があります。この場合、唯一のリスクは参加企業の評判です。十分な数の参加エンティティがトランザクションが有効であることに同意した場合、トランザクションは有効であるとみなされます。
すべてのソリューションにはコードと人間に対するある程度の信頼が必要であることに注意してください。バグのあるコードを含むソリューションはすべてハッカーによって悪用される可能性があり、すべてのソリューションにはコードベースのセットアップ、アップグレード、またはメンテナンスに人的要素が含まれています。
統合アーキテクチャ:
ポイントツーポイント モデル: 各ソース チェーンとターゲット チェーンの間に専用の通信チャネルを確立する必要があります。
中央ハブ モデル: ハブに接続されている他のすべてのブロックチェーンとの相互接続を実現するには、中央ハブとの通信チャネルを確立する必要があります。
接続された各ブロックチェーンにはペアになった通信チャネルが必要なため、ピアツーピア モデルの拡張は比較的困難です。コンセンサスやフレームワークが異なるブロックチェーンにとって、これらのチャネルの開発は困難な場合があります。ただし、ブリッジをペアにすると、必要に応じて構成をより柔軟にカスタマイズできます。ブロックチェーン間通信 (IBC) プロトコルを使用したリレーを介したマルチホップ ルーティングなどのハイブリッド アプローチも可能です。これにより、直接ピアツーピア通信の必要性がなくなりますが、セキュリティ、遅延、およびセキュリティの点でより複雑になります。料金。
信頼の仮定をコード/数学のみに依存するために、ライト クライアントを使用してターゲット チェーン上のソース チェーンのコンセンサスを検証できます。ライト クライアント/ノードは、フル ノードに接続してブロックチェーンと対話するソフトウェアです。ターゲット チェーン上のライト クライアントは通常、ソース チェーンのブロック ヘッダーの履歴を (順番に) 保存します。これはトランザクションを検証するのに十分です。オフチェーン プロキシ (リレーなど) は、ソース チェーン上のイベントを監視し、暗号化された包含証明を生成し、それらをブロック ヘッダーとともにターゲット チェーン上のライト クライアントに転送します。ライト クライアントはブロック ヘッダーを順番に保存し、それぞれに状態の証明に使用できるマークル ルート ハッシュが含まれるため、トランザクションを検証できます。このアプローチの主な機能の概要は次のとおりです。
安全性
信頼の仮定は、ライト クライアントの初期化中に導入されます。新しいライト クライアントを作成すると、他のチェーンの特定の高さのブロック ヘッダーに初期化されます。ただし、提供されたブロック ヘッダーが正しくない可能性があり、偽造されたブロック ヘッダーを使用してライト クライアントをだます可能性があります。ライトクライアントが初期化されると、それ以上の信頼仮定は導入されません。ただし、この初期化プロセスは誰でも検証できるため、弱い信頼の仮定に依存していることに注意してください。さらに、リレーによる情報の継続的な送信には、活性の仮定があります。
埋め込む
ライト クライアントの実装は、認証に必要な暗号化プリミティブが利用できるかどうかに依存します。同じタイプのチェーンが接続されている場合、つまり同じアプリケーション フレームワークとコンセンサス アルゴリズムを共有している場合、両端のライト クライアント実装は同じになります。たとえば、すべての Cosmos SDK ベースのチェーンはブロックチェーン間通信 (IBC) プロトコルを使用します。一方、ライト クライアントなどの実装は、認証に必要な暗号化プリミティブのサポートに依存します。同じタイプのチェーンが接続されている場合、つまり、同じアプリケーション フレームワークとコンセンサス アルゴリズムを共有している場合、両側のライト クライアント実装は同じになります。たとえば、ブロックチェーン間通信 (IBC) プロトコルは、すべての Cosmos SDK ベースのチェーンに使用されます。一方、異なるアプリケーション フレームワークやコンセンサス タイプなど、2 つの異なるタイプのチェーンが接続されている場合、ライト クライアントの実装は異なります。例としては、Cosmos SDK チェーンを IBC 経由で Polkadot エコシステムの Substrate アプリケーション フレームワークに接続することに取り組んでいる Composable Finance があります。これには、Substrate チェーン上に Tendermint ライト クライアントが必要で、Cosmos SDK チェーン上に「beefy」ライト クライアントが必要です。最近、彼らはIBCを介してPolkadotとKusamaの間の最初の接続を確立しました。
チャレンジ
資源の集約度は重要な課題です。ブロックチェーンへの書き込みにはコストがかかるため、すべてのチェーンでライト クライアントのペアを実行するとコストがかかる可能性があります。さらに、動的検証機能によるリソースの集中性も重要な課題です。ブロックチェーンへの書き込みにはコストがかかるため、ペアになったライト クライアントをすべてのチェーンで実行するとコストがかかる可能性があります。また、動的バリデータ セット (イーサリアムなど) を備えたチェーンの場合、軽量クライアントを実行することは現実的ではありません。
スケーラビリティもまた課題です。ライト クライアントの実装はチェーンのアーキテクチャによって異なるため、異なるエコシステムを拡張したり接続したりすることが困難になります。
コードのバグは脆弱性を引き起こす可能性があるため、コードの脆弱性は潜在的なリスクです。たとえば、2022 年 10 月の BNB チェーン侵害では、すべての IBC 対応チェーンに影響を与える重大なセキュリティ上の欠陥が明らかになりました。
すべてのチェーンでペアワイズ ライト クライアントを実行するコストと実用性に対処するには、ゼロ知識 (ZK) 証明などの代替ソリューションを採用して、サードパーティの信頼の必要性を取り除くことができます。
第三者の信頼のためのソリューションとしてのゼロ知識証明
ゼロ知識証明は、ターゲット チェーン上のソース チェーンの状態遷移の妥当性を検証するために使用できます。計算全体をオンチェーンで実行するのと比較して、ZK 証明は計算の検証部分のみをオンチェーンで実行し、実際の計算はオフチェーンで行われます。このアプローチにより、元の計算を再実行するよりも高速かつ効率的な検証が可能になります。例としては、Polymer Labs の Polymer ZK-IBC、Succinct Labs の Telepathy などが挙げられます。 Polymer は、接続性を強化し、必要なペア接続の数を減らすためにマルチホップ IBC を開発しています。
メカニズムの重要な側面は次のとおりです。
zk-SNARK のセキュリティは楕円曲線に依存しますが、zk-STARK はハッシュ関数に依存します。 zk-SNARK では、検証に使用される証明を生成するために使用される初期キーの作成など、信頼できるセットアップが必要な場合があります。重要なのは、トランザクションが偽造によって認証されるのを防ぐために、セットアップ イベントの秘密を破棄することです。信頼できるセットアップが完了すると、それ以上の信頼の仮定は導入されません。さらに、新しい ZK フレームワーク (Halo や Halo;2; など) では、信頼できるセットアップの必要性が完全になくなりました。
ZK 証明スキームには SNARK、STARK、VPD、SNARG などのさまざまなスキームがあり、現在 SNARK が最も広く使用されています。 Groth;16、Plonk、Marlin、Halo、Halo;2; などのさまざまな SNARK 証明フレームワークには、証明サイズ、証明時間、検証時間、メモリ要件、および信頼できるセットアップ要件の点でトレードオフがあります。再帰的 ZK 証明も登場し、証明ワークロードを 1 台のコンピュータではなく複数のコンピュータに分散できるようになりました。有効性の証明を生成するには、次のコアプリミティブを実装する必要があります: バリデーターによって使用される署名スキームの検証、オンチェーンに保存されているバリデーターセットコミットメントにバリデーターの公開鍵の証明を保管、およびバリデーターセットの追跡。頻繁に変更します。
zkSNARKs でさまざまな署名スキームを実装するには、ドメイン外の算術演算と複雑な楕円曲線演算の実装が必要ですが、これは簡単ではなく、フレームワークやさまざまなチェーンのコンセンサスに応じて異なる実装が必要になる場合があります。 ZK 回路の監査は困難であり、エラーが発生しやすい作業です。開発者は、Circom、Cairo、Noir などのドメイン固有言語に精通するか、回路を直接実装する必要がありますが、どちらも困難な場合があり、導入が遅れる可能性があります。時間と労力が非常にかかることが判明した場合、専用のチームと専用のハードウェアのみが対応することになり、集中化につながる可能性があります。校正刷りの生成時間が長くなると遅延も発生します。 Incrementally Verifiable Computation (IVC) などの技術は証明時間を最適化できますが、その多くはまだ研究段階にあり、実装を待っています。検証時間と作業負荷が長くなると、オンチェーンのコストが増加します。
ゲーム理論に基づく相互運用性プロトコルは、参加エンティティによる誠実な行動をどのように奨励するかに応じて、大きく 2 つのカテゴリに分類できます。
最初のカテゴリは、複数の外部アクター (バリデーターなど) が協力して、ソース チェーンの更新された状態を決定するための合意に達する経済的セキュリティ メカニズムです。バリデーターになるためには、参加者は一定量のトークンをステークする必要がありますが、悪意のある活動が発生した場合にはトークンが減らされる可能性があります。パーミッションレス設定では、誰でもステークを蓄積してバリデーターになることができます。さらに、ブロック報酬などの経済的インセンティブは、誠実な行動に対する経済的インセンティブを確保するために、プロトコルに従うバリデーターに提供されます。ただし、盗まれる可能性のある金額が賭け金を超える場合、参加者は共謀して資金を盗む可能性があります。経済的なセキュリティ メカニズムを使用するプロトコルの例には、Axelar および Celer IM などがあります。
2 番目のカテゴリは楽観的なセキュリティ メカニズムであり、このソリューションは、少数のブロックチェーン参加者だけが正直でプロトコルのルールに従っているという前提に基づいています。このアプローチでは、誠実な参加者が保証の役割を果たします。たとえば、最適なソリューションでは、誰でも不正行為の証拠を提出できます。金銭的なインセンティブはありますが、誠実に観察していれば不正な取引を見逃す可能性があります。オプティミスティックロールアップもこのメカニズムを使用します。 Nomad および ChainLink CCIP は、オプティミスティック セキュリティ メカニズムを使用するプロトコルの例です。 Nomad の場合、この記事の執筆時点ではホワイトリストに登録されていますが、観察者は詐欺を証明することができました。 ChainLink CCIPは、オラクルの分散ネットワークで構成される不正行為防止ネットワークを利用して悪意のあるアクティビティを検出する計画ですが、CCIPの不正行為防止ネットワークの実装は不明です。
セキュリティの観点から見ると、どちらのメカニズムも、ゲーム理論上の妥当性を確保するために、検証者とオブザーバーの許可のない参加に依存しています。経済安全メカニズムでは、賭け金が盗まれる可能性のある金額よりも低い場合、資金はより脆弱になります。一方、楽観的なセキュリティ メカニズムでは、誰も不正行為の証拠を提出しなかったり、権限監視者が危険にさらされたり削除されたりした場合に、少数派の信頼が悪用される可能性があります。対照的に、経済安全保障メカニズムは、安全保障を維持するために活力にあまり依存しません。
実装に関しては、1 つのアプローチには、独自のバリデーターを備えた中間チェーンが含まれます。この設定では、外部バリデータのグループがソース チェーンを監視し、呼び出しが検出されたときにトランザクションの有効性について合意に達します。合意に達すると、ターゲット チェーン上で証拠を提供します。バリデーターは通常、一定量のトークンをステークする必要がありますが、悪意のあるアクティビティが検出された場合はトークンが減らされる可能性があります。この実装方法を使用するプロトコルの例には、Axelar Network や Celer IM などがあります。
別の実装方法には、オフチェーン プロキシの使用が含まれます。オフチェーン プロキシは、楽観的なロールアップのようなソリューションを実装するために使用されます。事前に定義された時間枠内で、これらのオフチェーン プロキシは不正行為の証拠を提出し、必要に応じてトランザクションを取り消すことができます。たとえば、Nomad は独立したオフチェーン プロキシを利用してヘッダーと暗号証明を中継します。一方、ChainLink CCIPは、既存のオラクルネットワークを活用して、クロスチェーントランザクションを監視および証明することを計画しています。
強みと課題
ゲーム理論に基づいた AMP ソリューションの主な利点は、検証プロセスが通常オフチェーンで行われるため、リソースの最適化であり、リソース要件が軽減されます。さらに、コンセンサスメカニズムがさまざまなタイプのチェーンで同じままであるため、これらのメカニズムは拡張可能であり、異種ブロックチェーンに簡単に拡張できます。
これらのメカニズムに関連するいくつかの課題もあります。バリデーターの大多数が共謀すると、信頼の仮定が悪用されて資金が盗まれる可能性があり、二次投票や不正行為の証明などの対策が必要になります。さらに、楽観的セキュリティに基づくソリューションでは、ユーザーとアプリケーションがトランザクションの正当性を確保するために不正なウィンドウを待つ必要があるため、ファイナリティとライブネスの点で複雑さが生じます。
人間の実体への信頼を必要とするソリューションは、大きく 2 つのカテゴリに分類できます。
評判のセキュリティ: これらのソリューションは、複数のエンティティがトランザクションを検証して署名するマルチ署名の実装に依存しています。最小しきい値に達すると、トランザクションは有効とみなされます。ここでの前提は、ほとんどのエンティティが誠実であり、これらのエンティティの大多数が特定の取引に署名した場合、その取引は有効であるということです。ここでリスクにさらされるのは、関与する組織の評判だけです。例としては、マルチチェーン (Anycall V;6;) やワームホールなどがあります。 2022 年初頭のワームホール ハッキングで実証されたように、スマート コントラクトの脆弱性により脆弱性が依然として存在する可能性があります。
独立性: これらのソリューションは、メッセージング プロセス全体を 2 つの部分に分割し、異なる独立したエンティティに依存して 2 つのプロセスを管理します。ここでの前提は、これら 2 つのエンティティが互いに独立しており、共謀できないということです。 LayerZero はその一例です。ブロックヘッダーは分散オラクルを通じてオンデマンドで送信され、トランザクション証明はリレーラーを通じて送信されます。証明がヘッダーと一致する場合、トランザクションは有効であるとみなされます。一致の証明はコード/数学に依存しますが、参加者は、これらのエンティティが独立したままであり、悪意がないことを信頼する必要があります。 ;LayerZero; 上に構築されたアプリケーションは、オラクルとリレーを選択する (または独自のオラクル/リレーをホストする) ことができるため、個々のオラクル/リレーへのリスクを制限できます。エンドユーザーは、LayerZero、サードパーティ、またはアプリケーション自体が悪意なくオラクルとリレーを独立して実行していることを信頼する必要があります。
どちらのアプローチでも、参加しているサードパーティ エンティティの評判によって悪意のある行為が阻止されます。これらは通常、バリデーターやオラクルのコミュニティで尊敬されているエンティティであり、悪意のある行動をとった場合、風評被害や他の事業活動に悪影響を与えるリスクがあります。
AMP ソリューションのセキュリティと使いやすさを考えるときは、基本的な仕組みを超えた詳細も考慮する必要があります。これらは時間の経過とともに変化する可能性のあるコンポーネントであるため、全体的な比較には含めていません。
コードの整合性
最近のハッキングではコード エラーが悪用されており、堅牢な監査、バグ報奨金、および多様なクライアント実装の必要性が浮き彫りになっています。すべての検証者 (経済的/楽観的/評判的セキュリティ) が同じクライアント (検証用ソフトウェア) を実行すると、単一のコードベースへの依存度が高まり、クライアントの多様性が減少します。たとえば、イーサリアムは、geth、netermind、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 ソリューションの集約と抽象化が行われると予想しています。
「信頼コードと数学」メカニズムの成熟度
理想的な最終段階では、すべてのクロスチェーン メッセージは、ゼロ知識 (ZK) 証明の使用によって信頼が最小化されます。 Polymer Labs や Succinct Labs などの同様のプロジェクトが出現するのを見てきました。 Multichain は、ZK プルーフによる相互運用性に関する zkRouter ホワイト ペーパーも発行しました。最近発表された Axelar Virtual Machine を使用すると、開発者は Interchain Amplifier を利用して、許可なく Axelar ネットワークへの新しい接続を確立できます。たとえば、イーサリアムの状態に合わせて強力なライト クライアントと ZK プルーフが開発されると、開発者はそれらを Axelar ネットワークに簡単に統合して、既存の接続を置き換えたり強化したりできます。 Celer Networkは、dAppsとスマートコントラクトが複数のブロックチェーン上の任意のデータにアクセス、計算、利用できるようにするZKクロスチェーンデータ証明プラットフォームであるBrevisを発表しました。 Celer は、Ethereum Goerli テストネットと BNB Chain テストネット間のクロスチェーンに ZK ライト クライアント回路を使用してユーザー指向のアセット zkBridge を実装しました。 LayerZero は、ドキュメントの中で、将来的に新しい最適化されたプルーフ メッセージ ライブラリを追加する可能性について説明しています。 Lagrange のような新しいプロジェクトは、複数のソース チェーンから複数の証明を集約することを検討していますが、Herodotus は ZK 証明を使用して証明を保存できるようにしています。ただし、このアプローチは、さまざまなコンセンサスメカニズムやフレームワークに依存するブロックチェーン全体に拡張することが難しいため、この移行には時間がかかります。
ZK は比較的新しく複雑なテクノロジーであり、監査が困難であり、現在の検証と証明の生成コストは最適ではありません。私たちは、長期的には、ブロックチェーン上で拡張性の高いクロスチェーン アプリケーションをサポートするために、多くの AMP ソリューションが検証可能なソフトウェアと信頼できる人間やエンティティを組み合わせると考えています。その理由は次のとおりです。
監査とバグ報奨金を通じて、コード悪用の可能性を最小限に抑えることができます。時間が経つにつれて、その履歴が安全性の証拠となるため、これらのシステムを信頼することが容易になります。
ZK プルーフを生成するコストが削減されます。 ZKP、再帰的 ZKP、プルーフ集約、フォールディング スキーム、および特殊なハードウェアに関する研究開発がさらに進むことで、プルーフの生成と検証にかかる時間コストが大幅に削減され、よりコスト効率の高いアプローチになることが期待されます。
ブロックチェーンは ZK をよりサポートするようになります。将来的には、zkEVM は実行の妥当性の簡潔な証明を提供できるようになり、軽量クライアントベースのソリューションはソースチェーンの実行とコンセンサスを簡単に検証できるようになります。イーサリアムの最終段階では、コンセンサスメカニズムを含めた「すべてをzk-SNARK」することも計画されています。
人間の資格、評判、アイデンティティ
AMP ソリューションのような複雑なシステムのセキュリティは、単一のフレームワークだけではカプセル化できず、多層のソリューションが必要です。たとえば、Axelar は経済的インセンティブに加えて、ノードのサブセット間での投票権の集中を防ぎ、分散化を促進するために二次投票メカニズムを実装しています。他の人間の証明、評判、アイデンティティもセットアップと許可のメカニズムを補完することができます。
＃＃＃ 結論は
Web3 のオープンな精神により、複数のアプローチが共存する多元的な未来が訪れるかもしれません。実際、アプリケーションは、冗長的な方法で、またはユーザーがトレードオフに基づいて組み合わせを選択して、複数の相互運用性ソリューションを使用することを選択できます。 「トラフィックの多い」ルート間では、ポイントツーポイント ソリューションが優先される一方で、ハブアンドスポーク モデルがチェーンのロングテールを支配する可能性があります。最終的には、ユーザー、構築者、貢献者のコミュニティとして、Web3 インターネットの基本的な形を形作ることになります。
元のリンク
222k 投稿
186k 投稿
141k 投稿
79k 投稿
66k 投稿
62k 投稿
60k 投稿
57k 投稿
52k 投稿
51k 投稿
任意のメッセージング プロトコルを徹底的に解釈すると、相互運用性の信頼の問題はどのように解決されるのでしょうか?
原作者: Shi Khai Wei、Raghav Agarwal
オリジナルコンピレーション: Kxp、BlockBeats
＃＃＃ 序章
マルチチェーンは今後の開発トレンドであり、スケーラビリティの追求によりイーサリアムはロールアップ技術の構築に至りました。モジュラーブロックチェーンへの移行において、Liskに再び注目が集まっています。そして、そう遠くない将来、アプリケーション固有のロールアップ、L3、ソブリン チェーンに関する噂を耳にします。しかし、これにはすべて断片化という代償が伴い、現在のクロスチェーンブリッジは多くの場合機能が制限されており、セキュリティを信頼できる署名者に依存しています。
では、接続された Web3 は最終的にどのようなものになるのでしょうか?私たちは、クロスチェーン ブリッジが最終的にはクロスチェーン メッセージングまたは「任意メッセージング」(AMP) プロトコルに進化して、新しいアプリケーション シナリオを解き放ち、アプリケーションがソース チェーンとターゲット チェーンの間で任意のメッセージを受け渡すことができるようになると考えています。また、構築者が使いやすさ、複雑さ、セキュリティの間でさまざまなトレードオフを行う「信頼メカニズムのランドスケープ」の出現も目撃するでしょう。
すべての AMP ソリューションでは、次の 2 つの主要な機能を実装する必要があります。
残念ながら、100% トラストレス検証は現実的ではありません。ユーザーは、検証がオンチェーンかオフチェーンかに応じて、コード、ゲーム理論、人間 (またはエンティティ)、またはこれらの組み合わせを信頼することを選択する必要があります。
このペーパーでは、相互運用性ドメイン全体を信頼ベースのメカニズムと統合ベースのアーキテクチャに垂直に分割します。
信頼メカニズム:
コードと数学を信頼する: これらのソリューションには、誰でも検証できるオンチェーンの証明があります。これらのソリューションは通常、ライト クライアントに依存して、ターゲット チェーン上のソース チェーンのコンセンサスを検証したり、ターゲット チェーン上のソース チェーンの状態遷移の妥当性を検証したりします。ライトクライアントを介した検証は、ゼロ知識証明を通じて効率を向上させ、オフラインで実行される任意の長さの計算を圧縮すると同時に、計算結果を証明するためのシンプルなオンチェーン検証を提供します。
信頼ゲーム理論: ユーザー/アプリケーションがトランザクションの信頼性を保証するためにサードパーティまたはサードパーティのネットワークを信頼する必要がある場合、追加の信頼仮定が関係します。これらのメカニズムのセキュリティは、許可のないネットワークと、経済的インセンティブや楽観的セキュリティなどのゲーム理論を採用することで向上できます。
人間への信頼: これらのソリューションは、さまざまな情報を伝達する大多数のバリデーターの誠実さまたは独立性に依存しています。 2 つのインタラクティブ チェーンのコンセンサスを信頼することに加えて、サードパーティも信頼する必要があります。この場合、唯一のリスクは参加企業の評判です。十分な数の参加エンティティがトランザクションが有効であることに同意した場合、トランザクションは有効であるとみなされます。
すべてのソリューションにはコードと人間に対するある程度の信頼が必要であることに注意してください。バグのあるコードを含むソリューションはすべてハッカーによって悪用される可能性があり、すべてのソリューションにはコードベースのセットアップ、アップグレード、またはメンテナンスに人的要素が含まれています。
統合アーキテクチャ:
ポイントツーポイント モデル: 各ソース チェーンとターゲット チェーンの間に専用の通信チャネルを確立する必要があります。
中央ハブ モデル: ハブに接続されている他のすべてのブロックチェーンとの相互接続を実現するには、中央ハブとの通信チャネルを確立する必要があります。
接続された各ブロックチェーンにはペアになった通信チャネルが必要なため、ピアツーピア モデルの拡張は比較的困難です。コンセンサスやフレームワークが異なるブロックチェーンにとって、これらのチャネルの開発は困難な場合があります。ただし、ブリッジをペアにすると、必要に応じて構成をより柔軟にカスタマイズできます。ブロックチェーン間通信 (IBC) プロトコルを使用したリレーを介したマルチホップ ルーティングなどのハイブリッド アプローチも可能です。これにより、直接ピアツーピア通信の必要性がなくなりますが、セキュリティ、遅延、およびセキュリティの点でより複雑になります。料金。
トラストコードと数学
信頼の仮定をコード/数学のみに依存するために、ライト クライアントを使用してターゲット チェーン上のソース チェーンのコンセンサスを検証できます。ライト クライアント/ノードは、フル ノードに接続してブロックチェーンと対話するソフトウェアです。ターゲット チェーン上のライト クライアントは通常、ソース チェーンのブロック ヘッダーの履歴を (順番に) 保存します。これはトランザクションを検証するのに十分です。オフチェーン プロキシ (リレーなど) は、ソース チェーン上のイベントを監視し、暗号化された包含証明を生成し、それらをブロック ヘッダーとともにターゲット チェーン上のライト クライアントに転送します。ライト クライアントはブロック ヘッダーを順番に保存し、それぞれに状態の証明に使用できるマークル ルート ハッシュが含まれるため、トランザクションを検証できます。このアプローチの主な機能の概要は次のとおりです。
安全性
信頼の仮定は、ライト クライアントの初期化中に導入されます。新しいライト クライアントを作成すると、他のチェーンの特定の高さのブロック ヘッダーに初期化されます。ただし、提供されたブロック ヘッダーが正しくない可能性があり、偽造されたブロック ヘッダーを使用してライト クライアントをだます可能性があります。ライトクライアントが初期化されると、それ以上の信頼仮定は導入されません。ただし、この初期化プロセスは誰でも検証できるため、弱い信頼の仮定に依存していることに注意してください。さらに、リレーによる情報の継続的な送信には、活性の仮定があります。
埋め込む
ライト クライアントの実装は、認証に必要な暗号化プリミティブが利用できるかどうかに依存します。同じタイプのチェーンが接続されている場合、つまり同じアプリケーション フレームワークとコンセンサス アルゴリズムを共有している場合、両端のライト クライアント実装は同じになります。たとえば、すべての Cosmos SDK ベースのチェーンはブロックチェーン間通信 (IBC) プロトコルを使用します。一方、ライト クライアントなどの実装は、認証に必要な暗号化プリミティブのサポートに依存します。同じタイプのチェーンが接続されている場合、つまり、同じアプリケーション フレームワークとコンセンサス アルゴリズムを共有している場合、両側のライト クライアント実装は同じになります。たとえば、ブロックチェーン間通信 (IBC) プロトコルは、すべての Cosmos SDK ベースのチェーンに使用されます。一方、異なるアプリケーション フレームワークやコンセンサス タイプなど、2 つの異なるタイプのチェーンが接続されている場合、ライト クライアントの実装は異なります。例としては、Cosmos SDK チェーンを IBC 経由で Polkadot エコシステムの Substrate アプリケーション フレームワークに接続することに取り組んでいる Composable Finance があります。これには、Substrate チェーン上に Tendermint ライト クライアントが必要で、Cosmos SDK チェーン上に「beefy」ライト クライアントが必要です。最近、彼らはIBCを介してPolkadotとKusamaの間の最初の接続を確立しました。
チャレンジ
資源の集約度は重要な課題です。ブロックチェーンへの書き込みにはコストがかかるため、すべてのチェーンでライト クライアントのペアを実行するとコストがかかる可能性があります。さらに、動的検証機能によるリソースの集中性も重要な課題です。ブロックチェーンへの書き込みにはコストがかかるため、ペアになったライト クライアントをすべてのチェーンで実行するとコストがかかる可能性があります。また、動的バリデータ セット (イーサリアムなど) を備えたチェーンの場合、軽量クライアントを実行することは現実的ではありません。
スケーラビリティもまた課題です。ライト クライアントの実装はチェーンのアーキテクチャによって異なるため、異なるエコシステムを拡張したり接続したりすることが困難になります。
コードのバグは脆弱性を引き起こす可能性があるため、コードの脆弱性は潜在的なリスクです。たとえば、2022 年 10 月の BNB チェーン侵害では、すべての IBC 対応チェーンに影響を与える重大なセキュリティ上の欠陥が明らかになりました。
すべてのチェーンでペアワイズ ライト クライアントを実行するコストと実用性に対処するには、ゼロ知識 (ZK) 証明などの代替ソリューションを採用して、サードパーティの信頼の必要性を取り除くことができます。
第三者の信頼のためのソリューションとしてのゼロ知識証明
ゼロ知識証明は、ターゲット チェーン上のソース チェーンの状態遷移の妥当性を検証するために使用できます。計算全体をオンチェーンで実行するのと比較して、ZK 証明は計算の検証部分のみをオンチェーンで実行し、実際の計算はオフチェーンで行われます。このアプローチにより、元の計算を再実行するよりも高速かつ効率的な検証が可能になります。例としては、Polymer Labs の Polymer ZK-IBC、Succinct Labs の Telepathy などが挙げられます。 Polymer は、接続性を強化し、必要なペア接続の数を減らすためにマルチホップ IBC を開発しています。
メカニズムの重要な側面は次のとおりです。
安全性
zk-SNARK のセキュリティは楕円曲線に依存しますが、zk-STARK はハッシュ関数に依存します。 zk-SNARK では、検証に使用される証明を生成するために使用される初期キーの作成など、信頼できるセットアップが必要な場合があります。重要なのは、トランザクションが偽造によって認証されるのを防ぐために、セットアップ イベントの秘密を破棄することです。信頼できるセットアップが完了すると、それ以上の信頼の仮定は導入されません。さらに、新しい ZK フレームワーク (Halo や Halo;2; など) では、信頼できるセットアップの必要性が完全になくなりました。
埋め込む
ZK 証明スキームには SNARK、STARK、VPD、SNARG などのさまざまなスキームがあり、現在 SNARK が最も広く使用されています。 Groth;16、Plonk、Marlin、Halo、Halo;2; などのさまざまな SNARK 証明フレームワークには、証明サイズ、証明時間、検証時間、メモリ要件、および信頼できるセットアップ要件の点でトレードオフがあります。再帰的 ZK 証明も登場し、証明ワークロードを 1 台のコンピュータではなく複数のコンピュータに分散できるようになりました。有効性の証明を生成するには、次のコアプリミティブを実装する必要があります: バリデーターによって使用される署名スキームの検証、オンチェーンに保存されているバリデーターセットコミットメントにバリデーターの公開鍵の証明を保管、およびバリデーターセットの追跡。頻繁に変更します。
チャレンジ
zkSNARKs でさまざまな署名スキームを実装するには、ドメイン外の算術演算と複雑な楕円曲線演算の実装が必要ですが、これは簡単ではなく、フレームワークやさまざまなチェーンのコンセンサスに応じて異なる実装が必要になる場合があります。 ZK 回路の監査は困難であり、エラーが発生しやすい作業です。開発者は、Circom、Cairo、Noir などのドメイン固有言語に精通するか、回路を直接実装する必要がありますが、どちらも困難な場合があり、導入が遅れる可能性があります。時間と労力が非常にかかることが判明した場合、専用のチームと専用のハードウェアのみが対応することになり、集中化につながる可能性があります。校正刷りの生成時間が長くなると遅延も発生します。 Incrementally Verifiable Computation (IVC) などの技術は証明時間を最適化できますが、その多くはまだ研究段階にあり、実装を待っています。検証時間と作業負荷が長くなると、オンチェーンのコストが増加します。
信頼ゲーム理論
ゲーム理論に基づく相互運用性プロトコルは、参加エンティティによる誠実な行動をどのように奨励するかに応じて、大きく 2 つのカテゴリに分類できます。
最初のカテゴリは、複数の外部アクター (バリデーターなど) が協力して、ソース チェーンの更新された状態を決定するための合意に達する経済的セキュリティ メカニズムです。バリデーターになるためには、参加者は一定量のトークンをステークする必要がありますが、悪意のある活動が発生した場合にはトークンが減らされる可能性があります。パーミッションレス設定では、誰でもステークを蓄積してバリデーターになることができます。さらに、ブロック報酬などの経済的インセンティブは、誠実な行動に対する経済的インセンティブを確保するために、プロトコルに従うバリデーターに提供されます。ただし、盗まれる可能性のある金額が賭け金を超える場合、参加者は共謀して資金を盗む可能性があります。経済的なセキュリティ メカニズムを使用するプロトコルの例には、Axelar および Celer IM などがあります。
2 番目のカテゴリは楽観的なセキュリティ メカニズムであり、このソリューションは、少数のブロックチェーン参加者だけが正直でプロトコルのルールに従っているという前提に基づいています。このアプローチでは、誠実な参加者が保証の役割を果たします。たとえば、最適なソリューションでは、誰でも不正行為の証拠を提出できます。金銭的なインセンティブはありますが、誠実に観察していれば不正な取引を見逃す可能性があります。オプティミスティックロールアップもこのメカニズムを使用します。 Nomad および ChainLink CCIP は、オプティミスティック セキュリティ メカニズムを使用するプロトコルの例です。 Nomad の場合、この記事の執筆時点ではホワイトリストに登録されていますが、観察者は詐欺を証明することができました。 ChainLink CCIPは、オラクルの分散ネットワークで構成される不正行為防止ネットワークを利用して悪意のあるアクティビティを検出する計画ですが、CCIPの不正行為防止ネットワークの実装は不明です。
安全性
セキュリティの観点から見ると、どちらのメカニズムも、ゲーム理論上の妥当性を確保するために、検証者とオブザーバーの許可のない参加に依存しています。経済安全メカニズムでは、賭け金が盗まれる可能性のある金額よりも低い場合、資金はより脆弱になります。一方、楽観的なセキュリティ メカニズムでは、誰も不正行為の証拠を提出しなかったり、権限監視者が危険にさらされたり削除されたりした場合に、少数派の信頼が悪用される可能性があります。対照的に、経済安全保障メカニズムは、安全保障を維持するために活力にあまり依存しません。
埋め込む
実装に関しては、1 つのアプローチには、独自のバリデーターを備えた中間チェーンが含まれます。この設定では、外部バリデータのグループがソース チェーンを監視し、呼び出しが検出されたときにトランザクションの有効性について合意に達します。合意に達すると、ターゲット チェーン上で証拠を提供します。バリデーターは通常、一定量のトークンをステークする必要がありますが、悪意のあるアクティビティが検出された場合はトークンが減らされる可能性があります。この実装方法を使用するプロトコルの例には、Axelar Network や Celer IM などがあります。
別の実装方法には、オフチェーン プロキシの使用が含まれます。オフチェーン プロキシは、楽観的なロールアップのようなソリューションを実装するために使用されます。事前に定義された時間枠内で、これらのオフチェーン プロキシは不正行為の証拠を提出し、必要に応じてトランザクションを取り消すことができます。たとえば、Nomad は独立したオフチェーン プロキシを利用してヘッダーと暗号証明を中継します。一方、ChainLink CCIPは、既存のオラクルネットワークを活用して、クロスチェーントランザクションを監視および証明することを計画しています。
強みと課題
ゲーム理論に基づいた AMP ソリューションの主な利点は、検証プロセスが通常オフチェーンで行われるため、リソースの最適化であり、リソース要件が軽減されます。さらに、コンセンサスメカニズムがさまざまなタイプのチェーンで同じままであるため、これらのメカニズムは拡張可能であり、異種ブロックチェーンに簡単に拡張できます。
これらのメカニズムに関連するいくつかの課題もあります。バリデーターの大多数が共謀すると、信頼の仮定が悪用されて資金が盗まれる可能性があり、二次投票や不正行為の証明などの対策が必要になります。さらに、楽観的セキュリティに基づくソリューションでは、ユーザーとアプリケーションがトランザクションの正当性を確保するために不正なウィンドウを待つ必要があるため、ファイナリティとライブネスの点で複雑さが生じます。
人間を信頼する
人間の実体への信頼を必要とするソリューションは、大きく 2 つのカテゴリに分類できます。
評判のセキュリティ: これらのソリューションは、複数のエンティティがトランザクションを検証して署名するマルチ署名の実装に依存しています。最小しきい値に達すると、トランザクションは有効とみなされます。ここでの前提は、ほとんどのエンティティが誠実であり、これらのエンティティの大多数が特定の取引に署名した場合、その取引は有効であるということです。ここでリスクにさらされるのは、関与する組織の評判だけです。例としては、マルチチェーン (Anycall V;6;) やワームホールなどがあります。 2022 年初頭のワームホール ハッキングで実証されたように、スマート コントラクトの脆弱性により脆弱性が依然として存在する可能性があります。
独立性: これらのソリューションは、メッセージング プロセス全体を 2 つの部分に分割し、異なる独立したエンティティに依存して 2 つのプロセスを管理します。ここでの前提は、これら 2 つのエンティティが互いに独立しており、共謀できないということです。 LayerZero はその一例です。ブロックヘッダーは分散オラクルを通じてオンデマンドで送信され、トランザクション証明はリレーラーを通じて送信されます。証明がヘッダーと一致する場合、トランザクションは有効であるとみなされます。一致の証明はコード/数学に依存しますが、参加者は、これらのエンティティが独立したままであり、悪意がないことを信頼する必要があります。 ;LayerZero; 上に構築されたアプリケーションは、オラクルとリレーを選択する (または独自のオラクル/リレーをホストする) ことができるため、個々のオラクル/リレーへのリスクを制限できます。エンドユーザーは、LayerZero、サードパーティ、またはアプリケーション自体が悪意なくオラクルとリレーを独立して実行していることを信頼する必要があります。
どちらのアプローチでも、参加しているサードパーティ エンティティの評判によって悪意のある行為が阻止されます。これらは通常、バリデーターやオラクルのコミュニティで尊敬されているエンティティであり、悪意のある行動をとった場合、風評被害や他の事業活動に悪影響を与えるリスクがあります。
AMP ソリューションに関する追加の考慮事項
AMP ソリューションのセキュリティと使いやすさを考えるときは、基本的な仕組みを超えた詳細も考慮する必要があります。これらは時間の経過とともに変化する可能性のあるコンポーネントであるため、全体的な比較には含めていません。
コードの整合性
最近のハッキングではコード エラーが悪用されており、堅牢な監査、バグ報奨金、および多様なクライアント実装の必要性が浮き彫りになっています。すべての検証者 (経済的/楽観的/評判的セキュリティ) が同じクライアント (検証用ソフトウェア) を実行すると、単一のコードベースへの依存度が高まり、クライアントの多様性が減少します。たとえば、イーサリアムは、geth、netermind、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 ソリューションの集約と抽象化が行われると予想しています。
「信頼コードと数学」メカニズムの成熟度
理想的な最終段階では、すべてのクロスチェーン メッセージは、ゼロ知識 (ZK) 証明の使用によって信頼が最小化されます。 Polymer Labs や Succinct Labs などの同様のプロジェクトが出現するのを見てきました。 Multichain は、ZK プルーフによる相互運用性に関する zkRouter ホワイト ペーパーも発行しました。最近発表された Axelar Virtual Machine を使用すると、開発者は Interchain Amplifier を利用して、許可なく Axelar ネットワークへの新しい接続を確立できます。たとえば、イーサリアムの状態に合わせて強力なライト クライアントと ZK プルーフが開発されると、開発者はそれらを Axelar ネットワークに簡単に統合して、既存の接続を置き換えたり強化したりできます。 Celer Networkは、dAppsとスマートコントラクトが複数のブロックチェーン上の任意のデータにアクセス、計算、利用できるようにするZKクロスチェーンデータ証明プラットフォームであるBrevisを発表しました。 Celer は、Ethereum Goerli テストネットと BNB Chain テストネット間のクロスチェーンに ZK ライト クライアント回路を使用してユーザー指向のアセット zkBridge を実装しました。 LayerZero は、ドキュメントの中で、将来的に新しい最適化されたプルーフ メッセージ ライブラリを追加する可能性について説明しています。 Lagrange のような新しいプロジェクトは、複数のソース チェーンから複数の証明を集約することを検討していますが、Herodotus は ZK 証明を使用して証明を保存できるようにしています。ただし、このアプローチは、さまざまなコンセンサスメカニズムやフレームワークに依存するブロックチェーン全体に拡張することが難しいため、この移行には時間がかかります。
ZK は比較的新しく複雑なテクノロジーであり、監査が困難であり、現在の検証と証明の生成コストは最適ではありません。私たちは、長期的には、ブロックチェーン上で拡張性の高いクロスチェーン アプリケーションをサポートするために、多くの AMP ソリューションが検証可能なソフトウェアと信頼できる人間やエンティティを組み合わせると考えています。その理由は次のとおりです。
監査とバグ報奨金を通じて、コード悪用の可能性を最小限に抑えることができます。時間が経つにつれて、その履歴が安全性の証拠となるため、これらのシステムを信頼することが容易になります。
ZK プルーフを生成するコストが削減されます。 ZKP、再帰的 ZKP、プルーフ集約、フォールディング スキーム、および特殊なハードウェアに関する研究開発がさらに進むことで、プルーフの生成と検証にかかる時間コストが大幅に削減され、よりコスト効率の高いアプローチになることが期待されます。
ブロックチェーンは ZK をよりサポートするようになります。将来的には、zkEVM は実行の妥当性の簡潔な証明を提供できるようになり、軽量クライアントベースのソリューションはソースチェーンの実行とコンセンサスを簡単に検証できるようになります。イーサリアムの最終段階では、コンセンサスメカニズムを含めた「すべてをzk-SNARK」することも計画されています。
人間の資格、評判、アイデンティティ
AMP ソリューションのような複雑なシステムのセキュリティは、単一のフレームワークだけではカプセル化できず、多層のソリューションが必要です。たとえば、Axelar は経済的インセンティブに加えて、ノードのサブセット間での投票権の集中を防ぎ、分散化を促進するために二次投票メカニズムを実装しています。他の人間の証明、評判、アイデンティティもセットアップと許可のメカニズムを補完することができます。
＃＃＃ 結論は
Web3 のオープンな精神により、複数のアプローチが共存する多元的な未来が訪れるかもしれません。実際、アプリケーションは、冗長的な方法で、またはユーザーがトレードオフに基づいて組み合わせを選択して、複数の相互運用性ソリューションを使用することを選択できます。 「トラフィックの多い」ルート間では、ポイントツーポイント ソリューションが優先される一方で、ハブアンドスポーク モデルがチェーンのロングテールを支配する可能性があります。最終的には、ユーザー、構築者、貢献者のコミュニティとして、Web3 インターネットの基本的な形を形作ることになります。
元のリンク