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 の全体的なアーキテクチャは、いくつかの主要なコンポーネントで構成されています。   これは、Opside が ZKP 計算のために提供するクラウド インフラストラクチャです。これは、イーサリアム、BNB チェーン、ポリゴン PoS、オプサイド チェーンを含む複数のチェーンにわたってデプロイされます。 ZK-PoW クラウドは、ZKP 計算タスクの調整と管理を担当します。 ZK-PoW Cloud: これらは、ZKP 計算を実行するために計算能力を提供するマイナーによって運営されるノードです。マイナーは、マイニング ハードウェア上で特殊なソフトウェアを実行することで、ZK-PoW ネットワークに参加できます。 マイナー ノード:    ZK-PoW クラウドは、ZKP 計算タスクをマイナー ノードに分散します。公平性と効率性を確保するために、配布は分散型で行われます。 ZKP タスクには、さまざまな ZK ロールアップのゼロ知識証明の生成と検証が含まれます。 ZKP タスク分散:   マイナー ノードは ZKP 計算タスクを受け取り、必要な計算を実行して必要な証明を生成します。これには、暗号化アルゴリズムの実行と複雑な計算の実行が含まれます。 ZKP 計算:  ZKP の計算が完了すると、マイナー ノードは生成された証明を検証のために ZK-PoW クラウドに送信します。クラウド インフラストラクチャは証明の正確性を検証し、証明の有効性と完全性を保証します。 証明の送信と検証: マイナーは、計算への貢献に対する報酬を獲得することで、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 つの主要モジュールで構成されます。    : このモジュールは、アグリゲーターの開始時に 1 回だけ実行されます。その目的は、以前のアグリゲーター サービスからの未完成の ZKP プルーフの送信を完了することです。これは、proofHash が送信されたが、他のマイナーがすでに証明を送信している状況を処理します。 ProofHash の詳細については、Proof Sender モジュールを参照してください。 submitPendingProof    : このモジュールはコルーチンとして実行され、最新に生成された ZKP プルーフを、対応する未検証のシーケンスとともにプルーフ センダーのキャッシュに追加し、オンチェーンの送信を待ちます。 tryFetchProofToSend    : このモジュールはコルーチンとして実行され、指定された時間枠内で正常に検証されなかったシーケンスを再送信することを目的としています。その目的は、検証時間を超えたシーケンスがオンチェーン処理のために再送信されるようにすることです。 processResend 送信者証明 証明者の分散化を実現するために 2 段階の ZKP 提出アルゴリズムを提案しました。このアルゴリズムは、ZKP のフロントランニング攻撃を防ぎ、より多くのマイナーが報酬を受け取ることができるようにすることで、より多くのマイナーが参加し、安定した継続的な ZKP 計算能力を提供することを奨励します。 Opside は、  : 特定のシーケンスの PoW 証明 (証明と呼ばれる) を生成するとき、証明者はまず「証明 / アドレス」のハッシュを計算し、それをコントラクトに送信します。そのシーケンスに対して以前にproofHashが送信されていない場合は、proofHash送信時間ウィンドウT1が開きます。マイナーは T1 ブロック内でシーケンスを提出する資格があり、証明は T1 ブロック後にのみ提出できます。 ステップ 1  : T1 ブロックの後、T2 ブロックに対してプルーフ提出ウィンドウが開きます。提出されたプルーフが T2 ブロック内の検証に合格しない場合、以前にproofHashを提出したすべてのマイナーがペナルティを受けます。 ProofHash が T1 時間枠内で正常に送信されたが、証明が T2 時間枠内で正常に送信できず、他のマイナーが T2 時間枠内で証明を正常に送信した場合でも、証明者は引き続きその証明を送信できます。他のシナリオでは、2 段階の送信プロセスが再開されます。 ステップ 2 次の図は、Proof Sender が 3 つのスレッドセーフで優先順位でソートされたキャッシュを使用して 2 段階の送信を実装する方法を示しています。これらのキャッシュはシーケンスの開始高さに基づいて並べ替えられ、これらのキャッシュから要素が取得されるたびに、その要素が最も低いシーケンスの高さに対応することが保証されます。さらに、これらのキャッシュ内の要素は重複排除されます。対応するシーケンスの高さが低いほど、処理の優先順位が高くなります。  FinalProofMsgCache: ZKP プルーフの完了を示す、Proof Manager によって送信された FinalProof メッセージを保存します。  monitPHTxCache: 監視するproofHashトランザクションを保存します。  ProofHashCache: オンチェーン送信用の証明メッセージを保存します。   Proof Sender モジュールが起動された後、3 つのコルーチンが開始され、3 つのキャッシュからのデータが消費されます。簡略化されたプロセスは次のとおりです。 コルーチン 1 は、finalProofMsgCache からの FinalProof メッセージを消費し、proofHash を計算し、オンチェーン送信の条件 (T1 ウィンドウ内) を満たしている場合は、proofHash をチェーンに送信し、proofHash トランザクションを monitPHTxCache に追加します。 コルーチン 2 は、monitPHTxCache からのproofHash トランザクション メッセージを消費します。 ProofHash が T2 ウィンドウ内のオンチェーン送信の条件を満たしている場合、ProofHash は証明メッセージを構築し、ProofHashCache に保存します。 コルーチン 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 ロールアップ トランザクションの確認時間が大幅に短縮されたことです。

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

このオーディオは、ストーリーの元の言語で制作されています。

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

About Author

コメント

ラベル

この記事は

Related Stories

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

フロキのヴァルハラがインドのスリランカツアーのアソシエイトスポンサーに加わる

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

フロキのヴァルハラがインドのスリランカツアーのアソシエイトスポンサーに加わる

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps