次の兆ドルトラックの詳細な分析：ゼロ知識証明と分散コンピューティングの組み合わせ

より多くの実際のビジネス シナリオを Web3 に接続したい場合は、ゼロ知識証明と分散コンピューティングの組み合わせがチャンスをもたらします。

執筆者: X Research DAO

1. 分散コンピューティングの発展の歴史と市場展望

1.1 開発の歴史

当初、各コンピューターは 1 つのコンピューティング タスクしか実行できませんでした。マルチコアおよびマルチスレッド CPU の登場により、1 台のコンピューターで複数のコンピューティング タスクを実行できるようになりました。

大規模 Web サイトのビジネスが拡大するにつれて、単一サーバー モデルでは拡張が難しくなり、ハードウェア コストが増加します。複数のサーバーで構成されるサービス指向アーキテクチャが登場しました。サービス登録者、サービスプロバイダー、サービス消費者の 3 つの部分で構成されます。

しかし、ビジネスとサーバーの増加に伴い、SOA モデルにおけるポイントツーポイント サービスの保守性と拡張性はより困難になります。マイクロコンピュータの原理と同様に、バス モードはさまざまなサービス ユニットを調整するように見えます。サービス バスは、ハブのようなアーキテクチャを通じてすべてのシステムを接続します。このコンポーネントは ESB (Enterprise Service Bus) と呼ばれます。さまざまな形式や標準のサービス プロトコルを翻訳および調整する仲介役として機能します。

その後、アプリケーション プログラミング インターフェイス (API) に基づく REST モデル通信が、そのシンプルさと高い構成可能性で際立っていました。各サービスは REST 形式でインターフェースをエクスポートします。クライアントが RESTful API を通じてリクエストを行うと、リソースの状態の表現がリクエスト元またはエンドポイントに配信されます。この情報または表現は、JSON (Javascript Object Notation)、HTML、XLT、Python、PHP、またはプレーンテキストのいずれかの形式で HTTP 経由で送信されます。 JSON は最も一般的に使用されているプログラミング言語です。名前は「JavaScript Object Notation」を意味しますが、さまざまな言語に適用でき、人間と機械の両方で読み取ることができます。

仮想マシン、コンテナ テクノロジー、および Google からの 3 つの論文:

• 2003年、GFS: Google ファイル システム

• 2004年、MapReduce: 大規模クラスタでの簡素化されたデータ処理

• 2006年、Bigtable: 構造化データ用の分散ストレージ システム

これらは、分散ファイルシステム、分散コンピューティング、分散データベースであり、分散システムの幕を開けました。 Hadoop は Google の論文を再現したもので、Spark はより高速で使いやすく、Flink はリアルタイム コンピューティングのニーズを満たします。

しかし、これまでのシステムはすべて分散システムであり、完全なピアツーピア システムではありませんでした。 Web3分野では、これまでのソフトウェアアーキテクチャは完全に覆されます。分散システムの一貫性、不正行為防止攻撃、ダストトランザクション防止攻撃などの一連の問題はすべて、分散コンピューティング フレームワークに課題をもたらします。

Ethereum に代表されるスマート コントラクト パブリック チェーンは、抽象的には分散コンピューティング フレームワークとして理解できますが、EVM は命令セットが制限された仮想マシンであり、Web2 に必要な一般的なコンピューティングを実行することはできません。さらに、オンチェーンのリソースは非常に高価です。それにもかかわらず、イーサリアムは、ピアツーピア通信、ネットワーク全体でのコンピューティング結果の一貫性、データの一貫性などの問題を含む、ピアツーピアコンピューティングフレームワークのボトルネックも突破しました。

1.2 市場見通し

読者は上記で分散コンピューティングの歴史について学びましたが、まだ多くの混乱が残っています。読者が抱く可能性のある疑問を以下に挙げてみましょう。

ビジネスニーズの観点から、分散型コンピューティング ネットワークが重要なのはなぜですか?市場全体の規模はどのくらいですか？私たちは今どの段階にいて、将来にはどれだけの余地があるのでしょうか?どのような機会に注目する価値があるでしょうか?どうやってお金を稼ぐのか？

1.2.1 分散コンピューティングが重要な理由

イーサリアムの当初のビジョンは、世界のコンピューターになることでした。 2017 年の ICO ブームの後、ICO は依然として主に資産の発行に重点を置いていることに誰もが気づきました。しかし、2020年にはDefiサマーが到来し、多数のDappsが登場し始めました。オンチェーン データの爆発的な増加と複雑なビジネス シナリオの増加により、EVM はますます無力になってきています。 EVM では実現できない機能を実装するには、オフチェーン拡張が必要です。オラクルなどの役割はすべて、ある程度は分散コンピューティングです。

もっと広い視点で考えてみましょう。 Dappsは急速に成長しており、データ量も爆発的に増加しています。このデータの価値を計算し、その商業的価値を活用するには、より複雑なアルゴリズムが必要です。データの価値はコンピューティングによって反映され、生成されます。これらは、ほとんどのスマート コントラクト プラットフォームでは実現できないことです。

Dapp 開発は、0 から 1 を完成させるだけのプロセスを超えています。今では、より複雑なビジネス シナリオの完了をサポートするために、より強力な基盤インフラストラクチャが必要です。 Web3 全体はおもちゃのアプリケーションを開発する段階を過ぎており、将来的にはより複雑なロジックとビジネス シナリオに直面する必要があります。

1.2.2 市場全体の規模はどのくらいですか?

市場規模をどのように推定するか? Web2分野における分散コンピューティングビジネスの規模による推定は？ Web3 の市場浸透率を倍増しますか?現在市場にある対応する資金調達プロジェクトの評価額を合計しますか?

次の理由により、Web2 の分散コンピューティング市場規模を Web3 に単純にコピーすることはできません。1. Web2 分野の分散コンピューティングはほとんどのニーズを満たしていますが、Web3 分野の分散コンピューティングは市場ニーズを満たす差別化された方法です。コピーされた場合、客観的な市場背景環境に反することになります。 2. Web3分野の分散コンピューティングは、将来的に世界市場のビジネス範囲を持つことになります。したがって、市場規模をより厳密に見積もる必要があります。

Web3 分野の潜在的なトラックの全体的な予算は、次の点に基づいて計算されます。

1. トラックに含めることができる業界内の他のプロジェクトの評価がベンチマーク市場価値として使用されます。 coinmarketcap ウェブサイトのデータによると、すでに市場に流通している分散コンピューティング プロジェクトの市場価値は 67 億ドルです。

2. 収益モデルはトークン経済モデルの設計から生まれます。たとえば、現在より普及しているトークン収益モデルは、トークンを取引手数料の支払い手段として使用するというものです。したがって、取引手数料収入は、エコシステムの繁栄と取引活動のレベルを間接的に反映する可能性があります。最終的には、評価判断の基準として機能します。もちろん、担保マイニング、取引ペア、アルゴリズムステーブルコインの固定資産などに使用されるトークンの成熟モデルは他にもあります。したがって、Web3 プロジェクトの評価モデルは従来の株式市場とは異なり、国の通貨に似ています。トークンを採用できるシナリオは多岐にわたります。したがって、特定のプロジェクトを具体的に分析する必要があります。 Web3 分散コンピューティング シナリオでトークン モデルをどのように設計すべきかを検討することができます。まず、分散コンピューティング フレームワークを自分たちで設計すると仮定しましょう。どのような課題に直面するのでしょうか? a)。ネットワークは完全に分散化されているため、このような信頼できない環境でコンピューティング タスクを完了するには、オンライン レートとサービス品質を保証するためにリソース プロバイダーにインセンティブを与える必要があります。ゲームの仕組みとしては、インセンティブの仕組みが合理的であることを保証し、また、攻撃者が詐欺攻撃やウィッチ攻撃などの攻撃手段を仕掛けるのを防ぐ必要があります。したがって、POS コンセンサス ネットワークに参加するためのステーキング手段としてトークンが必要であり、まずすべてのノードのコンセンサスの一貫性を確保する必要があります。リソース提供者には、提供した作業負荷に基づいて特定のインセンティブ メカニズムが実装されます。トークンインセンティブは、ビジネスの成長とネットワーク効率の向上という点で、成長の好循環を持たなければなりません。 b)。他のレイヤー 1 と比較して、ネットワーク自体も大量のトランザクションを生成します。大量のダスト取引に直面し、取引ごとに手数料を支払うことは、市場で検証されたトークンモデルです。 c)。トークンが実用的な目的にのみ使用される場合、その市場価値をさらに拡大することは困難です。資産ポートフォリオのアンカー資産として活用し、何層にもわたる資産のネスティングを行えば、金融化の効果は大きく拡大します。全体評価額 = 担保率 * ガス消費率 * (流通量の逆数) * 単一価格

1.2.3 私たちは現在どの段階にあり、将来に向けてどれだけの余地があるのでしょうか?

2017 年から現在まで、多くのチームが分散コンピューティングの方向で開発を試みてきましたが、すべて失敗しました。失敗の理由については後ほど詳しく説明します。探索の道筋は、当初はエイリアン探索プログラムに似たプロジェクトから、従来のクラウド コンピューティングを模倣したモデル、そして Web3 ネイティブ モデルの探索へと進化しました。

トラック全体の現状としては、0から1へのブレークスルーが学術レベルで検証され、いくつかの大規模プロジェクトがエンジニアリングの実践において大きな進歩を遂げています。たとえば、現在の zkRollup と zkEVM の実装はどちらも、製品をリリースする段階にあります。

今後、改善の余地がまだ多く残されています。その理由としては、1. 検証計算の効率化が必要です。 2. 命令セットをさらに追加する必要があります。 3. まったく異なるビジネス シナリオの最適化。 4. これまでスマートコントラクトでは実現できなかったビジネスシナリオが、分散コンピューティングを通じて実現できるようになりました。

完全に分散化されたゲームについて、具体的な例を使って説明しましょう。現在、ほとんどの Gamefis では、バックエンドとして集中型サービスが必要です。バックエンドは、プレーヤーのステータス データと一部のビジネス ロジックを管理する役割を担い、アプリケーション フロントエンドは、ユーザー インタラクション ロジックとイベントのトリガーを担当し、それをバックエンドに渡します。現在、Gamefi のビジネス シナリオをサポートできる完全なソリューションは市場に存在しません。しかし、検証可能な分散コンピューティング プロトコルが登場し、バックエンドは zkvm に置き換えられました。真に分散化されたゲームを実現できます。フロントエンドは、関連するビジネス ロジックを実行するために、ユーザー イベント ロジックを zkvm に送信します。検証後、ステータスは分散データベースに記録されます。

もちろん、これは 1 つのアプリケーション シナリオにすぎず、Web2 にはコンピューティング機能を必要とするビジネス シナリオが多数あります。

1.2.4 どのような機会に注目する価値がありますか?どうやってお金を稼ぐのか？

2. 分散コンピューティングの試み

2.1 クラウドサービスモデル

現在、Ethereum には以下の問題があります。

1. 全体的なスループットは低いです。大量の計算能力を消費しますが、スループットはスマートフォンと同等です。

2. 検証熱意が低い。この問題は検証者のジレンマと呼ばれます。パッケージ化権を獲得したノードには報酬が与えられ、他のノードは検証する必要があるが、報酬は受け取れないため、検証への熱意は低い。時間が経つにつれて、計算が検証されなくなり、オンチェーン データのセキュリティにリスクが生じる可能性があります。

3. 計算量には制限があり（gasLimit）、計算コストが高くなります。

一部のチームは、Web2 で広く採用されているクラウド コンピューティング モデルを採用しようとしています。ユーザーは、コンピューティング リソースの使用時間に基づいて計算される一定の料金を支払います。このモードを採用する根本的な理由は、コンピューティング タスクが正しく実行されたかどうかを検証することは不可能であり、検出可能な時間パラメータまたはその他の制御可能なパラメータを通じてのみ検証できるためです。

結局、このモデルは人間の本質を考慮していなかったため、広く使用されませんでした。利益を最大化するために、多くのリソースが採掘に使用されます。その結果、実際に利用できるリソースが少なくなります。これは、ゲーム システム内の各役割が自らの利益を最大化しようとした結果です。

最終結果は当初の意図とは全く逆のものとなりました。

2.2 チャレンジャーモード

TrueBit はゲーム システムを使用してグローバル最適ソリューションを実現し、発行されたコンピューティング タスクが正しく実行されるようにします。

当社の高速計算フレームワークの重要なポイントは次のとおりです。

1. 役割: 問題解決者、挑戦者、判断者

2. 問題解決者はコンピューティングタスクに参加する前に資金を寄付する必要がある

3. 賞金稼ぎとして、挑戦者は問題解決者の計算結果が自分のローカルな結果と一致しているかどうかを繰り返し検証する必要があります。

4. 挑戦者は、両者の計算ステータスと一致する最新の計算タスクを抽出します。分岐点がある場合は、分岐点のMerkleツリーハッシュ値を送信します。

5. 最後に、裁判官は異議申し立てが成功したかどうかを決定します。

ただし、このモデルには次の欠点があります。

1. 挑戦者は、提出タスクを完了していれば、後から提出することができます。その結果、タイムリーさが失われます。

2.3 ゼロ知識証明を用いた計算の検証

では、それをどのように達成し、計算プロセスが検証可能であることを保証し、検証の適時性を確保するのでしょうか。

たとえば、zkEVM の実装では、検証可能な zkProof をブロックごとに送信する必要があります。この zkProof には、論理コンピューティング ビジネス コードによって生成されたバイトコードが含まれており、バイトコードが実行されて回路コードが生成されます。これにより、計算ビジネス ロジックが正しく実行され、短時間で一定の時間内に検証の適時性が保証されます。

zkEVM はスマート コントラクトが実行されるシナリオのみを対象としていますが、その本質は依然としてコンピューティング ビジネス フレームワークの下にあります。 EVM ロジックを、WASM 仮想マシンや、より一般的な LLVM 高性能仮想マシンなど、他の一般的なタイプの仮想マシンに拡張します。もちろん、エンジニアリングの実践を具体的に実施する上では多くの課題がありますが、それによって探求の余地が広がります。

十分に高性能なゼロ知識証明アクセラレーション ハードウェアと十分に最適化されたゼロ知識証明アルゴリズムが存在するという前提の下では、一般的なコンピューティング シナリオを完全に開発できます。 Web2 シナリオにおける多数のコンピューティング サービスは、ゼロ知識証明の一般的な仮想マシンによって再現できます。前述の通り、これは収益性の高いビジネス方向です。

3. ゼロ知識証明と分散コンピューティングの組み合わせ

3.1 学術レベル

ゼロ知識証明アルゴリズムの歴史的発展を振り返ってみましょう。

1. GMR85 は最も古いアルゴリズムであり、Goldwasser、Micali、Rackoff が共同で発表した論文「対話型証明システムの知識複雑性 (GMR85)」に由来しています。この論文は 1985 年に提案され、1989 年に公開されました。この論文では主に、K ラウンドの対話の後に対話型システムでステートメントが正しいことを証明するためにどれだけの知識を交換する必要があるかを説明しています。

2. ヤオのGarbled Circuit（GC）[89]任意の関数を評価できる、忘却転送に基づくよく知られた 2 者間セキュア計算プロトコル。ガーブル回路の中心的な考え方は、計算回路（AND、OR、NOT 回路を使用して任意の算術演算を実行できます）を生成フェーズと評価フェーズに分解することです。各当事者は 1 つのステージを担当し、各ステージでは回路が暗号化されるため、どの当事者も他の当事者から情報を取得することはできませんが、回路に基づいて結果を取得することはできます。暗号化された回路は、忘却転送プロトコルとブロック暗号で構成されています。回路の複雑さは、入力のサイズに応じて少なくとも直線的に増加します。ガーブル回路の発表後、ゴールドライヒ・ミカリ・ウィグダーソン（GMW）[91]は、悪意のある敵に抵抗するために、ガーブル回路の使用を複数の当事者に拡張しました。

3. シグマ プロトコルは、正直な検証者のための (特別な) ゼロ知識証明としても知られています。つまり、検証者は正直であると想定されます。この例は Schnorr 認証プロトコルに似ていますが、後者は通常非対話型である点が異なります。

4. 2013 年の Pinocchio (PGHR13): 証明と検証に必要な時間を実用的なレベルまで短縮する Pinocchio: Nearly Practical Verifiable Computation は、Zcash で使用される基本プロトコルでもあります。

5. 2016 年の Groth16: ペアリングベースの非対話型引数のサイズについて は、証明のサイズを簡素化し、検証の効率を向上させます。これは現在最も広く使用されている ZK 基本アルゴリズムです。

6. 2017 年、Bulletproofs (BBBPWM17) Bulletproofs: Short Proofs for Confidential Transactions and More では、信頼できるセットアップを必要としない、非常に短い非対話型のゼロ知識証明である Bulletproof アルゴリズムが提案されました。それは 6 か月後に Monero に適用されましたが、これは理論と応用の非常に迅速な組み合わせでした。

7. 2018 年、zk-STARKs (BBHR18) は、スケーラブルで透過的、かつ量子耐性に優れた安全な計算整合性を備えた、信頼できるセットアップを必要としない ZK-STARK アルゴリズム プロトコルを提案しました。これは、ZK 開発のもう一つの注目すべき方向性です。最も重要な ZK プロジェクトである StarkWare は、この基盤の上に誕生しました。

8. Bulletproofs の特徴は次のとおりです。

1) 信頼できるセットアップなしでNIZKをショートする

2) ペダーセンのコミットメントに基づいて

3) 証明集約をサポートする

4) 証明時間: O ( N ⋅ log ⁡ ( N ) ) O(N\cdot \log(N))O(N⋅log(N))、約30秒

5) 検証時間: O ( N ) O(N)O(N)、約1秒

6) 証明サイズ: O ( log ⁡ ( N ) ) O(\log(N))O(log(N))、約1.3KB

7) 離散対数のセキュリティ仮定に基づく

防弾は次の場合に適しています:

1) 範囲証明（約600バイトのみ）

2) 内積の証明

3) MPCプロトコルにおける中間チェック

4) 集約され分散された（多くのプライベート入力を含む）証明

9. Halo2 の主な機能は次のとおりです。

1) 信頼できるセットアップは必要なく、累積方式は PLONK のような演算と効率的に組み合わせられます。

2) IPAコミットメントスキームに基づく。

3) 繁栄した開発者エコシステム。

4) 証明時間は次の通りです: O ( N ∗ log ⁡ N ) O(N*\log N)O(N∗logN)。

5) 検証時間は次の通りである: O(1) > O(1)>O(1)>Groth16.

6) 証明サイズは、O ( log ⁡ N ) O(\log N)O(logN) です。

7) 離散対数のセキュリティ仮定に基づく。

Halo2 は次のシナリオに適しています。

1) 検証可能な計算

2) 再帰的証明構成

3) ルックアップベースのSinsemilla関数に基づく回路最適化ハッシュ

Halo2 は次のシナリオには適していません。

1) 代わりに Halo2 の KZG バージョンを使用しない限り、Ethereum での検証コストが高くなります。

10. Plonky2 の主な機能は次のとおりです。

1) 信頼できるセットアップなしで FRI と PLONK を組み合わせます。

2) SIMD を備え、64 バイトの Goldilocks フィールドを使用するプロセッサ向けに最適化されています。

3) 証明時間は次の通りです: O ( log ⁡ N ) O(\log N)O(logN)。

4) 検証時間は次のとおりです: O ( log ⁡ N ) O(\log N)O(logN)。

5) 証明サイズは、O ( N ∗ log ⁡ N ) O(N*\log N)O(N∗logN)です。

6) セキュリティ仮定に基づく：衝突耐性ハッシュ関数。

Plonky2 は次のシナリオに適しています。

1) 検証可能な計算。

2) 再帰的な証明の構成。

3) 回路の最適化にはカスタムゲートを使用します。

Plonky2 は次のシナリオには適していません。

1) 非ネイティブの算術制限のため、楕円曲線演算を含むステートメントには適していません。

現在、Halo2 は zkvm で使用される主流のアルゴリズムになっており、あらゆる種類の計算の再帰証明と検証をサポートしています。これにより、ゼロ知識証明タイプの仮想マシンの一般的なコンピューティング シナリオの基礎が築かれます。

3.2 エンジニアリングの実践

ゼロ知識証明は学術レベルでは急速に進歩していますが、実際の開発に関しては現在どの程度進んでいるのでしょうか？

私たちは複数のレベルから観察します:

• プログラミング言語: 現在、開発者が回路コードの設計方法を深く理解する必要がない特殊なプログラミング言語があり、開発のハードルが下がります。もちろん、Solidity を回路コードに変換するためのサポートもあります。開発者にとってより使いやすくなっています。

• 仮想マシン: 現在、zkvm の実装は複数あります。 1 つ目は独自に設計されたプログラミング言語で、独自のコンパイラを通じて回路コードにコンパイルされ、最終的に zkproof を生成します。 2 つ目は、Solidity プログラミング言語をサポートし、LLVM を介してターゲット バイトコードにコンパイルし、最終的に回路コードと zkproof に変換することです。 3 番目のタイプは真の EVM 同等互換性であり、最終的にはバイトコード実行操作を回路コードと zkproof に変換します。これは zkvm の終焉でしょうか?いいえ、スマート コントラクト プログラミングを超えて一般的なコンピューティング シナリオに拡張する場合でも、さまざまなソリューション向けの zkvm の基礎となる命令セットの完成と最適化する場合でも、まだ 1 対 N の段階にあります。まだ道のりは長く、多くのエンジニアリング作業を最適化して実装する必要があります。各社とも学術レベルからエンジニアリング実装まで成功を収めています。成功した者は最終的に勝者となり、前進する道を切り開くことになる。パフォーマンスの改善において大きな進歩を遂げる必要があるだけでなく、多数の開発者をエコシステムに引き付けることも必要です。タイミングは非常に重要な前提条件です。最初に市場に投入し、資本蓄積を誘致し、エコシステム内でアプリケーションが自発的に出現することが、すべて成功の要因です。

• 周辺サポートツールと機能: エディタープラグインサポート、ユニットテストプラグイン、デバッグデバッグツールなど、開発者がゼロ知識証明アプリケーションをより効率的に開発できるようにします。

• ゼロ知識証明高速化のためのインフラストラクチャ: FFT と MSM はゼロ知識証明アルゴリズム全体の中で多くの計算時間を占めるため、GPU/FPGA などの並列計算デバイスを使用して並列実行することで、時間オーバーヘッドを圧縮する効果が得られます。

• さまざまなプログラミング言語での実装: たとえば、より効率的またはパフォーマンスに優れたプログラミング言語である Rust を使用します。

• スタープロジェクトが登場しました。zkSync、Starkware などの高品質プロジェクトが、公式製品リリースの時期を相次いで発表しました。これは、ゼロ知識証明と分散コンピューティングの組み合わせがもはや単なる理論的な概念ではなく、エンジニアリングの実践において徐々に成熟しつつあることを示しています。

4. 遭遇したボトルネックとその解決方法

4.1 zkProof生成効率が低い

先ほど、市場のキャパシティ、現在の業界の発展、実際の技術の進歩についてお話ししましたが、課題はないのでしょうか?

zkProof 生成プロセス全体を分解します。

論理回路をデジタル化された R1C にコンパイルする段階では、計算の 80% が NTT や MSM などのコンピューティング サービスで実行されます。さらに、ハッシュ アルゴリズムはさまざまなレベルのロジック回路で実行されます。レベル数が増加すると、ハッシュ アルゴリズムの時間オーバーヘッドは直線的に増加します。もちろん、業界では現在、時間のオーバーヘッドを 200 倍削減する GKR アルゴリズムを提案しています。

しかし、NTT と MSM の計算時間のオーバーヘッドは依然として高いです。ユーザーの待ち時間を短縮し、ユーザー エクスペリエンスを向上させたい場合は、数学的実装、ソフトウェア アーキテクチャの最適化、GPU/FPGA/ASIC などの面で加速する必要があります。

次の図は、各 zkSnark ファミリー アルゴリズムの証明生成時間と検証時間のテストを示しています。

欠陥や課題が見えるということは、そこにチャンスが隠されているということでもあります。

1. 特定の zkSnark アルゴリズム アクセラレーションまたは一般的な zkSnark アルゴリズム アクセラレーション用のチップを設計します。他の種類の暗号化アルゴリズムと比較して、zkSnark はより多くの一時ファイルを生成し、デバイスのメモリとビデオ メモリに対する要件があります。チップのスタートアッププロジェクトも巨額の資本投資を必要としており、テープアウトが成功する保証はない。しかし、一度成功すれば、その技術的障壁と知的財産保護が堀となるだろう。チップ プロジェクトを開始するときは、最低コストを実現するために十分な交渉力を持つチャネルが必要です。全体的な品質管理を確実に行います。

2. グラフィック カード アクセラレーション SaaS サービスでは、アクセラレーションにグラフィック カードを使用します。これは、ASIC 設計よりもコストが低く、開発サイクルが短くなります。しかし、長期的にはソフトウェアのイノベーションはハードウェア アクセラレーションに置き換えられることになります。

4.2 ハードウェアリソースの大量使用

私はいくつかの zkRollup プロジェクトに関わってきましたが、最終的に、ソフトウェア アクセラレーションには大容量メモリと大容量ビデオ メモリを搭載したグラフィック カードの方が適していることが分かりました。たとえば、Filecoin マイニングでは、多数のアイドル データ パッケージング マシンが、現在人気の zkRollup プロジェクトのターゲット デバイスになっています。 Filecoin マイニングでは、C2 フェーズで、生成された回路コード ファイルを生成し、メモリにキャッシュする必要があります。ビジネス コード ロジックが非常に複雑な場合、対応する生成された回路コードも非常に大きくなり、最終的なプレゼンテーション形式は大きな一時ファイルになります。特に、回路コード上のハッシュ演算に関しては、AMD CPU 命令による高速化が必要です。 CPUとメモリ間の高速なやり取りのため、効率が非常に高くなります。これには NVME ソリッド ステート ドライブも含まれており、zkSnark の動作が高速化されます。上記では、加速実装の可能性について説明しましたが、リソース要件は依然として非常に高いことがわかりました。

将来、zkSnark アプリケーションを大規模に普及させたいのであれば、さまざまなレベルで最適化することが不可欠です。

4.3 ガス消費コスト

すべての zkRollup Layer2 は検証と保存のために zkProof をレイヤー 1 に渡す必要があることがわかりました。 ETHチェーンのリソースは非常に高価なため、広く普及すると、ETHに対して大量のガスを支払う必要があります。最終的にはユーザーがコストを負担することになり、技術開発の本来の目的に反することになります。

そのため、多くの zkp プロジェクトでは、データ検証レイヤーや、提出された zkProofs を圧縮するための再帰証明の使用を提案しており、これらはすべて Gas コストの削減を目的としています。

4.4 仮想マシンの指示が不足している

現在、ほとんどの zkvm プラットフォームはスマート コントラクト プログラミングに重点を置いています。より一般的なコンピューティング シナリオが必要な場合は、zkvm の基礎となる命令セットを完成させるために多くの作業を行う必要があります。たとえば、zkvm 仮想マシンの基盤となるレイヤーは、libc 命令、行列演算命令、およびその他のより複雑な計算命令をサポートします。

5. 結論

スマート コントラクト プラットフォームはより資産指向であるため、より多くの実際のビジネス シナリオを Web3 に接続したい場合は、ゼロ知識証明と分散コンピューティングを組み合わせることでチャンスが生まれます。当社が開発したゼロ知識証明は主流となり、もはやニッチな分野の技術ではなくなります。