V神が最も懸念していた「zkEVMマルチクライアント問題」がついに解決

Moni

Odaily资深作者

2023-04-02 04:50

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

ZK-EVM の技術的課題と解決策を分析してマルチクライアントエコシステムを構築する

この記事の由来はcryptoslate、リアム「アキバ」ライト著

日常翻訳者 |

次に、この記事の重要なポイントを明らかにしましょう。

副題

Zk-EVMのマルチクライアント問題

Vitalik Buterin 氏は、ZK-EVM は将来的にイーサリアムのレイヤー 1 セキュリティと検証プロセスの重要な部分に発展し、ゼロ知識 (ZK) テクノロジーにより、開発者は追加情報を明らかにすることなくトランザクションやメッセージの信頼性を証明できると考えています。情報セックス。

これは、トランザクションの一方の当事者が、メッセージの有効性以外の知識を明らかにすることなく、送信したメッセージが本物で有効であることを他方の当事者に納得させることができることを意味します。しかし、Vitalik Buterin氏の分析によると、ゼロ知識証明技術のプライバシー保護の性質は、イーサリアムクライアントがプロトコルのルールを実装する方法の微妙な違いにより、より広範なEVMの状況を混乱させる可能性があります。

現段階では、ZK Rollups の第 2 層プロトコルはゼロ知識証明テクノロジーの使用に成功し、複数のトランザクションを 1 つの証明にバンドルすることでイーサリアムブロックチェーンの拡張に役立ちました。しかし、メインネットワークでのトランザクションの実行を検証するためのZK-EVMの開発により、ヴィタリック・ブテリン氏は「ZK-EVMは実際には第3の種類のイーサリアムクライアントになる。ネットワークのセキュリティが最も重要である」と考えている。

しかし、ZK-EVM が 3 番目のタイプのイーサリアムクライアントとみなされると、Vitalik Buterin は次のような疑問を提起します。

「実際には、イーサリアムブロックの正しさのゼロ知識証明のための「マルチクライアント」エコシステムをどのように作成すればよいでしょうか?

イーサリアムのエコシステムが拡大し続ける中、ヴィタリック・ブテリン氏は「マルチクライアント哲学」の利点を維持しながら、ZK-EVMの機能を活用してイーサリアムネットワークのスケーラビリティ、セキュリティ、分散化を改善したいと考えています。

では、これらの問題をどのように解決すればよいでしょうか?ヴィタリック・ブテリンが解決策を示しました -

副題

イーサリアムエコシステムにおける上記の課題にもかかわらず、ヴィタリックブテリン氏は、オープンマルチクライアント ZK-EVM エコシステムの構築は完全に実現可能であり、イーサリアムのセキュリティと分散化に役立つと信じています。次の図は、イーサリアムエコシステムです。さまざまなクライアントの視覚的表現です。のコンセンサス層と実行層で使用されます。

画像の説明

出典: vitalik.eth.limo

Vitalik Buterin 氏は、複数のクライアントを持つことで、イーサリアムネットワーク全体をダウンさせる可能性のある 1 つの実装における単一の致命的なエラーのリスクが軽減され、ネットワークのセキュリティと分散化が向上すると考えています。さらに、マルチクライアントの概念は、1 つの開発チームまたは組織内での権力の集中を防ぐことにも役立ち、ネットワークの分散化が促進されます。

前述の ZK-EVm マルチクライアント問題について、Vitalik Buterin 氏は 3 つの可能な解決策を提案しました。

1. 単一の ZK-EVM: マルチクライアントパラダイムを放棄し、ブロックの検証に単一の ZK-EVM を選択します。

2. クローズされた複数の ZK-EVM: 複数の ZK-EVM の特定のセットについて同意してコンセンサスに達し、ブロックがセットプルーフ内の ZK-EVM の半分以上から取得される必要があるというコンセンサス層プロトコルルールを持っています。有効とみなされます。

3. 複数の ZK-EVM を開く: 異なるクライアントには異なる ZK-EVM 実装があり、各クライアントはブロックを有効なものとして受け入れる前に、自身の実装との互換性の証明を待ちます。」

ZK-EVM のコンテキストでは、Vitalik Buterin は、オープンマルチクライアント ZK-EVM エコシステムソリューションである 3 番目のソリューションをサポートしています。彼は、異なるクライアントには異なる ZK-EVM 実装があり、各クライアントはそれ自体との互換性の証明を待つと考えています。ブロックを有効なものとして受け入れる前に。

「少なくとも、すべての ZK-EVM 実装が相互に同等であることが正式に証明できるレベルまで技術が向上するまでは、私にとっては 3 番目のソリューションが理想的であるように思えます...」

それだけでなく、ZK-EVM がある程度の標準化を達成する点までテクノロジーが改善されれば、解決策は最も効率的なオプションを選択することになると Vitalik Buterin 氏は信じていますが、同時に「3 番目のソリューションの課題は次のとおりです」とも感じています。しかし、Vitalik Buterin 氏は、複数の ZK-EVM を開くと、次の 2 つの大きな課題に直面する可能性があると示唆しました。
データの非効率性: ZK-SNARK の利点の 1 つは、検証にのみ関連するデータ (「監視データ」と呼ばれることもあります) をブロックから削除できることです。たとえば、署名を検証したら、署名をブロックに保存する代わりに、署名が有効であることを示すビットと、すべての署名を確認する 1 つの証明をブロックに保存するだけで済みます。ただし、ブロックに対して複数のタイプのプルーフを生成できるようにしたい場合は、実際に元の署名を公開する必要があります。

副題

ZK-EVM は将来どのようにレイヤ 1 に参入するのでしょうか?

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

ヴィタリック・ブテリン氏は、時間の経過とともに、ブロックあたりのレイヤー 1 ガス目標を 1,500 万から 100 万に減らすことができると示唆しました。これは、ブロックに SNARK と一部の入出金を含めるには十分ですが、それ以外はそれほど多くはありません。これにより、ほぼすべてのユーザーアクティビティが強制的に制限されます。レイヤ 2 プロトコルに移行します。

副題

要約する

Vitalik Buterin 氏は、オープンなマルチクライアント ZK-EVM エコシステムを促進してうまく機能させるには、多くの作業が必要であると結論付けました。しかし良いニュースは、次の理由から、この目標を達成するための作業のほとんどは行われているか、いずれにしても起こるだろうということです。

1. イーサリアムにはすでに複数の強力な ZK-EVM 実装があります。

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

3. クライアントは、特に状態クライアントがなく、状態を維持するために各ブロックを直接再実行する技術的必要性がない場合、ZK-EVM を使用して自身の Ethereum ブロック実行を証明しようとし始める可能性があります。クライアントからは、イーサリアムブロックを再実行することで検証を終了し、SNARK プルーフをチェックすることでイーサリアムブロックを検証するほとんどのクライアントに移行します。

4. ERC-4337 および PBS エコシステムは、ガスコストを大幅に節約できる BLS や証明集約などのテクノロジーの使用を間もなく開始する可能性があります。