zkSync2.0 メインネットのローンチに際して、各種 zkEVM の分析
各種ZK RollupのzkEVMは、多くの性能の中で妥協があり、実際には絶対的な優劣はありません。著者：IOBC Capital
イーサリアムの発展の道筋は、モジュラーブロックチェーンにますます傾いており、その本質はLayer1のデータシャーディングとLayer2のロールアップの拡張を組み合わせたモジュール化アーキテクチャであり、イーサリアムが「世界コンピュータ」を実現するという本来の目的を推進しています。その中で、ロールアップの技術的な選択肢として、ZKロールアップがイーサリアムの拡張の最終目標と見なされています。
ZKロールアップ
ZKロールアップの核心的な作業メカニズムは、チェーン上のユーザー状態をメルクルツリーに圧縮して保存し、ユーザー状態の変更をオフチェーンで行い、zksnark/zkstark証明を通じてそのオフチェーンのユーザー状態変更プロセスの正当性を保証することです。一般的に理解すると、ZKロールアップはzksnarkまたはzkstarkを使用して、線形の数のステートメントを検証するために亜線形処理を利用することができます。例えば、1000のステートメントには10回の検証者のチェックが必要で、10000のステートメントには11回の検証者のチェックが必要です。したがって、ZKロールアップはイーサリアムの拡張を実現することができます。
ZKロールアップの大まかなブロックチェーン取引処理プロセスは以下の通りです：
- ユーザーはL1のzkロールアップスマートコントラクトに資産をロックします；
- ユーザーはこれらの資産に関する取引をL2に提出し、L2内の特定の役割（シーケンサー、初期の多くのプロジェクトは中央集権的であり、最近は分散型の方法を採用するプロジェクトもあります）がこれらの取引を特定のルールに従って順序付けられたバッチに収集し、各バッチの有効性証明（zksnark/zkstark）と集約状態更新を生成します；
- この状態更新と証明がL1のzkロールアップスマートコントラクトに提出され、検証されると、L1のブロックチェーンが更新されます；
- ユーザーはこのL1状態（異なるデータ可用性メカニズムに依存）を使用して資産を取得できるため、完全な自己管理を実現します。したがって、zkロールアップはイーサリアムのセキュリティを引き継いでいるとも見なされています。
zkEVMの必要性
ご存知の通り、第一世代のZKロールアップはEVMをサポートしておらず、プログラマビリティとコンポーザビリティが低いため、特定のシナリオに限定されています。例えば、LoopringはPayments&Swapsなどのシナリオに限定され、ImmutableはNFT Minting&Trading&Gamesなどのシナリオに限定され、zksync1.0も実際にはzkEVMをサポートしていません。汎用性がありません。
その後、主要なZKロールアップは、ZKロールアップ上でEVMバイトコードをサポートするコード実行環境を開発することを探求し、イーサリアム上のスマートコントラクトがイーサリアムからZKロールアップに移行できるようにしました。
EVMは最初のチューリング完全なブロックチェーン仮想マシンであり、2015年にリリースされました。これは、これまでで最も実績のあるブロックチェーン仮想マシンであり、イーサリアムにとって非常に重要なスマートコントラクトインフラです。他のブロックチェーンについて話すときにも、EVMの互換性が評価基準の一つとして扱われます。なぜなら、EVM互換性の背後には、スマートコントラクト実行環境だけでなく、利用可能なイーサリアムエコシステムやツールセット、さらには無視できないネットワーク効果があるからです。したがって、ZKロールアップもこの部分を無視することはできませんでした。
zkEVMは、EVMをスマートコントラクトエンジンとしてZKロールアップ内で実行することと理解できます。zkEVMの目標は、ロールアップの性能上の利点を失うことなく、イーサリアムの体験を完全にL2に持ち込むことです。
現在、zkSync2.0、Polygon Hermez2.0、Scrollなどの主要な汎用ZKロールアッププロジェクトは、次々とzkEVMテストネットを立ち上げており、StarkNetはすでにアルファメインネット段階に入っています。
zkEVMの互換性分類
現在のZKロールアップのzkEVMは、Ethereum自体とは完全に互換性があるわけではなく、「イーサリアム等価」の究極のビジョンには程遠いです。したがって、イーサリアム自体のアップグレード計画がロールアップフレンドリーに調整されているだけでなく、各ZKロールアッププロジェクトもイーサリアムとの互換性の問題を解決し続けています。
Vitalikは、既存のEVMインフラとの互換性の程度に基づいて、zkEVM汎用ZKロールアップを4つのタイプに分類しました：
Type-1：イーサリアムと完全に等価
Type-1型zkEVMは、イーサリアムと完全かつ妥協なく等価であることを目指します。イーサリアムシステムのいかなる部分も変更する必要はなく、ハッシュ、状態ツリー、トランザクションツリー、プレコンパイル、またはその他のコンセンサスロジックを置き換える必要もありません。簡単に言えば、Type-1型のzkEVMはEthereumと完全に等価です。
Type-1型zkEVMは、イーサリアムのブロックを検証することができ、少なくとも実行層端（すべてのトランザクション実行、スマートコントラクト、アカウントロジックを含むが、ビーコンサンセンサスロジックは含まない）を検証することができます。
Type-1型zkEVMは、イーサリアムが最終的に必要とするものであり、ロールアップの最も理想的な選択肢です。一方で、Type-1型zkEVMはロールアップが大量のインフラを再利用できるようにし（例：Ethereum Execution Clients、Block Explorers、Block Productionなど）、他方でType-1型zkEVMはイーサリアムLayer1自体をよりスケーラブルにします。なぜなら、Type-1型zkEVM上で探求されるイーサリアムへのいくつかの修正は、将来的にEthereum自体に導入されるかもしれないからです。
もちろん、Type-1型zkEVMにも欠点があります。イーサリアムは最初からZKフレンドリーに設計されていないため、イーサリアムプロトコルの多くの部分はZK証明を行うために大量の計算を必要とします。Type-1型はイーサリアムと同様に、この問題における非効率を緩和することはできません（証明生成には長い時間がかかります）。この問題に対して、現在業界で提案されている解決策は主に、巧妙なエンジニアリングによる大規模な並列証明、またはZK-SNARK ASICによるハードウェアアクセラレーションです。
現在、Type-1 ZK-EVMを探求している主なチームは、Privacy and Scaling Explorations teamとTaikoの2つです。
Type-2：EVMと完全に等価
Type-2型zkEVMは、EVMと完全に等価であることを目指しますが、イーサリアムとは完全に等価ではありません。既存のアプリケーションとも完全に互換性がありますが、開発を容易にし、証明の生成をより迅速にするために、イーサリアムにいくつかの小さな修正が必要です。
Type-2型zkEVMは、ブロック構造や状態ツリーなどのデータ構造にいくつかの修正を加えています。これらはEVM自体が直接アクセスできない構造であるため、イーサリアム上で動作するアプリケーションはほぼ直接Type-2型zkEVMロールアップ上で動作できます。元のままではイーサリアム実行クライアントを使用できませんが、いくつかの修正を加えることで使用でき、EVMデバッグツールやほとんどの他の開発ツールも使用できます。
不要な部分やZKに優しくないイーサリアムスタックを削除することで、Type-2 zkEVMの証明時間はType-1 zkEVMよりも速くなります。これらの修正は証明者の効率を大幅に向上させましたが、証明時間が遅いという根本的な問題を解決するものではありません。要するに、Type-2の証明時間は依然として遅いです。
Type-3：ほぼEVMと等価
Type-3型zkEVMは、ほぼEVMと等価であり、互換性の面でいくつかの犠牲を払っていますが、そのEVMは開発が容易です。
Type-3型zkEVMは、zkEVMで実装が難しい機能（例えば、プレコンパイル）を削除し、コントラクトコード、メモリ、またはスタックの処理において調整を行うことで、全体的に等価性の面でいくつかの犠牲を払っています。これにより、より多くの検証者時間が実現され、EVMがより開発しやすくなります。
互換性の面で犠牲を払っているため、Type-3型zkEVMが削除したプレコンパイルを使用しているアプリケーションは、一部を再記述する必要があります。
現在、ScrollとPolygonはType-3に分類されます。もちろん、長期的には、どのzkEVMチームもType-3に長期間留まる意向を公に示していません。ScrollとPolygon HermezはType-2型zkEVMの方向に向かって進んでおり、まだ多くの複雑なプレコンパイルが実装されていません。
Type-4：高級言語等価
Type-4型は実際にはzkVMに属します。Type-4システムは、高級言語（Solidity、Vyper）で書かれたスマートコントラクトのソースコードを取得し、ZK-SNARKフレンドリーに設計された特定の言語にコンパイルすることで機能します。
利点と欠点は明確です。Type-4型は、各EVM実行ステップのすべての異なる部分に対してZK証明を行うのではなく、より高いレベルのコードから始めるため、非常に速い検証時間を持ち、コストを削減し、より速い検証時間を得ることができます。互換性は低く、Type-4システム内のコントラクトのアドレスはEVM内のアドレスとは異なり、手書きのEVMバイトコードは使用が難しく、デバッグのためのインフラはEVMバイトコード上で動作するため、継承できません。
要するに、Type-4は言語レベルの等価性に属し、バイトコードレベルの等価性と比較して互換性に大きな差があります。Vitalikの見解によれば、現在主要なZksyncはType-4型に属していますが、時間が経つにつれてEVMバイトコードの互換性が増す可能性があります。Nethermindに基づくwarpプロジェクトは、SolidityからStarkwareのCairoコンパイラを構築しており、これもStarkNetをType-4型に変えるでしょう。
各種zkEVMの比較
これらのzkEVMには絶対的な優劣はありません。互換性と速度の間で妥協があり、Type-1型zkEVMはイーサリアムとの互換性が最も高いですが、証明速度は遅いです。Type-4型zkEVMはイーサリアムとの互換性が低いですが、検証速度は速いです。また、既存のZKロールアップのスタープロジェクトであるZksync、StarkNet、Polygon、Scrollなどは、Type-4/Type-3のようにイーサリアムとの互換性がそれほど高くないzkVM/zkEVMタイプに属しています。
Vitalikは、時間が経つにつれてzkEVMの改善とイーサリアム自体の改善を組み合わせることで、最終的にすべてのzkEVMがType-1型になることを望んでいます。この利点は、将来的に複数のzkEVMが存在し、ZKロールアップにも使用でき、イーサリアムチェーン自体の検証にも使用できることです（将来的にイーサリアムはZK-SNARKに対してよりフレンドリーになるでしょう）。
Vitalikが提案した見解は、一般的に業界全体の合意を得やすく、私も非常に賛同しています。Type-1型zkEVMのプロジェクトは、Ethereumエコシステム内で最も人気があり、Ethereum L1に適しています。しかし、Type-4型zkVMも実行層プロジェクトの良い技術的選択肢であることは否定できません。主に2つの点を考慮しています：
- モジュラー・ブロックチェーンの物語の下で、zkVMは他のL1との接続が容易です。イーサリアムエコシステムのL2を作るという考えから脱却し、バイトコードレベルでイーサリアム仮想マシンと互換性を持たず、zkVMを採用することで、将来的に他のL1コンセンサス層との接続が容易になるかもしれません；
- 現在のZKロールアップの性能の上限は証明生成速度に制約されており、Type-4型zkVMには利点があります。実行層の証明生成速度は非常に重要であり、L2が実行層の性能を極限まで高めることも良い考えです。将来的にASICハードウェアアクセラレーションによって証明生成の効率が向上する可能性がありますが、その効果は未知数です。Type-4型zkVMの証明生成速度が速いことは重要な利点です。
もちろん、zkEVMの互換性と速度は、実際には開発者がどのZKロールアップを基にアプリケーションを構築するかを考慮する唯一の指標ではありません。他にも多くの要因が彼らの選択に影響を与えます。例えば：
- 費用：どのトークンで費用を支払うか、L2の費用削減の程度も非常に重要な考慮要素ですが、ほとんどの汎用ZKロールアッププロジェクトはまだテストネット段階にあり、比較はできません；
- 証明生成のルール：どの人をプロバーとしてサポートするか、さらにはどのハードウェアを使用して証明生成を加速するか；
- L2取引の順序付けのルール：単一のシーケンサーを使用するか、分散型の方法を採用するか；
- 自己管理：L2で事故が発生した場合でもL1でユーザー資産を回復できる明確なメカニズムがあるか；
- データ可用性：完全なデータ可用性コストは自然に高くなるため、いくつかのZKロールアップが採用している低コストのデータ可用性モデルを受け入れられるか。
要するに、各種ZKロールアップのzkEVMは多くの性能の中で妥協があり、実際には絶対的な優劣はありません。
