ZK-EVM: ZKロールアップの聖杯

イーサリアムのスケーリングは、多くのユーザーが熱心に待ち望んでいるホットトピックです。2022年9月のイーサリアムマージ（コンセンサスメカニズムをPoWからPoSに移行）がイーサリアムのパフォーマンスを向上させるという誤解が一般的でした。実際には、マージはブロックサイズを変更せず、ブロック時間は平均13秒から12秒に短縮されただけで、パフォーマンスの向上は限定的と予想されています。イーサリアムの短期的なスケーリングの期待は、依然としてレイヤー2ネットワーク（ロールアップ）にかかっています。オプティミスティック・ロールアップとZKロールアップという2つの主要なロールアップアプローチの中で、多くの人々が後者を支持しています。ZKロールアップは、複数のオフチェーントランザクションをバッチ処理してネットワーク手数料を削減するだけでなく、ゼロ知識証明を通じてイーサリアムのセキュリティを継承し、オプティミスティック・ロールアップのようなチャレンジ期間を必要としません。

支払い専用のZKロールアップ

初期のZKロールアップは、EVM互換性がなくスマートコントラクト機能をサポートしていないという批判を受けていました。例えば、Gitcoinの主要な寄付支払い方法であるzkSync 1.0は、基本的な送金のみをサポートしていました。dYdXのような現在のZKアプリケーションは、カスタムビルドで相互運用性がなく、開発が困難です。また、異なるZKアプリケーションは独自のカスタム回路を使用しており、コンポーザビリティが制限されています。そのため、市場はイーサリアムのスマートコントラクトと互換性のあるZKロールアップを緊急に必要としており、その主な障壁はゼロ知識証明互換の仮想マシンの実現です。この記事では、EVM、ZK-EVM、主要なZK-EVMプロジェクトとその違いについて紹介します。

EVMとは？

イーサリアム仮想マシン（EVM）は、イーサリアムの実行エンジンとして機能し、スマートコントラクトのランタイム環境として働きます。開発者はSolidityなどの高級言語でビジネスロジックを記述し、それがバイトコードにコンパイルされます。EVMはこのバイトコードを機械可読なオペコードに解釈し、対応する命令を実行してシステムの状態を更新します。EVMはスタック、メモリ、ストレージと相互作用するスタックベースの仮想マシンです。イーサリアムや様々なスケーリングソリューション、競合チェーンにとって、EVMはイーサリアムエコシステム、その開発者、アプリケーション、ツールの代名詞となっています。EVM非互換のブロックチェーンは、独自のエコシステムを構築し、開発者がアプリケーションやツールを再作成する必要があります。EVMとの互換性により、開発者は既存のイーサリアムコントラクトをシームレスに移行し、イーサリアムのツールにアクセスできます。

新興のZK-EVM

EVMはイーサリアムのエコシステムで重要な役割を果たしていますが、ZK-EVMの開発は困難です。ZK-EVMは、EVM互換性を維持しながらゼロ知識証明を生成し、イーサリアムのスマートコントラクトを修正なしでデプロイし、ゼロ知識証明で計算を検証できるようにします。EVMはZK互換性を考慮して設計されていませんでした。なぜなら、zk-SNARKsのようなゼロ知識証明アルゴリズムは、2016年にZcashによって採用されるまで広く普及していなかったためです。一部のEVM操作はZKに適していないため、証明の生成が困難、遅い、または大きくなります。

ZKの開発は暗号学、数学、ハードウェアの専門知識を必要とする複雑な作業として知られています。ZK-EVMの構築は、EVM互換性とZK適合性の両方が必要なため、さらに課題が増えます。幸いなことに、近年ZK技術で大きなブレークスルーが達成されています。Starkware、zkSync 2.0、Polygon、Scrollを含むZK-EVM分野のプレイヤーたちは、ZK-EVMの開発を加速させており、ほとんどが2023年からメインネットの立ち上げを発表しています。

ZK-EVMプロジェクトの比較

ZK-EVMは統一された設計や標準に従っておらず、各プロジェクトはEVM互換性とZKサポートの間で独自のバランスを取っています。主に2つのアプローチがあります：

1. プログラミング言語レベルのサポート：ZKに最適化するためにEVMオペコードをカスタマイズし、ZKフレンドリーな操作をサポートするように仮想マシンを再構築し、Solidityを新しいVMオペコードにコンパイルします。

2. バイトコードレベルのサポート：ネイティブEVMオペコードの互換性を維持します。

第一のカテゴリーのプロジェクトには、StarkwareのStarkNetとzkSync 2.0が含まれます。StarkNetは、SolidityをStarkNetの言語であるCairoにコンパイルしてZKフレンドリーなVM上にデプロイすることで、任意のEthereumのdAppを実行できます。同様に、zkSync 2.0は、YulとZincコンパイラを通じてZK-EVM機能を実現しています。YulはSolidityの中間表現として、Rustベースの言語であるZincはスマートコントラクトと一般的なZKサーキット用に使用されます。両者ともLLVMフレームワーク上に構築され、高効率なZK-EVMバイトコードを実現しています。

これらのプロジェクトは言語レベルでSolidityとの互換性を提供し、開発者はSolidityコントラクトを移行できますが、基盤となるVMアーキテクチャはEVMとは異なり、技術的にはzkVMです。VMの命令セットが異なるため、既存の開発者ツールの一部は直接動作しない可能性がありますが、このアプローチはよりZKフレンドリーで、より効率的に証明を生成できます。

第二のアプローチでは、Polygon ZK-EVMやScrollなどのプロジェクトがネイティブEVMオペコードの互換性を維持しています。PolygonのuVM（ZK最適化VM）は、EVMバイトコードをマイクロオペコードにコンパイルして実行することで、EVMオペレーションを強化するカスタムオペコードを使用します。Polygon ZK-EVMは完全なEVM互換性を持ち、既存のスマートコントラクト、開発者ツール、ウォレットをシームレスに操作できます。同様に、Scrollは各バイトコード用のサーキットを設計し、バイトコードのロード、オペコードの実行、ストレージの更新を含む、すべてのEVM実行ステップを検証します。

Vitalikのブログでは、ZK-EVMをタイプ別に分類しています。タイプ1は、Ethereum上で直接開発されたZK-EVMを指し、複雑で非効率的であり、Ethereum Foundationによる研究が進行中です。タイプ2、2.5、3はEVM互換のZK-EVMで、ScrollとPolygon Hermezは現在タイプ3に位置し、タイプ2.5または2への移行を目指しています。タイプ4には、StarkwareやzkSyncなど、より高レベルな言語と互換性のあるZK-EVMが含まれます。標準化されたZK-EVMモデルが存在しないため、これらのタイプには本質的な優劣はありません。Vitalikが述べたように、「理論的には、L1使用のために単一のZK-EVM実装に標準化する必要はなく、異なるクライアントが異なる証明を使用できるため、コードの冗長性から引き続き恩恵を受けることができます。」

結論

各ZK-EVMソリューションには独自の強みがあり、ほとんどのプロジェクトがまだコードをオープンソース化していないため、効率性の比較はできません。最大のスマートコントラクトプラットフォームとして、Ethereumのエコシステムとネットワーク効果は強力です。ZK-Rollupの究極の目標であるZK-EVMは、Ethereumのエコシステムとネットワーク効果を活用して、そのセキュリティを継承し、手数料を削減し、活気のある開発者エコシステムを育成します。2021年初頭、Vitalikはブログで、短期的には一般的なEVM計算においてOptimistic Rollupが優位に立つ可能性がある一方、ZK-Rollupはよりシンプルな支払い、取引、アプリケーション固有のユースケースで優れる可能性があると示唆しました。しかし、zk-SNARK技術の進歩により、中長期的にはZK-Rollupがすべてのユースケースで優位に立つ可能性があります。複数のZK-EVMプロジェクトがメインネットを立ち上げる中、Ethereumのレイヤー2スケーリングの展望は近い将来、非常に興味深いものとなるでしょう。