Opside ZK-PoW V2.0: マルチチェーンおよびマルチロールアップ ZKP マイニングをサポート

1. オプサイド ZK-PoW の導入

Opside は、分散型 ZK-RaaS (ZK-Rollup as a Service) プラットフォームと業界をリードする ZKP (Zero-Knowledge Proof) マイニング ネットワークです。 ZK-RaaS (ZK-Rollup as a Service) は、誰でもワンクリックで ZK-Rollup を生成できるサービスを提供します。 Opside は一般的な ZK-Rollup 起動ベースを提供しており、これを通じて開発者はさまざまなタイプの ZK-Rollup をさまざまなベース チェーンに簡単にデプロイできます。

• Ethereum/Opside チェーン/BNB チェーン/Polygon PoS およびその他のパブリック チェーンを含むベース チェーン。

• ZK ロールアップ タイプ (zkSync、Polygon zkEVM、Scroll、StarkNet などの zkEVM、その他の種類の ZK ロールアップを含む)。

Opside ZK-PoW Cloud は、イーサリアム、BNB チェーン、ポリゴン PoS、およびオプサイド チェーン自体を含むがこれらに限定されない複数のチェーン上にデプロイされます。 Opside の設計では、開発者は上記のさまざまなベース チェーンに ZK ロールアップをデプロイできます。 ZK-Rollup テクノロジーが徐々に成熟すると、将来的には何百もの ZK-Rollup が誕生する可能性があり、ZKP のコンピューティング能力に対する膨大な需要がもたらされるでしょう。 Opside は、ZK-PoW メカニズムを使用してマイナーに ZKP コンピューティング能力を提供するように促し、ZK-Rollup に完全なハードウェア機能を提供します。

2. ZK-PoW V 2.0の全体的なアーキテクチャ

ZK-PoW V 2.0 の全体的なアーキテクチャには、いくつかの重要なコンポーネントが含まれています。

• ZK-PoW Cloud: これは、Opside が ZKP 計算のために提供するクラウド インフラストラクチャです。イーサリアム、BNB チェーン、ポリゴン PoS、オプサイド チェーンなどの複数のチェーンにデプロイされます。 ZK-PoW Cloud は、ZKP コンピューティング タスクの調整と管理を担当します。

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

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

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

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

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

一般に、ZK-PoW V 2.0 はマイナーのコンピューティング リソースをクラウド インフラストラクチャと組み合わせて、さまざまな ZK-Rollup に効率的でスケーラブルな ZKP コンピューティング パワーを提供します。

アグリゲーターは Prover の重要なコンポーネント モジュールであり、ZKP 証明タスクの配布とタスク結果 (つまり ZKP 証明) の受信、ZKP 証明の管理、ZKP 証明を Base Chain に送信して報酬を取得する責任を負います。したがって、Aggregator の新しいバージョンは、機能に基づいて 3 つのサブモジュール、つまり Proof Generator、Proof Manager、Proof Sender に分割されています。

上図の点線のボックス内の Proof Generator モジュールは、証明タスクを証明者 (PoW マイニング マシン) に発行し、タスクの結果 (ZKP 証明) を受け入れ、ZKP 証明を DB データベースに保存する役割を果たします。プルーフ マネージャーは、ZKP プルーフの完了を管理し、アップロードされる ZKP プルーフを送信タスクにパッケージ化し、それをモジュールプルーフ センダーに引き渡す責任を負います。モジュール Proof Sender は、ZKP プルーフ チェーンを完成させます。つまり、ベース チェーンにデプロイされた zkevm コントラクトにプルーフを送信します。

3 つのモジュールについては以下で説明します。

Proof generator

ロールアップ チェーンは、特定の数のトランザクションをバッチにパックし、次に複数のバッチ (トランザクションの頻度などの複数の要素に従って) をシーケンスにパックして、それをベース チェーンに送信します。そのため、データが更新されるたびに次のように言えます。チェーン上 単位はシーケンスです。各シーケンスには複数のバッチが含まれており、ZKP 証明は提出されたシーケンスの正当性を証明するため、バッチが証明タスクの最小単位になります。

シーケンスに含まれるバッチに応じて、完了する証明タスクも次のように異なります。

• バッチの数は 1 に等しく、証明プロセス BatchProofTask ----> FinalProofTask は、BatchProofTask 証明タスクと FinalProofTask 証明タスクを順番に完了する必要があります。

• シーケンスには 1 より大きいバッチ番号が含まれており、証明プロセスには複数の BatchProofTask ---->AggregatorproofTask ---> FinalProofTask があります。複数の BatchProofTask、AggregatorproofTask、および FinalProofTask 証明タスクは、順番に完了する必要があります。

プルーフ生成の効率を可能な限り向上させ、PoW マイナーの収入を増やすために、私たちはプルーフを可能な限り並行して生成します。具体的には次の 2 つの側面です。

• 各シーケンスは、生成にコンテキストや状態の依存関係がなく、同時に実行できることを証明しています。

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

このようにして、証明者の計算能力リソースをより有効に活用できるため、証明をより効率的に生成できます。

Proof manager

このモジュールは主に、ZKP 証明書の管理と ZKP 証明書のチェーン検証の制御を担当します。主に 3 つのモジュールに分かれています

• submitPendingProof: このモジュールは、最後のアグリゲーター サービスが停止する前に完了していなかった ZKP プルーフを送信する目的で、アグリゲーターが開始されるたびに 1 回だけ実行されます。ここでは、proofHash が送信され、他のマイナーが証明を送信するケースを示します。 ProofHash について、Proof の導入は Proof Sender を指します。

• tryFetchProofToSend: コルーチンの実行中に、生成された最新の ZKP プルーフと検証されていないプルーフに対応するシーケンスをプルーフ センダーのキャッシュに追加し、リンクを待ちます。

• processResend: コルーチン内で実行されます。目的は、時間枠を超えて検証されなかったシーケンスを再送信することです。

Proof sender

Opside証明者の分散化を実現するために、ZKP 2 段階提出アルゴリズムが提案されています。このアルゴリズムは、ZKP のフロントランニング攻撃を防ぐだけでなく、より多くのマイナーが報酬を獲得できるようにすることで、より多くのマイナーがオンラインになることを奨励し、安定した継続的な ZKP コンピューティング能力を提供します。

• ステップ 1: 特定のシーケンスでプルーフとして記録された PoW プルーフを生成するには、最初にハッシュ (プルーフ / アドレス) を計算し、それをプルーフ ハッシュとして記録し、コントラクトに送信します。シーケンスが以前にプルーフ ハッシュを送信したことがない場合は、プルーフ ハッシュを開きます提出時間枠 T 1。次の T 1 ブロックのマイナーはシーケンスを提出する資格があり、証明は T 1 ブロック後にのみ提出できます。

• ステップ 2: プルーフを送信する T 1 ブロックの後、プルーフの送信をオンにし、送信を T 2 ブロック以内に制限します。 T 2 ブロックの後、証明を提出したすべてのマイナーが検証に合格しなかった場合、以前に ProofHash を提出したすべてのマイナーが罰せられます。 ProofHash が T 1 時間枠で正常に送信できても、証明が T 2 時間枠で正常に送信できず、他のマイナーが T 2 時間枠で証明を正常に送信した場合でも、引き続き証明を送信できます。上記のシナリオに加えて、2 段階の送信プロセスを再度実行してください。

以下の図に示すように、Proof Sender は 3 つのスレッドセーフで優先順位でソートされたキャッシュに基づいて 2 段階の送信を実装します。これら 3 つのキャッシュはシーケンスの初期の高さに基づいてソートされ、シーケンスの高さがシーケンスから取得された要素に対応することが保証されます。これら 3 つのキャッシュは毎回最低であり、これら 3 つのキャッシュ内の要素は重複排除されます。対応するシーケンスの高さが低いほど、優先度は高くなります。

• FinalProofMsgCahce: ZKP 証明を完了するために Proof Manager によって送信された FinalProof メッセージを保存します。

• monitPHTxCache:proofHash を監視するトランザクションを保存します。

• ProofHashCache: 証明用の証明メッセージをオンチェーンに保存します。

以下に示すように:

Proof Sender モジュールが開始されると、3 つのコルーチンが開始され、3 つのキャッシュされたデータがそれぞれ消費されます。

簡単なプロセスは次のとおりです。

1. コルーチン 1 は、finalProofMsgCahce の FinalProof メッセージを消費し、proofHash を計算する責任を負います。オンチェーン条件 (T 1 条件内) を満たしている場合、proofHash をチェーンに配置し、proofHash トランザクションを monitPHTxCache に配置します。

2. コルーチン 2 は、monitPHTxCache の ProofHash トランザクション メッセージを消費します。T 2 時間枠内で証明オンチェーン条件が満たされた場合、証明メッセージを構築し、ProofHashCache に保存します。

3. コルーチン 3 は証明メッセージを消費し、証明がチェーンにアップロードされます。

古いモジュールと比較して、構造がより明確になり、リソースのオーバーヘッドが節約されます。

3. まとめ

バージョン1.0との比較

• V 2.0 では、元のサービスが 3 つのサブモジュールに分割されています。3 つのモジュールはそれぞれ、証明書の生成、証明書管理、および証明書のチェーンを担当します。構造はより明確です。3 つのモジュールは結合度が低く、堅牢性が優れています。

• 古いバージョンと比較して、Proof Generator には startBatch パラメーターが追加され、新しいマイナーがより早くマイニングの進行状況に追いつくことが容易になります。

• プルーフ管理モジュール Proof Manager は、古いバージョンよりも優れており、改善されています。マイナーがサービスを再起動するか、その他の理由でプルーフが送信されない、または送信が失敗した場合、マイナーの利益を確保するために、プルーフはできるだけ早く再送信されます。同時に、再送信メカニズムはプルーフの送信が失敗した場合だけでなく、すべてのプルーフの送信が失敗した場合、または送信されなかった場合にも、ロールアップ チェーンのセキュリティを確保するために時間枠が再開されます。

• プルーフ送信モジュール Proof Sender は、3 つのスレッドセーフ優先度キャッシュに基づいて 2 段階のトランザクション送信を実装します。これにより、以前のバージョンと比較してグローバル ロックの使用が削減され、低レベルのプルーフをできるだけ早く送信できるようになり、鉱山労働者の利益。同時に、サービスプロセス全体がより明確になり、スレッドの数が減り、プログラム実行時のリソース消費が削減されます。

圧力テストの結果:

• バージョン 2.0 では、10 台の 64 コア マシンを使用して 566 のバッチ プルーフを完了します。これには 7 時間 38 分 40 秒かかり、プルーフを完了するのに平均 48.62 秒かかります。マルチマイナー シナリオでは、V 1.0 と比較して、V 2.0 の zk プルーフ生成効率は全体で 50% 増加しました。

つまり、Opside ZK-PoW V 2.0 は、ZKP 計算に参加するマルチマイナーのプロセスを最適化し、ハードウェア使用率を向上させ、サービスの可用性を向上させ、マイナーにとってよりフレンドリーです。さらに重要なのは、マルチマイナーのシナリオでは、ZKP の計算が 1 分未満に短縮され、ZK-Rollup の確認時間が大幅に短縮されることです。