FOX のインセンティブ モデルは比較的新しいものです。まず、分散化と効率性の問題のバランスをとるために、トランザクションのソートと実行を担当するシーケンサー ノードと、トランザクション実行の正しさの証明の生成と集約を担当するフォルダー ノードにノードの役割を分割します。 FOX のフォルダー ノードは分散モデルを採用しており、どの FOX マイナーもプルーフ ジェネレーターとしてネットワークにアクセスできることを意味し、より多くのノードの参加を促すために、レイヤー 1 コントラクトに正しいプルーフを正常に送信したフォルダーはトークン報酬を得ることができます。同時に、計算能力の無駄を避けるために、最初の校正刷り提出者だけが報酬を受け取ることができるのではなく、最初の校正刷り提出者が正常に提出した後の時間枠と数量枠内で報酬を受け取ることができることを指摘します(ここでの特定のパラメータは状況に応じて異なります)。システム条件)、すべての正しい認証者に報酬が与えられます。
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
レイヤー 2 のインセンティブ メカニズムについて語る: FOX におけるフィアット シャミア ヒューリスティックのもう 1 つの素晴らしい使用法
序文
レイヤ 1 は分散システムであるため、合意形成に多大な通信コストが必要であり、大量の計算により高価なガスも消費します。したがって、Layer1 の拡張として、Layer2 を設計すると、Layer1 の効率を効果的に向上させることができます。しかし、この観点から見ると、レイヤー 2 の設計は依然としてレイヤー 1 と同じ大きな問題、つまり分散化の程度と効率性のバランスをどのように取るかという問題に直面しています。
zkRollup は、非常に有望なレイヤー 2 拡張ソリューションであり、計算をチェーンから移動し、ゼロ知識証明をレイヤー 1 チェーンに提供することによって実現されます。 zkRollupを実現するソリューションでは、FOXシステムが現在主流の構造を採用しており、主にSequencerとFolderの2種類のノードが存在します。簡単に言うと、Sequencer はユーザーが送信したトランザクションを並べ替えてパッケージ化し、Layer2 チェーン上のステータスを更新する役割を担い、Folder は Sequencer によってパッケージ化されたトランザクションのプルーフを生成し、Layer1 に送信する役割を担います。
興味深い問題は、レイヤー 2 ノードを分散化する必要があるかどうか、分散化する場合、分散化を確保するためのインセンティブをどのように設計するかということです。 Layer1 の低効率の本質は、分散化を実現するために各ノードが大量の計算と通信を行う必要があることにあると考えられるからです。ただし、計算処理を分離するためにレイヤ2システムが使用されており、この部分でもレイヤ1と完全に同等の分散モデルを使用すると、同様の理由でレイヤ2の輻輳が発生するため、トレードオフが必要となります。ここで作られます。
インセンティブ メカニズムの設計は、レイヤ 2 ノードがインセンティブ料金を取得する方法を調整し、レイヤ 2 ノードに支払われる料金のバランスをとることによって、ノードがレイヤ 2 システム メンテナンスに参加することを奨励することです。本質的に、レイヤー2ノードが受け取るインセンティブ料金の源泉はイーサリアムと同じで、トランザクションを送信するユーザーが支払うガス料金から来ます。この記事では、FOX システムにおいて、FOX ノードが取引手数料を徴収するためにシステムにどのように参加するのか、およびその理由について説明します。
ガスの役割
まず、イーサリアム システムにおけるガス料金の役割を確認してみましょう。 Layer1 のコンピューティング リソースは限られています。ユーザーがトランザクションを送信するときに、トランザクションのガス料金を指定します。ガス料金は基本的にトランザクションの実行操作の複雑さに関連します。これに基づいて、ユーザーは、ガス料金が高いほど、より高い優先度のトランザクション実装を取得できます。マイナーのインセンティブは、パッケージ化されたブロックのガス料金の合計から得られます。さらに、Gas 料金メカニズムは、悪意のあるコントラクト (無限ループなど) を効果的に防止し、ブロック サイズを制限することもできるため、ある程度のセキュリティが保証されます。
したがって、Gas 料金の合理的な使用は、本質的に、チェーン上のコンピューティング リソースの合理的なスケジューリングと割り当てであり、プロジェクト パーティ、マイナー、ユーザー間のマルチパーティ ゲームでもあることがわかります。インセンティブの仕組みと料金の使用と分配を適切に設計することは、システムの運用にとって重要です。
トランザクションのオンチェーンプロセス
ユーザーが FOX システムのトランザクション プールにトランザクションを送信すると、FOX ノードを動機付けるために料金が追加され、その後システムのシーケンサー ノードがトランザクション プールからトランザクションを取得してパッケージ化および並べ替えを行います。パッケージ化された各トランザクションは、はレイヤ 2 ブロックを構成し、シーケンサはトランザクション計算を実行し、計算結果をレイヤ 1 FOX コントラクトに送信する必要があります。また、シーケンサは、データの可用性を確保するためにトランザクション データを ZK-Ringer に保存する必要があります。その後、Sequencer のソート結果と計算結果が Folder ノードに送信され、Folder は証明 (証明の集計部分を含む) を正しく計算し、Layer1 コントラクトに渡します。この処理では、Sequencerによるトランザクションの実行結果は、実行完了後にそのままLayer 2に更新され、実際にLayer 1でトランザクションが合意された時点のノードは、Folderの証明が検証された後とみなすことができます。
このプロセスでは、ユーザーが支払う初期手数料がいくつかの目的に適用されることがわかります。
※シーケンサーに支払う手数料 ※手数料はFolderにお支払いいただきます
この目的を達成するには、すべての関係者が参加するよう動機付けるための具体的なメカニズムを整理する必要があります。
FOX のインセンティブの仕組み
FOX のインセンティブ モデルは比較的新しいものです。まず、分散化と効率性の問題のバランスをとるために、トランザクションのソートと実行を担当するシーケンサー ノードと、トランザクション実行の正しさの証明の生成と集約を担当するフォルダー ノードにノードの役割を分割します。 FOX のフォルダー ノードは分散モデルを採用しており、どの FOX マイナーもプルーフ ジェネレーターとしてネットワークにアクセスできることを意味し、より多くのノードの参加を促すために、レイヤー 1 コントラクトに正しいプルーフを正常に送信したフォルダーはトークン報酬を得ることができます。同時に、計算能力の無駄を避けるために、最初の校正刷り提出者だけが報酬を受け取ることができるのではなく、最初の校正刷り提出者が正常に提出した後の時間枠と数量枠内で報酬を受け取ることができることを指摘します(ここでの特定のパラメータは状況に応じて異なります)。システム条件)、すべての正しい認証者に報酬が与えられます。
図 1: インセンティブ モデルのオリジナル バージョン
ただし、このメカニズムでは、悪意のあるフォルダーは非常に狡猾な攻撃を行うことになります。
Adv として示される悪意のあるフォルダーがプルーフの生成を完了すると、一方では検証のためにそのプルーフを Layer1 の Verifier コントラクトに送信し、他方ではいくつかのノード (またはフォルダーによって制御されているノード) と共謀します。計算された証明はこれらのノードに公開され、ノードは独自の計算を行わずに Adv によって計算された証明を直接送信することができ、報酬の一部を受け取ることもでき、このプロセス中に計算能力を支払うことはありません。言い換えれば、Adv はより少ない計算能力で複数の利点を得ることができ、たとえ正しい証明を生成したとしても他のノードが Adv をめぐって競合することを困難にします。
図2:悪意のあるフォルダの攻撃手法
この攻撃では、証明書の値が同じであるため、Verifier が各証明書がフォルダーによって独立して生成されたものであるかどうかを区別できないことが問題の原因です。この問題を回避するには、フォルダーによって送信される証明書にフォルダーの一意のアドレス情報を追加する必要があります。これにより、各フォルダーによって送信される証明書は、そのフォルダー自体でのみ独立して生成され、他のノードによって送信されることはできなくなります。
この情報を組み込む方法は、Fiat-Shamir ヒューリスティックを使用する非常に巧妙です (技術的な詳細については、FOX の以前の記事「インタラクティブな証明を非インタラクティブな証明に変換するには? Fiat-Shamir ヒューリスティック!」を参照してください)。証明を生成するプロセスに従って計算され、ステップの 1 つである証明者、つまり、フォルダーはハッシュ関数を通じてランダムなチャレンジ値を生成する必要があり、このハッシュの入力にフォルダーのアドレスを追加するだけで済みます。したがって、チャレンジ値とフォルダーはアドレスに対応しますが、フォルダーが予測および制御できない乱数であることに変わりはありません。
この方法の安全性を厳密に述べるには、暗号化における理論的に安全なランダム関数や識別不可能性などの概念を使用する必要がありますが、ここでは詳しく説明しません。簡単に言えば、ハッシュ関数自体の安全性と Fiat-Shamir ヒューリスティック構造の安全性により、ハッシュのプリイメージとして固定値を追加しても出力の予測不可能性は損なわれないと考えることができます。オリジナルの zkp アルゴリズムのセキュリティは引き続き保証されます。
このようにして、各フォルダーは独立してプルーフを生成する必要があり、他のノードの結果を直接使用することはできないため、目的は達成されます。
図 3: 修正されたインセンティブ スキーマ
### 結論
本稿では、ノード料金の重要な役割の観点から、料金の関係とノードがシステム保守に参加するよう動機づける方法を紹介するとともに、優れたインセンティブメカニズムがシステムのセキュリティを効果的に維持できることを指摘します。これに基づいて、FOX が採用しているレイヤー 2 フォルダーのインセンティブ メカニズムについて詳しく説明し、このアプローチの合理性と、これを達成するために Fiat-Shamir ヒューリスティックを上手に使用する方法を説明しました。
参考文献
「詳細|反復と競争 - イーサリアムのレイヤー2拡張への道」国盛ブロックチェーン研究所