ZKP はクロスチェーンを保護する唯一の方法ですか?
2022 年以降、Multichain、Succinct、Celer などの多くのクロスチェーン プロジェクトによる ZKP クロスチェーン テストネットの立ち上げにより、ZKP ベースのライト クライアント クロスチェーンが業界で注目を集めるようになりました。 ZKP クロスチェーンの本質はネイティブ検証のカテゴリーに属し、トラストレスなソースチェーンのコンセンサス検証を実現し、DAPP が最も安全なマルチチェーン (またはフルチェーン) エコシステムを構築するのに役立ちます。最も安全と言われる理由は、第三者を信頼することでクロスチェーン通信を実現する現在のクロスチェーンソリューションと比較して、ZKPクロスチェーンは信頼の前提を導入しておらず、ユーザーは信頼するだけでよいためです。ソースチェーンのコンセンサスとターゲットチェーンのコンセンサス。この観点から、ZKP クロスチェーンは最も安全なクロスチェーン方法です。ただし、ZKP クロスチェーン ソリューション技術は非常に複雑であり、敷居が比較的高いです。
1. ZKP を使用してライトクライアントのネイティブ検証を構築することは、トラストレスなクロスチェーンを実現する最良の方法です
クロスチェーンで動作可能なプロトコルは、通常、検証方法の観点から、外部検証、ネイティブ検証、ローカル検証の 3 種類に分類できます。これら 3 種類の相互運用性プロトコルには独自の制限があり、トラストレス性、スケーラビリティ、汎用性のバランスをとることが困難です。
1. 外部検証
外部検証とは、クロスチェーン メッセージの検証を担当する信頼できる外部ノードのグループを導入することを指します。その前提として、ユーザーはこの外部ノードのグループによって形成されるリレー ネットワークを信頼する必要があります。 MPC、Oracle システム、PoS/PoA、マルチシグネチャ、および TEE に基づくクロスチェーン ソリューションはすべて、このカテゴリに分類されます。外部検証クロスチェーン相互運用性プロトコルは、サードパーティの中継ノードまたはオラクルの信頼に基づいており、トラストレスなメッセージ中継クロスチェーンを実現することは不可能ですが、場合によっては中継者やオラクルの検証も困難です。信頼。このタイプのクロスチェーン実装は、Multichain、Wormhole、Axelar、LayerZero などの有名なプロジェクトを含む、現在の市場の主流です。
2. ローカル認証
ローカル検証は P2P 検証とも呼ばれ、取引相手の直接検証を指し、その核心はハッシュ タイム ロックに基づくアトミック交換です。取引中は、取引当事者双方が相手方の行動を個別に確認し、一方が悪事を行う限り双方が損失を被ることになるため、双方の利益は一致します。実際には、取引を照合するために、取引相手として機能する流動性プロバイダーが存在します。 Connext と Hop はどちらもこのカテゴリの典型とみなすことができます。ただし、このタイプのソリューションはアセット クロスチェーンにのみ適しており、一般的なメッセージ クロスチェーンには適しておらず、汎用性が弱いです。
3. ネイティブ認証
ネイティブ検証とは、ターゲット チェーン上にソース チェーン ライト ノードをデプロイすることを指し、ソース チェーン メッセージはターゲット チェーンのライト ノードによって検証されます。ネイティブ検証には信頼の前提はありません。理論的には、ユーザーは、ソース チェーンのコンセンサスとターゲット チェーンのコンセンサスを確認し、ソース チェーンがターゲット チェーンでロールバックしないことを確認します (通常、チェーン上のライト ノードは、ソース チェーンとターゲット チェーンのロールバックを防ぐために、一定量のブロック冗長性を設定します)。 。ネイティブ検証の代表的なプロジェクトには、Rainbow Bridge が含まれ、過去 2 年間の ZK ベースのクロスチェーン ソリューションもこのカテゴリに分類され、代表的な ZKP クロスチェーン プロジェクトには、zkRouter、Succinct Labs、Nil;Foundation などが含まれます。
3 種類のクロスチェーン相互運用性プロトコルの検証方法の包括的な比較を表 1 に示します。
表1 クロスチェーン相互運用性プロトコルの3種類の検証手法の総合比較
マルチチェーンエコロジーの隆盛により、クロスチェーンの需要が生まれました。 Multichain (anyCall)、Layerzero、Wormhole などの優れたクロスチェーン プロジェクトが次々と誕生していますが、これらのクロスチェーン プロジェクトでは、より汎用性や拡張性が重視され、信頼できる中継ネットワークも必要とされています。
しかし、2021年から2022年にかけて、Ronin Network、Horizon、BNB Chain、Wormhole、Nomadなどのクロスチェーンプロジェクトが軒並みハッカーの攻撃を受け、膨大な資産が盗まれました。マルチチェーンのエコロジーユーザーとクロスチェーントラックの参加者は、トラストレスクロスチェーンはスケーラビリティが弱いものの、トラストレス機能はユーザーにとってより安全な選択肢であることに気づきました。したがって、ネイティブ検証はトラストレスクロスチェーンを実現する最良の方法になります。
ただし、通常のネイティブクロスチェーン相互運用プロトコルは、ターゲットチェーン上のソースチェーンのコンセンサスを検証するために大量のGasを消費する必要があり、その理由は、ターゲットチェーンのライトクライアントが大量のGasを取得する必要があるためです。ソースチェーンデータを収集してコンセンサスに関する情報を生成します。ネイティブ検証に ZKP を使用すると、簡潔な ZKP 証明を生成することで、ターゲット チェーンのライト クライアントはターゲット チェーンのトランザクションを検証するために ZKP を取得するだけで済みます。したがって、ZKP を使用してライト クライアント用のネイティブ検証メソッドを構築することは、より良いソリューションになります。 。
2. コンセンサス送信によるトラストレスクロスチェーンの実現
Polkadot や Cosmos などのパブリック チェーンのエコロジカル コンセンサスは、エコロジー内のクロス チェーンを当然サポートしますが、イーサリアム、ソラナ、その他の異種チェーンなど、同じエコロジー内にないパブリック チェーンの場合、そのクロスチェーンを利用することはできません。チェーンの利点。マルチチェーン、レイヤーゼロ、ワームホールなどの主流のサードパーティ クロスチェーン ブリッジはすべて、リレー ネットワークを信頼する必要があります。 ZKPを利用して構築されたクロスチェーンソリューションは、第三者を信頼する必要がなく、ソースチェーンのZKPコンセンサス証明をターゲットチェーンに直接送信し、ターゲットチェーンのライトクライアントはソースのコンセンサス証明を検証するだけで済みます。クロスチェーンで合意を達成するためのチェーン。
ただし、チェーンごとにコンセンサス生成の原則と方法は大きく異なり、コンセンサスを検証するために必要なデータも異なります。 ZKPクロスチェーンの難しさは、ソースチェーンコンセンサスZKPをどのように生成するかであり、ソースチェーンコンセンサスZKPはソースチェーンコンセンサスデータに基づいて生成されるため、ソースチェーンZKPの生成もソースチェーンに基づく必要があります。コンセンサス。さまざまなソースチェーンのコンセンサスによって生成された ZKP 回路もカスタマイズする必要があります。
異なるパブリックチェーンのコンセンサス生成プロセスは大きく異なり、ZKP の生成プロセスも異なります。以下では、このプロセスを説明するためにイーサリアム POS を例に挙げます。
イーサリアムは、コンセンサスを生成するために複雑なバリデーター選択メカニズムを設計しました。イーサリアムは、Altair アップグレードに重要な機能を追加しました。これは、ライトクライアントがブロック状態を同期できるように特別に設計された同期委員会です。イーサリアムは、RANDAOアルゴリズムを使用して512人の検証者をランダムに選択して同期委員会を形成し、同期委員会の情報はビーコンチェーンに保存され、256エポック（1エポックは約6.4分）ごとに更新されます。同期委員会の役割はブロックヘッダーに継続的に署名することであり、同期委員会メンバーの2/3が署名した時点でイーサリアムの状態遷移が確認されます。
ビーコン チェーンは、バリデーターが POS コンセンサスに参加する方法として BLS 12-381 アルゴリズムを使用します。ビーコン チェーン ブロック内の複数の検証者の BLS 署名をさらに 1 つの署名に集約できるため、元のいくつかの署名によるデータ通信とオンチェーン ストレージの負荷が効果的に軽減されます。同時に、バリデーターは単一の署名を検証するだけで、ブロック検証をより効率的に実行できます。
同期委員会はコンセンサス メカニズムの不可欠な部分であるため、ライト クライアントはバリデータ セット全体にアクセスしなくても、検証済みのコンセンサス状態を取得できます。ソースチェーンのコンセンサスステータスを確認するために、ターゲットチェーンのライトクライアントはいくつかのデータをダウンロードし、以下を含む検証と計算を実行します。
(1) マークルパス証明。現在のブロックの署名を検証する委員会 (sync_cmts) は、検証されたブロックのヘッダーで指定されている次の委員会です。
(2) 集約委員会の公開鍵。現在のブロック同期委員会の実際の署名に従って、集約委員会の公開鍵を計算できます。
(3) 委員会の署名を同期します。集約された委員会の公開キーを使用して、新しいブロック内の委員会の署名を検証します。
画像の説明
画像の説明
出典: zkPoS: エンドツーエンドのトラストレス
上記の ZKP ライト クライアント同期コンセンサス プロセスから、オフチェーン プルーフ生成プロセスがソース チェーン コンセンサス メカニズムおよびライト クライアント サポートと密接に関連していることがわかります。このため、チェーン上にライト クライアントを実装するのは難しく、ライト クライアントはイーサリアムがアップグレードされるたびに同期コードを更新する必要があるかどうかを確認する必要があります。
3. ZKPクロスチェーンプロジェクトの比較
ZKP クロスチェーンのプロセスも同様で、個別のケースを分析する際、著者は各クロスチェーン プロジェクトの独自性により注意を払います。 ZKP クロスチェーンの基本原理は、以前のブログ (https://www.theblockbeats.info/news/35560) でご覧いただけます。
1. zkRouter（Multichain）
zkRouter は Multichain によって開発された ZKP クロスチェーン プロジェクトであり、そのホワイト ペーパーによると、そのビジョンは、zkRouter を MBI (マルチチェーン相互運用性プロトコル) の一部として開発し、そのマルチチェーン相互運用性プロトコルを基礎的な信頼メカニズムとして提供することです。 。この部分の内容は前回の記事で詳しく説明しましたが、ここでは重要なポイントをいくつか紹介します。
画像の説明
画像の説明
出典: zkRouter: トラストレスな一般的なクロスチェーン インフラストラクチャ
( 1) 初期設定(Setup)
ターゲット チェーン ライト クライアントがソース チェーン ZKP 証明の検証を完了するには、前のソース チェーン ブロックのコンセンサス状態を持っている必要があります。ブロックチェーンのコンセンサス状態は連続的です。つまり、現在のブロックのコンセンサス結果は、前のブロックのコンセンサス結果に基づいて更新されるため、ターゲット チェーンのライト クライアントは、検証する前に、まずソース チェーンの現在のコンセンサス状態を取得する必要があります。後続のブロック コンセンサスの正しさ。
ターゲットチェーンのライトクライアントは、最初に初期のinitial_dataを必要とします。これには、初期ブロックの高さ、ブロックヘッダーハッシュなどが含まれます。初期設定は一度行うだけで済み、その後クロスチェーン動作が発生するとデータが自動的に更新されます。
( 2) コンセンサス証明の生成（Proof Gen）
このステップは、特定のクロスチェーン プロセスで発生します。ソースチェーンが新しいブロックを生成するとき、ターゲットチェーンは、前のブロックのステータス、ブロック生成ノードの選択、署名ノードの正当性などの新しい情報を同期する必要があります。非即時ファイナリティコンセンサスメカニズムの場合、フォークによる損失を避けるために一定数の冗長ブロックを設定することも必要です。次に、リレーラーはオフチェーン ZKP テクノロジーを通じてオフチェーン ZKP を計算および生成し、ターゲット チェーンに同期します。
(3) コンセンサス証明の検証（ProofVerify）
単純な ZKP がリレーラーによってターゲット チェーンに送信された後、ZKP を検証する必要があります。作業のこの部分はチェーン上のライト クライアントによって実行されます。検証に合格すると検証結果が返され、ソースチェーンのコンセンサスステータス情報がターゲットチェーン上で更新されます。
( 4) 相互運用可能な契約通話（InterOperCall）
ターゲット チェーン ライト クライアントがソース チェーン コンセンサス (ソース チェーン トランザクションを含む) の検証に合格すると、参加者はクロスチェーン コントラクトの相互運用性呼び出しを開始して、クロスチェーン インタラクションを完了できます。詳細については、ホワイトペーパーを参照してください。
zkRouter の主な利点は、高 TPS クロスチェーンの実現です。説明によると、zkRouter の TPS 上限はパブリック チェーンの TPS であり、テスト ネットワークではデータが 100 TXS に達することが示されています。
Goerli テスト ネットワークのソース チェーン アドレス: https://goerli.etherscan.io/txs?a=0x91d1d54572ef662419d9e552a013321b5713e3ad
Fantom テスト ネットワーク ターゲット チェーン アドレス: https://testnet.ftmscan.com/address/0x91d1D54572Ef662419d9E552A013321b5713E3AD#tokentxns
zkRouter の具体的なソリューションについては、ホワイト ペーパーで具体的な説明を参照してください。
2. Hyper Oracle（Hyper Oracle）
Hyper Oracle は、自身をトラストレスなオラクル ネットワークとして定義します。他の ZKP クロスチェーン プロジェクトとの違いは、Hyper Oracle がコンセンサス全体の転送を重視していることです。 Hyper Oracle のビジョンは、エンドツーエンドのトラストレスを実現することであり、これにはライト クライアントがイーサリアム PoS のコンセンサス全体を検証する必要があります。
イーサリアム POS の実装では、同期委員会のコンセンサスはすでに全体のコンセンサスの一部となっていますが、なぜ全体のコンセンサスの送信を重視する必要があるのでしょうか?
3. Brevis（Celer）
Brevis は、本質的にクロスチェーン通信ソリューションであるフルチェーン コンピューティングおよび検証プラットフォームとして自身を定義し、ZKP コンセンサス証明を生成することでトラストレスなクロスチェーン通信を実現します。 Brevis には、zkFabric、zkQueryNet、zkAggregatorRollup という 3 つのコンポーネントが含まれています。現状から判断すると、その対象範囲にはEVMチェーンとNON-EVMチェーンが含まれます。
zkFabric の主な機能は、ブロック ヘッダーを収集し、ZKP ライト クライアント回線を通じてその有効性を証明した後、コンセンサス プルーフを生成することです。これは、ZK クロスチェーン ロールの中継者および認証者に相当します。もちろんこのシステムでは中継先はzkAggregatorRollupです。
zkAggregator Rollup は、軽量 ZKP 仮想マシンを搭載した ZK ロールアップ ブロックチェーンで、zkQueryNet および zkFabric からのさまざまな証明と入力情報を集約します。 Celer の説明によると、zkAggregatorRollup VM ランタイムには次の機能があります。
(1) zkQueryNet と zkFabric によって生成された証明を再帰的に検証します。
(2) zkFabric からブロック ヘッダーを保存し、ZKP によって検証されます。
(3) クエリリクエストと ZKP 検証結果を保存します。
zkQueryNet は、チェーン上のスマート コントラクトからデータ クエリを直接受け入れ、ZKP クエリ エンジン回路を通じてクエリ結果と対応する ZKP クエリ証明を生成できる ZKP クエリ エンジンを提供するオープン マーケットです。この結果はクエリ結果にも保存されます (クエリ結果は zkAggregatorRollup モジュールに属します)。
画像の説明
画像の説明
出典: Brevis: ZK オムニチェーン データ認証プラットフォーム
他の zk クロスチェーン プロジェクトと比較して、Brevis の最大の特徴はモジュール化です。この構造化された設計により、Brevis の拡張性が向上します。さまざまな機能をカプセル化することで、Brevis は統一されたインターフェイスを実現できます。DAPP 呼び出しを容易にしながら、その後の接続にも役立ちます。より多くのパブリックチェーンの拡大。
4. Telepathy（Succinct）
テレパシーは、ユーザーが許可や信頼なしに相互運用性を実現できるようにすることを目的として、Succinct チームによって開発されたプロトコルです。テレパシーを通じて、DAPP はソース チェーンから任意のターゲット チェーンにメッセージを安全に送信できます。この定義は、従来のクロスチェーン メッセージ定義モデルに準拠しています。
テレパシーのクロスチェーン通信モデルには、図 4 に示すように主に 5 つのステップがあります。
(1) マルチチェーン DAPP コントラクトは、マルチチェーン相互運用性コマンドを開始します。
(2) Telepathy Broadcaster がこの指示を受信してから約 12 分後に、Ethereum メインチェーンが最終的な合意を形成します。
(3) テレパシーオペレーターはイーサリアムコンセンサスを使用して ZKP コンセンサス証明を生成します。
(4) Telepathy Relayer は、コンセンサス証明をターゲットチェーンコントラクトに渡します。
(5) ターゲット チェーンのライト クライアント コントラクトは、ZKP コンセンサス証明を検証します。
画像の説明
画像の説明
出典：テレパシー公式プロフィール
5. Nil.foundation
Nil の位置付けは Brevis と同様であり、マルチチェーンの証明市場になることを目標としており、DAPP は自社のニーズに応じて証明データの生成を Nil に要求できます。ここではあまり詳しく説明しません。
また、前回の記事で紹介したzkLLVMもNilの中核製品の1つです。この製品は、開発者が高級言語を使用して ZKP をコンパイルできるようにすることを目的としており、開発者の参入障壁を大幅に軽減します。このツールを使用すると、開発者は特定のドメイン言語 DSL の学習に行き詰まることなく、使い慣れた言語を使用して回路設計に集中できます。
4. まとめと展望
現在、多くのチームが ZK クロスチェーンブリッジの開発に取り組んでいます。 ZKP の生成はソースチェーンのコンセンサスと密接に関連しており、チェーンが異なればコンセンサスに達する方法や使用される署名アルゴリズムも異なるため、実際には、表 2 に示すように、さまざまなスキームの効率と特性も異なります。
表 2 ZKP に基づく主要なクロスチェーン プロトコルの比較
これらのプロジェクトはSNARK技術をベースとしたゼロ知識証明システムですが、実装アルゴリズム、アルゴリズムの最適化度、使用するハードウェアを統一することが難しいため、上記のZKP生成速度は参考値であり、より詳細なデータが必要です。より厳密にするために。
現在、ほとんどの ZK クロスチェーン ブリッジは NON-EVM をサポートしており、この点ではプロジェクト間の違いはほとんどありません。将来的には、ZK クロスチェーン相互運用性プロトコルの主な競争ポイントは、アルゴリズムの最適化、マルチチェーンの展開、および契約のセキュリティにあるでしょう。
ZKP オフチェーンの生成には大容量メモリの高性能サーバーが必要ですが、これは機器コストが高くつくことを意味し、最適化されたアルゴリズムにより計算能力を節約できます。
過去 2 か月間、多くのクロスチェーン プロトコルが基本的に ZKP クロスチェーン開発を中心に活動を開始しましたが、一般にクロスチェーン テストネットが立ち上げられ、メインネットはあまり立ち上げられません。また、多くのクロスチェーンプロトコルは一般に 1 つまたは 2 つのチェーンをリンクしており、マルチチェーンの相互運用性を実現していないため、将来的にクロスチェーンブリッジがサポートするチェーンが増えるほど、競争力はさらに高まるでしょう。
ZKクロスチェーンプロジェクトは通常、大規模な市場テストを受けておらず、契約の安全性がこれらのプロジェクトがこの市場で生き残れるかどうかを決定します。現時点では、この問題はほとんどの人に無視されており、将来のセキュリティは ZKP プロジェクトの最大のリスク項目になるでしょう。
クロスチェーン プロトコルは、ブロックチェーンのセキュリティ インシデントで最も大きな被害を受けている分野であり、ほぼすべての専門家がクロスチェーン プロトコルについて心配しています。さらに深刻なのは、現在主流のクロスチェーン プロトコルのほとんどすべてが外部検証のカテゴリーに属していることです。トラストレスネスの実現には重大なセキュリティリスクが伴います。ひとたび中継者たちが力を合わせて悪事を働くと、マルチチェーンの生態系参加者は計り知れない損失に直面することになる。ネイティブ検証の一種である ZKP クロスチェーンは、トラストレス、ユニバーサル、およびその他のネイティブ検証クロスチェーンの独自の利点があるだけでなく、ターゲット チェーン上の元のソース チェーン データを直接検証する方法よりもガス消費量が少なくなります。最近のクロスチェーン プロジェクト Fang は、頻繁に ZKP クロスチェーン テスト ネットワークを立ち上げており、これは彼らもこの点を強く意識していることを示しています。ただし、ZKP クロスチェーン プロトコルの開発はまだ初期段階にあり、ZKP クロスチェーン プロトコルがユーザーにより安全なクロスチェーン エクスペリエンスを提供できるかどうかは、今後追跡および観察される必要があります。
元のリンク
https://hyperoracle.medium.com/zkpos-end-to-end-trustless-65edccd87c5a
https://blog-cn.celer.network/2023/03/22/brevis-a-zk-omnichain-data-attestation-platform/
https://drive.google.com/file/d/1ibuHChcYcYCN6JelRAQPnM4rkaB9EgAM/view
https://blog.succinct.xyz/blog/telepathy
https://docs.telepathy.xyz/protocol/overview
https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/
