V 神の新しい記事: イーサリアムに ZK が組み込まれた後、レイヤー 2 はどこへ行くのですか?

Loopy Lu

读者

2023-12-14 07:07

この記事は約5230文字で、全文を読むには約8分かかります

イーサリアムの将来、データの可用性、レイヤー 2 の役割の変化。

AI要約

展開

イーサリアムの将来、データの可用性、レイヤー 2 の役割の変化。

制作者 - Odaily

コンピレーション - ルーピー・ルー

本日、Vitalik Buterin がイーサリアムコミュニティに「組み込みの ZK-EVM はどのようなものになるでしょうか?」というタイトルの記事を公開しました。》新着記事です。この記事では、イーサリアムが将来のネットワークアップグレードにどのように独自の ZK-EVM を組み込むかについて説明します。

ご存知のとおり、イーサリアムの開発が遅いという状況の中で、現在、ほとんどすべてのメインストリームのレイヤー 2 に ZK-EVM があります。イーサリアムのメインネットが独自の ZK-EVM をカプセル化するとき、メインネットとレイヤー 2 には役割の位置付けがありますか? 競合についてはどうなりますか? ?レイヤ 1 とレイヤ 2 はどのように効果的に分割し、連携できるでしょうか?

この記事では、Vitalik Buterin が互換性、データの可用性、監査可能性の重要性を強調し、効率的でステートフルな証明者を実装する可能性を探ります。さらに、この記事では、効率を高めるためにステートフル証明者を実装する可能性を検討し、高速な事前確認および MEV 軽減戦略を提供する際のレイヤー 2 プロジェクトの役割について説明します。この記事では、ZK-EVM を通じてイーサリアムネットワークの開発を進めながら、イーサリアムネットワークの柔軟性を維持するバランスについて考察します。

Odaily は原文を次のように編集しました。

Ethereum 上のレイヤ 2 EVM プロトコルとして、オプティミスティックロールアップと ZK ロールアップはどちらも EVM 検証に依存します。ただし、これには大規模なコードベースを信頼する必要があり、このコードベースにバグがある場合、これらの仮想マシンはハッキングされる危険にさらされます。これは、ZK-EVM が L1 EVM と完全に同等であり続けることを望んでいる場合でも、L1 EVM の変更を独自の EVM 実装にコピーするには何らかの形のガバナンスが必要になることも意味します。

これは理想的な状況ではありません。これらのプロジェクトはイーサリアムプロトコルにすでに存在する機能をそれ自体にコピーしているため、イーサリアムガバナンスはすでにアップグレードとバグ修正を担当しており、ZK-EVM は基本的にレイヤー 1 イーサリアムブロックを検証する仕事を行っています。今後数年間で、ライトクライアントはますます強力になり、間もなく ZK-SNARK を使用して L1 EVM の実行を完全に認証できるようになることが予想されます。その時点で、イーサリアムネットワークには実際にカプセル化された ZK-EVM が存在します。そこで疑問が生じます。なぜこの ZK-EVM をロールアップでもネイティブに利用できるようにしないのですか?

この記事では、「パッケージ内の ZK-EVM」のいくつかのバージョンについて説明し、それらのトレードオフ、設計上の課題、および特定の方向に進まない理由を分析します。プロトコル機能を実装する利点は、エコシステムにトランザクションを処理させ、基礎となるプロトコルをシンプルに保つことの利点と比較する必要があります。

パッケージ化された ZK-EVM から得たい主な機能は何ですか?

基本機能: Ethereumブロックを検証します。プロトコル関数 (オペコード、プリコンパイル、またはその他のメカニズムであるかどうかはまだ決定されていません) は、少なくとも前状態のルート、ブロック、および後状態のルートを入力として受け入れ、後状態であることを検証できる必要があります。ステートルートは実際には、このブロックの実行結果である前のステートルートの上にあります。イーサリアムのマルチクライアントに対応。これは、単一の証明システムを組み込むことを避け、代わりに異なるクライアントが異なる証明システムを使用できるようにしたいことを意味します。

これには次のような意味もあります。

データ可用性の要件:カプセル化された ZK-EVM 証明を使用する EVM 実行では、基礎となるデータが利用可能であることを確認して、異なる証明システムを使用する証明者が実行を再証明でき、その証明システムに依存するクライアントがこれらの新しく生成された証明を検証できるようにしたいと考えています。。

証明はEVMとブロックデータ構造の外側にあります：ZK-EVM 機能は、実際には SNARK を EVM 内の入力として受け入れません。これは、クライアントが異なれば予期される SNARK のタイプも異なるためです。代わりに、これは BLOB 検証に似ている可能性があります。トランザクションには、証明する必要があるクレーム (事前状態、ブロック本体、事後状態) を含めることができ、これらのクレームの内容にはオペコードまたはプリコンパイルによってアクセスでき、クライアントのコンセンサスルールはデータの可用性とブロック内で行われた主張の証明を確認します。

監査可能性:何らかの実行が証明された場合は、問題が発生した場合にユーザーと開発者の両方が検査できるように、基礎となるデータを利用できるようにしたいと考えています。実際、これにより、データ可用性要件が重要である理由が 1 つ増えます。

アップグレード可能性:特定の ZK-EVM ソリューションでバグが発見された場合、それを迅速に修正できるようにしたいと考えています。これは、問題を解決するためにハードフォークが必要ないことを意味します。これにより、EVM およびブロックデータ構造の外部での証明が重要であるもう 1 つの理由が追加されます。

「近似EVM」のサポート:L2 の魅力の 1 つは、実行層で革新し、EVM を拡張できることです。特定の L2 の VM が EVM とわずかに異なる場合、L2 が EVM と同じ部分にネイティブのプロトコル内 ZK-EVM を使用し、異なる部分の処理には独自のコードのみに依存できれば良いでしょう。これは、呼び出し元がビットフィールド、オペコード、またはアドレスのリストを指定できるように ZK-EVM 機能を設計することで実現できます。これらは、EVM 自体ではなく外部から提供されるテーブルによって処理されます。ガス料金もある程度カスタマイズ可能です。

「オープン」マルチクライアントシステムと「クローズド」マルチクライアントシステム

「マルチクライアントのアイデア」は、おそらくこのリストの中で最も物議を醸している要件です。 1 つのオプションは、マルチクライアントを放棄し、設計を簡素化する ZK-SNARK スキームに焦点を当てることです。しかし、その代償はイーサリアムにとってより大きな「哲学的変化」であり（これは実際にはイーサリアムの長年にわたるマルチクライアントの考え方を放棄することになるため）、より大きなリスクの導入となる。長期的な将来、例えば形式的な検証技術が向上した場合には、この方法を選択する方が良いかもしれませんが、現時点ではリスクが高すぎるように思えます。

もう 1 つのオプションは、プロトコル内で既知の固定の認証システムのセットが存在するクローズドマルチクライアントシステムです。たとえば、PSE ZK-EVM、Polygon ZK-EVM、および Kakarot の 3 つの ZK-EVM を使用することを決定する場合があります。ブロックが有効であるためには、これら 3 つのうち少なくとも 2 つからの証明が必要です。これは単一の証明システムよりも優れていますが、ユーザーは存在するすべての証明システムのバリデータを維持する必要があり、新しい証明システムを組み込むためにガバナンスプロセスが避けられないため、システムの適応性が低くなります。

このため、私はプルーフが「ブロックの外側」に配置され、クライアントによって個別に検証される、オープンなマルチクライアントシステムを好むようになりました。個々のユーザーは、ブロックを検証するために任意のクライアントを使用します。また、その証明システムの証明を作成する証明者が少なくとも 1 人いる限り、これを行うことができます。プルーフシステムは、プロトコルガバナンスプロセスを説得することではなく、ユーザーにそれを実行するよう説得することによって影響力を獲得します。ただし、このアプローチには、後で説明するように、より複雑なコストがかかります。

ZK-EVM 実装にはどのような重要な機能が必要ですか?

基本的な機能の正確性とセキュリティの保証に加えて、最も重要な属性は速度です。組み込みの ZK-EVM 関数を使用して非同期プロトコルを設計し、各ステートメントが N スロット後の結果のみを返すように設計することは可能ですが、証明が数秒で生成されることが確実に保証できれば、問題はより簡単になります。多数あるため、各ブロックで何が起こるかは自給自足です。

現在、イーサリアムブロックの証明を生成するには数分から数時間かかりますが、大規模な並列化を妨げる理論的な理由はありません。ブロックの実行のさまざまな部分を個別に証明するのに十分な GPU を常に集め、再帰的 SNARK を使用してこれらの証明を組み合わせることができます。。さらに、FPGA および ASIC によるハードウェアアクセラレーションにより、証明プロセスをさらに最適化できます。ただし、これを実際に達成することは、過小評価すべきではないエンジニアリング上の課題です。

プロトコル内の ZK-EVM 機能は正確にはどのようなものですか?

EIP-4844 BLOB トランザクションと同様に、ZK-EVM クレームを含む新しいトランザクションタイプを導入しました。

class ZKEVMClaimTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
transaction_and_witness_blob_pointers: List[VersionedHash]
...

EIP-4844 と同様、mempool に渡されるオブジェクトはトランザクションの修正バージョンです。

class ZKEvmClaimNetworkTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
proof: bytes
transaction_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]

後者を前者に変換することはできますが、その逆はできません。また、ブロックサイドカーオブジェクト (EIP-4844 で導入) を拡張して、ブロック内で宣言された証明のリストを含めました。

実際には、サイドカーを 2 つの別個のサイドカー (ブロブ用と証明用に 1 つ) に分割し、証明の種類ごとに別個のサブネット (ブロブの追加サブネット用に 1 つ) を用意する必要があることに注意してください。

コンセンサス層では、クライアントがブロック内の各クレームの有効な証拠を確認した場合にのみブロックを受け入れるという検証ルールを追加しました。証明は、ZK-SNARK 証明、シリアル化されたtransaction_and_witness_blobs のペア、および (i) valid を使用する pre_state_root と、(ii) 正しい post_state_root を出力する Witness を連結したものである必要があります (ブロック、監視)。 multiple 型証明の M-of-N。

ここで 1 つの注意点は、ブロックの実行自体は単に 3 つの要素 (σpre、σpost、Proof) として見なすことができ、ZKEVMClaimTransaction オブジェクトで提供される 3 つの要素と一緒にチェックする必要があるということです。

したがって、ユーザーの ZK-EVM 実装はその実行クライアントを置き換えることができます。実行クライアントは、(i) 証明者とブロックビルダー、および (ii) ローカルで使用するデータのインデックス作成と保存を行うノードによって引き続き使用されます。

検証と再検証

2 つの Ethereum クライアントがあり、1 つは PSE ZK-EVM を使用し、もう 1 つは Polygon ZK-EVM を使用しているとします。この時点で、両方の実装がイーサリアムブロックの実行を 5 秒で証明できるところまで進化しており、各証明システムには証明を生成するハードウェアを実行する十分な独立したボランティアがいると仮定します。

残念ながら、独立した証明システムが組み込まれていないため、プロトコルでインセンティブを与えることはできませんが、証明者の実行コストは研究開発コストに比べて低いと予想されるため、証明者に共通の権限を使用するだけで済みます。公共財に資金を提供します。

誰かが ZKEvmClaimNetworkTransaction をリリースするが、リリースされるのは PSE ZK-EVM 証明のバージョンのみであるとします。 Polygon ZK-EVM の証明ノードはこれを認識し、Polygon ZK-EVM の証明を使用してオブジェクトを計算し、再公開します。

これにより、ブロックを受け入れる最も早い正直なノードと同じブロックを受け入れる最も新しい正直なノードの間の合計最大遅延が増加します δ: 2 δ + Tprove (Tprove を仮定すると)<5 s ）。

ただし、良いニュースは、単一スロットのファイナリティを採用すると、SSF 固有のマルチラウンドコンセンサスレイテンシとともに、この追加のレイテンシをほぼ確実に「パイプライン化」できることです。たとえば、4 つのサブスロットの提案では、「先頭投票」ステップではベースブロックの有効性のチェックのみが必要ですが、「凍結と確認」ステップでは存在証明が必要になります。

拡張機能: 「近似EVM」のサポート

ZK-EVM 機能の理想的な目標は、「準 EVM」、つまりいくつかの追加機能が組み込まれた EVM をサポートすることです。これには、新しいプリコンパイル、新しいオペコード、さらには EVM またはまったく異なる仮想マシン (Arbitrum Stylus など) でコントラクトを作成できるオプション、さらには同期された相互通信 EVM による複数の並列処理が含まれる可能性があります。

一部の変更は簡単な方法でサポートできます。ZKEVMClaimTransaction が変更された EVM ルールの完全な記述を渡すことを可能にする言語を定義できます。これは次のように行うことができます。

カスタムガステーブル (ユーザーはガスコストを減らすことはできませんが、増やすことはできます)
特定のオペコードを無効にする
ブロック番号を設定します (これはハードフォークに応じて異なるルールを意味します)
L1 の使用ではなく L2 の使用のために標準化された一連の EVM 変更、またはその他のより単純な変更をアクティブにするフラグを設定します。

新しいプリコンパイル (またはオペコード) を導入することで、ユーザーがよりオープンな方法で新しい機能を追加できるようにするために、プリコンパイルされた入出力レコードを ZKEVMClaimNetworkTransaction の BLOB に追加できます。

class PrecompileInputOutputTranscript(Container):
used_precompile_addresses: List[Address]
inputs_commitments: List[VersionedHash]
outputs: List[Bytes]

EVM の実行は次のように変更されます。空の入力配列を初期化します。 used_precompile_addresses のアドレスが呼び出されるたびに、InputsRecord(callee_address, Gas, input_calldata) オブジェクトを入力に追加し、呼び出しの RETURNDATA を Outputs[i] に設定します。最後に、used_precompile_addresses が合計 len(outputs) 回呼び出されたこと、および inputs_commitments が BLOB コミットメントを生成する入力の SSZ シリアル化の結果と一致することを確認します。 inputs_commitments を公開する目的は、外部 SNARK が入力と出力の間の関係を証明しやすくすることです。

入力と出力の非対称性に注意してください。入力はハッシュに格納され、出力は提供する必要があるバイトに格納されます。これは、入力のみを参照して EVM を理解するクライアントによって実行を実行する必要があるためです。 EVM の実行により入力がすでに生成されているため、生成された入力が要求された入力と一致することを確認するだけで済みます。これにはハッシュチェックのみが必要です。ただし、出力は完全に提供される必要があるため、使用可能なデータでなければなりません。

もう 1 つの便利な機能は、任意の送信者アカウントから呼び出すことができる「特権トランザクション」を許可することです。これらのトランザクションは、他の 2 つのトランザクション間で実行することも、プリコンパイルが呼び出されたときに、別の (おそらく特権付きの) トランザクションの一部として実行することもできます。これを使用すると、非 EVM メカニズムが EVM にコールバックできるようになります。

この設計は、新規または変更されたプリコンパイルに加えて、新規または変更されたオペコードをサポートするように変更される場合があります。プリコンパイルだけでも、この設計は非常に強力です。例えば：

used_precompile_addresses を設定して状態に特定のフラグを持つ通常のアカウントアドレスのリストを含め、SNARK を作成して正しく構築されたことを証明することで、EVM または WASM (または別の) を使用してコントラクトを作成できる Arbitrum Stylus スタイルの機能をサポートできます。 VM)。特権トランザクションを使用すると、WASM アカウントが EVM にコールバックできるようになります。
外部チェックを追加して、複数の EVM によって実行される入出力レコードと特権トランザクションが正しい方法で一致していることを確認することで、同期チャネルを介して相互に通信する複数の EVM の並列システムを証明できます。
タイプ 4 の ZK-EVM は、複数の実装を使用して操作できます。1 つは、Solidity または別の高水準言語を SNARK 対応 VM に直接変換し、もう 1 つは、それを EVM コードにコンパイルして ZK-EVM 実装に組み込みます。 2 番目の (必然的に遅くなる) 実装は、障害証明者がバグをアサートするトランザクションを送信し、両方のトランザクションを異なる方法で処理できる場合に報奨金を徴収する場合にのみ実行できます。
純粋な非同期 VM は、すべての呼び出しでゼロを返し、その呼び出しをブロックの最後に追加された特権トランザクションにマッピングすることで実装できます。

拡張機能: ステートフル証明者のサポート

上記の設計の課題の 1 つは、完全にステートレスであるため、データ効率が非効率になることです。理想的なデータ圧縮では、ステートフル圧縮を使用して ERC 20 を送信すると、ステートフル圧縮のみよりも最大 3 倍のスペース効率が向上します。

さらに、ステートフル EVM では、証人データを提供する必要はありません。どちらの場合も原則は同じです。以前の EVM 実行で入力または生成されたデータであるため、データが利用可能であることがすでにわかっているときに、データを利用可能にすることを要求するのは無駄です。

ZK-EVM 機能をステートフルにしたい場合、次の 2 つのオプションがあります。

1) σpre が空、宣言されたキーと値を持つ利用可能なデータのリスト、または以前に実行された σpost のいずれかである必要があります。

２）ブロック生成されたレシートＲへのブロブコミットメントを（σｐｒｅ、σｐｏｓｔ、Ｐｒｏｏｆ）トリプレットに追加する。ブロック、証人、レシート、または単純な EIP-4844 BLOB トランザクションを表すものを含む、以前に生成または消費された BLOB コミットメントには、一定の時間制限がある場合があり、ZKEVMClaimTransaction で参照され、その実行中に (おそらく一連の命令を通じて) アクセスされる可能性があります。「コミットメント i のバイト N...N+k-1 をブロック + 証人データの位置 j に挿入します」)。

オプション 1 は、組み込みのステートレス EVM 検証の代わりに、EVM サブチェーンを構築することを意味します。オプション 2 は基本的に、以前に使用または生成された BLOB を辞書として使用する最小限の組み込みステートフル圧縮アルゴリズムを作成することです。どちらの方法でも証明者ノードに負担がかかりますが、より多くの情報を保存する必要があるのは証明者ノードだけです。ケース 2 の場合、ケース 1 よりもこの負担を時間制限する方が簡単です。

クローズドな複数の証明者とオフチェーンデータのパラメーター

M-of-N 構造で固定数の証明者が存在するクローズドマルチ証明者システムでは、上記の複雑さの多くが回避されます。特に、クローズドなマルチ認証者システムでは、データがオンチェーンに存在するかどうかを心配する必要はありません。さらに、クローズドマルチ証明者システムにより、ZK-EVM 証明をオフチェーンで実行できるようになり、EVM プラズマソリューションとの互換性が得られます。

ただし、閉鎖的な複数の認証者システムはガバナンスの複雑さを増大させ、監査可能性を排除します。これは、これらの利点と比較検討する必要がある高いコストです。

ZK-EVMを組み込んでプロトコル機能とした場合、「レイヤ2プロジェクト」の役割は何でしょうか?

現在レイヤ 2 チーム自体によって実装されている EVM 検証機能はプロトコルによって処理されますが、レイヤ 2 プロジェクトは引き続き多くの重要な機能を担当します。

高速な事前確認: 単一スロットのファイナリティによってレイヤー 1 スロットの速度が低下する可能性があり、レイヤー 2 プロジェクトはすでに、レイヤー 2 独自のセキュリティに裏付けられた「事前確認」を 1 つのスロットではるかに低い遅延でユーザーに提供しています。このサービスは引き続きレイヤー 2 によって完全に管理されます。
MEV (マイナー抽出可能値) 軽減戦略: これには、暗号化されたメモリプール、レピュテーションベースの順序付け者の選択、およびレイヤー 1 が実装したくないその他の機能が含まれる場合があります。
EVM の拡張: レイヤ 2 プロジェクトは、EVM の重要な拡張機能をユーザーに提供できます。これには、「近似 EVM」と、Arbitrum Stylus の WASM サポートや SNARK に適した Cairo 言語などの根本的に異なるアプローチが含まれます。
ユーザーと開発者の利便性: レイヤ 2 チームは、ユーザーとプロジェクトをエコシステムに引き付け、歓迎されていると感じてもらうために多くの作業を行っており、ネットワーク内の MEV と輻輳料金を取得することで報酬を得ています。この関係はこれからも続いていくでしょう。