あまり議論されていませんが、それでも非常に重要な方法の1つは、イーサリアムのセキュリティと分散化を維持する方法であり、マルチクライアントの哲学です。 イーサリアムには、誰もがデフォルトで実行する「リファレンスクライアント」を意図的に持たず、代わりに、共同で管理された仕様(最近では、非常に人間が読めるが、非常に遅い Python で 書かれている )があり、ユーザーが実際に実行する仕様の実装を行う複数のチーム(「クライアント」とも呼ばれる)があります。

各イーサリアムノードは、コンセンサスクライアントと実行クライアントを実行します。 現在、コンセンサスまたは実行クライアントは、ネットワークの2/3以上を占めていません。 カテゴリのシェアが 1/3 未満のクライアントにバグがある場合、ネットワークは通常どおり続行されます。 そのカテゴリで1/3から2/3のシェアを持つクライアント(Prysm、Lighthouse、Gethなど)にバグがある場合、チェーンはブロックの追加を続けますが、ブロックのファイナライズを停止し、開発者が介入する時間を与えます。

あまり議論されていませんが、それでも非常に重要な、イーサリアムチェーンの検証方法における今後の大きな変化は、ZK-EVMの台頭です。 EVMの実行を証明するSNARK は、すでに何年も前から開発が進められており、この技術は ZKロールアップと呼ばれるレイヤー2プロトコルで積極的に使用されています。 これらのZKロールアップの一部は、現在 メインネット で アクティブ であり、 近日中に さらに追加 される予定です 。しかし、長期的には、ZK-EVMは単なるロールアップのためではありません。これらを使用して、レイヤー 1 での実行も検証します ( The Verge も参照)。

そうなれば、ZK-EVMは事実上、第3のタイプのイーサリアムクライアントとなり、今日の実行クライアントやコンセンサスクライアントと同様に、ネットワークのセキュリティにとって重要です。 そして、ZK-EVMはマルチクライアント哲学とどのように相互作用するのかという疑問が当然ながら湧いてきます。 難しい部分の1つは、すでに複数のZK-EVM実装が活発に開発されていることです。 しかし、他にも難しい部分が残っています:イーサリアムブロックの正しさをZKで証明するための「マルチクライアント」エコシステムを実際にどのように作るのか? この質問は、いくつかの興味深い技術的課題を提起し、もちろん、トレードオフに見合う価値があるかどうかという迫り来る問題も抱えています。

イーサリアムのマルチクライアント哲学の当初の動機は何でしたか?

イーサリアムのマルチクライアント哲学は一種の分散化であり、<a href="https://medium.com/ @VitalikButerin /the-meaning-of-decentralization-a0c92b76a274">分散化全般と同様に、アーキテクチャの分散化の技術的利点または政治的分散化の社会的利益のいずれかに焦点を当てることができます。結局のところ、マルチクライアントの哲学は両方に動機づけられ、両方に役立っています。

技術的な分散化の議論

技術的な分散化の主な利点は単純で、1つのソフトウェアの1つのバグがネットワーク全体の壊滅的な故障につながるリスクを減らすことです。 このリスクを例示する歴史的な状況は、 2010年のビットコインオーバーフローバグです。 当時、ビットコインクライアントコードは、トランザクションの出力の合計がオーバーフローしない(最大整数の2^64-1を超える合計によってゼロに折り返される)ことをチェックしなかったため、誰かがまさにそれを行うトランザクションを行い、数十億のビットコインを与えました。 バグは数時間で発見され、修正が急がれてネットワーク全体に迅速に展開されましたが、当時成熟したエコシステムがあれば、これらのコインは取引所、ブリッジ、その他の構造物に受け入れられ、攻撃者は多額の資金を持ち逃げできた可能性があります。 5つの異なるビットコインクライアントがあった場合、それらすべてが同じバグを持っている可能性は非常に低いため、すぐに分割され、バグのある分割の側はおそらく失われていたでしょう。

致命的なバグのリスクを最小限に抑えるためにマルチクライアントアプローチを使用することにはトレードオフがあり、代わりにコンセンサス失敗のバグが発生します。 つまり、2人のクライアントがいる場合、クライアントによってプロトコルルールの解釈が微妙に異なるリスクがあり、どちらの解釈も合理的であり、お金を盗むことはできませんが、意見の相違によりチェーンが半分に分裂することになります。 イーサリアムの歴史の中で、この種の深刻な分裂が一度起こりました(古いバージョンのコードを実行しているネットワークのごく一部が分岐した、はるかに小規模な分裂が他にもありました)。単一クライアントアプローチの擁護者は、複数の実装を持たない理由として、コンセンサスの失敗を指摘します:クライアントが1つしかない場合、その1つのクライアントはそれ自身に同意しません。 クライアントの数がリスクにどのように変換されるかのモデルは、次のようになります。

もちろん、私はこの分析には同意しません。 私の意見の相違の核心は、(i) 2010 年型の壊滅的なバグも重要であり、(ii) 実際にはクライアントが 1 つしか持たないということです。 後者の点は、 2013年のビットコインフォークによって最も明白になります:チェーンスプリットは、ビットコインクライアントの2つの異なるバージョン間の不一致のために発生し、そのうちの1つは、単一のブロックで変更できるオブジェクトの数に偶発的で文書化されていない制限があることが判明しました。 したがって、理論的には1人のクライアントが実際には2人のクライアントであり、理論的には5人のクライアントが実際には6〜7人のクライアントである可能性があるため、思い切ってリスク曲線の右側に行き、少なくともいくつかの異なるクライアントを持つ必要があります。

地方分権の議論

独占クライアント開発者は、多くの政治的権力を持つ立場にあります。 クライアント開発者が変更を提案し、ユーザーが同意しない場合、理論的には更新されたバージョンのダウンロードを拒否したり、更新なしでフォークを作成したりできますが、実際にはユーザーがそれを行うことは難しいことがよくあります。 不快なプロトコルの変更が必要なセキュリティ更新プログラムにバンドルされている場合はどうなりますか? メインチームが自分の思い通りにならなければ辞めると脅したらどうしますか? あるいは、もっとおとなしく言えば、独占的なクライアントチームがプロトコルの専門知識を持つ唯一のグループになってしまい、エコシステムの残りの部分がクライアントチームが提起する技術的な議論を判断する立場に悪くなり、クライアントチームが独自の目標や価値観を推し進める余地が大きく残されたらどうなるでしょうか。 これは、より広いコミュニティと一致しない可能性がありますか?

特に 2013年から2014年にかけてのビットコイン OP_RETURN戦争の 文脈では、一部の参加者がチェーンの特定の使用法を差別することに公然と賛成していたため、プロトコルの政治に対する懸念は、イーサリアムがマルチクライアント哲学を早期に採用する大きな要因となりました。 イーサリアムのエコシステムに特有の懸念、つまりイーサリアム財団自体への権力の集中を避けることが、この方向性をさらに後押ししました。 2018年、財団が意図的にイーサリアムPoSプロトコルの実装を行わないようにすることが決定されました。 現在「コンセンサスクライアント」と呼ばれているもの)、そのタスクを完全に外部のチームに任せています。

ZK-EVMは今後、レイヤー1にどのように搭載されるのでしょうか?

現在、ZK-EVMはロールアップに使用されています。 これにより、コストのかかるEVMの実行をオフチェーンで数回行うだけで、他の誰もがオンチェーンに投稿された SNARK を検証するだけで、EVMの実行が正しく計算されたことを証明することができるため、スケーリングが向上します。 また、一部のデータ(特に署名)をオンチェーンに含めないため、ガス代を節約できます。 これにより、スケーラビリティに関する多くのメリットが得られ、ZK-EVMによるスケーラブルな計算と、<a href="https://hackmd.io/ @vbuterin /sharding_proposal#ELI5-data-availability-sampling">データ可用性サンプリングによるスケーラブルなデータを組み合わせることで、非常に大きなスケールアップが可能になります。

しかし、今日のイーサリアムネットワークには、レイヤー2のスケーリングだけでは解決できない別の問題もあります:レイヤー1の検証は難しく、多くのユーザーが自分のノードを実行していないほどです。 代わりに、ほとんどのユーザーは単にサードパーティのプロバイダーを信頼しています。 HeliosやSucinctなどのライトクライアントは、この問題を解決するためのステップを踏んでいますが、ライトクライアントは、完全に検証するノードとはほど遠いです:ライトクライアントは、同期委員会と呼ばれるバリデータのランダムなサブセットの署名を検証するだけで、チェーンが実際にプロトコルルールに従っているかどうかは検証しません。チェーンがルールに従っていることをユーザーが実際に確認できる世界に私たちを連れて行くには、何か違うことをしなければなりません。

オプション 1: レイヤー 1 を制限し、ほぼすべてのアクティビティをレイヤー 2 に強制的に移動させる

時間の経過とともに、ブロックあたりのレイヤー1のガス数を1,500万から100万に減らし、1つのブロックに1つのSNARKといくつかの入出金操作を含めるのに十分ですが、それ以外はそれほど多くなく、それによってほぼすべてのユーザーアクティビティをレイヤー2プロトコルに移行させることができます。 このような設計でも、各ブロックでコミットする多くのロールアップをサポートできます:カスタマイズされたビルダーが運営する オフチェーンアグリゲーションプロトコル を使用して、複数のレイヤー2プロトコルからSNARKを収集し、それらを1つのSNARKに結合することができます。 そのような世界では、レイヤー1の唯一の機能は、レイヤー2プロトコルのクリアリングハウスとなり、その証明を検証し、時にはレイヤー2間の大規模な資金移動を容易にすることです。

このアプローチはうまくいく可能性がありますが、いくつかの重要な弱点があります。

• これは事実上、下位互換性がなく、既存の L1 ベースのアプリケーションの多くが経済的に成り立たなくなるという意味です。 数百ドルまたは数千ドルのユーザー資金は、手数料が非常に高くなり、それらのアカウントを空にするコストを超えると、立ち往生する可能性があります。 これは、ユーザーがメッセージに署名して、選択したL2へのプロトコル内の大量移行をオプトインできるようにすることで対処できますが( 初期の実装のアイデアについては、こちらをご覧ください)、これにより移行が複雑になり、真に安価にするには、いずれにせよレイヤー1に何らかのSNARKが必要になります。 私は一般的に、 <a href="https://hackmd.io/ @vbuterin /selfdestruct">SELFDESTRUCTオペコードのようなものに関しては、下位互換性を破るのが好きですが、この場合、トレードオフはあまり好ましくないようです。
• それでも、検証のコストが十分に安くならない可能性があります。 理想的には、イーサリアムプロトコルは、ラップトップだけでなく、電話、ブラウザ拡張機能、さらには他のチェーン内でも簡単に検証できる必要があります。 チェーンを初めて同期する場合や、オフラインで長時間使用した後の同期も簡単です。 ラップトップノードは~20ミリ秒で100万個のガスを検証できますが、それでも1日オフラインになってから同期するのに54秒かかります(<a href="https://notes.ethereum.org/@vbuterin/single_slot_finality">シングル スロットのファイナリティによりスロット時間が 32 秒に増加します)、電話やブラウザー拡張機能の場合、ブロックごとに数百ミリ秒かかり、それでも無視できないバッテリーの消耗になる可能性があります。これらの数値は管理可能ですが、理想的ではありません。
• L2ファーストのエコシステムでも、L1が少なくともある程度手頃な価格であることにはメリットがあります。 バリディウム は、ユーザーが新しい状態データが利用できなくなったことに気付いた場合に資金を引き出すことができれば、より強力なセキュリティモデルの恩恵を受けることができます。 アービトラージは、経済的に実行可能なクロスL2直接送金の最小サイズが小さい場合、特に小さなトークンの場合、より効率的になります。

したがって、ZK-SNARKを使用してレイヤー1自体を検証する方法を見つけようとする方が合理的であるように思われます。

オプション 2:レイヤ 1 の SNARK 検証

タイプ1(完全にイーサリアムと同等)のZK-EVMを使用して、(レイヤー1)イーサリアムブロックのEVM実行を検証できます。ブロックのコンセンサス側を検証するために、より多くのSNARKコードを書くこともできます。 現在、ZK-EVMはイーサリアムブロックの検証に数分から数時間かかり、リアルタイムで証明を生成するには、(i)SNARKに不利なコンポーネントを削除するためのイーサリアム自体の改善、(ii)特殊なハードウェアによる大幅な効率向上、(iii)並列化の大幅な改善、の1つ以上が必要です。 しかし、それができない根本的な技術的理由はないので、何年かかっても実現することを期待しています。

マルチクライアントパラダイムとの共通点は、ZK-EVMを使用してレイヤー1を検証する場合、どのZK-EVMを使用するかということです。

次の 3 つのオプションが表示されます。

1. シングルZK-EVM:マルチクライアントパラダイムを放棄し、ブロックの検証に使用する単一のZK-EVMを選択します。
2. クローズド・マルチZK-EVM:複数のZK-EVMの特定のセットに合意し、コンセンサスに祀り、ブロックが有効と見なされるためには、そのセット内のZK-EVMの半数以上からの証明が必要であるというコンセンサス・レイヤー・プロトコル・ルールを持つ。
3. オープンマルチ ZK-EVM: クライアントごとに異なる ZK-EVM 実装があり、各クライアントはブロックを有効として受け入れる前に、独自の実装と互換性のある証明を待機します。

私には、(3)は、少なくとも、すべてのZK-EVM実装が互いに同等であることを 正式に証明 できるところまで技術が向上するまでは理想的に思えます。 (1)マルチクライアントパラダイムの利点を犠牲にし、(2)新しいクライアントを開発する可能性を閉ざし、より中央集権的なエコシステムにつながります。 (3)には課題がありますが、少なくとも今のところ、これらの課題は他の2つの選択肢よりも小さいようです。

(3)の実装はそれほど難しくありません:証明の種類ごとにP2Pサブネットワークを用意し、1つのタイプの証明を使用するクライアントは、対応するサブネットワークをリッスンし、検証者が有効であると認識する証明を受け取るまで待機します。

(3)の2つの主な課題は、次の2つである可能性があります。

• レイテンシーの課題:悪意のある攻撃者は、1つのクライアントに対して有効な証明とともに、ブロックを遅れて公開する可能性があります。 現実的には、他のクライアントに対して有効な証明を生成するのに長い時間(たとえば15秒)かかります。 この時間は、一時的なフォークを作成し、いくつかのスロットのチェーンを混乱させるのに十分な長さです。
• データの非効率性:ZK-SNARKsの利点の1つは、検証にのみ関連するデータ(「証人データ」と呼ばれることもあります)をブロックから削除できることです。 たとえば、署名を検証したら、署名をブロックに保持する必要はなく、署名が有効であることを示す 1 つのビットと、すべての有効な署名が存在することを確認する 1 つの証明をブロックに格納できます。 しかし、ブロックに対して複数のタイプの証明を生成できるようにしたい場合は、元の署名を実際に公開する必要があります。

レイテンシの課題は、シングルスロットのファイナリティプロトコルを慎重に設計することで対処できます。 シングルスロットのファイナリティプロトコルでは、スロットごとに2ラウンド以上のコンセンサスが必要になる可能性が高いため、最初のラウンドにブロックを含めることを要求し、3回目(または最終)ラウンドで署名する前にノードが証明を検証することだけを要求することができます。 これにより、ブロックの公開期限から配達確認が利用可能になると予想される時間までの間に、常にかなりの時間枠が確保されます。

データ効率の問題は、検証関連データを集約するための別のプロトコルを用意することで対処する必要があります。 署名には、 ERC-4337がすでにサポートしている BLSアグリゲーション を使用できます。検証関連データのもう一つの主要なカテゴリは、 プライバシーに使用されるZK-SNARKsです。 幸いなことに、これらは多くの場合、 独自のアグリゲーションプロトコルを持つ傾向があります。

また、レイヤー1のSNARK検証には重要な利点があり、オンチェーンEVMの実行をすべてのノードで検証する必要がなくなるという事実により、EVMの実行量を大幅に増やすことが可能になります。 これは、レイヤー 1 のガス制限を大幅に引き上げるか、 祀られたロールアップを導入するか、またはその両方によって発生する可能性があります。

結論

オープンなマルチクライアントZK-EVMエコシステムをうまく機能させるには、多くの作業が必要です。 しかし、本当に良いニュースは、この作業の多くが行われているか、いずれにせよ行われるということです。

• すでに複数の強力なZK-EVMを実装しています。これらの実装はまだ タイプ1 (完全にイーサリアムと同等)ではありませんが、その多くはその方向に積極的に動いています。
• HeliosやSucinctなどのライトクライアントでの作業は、最終的にはイーサリアムチェーンのPoSコンセンサス側のより完全なSNARK検証に変わる可能性があります。
• クライアントは、特に ステートレスなクライアント があり、状態を維持するためにすべてのブロックを直接再実行する技術的必要性がなくなった場合、イーサリアムブロックの実行を独自に証明するためにZK-EVMの実験を開始する可能性があります。 おそらく、イーサリアムブロックを再実行して検証するクライアントから、SNARKプルーフをチェックしてイーサリアムブロックを検証するほとんどのクライアントへと、ゆっくりと段階的な移行が進むでしょう。
• ERC-4337とPBSのエコシステムは、ガス代を節約するために、BLSやプルーフアグリゲーションなどのアグリゲーション技術との連携をまもなく開始すると思われます。 BLSアグリゲーションについては、 すでに作業が始まっています。

これらの技術が整備されれば、未来は非常に良好に見えます。 イーサリアムのブロックは現在よりも小さくなり、誰でもラップトップや携帯電話、またはブラウザ拡張機能内で完全に検証するノードを実行でき、これはすべてイーサリアムのマルチクライアント哲学の利点を維持しながら実現します。

もちろん、長期的には何が起こるかわかりません。 おそらくAIは、ZK-EVMの実装が同等であることを容易に証明し、それらの間の違いを引き起こすすべてのバグを特定できるところまで、形式検証をスーパーチャージするでしょう。 このようなプロジェクトは、今すぐ取り掛かるのが現実的かもしれません。 このような正式な検証ベースのアプローチが成功すれば、議定書の継続的な政治的分権化を確実にするために、異なるメカニズムを導入する必要があります。おそらくその時点で、プロトコルは「完全」と見なされ、不変性の規範はより強力になるでしょう。 しかし、それが長期的な未来であるとしても、オープンなマルチクライアントZK-EVMの世界は、いずれにせよ実現する可能性が高い自然な足がかりのように思えます。

短期的には、これはまだ長い道のりです。 ZK-EVMは登場しましたが、ZK-EVMがレイヤー1で真に実行可能になるには、タイプ1になり、リアルタイムで実現できるほど高速に証明する必要があります。 十分な並列化があれば、これは可能ですが、そこに到達するまでにはまだ多くの作業が必要です。 KECCAK、SHA256、その他のハッシュ関数プリコンパイルのガスコストの引き上げなどのコンセンサスの変更も、全体像の重要な部分になります。 とはいえ、移行の最初のステップは予想よりも早く起こるかもしれません: Verkleツリー とステートレスクライアントに切り替えれば、クライアントは徐々にZK-EVMを使い始めることができ、「オープンなマルチZK-EVM」の世界への移行は、すべて単独で起こり始める可能性があります。

免責事項：

1. この記事は[vitalik]から転載されており、すべての著作権は原作者[vitalik]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。