これまでのところ、通貨サークル/ブロックチェーン業界における福祉神話は続いており、「富の創造」の次の重要な領域は「ゲームトラック」に焦点を当てています。 XAI プロジェクトではオデッセイのイベントを開催しています。ご興味がございましたら、広場に掲載されている私の記事「XAI ゲーム パブリック チェーン オデッセイ イベント ゼロコスト初心者ガイド」にご参加ください。
この記事では、XAIゲームパブリックチェーンのSentryノードについて詳しく解説していきます！この記事は比較的専門的な内容になっているため、お金を稼ぎたい場合は注意深く読む必要があります。なぜなら、自分自身で「ロジック」を理解し、認知力を高めてこそ、お金を稼ぐチャンスが得られるからです！
Sentry ノードについて直接知りたい場合は、後で読まずに最初の部分を直接読んでください。論理的な閉ループが必要な場合は、2 番目、3 番目、および 4 番目の部分を読む必要があります。
私が強調したいのは、Xai が Offchain Labs から直接技術サポートを受けているということです。この種のサポートは他の Orbit チェーンでは考えられません。これは、Arbitrum エコシステム内における Xai の戦略的ゲーム プランの重要な要素です。
パート 1: セントリー ノードの説明
Sentry ノードは、Xai ロールアップ プロトコルを監視する観測ノードであり、不良ブロックが提案された場合は、他のノードが介入できるように (オペレーターが選択する手段によって) 警告を鳴らします。センチネル ノードの目的は、検証者のジレンマを解決することです (検証者のジレンマの詳細については、パート IV を参照してください)。
ここをクリックしてプロモーションビデオをご覧ください:
Xai ノードを実行して、ワンクリックで Xai トークンを取得しましょう!
Sentinel ノードは、コミュニティ メンバーのラップトップ、デスクトップ、さらにはクラウド インスタンス上でも実行できます。ノードが実行されている限り、ノード オペレーターがネットワークから esXai トークンで報酬を受け取るかどうかを決定する確率的アルゴリズムが存在します。 Xai をステーキングすることで、アルゴリズムの確率が高まります。 esXai についてご存知ない方は、広場に関する私の記事「XAI プロジェクトの「トークンエコノミー」の解釈」にご参加ください。
1.センチネルノードの動作原理
アテンション チャレンジ v2 プロトコルには、Xai チェーン、親チェーン (Arbitrum One)、信頼できるチャレンジャー、Xai センチネルとそのライセンス キー、審判 (審判) 契約を含む複数の参加者が関与します。挑戦者は BLS 鍵ペアを作成し、公開鍵を審判契約に登録し、Arbitrum One 上の Xai ロールアップ プロトコルでバリデーターによって作成されたクレームに署名します。これらの署名は審判契約によって検証され、クレームに関連付けられたチャレンジとして記録されます。
Xai Sentinel は、Sentinel ライセンス キーを購入することで審判契約に登録し、クレームに関する声明を公開する資格を得ることができます。これらは、発行ステートメントの後継となる正しいステートメントのステート ルートを取得します。一定の条件が満たされた場合、審判契約を発動して声明文を発行します。フォローアップ声明が作成および確認され、Sentinel が正しい声明を発行した場合、Sentinel は審判契約に連絡して償還トランザクションを発行します。審判はセンチネルに報酬を支払う前にいくつかの条件を確認します。
このプロトコルにより、各クレームは、その先行クレームが作成されたときに存在していた受信トレイ メッセージを完全に消費する必要があります。これは、クレームが作成されると、その後の正しいクレームの状態ルートが完全に決定され、どのノードでも計算できることを意味します。これにより、各センチネルが正しい次の状態ルートを決定するようになります。センチネルの報酬は、センチネルのステート許可 ID、後続ステート ルート、および後続ステート ルートが完全に決定されるまで判明しないチャレンジ値によって決定されます。
2. 誰がノードを実行できますか?
ソフトウェアをダウンロードし、インストールして実行するだけで、誰でも Sentinel を操作できます。ただし、トークン報酬を受け取るには、少なくとも 1 つの Sentinel ライセンス キーを購入する必要があります。
購入者は次のことを確認するために KYC チェックに合格する必要があります。
米国ではありません
米国の OFAC 制裁の対象ではありません (OFAC は米国の制裁リストに反映されています)
実行されていない、またはガス料金 (GAS) を支払うための適切な資金がない Sentinel ノードは、ライセンス キーがあっても報酬を獲得できません。したがって、通信事業者は、ノードが資金を提供され、オンラインで稼働していることを確認する必要があります。
3.審判（審判）契約
Referee は、事前定義されたルールへの準拠を強制し、送信元を検証し、システム内の勝者に報酬を分配するように設計されたスマート コントラクトです。審判スマート コントラクトは、Xai エコシステムの重要なコンポーネントであり、ネットワーク内のセンチネル ノードによって行われたクレームの管理と検証を担当します。契約にはいくつかの重要な機能があります。
3.1 声明の提出
審判契約により、センチネルノードはチャレンジに対してクレームを提出することができます。この機能は、Sentinel ライセンス キーの所有者、またはこの契約で承認されたアドレスの所有者のみが呼び出すことができます。この関数は、チャレンジがまだ提出可能かどうか、およびこのチャレンジに対して NodeLicense がすでに提出されているかどうかを確認します。
3.2 報酬を受け取る
この契約には、ユーザーが請求が成功した場合に報酬を請求できる機能が含まれています。この関数は、チャレンジの提出が終了したかどうかを確認し、ノード キーの所有者が KYC を完了したかどうかを確認します。これらの条件が満たされ、請求が支払いの対象となる場合、報酬はユーザーに送信されます。
3.3 請求ハッシュを作成し、支払いを確認します。
コントラクトには、センチネル許可 ID、チャレンジ ID、チャレンジ内のChallengerSignedHash、およびその後の状態ルートのハッシュを作成する関数があります。次に、ハッシュが特定のしきい値を下回っているかどうかを確認します。しきい値は、作成された Sentinel ライセンスの総数に基づいて計算されます。ハッシュがしきい値を下回っている場合、請求は支払いの対象となります。
審判契約は、主張を検証し成功したものに報酬を与えることによって Xai ネットワークの完全性を保証し、それによってセンチネル ノードがネットワークを正確かつ熱心に監視するよう奨励します。
4.チャレンジャーコンポーネント
チャレンジャーは Xai エコシステム内で信頼できる存在です。 BLS キー ペアを作成し、公開キーを参照コントラクトに登録します。バリデーターが Xai ロールアップ プロトコルでクレームを作成すると、挑戦者は秘密キーを使用してクレームに署名し、その署名をレフェリーに提出します。レフェリーは署名を検証し、ステートメントに関連付けられたチャレンジとして署名を記録します。このプロセスにより、Xai ロールアップ プロトコルで作成されたクレームの整合性が保証されます。
5. キー (NFT に基づくセンチネル ノード キーの権限)
Sentinel ライセンス キーは、Xai ネットワークで Sentinel ノードを操作するために必要な、独自の代替不可能なトークン (NFT) です。 Sentinel ライセンスは、ノードが請求を提出して報酬を受け取る資格の証明として機能します。適切な量の ETH を送信することで鋳造され、鋳造価格はしきい値を増加させるシステムによって決定されます。
ノードのライセンスは、審判契約において重要な役割を果たします。ノードがチャレンジに対してクレームを送信したい場合は、Sentinel 権限 ID を提供する必要があります。審判契約は、Sentinel ライセンスが有効であるかどうか、およびノードが Sentinel ライセンスの所有者であるか承認されたオペレーターであるかを確認します (上記の KYC セクション)。これらの条件が満たされる場合、ノードのクレームはチャレンジに送信されます。
Sentinel の権限は、成功した申請に対する報酬を請求するときにも影響します。審判契約では、Sentinel ライセンスの所有者が KYC を完了しているかどうか、またその明細書が支払いの対象となるかどうかを確認します。これらの条件が満たされた場合、報酬は Sentinel ライセンスの所有者に送信されます。
要約すると、Sentinel 権限は Xai ネットワークの重要なコンポーネントであり、Sentinel ノードの操作、請求の提出、報酬の分配を規制します。
6. ノードのダウンロードと実行
センチネル ノードを実行するには、ユーザーは特定のソフトウェア パッケージをダウンロードするだけで済みます。このパッケージは、デスクトップ アプリケーションまたはコンピュータ上のコマンド ライン ツールとして使用できます。簡単に言えば、これらのアプリは Sentinel ソフトウェアを使いやすくするツールです。このパッケージの目的は、Sentinel の実行に必要なすべての操作を自動化し、技術に詳しくなくてもセットアップと使用が非常に簡単になるようにすることです。
このパッケージは、セットアップ、管理、他のパーツとの対話などのタスクをユーザーが行うのに役立ち、ユーザーが設定を簡単に表示および調整できる使いやすいインターフェイスを備えています。このパッケージを使用すると、ユーザーはより効率的に実行し、より多くのトークン報酬を得る方法にさらに集中できます。ユーザーは、デスクトップ アプリケーションまたはコマンド ライン ツールを使用してこのパッケージを実行することを選択できます。どちらも非常に使いやすく、操作プロセスが非常にスムーズになります。
7.センチネルウォレット機能
Xai エコシステムでは、Sentinel ウォレットが Sentinel ノードとレフェリー スマート コントラクト間の対話において重要な役割を果たします。 Sentinel Wallet は仲介エージェントとして機能し、関連する Sentinel を代表して審判に声明を提出する責任を負います。これは、Sentinel ライセンス キーの所有者またはこの契約で承認されたアドレスの所有者のみが呼び出すことができる、審判契約内の特定の機能によって実現されます。
Sentinel ウォレットは、審判コントラクトの submitAssertionToChallenge 関数を呼び出すことで、チャレンジに対してステートメントを送信できます。この関数は、チャレンジがまだ送信可能であるかどうか、およびこのチャレンジに対してノード キーがすでに送信されているかどうかを確認します。
Sentry Wallet は、レフェリーコントラクトのclaimReward 関数を呼び出すことで、成功したクレームに対する報酬を請求することもできます。この機能は、チャレンジの提出が終了したかどうかを確認し、Sentinel ライセンスの所有者が「KYC」チェックを完了したかどうかを確認します。これらの条件が満たされ、請求が支払いの対象となる場合、報酬はセンチネルの所有者に送られます。
要約すると、Sentinel ウォレットはメッセンジャーとして機能し、ノードとレフェリーの間の対話を促進し、それによって Xai ネットワークのスムーズな運用を保証します。
8. ライセンス
ライセンスの数とノードの送信機能の関係は基本的なものです。ノードに複数のライセンスを関連付けることは可能ですが、ライセンスの数がノードのコミット能力に直接影響することを認識することが重要です。基本的に、公平なコミット クォータを確保するために、ライセンスとノード インスタンスの比率は 1:1 に維持されます。上記の原則に従うことにより、システムはライセンス付与、権利の提出、エコシステム内のノードの全体的な操作に対する構造化されたアプローチを確立します。
9.セントリーノードのソフトウェアおよびハードウェア要件
Sentinel ノード ソフトウェアは、Windows デスクトップ、Mac、および Linux (64 ビットが必要) をサポートします。以下は、最大 100 個のライセンス キーの Sentinel ノード ソフトウェアを実行するために必要な現在のリソースです。
4GBのRAM
2 CPU コア
60 GBのディスク容量
x86/X64 プロセッサ (Apple M1/M2 チップなどの ARM プロセッサをサポート)
安定したインターネット接続
ノードにキーを追加する場合、理想的にはハードウェアの機能もそれに応じて増加する必要があります。ただし、各キーに個別のマシンを割り当てることは必須ではありません。このシステムは、単一マシン上で数十のキー、場合によってはそれ以上のキーに対応できる拡張性があることが期待されています。
注: これらのハードウェア要件は変更される可能性があります。
10. セントリーノードネットワークの推定報酬
XAI トークンエコノミーモデルについては、XAI プロジェクトの「トークンエコノミー」の解釈を参照してください。
Sentry ノードを実行することで得られる Xai の報酬を見積もるための 3 つのシナリオを次に示します。これら 3 つのシナリオは、次の前提に基づいています。
XAI と esXAI の合計が 2,500,000,000 を超えることはありません。 Xai エコシステムが動的であることを考えると、各 Sentry キーに対する毎月のトークン報酬を正確に予測することは不可能です。
GAS は 100% 燃焼されるため、供給が常にインフレになるという保証はなく、デフレになる可能性があります。
Xai Foundation は、50,000 個を超えるセントリー キーを販売しません (ノードは複数のキーをロードできます)。これには 2 ～ 3 年かかると予想されます。セントリーキーは時間の経過とともに高価になります。
Sentry キーごとの esXAI の月次金額も、エコシステム内のステーキング参加者の数に基づいて変動する可能性があります。
次の 3 つの表の意味は、XAI トークンと esXAI トークンの異なる循環のもとで、ネットワーク内でアクティブ化されたノード キーの数と、それに対応するキーごとの予想される月間トークン報酬を示しています。
シナリオ A の推定: 合計 750,000 個の XAI および esXAI トークンが流通している場合、各 Sentry キーは次の表に従って esXAI 報酬を受け取ります。
シナリオ B の推定: 合計 1,250,000,000 個の XAI および esXAI トークンが流通している場合、各 Sentry キーは次の表に従って esXAI 報酬を受け取ります。
シナリオ C の推定: 合計 2,187,500,000 個の XAI および esXAI トークンが流通している場合、各 Sentry キーは次の表に従って esXAI 報酬を受け取ります。
パート 2: XAI は Arbitrum (ARB) によって開発および保守されているため、Arbitrum のアーキテクチャについて少し説明する必要があります。
1.ニトロ決定
すべての Arbitrum チェーンは、エコシステム内のすべてのチェーンの基礎となるテクノロジーである Arbitrum Nitro 上に構築されています。 Nitro は、フォークされたバージョンの Geth を実行し、不正防止の基盤となる仮想マシンとして WebAssembly を使用します。
2.任意の判断
Anytrust は、Data Availability Committee (DAC) と呼ばれるライセンサーの集合を通じてデータの可用性を管理する Arbitrum プロトコルです。このプロトコルは、イーサリアムのトラストレスなデータ可用性メカニズムを使用するのではなく、データの可用性に関する追加の信頼仮定を導入することにより、トランザクション手数料を削減します。
3. 知っているかもしれない Arbitrum 2 レイヤーの概要
Arbitrum Nova は AnyTrust チェーンの一例であり、Arbitrum One は純粋にトラストレスな (そしてより L1 ガスを大量に使用する) Arbitrum Rollup プロトコルを実装する別の代替チェーンです。どちらのチェーンも Nitro で構築されています。
4.オービットチェーン
Arbitrum Orbit を使用すると、サードパーティが独自の自己管理型 Arbitrum Rollup チェーンと AnyTrust チェーンを作成できます。 Arbitrum は、Orbit チェーンを構築する際の柔軟性を最大限に高めるために、Rollup および AnyTrust テクノロジーを提供します。 Arbitrum エコシステム内のすべてのチェーンと同様、Arbitrum Rollups と Arbitrum Anytrust Orbit チェーンは両方とも、基盤となるテクノロジーとして Nitro を使用して構築されています。
5. ザイの基本的な状況を理解する
上記の文脈で Xai を理解しましょう。 Xai は Arbitrum Orbit チェーンとして動作し、Anytrust テクノロジーを活用して最大速度と最小コストを実現します。ほとんどの「自律型」Orbit チェーンとは異なり、Xai は Offchain Labs からの直接技術サポートの恩恵を受けています。この種のサポートは他の Orbit チェーンでは考えられません。これは、Arbitrum エコシステム内における Xai の戦略的ゲーム プランの重要な要素です。
パート 3: 上記の概念を理解したら、アーキテクチャをさらに理解しましょう。
1.AnyTrust: 革新的なブロックチェーン インフラストラクチャ
AnyTrust フレームワーク内で、Arbitrum Nitro テクノロジーの最先端のバリアントとして、Offchain Labs はイノベーションを活用して、ブロックチェーン分野で最も差し迫った課題のいくつかを解決します。 AnyTrust は、軽い信頼の前提を組み込むことで新しい視点をもたらし、強力なデータの可用性とセキュリティを確保しながらコストを大幅に削減します。
2. 信頼の仮定によるコスト削減
Arbitrum プロトコルの中核では、すべての Arbitrum ノード (チェーンの正確性を検証し、正確な結果を賭けるバリデーターを含む) が、Arbitrum チェーンの受信箱内のすべてのレイヤー 2 (L2) トランザクションのデータにアクセスする必要があります。従来、Arbitrum ロールアップは、データをレイヤー 1 (L1) Ethereum 上のコールデータとして公開することによってデータ アクセスを保証します。このプロセスでは、Arbitrum の主要なコスト要素である多額の Ethereum ガス料金が発生します。
3.ケットセットの柔軟性
Ketsets は AnyTrust のアーキテクチャで重要な役割を果たします。これらは、委員会メンバーの公開キーと、データ可用性証明書 (DACert) を検証するために必要な署名の数を指定します。 Ketsets は委員会のメンバーを変更するための柔軟性を提供し、委員会のメンバーが必要に応じてキーを更新できるようにします。
4. データ可用性証明書 (DACerts)
AnyTrust の基本概念はデータ可用性証明書 (DACert) です。 DACert は、データ ブロックのハッシュ、有効期限、および N-1 委員会メンバーが (ハッシュ、有効期限) ペアに署名したことの証明で構成されます。この証明には、署名に使用されたキーセットのハッシュ、どの委員会メンバーが署名したかを示すビットマップ、および署名者を証明する BLS12-381 曲線上の BLS 集約署名が含まれます。
2-of-N の信頼仮定により、DACert は、ブロックのデータが指定された有効期限まで少なくとも 1 人の正直な委員会メンバーに利用可能であるという証拠として機能します。この信頼の前提は、AnyTrust フレームワーク内でのデータ可用性の信頼性とセキュリティの基礎となります。
5.二重データ解放機構
AnyTrust は、L1 でデータ ブロックを公開する二重方式を導入しています。完全なデータ ブロックを公開する従来の方法に加えて、データの可用性を証明する証明書である DACert の発行も可能になります。 L1 受信トレイ コントラクトは、DACert で指定された有効な Keset への参照を含め、DACert の有効性を検証します。
受信トレイからのデータの読み取りを担当する L2 コードは、両方のデータ形式をシームレスに処理できるように設計されています。 DACert が見つかると、署名者の数が Ketsets の要件を満たしていることの確認、集約署名の検証、現在の L2 タイムスタンプを超えた有効期限の確認などの有効性チェックが実行されます。有効な DACert は、データ ブロックにアクセス可能であり、L2 コードによって悪用できることを保証します。
6. データ可用性サーバー (DAS)
委員会のメンバーは、次の 2 つの主要な API を提供する Data Availability Server (DAS) を運用しています。
(1) ソーター API: Arbitrum チェーンのソーターで使用するために設計されたこの JSON-RPC インターフェイスにより、ソーターはデータ ブロックを DAS に送信して保存できます。
(2) REST API: より幅広いアクセシビリティを目的として設計された RESTful HTTP(S) ベースのプロトコルにより、ハッシュを介したデータ チャンクの取得が可能になります。完全にキャッシュ可能であり、キャッシング プロキシまたは CDN と組み合わせて導入することで、スケーラビリティを強化し、潜在的な DoS 攻撃から保護できます。
7. 選別者と委員会の交流
Arbitrum ソーターは、委員会を通じてデータのバッチを公開する場合、データと有効期限をすべての委員会メンバーに RPC 経由で並行して送信します。各委員会のメンバーはデータを保存し、BLS キーを使用して (ハッシュ、有効期限) ペアに署名し、署名と成功インジケータをシーケンサーに返します。十分な署名が収集されると、シーケンサーはそれらを集約して、(ハッシュ、有効期限) ペアの有効な DACert を作成します。この DACert は L1 受信トレイ コントラクトに公開され、L2 の AnyTrust チェーン ソフトウェアにアクセスできるようになります。シーケンサーが指定された時間枠内に十分な署名を収集できない場合、「ロールアップへのフォールバック」戦略を採用し、完全なデータを L1 チェーンに直接公開します。 L2 ソフトウェアは、両方のデータ公開形式 (DACert または完全なデータ経由) を理解し、各形式を適切に処理することに優れています。要約すると、AnyTrust は Offchain Labs エコシステム内の画期的なイノベーションとして、ブロックチェーン インフラストラクチャのデータ可用性、セキュリティ、コスト効率に対処する上で重要な進歩を表します。 AnyTrust は、賢明な信頼の仮定とデータ公開への新しいアプローチを通じて、よりスケーラブルでアクセスしやすく安全なブロックチェーン ソリューションへの道を切り開きます。
パート 4: 上記の概念を念頭に置いて、センチネル ノードが重要である理由、チーター チェックの問題、バリデーターのジレンマが思っているよりも難しい理由、およびその解決策を説明しましょう。
著者はArbitrum社の首席科学者、Ed Felten氏です。
ブロックチェーン システムの一般的な設計パターンは、一方の当事者に何らかの作業を行わせ、正しい動作を保証するデポジットをエスクローし、その後、他の当事者に作業を検証してもらい、作業者の不正行為を発見した場合にはこのデポジットを取り上げるように依頼することです。これを「アサートチャレンジ」設計パターンと呼ぶこともできます。私たちはこれを Arbitrum で行っており、最近ニュースで Optimistic Rollup のような提案を目にしました。
これらのシステムは、バリデーターのジレンマの影響を受ける可能性がありますが、これは基本的に、誰かが不正行為をしないことがわかっている場合、その人の作業をチェックすることに意味はないが、チェックしなければ、不正行為をするインセンティブが働くという観察です。あなたが設計者であれば、自分のシステムがインセンティブと互換性があること、つまり全員がインセンティブに従って一貫して行動すれば不正行為は発生しないことを証明したいと思うでしょう。これは、直感が間違った方向に導く可能性がある領域です。以下の当事者のインセンティブを紐解くとわかるように、この問題は見かけよりもはるかに難しいです。
超シンプルなモデル
できる限り最も単純なモデルを構築することから始めます。プレイヤーが 2 人いるとします。アサーターは、真または偽のステートメントを作成します。チェッカーはアサーターの主張をチェックすることも、おそらくアサーターがおそらく真実を語っているという仮定に基づいて、何もしないことを選択することもできます。チェッカーのチェックコストを C と仮定します。チェッカーがチェックし、アサーターが不正行為をしたことが判明した場合、チェッカーは R の報酬を受け取ります。 (R には、不正行為を発見することで審査官に生じるすべての利益が含まれます。これには、「システムの外部」で実現される利益と、システムに対する信頼の向上によって得られる利益が含まれます。) 主張者が逮捕されなかった場合、不正行為の下では、検査官は負けます。例えば、不正行為を主張する者がチェッカーから貴重品を不正に奪う可能性があるためです。
現在、私たちは贈収賄と怠惰という 2 つの脅威を心配する必要があります。賄賂とは、アサーターがチェックしないようにチェッカーに賄賂を渡し、それによってアサーターが検出されずに不正行為を行えるようにする可能性です。この事態の発生を防ぐには、アサーターがシステム内の合計値よりも大きい非常に多額のデポジットをエスクローし、不正行為が検出されたときにチェッカーに支払うようにすることで、アサーターがチェッカーの報酬 R の額を超える金額を支払おうとしないようにすることができます。賄賂。これにより贈収賄は防止されますが、システムを完全に担保する必要があり、これには非常に費用がかかる可能性があります。
もう 1 つの脅威は怠惰、つまりチェッカーがアサーターの作業をチェックしないと決定するリスクです。 (チェッカーはチェックしていると言うかもしれませんが、実際にはチェックしていないことを覚えておいてください。)これが合理的な戦略であるかどうかを確認するために、チェッカーのインセンティブを見てみましょう。
アサーターが確率 X で不正行為をしたとします。さて、インスペクターのユーティリティは次のとおりです。
レビュアーがチェックする場合: RX-C
チェッカーがチェックしない場合: -XL
検査する価値があるのは、検査する効用が検査しない効用より大きい場合、つまり X > C/(R+L) の場合だけです。ここに悪いニュースがあります。アサーターは C/(R+L) 未満の確率でランダムに不正行為を行う可能性がありますが、合理的なチェッカーは決してチェックしないため、アサーターが不正行為を捕らえられることはありません。
いくつかの数字を代入してみましょう。各トランザクションをチェックするコストが 0.10 ドルで、チェッカーが不正行為を検出した場合は 75 ドルの報奨金を受け取るが、不正行為を検出できなかった場合は 25 ドルを失う場合、アサーターは何千回でも罰を受けずに不正行為を行うことができます。このシステムで何千ものトランザクションを実行したい場合、大きな問題が発生します。明らかに、このモデルでは不正行為の可能性をゼロにするためにできることは何もありません。 C/(R+L)の分母が大きくなるような超過担保制度を期待するしかありません。
これは、悪い意味で、驚くほど堅実な結果です。それは主張者のインセンティブにはまったく依存しません。アサーターが不正行為の成功によってゼロではない利益を得ている限り、チェッカーがチェックする価値がないことを知っていれば、ある程度の確率でそうすることができます。また、この結果は、検査官に仕事を完了させるためにどれだけの時間を与えたか、あるいは（称する）検査官にお金を払ったかどうかにも依存しません。おそらくあなたは今考えているかもしれませんが、問題は検査官が 1 人しかいないことです。チェッカーをさらに追加すると不正行為の可能性は減りますか?驚くべきことに、そうではありません。
検閲官を追加しても不正行為の防止には役立たない
もう一度、最も単純なモデルを定式化してみましょう。現在、2 人の検査官が独立して活動しています。各チェッカーがチェックした場合は C を支払い、誰かがチェックしてアサーターの不正行為を発見した場合、成功したチェッカーに報酬 R が支払われます。または、両方がチェックした場合、報酬は 2 人で均等に分割されます。 (必要に応じて、全員がチェックした場合に、そのうちの 1 人にランダムな全額報酬 R を与えることができます。これは誰の戦略や結果にも影響しません。) 前と同様、アサーターが不正行為を行った場合、各チェッカーは L を失います。つかまった。
アサーターがその時点で C/(R+L) よりも不正行為を行っていない場合、チェックすることの効用はチェックしないことの効用よりも低いため、チェッカーがチェックする価値はないという状況が残ります。実際、インセンティブの問題は以前よりも悪化しています。チェッカーごとのチェックのコストは依然として C ですが、不正行為を発見したチェッカーの期待報酬は R 未満です。これは、報酬を分割する必要がある場合があるためです。期待される報酬は次のようになります。 R/2 と R にあります。期待される報酬が bR (b が 0.5 から 1 の間) の場合、アサーターはその時点で最大 C/(bR+L) まで不正行為を行うことができます。これは、チェッカーが 1 つだけの場合よりも検出されない不正行為です。 (b の値はチェッカーの戦略に依存し、チェッカーの戦略は b に依存するため、数学は少し複雑になりますが、報酬を分割する必要がある場合があることは明らかです。また、L の実効値も減少します。 、チェッカーはそうでないので、他のチェッカーによるチェックによって L を失うことはありません。)
検閲官の追加が本当に役立つのは、贈収賄の防止です。チェッカーが 2 人いる場合、アサーターは各アサーターに R を超える賄賂を支払わなければならないため、賄賂の費用が 2 倍になり、全額ステーキングではなく 50% のステーキングが可能になります。しかし、その代償として不正行為の量が増加します。
ここではすべての計算については説明しませんが、合理的な仮定の下では、チェッカーを 1 つから 2 つに増やすと、検出されない不正行為が 50% 増加する可能性があります。
検閲官を追加すると事態はさらに悪化します。
さらにチェッカーを追加すると、状況がさらに悪化する可能性があります。チェッカーの数が増加するにつれて、チェッカーは報酬が複数の方法に分割されることについてより心配する必要があるため、成功したチェッカーごとに期待される報酬は徐々に減少し、アサーターが安全に不正行為を行う確率が徐々に増加します。この観点から見ると、最悪のシナリオは、世界中の誰もが検閲官になる可能性があるということです。検閲官が増えれば増えるほど事態は悪化するため、これが無限に悪いことではありませんが、たとえ贈収賄のリスクを効果的に排除できたとしても、不正行為の防止には決して役立ちません。
あなたのシステムはインセンティブに対応していますか?
このタイプのモデルに適合するシステムがあり、それがインセンティブと互換性があると思われる場合は、その理由を慎重に考える必要があります。特に、たとえアサーターが不正行為をする可能性は低いと考えている場合でも、チェッカーがチェックの仕事をする理由を説明する必要があります。多額の不正行為ペナルティを課すだけでは十分ではありません。不正行為者を捕まえて報酬を得るだけでは十分ではありません。単にチェッカーをたくさん置くだけでは十分ではありません。実際、それは状況を悪化させる可能性があります。なぜあなたのシステムは免疫力があるのでしょうか?
この課題は、Optimistic Rollup などのシステムに当てはまります。 Arbitrum について話すとき、それは私たちにも当てはまります。
上記を考慮すると、従来のインセンティブ チェック方法では望ましい結果が得られません。ベースラインの不正行為率があり、それを下回るとチェック担当者はチェックに価値がないと判断します。結論は：
プレイヤーは 2 人います。1 つは真か偽か主張を行うアサーターであり、もう 1 つはチェッカーであり、ある程度の計算コストをかけて主張をチェックできます。チェッカーがチェックした場合のユーティリティは RX-C、チェックしなかった場合のユーティリティは -XL です。R は不正行為を発見したことに対する報酬、C はチェックのコスト、L は不正行為を検出できなかったことによるチェッカーの損失です。 , X は、アサーターが不正行為を行う確率 (アサーターが選択した) です。いくつかの代数は次のことを示しています
この問題を解決し、インセンティブ主導のレビュー担当者が常にチェックする状況を作り出すには、レビュー担当者のインセンティブを変更する必要があります。基本的な問題は、元のモデルでは、チェッカーがチェックする正のインセンティブはすべて次の値に比例するということです。関係なく機能するチェックインセンティブが必要な場合は、アサーターのアクションとは独立した、チェックインセンティブまたはチェックしないことに対するディスインセンティブを作成する必要があります。
TrueBit は、意図的に虚偽の主張を一連のアサーションに追加し、基本的に X を X に定数を加えたものに置き換えることによってこれを試みます。このアプローチにはいくつかの問題があります。 (Arbitrum のオリジナルの論文には、TrueBit のモチベーションの問題に関するセクションがあります。)
課題に焦点を当てる
私たちは、「課題に焦点を当てる」と呼ぶ、別のアプローチを採用しています。この考え方は、アサーターが値 f(x) を計算している場合、最初に x と暗号化チャレンジを発行するというものです。チャレンジに正しく応答するには、試験官は f(x) を知る必要があります。チャレンジが発生した後でのみ、アサーターは f(x) を公開します。この時点で、チェッカーはすでに f(x) を計算するという大変な作業を行っているため、怠惰になる動機はありません。 （契約の詳細については後述します。）
これに必要なオンチェーン トランザクションの数を減らすために、チェッカーによるチャレンジに対する正しい応答が通常は沈黙になるように調整します。ただし、まれに、チェッカーがチェーン上に非常に小さなトランザクションを発行する必要がある場合があります。チェッカーが間違った答えを出した場合、つまりリリースすべきときに沈黙するか、リリースすべきときに沈黙すると、少額のデポジットが失われます。
オリジナルのインセンティブ モデルを適応させて、注意喚起の課題を組み込んでみましょう。 2 つの新しいパラメータ (どちらも選択可能) が必要です。P はチェッカーの正しい応答が投稿される時間の割合、A はチェッカーが間違った応答をした場合のペナルティです。さて、インスペクターのユーティリティは次のとおりです。
チェックした場合：RX-C
そうでない場合は、-LX-PA をチェックしてください。
重要な観察は、PA > C である限り、X (不正行為の確率) が何であっても、チェックすることが最適な戦略であるということです。
非常に低コスト
コストを評価するために、具体的な例を見てみましょう。 5 分ごとにアサーションがあり、チェックのコストが 0.001 ドルだと仮定します。確率 P を 0.3% に設定すると、チェッカーは 3 ドルのデポジットを支払う必要があります。ここで、チェッカーのアサーションあたりのコストは、ガス料金 0.0003 ドル (サイレントではない応答を投稿するための 0.10 ドルのガス料金に、投稿する必要がある 0.3% の確率を掛けたもの) に、3 ドルのベットを 5 分間ロックするための約 0.0003 ドルを加えたものとなります。利息のコストはアサーションごとに 0.0006 ドルです。
複数のインスペクタ用の拡張機能
フォーカス チャレンジは、複数の試験官でもうまく対応できます。このプロトコルは、各チェッカーに異なる影響を与えるチャレンジを発行し、各チェッカーが f(x) を独自に計算するように強制します。各チェッカーには同じコストがかかります (この場合、アサーションごとに 0.0006 ドル)。
オープン システムでは、誰でも計算をチェックする資格があり、誰でもチェッカーとして登録し、必要な少額の入金を行うことができます。これにより、彼らはアテンションチャレンジを受ける資格が得られ、dapp開発者から報酬を受け取る可能性があります。誰でも主張者の不正確な主張に異議を唱えることができますが、登録された審査官のみが注目を集めるという課題に直面します。
契約の技術的詳細
課題に焦点を当てることで何ができるかを理解したところで、課題がどのように機能するかという技術的な詳細を見ていきましょう。
各チェッカーは、適切なグループで定義された秘密鍵 k と、対応する公開鍵 gᵏ を持っています。各チェッカーの公開キーは誰もが知っています。また、適切なハッシュ関数 H にも依存します。
関数 f が事前にわかっている場合、f(x) の計算にチャレンジを発行するには、アサーターはランダム値 r を生成し、(x, gʳ) をチャレンジとして発行します。
秘密鍵 k を所有するチェッカーは、H(gʳᵏ, f(x)) < T (T は適切に選択されたしきい値) の場合にのみ、小さなトランザクションを発行することでチャレンジに応答する必要があります。 gʳᵏ を計算できるのはアサーター (r を知っている) と特定のチェッカー (秘密鍵 k を知っている) だけであるため、ハッシュを計算できることに注意してください。また、ハッシュを計算するには f(x) を知る必要があることにも注意してください。
チェッカーがチャレンジに対する応答を投稿する時間が経過した後、アサーターはその f(x) を投稿することができ、チェッカーがそれに同意しない場合は、通常どおりチャレンジが行われます。この時点で、アサーターは、間違った応答についてチェッカーを非難することができます。アサーターは、自分の非難を実証するために r を発行する必要があります。マイナーまたは契約者は告発が正しいかどうかを確認し、違反者を罰することができますが、f(x) についての主張者の主張が最終的に正しいものとして受け入れられない場合、告発は無視されます。チェッカーに罰金が科せられた場合、アサーターは没収された資金の半分を受け取り、残りの半分は破棄されます。
このアプローチは、審査官に適切なインセンティブを与えます。チェッカーがチャレンジにどのように応答すべきかを知るには、そのチェッカーの秘密鍵と f(x) を知る必要があるため、各チェッカーは f(x) を計算する必要があります。チェッカー自体が f(x) を計算しない限り、プロトコルを安全に強制することはできません。他のチェッカーの応答は、それらのチェッカーの秘密キーに依存しているため、f(x) を決定するのには役に立ちません。チェッカーが f(x) を伝える他の誰かに依存している場合、その主張された値を検証する方法 (f(x) 自体を計算する以外) がなく、チェッカーはそれが間違っている場合にペナルティを受ける危険があります。一方の当事者には、f(x) についてチェッカーを誤解させようとするインセンティブさえあります。つまり、チェッカーの間違いから利益を得て、その利益を利用してチェッカーの「友人」に賄賂を渡し、チェッカーに間違った情報を提供する可能性があるアサーターです。 。
最適化と結論
このプロトコルをより効果的にするには、いくつかのトリックがあります。たとえば、チャレンジによってトランザクション数が増加しないように、アサーションと次のチャレンジをオンチェーン トランザクションにバンドルできます。 P が小さく (例: この例では 0.3%)、チェッカーの数がそれほど多くない場合、チェッカーがチェーン上にトランザクションを書き込む必要はほとんどないため、オンチェーン トランザクションの数に対するプロトコルの全体的な影響は次のようになります。最小であること。
賢明な実装により、このプロトコルのコストは、オンチェーンでアサーションを発行するための初期コストと比較して非常に低くなるはずです。私たちの場合、既存のアサーション チャレンジ プロトコルにアテンション チャレンジを追加すると、総コストの増加は 1% 未満になります。
そして、その利益は大きく、バリデーターのジレンマの影響を受けない、インセンティブと互換性のあるチェックプロトコルを手に入れることができます。少なくとも 1 人のチェッカーが合理的である限り、アサーターの主張は常にチェックされます。
プロジェクトに関するその他の情報については、次を参照してください: ゲーム パブリック チェーン Xai: Binance Square データベース
