helius-laserstream SDKを使用したフィルタリング戦略と実践的な実装について説明します。
前提条件: このガイドでは、LaserStream gRPCクイックスタートを完了し、APIキーを取得していることを前提としています。
トランザクションのフィルタリングオプション
LaserStreamは、tokenAccounts(ATA展開)フィルターを含め、Yellowstone gRPCと同じフィルター形式を使用します。transactions.<label>内で設定するフィールドは次のとおりです。
accountInclude— これらのアカウントのいずれかが含まれる場合に一致します(論理OR)accountRequired— これらのアカウントがすべて含まれる場合にのみ一致します(論理AND)accountExclude— これらのアカウントのいずれかが含まれる場合は除外しますvote/failed— 投票トランザクションと失敗したトランザクション用のブールフラグですtokenAccounts— 関連トークンアカウント(ATA)を明示的に展開します("balanceChanged"、"all"、または"none")。これにより、accountIncludeのウォレットがSPLトークン残高を所有しているトランザクションにも一致します。トークンアカウント(ATA)のフィルタリングと、以下のウォレットの監視タブを参照してください。matchMints— アカウントリストをトランザクション前後のトークン残高に含まれるミントとも照合するオプトインフラグです。これにより、accountIncludeに含まれるミントが、そのトークンのすべての転送、スワップ、ミント、バーンに一致します。トークンミントのフィルタリングと、以下のトークンの監視タブを参照してください。
- Program Filtering
- Account-Specific
- Advanced Filtering
- Watching a Wallet
- Watching a Token
特定のプログラムが関係するトランザクションを監視します対象のプログラムに関連するすべてのトランザクションを追跡します。最適な用途: プログラム固有の監視、DeFiプロトコルの追跡、スマートコントラクトとのインタラクション。
実践的な例
例1:DEXトランザクションを監視する
一般的なDEXプログラムに関連するトランザクションを追跡します。例2:失敗したトランザクションを監視する
失敗したトランザクションを追跡して、アプリケーションの問題を明らかにします。例3:高額トランザクションを監視する
大量のSOLが転送されるトランザクションを追跡します。例4:ウォレットを監視する(トークン転送を含む)
単純なaccountIncludeフィルターにtokenAccountsを追加することで、そのウォレットのATAを使用する受信SPLトークン転送を含め、ウォレットの資金を移動するすべてのトランザクションを監視します。
トランザクションのデータ構造
Transaction Message Structure
Transaction Message Structure
Token Balance Changes
Token Balance Changes
Instruction Details
Instruction Details
フィルターロジックのリファレンス
Include Logic (OR)
accountInclude: トランザクションには、これらのアカウントのいずれかが含まれている必要があります。["A", "B"]は、アカウントAまたはアカウントBが関係するトランザクションに一致します。Required Logic (AND)
accountRequired: トランザクションには、これらのアカウントがすべて含まれている必要があります。["A", "B"]は、アカウントAとアカウントBの両方が関係するトランザクションに一致します。Exclude Logic (NOT)
accountExclude: トランザクションには、これらのアカウントが1つも含まれていてはいけません。Combined Logic
最終的なフィルター:
(accountInclude OR empty) AND (accountRequired AND all) AND NOT (accountExclude OR any)。パフォーマンスに関する考慮事項
- Volume Management
- Data Processing
トランザクションストリームは大量のデータを生成する可能性があります。処理を追いつかせるには、次の方法を使用します。
- 特定のプログラムフィルターから始めます(「すべてのトランザクション」を購読しないでください)
- 約1.5秒の追加レイテンシーを許容できる場合は、
processedではなくconfirmedを使用します - カウンターを使用して処理能力を監視します
- キューの背後で並列コンシューマーを実行することを検討します
エラー処理
Too Many Transactions
Too Many Transactions
症状: トランザクション量が多すぎて処理しきれません。解決策: より厳密なフィルター(
accountRequired、accountExclude)を追加します。より高いコミットメントを使用します。サンプリングまたはレート制限を実装します。非同期で処理します。Missing Transactions
Missing Transactions
症状: 想定したトランザクションが表示されません。解決策: プログラムアドレスが正しいことを確認します。トランザクションが実際に存在することを確認します。更新を高速化するには
processedを試します。制限の厳しいaccountRequired/accountExcludeフィルターを緩和します。Parse Errors
Parse Errors
症状: トランザクションデータを解析できません。解決策: 欠落しているフィールドを適切に処理します。処理前に構造を検証します。解析処理をtry/catchでラップします。トランザクションデータのデコードを参照してください。
次のステップ
Slot & Block Monitoring
ネットワークのコンセンサスとブロック生成を追跡します。
Stream Pump AMM Data
実際の例として、Pump.fun AMMトランザクションを監視します。
Decoding Transaction Data
バイナリのトランザクションペイロードを読み取り可能なSolanaトランザクションに解析します。
Yellowstone protocol reference
生のYellowstone gRPCプロトコルに対して同じワークフローを実行します。