原作：ゾーイ、パズルベンチャーズ
TL; DR
イーサリアムのロードマップのダンクシャーディング、op/zk などの第 2 層ソリューションに至るまで、多くのパブリック チェーン間の競争以来、私たちはブロックチェーンのスケーラビリティ、つまり多数のユーザーと資金が流入した場合にどうするかについて継続的に議論してきました。 ?以下のシリーズ記事を通じて、データ取得、オフチェーン計算、オンチェーン検証の 3 つの部分で構成される将来像を示したいと思います。
Trustless Data Access + Off-chain Computation + On-chain Verification
「合意の証明」は、このブループリントの重要な部分です。この記事では、ゼロ知識を使用してイーサリアム PoS に基づいてコンセンサスを証明することの重要性について説明します。
1. EVM における分散化の重要性。
2. Web3 拡張における分散型データ アクセスの重要性。
イーサリアムメインネットの完全なコンセンサスを証明することは複雑な作業ですが、コンセンサス層のzk化を実現できれば、セキュリティと信頼性の確保を基盤としたイーサリアムの拡張に役立つと同時に、イーサリアムの堅牢性も向上します。参加コストを削減し、より多くの人が参加できるようにします。
1. コンセンサス層を証明することが重要なのはなぜですか?
zk を使用してイーサリアム L1 のコンセンサス層を検証することは、2 つの一般的な方向で意味があります。まず、現在のノードの多様性の欠点を補い、イーサリアム自体の分散化とセキュリティを強化できます。第二に、クロスチェーンセキュリティ、トラストレスデータアクセス、分散型オラクル、拡張など、イーサリアムエコシステムのあらゆるレベルでのプロトコルの使いやすさとセキュリティの基盤をより多くのユーザーに提供します。
1. イーサリアムの視点
イーサリアムがその分散化と堅牢性を実現するには、クライアントの多様性に対応した環境が必要です。これは、より多くの人々、特に一般ユーザーが、さまざまなコード環境に基づいてクライアントを実行することに関与することを意味します。ただし、すべてのユーザーにフル ノードの実行を要求するのは非現実的です。これには多くのリソースが必要であり、少なくとも 16 GB 以上の RAM と 2 TB 以上の高速 SSD を購入できる人はほとんどいないため、これらの要件は増加し続けています。
現在の目標は、メモリ、ストレージ、帯域幅要件の点でコストを削減しながら、フル ノードと同じレベルの信頼 (信頼の最小化) を提供できるライト ノードを実現することです。ただし、現在、ライト ノードはコンセンサス プロセスに参加していないか、コンセンサス メカニズム (同期委員会) によって部分的にのみ保護されています。
この目標は、イーサリアムのロードマップでは「The Verge」と呼ばれています。
Goal: verifying blocks should be super easy - download N bytes of data, perform a few basic computations, verify a SNARK and you’re done— The Verge on Ethereum’s Roadmap
「The Verge」はクライアントギャップを埋めることを目指しています。重要なステップは、トラストレスライトノードをいかに実現するかです。セキュリティレベルは今日のフルノードと同等であり、「クライアントギャップ」を埋め、より多くの人が積極的に参加できるようにする必要があります。ネットワークの分散化と堅牢性。
https://www.ethernodes.org/network-types
https://clientdiversity.org/
2. イーサリアムエコシステムの各層におけるプロトコルの視点
最初の原則から始めて、オンチェーンのデータアクセスとオフチェーンのコンピューティング検証を組み合わせる問題を解決する必要があります。
現在のオンチェーン データの使用は比較的初歩的で不十分です。多くの場合、プロトコル調整に必要なデータはオンチェーンで計算するには複雑すぎるため、トラストレスな方法でデータを取得するコストが高すぎるため、大量の履歴データへのアクセスと頻繁な数値計算が必要になります。
個々のユーザーやプロジェクトにとって、私たちの理想的な状況は、分散化されたエンドツーエンドのトラストレスなデータ送信と読み書きを実現することであり、これに基づいて、将来のより多くのユーザーにとって、コンピューティングコストは可能な限り低く抑えられるべきです。アカウントの安全性、使いやすさ、経済性を実現します。
具体的には次の側面が含まれます。
1. 分散型トラストレスオラクル (Oracle): 現在のプロトコルは集中型オラクルを使用して、チェーン上の大量の履歴データへの直接アクセスを回避します。これにより、不必要な信頼コストが増加し、構成可能性が低下します。
2. データの読み取りと書き込み、および資産に依存するプロトコル：たとえば、DeFi プロトコルは運用中に一部のパラメーターを動的に調整する必要がありますが、信頼なしで履歴データにアクセスし、最近のデータに基づくなど、より複雑な計算を実行できるかどうか。市場変動 AMM手数料を調整し、チェーンデリバティブ取引価格モデルと動的な変動を設計し、資産管理に機械学習手法を導入し、市場状況に応じてローン金利を調整します。
3. クロスチェーンセキュリティ：現時点では、zkテクノロジーに基づくライトノードスキームは、セキュリティ、資本効率、ステートフル性、送信情報の多様性の点で優れています。 Succinct の現在の Telepathy クロスチェーン ソリューションと LayerZero 上の Polehedra のクロスチェーン ソリューションは、どちらも Sync Committee によるライト ノード ブロック ヘッダーの zk 検証に基づいています。ただし、同期委員会はイーサリアム PoS コンセンサス層そのものではなく、一定の信頼の前提があり、将来的にはより完全なものにする余地があります。
現在、経済的コスト、技術的制限、およびユーザー エクスペリエンスの考慮事項により、開発者は通常、オンチェーン データを利用する場合、Alchemy、Infura、Ankr などの集中型 RPC サーバーに依存しています。
2. ブロックチェーンデータはどこから来たのですか?さまざまなデータソースに対する仮定を信頼する
ブロックチェーンには、オンチェーン データとオフチェーン データという 2 つのコンピューティング データ ソースがあります。オンチェーンとオフチェーンの宛先に応じて計算が実行されます。たとえば、前述の DeFi プロトコルのパラメーターを調整する必要性です。
Data Access, computation, proof and verification
オンチェーンおよびオフチェーンのデータの読み取り、書き込み、およびコンピューティングには、次の 2 つの特徴があります。
1. 分散化とセキュリティを実現するには、取得したデータを検証する、つまり「Dont Trust, Verify」が最善です。
2. 多くの場合、複雑でコストのかかる計算プロセスが必要になります。
適切な技術的解決策が見つからない場合、上記 2 点がブロックチェーンの使いやすさに影響を及ぼします。
簡単な例を通して、さまざまなデータ取得方法を説明します。口座残高を確認したいと思ったら、どうしますか?
最も安全な方法の 1 つは、フルノードを自分で実行し、ローカルに保存されている Ethereum の状態を確認し、そこからアカウント残高を取得することです。
フルノードのベンチマーク。同期モードとクライアントの選択は、必要なスペース要件に影響します。
参照する：
https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/; https://docs.google.com/presentation/d/1ZxEp6Go5XqTZxQFYTYYnzyd97JKbcXlA6O2s4RI9jr4/mobilepresent?pli=1&slide=id.g252bbdac496_0_109）
ただし、完全なノードを自分で実行すると、非常に費用がかかり、自己メンテナンスが必要になります。トラブルを避けるために、多くの人は集中ノードのオペレーターに直接データを要求するかもしれません。 Web2 での動作と同様に、これを行うことに問題はありません。また、これらのプロバイダーによる悪意のある動作は一度も見たことがありませんが、集中型のサービス プロバイダーを信頼する必要があることも意味し、全体的なセキュリティの前提条件が高まります。
この問題を解決するには、2 つの解決策が考えられます。1 つはノードの実行コストを削減すること、もう 1 つはサードパーティ データの信頼性を検証する方法を見つけることです。
あとは必要なデータを保存するだけです。データにより効率的にアクセスし、信頼コストを削減し、独立してデータを検証するために、一部の機関は、Rust ベースの Helio (a16z によって開発)、Lodestar、Nimbus、JavaScript ベースの Kevlar などのライト クライアントを開発しました。ライト クライアントはすべてのブロック データを保存するのではなく、ブロックに関するすべての情報の「概要」であるブロック ヘッダーのみをダウンロードして保存します。ライト クライアントは受信したデータ情報を独立して検証できるため、サードパーティのデータ プロバイダーからデータを取得するときに、プロバイダーのデータを完全に信頼する必要はなくなります。
https://medium.com/coinmonks/ethereum-data-transaction-trie-simplified-795483ff3929
ライトノードの主な特徴は次のとおりです。
理想的には、ライト ノードは携帯電話または組み込みデバイス上で実行できます。
理想的には、フル ノードと同じ機能とセキュリティが保証されることです。
ただし、ライトノードはコンセンサスプロセスに参加しないか、コンセンサスメカニズムの一部、つまり同期委員会によってのみ保護されます。
同期委員会はライト ノードの信頼を前提としています。
2020 年 12 月から始まるマージの前に、ビーコン チェーンは Altair と呼ばれるハード フォークを経験しました。その主な目的は、ライト ノードにコンセンサス サポートを提供することでした。 PoS の完全なコンセンサスとは異なり、この検証者グループ (512) は、より長い期間 (256 エポック、約 27 時間) でランダムに抽出された小規模なデータセットで構成されています。
Light clients such as Helios and Succinct are taking steps toward solving the problem, but a light client is far from a fully verifying node: a light client merely verifies the signatures of a random subset of validators called the sync committee, and does not verify that the chain actually follows the protocol rules. To bring us to a world where users can actually verify that the chain follows the rules, we would have to do something different.How will Ethereum's multi-client philosophy interact with ZK-EVMs?, by Vitalik Buterin*
これが、より安全で、より使いやすく、より多様なプロトコルを備え、大規模に採用される未来を導くために、私たちがイーサリアムのコンセンサス層全体を検証したい理由です。知識（ゼロ知識）テクノロジー。
3. ゼロ知識を使用してコンセンサス層への道を証明する
信頼を前提としない環境を構築するには、ライトノードの信頼性、分散データアクセス、オフチェーン計算の検証などの問題を解決する必要があり、これらの点で現在最も認知されているコア技術はゼロ知識証明です。 zkEVM、zkWASM、その他の zkVM、zk コプロセッサー、その他の基盤となるソリューションに限定されません。
コンセンサス層がその重要な部分であることを証明します。
PoS アルゴリズムは非常に複雑で、ZK に実装するには多くのエンジニアリング作業とアーキテクチャ上の考慮事項が必要です。まずコンポーネントを分割しましょう。
1. イーサリアム 2.0 における合意形成のための中心的なステップ
(1) バリデータ関連のアルゴリズム
これには次の手順が含まれます
バリデーターになる: バリデーター候補者は、デポジットコントラクトに 32 ETH を送信し、ビーコンチェーンが処理されてアクティブ化されて正式なバリデーターになるまで、少なくとも 16 時間から数日または数週間待つ必要があります。 (FAQ - バリデーターの有効化に時間がかかるのはなぜですかを参照してください)
検証責任の行使: 乱数とブロックプルーフアルゴリズムが関与します。
検証者の役割を終了する: 検証者を終了するには、自発的に撤退するか、違反により削減されることが考えられます。検証者はいつでもアクティブに「終了」を開始でき、各エポックには終了できる検証者の数に制限があります。同時に終了しようとするバリデーターが多すぎると、バリデーターはまだ検証義務を実行する必要があるキューに入れられます。正常に終了した後、1/8 ek 後に、バリデーターは約束された資金を引き出すことができるようになります。
(2) 乱数関連のアルゴリズム
各エポックには 2 エポック前にランダムにグループ化された 32 個のブロック (スロット) が含まれており、すべてのバリデーターは 32 の委員会 (委員会) に分割され、現在のエポックで任務を実行し、各ブロックのコンセンサスに責任を負います。
各委員会には 2 つの役割があり、1 つは提案者、残りはブロック ビルダーであり、ブロック ビルダーもランダムに選択されます。これにより、トランザクションのソートとブロック構築の 2 つのプロセスが分離されます (詳細については、提案者/構築者の分離 - PBS を参照してください)。
(3) ブロック認証および BLS 署名関連のアルゴリズム
署名部分はコンセンサス層の中核となる部分です。
各スロットの検証委員会が投票し (BLS 署名を使用)、ブロックを構築するには 2/3 の合格率が必要です。
イーサリアム PoS コンセンサス層では、BLS 署名は BLS 12-381 楕円曲線を使用しており、ペアリングが容易で、すべての署名の集約に適しており、証明時間とサイズが削減されます。
プルーフ・オブ・ワークでは、ブロックが再編成される場合があります。合併後、実行層に「ファイナライズされたブロックとセーフヘッド」の概念が導入されました。競合するブロックを作成するには、攻撃者はステークされたイーサ全体の少なくとも 1/3 を燃やす必要がありますが、主に PoS は PoW よりも信頼性が高くなります。
https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer
2023 年 6 月末、「Puzzle Ventures Evening Study」で Hyper Oracle の zkPoS (zk メソッドを使用してイーサリアムの完全なコンセンサス層を検証) が紹介されました。詳細については、「zkPoS: エンドツーエンドのトラストレス」を参照してください。
(4) その他：主観性の弱いチェックポイントなど
トラストレス PoS コンセンサス証明が直面する課題の 1 つは、主観的なチェックポイントの選択には、社会情報に基づく社会的合意が含まれることです。弱い主観的なチェックポイントより前のブロックは変更できないため、これらのチェックポイントは元に戻す制限となります。詳細については、https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/を参照してください。
チェックポイントもコンセンサス層のzk化において考慮すべきポイントです。
2. コンセンサス層の ZK テクノロジースタックを証明する
証明コンセンサス層では、署名やその他の計算の証明自体に非常にコストがかかりますが、ゼロ知識証明の検証はそれに比べて非常に安価です。
ゼロ知識証明コンセンサス層を使用するアプローチを選択する場合、プロトコルは次の要素を考慮する必要があります。
何を証明するつもりですか？
証明後の応用シナリオは何ですか?
証明の効率を高めるにはどうすればよいでしょうか?
Hyper Oracle を例に挙げると、BLS 署名の証明に、Succinct Labs が使用している Circom ではなく Halo 2 を選択しました。その理由は次のとおりです。
Circom と Halo 2 はどちらも、BLS 署名 (BLS 12 – 381 楕円曲線) のゼロ知識証明を生成できます。
Hyper Oracle は zkPoS を実行しているだけではなく、そのコア製品はプログラマブル オンチェーン ゼロ知識オラクル (Programmable Onchain zkOracle) です。このうち、zkGraph、zkIndexing、zkAutomation はユーザーを直接対象としており、zkWASM 仮想マシンはオフチェーン計算の検証にも使用されます。 Circom はエンジニアにとって使いやすいですが、互換性が低く、すべての機能ロジックを使用できることを保証できません。
Circom ペアリングは R 1 CS にコンパイルされますが、これは zkWASM および他の回路の Plonkish 制約システムと互換性がありませんが、Halo 2 ペアリング回路は zkWASM 回路に簡単に統合できます。対照的に、R 1 CS はバッチプルーフには適していません。 ( 証明バッチ処理 ) も理想的ではありません。
効率の観点から見ると、Halo 2 ペアリングによって生成される BLS 回路はより小さく、証明時間が短く、ハードウェア要件が低くなり、ガス料金も低くなります。
https://mirror.xyz/hyperoracleblog.eth/lAE9erAz5eIlQZ346PG6tfh7Q6xy59bmA_kFNr-l6dE
ゼロ知識を使用してコンセンサス層を証明するもう 1 つの重要な点は、再帰的証明、つまり、以前に起こったことを証明にパッケージ化する証明の証明です。
再帰的証明がない場合、最終的には O(ブロック高さ) サイズの証明、つまり各ブロック認証 (block attestation) とそれに対応する zkp が出力されます。再帰的証明では、初期状態と最終状態に加えて、任意の数のブロックに対して O(1) サイズの証明のみが必要です。
Verify Proof N and Step N+ 1 to get Proof N+ 1, i.e. you know N+ 1 pieces of knowledge, instead of verify all N Steps separately.
元の目標に戻ると、私たちのソリューションは、コンピューティングとメモリの制約がある「ライト クライアント」をターゲットにする必要があります。たとえ各証明を一定時間内に検証できたとしても、ブロック数や証明数が積み重なると検証時間が非常に長くなってしまいます。
3. 最終目標: 多様化したレベル 1 zkEVM
イーサリアムの目標は、コンセンサス層を証明することだけでなく、zkEVM を通じてレイヤー 1 仮想マシン全体のゼロ知識を達成し、最終的には多様な zkEVM を実現してイーサリアムの分散化と堅牢性を強化することです。
これらの問題に対するイーサリアムの現在の解決策とロードマップは次のとおりです。
「軽量」 - メモリ、ストレージ、帯域幅の要件が小さい
現在、ブロック ヘッダーのみがライト ノードを通じて保存および検証されます。
将来の開発には、メインネットのデータ構造の改善を含む、バークル ツリーとステートレス クライアントにおけるさらなる努力も必要になります。
「Safety to Trustless」—フルノードと同じ最小の信頼を実現します (信頼の最小化)
現在、基本的なライトノードのコンセンサス層、つまり同期委員会が実装されていますが、これは単なる過渡的な解決策です。
SNARK を使用して、実行層の Verkle Proof の検証、コンセンサス層の検証、仮想マシン全体の SNARK など、Ethereum レイヤー 1 を検証します。
レベル 1 zkEVM は、イーサリアム レイヤ 1 仮想マシン全体のゼロ知識を実現し、zkEVM の多様化を実現するために使用されます。
起こり得るリスク
理想的には、zk 時代に入ると、複数のオープンソース zkEVM が必要になります。異なるクライアントには異なる zkEVM 実装があり、各クライアントはブロックを受け入れる前に、独自の実装との互換性の証明を待ちます。
ただし、各証明システムにはピアツーピア ネットワークが必要であり、1 つの証明システムのみをサポートするクライアントは、検証者によって検証される前に、対応する種類の証明を待つことしかできないため、複数の証明システムはいくつかの問題に直面する可能性があると認識されています。発生する可能性のある 2 つの主な課題には、「レイテンシの課題」と「データの非効率性」が含まれます。前者は主に証明の生成が遅いことが原因です。異なる証明システムの証明を生成する際には一定のタイムラグが発生します。理論的には、zkSNARK 自体の利点は、元の署名やその他のデータを削除できることですが、複数の種類の zk 証明を生成する必要があるため、後者では、一時的なフォークを作成する必要があります。ここには、最適化と解像度という相反する要件がいくつかあります。
4. 今後の展望
Web3 がより多くのユーザーを歓迎し、よりスムーズなエクスペリエンスを提供し、より高い使いやすさを生み出し、アプリケーションのセキュリティを確保するには、分散型データ アクセス、オフチェーン コンピューティング、オンチェーン検証のためのインフラストラクチャを構築する必要があります。
証明コンセンサス層はその重要な部分であり、イーサリアム PSE と前述の zkEVM レイヤ 2 に加えて、Hyper Oracle (プログラマブル zkOracle) など、ゼロ知識証明コンセンサスを通じて独自のアプリケーション側の目標を達成しているプロトコルもいくつかあります。 Network ) は、ゼロ知識証明イーサリアム PoS のコンセンサス層全体を使用してデータを取得する予定です; Succinct Labs の Telepathy は、Sync Committee のコンセンサスを検証し、状態の有効性証明を提出することでクロスチェーン通信を実現するライト ノード ブリッジです。は元々はライトノードブリッジでしたが、現在は devirgo を使用してフルノードフルコンセンサス ZK 証明を達成しているとも述べられています。
クロスチェーンセキュリティと分散型オラクルに加えて、このオフチェーン計算 + オンチェーン検証方法は、オプティミスティックロールアップでの不正行為の証明にも参加し、OP L2 と統合することもできます; またはインテントベースのアーキテクチャ (インテントベースのアーキテクチャ) 、より複雑なインテント構造などに対するオンチェーン証明を提供します。
ここでは、イーサリアムに限定されず、イーサリアムを超えたより広範な市場を含む、イーサリアムを取り巻くオフチェーンエコシステムについて話します。
このトピックにはまだ深く研究する価値のある部分がたくさんあります。たとえば、先週 8 月 24 日に a16z は、「ステートレス ブロックチェーン (ステートレス ブロックチェーン) には到達できない」と主張する記事を掲載しました。もう 1 つの例は、弱い主観性チェックポイントです。主観チェックポイント）、同期委員会のセキュリティは数学的に十分であるなど。
アドバイスとフィードバックをくれた同僚、Alex @ IOBC (@looksrare_eth)、Fan Zhang @ Yale University (@0x FanZhang)、Roy @ Aki Protocol (@aki_protocol)、Zhixiong Pan @ ChainFeeds (@nake 13)、Suning Yao に改めて感謝します。 @ Hyper Oracle (@msfew_eth)、Qi Zhou @ EthStorage (@qc_qizhou)、Sinka @ Delphinus (@DelphinusLab)、Shumo @ Manta (@shumochu)
