Opside ZK-PoW V2.0: マルチチェーンおよびマルチロールアップの分散証明者ネットワーク

Opside ZK-PoW の紹介

Opside は、分散型 ZK-RaaS (ZK-Rollup as a Service) プラットフォームであり、ZKP (Zero-Knowledge Proof) マイニングの主要ネットワークです。 ZK-RaaS は、誰でも ZK-Rollups を生成できるワンクリック サービスを提供します。 Opside はユニバーサル ZK-Rollup 起動ベースを提供し、開発者がさまざまなタイプの ZK-Rollup をさまざまなベース チェーンに簡単にデプロイできるようにします。

• ベースチェーン: Ethereum/Opside チェーン/BNB チェーン/Polygon PoS、およびその他のパブリック チェーン。
• ZK-Rollup タイプ: zkSync、Polygon zkEVM、Scroll、StarkNet、および ZK-Rollup のその他のバリアント。

Opside の設計では、開発者はこれらの異なるベース チェーンに ZK ロールアップをデプロイできます。 ZK-Rollup テクノロジーが成熟するにつれて、将来的には数百、さらには数千の ZK-Rollup が存在する可能性があり、ZKP の計算能力に対する大きな需要が生じることになります。 Opside は、ZK-PoW メカニズムを利用してマイナーに ZKP の計算能力を提供するよう奨励し、ZK-Rollups のための完全なハードウェア インフラストラクチャを提供します。

ZK-PoW V2.0 アーキテクチャ

ZK-PoW V2.0 の全体的なアーキテクチャは、いくつかの主要なコンポーネントで構成されています。

1. ZK-PoW Cloud:これは、Opside が ZKP 計算のために提供するクラウド インフラストラクチャです。これは、イーサリアム、BNB チェーン、ポリゴン PoS、オプサイド チェーンを含む複数のチェーンにわたってデプロイされます。 ZK-PoW クラウドは、ZKP 計算タスクの調整と管理を担当します。

   
   

2. マイナー ノード:これらは、ZKP 計算を実行するために計算能力を提供するマイナーによって運営されるノードです。マイナーは、マイニング ハードウェア上で特殊なソフトウェアを実行することで、ZK-PoW ネットワークに参加できます。

   
   

3. ZKP タスク分散: ZK-PoW クラウドは、ZKP 計算タスクをマイナー ノードに分散します。公平性と効率性を確保するために、配布は分散型で行われます。 ZKP タスクには、さまざまな ZK ロールアップのゼロ知識証明の生成と検証が含まれます。

   
   

4. ZKP 計算:マイナー ノードは ZKP 計算タスクを受け取り、必要な計算を実行して必要な証明を生成します。これには、暗号化アルゴリズムの実行と複雑な計算の実行が含まれます。

   
   

5. 証明の送信と検証: ZKP の計算が完了すると、マイナー ノードは生成された証明を検証のために ZK-PoW クラウドに送信します。クラウド インフラストラクチャは証明の正確性を検証し、証明の有効性と完全性を保証します。

   
   

6. インセンティブのメカニズム:マイナーは、計算への貢献に対する報酬を獲得することで、ZK-PoW ネットワークに参加するよう奨励されます。報酬システムは、マイナーのモチベーションを高め、ネットワークのセキュリティと安定性を維持するように設計されています。

全体として、ZK-PoW V2.0 はマイナーの計算リソースの能力とクラウド インフラストラクチャを組み合わせて、幅広い ZK ロールアップに対して効率的でスケーラブルな ZKP 計算を提供します。

Aggregator は、ZK-PoW V2.0 システムの Prover の重要なコンポーネントです。 ZKP 証明タスクの配布、タスク結果 (ZKP 証明) の受信、証明の管理、報酬を獲得するためのベース チェーンへの送信を担当します。新しいバージョンのアグリゲーターは、その機能に基づいて、Proof Generator、Proof Manager、Proof Sender の 3 つのサブモジュールに分かれています。

• Proof Generator モジュールは、証明タスクを証明者 (PoW マイナー) に割り当て、タスクの結果 (ZKP 証明) を受け取り、ZKP 証明を DB データベースに保存する責任を負います。

• プルーフ マネージャーは、完成した ZKP プルーフを管理し、プルーフ センダー モジュールのタスクとしてオンチェーン送信の準備ができたプルーフをパッケージ化する責任を負います。

• Proof Sender モジュールは、ベース チェーン上にデプロイされた zkEVM コントラクトに ZKP プルーフを送信することで、ZKP プルーフのオンチェーン送信を処理します。

  
  

以下にこれら 3 つのモジュールの紹介を示します。

プルーフジェネレータ

ロールアップ チェーンは、特定の数のトランザクションを 1 つのバッチに集約し、複数のバッチ (トランザクション頻度などの要因に基づいて) を 1 つのシーケンスに結合します。その後、シーケンスは Base Chain に送信され、それが各オンチェーン操作のデータ送信の単位になります。各シーケンスは 1 つ以上のバッチで構成され、ZKP プルーフにより、送信されたシーケンスの有効性が検証されます。したがって、バッチは証明タスクの最小単位です。シーケンスに含まれるバッチの数に応じて、必要な証明タスクは次のように異なります。

• バッチ数が 1 の場合、校正プロセスには BatchProofTask に続いて FinalProofTask が含まれ、タスクは順番に完了します。

• シーケンスに複数のバッチが含まれている場合、証明プロセスには複数の BatchProofTask、AggregatorProofTask、および FinalProofTask が含まれ、タスクは順番に完了します。

  
  

プルーフ生成の効率を最大化し、PoW マイナーのマイニング報酬を増やすために、プルーフを同時に生成することを目指しています。これは次の 2 つの側面で実現されます。

• 文脈依存性や状態依存性がないため、さまざまなシーケンスのプルーフ生成を同時に行うことができます。

• 同じシーケンス内で、複数の BatchProofTask を同時に実行できます。

  
  

このアプローチは証明者の計算リソースをより効率的に利用し、より効率的な証明生成をもたらします。

プルーフマネージャー

このモジュールは主に、ZKP 証明の管理とそのオンチェーン検証の制御を担当します。これは 3 つの主要モジュールで構成されます。

• submitPendingProof : このモジュールは、アグリゲーターの開始時に 1 回だけ実行されます。その目的は、以前のアグリゲーター サービスからの未完成の ZKP プルーフの送信を完了することです。これは、proofHash が送信されたが、他のマイナーがすでに証明を送信している状況を処理します。 ProofHash の詳細については、Proof Sender モジュールを参照してください。
• tryFetchProofToSend : このモジュールはコルーチンとして実行され、最新に生成された ZKP プルーフを、対応する未検証のシーケンスとともにプルーフ センダーのキャッシュに追加し、オンチェーンの送信を待ちます。
• processResend : このモジュールはコルーチンとして実行され、指定された時間枠内で正常に検証されなかったシーケンスを再送信することを目的としています。その目的は、検証時間を超えたシーケンスがオンチェーン処理のために再送信されるようにすることです。

送信者証明

Opside は、証明者の分散化を実現するために 2 段階の ZKP 提出アルゴリズムを提案しました。このアルゴリズムは、ZKP のフロントランニング攻撃を防ぎ、より多くのマイナーが報酬を受け取ることができるようにすることで、より多くのマイナーが参加し、安定した継続的な ZKP 計算能力を提供することを奨励します。

• ステップ 1 : 特定のシーケンスの PoW 証明 (証明と呼ばれる) を生成するとき、証明者はまず「証明 / アドレス」のハッシュを計算し、それをコントラクトに送信します。そのシーケンスに対して以前にproofHashが送信されていない場合は、proofHash送信時間ウィンドウT1が開きます。マイナーは T1 ブロック内でシーケンスを提出する資格があり、証明は T1 ブロック後にのみ提出できます。

  
  

• ステップ 2 : T1 ブロックの後、T2 ブロックに対してプルーフ提出ウィンドウが開きます。提出されたプルーフが T2 ブロック内の検証に合格しない場合、以前にproofHashを提出したすべてのマイナーがペナルティを受けます。 ProofHash が T1 時間枠内で正常に送信されたが、証明が T2 時間枠内で正常に送信できず、他のマイナーが T2 時間枠内で証明を正常に送信した場合でも、証明者は引き続きその証明を送信できます。他のシナリオでは、2 段階の送信プロセスが再開されます。

次の図は、Proof Sender が 3 つのスレッドセーフで優先順位でソートされたキャッシュを使用して 2 段階の送信を実装する方法を示しています。これらのキャッシュはシーケンスの開始高さに基づいて並べ替えられ、これらのキャッシュから要素が取得されるたびに、その要素が最も低いシーケンスの高さに対応することが保証されます。さらに、これらのキャッシュ内の要素は重複排除されます。対応するシーケンスの高さが低いほど、処理の優先順位が高くなります。

• FinalProofMsgCache: ZKP プルーフの完了を示す、Proof Manager によって送信された FinalProof メッセージを保存します。
• monitPHTxCache: 監視するproofHashトランザクションを保存します。
• ProofHashCache: オンチェーン送信用の証明メッセージを保存します。

Proof Sender モジュールが起動された後、3 つのコルーチンが開始され、3 つのキャッシュからのデータが消費されます。簡略化されたプロセスは次のとおりです。

1. コルーチン 1 は、finalProofMsgCache からの FinalProof メッセージを消費し、proofHash を計算し、オンチェーン送信の条件 (T1 ウィンドウ内) を満たしている場合は、proofHash をチェーンに送信し、proofHash トランザクションを monitPHTxCache に追加します。

2. コルーチン 2 は、monitPHTxCache からのproofHash トランザクション メッセージを消費します。 ProofHash が T2 ウィンドウ内のオンチェーン送信の条件を満たしている場合、ProofHash は証明メッセージを構築し、ProofHashCache に保存します。

3. コルーチン 3 は、ProofHashCache からの証明メッセージを消費し、証明をチェーンに送信します。

   
   

前のモジュールと比較して、この構造はより明確であり、リソースのオーバーヘッドが節約されます。

まとめ

バージョン1.0との比較

• バージョン 2.0 では、元のサービスが 3 つのサブモジュールに分割され、それぞれがプルーフ生成、プルーフ管理、プルーフ送信を担当するため、構造がより明確になり、結合が低くなり、堅牢性が強化されます。
• プルーフ生成モジュールである Proof Generator には、古いバージョンと比較して startBatch パラメーターが追加されており、新しいマイナーがマイニングの進行状況に追いつきやすくなっています。
• 校正刷り管理モジュール Proof Manager が旧バージョンに比べて改良されました。マイナーサービスの再開やその他の理由で証明の提出が失敗した場合には、速やかに証明を再送信し、マイナーの利益を確保します。再送信メカニズムは、校正刷りの提出が失敗したケースに対処するだけでなく、校正刷りの提出が失敗または提出されなかったすべてのケースも処理し、ロールアップ チェーンのセキュリティを確保します。
• プルーフ送信モジュールである Proof Sender は、3 つのスレッドセーフ優先度キャッシュを使用して 2 段階のトランザクション送信を実装します。以前のバージョンと比較してグローバル ロックの使用が削減され、より低い高さのプルーフが迅速に送信されるようになり、マイナーの利益が保護されます。さらに、プログラム実行中のスレッド数とリソース消費が削減され、全体的なサービス フローがより明確になります。

ストレステストの結果:

• バージョン 2.0 では、それぞれ 64 コアを備えた 10 台のマシンを使用して、566 のバッチ プルーフが 7 時間 38 分 40 秒で完了し、1 プルーフあたりの平均時間は 48.62 秒でした。マルチマイナー シナリオでは、バージョン 1.0 と比較して、バージョン 2.0 の zk 証明生成の効率は全体で 50% 向上しました。

  
  

結論として、Opside ZK-PoW V2.0 は、ZKP 計算に参加する複数のマイナーのプロセスを最適化し、ハードウェア使用率を改善し、サービスの可用性を強化し、よりマイナーに優しいものにしました。重要なのは、マルチマイナーのシナリオでは、ZKP の計算時間が 1 分未満に短縮され、ZK ロールアップ トランザクションの確認時間が大幅に短縮されたことです。