原作者 -Lisa Akselrod
コンパイル - 毎日 0xAyA
編集後記：以前Vitalik氏が書いたZK-EVMの紹介記事を元に筆者が編集し、ZK-EVMの種類とその違いについて詳しく紹介しました。
約 1 年前、ZK-EVM のグループが今後のテストネットの立ち上げを発表しました。これらの動きはイーサリアムコミュニティの好奇心を刺激し、イーサリアム同等性やEVM同等性などの用語の背後にあるニュアンスについての議論を引き起こしました。
明確にするために、ヴィタリックは次のタイトルの重要な記事を書きました。「さまざまなタイプの ZK-EVM」では、さまざまなZK-EVMを4つのタイプに分類し、その違いを説明します。
核となるアイデアは次のとおりです。タイプ 1 (例: Taiko) はイーサリアムと完全に同等ですが、タイプ 4 (例: zkSync) は効率的なプルーフ生成に優れています。他のすべてのタイプ、タイプ 2、タイプ 2.5、およびタイプ 3 はその中間にあります (例: Polygon zkEVM、Scroll、Linea)。
ほとんどの ZK-EVM は当初タイプ 2.5 およびタイプ 3 であり、タイプ 1 またはタイプ 2 への移行に向けたいくつかの意図が明らかにされていますが、これらのプロジェクトはこれに関する具体的なタイムラインやコミットメントを提供していません。
この記事では、タイプ 1 とタイプ 2/タイプ 2.5 の違いに焦点を当て、イーサリアムの同等性を破った場合に起こり得る影響について説明します。他のタイプについても簡単に触れておきます。
ZK-EVM の主な目標は、イーサリアムをスケーリングすること、つまり、他の機能 (セキュリティ、開発者エクスペリエンスなど) を維持しながらイーサリアムのスループットを向上させることです。理想的には、ZK-EVM は次のことができる必要があります。
イエローブックのイーサリアム仮想マシン仕様に準拠した、未変更のネイティブ バイトコード (イーサリアム オペコードの 100% をカバー) の実行が実証されています。
迅速かつ安価に校正証明書を生成します。
イーサリアム用に開発されたツールとインフラストラクチャを 100% 再利用できます。
あらゆる Ethereum dApp を ZK-EVM に「現状のまま」再デプロイできるようにします (「現状のまま」とは、変更が必要なく、妥協もしないことを意味します)。
ZK-EVMタイプの違い
ZK-EVM 空間では、違いは主にイーサリアム/EVM の同等レベル、証明生成のコストと速度に対する ZK 非フレンドリーな要素の影響、回路実装の複雑さ (VM 構築やステート ツリーなど) から生じます。 。
これらの違いを分析して、特にタイプ 1 とタイプ 2/タイプ 2.5 を区別してみましょう。それぞれのタイプに最も関連するユースケースについても触れます。
さまざまなタイプを比較する場合、次の表がよく使用されます。
ZK-EVM 分野でフルタイムで働いていない人にとって、この表はわかりにくいように思えるかもしれません。そこで、これらの用語を分かりやすい言葉に翻訳して見てみましょう。
この図は、各タイプが実際にどのようなものかをより明確に示していますが、まだ少しわかりにくい場合があるため、各タイプを個別に説明して ZK-EVM の世界を詳しく見てみましょう。
タイプ 1: イーサリアムと同等
「タイプ 1 ZK-EVM は、イーサリアム レイヤー 1 自体のスケーラビリティを高めるために最終的に必要なものです。」
タイプ 1 は、プルーフの生成を容易にするためにイーサリアム システムのどの部分も変更しないことを意味します。ほとんどの暗号化プリミティブ (ハッシュ関数など)、開発者インフラストラクチャ (デバッガなど)、チェーン インフラストラクチャ (実行クライアントなど) はすでに 9 年間にわたるフィールド テストを経ているため、イーサリアムに変更を加えないということは、セキュリティに妥協がないことを意味します。
タイプ 1 ZK-EVM は、ハッシュ、ステート ツリー、トランザクション ツリー、プリコンパイル、その他のコンセンサス ロジックを何も置き換えず、すべてがメインネットの EVM とまったく同じです。
タイプ 1 は、ブロック全体からトランザクションの実行、スマート コントラクト、アカウント ロジックに至るまで、イーサリアム チェーン自体を検証できる唯一のタイプです。
タイプ2：EVMと同等
タイプ 2 は、ZK に適さない一部の部分を削除することにより、プルーフの生成を高速化し、回路開発を容易にします。ただし、この結果により、ZK ロールアップの他の部分 (ノード ソフトウェアなど) の開発がより複雑になる可能性があります。これらの複雑さは、確立されたベスト プラクティスおよびテスト ツールと、実装されている変更 (ステート ツリーの変更など) との間の非互換性によって引き起こされる可能性があります。
注: Ethereum に相当するものと EVM に相当するものは同じではありません。イーサリアムと同等であるということは、イーサリアムのどの部分も変更されていないこと、つまりすべてのイーサリアム dApp と完全に互換性があることを意味しますが、EVM と同等であるということは、データ構造 (ブロック構造やステート ツリーなど) の変更を許可します。
これらの調整は些細なように見えるかもしれませんが、イーサリアムの互換性に影響を与えます。データ構造を変更すると、特に過去のトランザクション、領収書、または状態（クロスチェーンブリッジなど）に関するマークル証明を検証する場合、イーサリアム dApps がタイプ 2 ZK-EVM と互換性がなくなる可能性があります。
ZK の非友好的な要素を削除する
イーサリアムへの変更は、開発を簡素化し、プルーフ生成の速度を上げることを目的としています。目標は、不親切なゼロ知識暗号に依存するイーサリアムの部分を取り除くことです。より専門的な用語では、非ローカル領域 (ハッシュ関数など)、多数のマルチスカラー乗算および/または高速フーリエ変換 (FFT) のために大量のゲート (加算および乗算演算) を必要とする部分。または、多くの操作が必要な部分だけ。
タイプ 2 ZK-EVM が変更する可能性がある非友好的なゼロ知識要素の具体的な例:
ハッシュ関数: イーサリアムは Keccak ハッシュ関数を使用しますが、多くの ZK-EVM は、必要なゲートが大幅に少ない Poseidon ハッシュ関数を使用します。たとえば、各タイプのハッシュ関数が 1 秒あたりにいくつ計算できるかを見積もってみましょう (つまり、生成速度を示す比較)。
ポセイドン ハッシュ関数は、プルーフ生成において速度に大きな利点があります。
ただし、新しい暗号化プリミティブは、コミュニティに広く認識されている確立された暗号化プリミティブと比べて人気が低いことに注意することが重要です。ポセイドンはスピードを提供するかもしれませんが、ケチャックは実戦でテストされた特性により、より広く採用されるにつれてより堅牢で安全になります。
これが、Kecck が古く、より広範なコミュニティ (セキュリティ システムやスマート デバイスのセンサーなど、他の業界) に採用されているにもかかわらず、結局 ZK コミュニティ内にある Poseidon よりも実証済みであると考えられる理由です。作成して使用する関数。
データストレージの状態ツリー: たとえば、イーサリアムはマークル パトリシア ツリー(Kecck ハッシュを使用)、ただし一部のタイプ 2 ZK-EVM オプションスパースマークルツリー(ポセイドンハッシュを使用)。状態ツリーを変更すると、互換性がなくなる可能性があります。たとえば、イーサリアムのマークル ツリーにはさまざまなノード タイプがあり、RLP を使用してデータをエンコードしますが、これを ZK で行うのは困難です。
ブロック構造: ブロックには大量の情報が含まれています。ただし、L2 を調査するときは、execution_payload_header (つまり、ブロック ハッシュ) のみを考慮します。下の画像には、execution_payload_header に含まれるすべてのデータの構造 (ブロック ハッシュ) があります。
注意してください: これらのコンポーネントのいずれかを変更すると、イーサリアムの同等性が失われます。
タイプ2.5：ガスコストを考慮したEVMと同等
タイプ 2.5 ZK-EVM は、EVM で ZK テクノロジーを使用して証明することが難しい特定の操作のガスコストを増加させます。
イーサリアムのブロックあたりのガス制限 (30 M ガス) を考慮すると、オペコードあたりのガスコストが増加すると、ブロックあたりのオペコードが少なくなります。したがって、それほど複雑でないオペコードをブロックに含めることができます。オペコードが単純になると、回路が小さくなり、証明をより速く生成できるようになります。
ガスは仕事の測定単位です。
オペコードの価格はガスで計算されます。
オペコードは、機械語命令内の操作を指定します。
プログラムはオペコードの静的なリストです。プログラムの実行は実行トレースです。
実行トレースは、プログラムによって実行されるオペコードの特定の順序付きリストです。
ZK を証明するのが難しい部分には次のようなものがあります。
Keccak オペコードと Keccak に依存するその他のオペコード。
プリコンパイル済み: EVM にアクセスできる関数。それらの中には、暗号関数 (blake 2 f や sha 256 など) など、複雑なタスクや数学的に複雑なタスクを提供するものもあります。これらは EVM 内で実行されるのではなく、実行クライアントにハードコードされた関数として実行され、特別なアドレスへの CALL を使用して EVM に公開されます。
メモリアクセス: 例: メモリスロットサイズの増加(例: Ethereum の使用)バイトアライメントPolygon zkEVM は 32 バイトのメモリ スロットを使用します)。この変更を可能にするには、特定のオペコード (MLOAD など) の内部ロジックを変更する必要がありました。
ストレージ (つまり、上記のハッシュ関数または状態ツリーの変更)。
ガスコストを変更すると、開発者ツールの互換性が低下し、一部の dApp が機能しなくなる可能性があります。たとえば、ガスコストが増加するオペコードを頻繁に実行するスマート コントラクトは、ブロック ガス制限を超えて実行に失敗する可能性があります。
タイプ 3: EVM とほぼ同等
タイプ 3 ZK-EVM は、ZK に適用されないプリコンパイルを省略し、メモリとストレージのアクセスを調整する場合があります。
削除されたプリコンパイル済みアプリに依存していた dApp は書き直す必要があります。まれに、タイプ 3 ZK-EVM と元の EVM がエッジ ケースを処理する方法が異なるため、dApp の調整が必要になる場合があります。
タイプ4（高級言語に相当）
タイプ 4 はすでに EVM から遠く離れています。
高級言語 (Solidity、Zinc など) で書かれたスマート コントラクトのソース コードは中間表現にコンパイルされ、ZK フレンドリーな仮想マシンに適したオペコードを生成します。
このアプローチでは、EVM 実行ステップごとに ZK 証明を生成することが回避されるため、証明の労力が大幅に削減されます。
コントラクトをコンパイルできたとしても、dApp が EVM 手書きバイトコードを使用する場合は、さらなる作業が必要になります。
タイプ 4 ZK-EVM には、デバッガーやトレーサーなどの独自の開発者ツール (オペコード レベルのみ) も必要です。
実行軌跡を証明する ZK 回路では、各ステップが制約を実装し、各ステップのコストはすべてのオペコードの合計になります。したがって、タイプ 4 ZK-EVM は、効率を最適化するために複雑なオペコードをできるだけ少なく使用するように設計されています。
カスタム オペコード (イーサリアムではカバーされていないオペコード) を使用すると、イーサリアムではデフォルトでは不可能な新機能を渡すことが可能になることに言及する価値があります。たとえば、アカウント抽象化機能を介して複数の呼び出しを実行したり、Argent のようなすぐに使用できるソリューションを使用してスマート コントラクト ウォレットを起動したりできます。
要約する
ZK-EVM のタイプによって、優先順位が異なる目標と特性が異なります。タイプ 1 はイーサリアムとの同等性に重点を置き、タイプ 4 は効率的なプルーフ生成を優先します。他のタイプはこれらの両極端の間にあり、多くのタイプ 2 および 3 ZK-EVM プロトコルはイーサリアム同等のものに移行する意向を発表しています。
これら 4 種類の分類は ZK ロールアップの最終状態ではない可能性があり、将来さらに変更される可能性があります。たとえば、一部の ZK-EVM はハイブリッドになる可能性があり、タイプ 1/2 はタイプ 4 ソリューション (可能な限り最高の効率) を開発し、両方のオプションを備えた dApp を提供する可能性がありますが、タイプ 3 および 4 の ZK-EVM にはイーサリアム同等のオプションが追加される可能性があります。
