著者: Ye Zhang@Scroll

レビューと洞察を提供してくれた Vitalik Buterin、Barry Whitehat、Chih-Cheng Liang、Kobi Gurkan、Georgios Konstantopoulos に感謝します。

長すぎる

私たちは、zk-Rollup が「スイート スポット」になると信じています。そのコスト上の利点と非常に高いセキュリティにより、多くのレイヤー 2 スケーラビリティ ソリューションは比較にならないほど見劣りします。ただし、既存の zk-Rollup 実装はすべてアプリケーション固有であるため、特定の zk-Rollup 内で構成可能な汎用 dApp を構築することは困難であり、既存のアプリケーションを移行することは不可能です。一般的な EVM 検証用にゼロ知識証明を生成する zkEVM を導入します。このようにして、EVM と完全に互換性のある zk-Rollup を構築できるため、既存の Ethereum アプリケーションをこの zk-Rollup に簡単に移行できます。

背景

背景

zk-Rollup は、最高の Ethereum スケーラビリティ ソリューションとして認識されています。セキュリティの点でイーサリアムのレイヤー 1 に匹敵するだけでなく、トランザクションの完了速度の点でもレイヤー 2 ソリューションのリーダーです (詳細な比較分析を表示するには、ここをクリックしてください (原文、翻訳))。

中長期的には、ZK-SNARK テクノロジーの継続的な開発により、zk-rollup はあらゆるアプリケーション シナリオで主導権を握ることになります。 ——ヴィタリック・ブテリン

zk-Rollup の基本原理は、多数のトランザクションを Rollup ブロックにパックし、チェーンからブロックの簡潔な証明を生成することです。レイヤ 1 のスマート コントラクトは、この証明を検証するだけで新しい状態を直接適用でき、これらのトランザクションを再実行する必要はありません。証明の検証コストが再実行の計算コストよりもはるかに低いため、これによりガスが大幅に節約されます。もう 1 つの利点は、データ圧縮によってストレージ スペースを節約できることです (つまり、検証のために最小限のデータのみがオンチェーンに保存される)。

zk-Rollup は安全で効率的ですが、その用途は依然として支払いとスワップに限定されています。汎用 dApp は、次の 2 つの主な理由により構築が困難です。

• まず、zk-Rollup 内で dApp を開発したい場合は、特別な言語 (R1CS など) を使用してすべてのスマート コントラクトのロジックを記述する必要があります。この言語の構文は複雑で、ユーザーはゼロ知識証明に習熟している必要があります。

• 第 2 に、既存の zk-Rollup 実装は composability1 をサポートしていません。したがって、レイヤー 2 では、異なる zk-Rollup アプリケーションは相互に対話できず、DeFi アプリケーションの構成可能性に重大な損害を与えます。

つまり、zk-Rollup は現時点では開発者にとって使いやすいものではなく、機能も限られています。これが私たちが解決したい最大の問題です。私たちは、ネイティブ EVM 検証を直接サポートし、レイヤー 2 でのコンポーザビリティをサポートすることで最高の開発者エクスペリエンスを提供し、既存の Ethereum アプリケーションをそのまま zk-Rollup に移行できるようにしたいと考えています。

zk-Rollup でユニバーサル dApp を構築する

zk-Rollup 内で汎用 dApp を構築するには、次の 2 つの方法があります。

• 1 つは、さまざまな dApp 用にアプリケーション固有の回路 (「ASIC」) を構築することです。

• もう1つは、スマートコントラクトを実行するための汎用「EVM」回路を構築することです。

「回路」とは、ゼロ知識証明で使用されるプログラム表現を指します。たとえば、hash(x) = y を証明したい場合は、ハッシュ関数を回路形式で書き直す必要があります。回路形式は非常に限られた表現のみをサポートします (つまり、R1CS は加算と乗算のみをサポートします)。したがって、回路言語でプログラムを記述することは非常に困難です。すべてのプログラム ロジック (if else、ループなどを含む) を構築するには、加算と乗算しか使用できません。

最初の方法では、開発者はさまざまな dApp 用に専用の「ASIC」回路を設計する必要があります。これは、ゼロ知識証明を使用する最も伝統的な方法です。カスタム回路設計は、個々の dApp のコストを削減するのに役立ちます。ただし、回路は「静的」であり、回路設計の知識への依存度が高いため、開発者のエクスペリエンスが低下するため、これは構成可能性の問題も引き起こします2。

2 番目の方法では、特別な設計は必要なく、開発者が高度な専門知識を持っている必要もありません。このタイプのマシンベースの証明の背後にある基本的な概念は、どのプログラムも最終的には CPU 上で実行されるということです。したがって、低レベルの CPU 動作を検証するには、汎用 CPU 回路を構築するだけで済みます。この CPU 回路を使用して、プログラムの実行を検証できます。この記事のアプリケーション シナリオに関する限り、プログラムはスマート コントラクトを指し、CPU は EVM を指します。しかし、この方法は法外なコストのため、ここ数年は広く採用されていません。たとえば、ある演算の加算結果が正しいことだけを証明したい場合でも、EVM回路全体のコストを負担する必要があります。実行トレースに何千ものオペレーションがある場合、証明者は EVM 回路のコストの 1000 倍を支払います3。

最近、(i) ZKP に適した新しいプリミティブ ポセイドン ハッシュの提案 (ポセイドン ハッシュは回路内で SHA256 よりも 100 倍効率的です)、(ii) 継続的な改善など、これら 2 つの方法を使用した ZKP の最適化に多くの研究が注がれています。 TinyRAM などの汎用の検証可能な仮想マシンの効率、(iii) Plookup などの汎用の最適化技術や、より高速に実行される暗号化ライブラリがますます増えています。

前回の記事では、dApp ごとに「ASIC」回路を設計し、暗号化コミットメントを介して通信させることを提案しました。ただし、コミュニティからのフィードバックに基づいて、私たちは研究の焦点を変更し、2 番目のアプローチを使用して汎用 EVM 回路 (いわゆる「zkEVM」) を構築することに焦点を当てます。 zkEVM は、レイヤー 1 とまったく同じ開発エクスペリエンスをもたらします。設計の複雑さを開発者に任せるのではなく、効率の問題に対処するためにカスタム EVM 回路設計に置き換えます。

zkEVM の設計上の課題

zkEVM は構築が困難です。この直感は何年も前から明らかですが、ネイティブ EVM 回路の構築に成功した人はまだいません。 TinyRAM とは異なり、zkEVM は次の理由から設計と実装がより困難です。

• まず、EVM では楕円曲線のサポートが制限されています。現在、EVM は BN254 ペアリングのみをサポートしています。 EVM は循環楕円曲線を直接サポートしていないため、再帰的に実装するのは困難です。この設定では、他の独自のプロトコルを使用することも困難です。検証アルゴリズムは EVM フレンドリーである必要があります。

• 次に、EVM のワード サイズは 256 ビットです。 EVM は 256 ビット整数で実行され (ほとんどの一般的な仮想マシンが 32 ～ 64 ビット整数で実行されるのと同様)、ゼロ知識証明は「自然に」素数フィールドで実行されます。回路内で「不一致ドメイン演算」を実行するには範囲証明が必要であり、これにより各 EVM 演算に約 100 個の制約が追加されます。これにより、EVM 回路のサイズが 2 桁増加します。

• 第三に、EVM には多くの特別なオペコードがあります。従来の仮想マシンとは異なり、EVM には CALL などの特殊なオペコードや、実行環境やガスに関連するエラー タイプが多数あります。これは回路設計に新たな課題をもたらすでしょう。

• 4 番目に、EVM はスタックベースの仮想マシンです。 SyncVM (zksync) および Cario (starkware) アーキテクチャは、レジスタベースのモデルで独自の IR/AIR を定義します。彼らは、スマート コントラクト コードを新しいゼロ知識証明に適した IR にコンパイルするための専用のコンパイラーを構築しました。この方法は言語互換性がありますが、ネイティブ EVM 互換性はありません。スタックベースのモデルを証明するか、ネイティブ ツールチェーンを直接サポートするかは、より困難になります。

• 第 5 に、イーサリアムのストレージ レイアウトは高コストをもたらします。イーサリアムのストレージ レイアウトは Keccak と巨大な MPT4 に大きく依存しています。どちらもゼロ知識証明には適しておらず、証明コストが高くなります。たとえば、ケチャック ハッシュの回路サイズは、ポセイドン ハッシュの 1000 倍です。ただし、Kecck ハッシュを別のハッシュに置き換えると、既存の Ethereum インフラストラクチャとの互換性の問題が発生します。

• 第 6 に、機械ベースの証明には高いコストがかかります。上記のすべてを処理できたとしても、それらを組み合わせて完全な EVM 回路を得る効率的な方法を見つける必要があります。前のセクションで述べたように、add のような単純なオペコードであっても、EVM 回路全体にコストがかかる可能性があります。

zkEVM が今日可能になった理由

研究者らによる大幅な進歩のおかげで、過去 2 年間で効率の問題がますます解決され、zkEVM の実証コストはついに障害ではなくなりました。主な技術的進歩は次の側面に反映されています。

• 多項式コミットメントの使用。過去数年間の簡潔なゼロ知識証明プロトコルのほとんどは R1CS を使用しており、PCP クエリはアプリケーション固有の信頼できるセットアップにエンコードされています。これにより、回路のサイズが増大する傾向があり、各制約は次数 2 でなければならないため、多くのカスタム最適化が不可能になります (双線形ペアリングでは指数乗算の計算が 1 回しか許可されません)。多項式コミットメント スキームを使用すると、ユニバーサル セットアップまたは透過的なセットアップを通じて任意の次数に対する制約を増やすことができ、バックエンド選択の柔軟性が大幅に向上します。

• ルックアップ テーブル パラメータとカスタム ウィジェットの外観。もう 1 つの重要な最適化は、ルックアップ テーブルの使用です。この最適化は最初に Arya で提案され、その後 Plookup で実装されました。ゼロ知識証明 (つまり、AND や XOR などのビット単位の演算) に適さないプリミティブの場合、ルックアップ テーブルを使用すると多くの作業を節約できます。カスタム ウィジェットは、高レベルの制約を効率的に実装できます。 TurboPlonk と UltraPlonk は、ルックアップ テーブルの使用とカスタム ウィジェットの定義の難しさを軽減する洗練されたプログラム構文を定義します。これは、EVM 回路のコスト削減に大きく役立ちます。

• 再帰的証明の実現可能性はますます高くなっています。以前は、再帰的証明は、ペアリングに適した特別な円楕円曲線 (つまり、MNT 曲線ベースの構造) に依存していたため、コストがかかりました。これには、高い計算コストがかかります。ただし、効率を犠牲にすることなく再帰的証明を可能にする手法が増えています。たとえば、Halo はペアに適した曲線を必要とせず、特別な内積パラメーターを使用して再帰コストを償却することもできます。 Aztec は、既存のプロトコルから直接集約できる証明を証明します (ルックアップ テーブルにより非ネイティブ ドメイン操作のコストが削減され、それによって検証回路のサイズが削減されます)。同じ回路規模でより多くの機能を実現できるようになりました。

• ハードウェアアクセラレーションにより証明効率が向上しています。私たちの知る限り、当社は証明プログラム用に最速の GPU および ASIC/FPGA アクセラレータを構築しました。 ASICの証明手順に関する論文が今年、コンピュータ学会のトップであるISCAに採択されました。私たちの GPU 証明者は Filecoin の実装よりも約 5 ～ 10 倍高速であり、証明者の計算効率を大幅に向上させることができます。

zkEVM はどのように動作し、構築されますか?

強い直観と技術的な改善に加えて、何を証明する必要があるのか​​を見つけ出し、より具体的なアーキテクチャを構想する必要があります。技術的な詳細と比較分析については、今後の記事で取り上げます。この記事では、ワークフロー全体といくつかの中心的な概念を紹介します。

開発者とユーザーのワークフロー

開発者はEVM互換言語を使用してスマートコントラクトを実装し、コンパイルされたバイトコードをScrollにデプロイできます。その後、ユーザーはトランザクションを送信して、展開されたスマート コントラクトと対話できるようになります。ユーザーと開発者はレイヤー 1 と同じエクスペリエンスを得ることができます。ただし、ガス料金は大幅に安くなり、取引は Scroll 上で即座に事前確認されます (出金が完了するまでにわずか数分しかかかりません)。

zkEVMのワークフロー

外部ワークフローは同じですが、レイヤー 1 とレイヤー 2 の基礎となる処理は完全に異なります。

• レイヤ 1 はスマート コントラクトの再実行に依存しています。
• レイヤ 2 は、zkEVM 回線の有効性の証明に依存します。

レイヤ 1 とレイヤ 2 のトランザクションがどのように異なるのかを詳しく説明します。

レイヤ 1 では、デプロイされたスマート コントラクトのバイトコードがイーサリアム ストレージ (ストレージ アイテム) に保存されます。トランザクションはピアツーピア ネットワーク内で伝播されます。各トランザクションについて、各フル ノードは対応するバイトコードをロードし、それを EVM 上で実行して同じ状態を取得する必要があります (トランザクションは入力データとして使用されます)。

レイヤ2でもバイトコードが格納項目に格納され、ユーザーは同様に操作します。トランザクションはオフチェーンで集中型の zkEVM ノードに送信されます。次に、zkEVM はバイトコードを実行するだけでなく、トランザクション後に状態が正しく更新されたことを示す簡潔な証拠を生成します。最後に、レイヤー 1 コントラクトは証明を検証し、トランザクションを再実行せずに状態を更新します。

実行を深く掘り下げて、zkEVM が最終的に何を証明する必要があるかを見てみましょう。ネイティブ実行では、EVM はバイトコードをロードし、バイトコード内のオペコードを 1 つずつ最初から実行します。各オペコードは、次の 3 つのステップを実行すると見なされます: (i) スタック (スタック)、メモリ、またはストレージ項目から要素を読み取ります。(ii) これらの要素に基づいて計算を実行します。(iii) 結果をスタックに書き込みます。メモリまたはストレージ項目5.たとえば、add オペコードはスタックから 2 つの要素を読み取り、それらを追加し、結果をスタックに書き込む必要があります。

したがって、zkEVM の証明には次の側面 (実行フローに相当) を含める必要があることは明らかです。

• バイトコードが永続ストレージから正しくロードされている (アドレスからロードされた正しいオペコードを実行している)
• バイトコード内のオペコードは常に 1 つずつ実行されます (バイトコードは順番に実行され、オペコードの欠落やスキップはありません)。
• すべてのオペコードが正しく実行されます (各オペコード内の 3 つのサブオペが正しく実行されます (R/W + 計算))

zkEVM 設計のハイライト

zkEVMのアーキテクチャを設計する際には、上記の3つの要件をそれぞれ満たすための対策を講じる必要があります。

1. 暗号アキュムレータの回路を設計する必要があります。

これは「検証可能な記憶」として機能するため、読み取りプロセスが正確であることを証明する何らかのテクノロジーが必要です。暗号アキュムレータはこれをより効率的に実行できます6。例としてマークル ツリーを見てみましょう。デプロイされたバイトコードは、マークル ツリー上のリーフ ノードとして保存されます。検証者は、簡潔な証明を使用して、このバイトコードがアドレスから正しくロードされたことを検証できます (つまり、回路内のマークル パスを検証します)。イーサリアム ストレージの場合、この回路がマークル パトリシア ツリーとケチャック ハッシュ関数の両方と互換性がある必要があります。

2. バイトコードと実際の実行トレースを関連付ける回路を設計する必要があります。

バイトコードを静的回路に移動すると問題が発生します。ジャンプのような条件付きオペコード (スマート コントラクトのループや if else ステートメントとは対照的に) はどこにでもジャンプする可能性があります。ジャンプ先は、誰かが特定の入力でそのバイトコードを実行するまで定義されません。そのため、実際の実行トレースを確認する必要があります。実行トレースは、実際に実行された順序でオペコードを含む「展開されたバイトコード」と考えることができます (つまり、別の場所にジャンプすると、そのターゲットのオペコードと場所がトレースに含まれます)。

証明者は、回路の証人データとして実行トレースを直接提供します。実行トレースが、特定の入力を含む特定のバイトコードによって実際に「展開」されることを証明する必要があります。目的は、プログラム カウンタの値を強制的に一貫させることです。宛先が不明な問題の解決策は、証明者にすべてのデータの提供を依頼することです。その後、ルックアップ パラメータを使用して一貫性を効率的にチェックできます (つまり、正確なグローバル カウンタを持つオペコードが「バス」に含まれていることを証明できます)。

3. 各オペコードの回路を設計する必要があります (各オペコードの読み取り、書き込み、計算が正しいことを証明するため)。

これは最も重要な部分であり、実行トレース内の各オペコードが正しく、一貫性があることを証明します。ただ全部揃えるとなると、かなりの費用がかかってしまいます。ここでの重要な最適化のアイデアは次のとおりです。

• R/W と計算を 2 つの証明に分けることができます。証明では、オペコードによって使用されるすべての要素が「バス」上に配置されます。別の証明は、「バス」上の要素の計算が正しく実行されたことを証明します。これにより、部品あたりのコストが大幅に削減されます (つまり、計算証明を生成するときに EVM ストレージ全体を考慮する必要がなくなります)。より詳細な仕様では、前者は「Proof of State」と呼ばれ、後者は「Proof of EVM」と呼ばれます。もう 1 つの発見は、lookup ステートメントが「バス マッピング」を効率的に処理できることです。

• 各オペコードに対してさらにカスタマイズされた制約を設計できます (つまり、より効率的な処理のために EVM ワードを複数のデータ ブロックに分割できます)。選択多項式を通じてオンデマンドで制約を「オン」にするかどうかを選択できます。これにより、各操作で EVM 回路全体を消費するコストが回避されます。

もともとイーサリアム財団によって提案されたこのアーキテクチャはまだ初期段階にあり、活発に開発中です。私たちはイーサリアム財団と緊密に協力して、この EVM 回路を実装する最適な方法を見つけています。これまでのところ、EVM 回路の最も重要な機能を定義し、(Halo2 ライブラリの UltraPlonk 構文を使用して) いくつかのオペコードを実装しました (表示するにはここをクリックしてください)。詳しい内容は次回以降の記事で紹介していきます。興味のある読者はこのドキュメントを読むことをお勧めします。開発プロセスは透明になります。これは、コミュニティ全体が結集した完全なオープンソースの設計になります。より多くの人が参加し、貢献してくれることを願っています。

zkEVM は他に何をもたらすのでしょうか?

zkEVM はレイヤ 2 スケーリングをはるかに超えています。これは、レイヤー 1 の有効性証明を通じてイーサリアム レイヤー 1 を拡張する簡単な方法として理解できます。これは、既存のレイヤー 1 を特別なレイヤー 2 なしで拡張できることを意味します。

結論は

結論は

私たちについて

私たちについて

注記：

注記：

1. コンポーザビリティは、Starkware の 2021 年 9 月 1 日の発表で実現されました (発表を表示するにはここをクリックしてください)。

2. 回路は固定されており、静的です。たとえば、プログラムを回路として実装する場合、可変上限ループは使用できません。上限は最大値に固定する必要があります。回路は動的ロジックを処理できません。

3. 読者の便宜のために、ここでは EVM 回路のコストを詳しく説明します。前述したように、回路は固定されており、静的です。したがって、EVM 回路には、考えられるすべてのロジックを含める必要があります (このボリュームは、加算のみを含む回路の 10000 倍になります)。これは、たとえ加算を証明したいだけであっても、この EVM 回路に含まれるすべてのロジックのコストを負担しなければならないことを意味します。つまり、コストは 10,000 倍になります。実行トレースでは、一連のオペコードを証明する必要があり、各オペコードには高いコストがかかります。

4. EVM 自体はマークル パトリシア ツリー (MPT) に厳密にバインドされていません。現在、MPT はイーサリアムの状態を保存するためにのみ使用されます。置き換えは簡単です (MPT の置き換えに Verkle ツリーを使用することを提案する人もいます)。

5. これは非常に単純化された抽象化です。技術的には、「EVM 状態」のリストはさらに長く、プログラム カウンター、ガス ヘッドルーム、コール スタック (上記のすべてに加え、スタック内の各コールのアドレスと静的情報)、一連のログ、およびトランザクション スコープの変数 (ホット ストレージ スロット) が含まれます。 、返金、自爆）。さらに、さまざまな呼び出し環境の識別子を導入して、構成可能性を直接サポートできます。

6. ストレージが大きいため、ストレージにはアキュムレータを使用します。メモリとスタックは Plookup を使用して編集できます (この方法で「RAM」を効果的に実装できます)。

7. 元のリンク:

元のリンク:

https://hackmd.io/@yezhang/S1_KMMbGt