カストディアル Avalanche 製品、財務管理ツール、マルチウォレット ポートフォリオ サービスはすべて同じデータ問題を抱えています。製品は、追跡するすべての顧客アドレスの AVAX 残高と ERC-20 トークン保有量を必要とし、決定論的なレポートのために特定のブロック高に固定され、UI が古くなることがないようにクロックで更新され、Avalanche アーカイブ ノードを運用することなく、また繰り返しポーリングの呼び出しごとに料金を支払うことなく、数千のアドレスにわたって必要です。この記事では、Avalanche アドレス残高クエリ パターン、スナップショットを再現可能にするブロック高固定手順、ほとんどの繰り返しポーリングのコストをほぼゼロに削減するキャッシュ動作、単一アドレスとバッチ処理のトレードオフ、および自己ホスト型の Avalanche アーカイブ ノードとインデクサーとの購入と構築の比較について説明します。これは、カストディアン向けの Cardano ポーリング ガイドの Avalanche 版です。同じパターンですが、チェーンとスキーマ 名前空間が異なります。 ## 固定ブロック高での Avalanche 残高クエリ カストディアル Avalanche 製品に必要なクエリは、選択したブロック高に固定された 1 つのアドレスの AVAX 残高とすべての ERC-20 保有トークンを返します。Bitquery GraphQL IDE でブロック高での Avalanche 残高クエリを開いて、任意のアドレスに対して実行および変更します。is: アドレスを任意の Avalanche ウォレットに置き換えます。height 値をスナップショットを固定する任意のブロックに置き換えます。レスポンスは 2 つの部分から構成されます。blocks フィールドは、選択した高さが存在することを確認し、そのブロックのウォールクロック タイムスタンプを返します。これは、ユーザー向けレポートのスナップショットの「as of」スタンプになります。address.balances フィールドは、固定された高さ以前またはそれ以前にアドレスが保持していた AVAX ポジションとすべての ERC-20 トークンを返します。これには、コントラクト アドレス、シンボル、小数点、トークン スタンダードが含まれます。4 つのフィールドが、ほぼすべてのカストディアル Avalanche UI を駆動します。balances.valuepercurrencyは、ウォレット内の AVAX とすべての ERC-20 を対象としています。currency.addressはトークンのコントラクト アドレスであり、サポートされている資産の内部ホワイトリストに対する結合キーです。currency.decimalsは、人間が読みやすい表示のための除数です。blocks.timestamp.timeはスナップショットの経過時間であり、UI の残高の横に表示されるため、ユーザーはその数値がいつ取得されたかを知ることができます。## ブロックの高さでアンカーすることが重要な理由 高さが固定されていない残高クエリは、最新のインデックス値を返します。その数値は、1 秒間隔で行われた 2 つの呼び出しの間で変化しますが、これはライブ ビューには適していますが、レポートには役に立ちません。height: {lteq: 60000000}を指定したバランス クエリは、決定論的な値を返します。同じアドレスと高さのペアは、常に同じ数値を返します。決定論によって、2 つのことが実現します。まず、再現可能なレポートが実現します。先週の金曜日の保有分について明日生成されるステートメントは、先週の金曜日の保有分について今日生成されるステートメントと一致する必要があります。高さを固定することで、これが保証されます。次に、キャッシュの再利用が実現します。これについては後述します。指定されたターゲット ウォールクロック タイムの適切なブロックを選択するには、パターンの 2 番目のクエリは、Bitquery GraphQL IDE の Avalanche block-before-timestamp クエリです。tillをターゲット タイムスタンプに設定し、その時刻以前の最後のブロックのブロック高さを取得します。その高さを上記の balances クエリに渡します。この 2 つの呼び出しにより、製品がレポートする必要のある任意の履歴タイムスタンプのバランス スナップショットが生成されます。## ファンアウト用のバッチ バリアント 単一アドレス クエリは、ユーザーごとのウォレット ビューで機能します。更新サイクルで数千のアドレスをポーリングするカストディアンは、バッチ処理バージョンを必要とします。addressフィルタはリストを受け入れます。ほとんどのカストディアンは、50 ～ 100 のバッチに落ち着きます。バッチが小さいほど、ウォールクロック並列性が高くなり、アドレスごとに最新の結果が得られます。バッチが大きいほど、応答ごとのレイテンシが高くなるという代償で、リクエスト数が減少します。適切な数は、製品が管理するアドレスの数と、ポーリング レイヤーの同時実行性によって異なります。## キャッシュによって繰り返しポーリングがゼロ コストの読み取りに変わる方法 カストディアンのワークロードは、繰り返し処理が中心です。同じ顧客アドレスが、更新サイクルごと、ページ読み込みごと、調整パスごとにポーリングされます。Bitquery は、(address, height)キャッシュ キーごとに応答をキャッシュし、キャッシュされたスナップショットを次の呼び出し元に返します。キャッシュされた応答は、API ポイントを消費しません。 C-Chain 上でブロックが確定すると、その確定した高さにおける任意のアドレスのbalances(height: {lteq: … })に対する答えは永久に固定されます。同じ質問をする後続の呼び出し元はすべて同じキャッシュされたバイトを取得します。最初の呼び出しでポイントが支払われます。リプレイはキャッシュにヒットします。固定された履歴高さに対する調整は、ほぼ完全にキャッシュから解決されます。監査、カスタマー サポート、およびユーザー ダッシュボードによってポーリングされる同じ日末スナップショットは、同じキャッシュ キーに収束します。月末および四半期末のレポートは、レポートが再生成されるたびに同じ高さのセットに対して実行されます。再実行はキャッシュにヒットします。これが Bitquery と独自のアーカイブ ノードに対して生の RPC を実行することとの間の最大の経済的な違いです。生の RPC には、呼び出し元間で共有されるキャッシュ レイヤーがありません。すべての呼び出しはノードをたどります。Bitquery は、同じ質問をするすべての呼び出し元間で同じアドレスの読み取りを償却します。## スケーリング プロファイル 上記のパターンは、典型的なカストディアルまたはトレジャリーのワークロードを示しています。ほとんどの製品では、1 日あたりアドレスごとに 1 つのスナップショットがケイデンスであり、ウォレットの詳細ページにはオプションでより頻繁なライブ ポーリングが可能です。アドレス数が増加しても、キャッシュ ヒット率は維持されます。すべてのアドレスは独自のキャッシュ キーです。数万のアドレスを管理する製品のアドレスごとの経済性は、数千のアドレスを管理する製品と同じです。ポーリング ケイデンスは、コストと鮮度の主なレバーです。毎日ではなく 15 分ごとにポーリングすると、リクエスト カウントが 96 倍になります。Avalanche の残高は、送金がアドレスに触れたときにのみ変更されるため、この増加のほとんどはキャッシュから解決されます。アドレスごとに完全なbalancesリストを返すと、ウォレットがこれまで保持したすべてのトークンが含まれます。数百の低キャップトークンを保持するアドレスは、AVAX のみのウォレットよりもシリアル化にコストがかかります。製品が厳選された資産リストのみを表示する場合は、クライアント側でcurrency.addressをフィルタリングするか、クエリで設定された既知の資産アドレスでフィルタリングします。## Bitquery とセルフホスト型 Avalanche Archive ノードおよびインデクサー 自然な代替案は、カスタム Erigon 構成や The Graph のようなホスト型スタックなどの EVM インデクサーと並行して Avalanche アーカイブ ノードを実行することです。これは一部のチームにとっては正当な選択肢です。ほとんどのカストディアンや財務製品にとっては間違った選択肢です。アーカイブ ノードの利点は、プライベート クエリの 50 ミリ秒未満のレイテンシ、実行レイヤーの状態スキーマの完全な制御、および Bitquery が公開しない分析クエリを実行できることです。アーカイブ ノードに反対する理由は、それ以外のすべてです。運用上、Avalanche アーカイブ ノード フリートを運用するということは、コンセンサス クライアントのアップグレードごとに、失われたエンジニアリング タイムのコストを支払うことを意味します。ステート プルーニングはデリケートです。ディスクは継続的に増加します。監視、バックアップ、フェイルオーバーはチームの問題です。これらは Avalanche に特有のものではありません。コストは、チームが構築している他のものに加えて支払う必要があります。## これをカストディアル Avalanche バックエンドに接続する 一般的なカストディアル統合では、4 つのコンポーネントを使用します。タイムスタンプから高さへのリゾルバは、スナップショット間隔ごとに 1 回、タイムスタンプ前のブロック クエリを実行し、高さのマッピングをキャッシュします。バッチ処理された残高フェッチャーは、顧客アドレスのバッチごとに、解決された高さに対してバッチ処理されたaddress: {in: [… ]}` バリアントを実行します。出力は、AVAX およびサポートされている ERC-20 セットをカバーするアドレスごとのレコードに解析されます。調整ジョブは、同じクエリを同じ高さに対してより遅い頻度 (週単位) で実行し、ポーリングされたスナップショットをカストディアンの内部台帳と比較します。履歴ステートメント ジェネレータは、同じ 2 つのクエリを再利用して、任意の過去の期間のステートメントを生成します。クエリは高さに固定されるため、ステートメントは再実行間で再現可能です。Avalanche C-Chain の残高は、送金がアドレスに触れるたびに変化します。これは、活発に取引されているウォレットでは 1 分に何度も発生する可能性があります。5 分ごとにポーリングすることは、活発な取引製品には理にかなっています。コールド ストレージ トレジャリーで 5 分ごとにポーリングすることは理にかなっていません。ほとんどのカストディアンは、アクティブなウォレットについては1分ごとまたは15分ごと、それ以外のウォレットについては1時間ごとまたは1日ごとに料金を設定しています。## 要約 数千の顧客アドレスからAVAXおよびERC-20残高をポーリングするカストディアルAvalanche製品には、3つの選択肢があります。Avalancheアーカイブノードとインデクサースタックを構築して運用する。呼び出しごとにRPCプロバイダーに料金を支払う。または、ブロック高アンカーパターンを使用してBitqueryのキャッシュされたGraphQLレイヤーを使用し、ワークロードの大部分を占める繰り返しトラフィックに対してGraphQLポイントをゼロに支払う。3番目のオプションが存在するのは、繰り返しパターンがカストディアン、財務ツール、ポートフォリオ製品全体で非常に普遍的であるためです。この記事の2つのクエリは、これらの製品が収束する標準的なクエリ形式です。[Bitquery]