注: The Graph の TAP 移行期限は 2024 年 12 月 3 日で、インデクサーの約 34% がアップグレードされ、クエリ量の 81.6% を占めています。 Q&A ディスカッションでは、TAP の構成設定、特に RAV (Receipt Aggregation Voucher) リクエストと非集計料金の管理に焦点が当てられ、デフォルトから始めてクエリ量に基づいて調整することが推奨されました。
皆さん、こんにちは。Indexer オフィスアワー会議議事録、セッション 184 へようこそ。
動画リンク：https://youtu.be/w0LZkVJemPY
Persistence Labs の COO、Jeroen Develter による GRTiQ ポッドキャストをご覧ください。 Jeroen の Web3 の旅は、従来の金融、コンサルティングの世界から始まり、暗号通貨とブロックチェーンの世界に飛び込みました。
重要なリポジトリの最新アップデート
- 新しいバージョン v1.4.12 を入手します。
- 日付: 2024-11-19 13:53:28 UTC
- このリリースでは、非推奨のパーソナル RPC 名前空間と –unlock コマンドが削除され、キー管理が大幅に変更されました。また、最適化、データベースの改善、さまざまなバグ修正に加え、トラッカー構成の大幅な変更も含まれています。
- 緊急インジケーター：黄色
- 緊急の理由: キー管理の変更にはユーザーによる調整が必要です。
- Reth 新バージョン v1.1.2
- 日付: 2024-11-19 16:27:10 UTC
- このリリースには、パフォーマンスの向上、バグ修正、および新しいハード フォークに向けた重要な準備が含まれています。これらの変更は、特にペイロード ジョブの取得を最適化し、保留中のトランザクション順序に対処するため、OP-reth ユーザーが常に最新情報を入手できることが重要になります。
- 非常インジケーター：赤色
- 緊急の理由: OP-reth ユーザー向けのハードフォークの準備。
- sfeth/fireeth: 新しいバージョン v2.8.0:
- 日付: 2024-11-14 14:55:01 UTC
- CombinedFilter は nil 安全性チェックを統合し、トランザクション処理中の安定性を強化します。さらに、サブストリームと dmetering の更新には、計測機能の改善が含まれています。
- 緊急インジケーター：黄色
- 緊急の理由: 安定性の向上ですが、差し迫った脅威ではありません。
- Avalanche: 新しいバージョン v1.11.13:
- 日付: 2024-11-18 22:24:03 UTC
- このリリースでは、プラットフォームに新しい API が導入されているほか、RPCChainVM メトリクスの初期化と互換性の改善が修正されています。互換性と安定性を高めるために、Operator を最新のプラグイン バージョンに更新することをお勧めします。
- 緊急インジケーター：黄色
- 緊急の理由: 重要な修正と新機能には迅速な対応が必要です。
- インデクサー サービスおよびエージェント (TS): 新しいバージョン v0.21.8:
- 日付: 2024-11-18 19:23:13 UTC
- このリリースには、いくつかのマイナー アップデートが含まれており、サブグラフの高さの競合メッセージを軽視することでユーザー インターフェイスが改善され、インデックス エージェントのポーリング間隔パラメータが修正されています。システムのパフォーマンスやセキュリティに影響を与える重大な変更は見つかりませんでした。
- 緊急インジケーター：緑色
- 緊急の理由: 変更による影響は少なく、重大な問題はありません。
- インデクサー サービスとクリック エージェント (RS): 新しいバージョンのindexer-tap-agent-v1.7.3:
- 日付: 2024-11-13 19:04:13 UTC
- バージョン 1.7.3 では、トランザクション処理に影響を与える可能性があるマネージド アダプター チェックを削除することでバグを解決しています。すべてのオペレーターは、シームレスな機能を確保するためにこの変更を確認する必要があります。
- 緊急インジケーター：黄色
- 緊急の理由: 重要な修正であり、重大ではありませんが、できるだけ早く更新することをお勧めします。
プロトコルの重要な変更に関する最新の更新情報
- The Graph での仲裁の強化: ワーキンググループの立ち上げ、仲裁委員会の拡大、プロセスの更新
- 新しい仲裁ワーキンググループは、新しいアナリストが就任するまで一時的に仲裁アナリストの任務を引き継ぎます。
- 仲裁委員会の拡大により、仲裁において高い基準を維持するというグラフの取り組みが強化されます。
- 仲裁プロセスは、改善の余地がある領域を特定するために積極的に検討されています。
- よくある質問と参考資料については、フォーラムの投稿を参照してください。
- 紛争 #GDR-19 に関する情報の要求
- 同じインデクサーが以前にスラッシュを引き起こす行為を繰り返していたため、この紛争は GDR-18 に関連しています。
- 一般: 非ローカル チェーンにはハードハット セキュア アカウントを使用する #1070 (オープン)
- 一般: Bump Ignition バージョンを 0.15.7 #1069 (オープン)
- 修正: デプロイメント スクリプトに不足しているパラメーターを追加し、SubgraphService の実行回数を 50 回に減らしました #1062 (オープン)
今日のディスカッションは、GraphOps の Ana と Semiotic Labs の Gustavo による TAP 移行 Q&A です。 TAP は、The Graph をクエリするための新しいマイクロペイメント システムです。
🚨 インデクサーは 2024 年 12 月 3 日までに TAP に移行する必要があります。
このセッションは、Ana の IOH TAP 移行に関する Q&A ノートに基づいて進められました。このノートは、ディスカッションの背景情報とともにこのセクションにコピーされています。コメントは軽く編集してあります
アナ |GraphOps: TAP とは何ですか?
TAP (タイムライン集約プロトコル) の概要:
- 古い Scalar 支払いシステムを置き換えます。
- 効率的なマイクロペイメント、オンチェーントランザクションの削減、レシートに対するインデクサー制御などの重要な機能を備えています。
- インデクサーが複数のゲートウェイからのクエリを受け入れられるようにすることで、分散ゲートウェイを有効にします。
インデクサーは何をする必要がありますか?
- インデクサースタックを更新してindexer-agent (バージョン0.21.4以降)を実行し、indexer-serviceを置き換えてRustバージョンを実行し、新しいコンポーネントindexer-tap-agentを追加します。
- インデクサー リポジトリ (インデクサー エージェント)
- インデクサー RS コード ベース (インデクサー サービスおよびインデクサー タップ エージェント)
- リソース：
- Kubernetes を使用している場合は、launchpad-charts/graph-network-indexer を使用します。
- Docker Compose を使用する場合は、StakeSquid スタックを使用します
- TAP 移行ガイド
Mickey |The Graph |E&N: インデクサーが期限を過ぎたらどうなりますか?ゲートウェイは、アップグレードされるまで、新しいクエリをルーティングしません。それとも...?
- Gustavo |Semiotic Labs: ゲートウェイは現在、Scalar と TAP のレシートを提供しています。期限に達すると、ゲートウェイは TAP 受信のみをサポートします。バージョンが 1.0 より前の場合は、クエリを受信できなくなります。
- アナ: ありがとう、それは当然ですね。したがって、引き続きクエリを取得したい場合は、移行する必要があります。
Mickey |The Graph |E&N: インデクサーの何パーセントが Indexer-rs/tap に移動されたかを知る方法はありますか?
- Ana: インデクサーが TAP に移行されているかどうかを確認する 1 つの方法は、GraphSeer のインデクサー設定ファイルに TAP READY というラベルの付いたバッジがあるかどうかです。
- Gustavo: Semiotic では、この数値を注意深く追跡し、インデクサーが 1.0 より新しいバージョンを実行しているかどうかを確認しています。私たちが追跡している 88 のインデクサーのうち、30 がインデクサー バージョン 1.0 以降を実行しており、インデクサーの約 34% を占めています。
- また、クエリごとに先月に処理されたクエリの数も追跡しているため、現在、クエリの 81.6% が TAP 経由で実行されています。
- アナ: あなたの言いたいことは、クエリ量が最も多いインデクサーがアップグレードされたということだと思います。
- グスタボ: はい。上位 10 のインデクサーのうち、9 がアップグレードされました。実際、最初の 14 個のインデクサーのうち 13 個がアップグレードされました。
Mickey |The Graph |E&N: 私の印象では、多くのインデクサーがアップグレードで問題を抱えているということです。その印象は正しいでしょうか。そうであれば、全員を事前にアップグレードするために 12 月 3 日の期限は現実的でしょうか? (シェーディングはありません。これが十分に安定しているかどうかが気になるだけです)
- Gustavo: ほとんどのクエリは順調に[移行]できていると思います。 12 月 3 日の期限までにインデクサーの 100% を移行するのは少し難しいですが、95% までは簡単に達成できると思います。 100％達成できるよう全力でサポートさせていただきます。
Mickey |The Graph |E&N: なぜ 88 [インデクサー] なのでしょうか?実際にクエリを処理するのはこれらだけですか?
- Gustavo: サービス品質 (QoS) サブグラフを使用してすべてのアクティブなインデクサーをチェックします。そのため、基本的に、先月にクエリを提供した場合、それらは 88 リストに表示されます。私たちは主にクエリに関心があり、クエリを提供するインデクサーが最新バージョンを使用していれば満足です。
paka |E&N: クエリ トラフィックのほとんどが TAP に送られることも確信しています。
ミッキー |ザ・グラフ |E&N: はい、わかりました!良い戦略だ。
Mickey |The Graph |E&N: 問い合わせを行ったがまだアップグレードしていない遅れているユーザーに個別に連絡しますか?
- グスタボ氏: 私たちは、連絡を取ったインデックス業者と連絡を取っているところです。私たちはリストを持っており、最大のリストから順に各リストに連絡しています。現在、まだアップグレードされていない最大の 2 つは、Upgrade Indexer [Edge & Node] と Pinax です。私たちは、1.0 以降のバージョンへのアップグレードをサポートできるように、Edge および Node と緊密に連携しています。そのインデクサーに接続している限り、処理される量が最も多いクエリから最も少ないクエリまで 1 つずつ作業が行われます。
アナ: インデクサーは、移行されたインデクサーに支援を求めてフラグを立てることを歓迎します。ご不明な点がございましたら、お気軽にお問い合わせください。
Gustavo | Semiotic Labs: 質問がある場合は、📁︱indexers および 📁︱indexers - ソフトウェア チャネルの Graph Discord でお答えします。
- 集計されていない料金と RAV リクエスト:
- 問題: 特に rav_request_trigger_value の設定が低すぎる場合、インデクサーは未集計の料金が頭打ちになる可能性があります。
- 説明: rav_request_trigger_value は、インデクサーが送信者から受信集約バウチャー (RAV) を要求するタイミングを決定します (送信者はゲートウェイと考えることができます)。この値が低すぎる場合、トリガーが頻繁に満たされず、チャージがロールアップされずに蓄積される可能性があります。
- 解決策: max_amount_willing_to_lose_grt /trigger_value_divisor として計算された rav_request_trigger_value を更新します。
アナ: ダッシュボードがあって、ここに置きました。非集計パネルでは、トリガー値を確認できます。私の場合、RAV トリガー値は 3 です。その仕組みは、新しい領収書を受け取ると、その金額が未集計の経費に追加され、システムは未集計の経費の合計がトリガー値を超えているかどうかを継続的にチェックすることです。
トリガー条件が満たされると、タイムスタンプ バッファーをチェックして受信が受信としてみなされる期間を決定することによって RAV リクエストが作成され、RAV リクエストの受信制限に基づいて受信の数が制限されます。
構成をざっと見てみると、重要な点がいくつかあります。
- max_amount_willing_to_lose_GRT
- トリガー値除数
これら 2 つによってトリガー値が決まります。
- timestamp_buffer_secs、つまり受信が考慮される時間
- max_receipts_per_request なので、RAV には最大 10000 件のレシートを含めることができます
無効なレシートがある場合、それらはインデクサー メタデータ データベース内の Scaler TAP レシート無効テーブルに個別に保存されます。 max_receipt_value_GRT がこの値より大きい場合、レシートは無効になります。
構成: maximal-config-example-toml
Gustavo: ここで何が起こっているのか、そしてなぜ多くの構成があるのかについて話したいと思います。ほとんどのインデクサーでは、大量のクエリが発生しないため、これらの構成は問題になりません。
1 秒あたりの割り当てが多すぎる場合、またはクエリが多すぎる場合は、少し困難になる可能性があるため、これらを更新して構成する必要があります。一般的には、まずデフォルトを試して確認することをお勧めします。現在のデフォルト値は次のとおりです。
- max_amount_willing_to_lose_GRT = 20
- トリガー値除数 = 10
- これは、未要約の領収書 (未要約の料金とも呼ばれます) の合計金額が 2 GRT に達するたびに、それらをロールアップしようとすることを意味します。ただし、値が常に 2 より大きい場合は、これらの値を変更する必要があります。
- max_amount_willing_to_lose_GRT をできるだけ低く保つようにしてください。ただし、大規模なインデクサーであるため、RAV リクエストが失敗し、その時点で大量の受信確認を受信した場合、送信者はすぐにブロックされます。
- タイムスタンプ_バッファ_秒 = 60
- request_timeout_secs = 5
- リクエストごとの最大受信数 = 10000
最初の 15 ～ 20 のインデクサーは、これらの値を更新する必要があります。
Pierre | Chain-Insights.io: 私の理想的な価値観は何ですか?やはりデフォルトのままで良いのでしょうか？ RAVのリクエストはないようです。
最初の 15 ～ 20 のインデクサーは、これらの値を更新する必要があります。
Pierre | Chain-Insights.io: 私の理想的な価値観は何ですか?やはりデフォルトのままで良いのでしょうか？ RAVのリクエストはないようです。
Gustavo: 確認させてください... トリガー値 未集計コストの合計。それで、最初にいくつかの更新があります。どのバージョンを使用していますか?
ピエール: 最新バージョンです。
Gustavo: 通常、トリガー RAV に到達すると、RAV リクエストの作成が試行されるはずです。これが起こらない場合は、調査する必要があります。
ピエール | Chain-Insights.io: 私には当てはまりません:
tap: max_amount_willing_to_lose_grt: 20 tap.rav_request: trigger_value_divisor: 2 timestamp_buffer_secs: 60 request_timeout_secs: 5 max_receipts_per_request: 10000
グスタボ: トリガー値は約 10 ですよね?
ピエール投稿: はい、20/2
Gustavo: つまり、特定の割り当てに対して 10 GRT または 10000 レシートに達した場合にのみ、RAV リクエストがトリガーされます。クエリの量を考えると、0.1 程度、または次の値をお勧めします。
max_amount_willing_to_lose_grt: 1 trigger_value_divisor: 10 max_receipts_per_request: 1000
ピエール投稿: わかりました、ありがとう。
Gustavo: 1 秒あたりのクエリ数がそれほど多くない場合は、RAV リクエストを増やすか、トリガー値を大きくする必要があります。
すべては、開いている割り当ての数、受信する 1 秒あたりのクエリの数、割り当てごとの 1 秒あたりのクエリの数、およびバーストによって異なります。
TAP では、ある時点での集計後、その時点より前のタイムスタンプを含むレシートは機能しなくなります。これらは無効であると見なされるため、このバッファーが存在します。 60秒経過後の領収書のみ受け付けます。これは、異なるコンピュータ間で時計を同期することが難しいためです。ゲートウェイは受信確認を送信し、時計の 5 秒前または後のタイムスタンプを定義します。
デフォルト値は、1 秒あたり 1 ～ 2 クエリ、15 分ごとに 1 つの RAV リクエストとして、その中間の値に設定します。ただし、メモリがこの量より少ない場合は、より低い max_amount_willing_to_lose_grt に更新する必要がある場合があります。この数を超える場合は、さらに多くの数に更新する必要がある場合があります。
Gemma | LunaNova: これらの値は割り当てごとですか、それともすべての割り当てですか?
カリーナ | GraphOps: 割り当てごと
Pierre | Chain-Insights.io: 次のバージョンに更新した後:
Gemma|LunaNova: これらの値は割り当てごとですか、それともすべての割り当てですか?
カリーナ | GraphOps: 割り当てごと
Pierre | Chain-Insights.io: 次のバージョンに更新した後:
calinah |GraphOps: 素晴らしいですね、受け入れ率が向上しました。
グスタボ: ああ、それはいいよ。したがって、ダッシュボードに対して行うべきことは、未集計の料金を常に 0.1 に保つことです。これにより、RAV リクエストがあるたびに料金が少しずつ下がり、15 分後には別の RAV リクエストをトリガーするのに十分なレシートが得られるようになります。
Josh Kauffman |StreamingFast.io: これらの値に設定した内容を共有できる人はいますか?
Marc-André |Ellipfra: 参考までに、私はキャンペーンにこれらの値を使用しました。ほぼランダムに設定されるため、特にお勧めしません。 max_willing_to_lose は、ゲートウェイが頻繁に拒否されるのを避けるために非常に高く設定されています。ある時点でこれを下げる予定です。
max_amount_willing_to_lose_grt = "1000.0" [tap.rav_request] timestamp_buffer_secs = 30 trigger_value_divisor = 50 request_timeout_secs = 20 max_receipts_per_request = 2000
- 送信者の拒否の問題:
- 送信者は Tap.sender_aggregator_endpoints にリストされていません。
- 送信者のエスクロー残高が未払いの料金をカバーするには不十分です。
- 未集計の料金が max_fee_per_sender 制限を超えています。
- 問題: インデクサーで送信者の拒否が発生し、クエリの処理と収益が中断される可能性があります。
- 拒否の理由: 送信者が拒否される主な理由は次の 3 つです。
- 解決策: 拒否理由ごとの具体的な解決策:
- 送信者が Tap.sender_aggregator_endpoints セクションで正しく構成されていることを確認します。
- エスクロー ファンドに関する潜在的な問題を調査し、適切な残高を確保します。
- 未集計の料金が頻繁に制限に達する場合は、max_amount_willing_to_lose_grt 設定を確認し、場合によっては調整します。
- 注: インデクサー TAP エージェントは常に次の名前で開始します。
2024-11-13T08:41:31.200776Z ERROR indexer_tap_agent::agent::sender_accounts_manager: There was an error while starting the sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490, denying it. Error: No sender_aggregator_endpoints found for sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490 in ractor::actor::Actor with id: "0.0" at tap-agent/src/agent/sender_accounts_manager.rs:311 (ID: "0.0") で見つかりました。
INDEXER_TAP__SENDER_AGGREGATOR_ENDPOINTS__ が Tap.sender_aggregator_endpoints にない、または環境変数を介していない場合
- インデクサー エージェントでの収集受信エンドポイント エラー:
- インデクサーエージェント上のcollect-receipt-endpoint 説明：
{"level":40,"time":1731239677641,"pid":1,"hostname":"graph-network-indexer-agent-0","name":"IndexerAgent","msg":"The option '--collect-receipts-endpoint' is deprecated. Please use the option '--gateway-endpoint' to inform the Gateway base URL."}
Gustavo: 送信者を拒否したい理由は、送信者があなたに支払いをしていないため、十分なエスクローを持っていない、またはあなたが失っても構わない金額を要求しているためです。もう 1 つ発生する可能性があるのは、無効なレシートを使用することです。そのため、無効なレシートの数が損失しても構わない最大数である場合は、その送信者をブロックすることになります。
max_receipt_value_grt に関する簡単な更新は、これがそのサービスにのみ適用されるということです。 TAP が最低限信頼されるためには、これらがマイクロペイメントである必要があるため、ゲートウェイがレシートを送信すると、これが無効なレシートとみなされずに受け入れられるレシートの最大値となります。
無効な領収書とは、お客様が受け取って問い合わせた結果、その領収書が無効であることが判明した領収書です。
アナ: 無効なレシートの場合、条件が変更された場合に有効になりますか、それともレシートが無効としてマークされると再試行は行われないのでしょうか?
グスタボ: 再試行はありません。このテーブルはログ記録にのみ使用されるため、データベースにアクセスして、何が起こったのか、なぜ受信が失敗したかを確認できます。
アナ: それは当然ですね。さらに、TAP コントロール パネルでは、送信者がブロックされているかどうかを確認できます。
- RAV リクエスト エラー:
- 問題: RAV リクエスト中のエラーにより、集計プロセスが中断される可能性があります。
- エラーの例: RAV リクエストに有効な受信がないようです... rav_request_trigger_value を増やすことでこれを修正できます。
- 説明: このエラーは、rav_request_trigger_value が不十分であるため、受信を RAV 要求に含めることができないことを示します。
- 解決策: 解決策はエラー メッセージに示されています – rav_request_trigger_value を増やします。
- ソフトウェア バージョン: インデクサー エージェント、インデクサー サービス、およびタップ エージェントに必要なソフトウェア バージョンを使用します。
- 構成ファイルのチュートリアル:
- 共有構成: インデクサーサービスとタップエージェントは共通の TOML 構成ファイルを共有します。
- ブロックチェーンのアドレスとエンドポイント:
- 重要: 正しいコントラクト アドレス、ゲートウェイ エンドポイント、チェーン ID を使用してください。
- ログ レベルの構成: 適切なログ記録用に RUST_LOG 環境変数を設定するには、RUST_LOG=indexer_tap_agent=debug,info を使用します。
- メトリクスと Grafana ダッシュボード:
- メトリクス エンドポイント: すべてのコンポーネントは、Prometheus のポート 7300 でメトリクスを公開します。
- Grafana ダッシュボード:indexer-rs/docs/dashboard.json
Pierre | Chain-Insights.io: 12 月 3 日まで、アクティブな送信者は 1 人だけですか?
# collect-receipts-endpoint: " " DEPRECATED # collect-receipts-endpoint: " " DEPRECATED gateway-endpoint: " " gateway-endpoint: " "
- アナ: 私の知る限り、これは正しいので、エッジとノードの送信者だけがアクティブになり、全員が使用します。 GraphOps では、12 月末から 1 月初旬までにいくつかのインデクサーをゲートウェイに追加したいと考えています。
Pierre: これで良いですか、それとも元に戻してcollect-receipt-endpointをアクティブ化する必要がありますか?
Pierre: これで良いですか、それとも元に戻してcollect-receipt-endpointをアクティブ化する必要がありますか?
- アナ: ゲートウェイ エンドポイントを使用するのは素晴らしいことです。基本的に、知っておく必要がある唯一のことは、使用する CLI フラグを選択できるということですが、どちらにしても同じエラーが表示され、混乱を招くため、ここでは何もする必要はありません。
アナ: 移行したインデクサーの中には、発見したことについて共有したいコメントはありますか?
- Marc-André |Ellipfra: ダッシュボードの設定と監視は非常に重要です。リリースごとに安定性は増していますが、それはわかりません。
Gustavo: 機能のリクエストや、より適切に構成する方法に関するアイデアがある場合は、お気軽に Indexer-rs リポジトリで問題を提起してください。
私たちは、システムを改善し、テクノロジーをより安定させ、できればより良いレベルに到達できるように、あらゆる問題や機能リクエストを喜んでレビューします。 TAP について詳しく説明していただき、ありがとうございます。
#blockchaindataindex#web3dataanalytics#TheGraph
全てのコメント