投資
ローンチパッド
CandyDrop
キャンディーを集めてエアドロップを獲得
Launchpool
クイックステーキング
潜在的な新しいトークンを獲得しよう
HODLer Airdrop
GTを保有して、大量のエアドロップを無料で入手
Launchpad
次の大きなトークンプロジェクトを一足先に
Alphaポイント
NEW
オンチェーン資産を取引して、Airdrop報酬を楽しもう！
先物ポイント
NEW
先物ポイントを獲得し、Airdrop報酬を受け取りましょう。
株式トークン化デプスレポート：ブル・マーケット第二上昇曲線を開く
2025-07-24 13:37
SECの被告からウォールストリートの鐘を鳴らす人へ、素晴らしい「ゲイツサン」が力強く権力のゲームを演じる
2025-07-24 07:59
人気の話題
もっと見る19.59K 人気度
54.99K 人気度
65.39K 人気度
92.27K 人気度
4.56K 人気度
人気の Gate Fun
もっと見る- 時価総額:$3.7K保有者数:20.10%
- 時価総額:$3.6K保有者数:10.00%
- 時価総額:$3.59K保有者数:10.00%
- 時価総額:$3.71K保有者数:20.41%
- 時価総額:$19.5K保有者数:18548.93%
ピン
V Shen Xinwen: ETH Fang ビルトイン ZK の後、Layer2 はどこへ向かうのでしょうか?
プロデュース | Odaily(オデイリー)
コンパイル | ルーピー・ルー
本日、Vitalik Buterinは、ETHコミュニティに「What might a built-in ZK-EVM look like?」と題する新しい記事を公開しました。 この記事ではETHワークショップが将来のネットワークアップグレードに独自のZK-EVMをどのように組み込むかを探ります。
ご存知のように、ETHの開発が遅いという状況では、ほとんどすべての主流のレイヤー2がすでにZK-EVMを持っていますが、ETHワークショップのメインネットが独自のZK-EVMをカプセル化した場合、メインネットとレイヤー2の役割の位置付けの間に矛盾が生じるのでしょうか?
この記事では、Vitalik Buterin が互換性、データの可用性、監査可能性の重要性を強調し、効率的でステートフルなアテスターを実装する可能性を探ります。 さらに、この記事では、効率のためにステートフルな証明を実装する可能性を探り、迅速な事前確認とMEV緩和戦略を提供する上でのレイヤー2プロジェクトの役割について説明します。 本稿では、ZK-EVMによるETHネットワークの開発を進めながら、その柔軟性を維持するというバランスについて考察します。
**Odaily Planet Dailyが元の記事をまとめたもので、記事の全文は以下の通りです。
オプティミスティック・ロールアップとZKロールアップは、ETH上のレイヤ2 EVMプロトコルであり、どちらもEVM検証に依存しています。 ただし、これには大規模なコードベースを信頼する必要があり、このコードベースにバグがある場合、これらのVMはハッキングされるリスクがあります。 また、ZK-EVMは、L1 EVMと完全に同等にしたい場合でも、L1 EVMの変更を独自のEVM実装に複製するために、何らかのガバナンスが必要になることも意味します。
これは理想的な状況ではありません。 これらのプロジェクトは、ETH Workshop Protocolにすでに存在する機能を複製しているため、ETH Governanceはすでにバグのアップグレードと修正を担当しており、ZK-EVMが基本的に行うことは、レイヤー1 ETHブロックの検証です。 今後数年間で、ライトクライアントはますます強力になり、まもなくZK-SNARKを使用してL1 EVMの実行を完全に検証できるようになると予想されます。 その時点で、ETHネットワークは実際にZK-EVMをパッケージに収めていることになります。 そこで、このZK-EVMをロールアップでもネイティブに利用できるようにしてはどうか、という疑問が湧いてきます。
本稿では、「カプセル化されたZK-EVM」のいくつかのバージョンについて説明し、それらのトレードオフ、設計上の課題、および特定の方向に進まない理由を分析します。 プロトコルの機能を実装することの利点は、エコシステムにトランザクションを処理させ、基盤となるプロトコルをシンプルに保つことの利点と比較する必要があります。
カプセル化された ZK-EVM に求める主な機能は何ですか?
パッケージ化されたZK-EVMに期待できる主な特性は何ですか?
基本機能:ETHブロックを検証します。 プロトコル関数 (オペコード、プリコンパイル、またはその他のメカニズムのいずれであるかはまだ決定されていません) は、少なくとも前状態ルート、ブロック、および後状態ルートを入力として受け入れ、後状態ルートが実際に前状態ルート上でそのブロックを実行した結果であることを検証できる必要があります。 ETH Workshopのマルチクライアントと互換性があります。 つまり、単一の構成証明システムが組み込まれることは避け、代わりに、異なるクライアントが異なる構成証明システムを使用できるようにする必要があります。
これには、いくつかの意味もあります。
データ可用性の要件:カプセル化されたZK-EVMプルーフを使用するEVM実行では、別のアテステーションシステムを使用しているプルーバーが実行を再アテストでき、そのアテステーションシステムに依存するクライアントが新しく生成されたプルーフを検証できるように、基礎となるデータが使用可能であることを保証する必要があります。
証明はEVMとチャンクデータ構造の外部に存在する:ZK-EVMの機能は、クライアントごとに異なるタイプのSNARKを期待するため、実際にはEVM内の入力としてSNARKを受け付けません。 代わりに、BLOB 検証に似ているかもしれません: トランザクションには、証明する必要がある要求 (事前状態、ブロック本文、事後状態) を含めることができ、その内容はオペコードまたはプリコンパイルによってアクセスでき、クライアント側のコンセンサス ルールは、データの可用性とブロックで行われた要求の証明をそれぞれチェックします。
監査可能性: 実行が証明された場合、何か問題が発生した場合にユーザーと開発者の両方が検査できるように、基になるデータを使用できるようにする必要があります。 実際、これにより、データ可用性の要件が重要である理由がもう 1 つ追加されます。
アップグレード性:特定のZK-EVMソリューションにバグが見つかった場合、迅速に修正できるようにしたいと考えています。 これは、問題を解決するためにハードフォークの必要がないことを意味します。 これは、EVMとブロックデータ構造の外側の証明が重要であるもう一つの理由です。
「近似EVM」:**L2をサポートする魅力の1つは、実行層でのイノベーションとEVMのスケーリングができることです。 L2 VM が EVM とわずかに異なるだけであれば、L2 が EVM と同じ部分にネイティブのプロトコル内 ZK-EVM を使用し、異なる部分を処理するために独自のコードのみに依存できると便利です。 これは、呼び出し側がビット・フィールド、オペコード、またはアドレス・リストを指定できる ZK-EVM 機能を設計することで実現でき、EVM 自体ではなく、外部から提供されたフォームで処理されます。 また、ガス代をある程度カスタマイズすることもできます。
「オープン」と「クローズド」のマルチクライアントシステム
「マルチクライアントメンタリティ」は、おそらくこのリストの中で最も物議を醸す要件です。 1つの選択肢は、マルチクライアントを放棄し、設計を簡素化する1つのZK-SNARKスキームに集中することです。 しかし、その代償として、ETH Workshopの大きな「哲学的転換」が起こり(これは、ETH Workshopの長年のマルチクライアントの考え方を事実上放棄することになる)、より大きなリスクをもたらすことになる。 長期的には、例えば、形式的な検証技術が向上すれば、このルートを行く方が良いかもしれませんが、今のところはリスクが高すぎるようです。
もう 1 つのオプションは、プロトコル内で認識される構成証明システムの固定セットを持つクローズド マルチクライアント システムです。 たとえば、PSE ZK-EVM、Polygon ZK-EVM、Kakarot の 3 つの ZK-EVM を使用することにします。 ブロックが有効であるためには、これら3つのうち少なくとも2つの証明が必要です。 これは単一の証明システムよりはましですが、ユーザーは存在する証明システムごとにバリデーターを維持しなければならないため、システムの適応性が低くなります。
このため、証明が「ブロックの外側」に配置され、クライアントによって個別に検証されるオープンなマルチクライアントシステムを好むようになりました。 個々のユーザーは、ブロックの検証に任意のクライアントを使用し、少なくとも1人の証明者がその構成証明システムの証明を作成する限り、検証を行うことができます。 構成証明システムは、プロトコル ガバナンス プロセスを納得させるのではなく、ユーザーに実行を納得させることで影響力を獲得します。 ただし、このアプローチには、後で説明するように、より複雑なコストがかかります。
ZK-EVMの実装に求める主な機能は何ですか?
基本的な機能の正確性と安全性の保証に加えて、最も重要な属性は速度です。 ZK-EVM機能を内蔵した非同期プロトコルを設計し、各クレームがNスロット後にのみ結果を返すようにすることは可能ですが、数秒で証明が生成され、各ブロックで起こることが自己完結するように確実に保証できれば、問題ははるかに簡単になります。
現在、ETHブロックの証明を生成するのに数分から数時間かかりますが、大量並列化を妨げる理論的な理由はないことがわかっています:ブロック実行のさまざまな部分を個別に証明するのに十分なGPUをいつでも組み立て、再帰的なSNARKを使用してそれらの証明をまとめることができます。 さらに、プルーフプロセスは、FPGAとASICのハードウェアアクセラレーションによってさらに最適化できます。 しかし、実際にそこにたどり着くことは、過小評価してはならないエンジニアリング上の課題です。
ZK-EVM機能はプロトコルで具体的にどのように見えますか?
EIP-4844 BLOB トランザクションと同様に、ZK-EVM 要求を含む新しいトランザクションの種類が導入されています。
EIP-4844 と同様に、mempool で渡されるオブジェクトは、トランザクションの修正バージョンです。
後者は前者に変換できますが、その逆はできません。 また、ブロックサイドカーオブジェクト(EIP-4844で導入)を拡張し、ブロックで宣言された証明のリストを含めました。
実際には、サイドカーを 2 つの個別のサイドカー (1 つは BLOB 用、もう 1 つは構成証明用) に分割し、証明の種類ごとに個別のサブネット (および BLOB 用の追加のサブネット) を設定することもできます。
コンセンサスレイヤーでは、クライアントがブロック内の各クレームの有効な証拠を見た場合にのみブロックを受け入れる検証ルールを追加しました。 証明はZK-SNARK証明を連結したもので、トランザクション_and_witness_blobsのペアとしてシリアル化され、(i)とWitness(ii)で有効なpre_state_rootは正しいpost_state_rootを出力する必要があります。 (ブロック、証人) 場合によっては、顧客は複数のタイプの証明のために M-of-N を待つことを選択できます。
ここでの注意点は、ブロックの実行自体は、ZKEVMClaimTransactionオブジェクト(σpre、σpost、Proof)で提供されるトリプルとともにチェックする必要があるトリプレットと考えることができるということです。
その結果、ユーザーのZK-EVM実装は、(i)プルーバーとブロックビルダー、および(ii)ローカルで使用するためのデータのインデックス作成と保存を重視するノードによって引き続き使用される実行クライアントを置き換えることができます。
検証と再検証
たとえば、2 つの ETH クライアントがあり、そのうちの 1 つが PSE ZK-EVM を使用し、もう 1 つが Polygon ZK-EVM を使用しているとします。 この時点で、両方の実装が、ETHブロックの実行を 5 秒未満で証明できるところまで進化し、各証明システムについて、証明を生成するのに十分なハードウェアを実行する独立したボランティアがいると仮定します。
残念ながら、独立した認証システムは組み込まれていないため、プロトコルでインセンティブを与えることはできませんが、証明者の運営コストは研究開発のコストに比べて低いと予想されるため、証明者のための公共財に資金を提供するために一般的な機関を使用するだけでよいでしょう。
例えば、誰かがZKEvmClaimNetworkTransactionをリリースしたが、PSE ZK-EVMプルーフのバージョンしかリリースしていないとします。 Polygon ZK-EVMのプルーフノードはこれを見て、Polygon ZK-EVMのプルーフを使用してオブジェクトを計算して再公開します。
これにより、ブロックを受け入れる最も古い正直なノードと、同じブロックを受け入れる最新の正直なノードの間の最大遅延の合計が増加します δ:2 δ+Tprove(Tprove<5秒と仮定)。
しかし、良いニュースは、スロットのファイナリティを取ると、SSFに固有のマルチラウンドコンセンサスレイテンシーとともに、ほぼ確実にこの余分なレイテンシーを「パイプライン化」できることです。 たとえば、4スロットのプロポーザルでは、「ヘッド投票」ステップはベースブロックの有効性を確認するだけで済みますが、「凍結して確認する」ステップでは存在の証明が必要になります。
拡張機能: “Approximate EVM” のサポート
ZK-EVM機能の理想的な目標は、「近似EVM」、つまりいくつかの追加機能を内蔵したEVMをサポートすることです。 これには、新しいプリコンパイル、新しいオペコード、さらにはEVMやまったく異なる仮想マシン(Arbitrum Stylusなど)でコントラクトを記述できるオプション、さらには同期クロスコミュニケーションを備えた複数の並列EVMなどが含まれます。
いくつかの変更は簡単な方法でサポートできます:ZKEVMClaimTransactionが修正されたEVMルールの完全な記述を渡すことを可能にする言語を定義することができます。 これは、次の方法で実行できます。
*カスタムガステーブル(ユーザーはガスコストを削減できませんが、増やすことはできます) *特定のオペコードを無効にする *ブロック番号を設定します(これはハードフォークに応じて異なるルールを意味します)
ユーザーがよりオープンな方法で新しい機能を追加できるようにするために、新しいプリコンパイル(またはオペコード)を導入することで、ZKEVMClaimNetworkTransactionのblobにプリコンパイルされた入出力レコードを含めることができます。
EVM の実行は次のように変更されます。 空の入力配列を初期化します。 used_precompile_addresses のアドレスが呼び出されるたびに、入力に InputsRecord(callee_address, gas, input_calldata) オブジェクトを追加し、呼び出しの RETURNDATA を出力に設定します[i]。 最後に、used_precompile_addresses が合計で len(outputs) 呼び出されたこと、および inputs_commitments が入力の SSZ をシリアル化することによって約束された結果と一致することを確認します。 inputs_commitments を公開する目的は、外部の SNARK が入力と出力の関係を証明しやすくすることです。
入力と出力の非対称性に注意し、入力はハッシュに格納され、出力は指定する必要があるバイトに格納されます。 これは、入力のみを見てEVMを理解するクライアントによって実行する必要があるためです。 EVMの実行では、すでに入力が生成されているため、生成された入力が要求された入力と一致するかどうかをチェックするだけでよく、ハッシュチェックのみが必要です。 ただし、出力は全体を提供する必要があるため、使用可能なデータである必要があります。
もう1つの便利な機能は、任意の送信者アカウントから呼び出すことができる「特権トランザクション」を許可することです。 これらのトランザクションは、他の 2 つのトランザクション間で実行することも、プリコンパイルが呼び出されたときに別の (場合によっては特権のある) トランザクションの一部として実行することもできます。 これを使用すると、非EVMメカニズムをEVMにコールバックできます。
この設計は、新規または変更されたプリコンパイルに加えて、新規または変更されたオペコードをサポートするように変更できます。 プリコンパイルのみでも、この設計は非常に強力です。 例えば：
拡張機能: ステートフル認証者のサポート
上記の設計の課題の 1 つは、完全にステートレスであるため、データの効率が悪いことです。 理想的なデータ圧縮の場合、ステートフル圧縮を使用したERC 20送信は、ステートオンリー圧縮よりも最大3倍のスペース効率が得られます。
さらに、ステートフルなEVMは、監視データを提供する必要はありません。 どちらの場合も、原則は同じで、以前のEVM実行で入力または生成されたデータによってデータが使用可能であることがすでにわかっている場合、データが利用可能であることを尋ねるのは無駄です。
ZK-EVM 機能にステートを持たせるには、次の 2 つのオプションがあります。
1)応募資格 σpre 空であるか、キーと値が宣言された使用可能なデータのリストであるか、特定の時間より前に実行されます σポスト 。
2)に向けて ( σpre、 σpost、 証拠 ) トリプルは、ブロックに対して生成されたレシートを追加します。 R BLOB コミットメントの。 ブロック、証人、レシート、またはプレーンなEIP-4844 BLOBトランザクションを表すものを含む、以前に生成または使用されたBLOBコミットメントには、ZKEVMClaimTransactionで参照され、実行中にアクセスできる時間制約がある場合があります(おそらく一連の命令を介して)。 私 The bytes of N… N+k-1 がチャンク + witness データに挿入されます J "）。
オプション1は、ステートレスなEVM検証を組み込むのではなく、EVM子チェーンを組み込んだ方が良いことを意味します。 オプション 2 では、基本的に、以前に使用または生成された BLOB をディクショナリとして使用する最小限の組み込みステートフル圧縮アルゴリズムが作成されます。 どちらのアプローチも、より多くの情報を格納する必要がある唯一の証明ノードに負担をかけますが、2番目のケースでは、ケース1よりもこの負担に時間制限を設ける方が簡単です。
クローズドマルチサーバーとオフチェーンデータのパラメータ
M-of-N構造の証明数が固定されたクローズドマルチプルーバーシステムは、上記の複雑さの多くを回避します。 特に、クローズドなマルチプルーバーシステムは、データがオンチェーンであることを保証することを心配する必要はありません。 さらに、クローズドなマルチアテスタシステムにより、ZK-EVMプルーフをオフチェーンで実行できるため、EVMプラズマソリューションと互換性があります。
しかし、クローズドなマルチプルーバーシステムでは、ガバナンスが複雑になり、監査可能性が失われるため、これらのメリットと比較検討する必要がある高いコストがかかります。
そこにZK-EVMを組み込み、プロトコル機能にした場合、「レイヤー2プロジェクト」の役割は何でしょうか?
現在、レイヤー 2 チーム自身によって実装されている EVM 検証機能は、このプロトコルによって処理されますが、レイヤー 2 プロジェクトは依然として多くの重要な機能を担当しています。
*迅速な事前確認:単一のスロットのファイナリティはレイヤー1スロットの速度を低下させる可能性がありますが、レイヤー2プロジェクトは、単一のスロットよりもはるかに低いレイテンシーで、レイヤー2独自のセキュリティに裏打ちされた「事前確認」をすでにユーザーに提供しています。 このサービスは、引き続きレイヤー 2 の責任を完全に負います。