Scroll の共同創設者である Zhang Ye は 4 つのパートに分けて講演し、最初のパートでは開発の背景、そもそもなぜ zkEVM が必要なのか、そしてなぜそれが過去 2 年間で非常に人気になったのかを紹介しました。完全なプロセスを通じてその方法を説明しました。ゼロからの zkEVM の構築には、算術システムと証明システムが含まれます。第 3 部では、興味深い調査質問を通じて zkEVM を構築するときに Scroll が遭遇した問題について説明し、最後に zkEVM を使用する他のアプリケーションをいくつか紹介します。
従来のレイヤー 1 ブロックチェーンには、P2P ネットワークを通じていくつかのノードが一緒に維持されます。ユーザーのトランザクションを受信すると、それを EVM 仮想マシンで実行し、呼び出し元のコントラクトとストレージを読み取り、トランザクションに従ってグローバル ステート ツリーを更新します。
このようなアーキテクチャの利点は分散化とセキュリティです。欠点は、L1 でのトランザクション手数料が高く、トランザクションの確認が遅いことです。
ZK-Rollup アーキテクチャでは、L2 ネットワークはデータと証明を L1 にアップロードするだけでデータの正しさを検証でき、証明はゼロ知識証明回路を通じて計算されます。
初期の ZK-Rollup では、回路は特定のアプリケーション向けに設計されており、ユーザーはトランザクションをさまざまな証明者に送信する必要があり、その後、さまざまなアプリケーションの ZK-Rollup が独自のデータと証明を L1 に送信しました。これによってもたらされる問題は、元の L1 コントラクトの構成可能性が失われることです。
Scroll が行うのは、汎用の ZK-Rollup であるネイティブ zkEVM ソリューションです。これはユーザーフレンドリーであるだけでなく、開発者に L1 でのより良い開発エクスペリエンスを提供します。もちろん、この背後にある開発は非常に困難であり、現在の証明生成のコストも非常に高くなります。
幸いなことに、ゼロ知識証明の効率は過去 2 年間で大幅に向上しました。これが、zkEVM が過去 2 年間で非常に人気になった理由です。それが実現可能になる理由は少なくとも 4 つあります。1 つ目は、元の Groth16 証明システムでは制約の規模が非常に大きかったのですが、多項式のコミットメントによって高次の制約がサポートされ、その規模が縮小されることです。 2 番目は、ルックアップ テーブルとカスタム ゲートの出現により、より柔軟な設計がサポートされ、より効率的な証明が可能になります。3 番目は、GPU、FPGA、ASIC によって証明時間を 1 ～ 2 桁短縮できるハードウェア アクセラレーションの画期的な進歩です。 4 番目の再帰的証明では、複数の証明を 1 つの証明に圧縮でき、証明が小さくなり、検証が容易になります。これら 4 つの要素を組み合わせると、ゼロ知識証明の生成効率は 2 年前に比べて 3 桁も向上しました。これが Scoll の起源でもあります。
Justin Drake の定義によれば、zkEVM は 3 つのカテゴリに分類できます。最初のカテゴリは言語レベルの互換性です。主な理由は、EVM が ZK 用に設計されておらず、ZK にとって不向きなオペコードが多数あるためです。追加のオーバーヘッドが大量に発生します。したがって、Starkware や zkSync などの企業は、Solidity または Yul を言語レベルで ZK フレンドリーなコンパイラーにコンパイルすることを選択しています。
2つ目はScrollが行っているバイトコードレベルの互換性で、EVMのバイトコード処理が正しいかどうかを直接証明し、イーサリアムの実行環境を直接継承します。ここでのトレードオフとしては、ZK に適したデータ構造を使用するなど、EVM とは異なるステート ルートを使用することが挙げられます。 Hermez と Consensys も同様のことを行っています。
3 番目のカテゴリはコンセンサス レベルでの互換性です。ここでのトレードオフは、EVM を変更しないだけでなく、イーサリアムとの完全な互換性を実現するためにストレージ構造も含める必要があることですが、その代わりに検証時間が長くなります。 Scroll は、イーサリアムの ZK 化を実現するために、イーサリアム財団の PSE チームと協力して構築されています。
2 番目のパートでは、Zhang Ye が ZKVM をゼロから構築する方法を全員に示しました。
完全なプロセス
まず、ZKP のフロントエンド部分では、算術演算を通じて計算を表現する必要があります。最も一般的に使用されるのは、Plonkish および AIR と同様に線形 R1CS です。算術演算によって制約を取得した後、ZKP のバックエンドで証明アルゴリズムを実行して、計算の正しさを証明する必要があります。最も一般的に使用される多項式インタラクティブ オラクル証明 (多項式 IOP) と多項式コミットメント スキーム (PCS) を次に示します。
ここでは、zkEVM と Scroll が Plonkish、Plonk IOP、および KZG の組み合わせを使用していることを証明する必要があります。
これら 3 つのソリューションを使用する理由を理解するため。まず、最も単純な R1CS から始めます。R1CS の制約は、線形結合と線形結合の積が線形結合と等しいということです。追加のオーバーヘッドなしで変数の線形結合を追加できますが、各制約の最大次数は 2 です。したがって、高次の演算では、より多くの制約が必要になります。
Plonkish では、入力、出力、中間変数の証人を含むすべての変数をテーブルに入力する必要があります。これに加えて、さまざまな制約を定義できます。 Plonkish では 3 種類の制約が使用できます。
1 つ目のタイプの制約はカスタム ゲートです。va3 * vb3 * vc3 - vb4 =0 など、さまざまなセル間の多項式制約関係を定義できます。 R1CS と比較すると、任意の変数に制約を定義でき、いくつかの非常に異なる制約を定義できるため、次数が高くなる可能性があります。
2 番目のタイプの制約は置換、つまり等価性チェックです。これは、異なるセルの等価性をチェックするために使用でき、前のゲートの出力が次のゲートの入力と等しいことを証明するなど、回路内の異なるゲートを関連付けるためによく使用されます。
最後のタイプの制約はルックアップ テーブルです。ルックアップ テーブルは、テーブルとして表現できる変数間の関係として理解できます。たとえば、vc7 が 0 ～ 15 の範囲にあることを証明するには、R1CS ではまずこの値を 4 ビットのバイナリに分解し、次に各ビットが 0 ～ 1 の範囲にあることを証明する必要があります。 4 つの制約が必要になります。 Plonkish では、同じ列内のすべての可能な範囲をリストすることができ、vc7 がその列に属していることを証明するだけで済みます。これは、範囲の証明に非常に効率的です。zkEVM では、ルックアップ テーブルはメモリの読み取りと書き込みを証明するのに非常に役立ちます。
要約すると、Plonkish はカスタム ゲート、等価性チェック、ルックアップ テーブルもサポートしており、さまざまな回路のニーズを満たすために非常に柔軟です。 STARK の単純な比較。STARK の各行は制約です。制約は行間の状態遷移を表す必要がありますが、Plonkish のカスタム制約の方が明らかに柔軟性が高くなります。
ここで問題となるのは、zkEVM でフロントエンドをどのように選択するかです。 zkEVM には 4 つの主な課題があります。最初の課題は、EVM のフィールドが 256 ビットであることです。これは、変数を効率的に範囲制約する必要があることを意味します。2 つ目の課題は、EVM には ZK に適さないオペコードが多数あるため、これらの演算を証明するには非常に大規模な制約が必要であることです。 Keccak-256 などのコード。3 番目の課題はメモリの読み取りと書き込みの問題です。読み取った内容が以前に書き込んだ内容と一致していることを証明するための効果的なマッピングが必要です。4 番目の課題は、EVM の実行トレースです。は動的に変化するため、さまざまな実行トレースに適応するカスタム ゲートが必要です。上記を考慮して Plonkish を選択しました。
次に、最初のグローバル状態ツリーに基づいて、新しいトランザクションが到着すると、EVM は保存され呼び出されたコントラクトのバイトコードを読み取り、トランザクションに基づいて対応する実行トレースを生成します。 PUSH、PUSH、STORE、CALLVALUE を実行し、トランザクション後にグローバル状態ツリーを取得するためにグローバル状態を徐々に更新します。 zkEVM は、初期グローバル状態ツリー、トランザクション自体、およびトランザクション後のグローバル状態ツリーを入力として受け取り、EVM 仕様を使用して実行トレースの正確さを証明します。
EVM 回路の詳細を詳しく調べると、実行トレースの各ステップには対応する回路制約があります。具体的には、各ステップの回路制約には、Step Context、Case Switch、Opcode Specific Witness が含まれます。ステップ コンテキストには、実行トレースに対応するコードハッシュ、残りのガス、およびカウンターが含まれます。ケース スイッチには、すべてのオペコード、すべてのエラー条件、およびステップの対応する操作が含まれます。オペコード固有の監視には、オペランド待機などのオペコードに必要な追加の監視が含まれます。
単純な加算を例にとると、加算オペコードの制御変数 sADD が 1 に設定され、他のオペコードの制御変数がすべて 0 であることを確認する必要があります。ステップ コンテキストでは、ガス' - ガス - 3 = 0 を設定することで、消費されるガスは 3 に等しくなるように制限されます。同様に、カウンタは、ステップの後に、次の合計である 1 に制限されます。変数はオペコードを通じて 1 に制御されます。このステップを加算演算に制限するには、オペコード固有の監視でオペランドの実際の加算を制限します。
さらに、メモリから読み取られるオペランドの正確性を保証するには、追加の回路制約が必要です。ここではまず、オペランドがメモリに属していることを証明するためにルックアップ テーブルを構築する必要があります。そしてメモリ回路(RAM回路)を通してメモリテーブルの正当性を検証します。
同じ方法を zk 非フレンドリーなハッシュ関数に適用して、ハッシュ関数のルックアップ テーブルを作成し、実行トレースのハッシュ入力と出力をルックアップ テーブルにマッピングし、追加のハッシュ回路を使用してハッシュ関数を検証します。ルックアップテーブルの正確さ。
ここで、zkEVM の回路アーキテクチャを見てみましょう。コア EVM 回路は、EVM 回路の制約が難しい場所で、Fixed Table、Kecchak などのルックアップ テーブルを使用して、実行トレースの各ステップの正確さを制約します。テーブル、RAM テーブル、バイトコード、トランザクション、ブロック コンテキスト、およびこれらのルックアップ テーブルを制約する別の回路 (Kecck テーブルを制約する Keccak 回路など) を使用します。
要約すると、zkEVM の完全なワークフローを次の図に示します。
証明システム
前述のEVM回路やメモリ回路、ストレージ回路などをL1上で直接検証するのはコストがかかるため、Scroll社の証明システムは2層アーキテクチャを採用している。
最初の層は EVM 自体を直接証明する役割を担っており、証明を生成するには大量の計算が必要です。したがって、第 1 レベルの証明システムには、カスタム ゲートとルックアップ テーブルをサポートし、ハードウェア アクセラレーションに対応し、低ピーク メモリで並列計算を生成し、迅速に検証できる小規模な検証回路が必要です。有望な代替案には、Plonky2、Starky、eSTARK が含まれます。これらはすべて、基本的にフロントエンドで Plonk を使用しますが、バックエンドで FRI を使用する可能性があり、すべて上記の 4 つの特性を満たしています。別のタイプの代替ソリューションには、Zcash によって開発された Halo2 と Halo2 の KZG バージョンが含まれます。
最近 FFT を削除した HyperPlonk など、有望な新しい証明システムもいくつかあり、NOVA 証明システムは小規模な再帰証明を実現できます。しかし、彼らは研究においてのみ R1CS をサポートしています。将来 Plonkish をサポートし、実際に適用できれば、それは非常に実用的で効率的になるでしょう。
第 2 レベルの証明システムは、第 1 レベルの証明の正しさを証明するために使用され、EVM で効率的に検証される必要があり、理想的には、ハードウェア アクセラレーションに対応し、透過的またはユニバーサルなセットアップをサポートする必要があります。有望な代替案には、Groth16 やカラムレスの Plonkish 証明システムなどがあります。 Groth16 は現在の研究においても非常に高い証明効率を示す代表的なものであり、Plonkish 証明システムも少ないカラム数でも高い証明効率を達成できます。
Scroll では、両方の 2 層証明システムで Halo2-KZG 証明システムを使用しています。 Halo2-KZG はカスタム ゲートとルックアップ テーブルをサポートできるため、GPU ハードウェア アクセラレーション下で優れたパフォーマンスを発揮し、検証回路のサイズが小さく、迅速に検証できます。違いは、証明効率をさらに向上させるために第 1 層の証明システムでポセイドン ハッシュを使用するのに対し、第 2 層の証明システムではイーサリアム上で直接検証されるため引き続き Keccak ハッシュを使用することです。 Scroll は、第 2 レベルの証明システムによって生成された集約証明をさらに集約するための多層証明システムの可能性も模索しています。
現在の実装では、Scroll の第 1 レベルの証明システムの EVM 回路には 116 列、2496 のカスタム ゲート、50 のルックアップ テーブルがあり、最高次数は 9 で、1M ガスの下で 2^18 ラインが必要ですが、第 2 レベルの証明システムには集約回路には 23 列、1 つのカスタム ゲート、7 つのルックアップ テーブルしかなく、最上位は 5 です。EVM 回路、メモリ回路、およびストレージ回路を集約するには、2^25 行が必要です。
Scroll は、GPU ハードウェア アクセラレーションに関する多くの研究と最適化作業も行っています。EVM 回路の場合、最適化された GPU 証明者は 30 秒しかかかりません。これは、最適化後の CPU 証明者よりも 9 倍効率的です。所要時間は 149 秒で、CPU よりも 15 倍効率的です。現在の最適化条件では、1M Gas の第 1 レベルの証明システムには約 2 分、第 2 レベルの証明システムには約 3 分かかります。
第 3 部では、Zhang Ye が、フロントエンドの算術回路から証明器の実装に至るまで、Scroll の zkEVM 構築プロセスにおけるいくつかの興味深い研究課題について話しました。
回路
1 つ目は、回路内のランダム性です。EVM フィールドは 256 ビットであるため、範囲証明をより効率的に実行するには、それを 32 個の 8 ビット フィールドに分割する必要があります。次に、ランダム線形結合 (RLC) メソッドを使用して、乱数を使用して 32 フィールドを 1 にエンコードします。このフィールドを検証するだけで、元の 256 ビット フィールドが検証されます。ただし、問題は、乱数が改ざんされないようにフィールドを分割した後に生成する必要があることです。したがって、Scroll と PSE チームは、フィールド分割後に乱数を使用して RLC を生成するための多段階証明者ソリューションを提案しました。このソリューションは Challenge API にカプセル化されています。 RLC には、zkEVM に多くのアプリケーション シナリオがあります。EVM フィールドを 1 つのフィールドに圧縮できるだけでなく、可変長入力を暗号化したり、ルックアップ テーブルのレイアウトを最適化したりすることもできます。ただし、解決すべき未解決の問題がまだ多くあります。
回路に関する 2 番目の興味深い研究課題は、回路レイアウトです。 Scroll フロントエンドが Plonkish を使用する理由は、EVM の実行トレースは動的に変化し、さまざまな制約や変化する等価性テストをサポートできる必要があるのに対し、R1CS の標準化されたゲートは実装に大きな回路規模を必要とするためです。ただし、Scroll は現在、動的に変化する実行トレースに対応するために 2,000 を超えるカスタム ゲートを使用しており、オペコードをマイクロ オペコードに分割したり、同じテーブル内のセルを再利用したりするなど、回路レイアウトをさらに最適化する方法も模索しています。
回路における 3 番目の興味深い研究課題は、ダイナミック スケーリングです。オペコードごとに回路規模は異なりますが、動的に変化する実行トレースに対応するには、各ステップのオペコードがケチャックハッシュなどの最大回路規模を満たす必要があり、実際には余分なオーバーヘッドがかかっています。動的に変化する実行トレースに zkEVM を動的に適応させることができれば、不必要なオーバーヘッドが節約されます。
証明者
証明者に関しては、Scroll は GPU アクセラレーションの点で MSM と NTT に対して多くの最適化を行ってきましたが、ボトルネックはデータの生成とコピーを監視することに移行しました。 MSM と NTT が証明時間の 80% を占めると想定されているため、ハードウェア アクセラレーションによってこの効率が数桁向上したとしても、証人の生成とデータのコピーにかかる本来の 20% の証明時間が新たなボトルネックになります。証明者に関するもう 1 つの問題は、大量のメモリを必要とするため、より安価でより分散化されたハードウェア ソリューションを検討する必要があることです。
同時に、Scroll は証明者の効率を向上させるためのハードウェア アクセラレーションと証明アルゴリズムも研究しています。現在、主な方向性は 2 つあり、64 ビットの Goldilocks ドメインや 32 ビットの Mersenne Prime などのより小さなドメインに切り替えるか、SuperNova などの楕円曲線に基づく新しい証明システムに固執するかのいずれかです。 。もちろん、他にも考えられる方法はあります。アイデアのある友人は Scroll に直接連絡することを歓迎します。
安全性
zkEVM を構築する場合、セキュリティが最も重要です。 PSE と Scroll が共同で構築した zkEVM には約 34,000 行のコードが含まれており、ソフトウェア エンジニアリングの観点から見ると、これらの複雑なコード ベースに長期間にわたって脆弱性が存在しないことは不可能です。 Scroll は現在、業界トップの監査会社からの監査を含む多数の監査を通じて zkEVM コード ベースをレビューしています。
パート 4 では、zkEVM を使用する他のアプリケーションについて説明します。
zkRollup アーキテクチャでは、L2 の n 個のトランザクションが L1 のスマート コントラクトを通じて有効であることを検証します。
L1 ブロックを直接検証する場合、L1 ノードはトランザクションを繰り返し実行する必要はなく、各ブロック証明書の有効性を検証するだけで済みます。このようなアーキテクチャ上のソリューションは、Enshrine Blockchain と呼ばれます。現時点では、イーサリアム ブロック全体を検証する必要があり、これには多数の署名の検証が含まれるため、イーサリアム上に直接実装することは非常に困難であり、結果として検証時間が長くなり、セキュリティが低下します。もちろん、Mina など、再帰的証明を使用して単一の証明を使用してブロックチェーン全体を検証するパブリック チェーンは他にもすでにいくつかあります。
zkEVM は状態遷移を証明できるため、ホワイトハットが特定のスマート コントラクトの脆弱性を知っていることを証明し、プロジェクト関係者から報奨金を求めるために使用することもできます。
最後の使用例は、ゼロ知識証明を通じて履歴データに関する主張を証明し、それを Axiom が現在この分野で製品を作成しているオラクルとして使用することです。最近の ETHBeijing Hackathon で、GasLockR チームはこの機能を利用して、歴史的な Gas オーバーヘッドを証明しました。
最後に、Scroll は、非常に高度な算術回路と証明システムを使用して、再帰を証明するためのハードウェア アクセラレーションによる高速検証器を構築して、イーサリアム用の zkRollup のユニバーサル スケーリング ソリューションを構築しています。現在、アルファ テスト ネットワークはオンラインであり、長期間にわたって安定して実行されています。
もちろん、プロトコル設計やメカニズム設計、ゼロ知識エンジニアリング、実際の効率など、解決すべき興味深い問題がまだいくつかあります。ぜひ Scroll に参加して一緒に構築してください。
