本レポートでは、乱立するzkEVMプロジェクトについて、その違いを様々な角度から比較することを目的としています。zkEVMを活用したzkRollupでは、Layer 2（以下、L2）を構成する様々な要素が組み合わさってできているため、単純にどちらが優れていると比較することは困難です。ScrollとLineaはどちらもzkRollupを採用し、分散化とスケーラビリティの向上を目指しているも点で共通していますが、その技術的アプローチや分散化のロードマップにおいては、異なる戦略をとっています。本レポートを通じて、これらの異なる仕組みがどのようなトレードオフのもとで採用されているかを理解し、今後のプロジェクトに対する考察の材料としていただければ幸いです。

本レポートでは、乱立するzkEVMプロジェクトについて、その違いを様々な角度から比較することを目的としています。zkEVMを活用したzkRollupでは、Layer 2（以下、L2）を構成する様々な要素が組み合わさってできているため、単純にどちらが優れていると比較することは困難です。ScrollとLineaはどちらもzkRollupを採用し、分散化とスケーラビリティの向上を目指しているも点で共通していますが、その技術的アプローチや分散化のロードマップにおいては、異なる戦略をとっています。本レポートを通じて、これらの異なる仕組みがどのようなトレードオフのもとで採用されているかを理解し、今後のプロジェクトに対する考察の材料としていただければ幸いです。

zkEVMの仕組みについて簡単に解説します。
zkEVMの詳しい説明はこちらのレポートを参照してください。

【関連レポート】

zkEVMはzkRollupをEthereumのようなより汎用的な用途に適用できるようにすることを目指して開発されています。従来のzkRollupは、資金のdeposit/withdrawやトークンの移動など、限られた機能しか提供できませんでした。これは、ゼロ知識証明を実装する際に、特定の制約に対応した個別のCircuitを実装する必要があり、すべてのロジックに対してCircuitを作ることが困難だったためです。

この課題を解決するために、バイトコードレベルでCircuitを実装することで、汎用的なzkRollupを開発する取り組みが進められています。このようにして、より広範な用途に対応可能なzkEVMの実現が期待されています。

上図は、zkEVMで行われるゼロ知識証明の実装について簡単に説明しています。基本的には、Ehtereumのstateがコントラクトの実行によって正しく更新されているかをオペコードごとに確認し、状態遷移の正当性を証明しています。

このときに必要な制約が以下の通りです。

これらの制約を満たすことで、L2のEVM内で正しくトランザクションが実行され、状態（state）が正しく更新されていることを確かめることができます。

この仕組みを活用し、複数のトランザクションに対して1つのProofを作成することで、L2で実行された複数のトランザクションに対する検証を、L1でProofの検証を1回行うだけで済ませることが可能になります。こうしてトランザクションをrollupすることでガス代を削減し、ブロックチェーンのスケーラビリティを改善しようとしています。

zkEVMにおいては、どれだけEVMとの互換性を保つかが重要な要素となります。この互換性の度合いに基づき、zkEVMは5種類に分類されます。ここでは、その分類と共に、ScrollとLineaがどのようにEVMと異なるのかを具体的に見ていきましょう。

zkEVMは、ゼロ知識証明を用いて、汎用的なアプリケーションを実装することを可能にします。しかし、EVMと全く同じ計算を行おうとすると、パフォーマンスが低下します。一方で、パフォーマンスを向上させるためにゼロ知識証明に適した処理に置き換えると、EVMとの互換性が低下します。互換性が低下すると、現在のEthereumエコシステム（スマートコントラクトのコード、ERC-20などの標準規格、開発者ツールとフレームワーク、ウォレットなど）をそのまま引き継ぐことが難しくなります。その結果、スマートコントラクトのコードを再利用してそのまま移行することが難しくなり、開発者の採用障壁が高くなります。また、zkEVMとEVMの間でツールやインフラの統一が難しくなり、エコシステムが断片化する恐れがあります。

このようなパフォーマンスと互換性のトレードオフを考慮して、様々な開発機関が異なる種類のzkEVMを開発しています。これらのzkEVMの特徴をしっかりと把握するために、いくつかの基準に基づいて5つのタイプに分類されます。（参考：「The different types of ZK-EVMs」）

zkEVMの分類について詳しい説明はこちらのレポートを参照してください。

【関連レポート】

ScrollとLineaは、いずれもType 2に分類されます。こちらのレポートからType2の特徴について再掲します。

ScrollとLineaは、いずれもstateツリーの構造に変更を加えており、ブロックヘッダーの値などはEVMと異なっています。また、ほとんどのopcodeとprecompiled contractを実装しているため、Type2に分類されますが、将来的にはType 1への移行を目指しています。次節では、より具体的にEVMと何が違うのかを明確にするために、次節では、EVMとの具体的な違いについて詳しく説明し、ScrollとLineaの特徴をさらに明確にしていきます。

ScrollとLineaはstateツリーなどのデータ構造においてEVMと違うアプローチを採用しています。ScrollはSparse Binary Merkle Patricia Trieという構造を採用していおり、これを「zkTrie」と呼んでいます。一方、LineaではSparse Merkle Treeという構造を使用しています。

EthereumはMerkle Patricia Trieを使用していますが、これらのプロジェクトが採用する木構造との大きな違いは、ハッシュ関数にKeccak-256ではなく、Poseidonハッシュ関数を用いている点です。SHA256やKeccak-256などのビット演算を多用するハッシュ関数はzkの計算に不向きであるため、zkの（有限体上の）計算に適したzk-friendlyなハッシュ関数としてPoseidonハッシュ関数が採用されています。

また、両プロジェクトのツリー構造には「Sparse性」があります。これは、多くの要素が「ゼロ」や「空」であり、キー空間全体が効率的に使用されるように設計されていることを意味します。さらに、ツリーの深さを減らすために、単一のリーフノードしか持たないサブツリーを縮約する最適化が行われています。

参考：

ブロックヘッダーの構造はEthereumと同じになるように設定されていますが、L2に適応するためにいくつかのフィールドが変更されています。

Scrollのブロックヘッダーを例に挙げると、EthereumでPoWの難易度を表すdifficultyフィールドは、Scrollでは常に1か2に設定されており、マイニングの難易度とは無関係の固定値になっています。他にも、EIP-1559で導入された各ブロックでの最小ガス価格を指定するbaseFee フィールドはまだ対応していないため未設定となっています。

参考：

Scrollでは、サポートしていないopcodeが3つ、サポートしていないprecompiled contractが3つ、少し変更を加えてサポートしているものが2つあります。

一方、Lineaでは、サポートしていないopcodeが6つ、サポートしていないprecompiled contractが1つ、少し変更を加えてサポートしているものが1つあります。

opcodeの互換性に関しては、Scrollの方が互換性が高いように思いますが、これはLineaがCancun アップグレードやLondonアップグレードで追加されたopcodeに対応できていないためです。Precompiled contractに関しては、Scrollの方が対応するPrecompiled contractが少なく、特に、blake2fやRIPEMD-160といったハッシュ関数の実装が未対応という点で違いがあります。

参考：

zkEVMが実用的なレベルまで実装可能になったのは、ゼロ知識証明の技術的な進歩があったからです。例えば、EVMがサポートする楕円曲線が限られているため、証明の再帰を行うのが難しいことや、zkpの計算に適さないビット演算（AND、ORなど）が多く使われるなどの課題がありました。しかし、多項式コミットメントやルックアップテーブルといったゼロ知識証明の技術的な進歩により、これらの課題が解決され、実用的なzkEVMの実装が可能になっています。