Vitalikのブログ記事を解釈する：イーサリアムにZK-EVMを内蔵する可能性を探る

2023.12.14

共有先

TechFlow厳選深潮セレクト

Vitalikのブログ記事を解釈する：イーサリアムにZK-EVMを内蔵する可能性を探る

イーサリアムは、今後ZK-EVMを単なる付加コンポーネントとして扱うだけではなくなるかもしれない。

2023.12.14 - 05:42:02

ZK-EVM以太坊

Web3業界の深掘り報道に専念し潮流を洞察

イーサリアムは、今後ZK-EVMを単なる付加コンポーネントとして扱うだけではなくなるかもしれない。

執筆：TechFlow

昨日、Vitalikは自身のブログで「What might an “enshrined ZK-EVM” look like?」という記事を更新し、イーサリアムへのZK-EVM統合の可能性やその方法、期待される効果などについて体系的に説明した。

EVMの将来の発展は、インフラ関連の複数のナラティブや方向性の変化と密接に関係しており、読む価値がある。

しかし、この記事には非常に多くの技術的詳細が含まれており、中国語メディアやコミュニティの大部分の資料は単に翻訳しているだけであるため、文章の前後関係や主張を把握することが難しい。

そこで、TechFlowはこの記事を解釈し、Vitalikの思考プロセスと主張をより平易な形で再現することで、読者の参考としたい。

タイトルの単語が示唆するもの：ZK-EVMを「奉じる」という意味

直訳された記事だけを見ると、英語本来のニュアンスや自然な表現を捉えにくい。

Vitalikのこの記事のタイトルには、あまり使われない英単語「enshrined」が登場する。

GPTや英語辞書を調べればわかるように、「enshrined」とはもともと「神聖視する」「崇める」という意味であり、ある物事や人物の地位・重要性・価値を極めて高いレベルにまで高め、まるで神聖な場所や保護された位置に安置することを表す。

法的または宗教的な文脈では、「enshrine」は特定の原則・権利・信仰を正式かつ敬意を持って記録・保存することを指す。

技術やソフトウェアの分野では、「enshrined」は特定の技術・機能・原則をシステム・フレームワーク・プロトコルに正式かつ重要な形で統合することを意味する。これは通常、当該技術や機能が基礎的・核心的・不可欠であると見なされ、公式かつ永続的にシステムに組み込まれることを意味する。

したがって、この記事のタイトルからVitalikの意図をすぐに読み取ることができる：

ゼロ知識証明（ZK）を備えたイーサリアム仮想機械（EVM）を、イーサリアムプロトコルのコアまたは公式な一部として統合する可能性を探っている。

つまり、今後イーサリアムはZK-EVMを単なる追加コンポーネントとして扱うのではなくなるかもしれないということだ。

ZK-EVMの過去：L2形式の「外付けコンポーネント」、非ネイティブ

イーサリアムEVMや関連L2ソリューションに馴染みのない読者にとって、VitalikがZK-EVMをメインネットの正式な一部とする議論は、次の疑問を生む：

従来、ZK-EVMとイーサリアムの関係はどうだったのか？以前のZK-EVMはイーサリアムの「正式部分」ではなかったのか？

軽く、簡潔に解説しよう：

イーサリアム仮想機械（EVM）：イーサリアムネットワークの中心であり、スマートコントラクトコードの実行を担当。イーサリアム上で動作するすべてのスマートコントラクトはEVMによって実行される。
ゼロ知識証明（ZK）：一方（証明者）が他方（検証者）に対してある命題が真であることを、その命題以外の情報を一切開示せずに証明できる暗号技術。暗号通貨やブロックチェーン分野では、取引のプライバシーとセキュリティ強化に用いられる。
ZK-EVMの役割：EVMの機能とゼロ知識証明によるプライバシー保護特性を組み合わせたもの。取引データを秘匿しつつ、その有効性を検証可能にする。つまり、取引内容を公開せずに、それがスマートコントラクトおよびブロックチェーンのルールに合致していることを証明できる。
ZK-EVMとイーサリアムメインネットの関係：ZK-EVMは、EVMとの互換性を保ちつつゼロ知識証明を導入するソリューションとして機能し、取引の秘匿性を実現する。初期段階では、ZK-EVMは主に第2層（Layer 2）ソリューションとして登場し、イーサリアムメインネット上に構築され、プライバシー保護と拡張性の追加機能を提供していた。

したがって、現在のZK-EVMは大半がL2の形態で存在し、イーサリアムL1の設計に直接組み込まれているわけではない。言い換えれば外部拡張コンポーネントである。

有名なZK-EVMソリューションとしては、Starknet、zkSync、Polygon Hermez、Scrollなどが知られている。

以上の背景知識があれば、Vitalikのブログを理解するのはずっと容易になる。

なぜイーサリアムにネイティブなZK-EVMを内蔵するのか？

上記の流れから、こう考えるだろう：ZK-EVMのL2ソリューションはうまく機能しているのに、なぜVitalikはZK-EVMをイーサリアムのコア設計に直接取り込むことを検討しているのか？

Vitalikは次のように簡潔に答えている：

大規模なコードベースへの依存：現在のLayer 2ソリューション（Optimistic RollupsやZK Rollupsなど）はEVM検証に依存しており、膨大なコードベースを信頼しなければならない。もしコードに脆弱性があれば、これらの仮想マシン（VM）はハッキングのリスクにさらされる。
ガバナンスの問題：L1 EVMと完全に等価であることを目指すZK-EVMであっても、L1 EVMの変更を自らのEVM実装に反映させるための何らかのガバナンス機構が必要となる。これにより複雑さと潜在的な不整合リスクが増す。
機能の重複：Layer 2プロジェクトは、すでにイーサリアムプロトコルに存在する機能をコピーしている。イーサリアムのガバナンスは既にアップグレードや脆弱性修正を担っている。ZK-EVMが本質的に行っている作業は、L1イーサリアムブロックの検証と同一である。
将来のライトクライアントの発展：ライトクライアントがますます強力になり、まもなくZK-SNARKsを使ってL1 EVMの実行を完全に検証できるようになる。するとイーサリアムネットワークは事実上、内蔵されたZK-EVMを持つことになる。ここで疑問が生じる：なぜRollupにもこのようなネイティブなZK-EVMを提供しないのか？

これらの問題を通じて、VitalikはZK-EVMをイーサリアムのコア設計に取り込む動機を明らかにしている――外部コードベースへの依存リスクを解決し、ガバナンスを簡素化し、機能の重複を減らし、イーサリアムネットワーク自体が持つ能力を活用するためである。

内蔵型ZK-EVMとは、どのような姿になるべきか？

では、イーサリアムがZK-EVMを内蔵する場合、どのような機能や特性を持つべきか？Vitalikはさらにアイデアを提示している：

基本機能：ZK-EVMの核となる機能はイーサリアムブロックの検証である。つまり、事前状態ルート（pre-state root）、ブロック、事後状態ルート（post-state root）を入力として受け取り、事後状態ルートが実際にそのブロック実行後の結果であることを検証できなければならない。
イーサリアムのマルチクライアント哲学との互換性：ZK-EVMは単一の証明システムに限定せず、異なるクライアントが異なる証明システムを使えるようにすべきである。これはデータ可用性の要件や、証明がEVMおよびブロックデータ構造から独立している必要があることを含む。
監査可能性：いかなる実行も証明された場合、問題発生時にユーザーと開発者が確認できるよう、基盤データは利用可能でなければならない。
アップグレード性：特定のZK-EVM方式に脆弱性が見つかった場合、ハードフォークなしで迅速に修正できるべきである。
almost-EVMs（ほぼ同じEVM）のサポート：ZK-EVMは実行面での革新やEVMの拡張をサポートすべきである。あるL2のVMがEVMとわずかに異なる場合でも、ネイティブなプロトコル内ZK-EVMを使ってEVMと同じ部分を処理し、異なる部分のみ自らのコードに依存すればよい。

なお、almost-EVMsという言葉に戸惑う読者もいるだろうが、実はVitalikは以前から同様の見解を示しており、ZK-EVMソリューションがEVMと厳密に同一である必要はなく、むしろ「ある程度似ている」程度でよいと考えている。

Vitalikが提唱するZK-EVMの枠組みにおいて、almost-EVMsのサポートは、さまざまなニーズやシナリオに柔軟に対応できることを意味する。これにより、標準EVM仕様を完全に遵守するアプリケーションだけでなく、わずかな調整を必要とするシステムも支援可能になる。

内蔵型ZK-EVMは、異なるイーサリアムクライアント上でどのように動作するか？

Vitalikの原文を続けて読むと、急にクライアントの話題に移り、混乱しやすい。

上記を振り返ると、Vitalikの論理展開は非常に明快である：

「ZK-EVMをイーサリアムの内蔵コンポーネントにしたい → なぜそれをしたいのか？ → そのためにはどんな機能が必要か？」

したがって、次の議論は自然とこうなる：具体的に、異なるクライアント上でどう実装・運用するか？

Vitalikは2つの方向を提示している：オープンなマルチクライアントシステムで動作させるか、クローズドなマルチクライアントシステムで動作させるか。

オープンシステム：イーサリアムの非中央集権化と革新精神により合致しており、コミュニティが必要に応じて新しい証明技術を開発・採用できる。
クローズドシステム：管理・メンテナンスは容易だが、長期的な適応性や革新の可能性を制限する恐れがある。

また、Vitalikは後半でZK-EVMにおける速度の重要性にも言及している。ZK-EVMが迅速に証明を生成できれば、イーサリアムメインプロトコルへの統合に適し、ネットワークのパフォーマンス要件やユーザーエクスペリエンスの期待に更好地応えられる。

ただし、これを実現するには大きな技術的・工学的課題を克服する必要がある。Vitalikはこの部分でそれらの課題を明確にし、可能な解決策やアプローチを提案している。

ZK-EVMはイーサリアム上で具体的にどう実装されるか？

VitalikはZK-EVMの実現方法の可能性も提示している。

彼は新しいトランザクスタイプ――ZK-EVM宣言トランザクション（ZKEVMClaimTransaction）を提案し、イーサリアムネットワーク内でこれらのトランザクションをどう処理・検証するかを説明している。

この部分は非常に技術的であるため、初心者は技術的詳細を飛ばしてもよい。ここでは彼の設計思想と概要を紹介する：

ZK-EVM関連の宣言をネットワーク内で伝達するためのコンテナータイプを導入。
コンセンサス層において新たなルールを提案：クライアントが各宣言の有効な証明を確認した後のみ、ブロックを受け入れる。
ユーザーはZK-EVMの証明中に実行クライアントを交換できるが、実行クライアントは依然として証明生成・ブロック構築・ノードのデータ保存・インデックス作成に使用される。
異なるZK-EVMの実装は異なる証明方法を持つ可能性があるが、互いに証明を検証・受容できる。

また、この部分でVitalikは「almost-EVMs」（イーサリアム仮想機械にほぼ等しいシステム）のサポートについても言及しており、これはZK-EVMの機能における望ましい目標である。

これらには追加機能が内蔵されており、新しいプリコンパイル契約、オペコード、契約記述オプション（標準EVMまたは全く異なる仮想マシン、例えばArbitrum Stylusなどでの記述選択可）、あるいは同期クロス通信をサポートする複数の並列EVMなどを含む。

同時に、Vitalik ButerinはZK-EVM内でのステートフル検証者（stateful verifier）のサポートとそのメリットについても議論している：

なぜステートフル検証者をサポートするのか？

データ効率：ステートフル検証者はデータ圧縮効率を向上させられる。完全にステートレスなシステムでは、すべてのデータが毎回トランザクションで利用可能でなければならないため、データの重複や無駄が生じる可能性がある。ステートフル検証者は以前の状態情報を保存できるため、送信・処理が必要なデータ量を削減できる。
データ冗長性の削減：あるデータ断片が前のブロックやトランザクションですでに提供されている場合、その後の証明では再び提供する必要がない（すでに「既知」だから）。
システムパフォーマンス：ステートフルなシステムは既知の情報を活用できるため、より効率的な計算と検証が可能となり、毎回ゼロから始める必要がない。

どうやってサポートするかについては、原文に多くの技術的詳細が含まれており、ここでは深入りしないが、要点は次の通り：

「ステートフル検証者をサポートする」とは、ZK-EVMにシステムが以前の状態を記憶・活用できるメカニズムを導入することを意味する。これによりシステム全体のパフォーマンスが向上し、必要なデータ転送量が削減され、より効率的な計算が可能になる。これはZK-EVM設計の拡張であり、現実世界での適用可能性と効率性を高める目的がある。

ZK-EVMが内蔵された場合、他の類似のL2はどうなるか？

記事の最後で、Vitalikは少し技術的な議論から離れ、別の問題を考え始めた。もしZK-EVMがイーサリアムL1の内蔵機能になった場合、他のZK系L2の役割はどう変わるのか？

Vitalikの構想では、もしそうなれば、L2は今後より「補助的」な役割を担い、以下の点で補完的な役割を果たすことになる：

高速な事前確定（Fast pre-confirmations）：単一スロットでの最終性（single-slot finality）はL1の処理速度を遅くする可能性があるが、L2プロジェクトはL2独自のセキュリティメカニズムに基づき、スロット時間よりもはるかに短いレイテンシーで高速な事前確定サービスを提供できる。これは引き続きL2独自の責務となる。
MEV緩和戦略：これには暗号化メモリプール、評判に基づくソーター選定、L1が実施を控える他の機能が含まれる。L2はこれらの戦略を実施し、MEVがユーザー取引に与える影響を低減できる。
EVMの拡張：L2プロジェクトはEVMに対する重大な拡張を導入し、ユーザーに顕著な価値を提供できる。これには「almost-EVMs」のバージョンのサポートや、WASM対応のArbitrum Stylus、SNARKに親和的なCairo言語など、まったく異なるアプローチが含まれる。
ユーザーと開発者への利便性：L2チームはユーザーとプロジェクトを自らのエコシステムに惹きつけ、居心地の良さを感じさせる大量の作業を行う。彼らはネットワーク内のMEVや混雑料金を獲得することで報酬を得る。ZK-EVMがイーサリアムプロトコルに統合されたとしても、このモデルは存続する。