セグメントのプルーフが生成されると、最終的にはロールアップされます。各「ロールアップ」操作は、連続するセグメント化されたプルーフのペアを取得し、それらのセグメントの組み合わせに対して新しいプルーフを生成します。たとえば、セグメント 1 がプログラムが状態 A から状態 B に遷移したことを証明し、セグメント 2 がプログラムが状態 B から状態 C に遷移したことを証明する場合、ロールアップはプログラムが状態 A から状態 C に遷移したことを証明します。十分なワーカーがあれば、これは log(N) 時間で実行できます (N はフラグメントの数です)。
さらにコストを削減するにはいくつかの方法があります。おそらく Keccak アクセラレータを追加して、zkVM のパフォーマンスを向上し続けることに加えて、より安価なインスタンスを探すこともできます。重要なのは、私たちが使用している低スペックのマシン (そして私たちの zkVM は nVidia Cuda と Apple Metal をサポートしている) を考慮すると、この作業は一般の消費者向け PC および Mac の p2p ネットワーク経由で簡単に実行できることです。
オンチェーン検証
上で述べたように、RISC Zero Groth16 バリデーターを使用して Sepolia 上の Zeth 証明を検証しました。これは、今月初めにリリースされた RISC Zero プロトコル スタックの比較的新しい部分です。これは、Bonsai を使用して zkVM のネイティブ STARK プルーフを同等の SNARK プルーフに変換し、そのプルーフをオンチェーンの SNARK バリデータに送信することで機能します。
イーサリアム ブロック バリデータ Zeth の詳細説明: 最初のタイプ 0 zkEVM
原題: Announcing Zeth: the first Type Zero zkEVM
著者：ティム・カーテンス、ヴィクター・グラフ、ラミ・カリル、スティーブン・リー、パーカー・トンプソン、ヴォルフガング・ウェルツ、ゼス・コラボレーション
ビルド: Bayemon.eth、ChainCatcher
8 月 25 日、RISC Zero zkVM に基づくイーサリアム オープン ソース ZK ブロック バリデーターである Zeth が一般公開されました。 Zeth は、バリデーターや同期委員会に依存せずに、zkVM で新しいブロックを構築するために必要なすべての作業を実行します。 Zeth はイーサリアム メインネットの複数の実際のブロックで検証されており、公式イーサリアム テスト スイートのすべての関連テストに合格しています。 Zeth は 4 週間以内に、zkVM ベースの Rust サポートと、revm、ethers、alloy を含む強力なボードを実装することができました。 zkVM の継続性および Bonsai プルーフ サービスのサポートにより、Zeth はこれらのプルーフを数分で生成できます。 Zeth のオンチェーン検証のサポートにより、誰でも低コストでこれらの証明をオンチェーンで検証できます。この投稿ではさらに詳しく説明しますが、コードを詳しく知りたい場合は、ソース コードをチェックし、RISC Zero 開発者ポータルにアクセスしてください。
＃＃＃ まとめ
約 1 年前、Vitalik はさまざまな種類の zkEVM について詳しく説明しました。
イーサリアムの歴史の中でこれが可能だったケースはありましたが、本日、RISC Zero の zkVM および Bonsai サービスを使用したイーサリアムのブロック証明が数時間ではなく数分で完了することを発表できることを嬉しく思います。
Zeth: 検証可能な Ethereum ブロックの生成
本日、RISC Zero zkVM 上のイーサリアム用のオープンソース ZK ブロック検証ツールである Zeth をリリースしました。
Zeth は、バリデーターや同期委員会に頼ることなく、特定のイーサリアム ブロックが有効であることを証明できます。これは、Zeth が zkVM で新しいブロックを生成するために必要な次の作業をすべて実行するためです。
新しいブロックが生成された後、Zeth はそのハッシュを計算して出力します。 zkVM でこのプロセスを実行することにより、新しいブロックが有効であるという ZK 証明を取得できます。
RISC Zero の zkVM と、revm、ether、alloy などの人気のある Rust クレートを活用することで、私たちは 4 週間以内に Zeth の最初のバージョンを作成しました。 zkVM の継続性サポートと Bonsai プルーフ サービスにより、プルーフの生成はわずか数分で実行できます。オンチェーン検証のサポートにより、これらの証明を低コストでオンチェーンで検証できます。
Zeth はイーサリアム メインネットの複数の実際のブロックで検証されており、公式イーサリアム テスト スイートのすべての関連テストに合格しています。
Zeth は標準の Ethereum ブロックを構築するため、タイプ 1 zkEVM と考えることができます。しかし、それはそれだけではありません。Zeth は標準の Rust コードボード (Reth などの一般的なフルノードで使用されるのと同じコードボード) を使用して構築されているため、クラス 0 zkEVM として考えることを好みます。完全なプロトコル互換性と、多くのコードの再利用です。 。 **
このマイルストーンは、ZK テクノロジーとイーサリアム エコシステムにとって大きな前進を意味します。この投稿では、数週間で Zeth の最初のバージョンを作成する方法、そのパフォーマンス、仕組み、そしてこれが ZK プロジェクトにとって何を意味するかについて説明します。
RISC Zero により、zk ロールアップ、zkEVM、ライト クライアント、ブリッジの構築が容易になります
Zeth を作成した理由は 2 つあります。
zk ロールアップと zkEVM
タイプ 0 zkEVM として、Zeth を使用すると、開発者は完全にネイティブな EVM とイーサリアム互換性を備えた zk ロールアップを構築できます。 Zeth のオンチェーン証明検証のサポートと組み合わせると、ZK 主導の L2 拡張ソリューションの構築が非常に簡単になります。
既存の ZK ロールアップおよび zkEVM 回路は設計上モノリシックであり、ZK 暗号化について高度な理解を持っている開発者なしではアップグレードできません。対照的に、zkVM ベースの Zeth アプローチでは、開発者はニーズに応じてカスタマイズおよび変更できます。
Zeth は revm に基づいたオープンソースであり、他の zkEVM および EVM 互換チェーンをサポートするための調整は比較的簡単な作業です。したがって、Zeth は将来の EIP アップデートに対して比較的迅速に対応できるようになります。さらに、Zeth はモジュール性も提供し、開発者が独自のブロック構築ロジックを構築できるようにします。
zk 主導の L2 ソリューションには以前は何年にもわたる研究開発と 1 億米ドルを超える資金が必要であり、ほとんどのプロジェクトでは余裕のない資金を消費していたことを承知しており、Zeth の取り組みによって zk ロールアップと zkEVM が民主化されることを期待しています。
ライトクライアントとブリッジ
ビーコン チェーンの導入がライト クライアントとブリッジにとって恩恵となることは疑いの余地がありません。これらの技術は、イーサリアムの現在成熟した PoS モデルに基づいて構築されており、全員がルールを遵守していれば、ライトクライアントとブリッジが最近のブロックを再構築することなく簡単に検証できるようになります。
もちろん、ステーキングの目的は、ノードがルールに従う経済的インセンティブを提供することです。ただし、Slashing がノードに課す脅威は、悪を完全に回避することはできません。外部からのインセンティブにより、利害の「バランス」は常に悪に傾きます。そして、これらの悪意のある動作を適切に処理できる軽量クライアントまたはブリッジを設計することが非常に重要です。難しい。
Zeth のようなツールを使用すると、ノードが悪事を行うリスクが大幅に軽減されます。ライト クライアントは、zkVM にいくつかのコールアウトを追加するだけで Zeth と統合でき、ブリッジなどのオンチェーン アプリケーションは、オンチェーンのproof-of-proof 検証コントラクトを使用して Zeth と統合できます。
近い将来、ライトクライアントとブリッジが ZK 証明を使用して特定のブロックが有効かどうかを判断することを想像できます。このアプローチでは、ブロックの検証コストを大幅に増加させることなく、リスクを大幅に軽減できます。
これは、イーサリアムの大規模なフルノード コミュニティが提供するのと同じレベルのセキュリティをまだ備えていないアプリケーション チェーン、モジュラー エコシステム、および新しいチェーンにとって特に重要です。
優れた基盤はプロジェクト開発プロセスを簡素化します
RISC Zero zkVM をベースにし、RISC-V 命令セット アーキテクチャを活用した Zeth は、開発者に使い慣れたプログラミング エクスペリエンスを提供します。しかし、私たちの zkVM は単なる RISC-V コアではありません。また、ハッシュや署名検証などの一般的な暗号タスク用の高速化回路もあります。
このハイブリッド アプローチ (汎用 CPU コアと加速回路の組み合わせ) により、次の両方の長所が得られます。
その結果、revm、ether、alloy の既存の Rust コード パッケージを使用して Zeth を迅速に構築することができました。既存のボードを再利用することで、4 週間以内に Zeth の最初のバージョンを完成させました。この種の速度は、成熟していないエコシステムでは不可能です。
パフォーマンスの面では、Zeth は ECDSA 署名検証と継続性のアクセラレータ回路を活用しています。これは、(nVidia CUDA または Apple Metal を使用して) 並行して動作する GPU のクラスターを簡単に使用して、大容量であることを迅速に証明できる ZK フレームワークの新機能です。計算。継続は使いやすいです。この機能は、zkVM で実行されているすべてのゲスト プログラムに透過的に提供されます。つまり、正しく機能するためにコードを変更する必要はありません。
zkVM を使用すると、イーサリアム ブロックの有効性の ZK プルーフを数時間ではなく数分で迅速に生成できます。
＃＃＃ パフォーマンス
Zethブロックジェネレーターのパフォーマンスについて説明します。 Zeth はまだ新しい製品であるため、これらの数値は変更される可能性がありますが、将来の作業のベースラインとして役立つ具体的な数値を提供したいと考えました。
パフォーマンスに関しては、考慮すべき要素がいくつかあります。
継続性
Zeth の zkVM は、継続実行を使用してパフォーマンスを調整できます。そこで、少し立ち止まって、「継続的操作」がどのように機能するかを議論する必要があります。
当社の zkVM は標準の RISC-V プロセッサを実装しています。したがって、実行はサイクルで測定されます。 (私たちの回路では、例外もありますが、ほとんどの RISC-V 命令は 1 サイクルで実行されます)。通常、単純なプログラムの実行には数十万サイクルしか必要としませんが、より複雑なプログラムには数十億サイクルが必要になる場合があります。
一般的な ZK システムでは、これらの実行サイクルはプルーフにプールされ、サイクル数が増加すると、プルーフの生成に必要な時間とメモリも増加します。しかし、私たちの zkVM はこれらの固定概念に従っておらず、今年初めに、従来の証明スキーマ生成の欠点を改善する新しい継続性機能を開発しました。
継続性の観点から、証明プロセスは 3 つのフェーズに分かれています。
必要な計算は非証明シミュレーターで実行します。途中で、これまでにループが実行された回数を数えます。設定可能な間隔で、プログラムの状態のスナップショットを取得します。これにより、実行が効果的に複数の部分に分割されます。各セグメントは小さく、通常は 100 万サイクル以下を表します。
これらの部分はプルーフ生成ワーカーのセットに割り当てられます。彼らは、指定されたプログラム セグメントの ZK 証明を生成します。重要なのは、これを並行して実行できることです。十分なワーカーがいる限り、1 つのプログラム セグメントを証明するのに必要な時間内にすべてのプログラム セグメントを証明できます。ネットワーク セグメントのサイズが小さいため、通常、必要な時間は短くなります (数十秒)。
セグメントのプルーフが生成されると、最終的にはロールアップされます。各「ロールアップ」操作は、連続するセグメント化されたプルーフのペアを取得し、それらのセグメントの組み合わせに対して新しいプルーフを生成します。たとえば、セグメント 1 がプログラムが状態 A から状態 B に遷移したことを証明し、セグメント 2 がプログラムが状態 B から状態 C に遷移したことを証明する場合、ロールアップはプログラムが状態 A から状態 C に遷移したことを証明します。十分なワーカーがあれば、これは log(N) 時間で実行できます (N はフラグメントの数です)。
数字を詳しく調べると、これらの段階が実際に動作していることがわかります。
**イーサリアムブロックを構築するのはどのくらい難しいですか? **
まず、イーサリアム ブロックの構築の複雑さを見てみましょう。以下の表では、いくつかの現実世界の Ethereum ブロックを取得し、zkVM の Zeth を使用してそれらを再構築します。
たとえば、ブロック 17606771 は 2131 のエクステントを生成します。各セグメントは最大 2^20 の実行サイクルを表すため、計算全体には最大 2,234,515,456 の実行サイクルがかかります。
一般に、典型的なイーサリアム ブロックの構築には 2 ～ 4 億サイクルかかりますが、場合によっては 95 億サイクルもかかることがあります。 (最初は、これらの違いがトランザクションのガスに反映されていないことに驚きました。しかし、さらに考えてみると、それは理にかなっていました。ガス システムは、ZK 証明ではなく、定期的な実行を念頭に置いて設計されていました)。
継続性があるため、この規模は管理が容易です。これらの数字によると、zkVM バリデーターを実行する 10,000 ノードのピアツーピア ネットワークは、最大のブロックに対して最高の並列検証パフォーマンスを達成するのに十分ですが、これはイーサリアムが現在備えている 700,000 個のバリデーターのほんの一部です。
**証拠を生成するのにどのくらい時間がかかりますか? **
基本的なパフォーマンス データを収集するために、64 GPU ワーカーを備えた Bonsai テスト インスタンスを起動しました。次に、Zeth を使用して 17735424 (182 トランザクション、3242 セグメント、または約 34 億サイクル) をブロックすることを証明するように依頼しました。
プルーフを生成するには、zkVM はまず実行をセグメントに分割する必要があります。以下のスクリーンショットでは、このプロセスは 10 分間実行された utor タスクによってキャプチャされました。 (その時間のほとんどは、ネットワーク ストレージへの書き込みなどの AWS の作業に費やされます)。ローカル マシンでは、同じタスクが完了するまでに 6 分もかかりません。来年にかけてこの時間を大幅に短縮したいと考えています)。
実行者は最終的に実行を 3242 個の部分に分割します。わずか 64 個の GPU ではかなりの断片化になります。したがって、各ワーカー ノードはセグメントのプルーフを 50 個生成する必要があります。次の図に示すように、これには 35 分かかります。 50 倍のワーカー ノードがある場合、所要時間はわずか 42 秒です。
セグメント校正が完了すると、ロールアップが開始されます。セグメントが 3242 個あるため、log_2(3242) = 12 ラウンドのロールアップ プロセスを実行する必要があります。ロールアップの初期段階ではワーカーの数がワーカーよりも多いため、最初のステージには 1 分、第 2 ステージには 35 秒、第 3 ステージには 25 秒かかります。ステージ 7 までに、タイムは 5 秒強で安定しました。同様に、より多くのワーカーがいる場合、各ステージにかかる時間はわずか 5 秒になります。
ロールアップが完了すると、結果が確定します。これにはさらに 1 分かかります。
その結果、クラスターサイズが不十分でも、約 50 分 (実効速度 1.1 MHz) で証明を生成することができました。クラスターのサイズが適切であれば、証明の生成はより速くなると推定されます。
完全に並列化された場合、証明ステップは 42 + 12 * 5 + 60 秒、つまり 2 分 42 秒で完了できます。
控えめに四捨五入して実行時間を含めると、時間は 9 ～ 12 分の間になります (実効速度 4.7 MHz ～ 6.3 MHz)。
私たちはエグゼキュータと証明フレームワークの改善を続けているため、この時間が来年には大幅に短縮されると楽観的に考えています。
プルーフを生成するためのリソース消費
上記のテスト クラスターは AWS にデプロイされました。これは、64 個の g5.xlarge 証明ノードと 1 個の m5zn.xlarge 実行ノードで構成されます。 Amazon によると、各 g5.xlarge ノードには
この記事の執筆時点では、これらのインスタンスのオンデマンド料金は 1.006 ドル/時間、リザーブド インスタンスは 0.402 ドル/時間です。一方、Amazon の仕様書によると、m5zn.xlarge ノードには
この記事の執筆時点では、このインスタンスのオンデマンド料金は 0.3303 ドル/時間です。
これらの数値を使用して、上記のブロック 17735424 の証明コストを大まかに見積もることができます。
64 個のプルーフ ノードをデプロイしましたが、このデプロイメントではプルーフの生成に (エンドツーエンドで) 50 分かかったことを思い出してください。ワーカーのアイドル時間を無視すると、64 個の証明ノードと 1 個の実行ノードのコストは、50 分間で 50/60 * (64 * 0.402 + 0.3303) = 21.72 ドルになります。これは、遊休労働者に賃金を支払っていることを前提としているため、過大評価です。従業員をアイドル状態にするコスト (たとえば、従業員をシャットダウンするか、別の仕事に就かせるなど) を考慮しない場合、そのコストは約 19.61 ドルになります。
これらの金額の見積もりはクラスターのサイズとは無関係であることに注意してください。重要なのはセグメントの数です。これは、1 台のマシンが 2 つのジョブを順番に実行する場合のコストは、2 台のマシンが 1 つのジョブを並行して実行する場合と同じであるためです。したがって、クラスター サイズが大きい場合、プルーフの生成は速くなりますが、コストは高くなります。
さらにコストを削減するにはいくつかの方法があります。おそらく Keccak アクセラレータを追加して、zkVM のパフォーマンスを向上し続けることに加えて、より安価なインスタンスを探すこともできます。重要なのは、私たちが使用している低スペックのマシン (そして私たちの zkVM は nVidia Cuda と Apple Metal をサポートしている) を考慮すると、この作業は一般の消費者向け PC および Mac の p2p ネットワーク経由で簡単に実行できることです。
オンチェーン検証
上で述べたように、RISC Zero Groth16 バリデーターを使用して Sepolia 上の Zeth 証明を検証しました。これは、今月初めにリリースされた RISC Zero プロトコル スタックの比較的新しい部分です。これは、Bonsai を使用して zkVM のネイティブ STARK プルーフを同等の SNARK プルーフに変換し、そのプルーフをオンチェーンの SNARK バリデータに送信することで機能します。
トランザクション入力を UTF-8 データとして見ると、証明がブロック 17735424 に対応していることがわかります。
Bonsai を使用すると、STARK から SNARK への変換には約 40 秒かかります。 SNARK オンチェーンの検証には 245,129 ガス (執筆時点では約 5.90 ドル) かかりました。
もちろん、zkVM の利点の 1 つは、複数の証明を 1 つに結合できることです。この機能を使用すると、追加のガスを使用せずに証明セット全体をオンチェーンで検証できます。このようにして、オンチェーン検証のコストを証明セット全体に分散し、全員のコストを削減できます。
イーサリアムにとってこれが意味すること
前述したように、イーサリアムは ZK との親和性を念頭に置いて設計されていません。 zkEVM の例が示すように、特にオペコード、デジタル署名、ハッシュ関数に関しては、さまざまな方法で実行できることがたくさんあります。
これらの変更によりパフォーマンスは向上しましたが、変更がなくても安定したパフォーマンスを達成できました。昨年 Vitalik がさまざまなタイプの zkEVM について書いたとき、イーサリアム ブロックの正当性を証明するのに何時間もかかりましたが、今では数分で証明できるようになりました。 ZK のパフォーマンスは急速に向上しており、この傾向は今後数年間続くと信じる理由があります。
付録: Zeth の仕組み
このセクションは開発者向けです。
大まかに言えば、Zeth は完全なノードと同じ方法でブロックを構築します。親ブロック、トランザクション リスト、ブロック作成者から始めて、多くの計算 (署名の検証、トランザクションの実行、グローバル状態の更新など) を実行します。そして最後に新しいブロックのハッシュ値を返します。
ただし、完全なノードとは異なり、これを zkVM で行います。これは、指定されたハッシュを持つブロックが有効であるという ZK 証明を取得できることを意味します。
もちろん、これには課題がないわけではありません。このセクションでは、これらの課題とその対処方法を紹介します。
暗号化
最初の課題は暗号化です。 Ethereum ブロックの構築には多くの作業が必要ですが、その中で最も重要なのはハッシュ化 (Keccak-256) と署名検証 (ECDSA および secp256k1) です。
私たちの zkVM は楕円曲線のサポートを高速化しているため、ECDSA 署名の検証は難しくありません。
しかし、ハッシュに関しては、それほど幸運ではありません。私たちの zkVM は Sha2-256 のサポートを加速しましたが、(執筆時点では) Keccak-256 のサポートは加速していません。したがって、現在は sha3 Rust クレート内の Keccak 実装のみを使用しています。プロファイリングを通じて、これには多くのサイクルが必要であることがわかります。これは最適ではありませんが、zkVM はそれを処理でき、後で Keccak アクセラレータをリサイクルして追加できます。
アカウントとストレージ: パフォーマンスとセキュリティ
イーサリアムでは、アカウントとストレージはグローバル マークル パトリシア トライ (MPT) によって追跡されます。
Etherscan によると、この記事の執筆時点では、ツリーには約 2 億 5,000,000 個の一意のイーサリアム アドレスの状態が含まれていました。これは全体としてはそれほど大きなデータ量ではありませんが、データの保存方法と使用方法に注意を払うには十分です。特に、MPT のパフォーマンスは重要です。
ただし、パフォーマンスが唯一の要素ではなく、セキュリティも考慮する必要があります。
Zeth のブロック ジェネレーターは、zkVM のクライアントとして実行されます。これは、イーサリアム p2p ネットワークや他の RPC プロバイダーに直接アクセスできないことを意味します。代わりに、zkVM の外部で実行される別のプログラムによって提供されるデータに依存する必要があります。
ZK アプリケーションのセキュリティを分析するときは、外部プログラムが悪意のあるものであるため、悪意のあるデータを提供する可能性があることを想定する必要があります。これを防ぐには、ZK アプリケーションは、提供されたデータが有効であることを確認する必要があります。
Zeth ブロック ジェネレーターの場合、これは、関連するすべてのアカウントとストレージ (つまり、指定されたトランザクションのリストを実行するために必要なアカウントとストレージ) の状態を検証することを意味します。
幸いなことに、このようなメカニズムは EIP-1186 によって提供されており、マークルを含めることで特定のアカウント (およびそのストレージ) の状態を証明する標準的な方法が定義されています。
原則として、Zeth のブロック ジェネレーターは、一連の EIP-1186 包含証明を検証することで、アカウントとストレージの状態を検証できます。しかし、このアプローチは理想的ではありません。
代わりに、EIP-1186 の包含証明のデータを使用して部分的な MPT を構築することをお勧めします。これは、特定のトランザクション リストに関連するノードのみを含む MPT のタイプであり、無関係なブランチは対応するハッシュで単純に表されます。部分 MPT は、マークル包含証明の一種の「結合」として考えることも、必要に応じてマークル サブセット証明として考えることもできます。
部分 MPT を検証するプロセスは、基本的に通常の EIP-1186 証明を検証するのと同じです。ルート ハッシュが計算され、親ブロックの状態ルートと比較されます。この 2 つが等しい場合、アカウントとその中のストレージの整合性は信頼できます。
部分的な MPT が検証されると、トランザクションを適用して部分的な MPT を更新できます。新しい状態ルートは、部分 MPT の新しいルート ハッシュ値を計算することで取得できます。
zkVM の Zeth ブロック ジェネレーターは次のようになります。
Zeth ブロック ジェネレーターが完了すると、新しいブロックのハッシュ値が出力されます。
このハッシュには、親ブロックへのコミットメントが含まれるため、親ブロックの状態ルート (元の部分 MPT を検証するために使用されます) が含まれます。これは、悪意のあるバリデータは、無効な親ブロックを提供しない限り、アカウントとストレージに無効なデータを提供できないことを意味します。
言い換えると、親ブロックが有効であれば、Zeth によって生成された新しいブロックも有効になります。
したがって、誰かが新しいブロックと Zeth によって生成された ZK プルーフを渡された場合、次の 3 つのことをチェックすることでブロックの有効性を確認できます。
これらがチェックアウトされている場合、新しいブロックは有効です。
制限事項と今後の改善点
私たちのプロジェクトの目標は、ブロック構築のパフォーマンスを研究することです。このため、範囲をマージされたブロックに限定することにしました。
さらに、Zeth は特定のブロックが有効であることを証明できますが、現時点ではコンセンサス (つまり、ブロックが実際に正規チェーンに含まれていること) を証明することはできません。これは、おそらく zkVM にバリデーターまたは同期委員会の署名のチェックを追加することによって、将来変更される可能性があります。
最後に、Zeth は新しいソフトウェアです。私たちはいくつかのテスト (イーサリアム テスト スイートやさまざまな現実世界のブロックを含む) を実行しましたが、Zeth にはまだいくつかのバグが含まれている可能性があります。この記事の執筆時点では、これは実験的なソフトウェアであると考えるべきです。