Vitalik：イーサリアムのマルチクライアントの理念は、ZK-EVMとどのように相互作用しますか？

原文标题：How willEthereum'smulti-client philosophy interact with ZK-EVM?

原文作者：Vitalik Buterin

编译：倩雯，ChainCatcher

イーサリアムはマルチクライアント エンド の 理念 によってその安全性と分散化を維持していますが、これは非常に重要でありながら、十分に議論されていません。イーサリアムは誰もがデフォルトで実行できる「リファレンスクライアント」を設計しているわけではなく、ユーザーが協力して管理する仕様を設定しています（最近は可読性が高いが速度が遅いPythonで書かれています）。そして、複数のチームがその仕様（つまり「クライアント」）を実装しており、これがユーザーが実際に実行するものです。

すべてのイーサリアムノードは、コンセンサスクライアントと実行クライアントの両方を実行しています。現時点では、コンセンサスまたは実行クライアントのいずれもネットワークの2/3以上を占めていません。もし、あるクライアントがそのカテゴリで1/3未満のシェアを持っている場合、そのクライアントが エラーを 起こしても、ネットワークは 正常に 動作し続けます。もし、あるクライアントがそのカテゴリで1/3から2/3のシェアを持っている場合（ 例えば 、 Prysm、Lighthouse、またはGeth） そのクライアントが エラーを 起こすと、チェーンはブロックを追加し続けますが、ブロックの最終確定を停止し、 開発者に 介入する時間を 与えます。

イーサリアムの証明方法において、十分に議論されていないが、今後の重要な変化の一つはZK-EVMの台頭です。EVM実行のSNARKは数年間開発されており、この技術はZKロールアップのL2プロトコルに積極的に採用されています。その中のいくつかのZKロールアップはメインネットで活発に稼働しており、さらに多くが今後登場する予定です。しかし、長期的には、ZK-EVMはロールアップだけにとどまらず、第一層の実行状況を検証するためにも使用したいと考えています。

こうして 、 ZK-EVMは 事実上の 第三のイーサリアムクライアントとなり、 現在の 実行クライアントとコンセンサスクライアントと同様に 、 ネットワークの安全性に 不可欠 となります。これは自然に一つの疑問を引き起こします：ZK-EVMはどのようにマルチクライアントの理念と相互作用するのでしょうか？その一つの難点は解決されました：私たちはすでに複数のZK-EVMの実装を持ち、積極的に開発が進められています。しかし、他の困難な部分は依然として存在します：私たちはどのようにして「マルチクライアント」エコシステムをZK証明によってイーサリアムブロックの正当性に適用するのでしょうか？この問題は興味深い技術的な課題をもたらします------もちろん、これらのトレードオフが価値があるかどうかという緊急の問題もあります。

イーサリアムのマルチクライアント理念の最初の動機は何ですか？

イーサリアムのマルチクライアント理念は分散化の一形態であり、一般的な分散化と同様に、人々はアーキテクチャの分散化による技術的な利点にも、政治的な分散化による社会的な利点にも注目できます。最終的に、マルチクライアントの理念はこの二つによって促進され、両者にサービスを提供します。

技術的 分散化

技術的分散化の主な利点は非常にシンプルです：それはソフトウェアの一つのバグが全体のネットワークを完全に崩壊させるリスクを減少させます。このリスクを示す歴史的な事例は、2010年のビットコインのオーバーフロー脆弱性です。当時、ビットコインクライアントのコードは、取引出力の合計がオーバーフローするかどうかをチェックしていませんでした（264-1を超える最大整数を合計してゼロに戻るため）、そのため誰かがオーバーフロートランザクションを行い、自分に数十億のビットコインをもたらしました。このバグは数時間以内に発見され、修正プログラムが急いでネットワーク全体に展開されました。もし当時成熟したエコシステムがあったなら、これらのトークンは取引所やブリッジ、他の機関によって受け入れられ、攻撃者は資金を持ち逃げしていたでしょう。しかし、もし当時5つの異なるビットコインクライアントが存在していたなら、同じ脆弱性が発生する可能性は非常に低く、すぐに分裂が起こり、脆弱性のある側が敗北する可能性が高かったでしょう。

マルチクライアントを使用して壊滅的な脆弱性のリスクを減少させることにはコストがかかります：あなた は コンセンサス失敗の 脆弱性 を 得る可能性があります：もし二つのクライアントが、あるプロトコルルールの解釈に微妙な違いがある場合、両方の解釈が非常に合理的であっても、資金の盗用を防ぐことができるとしても、この不一致はチェーンを二つに分裂させる可能性があります。このタイプの深刻な分裂は、イーサリアムの歴史の中で一度発生したことがあります（他の小さな分裂も発生しました）。

単一クライアント方式の擁護者は、コンセンサス失敗を引き合いに出し、複数の実装を行う必要はないと主張します：もし一つのクライアントしかなければ、そのクライアントは自分自身と対立することはありません。彼らのクライアント数がリスクを引き起こすというモデルは次のようになるかもしれません：

もちろん、私はこの分析には同意しません。なぜなら（1）2010年の壊滅的な脆弱性も考慮する必要があるからです。当時の状況も非常に深刻でした；（2）単一のクライアント の状況は実際には存在しなかった からです。この点は2013年のビットコインのフォーク事件で最も明らかになりました：二つの異なるバージョンのビットコインクライアントの間に不一致があり、一方のバージョンは単一のブロック内で変更可能なオブジェクトの数に予期しない、記録されていない制限を設けていたため、チェーンが分裂しました。したがって、理論上の「一つのクライアント」は実際には二つのクライアントであり、理論上の五つのクライアントは実際には六つまたは七つのクライアントである可能性があります------したがって、私たちはリスク曲線（上図）の右側を選択し、少なくともいくつかの異なるクライアントを持つ方が良いでしょう。

政治的 分散化

独占的なクライアント開発者は非常に大きな政治的権力を持っています。もしクライアント開発者が変更を提案し、ユーザーが同意しなければ、理論的には彼らは更新版をダウンロードすることを拒否するか、そのバージョンのないフォークを作成することができますが、実際にはユーザーがそれを行うのは非常に難しいことが多いです。もしこの不快なプロトコルの変更が必要なセキュリティ更新と一緒にバンドルされていたらどうでしょうか？もし主要なチームが撤退すると脅迫したらどうでしょうか？または、より一般的な状況として、もし独占的なクライアントチームがプロトコルの知識において最も専門的な団体であった場合、どうなるでしょうか？このように、エコシステムの他のメンバーは、クライアントチームが提案する技術的な議論が適切かどうかを判断するのが難しくなり、クライアントチームは自分たちの目標や価値観を推進するための大きな余地を持ち、これらの目標や価値観がコミュニティのより広範な追求と一致しない可能性がある場合、どうすればよいのでしょうか？

プロトコルの政治に対する関心は、特に2013-14年のビットコインOP_RETURN戦争から来ており、その時、一部の参加者は特定の用途に対する差別的なチェーンを公然と支持しました。これは、イーサリアムが初期にマルチクライアントの理念を採用する重要な要因の一つであり、このような事態が再び発生するのを避けるためです。イーサリアムエコシステムへの関心------すなわち、権力がイーサリアム財団自体に集中するのを避けること------もこの方向性をさらに支持しています。2018年、チームはイーサリアムのPoSプロトコル（現在の「コンセンサスクライアント」）を財団が実施することを許可せず、その任務を完全に外部チームに委ねることを決定しました。

ZK-EVMは今後第一層でどのように登場するのか？

現在、ZK-EVMはロールアップで使用されています：コストのかかるEVM実行をチェーン外で数回行い、他の人はチェーン上でEVM実行計算が正しいことを検証するSNARKを検証することでスケーリングを行います。また、いくつかのデータ（特に署名）がチェーン上に含まれないようにすることで、手数料を節約することも可能です。これにより、私たちは多くのスケーリングの利点を得ることができ、スケーラブルな計算をZK-EVMとデータ可用性サンプリングと組み合わせることで、非常に大きなスケーリングを実現できます。

しかし、今日のイーサリアムネットワークは、どの第2層スケーリングソリューションでも解決できない異なる問題にも直面しています：第1層は検証が難しく、ほとんどのユーザーが自分のノードを運用していません。逆に、ほとんどのユーザーは第三者のプロバイダーを信頼しています。軽量クライアント、例えば Heliosや Succinctはこの問題を解決するための措置を講じていますが、軽量クライアントは完全な検証ノードではありません：軽量クライアントは、ランダムな検証者（「同期委員会」と呼ばれる）サブセットの署名を検証するだけで、チェーンが実際にプロトコルルールに従っているかどうかを検証しません。ユーザーが実際にチェーンがルールに従っているかどうかを検証できるようにするためには、変更を加える必要があります。

方案1：第1層を縮小し、ほぼすべての活動を第2層に移行させる

私たちは、各ブロックの第1層のガス目標を1500万から100万に段階的に減少させることができます。これにより、1つのブロックにSNARKといくつかの入金および出金操作を含めるのに十分ですが、他の多くの操作を行うことはできず、ほぼすべてのユーザー活動を第2層プロトコルに移行させることが強制されます。この設計は、各ブロック内で多くのロールアップを提出することをサポートすることができます：私たちは、カスタマイズされたビルダーによって運営されるチェーン外集約プロトコルを使用して、複数の第2層プロトコルからのSNARKを集約し、1つのSNARKに統合することができます。こうして 、 第1層の唯一の機能は第2層プロトコルの交換センターとなり、 第2層の 証明を検証し、時折それらの間の大規模な資金移動を促進することになります。

この方法は機能する可能性がありますが、いくつかの重要な弱点があります：

1. 実際には 後方互換性が ありません。つまり、多くの既存のL1ベースのアプリケーションは経済的に不可能になるでしょう。手数料が高騰し、これらのアカウントを清算するコストを超える場合、ユーザーの資金は数百または数千ドルにわたって凍結される可能性があります。ユーザーが情報に署名してプロトコル内に大規模にL2に移行することを許可することで、この問題を解決できますが、移行の複雑さが増します。また、真に低コストを実現するためには、第1層で何らかのSNARKを実装する必要があります。SELFDESTRUのようなものに関しては、私は一般的に後方互換性を破ることに賛成ですが、この場合は後方互換性を放棄することをお勧めしません。

2.検証 のコストは大幅に削減されません。理想的には、イーサリアムプロトコルはノートパソコンだけでなく、スマートフォン、ブラウザプラグイン、さらには他のチェーン内でも簡単に検証できるべきです。チェーンを初めて同期すること、または長時間オフラインの後に同期することも簡単であるべきです。ノートパソクライアントは約20ミリ秒で100万ガスを検証できますが、それでも、オフラインで1日後に54秒かかることを意味します（単一スロットの確定性の時間が32秒に増加したと仮定すると）。スマートフォンやブラウザプラグインの場合、各ブロックには数百ミリ秒かかり、無視できないバッテリー消費を引き起こす可能性があります。これらの数字は制御可能ですが、私たちの理想的な期待には合致しません。

3. L2 優先のエコシステムでも、L1はコストをかけずに利益を得ることができます。 Validiumsは、より強力なセキュリティモデルから利益を得ることができ、ユーザーが新しい状態データがもはや利用できないことに気づいた場合、資金を引き出すことができます。経済的に実行可能なL2間の直接移動に必要な最小規模が小さい場合、特に小さなトークンに対して、アービトラージがより効果的になります。

したがって、ZK-SNARKを使用して第1層を検証する方法がより合理的に思えます。

方案2：SNARK-検証第1層

タイプ1（完全にイーサリアムと同等）ZK-EVMは、（第1層）イーサリアムブロックのEVM実行を検証するために使用できます。私たちは、ブロックのコンセンサス側を検証するために、さらに多くのSNARKコードを書くことができます。これは挑戦的なエンジニアリングの問題になります：現在、ZK-EVMはイーサリアムブロックを検証するのに数分から数時間かかりますが、リアルタイムで証明を生成するには、（i）SNARKに優しくないコンポーネントを排除するためのイーサリアム自体の改善、（ii）大幅な効率向上のための専用ハードウェア、（iii）より多くの並列化を行うためのアーキテクチャの改善が必要です。現在、これを実現できない技術的な理由はありません------したがって、たとえ何年かかっても、これを実現できることを願っています。

ここで考慮すべきは マルチクライアント の パラダイムです：もし私たちが ZK-EVMを使用して第1層を検証するなら、 どのZK-EVMを使用すべきでしょうか？ 三つの選択肢があります：

1）単一ZK-EVM：マルチクライアントモデルを放棄し、単一のZK-EVMを選択してそれを使用してブロックを検証します。

2）クローズドマルチZK-EVM：特定のマルチZK-EVMのグループに合意し、合意層プロトコルで、そのグループの半数以上のZK-EVMからの証明が必要であると規定します。

3）オープンマルチZK-EVM：異なるクライアントが異なるZK-EVM実装を持ち、各クライアントは自分の実装と互換性のある証明を受け取るまで、ブロックを有効として受け入れません。

私にとって、選択肢3が理想的です。この状況は、私たちの技術がすべてのZK-EVM実装が同等であることを正式に証明できるようになるまで変わりません。

選択肢1はマルチクライアントモデルの利点を犠牲にし、選択肢2は新しいクライアントの開発の可能性を閉じ、エコシステムをより集中化させることになります。選択肢3は挑戦を伴いますが、これらの挑戦は他の二つの選択肢の挑戦よりも小さいように思えます、少なくとも現時点では。

選択肢3を実現するのは難しくありません：私たちは各タイプの証明のためにp2pサブネットワークを構築し、あるタイプの証明を使用するクライアントは、対応するサブネットワークでリスニングし、検証者によって有効と認識された証明を受け取るのを待つことができます。

選択肢3 の二つの主要な挑戦は以下の通りです：

1）遅延：悪意のある攻撃者がブロックとクライアントに対して有効な証明を遅延させる可能性があり、他のクライアントに対して有効な証明を生成するのに長い時間（つまり、15秒以上）かかることがあります。この時間は一時的なフォークを生み出し、数回の時間スロット内でチェーンに干渉するのに十分です。

2）データ効率の低下：ZK-SNARKの利点の一つは、検証に関連するデータ（時には「証明データ」と呼ばれる）をブロックから削除できることです。例えば、署名を検証した後、その署名をブロックに保持する必要はなく、その署名が有効であることを示すビットを保存し、すべての有効な署名の存在を確認する証明をブロックに保存できます。しかし、私たちが一つのブロックに対して複数のタイプの証明を生成したい場合、元の署名は実際に公開される必要があります。

遅延は、慎重に設計された単一スロット決定性プロトコルによって解決できます。単一スロット決定性プロトコルは、各スロットで2回以上の合意を必要とする場合があり、最初のラウンドにはブロックを含め、ノードが第三ラウンド（または最後のラウンド）で署名する前に証明を検証することを要求できます。これにより、ブロックの公開期限と予想される証明の可用性の間に常に重要な時間ウィンドウが確保されます。

データ効率の問題を解決するためには、検証に関連するデータを集約するための別のプロトコルが必要です。署名に関しては、BLS集約を使用できます。これはERC-4337でサポートされています。検証に関連するデータのもう一つの大きなカテゴリはZK-SNARKであり、プライバシーを保護するために使用されます。これらのデータは通常、独自の集約プロトコルを持っています。

さらに重要なのは、SNARK-検証第1層には重要な利点があります：チェーン上のEVMの実行はもはや各ノードによって検証される必要がなくなり、EVMの実行量の大幅な増加が実現可能になります。これは、第1層のガス制限を大幅に増加させるか、暗黙のロールアップ（enshrined rollup）を導入するか、またはその両方を採用することで実現できます。

結論

マルチクライアントZK-EVMエコシステムの良好な運用を実現することは簡単ではありません。しかし、良いニュースは、これらの作業の大部分がすでに行われているか、行われる予定であるということです：

• 私たちは複数の強力なZK-EVM実装を持っており、これらはまだ1型EVM（完全にイーサリアムと同等）ではありませんが、その多くはこの方向に向かって積極的に進展しています。

• 軽量クライアント（Heliosや Succinctなど）での作業は、最終的にイーサリアムチェーンのPoSコンセンサスに対するより包括的なSNARK検証に変わる可能性があります。

• クライアントは、特に私たちが無状態クライアントを実現し、技術的に各ブロックを直接再実行することなく状態を維持できるようになった場合、ZK-EVMを使用してイーサリアムブロックの実行を独自に証明し始めるかもしれません。私たちは、クライアントがブロックを再実行することでイーサリアムブロックを検証することから、ほとんどのクライアントがSNARK証明をチェックすることでイーサリアムブロックを検証するという緩やかな移行を行うかもしれません。

• ERC-4337とPBSエコシステムは、手数料を節約するためにBLSや証明集約などの集約技術をすぐに使用し始める可能性があります。BLSの集約に関する関連作業も開始されています。

これらの技術が整えば、未来は明るいものになります。イーサリアムブロックは現在よりも小さくなり、誰もが自分のノートパソコンやスマートフォン、またはブラウザプラグインで完全に検証されたノードを運用できるようになり、すべてはイーサリアムのマルチクライアント理念を保持することになります。

さらに遠い未来には、すべてが起こり得ます。もしかしたら、人工知能が形式的な検証の性能を大幅に向上させ、ZK-EVM実装の等価性を簡単に証明し、それらの間の差異を引き起こすすべての脆弱性を特定できるようになるかもしれません。私たちは今すぐこのプロジェクトに着手すべきです。この形式的な検証に基づくアプローチが成功すれば、プロトコルの持続的な政治的権力の分散化を確保するために異なるメカニズムを構築する必要があります。もしかしたら、その時にはプロトコルが「完全」であり、変更不可能な規範がより堅牢になるかもしれません。しかし、たとえ長い時間が経過した後でも、オープンなマルチクライアントZK-EVMの世界は必ず訪れるでしょう。

短期的には、すべてが困難で長い道のりです。ZK-EVMはすでに登場していますが、ZK-EVMを第1層で実際に機能させるためには、タイプ1のZK-EVMとなり、迅速でリアルタイムの証明を実現する必要があります。十分な並列性があれば、これを実現できますが、まだ多くの作業が必要です。KECCAK、SHA256、その他のハッシュ関数のプレコンパイルの手数料を引き上げるようなコンセンサスの変更も、今後の重要な部分になるでしょう。移行の第一歩は、私たちが予想するよりも早く起こるかもしれません：一度私たちがボッカーツリーと無状態クライアントに移行すれば、クライアントは徐々にZK-EVMを使用し始め、「オープンでマルチZK-EVM」の世界への移行が自動的に起こるかもしれません。