ZKはモジュラースタックを食べるのか？

著者：Hannes Huitula; Compiled by Vernacular Blockchain

1.ブロックチェーンとは何か、現在のコンピューティングパラダイムをどのように拡張するのか？

ブロックチェーン（名詞）：世界中の参加者が、第三者を介することなく、共通に合意されたルールの下で共同作業を行うことを可能にする調整マシン。

コンピュータは、データの保存、計算、他のコンピュータや人間との通信という3つのことを行うように設計されている。ブロックチェーンは、これら3つのこと（保存、計算、通信）が合意されたとおりに行われることを保証するという、第4の次元を追加します。これらの保証によって、信頼できる第三者がそれを促進しなくても、見知らぬ人同士が協力し合うことができるようになる（分散化）。

これらの追加的な保証は、経済的なもの（信頼ゲーム理論やインセンティブ/ペナルティメカニズムに基づく）か、暗号的なもの（数学に基づく信頼）かのどちらかですが、ほとんどのアプリは両方の組み合わせ（暗号経済学）を利用しています。これは、主に評判ベースの現在のシステムとは対照的です。

Web3はしばしば「読む、書く、所有する」と表現されますが、私たちはインターネットの第3の進化のためのより良いコンセプトは「読む、書く、検証する」だろうと考えています。「なぜなら、パブリック・ブロックチェーンの重要な利点は、保証の計算と、その保証が守られていることの検証の容易さにあるからだ。私たちが構築したデジタル製品を売買・管理できるのであれば、所有権は保証計算のサブセットになり得る。しかし、ブロックチェーンのユースケースの多くは、保証計算の恩恵を受けているが、所有権には直接関与していない。例えば、完全にオンチェーンであるゲームにおいて、もしあなたが77/100の健康状態であった場合、あなたはその健康状態を所有しているのでしょうか、それとも単に一般的に合意されたルールに従ってオンチェーンで強制可能なのでしょうか？

Web3 = Read, Write, Verify

2.align: left;">2.ZKとモジュール性 - 加速する2つのトレンド

ブロックチェーンは多くの興奮をもたらしますが、分散型モデルもまた、追加機能（P2P通信やコンセンサスなど）を通じて、オーバーヘッドと非効率性を追加します。オーバーヘッドや非効率性を増大させる。加えて、ほとんどのブロックチェーンは依然として再実行によって正しい状態遷移を検証しており、これはネットワーク上のすべてのノードが提案された状態遷移の正しさを検証するためにトランザクションを再実行しなければならないことを意味する。これは、1つのエンティティのみが実行する集中型モデルとは対照的に、無駄が多い可能性がある。分散型システムには常にオーバーヘッドとレプリケーションが含まれますが、効率性という点では集中型ベンチマークに収束することを目標とすべきです。

インフラは過去10年間で劇的に改善されましたが、ブロックチェーンがインターネットレベルのスケールを扱えるようになるには、まだ多くの課題があります。私たちは、表現力と難易度という2つの主軸に沿ってトレードオフを考えており、モジュール化によって迅速な実験が可能になり、ゼロ知識証明によって拡張されたトレードオフのフロンティアを加速できると考えています。align: left;">表現力 - どのような保証を作ることができるか？スケーラビリティ（コスト、レイテンシ、スループットなど）、プライバシー（または情報フロー管理）、プログラマビリティ、合成可能性を含みます。

難易度 - これらの保証を達成するのはどれくらい難しいか？セキュリティ、分散化、ユーザーとコードのセキュリティを含みます。

モジュール性とは、システムのコンポーネントを分離して再編成できる度合いのことです。より速いフィードバックループと、より低い参入障壁を通じて、より少ない資本（経済的および人的）で、モジュール性は実験と専門化を加速させることができる。モジュール性と統合性の間の問題は、二元的なものではなく、どの部分を切り離し、どの部分を切り離すべきでないかを見つけるための実験のスペクトラムなのである。

一方、ゼロ知識証明（ZKP）は、一方の当事者（証明者）が、他方の当事者（検証者）に対して、その有効性以上の追加情報を明らかにすることなく、あることが真実であることを知っていることを証明することを可能にします。ZKPは、より弱い暗号経済学的な保証をより強い保証に置き換えることで、保証の難易度を高めます。これは、トレードオフ・フロントを外側に押し出すことで示されます（上図を参照）。

モジュール性と「あらゆるものにおけるゼロ知識証明」は、どちらも加速し続けるトレンドだと考えています。どちらもこの分野を探求する上で興味深い視点を提供してくれますが、私たちは特にこの2つの交差点に興味を持っています。

1）モジュール性スタックのどの部分がすでにゼロ知識証明を組み込んでいるのか、そして何がまだ探求されていないのか？

2）ゼロ知識証明はどのような問題を解決できるのか？

しかし、これらの問いを掘り下げる前に、2024年のモジュラースタックについて新たな視点を持つ必要があります。

3.2024年のモジュラー・スタック

一般的に使用される4つのコンポーネント（実行、データ公開、コンセンサス、決済）を備えたモジュラー・スタックのイメージは、単純なメンタルモデルとしては有用ですが、私たちは、これはもはや十分ではないと感じます。モジュール化の分野は非常に急速に進化しているため、これはもはや十分に正確な表現ではないと感じる。さらに分解を進めると、以前はより大きな部分の一部と考えられていた新しいコンポーネントが生まれ、異なるコンポーネント間の安全な相互運用性を必要とする新たな依存関係も生まれている（これについては後で詳しく説明する）。この分野での開発のスピードを考えると、スタックのさまざまなレベルでの革新的な技術すべてに追いつくのは難しいかもしれません。

web3スタックを探求する以前の試みとしては、Kyle Samani氏（Mult1C0in）が2018年に初めて発表し、2019年に更新したものがある。これは、分散型ラストマイルインターネットアクセス（Heliumなど）からエンドユーザーの鍵管理まですべてをカバーしている。その中の原則は再利用可能かもしれないが、証明や認証など、完全に欠けている部分もある。

これらの点を考慮し、2024年、私たちは既存の4つの部分からなるモジュール式スタックを拡張した、モジュール式スタックの更新された表現を作成することを試みました。これは機能ではなくコンポーネントで分割されており、例えばピアツーピアネットワークは、別々のコンポーネントに分割されるのではなく、コンセンサスに含まれることを意味する。

1）ユーザーアクションの抽象化

現在のブロックチェーンユーザーは、複数のチェーン、ウォレット、インターフェースの間を移動する必要があり、これは面倒で、より広い普及のための摩擦になりつつあります。ユーザーアクションの抽象化とは、このような複雑さを抽象化し、ユーザーが1つのインターフェース（特定のアプリケーションやウォレットなど）とやり取りするだけで、複雑さはすべてバックエンドで発生するようにする試みの総称です。

アカウント抽象化（AA）は、スマートコントラクトが操作のたびにユーザーの署名を必要とせずにトランザクションを実行することを可能にします（「プログラム可能な暗号アカウント」）。誰が署名できるか（鍵の管理）、何に署名するか（トランザクションの負荷）、どのように署名するか（署名アルゴリズム）、いつ署名するか（トランザクションの承認条件）を定義するために使用できる。これらの機能を組み合わせることで、ソーシャルログインを使ってdAppとやり取りしたり、二要素認証（2FA）、アカウント復旧、自動化（取引の自動署名）などが可能になる。通常、イーサ（ERC-4337は2023年春に通過）に議論が集中するが、他の多くのチェーンはすでにローカルアカウントの抽象化を組み込んでいる（Aptos、Sui、Near、ICP、Starknet、zkSync）。

チェーンの抽象化により、ユーザーは1つのアカウント（1つのインターフェイスで複数のチェーン）とやり取りしながら、異なるチェーン上の取引に署名することができます。Near、ICP、dWalletを含む多くのチームがこれに取り組んでいる。これらのソリューションはMPCとチェーン署名を利用して、他のネットワークの秘密鍵をより小さな部分に分割し、ソースチェーンの検証者間で共有し、クロスチェーンの取引に署名する。ユーザーが他のチェーンとやり取りしたい場合、閾値暗号化を満たすために十分な数の検証者が取引に署名する必要がある。これにより、秘密鍵が完全に共有されることはないため、セキュリティは保たれる。しかし、検証者が結託するリスクがあるため、暗号経済的なセキュリティと検証者の分散化が依然として非常に重要である。

インテントは、高いレベルで、ユーザーの要望やニーズをブロックチェーンが実行できるアクションに変換します。これには、インテント・リゾルバ（ユーザーのインテントに対する最適な解決策を見つける役割を担う、チェーン外の専門エージェント）が必要です。DEXアグリゲーター（"最安値"）やブリッジアグリゲーター（"最安/最速ブリッジ"）など、特殊化されたインテントを使用するアプリケーションはすでにいくつかある。Generic Intent Settlement Network（Anoma、Essential、Suave）は、ユーザがより複雑なインテントを簡単に表現できるようにし、開発者がインテント中心のアプリケーションを構築できるようにすることを目的としている。しかし、このプロセスをどのように公式化するか、インテント中心の言語はどのようなものか、最適な解決策は常に存在するのか、そしてそれを見つける方法など、まだ多くの未解決の問題があります。

既存のZK統合

AA x ZK認証：一例として、SuiのzkLoginがあります。を使うことができる。第三者がSuiのアドレスと対応するOAuth識別子を関連付けることを防ぐためにZKPを使用しています。

AAウォレットのより効率的な署名検証：AA契約のトランザクションを検証することは、従来のアカウント（EOA）で開始されたトランザクションよりも大幅にコストがかかる可能性があります。Orbiterは、ZKPを活用してトランザクション署名が正しいことを検証し、AAアカウントのnonce値とガス残高を（Merkle世界状態木を介して）維持するバンドルサービスでこれに対処しようとしている。これにより、証明の集約と、オンチェーン検証のコストを全ユーザーに均等に分配することで、大幅なコスト削減を実現しています。

ZKPが対処する可能性のある未解決の問題

最良の実行または意図の履行の証明：意図とAAはユーザーの複雑さを抽象化することができますが、中央集権的な力として作用することもあり、私たちは専門化されたアクター（専門化されたアクター）（Merkle world state tree）に依存する必要があります。最適な実行経路を見つけるために、専門化されたアクター（リゾルバ）に依存する必要がある。ソルバーの善意を信頼するのではなく、ZKPは、ユーザーにとって最良のパスが、ソルバーによってサンプリングされたパスの中から選択されることを示すために使われるかもしれない。

意図的な決済のためのプライバシー保護：Taigaのようなプロトコルは、ユーザーのプライバシーを保護するために、完全に保護された意図的な決済を可能にすることを目指しています！の一部である。ZKP（Halo2）を使用して、状態遷移に関する機密情報（アプリの種類、参加者など）を隠します。

AAウォレットのパスワード回復：この提案のアイデアは、ユーザーが秘密鍵を紛失した場合にウォレットを回復できるようにすることです。コントラクトウォレットにハッシュ（パスワード、nonce）を保存することで、ユーザはパスワードの助けを借りてZKPを生成し、それが自分のアカウントであることを確認し、秘密鍵の変更を要求することができる。確認期間(3日以上)は、不正アクセスの試みに対する安全装置として使用される。

2）順序付け

取引はブロックに追加される前に順序付けされる必要があり、これはいくつかの方法で行うことができます：提案者の収益性によってソートされる（最高額の取引が優先される）、提出順序によってソートされる（先入れ先出し）、最高額の支払者から来た取引に与えられる（先入れ先出し）。(first-in-first-out）、プライベート・メモリー・プールからのトランザクションに優先権を与える、などである。

もう一つの問題は、誰がトランザクションを注文するかである。モジュールの世界では、ローリングパッカー（集中型または分散型）、L1ソート（ローリングパッカーに基づく）、共有ソートネットワーク（複数のローリングパッカーによって使用される分散型ソートネットワーク）など、これを行うことができる複数の異なる参加者が存在する。これらはすべて、信頼の前提やスケーラビリティが異なる。実際には、トランザクションの実際のソートとブロックへのパッキングは、専用の参加者（ブロックビルダー）によってプロトコルの外部で行うこともできる。

既存のZK統合

メモリプールが正しく暗号化されていることを検証する：ラディウスは、PVDE（Practically Verifiable Delayed Encryption）で暗号化されたメモリプールを持つ共有ソーティングネットワークです。ユーザーはZKPを生成し、このZKPはタイムロックパズルを解くことで有効なトランザクション、すなわち有効な署名とノンスを含むトランザクションが正しく復号化され、送信者がトランザクションの支払いに十分な残高を持っていることを証明するために使用される。

ZKPによって解決される可能性のある未解決の問題

検証可能なシーケンスルール（Verifiable Sequencing Rules：VSR）：提案者／シーケンサーに実行順序に関する一連のルールを課し、これらのルールが守られることを追加保証する。検証はZKPまたは不正証明によって行うことができ、後者は提案者／発注者が不正を行った場合にカットされる、十分に大きな金銭的マージンを必要とする。

3）実行（Extended Write）

実行レイヤーには状態更新のロジックが含まれ、スマートコントラクトが実行されます。計算結果を返すことに加えて、zkVMは状態遷移が正しく実行されたかどうかを証明することができます。これにより、他のネットワーク参加者は、トランザクションを再実行することなく、証明を検証するだけで正しい実行を確認することができます。

より高速で効率的な検証に加えて、証明可能な実行のもう1つの利点は、ガスや限られたオンチェーンリソースの典型的な問題に遭遇しないため、より複雑な計算を実行できることです。これにより、計算集約的で保証された計算を利用する、全く新しいアプリケーションをブロックチェーン上で実行する道が開かれます。

既存のZK統合

zkEVMローリングパッケージング：イーサとの互換性のために最適化され、EVM実行環境を証明する特別なタイプのzkVM。2023年には、Polygon zkEVM、zkSync Era、Scroll、Lineaなど、複数のzkEVMが発表されました。polygonは最近、ブロックあたり0.20～0.50ドルでメインネットの証明に使用できる、タイプ1のzkEVMプローバを発表しました！RiscZeroもEtherブロックを証明できるソリューションを持っていますが、コストが高く、ベンチマークも限られています。

代替zkVM：いくつかのプロトコルは、Etherとの互換性を最大化しようとするのではなく、パフォーマンス/証明性（Starknet、Zorp）または開発者の利便性のために最適化された別の道を選びました。後者の例としては、zkWASMプロトコル（Fluent、Delphinus Labs）やzkMOVE（M2、zkmove）があります。

プライバシーに特化したzkVM：この場合、ZKPは再実行の回避とプライバシーの実現という2つの目的で使用されます。ZKPだけで実現できるプライバシーは限られているが（個人のプライベートな状態のみ）、これから登場するプロトコルは、既存のソリューションに多くの表現力とプログラマビリティを追加する。

ZKコプロセッサ：オフチェーンデータ（ただし状態は含まない）に対するオンチェーン計算を可能にします。ZKPは正しい実行の証明に使われ、楽観的コプロセッサよりも早く解決するが、コストとトレードオフの関係にある。ZKPを生成するコストや難しさを考慮すると、開発者がZKモードか楽観的モードかを選択できる（コストと保証の難しさのトレードオフ）Brevis coChainのようなハイブリッドバージョンも見られます。

ZKPが対処するかもしれない未解決の問題

zkVMの包含：ほとんどのベースレイヤー（L1）は、正しい状態遷移を検証するために、まだ再実行を使用しています。zkVMをベースレイヤーに組み込むことで、検証者が証明を検証できるため、これを回避できます。これにより、運用効率が向上する。ほとんどの焦点はイーサであり、zkEVMを組み込んだベースレイヤーを望んでいますが、他の多くのエコシステムも再実行に依存しています。

zkSVM：SVMは現在主にSolana L1で使用されていますが、Eclipseのようなチームは、Ether上で決済するロールオーバーにSVMを使用する実験を行っています。SVMにおける状態遷移の潜在的な課題に対処するためである。しかし、完全なzkSVMはまだ検討されていません。おそらく問題の複雑さと、SVMが証明可能性以外のことのために最適化されているという事実が原因でしょう。

4）データクエリ（Read Extensions）

データクエリ、つまりブロックチェーンからのデータの読み取りは、ほとんどのアプリケーションで重要な部分です。近年の議論や努力の多くは書き込みの拡張（実行）に集中していますが、読み取りの拡張は（特に分散環境では）両者のバランスが悪いため、より重要です。読み取りと書き込みの比率はブロックチェーンによって異なりますが、1つのデータポイントとして、Solana上のノードへの呼び出しの96%以上が読み取り呼び出しであるというSigの推定があります（2年間の実証データに基づいています）。

読み取りを拡張することには、専用のバリデータクライアント（Solana上のSigなど）を通じてパフォーマンスを向上させる（1秒あたりの読み取り回数を増やす）だけでなく、例えばコプロセッサの助けを借りて、より複雑なクエリ（読み取りと計算の組み合わせ）を可能にすることも含まれます。

もう1つの切り口は、データクエリへの分散型アプローチです。今日、ブロックチェーンにおけるほとんどのデータクエリ要求は、RPCノード（Infura）やインデクサ（Dune）など、（レピュテーションに基づく）信頼できるサードパーティによって処理されている。より非中央集権的なオプションの例としては、The Graphやプルーフ・オブ・ストレージ・オペレーター（これも検証可能）がある。また、Infura DINやLava Network（分散RPCに加えて、Lavaは追加のデータアクセスサービスを計画しています）のような分散RPCネットワークを作成する試みもあります。

既存のZK統合

保存証明：信頼できるサードパーティを使用することなく、ブロックチェーンから過去および現在のデータを照会できます。この領域で構築されているプロジェクトの例には、Axiom、Brevis、Herodotus、Lagrangeが含まれます。

ZKPが解決するかもしれないオープンな問題

プライバシーの状況効率的なクエリ：プライバシー・プロジェクトでは、しばしばUTXOモデルの変種を使用します。これはアカウント・モデルよりも優れたプライバシー特性を持ちますが、開発者の利便性を犠牲にしています。プライベートのUTXOモデルはまた、同期の問題につながる可能性があります。Zcashは2022年以降、プライバシートランザクションの大幅な増加を経験した後、この問題に苦労してきました。ウォレットは資金を使用する前にチェーンと同期する必要があるため、これはネットワーク運用にとって非常に基本的な課題です。この問題を見越して、Aztecは最近、ノートディスカバリーのアイデアを募集するRFPを発表しましたが、明確な解決策はまだ見つかっていません。

5）証明

証明と検証は、ZKPを組み込むアプリケーションが増えるにつれて、モジュールスタックの重要な部分に急速になりつつあります。しかし、今日のほとんどの証明インフラストラクチャはまだライセンス供与された中央集権的なものであり、多くのアプリケーションは単一の証明者に依存しています。

集中化されたソリューションはそれほど複雑ではありませんが、証明アーキテクチャを分散化し、モジュールスタックの別のコンポーネントに分割することで、いくつかの利点がもたらされます。重要な利点の1つはアクティビティ保証であり、頻繁な証明生成に依存するアプリケーションには不可欠である。また、複数のプローバに対する競争と作業負荷の共有により、検閲への耐性が高まり、利用料が下がるというメリットもあります。

利用可能なハードウェアをより効率的に利用でき、プローバにとって複雑でないため、単一アプリケーションのプローバネットワーク（1つのアプリ、多数のプローバ）よりも、汎用プローバネットワーク（多数のアプリ、多数のプローバ）の方が望ましいと考えます。より高い利用率によって、プローバはより高い料金（それでも固定費をカバーする必要がある）によって冗長性を補う必要がないため、ユーザーはより低いコストの恩恵を受けることもできます。

図キャピタルは、プルーフ生成とプルーフ集約（これは基本的にプルーフ生成ですが、トレースを実行する代わりに2つのプルーフを入力として受け取るだけです）を含む、現在のプルーフサプライチェーンの状況の良い概要を提供しています。

既存のZK統合

STARK vs. SNARKパッケージング: STARKは以下のことが証明されました。STARKの欠点は、高速で信頼設定が不要であることですが、Ether L1で検証するのに高価な大きな証明を生成することです。最終段階としてSTARKをSNARKで包むことで、Ether上での検証コストを大幅に削減することができる。しかし、これは複雑さを増し、このような「複合証明システム」の安全性は十分に研究されていない。

汎用分散型証明ネットワーク： より多くのアプリケーションを分散型証明ネットワークに統合することで、証明者はハードウェアをより効率的に利用できるようになり（ハードウェアの利用率が高くなり）、また証明者はハードウェアをより効率的に利用できるようになります。ハードウェアをより効率的に利用できるようになり（ハードウェアの利用率が高くなる）、また、ユーザーにとっても安価になる可能性がある（ハードウェアの冗長化のための費用が不要になる）。

ZKPが解決するかもしれない未解決の問題

ZK不正証明：楽観的なソリューションでは、誰でも状態遷移に挑戦でき、挑戦中に不正証明を作成できる。不正証明を作成することができます。ZK Fraud Proofは、チャレンジされている状態遷移のプルーフを作成することでこの問題を解決し、より効率的な検証（再実行不要）を実現し、決済を高速化する可能性があります。少なくともOptimism（O1 LabsとRiscZeroとの提携）とAltLayer x RiscZeroはこの問題に取り組んでいる。

より効率的な証明の集約：ZKPの優れた特徴の1つは、検証コストを大幅に増加させることなく、複数の証明を1つの証明に集約できることです。これにより、検証コストを複数の証明やアプリケーションに分散させることができる。証明集約も証明であるが、入力は実行トレースの代わりに2つの証明である。この分野のプロジェクトの例としては、NEBRAやGevulotがある。

6）データ公開（可用性）

データ公開（DP）は、データが短期間（1～2週間）で利用でき、容易に検索できることを保証します。簡単に取り出すことができます。これは、セキュリティ（Optimistic Rollupsは、1～2週間のデータ入力を必要とするチャレンジ中に再実行することにより、正しい実行を検証する）およびアクティビティ（システムがProof of Validityを使用している場合でも、データは、エスケープルートのための資産の所有権を証明するため、またはトランザクションを強制するために必要とされる場合がある）にとって重要である。ユーザー（zk-bridgesやRollupsなど）は、データが削除されるまでトランザクションや状態を保存するコストをまかなうために、1回限りの支払いを行う必要がある。データ配布ネットワークは、長期的なデータ保存のために設計されていない（可能な解決策については次のセクションを参照）。

Celestiaは、DPレイヤーの主要ネットワークを公開した最初の代替案です（10月31日）が、Avail、EigenDA、Near DAなどのプロジェクトが2024年に開始される予定であるため、すぐに多くの代替案から選択できるようになるでしょう。さらに、イーサネットのEIP 4844アップグレードは、イーサネット上のデータ配信の効率を改善し（同時に、Blobストレージのための独立した料金市場を創設する）、完全なタンクスライシングへの道を開く。

多くのDPソリューションは、ソブリン・ロールアップの共有セキュリティ（例：CelestiaやAvail）や、ロールアップ間のスムーズな相互運用性（例：AvailのNexus）など、純粋なデータ配信以外のサービスも提供しています。 また、長期的な状態保存だけでなく、データ配布を提供するプロジェクト（Dom1C0nやZero Gravityなど）もあり、これは説得力のある提案だ。 これはまた、モジュール式スタックに2つのコンポーネントを再バンドルした例でもあり、今後もっと見られるかもしれないものだ（さらなるアンバンドリングと再バンドル化の実験）。

既存のZK統合

訂正されたコードの正しさを検証する：訂正されたコードは、符号化されたデータの一部が利用できなくても、元のデータを復元できるように、ある程度の冗長性をもたらします。これはまた、データが存在することを確率的に保証するために、ライトノードがブロックの一部だけをサンプリングする分散ストレージ（DAS）の前提条件でもある。悪意のある提案者がデータを誤ってエンコードした場合、ライトノードが十分な数のユニークなブロックをサンプリングしても、元のデータは復元できない可能性があります。正しい訂正された削除コードの検証は、有効性の証明（ZKP）または不正の証明のいずれかを使用して行うことができますが、後者はチャレンジ期間に関連する遅延に悩まされます。有効性の証明は、Celestia以外のすべてのソリューションで使用されています。

ZKライトクライアントによるデータブリッジの提供：外部データパブリッシングレイヤーを使用するロールアップは、データが正しくパブリッシングされたことを決済レイヤーに通知する必要があります。そこで、データ認証ブリッジが活躍する。ZKPを使用することで、イーサ上のソースチェーンのコンセンサス署名をより効率的に検証することができます。Avail（VectorX）とCelestia（BlobstreamX）のデータ認証ブリッジは、どちらもSuccinctとのパートナーシップで構築されたZKライトクライアントによって提供されています。

Celestiaは、正しい正しい削除コードを検証するために有効性の証明を統合しています：Celestiaは現在、正しい正しい削除コードを検証するために不正な証明を使用しているため、データ公開ネットワークにおける異常値です。悪意のあるブロック提案者が誤ってデータをエンコードした場合、他の無傷のノードが不正証明を生成して、それに異議を唱えることができます。このアプローチは実装が比較的簡単な反面、遅延が発生し（ブロックは不正証明ウィンドウの後にのみ確定される）、ライトノードは不正証明を生成する正直なフルノードを信頼する必要がある（これは単独では検証できない）。しかし、Celestiaは現在のReed-SolomonエンコーディングとZKPを組み合わせて正しいエンコーディングを証明する方法を模索しており、これにより最終的な確実性を大幅に減らすことができる。このトピックに関する最新の議論は、以前のワーキンググループの記録（CelestiaのベースレイヤーにZKPを追加する、より一般的な試みに加えて）を含め、ここで見ることができます。

ZK-プルーフDAS：ZK-プルーフデータの可用性について、いくつかの調査が行われています。ライトノードは、データの小さなチャンクをダウンロードして定期的なサンプリングを行うのではなく、MerkleルートとZKPを検証するだけでよいのです。これによって、ライトノードの要件はさらに削減されますが、開発は停滞しているようです。

7)長期（状態）保存

履歴データの保存は、主に同期を目的とし、データ要求に対応するために重要です。しかし、すべてのフルノードがすべてのデータを保存できるわけではなく、ほとんどのフルノードはハードウェア要件を合理的に保つために古いデータを切り捨てます。その代わりに、私たちは、すべての履歴データを保存し、ユーザーの要求に応じて利用できるようにするために、特別な関係者（アーカイブノードとインデクサー）に依存しています。

また、FilecoinやArweaveのように、リーズナブルな価格で長期的な分散ストレージソリューションを提供する分散ストレージプロバイダーもあります。ほとんどのブロックチェーンは正式なアーカイブ保存プロセスを持っていない（誰かが保存してくれることだけに頼っている）が、分散型ストレージプロトコルは、過去のデータを保存し、ストレージネットワークに組み込まれたインセンティブによって一定の冗長性（少なくともデータを保存するためのXノード）を追加するための良い選択肢である。

既存のZK統合

ストレージの証明：長期ストレージプロバイダーは、彼らが主張するすべてのデータを保存したことを証明するために、定期的にZKPを生成する必要があります。この例として、FilecoinのProof of Time and Space (PoSt)があり、ストレージプロバイダーはPoStチャレンジに成功するたびにブロックを報酬として受け取ることができます。

ZKPが解決できる問題

データの出所と機密データを閲覧する権限の証明：機密データを交換したい信頼されていない2つの当事者に対して、ZKPを使用することで、実際のファイルをアップロードしたり、機密データを公開したりすることなく、一方の当事者が必要な権限を持つことを証明できます。実際のファイルをアップロードしたり、パスワードやログイン情報を公開したりすることなく。

8）合意

ブロックチェーンが分散P2Pシステムであることを考慮すると、グローバルな真実を決定する信頼できる第三者は存在しません。その代わりに、ネットワーク内のノードは、コンセンサスと呼ばれるメカニズムを通じて、現在の真実（どのブロックが正しいか）を全会一致で決定する。PoSベースのコンセンサス方法は、BFTベース（検証者のビザンチンフォールトトレラントコミュニティが最終的な状態を決定する）とチェーンベース（最終的な状態がフォーク選択ルールによって遡及的に決定される）に分類することができます。既存のPoSコンセンサス実装のほとんどはBFTベースであるが、カルダノは最も長いチェーン実装の例である。また、Narwhal-BullsharkのようなDAGベースのコンセンサスメカニズムに注目が集まっており、Aleo、Aptos、Suiなどのプロジェクトで様々な形で実装されている。

コンセンサスは、共有シーケンサー、分散型証明、ブロックチェーンベースのデータ公開ネットワーク（EigenDAのような委員会ベースではないもの）など、モジュールスタックの多くの異なるコンポーネントの重要な部分です。

既存のZKとの統合

ZKプライバシーネットワークにおける誓約：PoSベースのプライバシーネットワークは、誓約されたトークンを保有する人々が、プライバシーとコンセンサスへの参加（および誓約に対する報酬）のどちらかを選択しなければならないという課題をもたらします。Penumbraは、誓約の報酬を排除し、代わりに誓約されていない誓約と誓約された誓約を異なる資産として扱うことで、この問題を解決することを目指しています。このアプローチでは、各検証者が誓約した総額は公開されたままですが、個々の手数料は非公開に保たれます。

プライベート・ガバナンス：匿名投票を可能にすることは、暗号通貨空間における長年の課題であり、例えばNouns Private Votingプロジェクトはこれを前進させようとしている。ガバナンスについても同様で、少なくともPenumbraは提案の匿名投票に取り組んでいる。この場合、ZKPは、誰かが投票する権利があること（トークンの所有権など）や、特定の投票基準が満たされているかどうか（投票がまだ行われていないかなど）を証明するために使うことができる。

非公開のリーダー選挙：イーサリアムは現在、各期間の最初に次の32ブロックの提案者を選挙しており、この選挙結果は公開されています。このため、悪意のある者がイーサを無効化しようと、各提案者に対して順番にDoS攻撃を仕掛けるリスクがある。この問題に対処するため、WhiskはEther上でブロック提案者を選出するためのプライバシーを保護するプロトコルを提案する。バリデータはZKPを使用して、シャッフリングとランダム化が正直に実行されたことを証明する。同様の目標を達成する方法は他にもあり、そのいくつかはa16zによるこのブログ記事で取り上げられている。

署名の集約：ZKPを使って署名を集約することで、署名検証の通信と計算のオーバーヘッドを大幅に削減できます（個々の署名の代わりに集約された証明を検証する）。これはすでにZKライトクライアントで利用されていますが、コンセンサスに拡張されるかもしれません。

9）決済

決済は最高裁判所に類似しており、状態遷移の正しさを検証し、紛争を解決するための究極の真実の情報源です。取引は、不可逆性の時点で（あるいは確率的最終性の場合は、逆転が十分に困難な時点で）最終的なものとみなされる。確定に必要な時間は、使用される決済レイヤーに依存し、さらに使用される特定の確定ルールとブロックタイムに依存します。

ロールアップがトランザクションを承認するためにイーサからの確認を待つ必要があるためです（楽観的なロールアップでは7日間、有効なロールアップでは12分と検証時間）。この結果、ユーザーエクスペリエンスが低下する。この問題を解決するために、エコシステムに特化したソリューション（Polygon AggLayerやzkSync HyperBridgeなど）や、EigenLayerの経済的安全性を活用して複数の異なるRollupを相互に接続することを目的としたNearのFast Finality Layerのような汎用的なソリューションなど、複数の取り組みが行われている。経済的な安全性を活用して、複数の異なるロールアップ・エコシステムを接続することを目的としています。また、完全なファイナリティを待つことを避けるために、EigenLayerをソフトコンファメーションローカルRollupブリッジングに使用するオプションもあります。

既存のZK統合

妥当性ロールアップによる決済のスピードアップ：楽観的ロールアップとは異なり、妥当性ロールアップはチャレンジ期間を必要としません。これは、チャレンジの有無にかかわらず、ZKPが正しい状態遷移を正当化することに依存するためである(Pessimistic Rollup)。これにより、ベースレイヤーでの決済がより速くなり（イーサの7日間に対して12分）、再実行を避けることができます。

10）セキュリティ

保証の難しさに関連するセキュリティは、ブロックチェーンの価値提案の重要な部分です。しかし、暗号経済的なセキュリティをナビゲートすることは難しく、参入障壁を高め、それを必要とするアプリケーション（さまざまなミドルウェアや代替L1）には革新的な摩擦をもたらします。

共有セキュリティのアイデアは、既存のPoSネットワークの経済的セキュリティを活用し、各コンポーネントが独自のセキュリティを立ち上げようとするのではなく、追加の緩和リスク（ペナルティ条件）を課すことです。似たようなことがPoWネットワーク（マージマイニング）でも試みられたが、インセンティブが一貫していないため、採掘者が結託して合意し、プロトコルを操作することが容易になった（物理的な世界で行われる作業、つまり計算力を使った採掘のため、悪い行動にペナルティを与えることが難しい）。の両方のインセンティブがあるためです。

共有セキュリティを中心に構築されたプロトコルには次のようなものがあります：

EigenLayerは、既存のイーサリアムセキュリティを活用して幅広いアプリケーションを保護するように設計されています。ホワイトペーパーは2023年初頭にリリースされ、EigenLayerは現在メインネットのテスト段階にあり、今年後半にはフルメインネットの展開が予定されています。

Cosmosは2023年5月にインターチェーンセキュリティ（ICS）を開始し、Cosmos Hub（約24億ドルの誓約済みATOMに支えられたCosmos最大のチェーンの1つ）がそのセキュリティを消費者チェーンに貸し出すことを可能にしました。Cosmos Hubを駆動するバリデータと同じセットをコンシューマーチェーン上のブロックの検証に使用することで、Cosmosスタックの上に新しいチェーンを立ち上げる際の障壁を下げることを目的としている。しかし、現在アクティブなコンシューマーチェーンは2つしかない（NeutronとStride）。

Babylonはまた、ビットコインを共有セキュリティで利用可能にしようとしている。マージマイニングに関連する問題（悪行を罰することの難しさ）に対処するため、ユーザーがビットコインをビットコイン上の誓約契約にロックできる仮想PoSレイヤーを構築している（ブリッジングは不要）。ビットコインにはスマートコントラクト層がないため、誓約契約の削減ルールはビットコインスクリプトのUTXOトランザクションとして表現される。

他のネットワークでのリプレッジには、NearのOctopusやSolanaのPicassoがあります。Polkadotのパラレルチェーンも共有セキュリティの概念を活用しています。

既存のZK統合

ZKと経済的セキュリティのハイブリッド：ZKベースのセキュリティ保証はより強力かもしれないが、証明はアプリによってはまだコストがかかりすぎ、生成に時間がかかりすぎる！.その一例がBrevis coChainで、ETHの再担保者から経済的セキュリティを導き出し、（ZK詐欺証明によって）計算を楽観的に保証するコプロセッサです。dAppは、セキュリティとコストのトレードオフに対する特定のニーズに応じて、純粋なZKモデルとcoChainモデルのどちらかを選択できます。

11）相互運用性

マルチチェーンの世界における安全で効率的な相互運用性は、ブリッジハッキングで失われた28億ドルによって証明されているように、依然として大きな問題です。モジュラーシステムでは、相互運用性がさらに重要になる。他のチェーン間で通信する必要があるだけでなく、モジュラーブロックチェーンは異なるコンポーネント（DA層や決済層など）間でも通信する必要がある。その結果、統合型ブロックチェーンのように、単にフルノードを稼働させたり、個々のコンセンサス証明を検証したりすることは、もはや実現不可能となる。これは方程式にさらに多くの変数を加えることになる。

相互運用性には、トークンのブリッジングとブロックチェーン間のより一般的なメッセージングが含まれます。利用可能なオプションはいくつかあり、どれもセキュリティ、レイテンシ、コストの点で異なるトレードオフがあります。この3つを同時に最適化することは非常に難しく、通常は少なくとも1つを犠牲にする必要がある。加えて、異なるチェーンで異なる標準が存在するため、新しいチェーンに実装することが難しくなります。

さまざまなタイプのライトクライアント（またはノード）の明確な定義はまだありませんが、FluentとModular Mediaの共同創設者であるDinoは、この投稿で良い紹介をしています。今日、ほとんどのライトクライアントはコンセンサスの検証しか行っていないが、理想的には、信頼の仮定を減らすために、実行とDAを検証できるライトクライアントが必要だ。これによって、高いハードウェア要件なしに、完全なノードのセキュリティに近づくことが可能になるだろう。

既存のZK統合

ZKライトクライアント（コンセンサス検証）：現在のライトクライアントのほとんどは、他のチェーンのコンセンサスを検証できます。現在のライトクライアント（コンセンサス検証）：現在のライトクライアントは、他のチェーンのコンセンサスを検証することができます。 ZKPは、検証のスピードアップとコスト削減のために使用される。元のチェーンで使用されていた署名スキームが、検証対象のチェーンでネイティブにサポートされているとは限らないからである。ブリッジングにおけるZKライトクライアントの重要性は高まることが予想されるが、現在の展開で直面する摩擦には、証明や検証のコスト、新しいチェーンごとにZKライトクライアントを実装することなどがある。この分野のプロトコルの例としては、Polyhedra、Avail、CelestiaのData Confirmation Bridge、Electron LabsのzkIBCが挙げられます。

保管証明：前述の通り、保管証明によって、信頼できる第三者を利用することなく、ブロックチェーン上の過去および現在のデータを照会することが可能になります。信頼できるサードパーティを利用する必要がない。これはまた、チェーンをまたいだ通信に使用できるため、相互運用性にとっても重要である。例えば、ユーザーはあるチェーン上でトークンを持っていることを証明し、それを別のチェーン上で（ブリッジングなしで）ガバナンスに使用することができる。また、LambdaClassによって開発されたこのソリューションのように、保存された証明をブリッジングに使おうとするソリューションもある。

ZK オラクル：オラクルは仲介者として機能し、実世界のデータをブロックチェーンに橋渡しする。 ZKオラクルは、データの出所と完全性、およびそのデータ上で実行されるあらゆる計算を証明できるようにすることで、現在のレピュテーションベースのオラクルモデルを改善する。

ゼロ知識証明（ZKP）が解決できるオープンな問題

A.コンプリート・ライト・クライアント：チェーンの残りの部分を盲目的に信頼する検証者のセットとは異なり、コンプリート・ライト・クライアントは正しい実行とDAも検証します。これは、信頼の前提条件とフルノードへの接近の数を減らすと同時に、ハードウェア要件を低く抑える（より多くの人がライトクライアントを実行できるようにする）。しかし、コンセンサス以外の何かを検証することは、ほとんどのチェーン、特にイーサではまだコストがかかりすぎる。さらに、ライトクライアントはメッセージを検証することしかできません（問題の半分）。つまり、メッセージが正しくないかどうかを認識することはできますが、アクションを起こすための追加メカニズムが必要です。

B.アグリゲーションレイヤー：ポリゴンのアグリゲーションレイヤーは、集約された証明と統一されたブリッジングコントラクトを活用することで、エコシステム内のL2間のスムーズな相互運用を可能にすることを目的としています。アグリゲーションの証明は、より効率的な検証とより高いセキュリティの両方を可能にします。依存関係のあるチェーンの状態とバンドルの一貫性を強制し、ロールアップの状態が他のチェーンの無効な状態に依存している場合、その状態はイーサ上で解決できないことを保証します。

5.ゼロ知識証明（ZKP）がモジュラースタックを共食いさせるとどうなりますか？

ZKPを生成するのが非常に速く（ほとんど光速に近い）、非常に安価（ほとんど無料）になる状態になれると仮定すると、最終結果はどのようになるのでしょうか？言い換えれば、ZKPがモジュラースタックを食い尽くすとどうなるのでしょうか？

全体として、私たちはこのシナリオには2つの現実があると考えています：

すべての不要な再実行の排除：1/N実行モデル（再実行のあるN/Nモデルの代わりに）に移行することで、全体の冗長性を大幅に削減します。の代わりに）1/N実行モデルに移行することで、ネットワークの全体的な冗長性を大幅に削減し、基礎となるハードウェアのより効率的な使用を実現します。多少のオーバーヘッドは残りますが、これによりブロックチェーンは計算効率の点で漸近的に集中型システムに近づくことができます。

ほとんどのアプリは、経済的な安全性よりも、ZKP対応の暗号保証に依存します。証明を生成するコストと時間がもはや関連性のある要素でなくなったとき、ほとんどのアプリは、より強力な保証のためにZKPに依存すると考えられます。これには、ZKPアプリを構築するためのユーザビリティと開発者の利便性の向上も必要になりますが、これらは複数のチームが取り組んでいる問題です。

3つ目の条件はプライバシー（または情報フロー管理）に関するものですが、これはより複雑です。クライアント側の証明を使用することで、ZKPはいくつかのプライバシーアプリケーションに使用することができ、これはAleo、Aztec、またはPolygon Midenのようなプラットフォームが構築しているものですが、すべての潜在的なユースケースに対して広範なプライバシー保護を達成することは、MPCとFHEの進捗にも依存しています。

6.私たちの議論に対するリスク

もし私たちが間違っていて、未来がモジュラーでもゼロ知識でもなかったらどうなるでしょうか？

モジュール化は複雑さを増大させる

ユーザーも開発者も、チェーン数の増加によって影響を受けます。ユーザーは複数のチェーン（そして場合によっては複数のウォレット）にまたがって資金を管理する必要があります。一方、アプリ開発者は、まだ進化を続けている領域で安定性や予測可能性が低く、どのチェーンでアプリを構築するかを決めるのが難しくなっている。また、状態や流動性の断片化も考慮する必要がある。どのコンポーネントがデカップリングに適し、どのコンポーネントが再カップリングされるかを模索している最中である現在、これは特に当てはまります。私たちは、ユーザー操作の抽象化と、安全で効率的な相互運用性ソリューションが、この問題の解決策の重要な部分であると考えています。

ZKは十分に効率的だろうか？

証明の生成にはとにかく時間がかかりすぎ、証明と検証のコストは今日でも高すぎます。多くのアプリケーションでは、Trusted Execution Environments/TEE（プライバシー）や楽観的/暗号的な経済的セキュリティソリューション（コスト）といった競合するソリューションの方が、今日でもまだ理にかなっています。

しかしながら、ZKPのソフトウェア最適化とハードウェアアクセラレーションに関する作業はすでに進行中です。プルーフ・アグリゲーションは、複数の異なる参加者にコストを分散させることで、検証コストをさらに削減します（ユーザーあたりのコストが低くなります）。また、ZKPをより最適に検証するためにベース・レイヤーを適合させる可能性もある。ZKPのハードウェア・アクセラレーションに関する1つの課題は、プルーフ・システムの急速な発展である。そのため、特殊なハードウェア（ASIC）を作成することは困難であり、基礎となる証明システムの標準が変更されると、すぐに陳腐化してしまいます。

Ingonyamaは、ZKスコアと呼ばれる比較可能な指標を通じて、証明者性能のベンチマークを作成しようと試みました。これは、計算を実行するコスト（OPEX）に基づいており、MMOPS/WATTを追跡します。このトピックに関する参考文献は、CysicとIngonyamaのブログ、およびWei Daiによるこの講演を参照してください。

限定的なZKPによって提供されるプライバシーは有用か？

ZKPは個人的な状態のプライバシーを可能にするためにのみ使用でき、複数のパーティが暗号化されたデータで計算する必要がある共有状態（例えば、プライベートなUniswap）では使用できません。完全なプライバシーを実現するには、FHEとMPCも必要だが、より広く使用するためには、コストと性能の大幅な改善が必要だ。とはいえ、ZKPはIDソリューションや決済など、プライベートな共有状態を必要としない特定のユースケースには有用である。すべての問題を同じツールで解決する必要はないのだ。

7.まとめ

さて、これで私たちはどうなるのでしょうか？日々進歩しているとはいえ、まだやるべきことはたくさんある。取り組むべき最も差し迫った問題は、スピードやコストを犠牲にすることなく、異なるモジュラー・コンポーネント間で価値や情報を安全に受け渡す方法と、エンドユーザーがチェーン間のブリッジングやウォレットの切り替えなどを心配する必要がないように、これらすべてを抽象化する方法です。

私たちはまだ実験段階ですが、それぞれのユースケースにとってベストなトレードオフがどこにあるのかを探るうちに、物事は時間とともに安定していくはずです。その結果、（非公式または正式な）標準が出現する余地が生まれ、これらのチェーンの上に構築されるものにとってより安定したものになるでしょう。

ZKPを生成するコストと複雑さのために、暗号経済的なセキュリティがデフォルトで使用されるユースケースは今日でもまだ多くあり、両方の組み合わせが必要なものもあります。しかし、証明と検証のコストと待ち時間を削減するために、より効率的な証明システムと特殊なハードウェアを設計するにつれて、この割合は時間の経過とともに減少するはずです。コストとスピードが指数関数的に削減されるたびに、新たなユースケースが解放されるでしょう。

この投稿はZKPに焦点を当てていますが、最新の暗号ソリューション（ZKP、MPC、FHE、TEE）がどのように連携できるかを検討することも増えています。