zkSync 2.0のメインネットがまもなくリリース予定。各種zkEVMを概観する
TechFlow厳選深潮セレクト
zkSync 2.0のメインネットがまもなくリリース予定。各種zkEVMを概観する
ロールアップの技術的アプローチに関しては、ZK ロールアップがイーサリアムのスケーリングの最終的な目標とされている。
Web3業界の深掘り報道に専念し潮流を洞察イーサリアムの発展路線はますますモジュラーブロックチェーンに傾いており、これは本質的にLayer1のデータシャーディングとLayer2のRollupsスケーリングを組み合わせたモジュラー型アーキテクチャであり、イーサリアムが「ワールドコンピュータ」という本来の目標を実現するための推進力となる。
その中でRollupsの技術的選択肢に関して、ZK Rollupはイーサリアムのスケーラビリティにおける最終的な目標と見なされている。
ZK Rollup
ZK Rollupのコア動作メカニズムは、ブロックチェーン上のユーザー状態をMerkle木構造に圧縮して保存し、ユーザー状態の変更処理をオンチェーンからオフチェーンに移行することにある。同時に、zksnark/zkstark証明によって、このオフチェーンでの状態変更プロセスの正確性を保証する。平たく言えば、ZK Rollupとは、zksnarkまたはzkstarkを用いて亜線形的な処理で線形数の文を検証できるようにする仕組みである。例えば、1000件の文を検証するのに10回のチェック、10000件では11回のチェックで済む。こうした特性により、ZK Rollupはイーサリアムのスケーリングを実現できる。
ZK Rollupにおけるブロックチェーントランザクションの大まかな処理手順は以下の通り：
-
ユーザーは資産をL1上のzk rollupスマートコントラクト内にロックする；
-
ユーザーはこれらの資産に関わる取引をL2に提出する。L2内の特定の役割（Sequencer。初期の多くのプロジェクトでは中央集権的だが、一部では非中央集権化も始まっている）がこれらの取引を一定のルールに基づき順序付きのバッチとしてまとめ、各バッチに対して有効性証明（zksnark/zkstark）および集約された状態更新を生成する；
-
この状態更新および証明は、L1のzk rollupスマートコントラクトに提出され検証された後、L1ブロックチェーン上で状態が更新される；
-
ユーザーはこのようなL1状態（異なるデータ可用性メカニズムに依存）を利用して自身の資産を引き出すことができ、完全なセルフホスティングが可能となる。そのため、zk rollupはイーサリアムの安全性を継承しているとみなされている。
zkEVMの必要性
周知の通り、初代のZK RollupsはEVMをサポートしておらず、プログラマビリティやコンポーザビリティが低く、特定の用途に限定されていた。例えばLoopringはPayments＆Swapsなどの用途に、ImmutableはNFT Minting＆Trading＆Gamesなどに制限されていた。またzksync1.0もzkEVMをサポートしていなかった。つまり汎用性がなかった。
その後、主要なZK Rollupsプロジェクトは、ZK Rollup上でEVMバイトコードを実行可能な環境を開発し始め、これによりイーサリアム上のスマートコントラクトをゼロから書き直すことなく、そのままZK Rollupに移行できるようになった。
EVMは2015年に登場した最初のチューリング完全なブロックチェーン仮想機械であり、これまで最も実績のあるブロックチェーンVMであり、イーサリアムの重要なスマートコントラクト基盤でもある。他のブロックチェーンについて語る際にも、EVM互換かどうかは一つの評価軸となる。なぜならEVM互換とは単なる実行環境の互換だけでなく、利用可能なイーサリアムエコシステムやツール群、そして無視できないネットワーク効果を意味しているからである。そのため、ZK Rollupsもこの点を無視することはできなかった。
zkEVMとは、EVMをスマートコントラクトエンジンとしてZK Rollup内で動作させることを意味する。zkEVMの目標は、Rollupのパフォーマンス優位性を損なうことなく、イーサリアム体験を完全にL2に持ち込むことである。
現時点では、zkSync2.0、Polygon Hermez2.0、Scrollといった主要な汎用ZK RollupプロジェクトはすでにzkEVMテストネットを相次いで公開しており、StarkNetはすでにAlpha Mainnet段階に入っている。
zkEVMの互換性分類
現在のZK RollupsのzkEVMはイーサリアム自体と完全に互換というわけではない。「イーサリアム同等（equivalent）」という究極のビジョンには程遠い。そのため、イーサリアム側のアップグレード計画もRollupフレンドリーになるよう調整されており、各ZK Rollupプロジェクトもイーサリアムとの互換性問題の解決に継続的に取り組んでいる。
Vitalikは既存のEVMインフラとの互換性レベルに基づき、zkEVM搭載の汎用ZK Rollupを4つのタイプに分類している：
Type-1：イーサリアムと完全等価
Type-1型zkEVMは、イーサリアムと完全かつ妥協なく等価になることを目指す。イーサリアムシステムのハッシュ、ステートツリー、トランザクションツリー、プリコンパイル、あるいはその他の合意ロジックなど、いかなる部分も変更せず、置き換えず、そのままである。つまり、Type-1型zkEVMはイーサリアムと完全に等価である。
Type-1型zkEVMは、イーサリアムのブロックを検証できるか、少なくとも実行層（すべてのトランザクション実行、スマートコントラクト、アカウントロジックを含むが、ビーコンチェーンの合意ロジックは除く）を検証できる。
Type-1型zkEVMは、イーサリアムが最終的に必要とするものであり、Rollupsにとっても最も理想的な選択肢である。第一に、Type-1型zkEVMにより、Rollupsは大量の既存インフラ（Ethereum Execution Clients、Block Explorers、Block Productionなど）を再利用できる。第二に、Type-1型zkEVMはイーサリアムL1自体のスケーラビリティを高める可能性もある。なぜなら、Type-1型zkEVMで試行されるいくつかの改良が将来イーサリアム本体にも採用されるかもしれないからである。
もちろん、Type-1型zkEVMにも欠点がある。イーサリアムは当初ZKフレンドリーを念頭に設計されたわけではなく、プロトコルの多くの部分がZK証明のために膨大な計算を要する。Type-1型はイーサリアムと同じ構造のため、この非効率性を回避できない（証明生成に長時間かかる）。この問題に対し、業界で提案されている解決策としては、巧妙な工学的手法による大規模な並列証明、またはZK-SNARK用のASICによるハードウェアアクセラレーションがある。
現在、Type-1 ZK-EVMの開発に取り組んでいる主なチームはPrivacy and Scaling Explorations teamとTaikoの二つである。
Type-2：EVMと完全等価
Type-2型zkEVMはEVMと完全に等価になることを目指すが、イーサリアム全体とは完全には等価ではない。既存のアプリケーションとも完全に互換性を持つが、開発を容易にし、証明生成を高速化するためにイーサリアムに若干の修正が必要となる。
Type-2型zkEVMは、ブロック構造やステートツリーなどのデータ構造に若干の変更を加える。これらはEVM自体からは直接アクセスできないため、イーサリアム上で動作するアプリケーションはほぼそのままType-2型zkEVM Rollup上で動作可能である。イーサリアムの実行クライアントをそのまま使用はできないが、修正を加えれば利用可能であり、EVMデバッガーやその他の開発ツールの多くも使用できる。
不要でZK非対応なイーサリアムスタックの一部を削除することで、Type-2 zkEVMはType-1より証明時間が短くなる。これらの変更により証明者の効率は大幅に向上するが、根本的に証明時間が遅いという問題は解決していない。総じて、Type-2の証明時間も依然として遅い。
Type-3：ほぼEVM等価
Type-3型zkEVMはEVMにほぼ等価であり、互換性の面で妥協しつつも、EVMの開発が容易になっている。
Type-3型zkEVMは、zkEVM内で実装が困難な機能（例：プリコンパイル）を削除したり、コントラクトコード、メモリ、スタックの処理方法を調整したりすることで、等価性に若干の妥協をしながら、検証時間の短縮と開発の容易さを実現している。
互換性の面では若干劣る。Type-3型zkEVMが削除したプリコンパイルを使用しているアプリケーションは、それらの部分を再記述する必要がある。
現在、ScrollとPolygonがType-3に該当する。ただし長期的に見れば、どのzkEVMチームもType-3に留まることを公言しているわけではない。ScrollとPolygon HermezはいずれもType-2を目指しており、まだ実装されていない複雑なプリコンパイルも多い。
Type-4：高級言語レベルでの等価
Type-4は実際にはzkVMに分類される。Type-4システムは、高級言語（Solidity、Vyper）で書かれたスマートコントラクトのソースコードを取得し、ZK-SNARKに最適化された言語へとコンパイルすることで動作する。
利点と欠点が明確である。非常に速い検証時間を実現できる。Type-4はEVMの各実行ステップのすべてをZK証明するのではなく、高レベルのコードから開始するため、コストが低く、検証が迅速になる。一方で互換性は劣り、Type-4システム上のコントラクトアドレスはEVM上とは異なる。手書きのEVMバイトコードの利用が難しくなる。また、EVMバイトコード上で動作するデバッグインフラの多くは継承できない。
要するに、Type-4は言語レベルでの等価であり、バイトコードレベルの等価に比べて互換性に大きな差がある。Vitalikによれば、現在Type-4に該当するのは主にZksyncであり、将来的にはEVMバイトコード互換性を追加していく可能性がある。また、NethermindのWarpプロジェクトがSolidityからStarkwareのCairoへのコンパイラーを開発しており、これによりStarkNetもType-4型になる。
各種zkEVMの比較
これらのzkEVMに絶対的な優劣はない。互換性と速度のトレードオフの違いにすぎない。Type-1型はイーサリアムとの互換性が最高だが証明速度が遅い。Type-4型は互換性が低いが検証速度が速い。また、現時点で注目を集めるZK Rollupの主要プロジェクト（Zksync、StarkNet、Polygon、Scrollなど）の多くが、Type-4またはType-3といった、イーサリアムとの互換性が高くないzkVM/zkEVMタイプに属していることもわかる。
Vitalikは、zkEVMの改善とイーサリアム自体の改善を組み合わせることで、最終的にはすべてのzkEVMがType-1になることを望んでいる。 こうすれば、将来的に複数のzkEVMが存在し、ZK Rollupに利用されるだけでなく、イーサリアムチェーン自体の検証にも使えるようになる（今後のイーサリアムはZK-SNARKによりフレンドリーになる予定）。
Vitalikの提唱する考え方は、業界全体で広く共通認識となりやすく、私も強く同意する。Type-1型zkEVMのプロジェクトはイーサリアムエコシステム内で自然に最も好まれ、Ethereum L1にも適合しやすい。しかし、Type-4型zkVMも、実行レイヤープロジェクトにとっては優れた技術的選択肢になり得る。
主に以下の2点の理由からである：
-
モジュラーブロックチェーンの枠組みの中で、zkVMは他のL1との接続が容易である。単にイーサリアムエコシステムのL2を作るという発想を超え、バイトコードレベルでEVMと互換性を持たせずにzkVMを選択すれば、将来的に他のL1コンセンサス層と連携しやすくなる可能性がある；
-
現在のZK Rollupの性能上限は証明生成速度に制限されており、この点でType-4型zkVMに優位性がある。実行層における証明生成速度は非常に重要であり、L2が実行層のパフォーマンスを極限まで高めることも、立派な戦略といえる。確かに将来ASICによるハードウェアアクセラレーションで証明効率を高められる可能性はあるが、その効果は未知数であり、Type-4型zkVMの証明生成速度の速さは重要な強みである。
もちろん、zkEVMの互換性と速度は、開発者がどのZK Rollupをベースにアプリを開発するかを決める唯一の指標ではない。以下のような他の要素も選択に大きく影響する：
-
費用：どのトークンで手数料を支払うか、L2の手数料がどれだけ低下するか。ただし、多くの汎用ZK Rollupプロジェクトがまだテストネット段階であるため、現時点では比較が難しい；
-
証明生成ルール：誰がProverになれるか、どのようなハードウェアを使って証明生成を加速できるか；
-
L2トランザクションの順序決定ルール：単一のSequencerか、非中央集権的な方式か；
-
セルフホスティング：L2で障害が発生した場合でも、L1でユーザー資産を回復できる明確なメカニズムがあるか；
-
データ可用性：完全なデータ可用性はコストが高くなるため、一部のZK Rollupが採用する低コストのデータ可用性モデルを受け入れられるか。
結局のところ、各ZK RollupのzkEVMはさまざまな性能のトレードオフの結果であり、絶対的な優劣は存在しない。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
