Solanaデータのインデックス方法

​

概要

​

これを使用する時

• あなたの製品が高速なフィルタリングクエリを必要としているが、直接のRPCコールが遅すぎる場合（例：ウォレットのトークンアカウントや残高、取引ペアの完全な履歴）
• オンチェーンデータをフィルタリング、集約、結合、またはオフチェーンデータ（CEX価格、KYC、ラベル）と組み合わせる必要がある場合
• PnL、ホルダー分析、またはNFT販売履歴のような事前処理およびクエリ可能なデータが必要な計算を行う場合
• 多くのユーザーにサービスを提供しており、チェーンへのリクエストごとの遅延を許容できない場合

​

Solanaデータのインデックス化とは何ですか？

1. 履歴データのバックフィル: アーカイブRPCメソッドを使用してすべての履歴データをクエリする
2. 新しいデータをストリーム: ネットワークによって確認されたときに新しいブロックを処理する
3. データの解析と変換: 確認済みブロックから関連データを抽出 (例：トランザクション、状態の変化など)
4. データをデータベースに整理: 新しいデータでインデックスを更新する

​

ほとんどの企業がSolanaインデックスを構築する理由

​

ウォレットの例

​

トレーディングの例

​

フィルタリングの例

​

PnLの例

• 特定の期間におけるウォレットに関連するすべてのトランザクションを見つける
• スワップトランザクションをフィルタリングして、買いまたは売りとしてラベルを付ける
• 各スワップでユーザーが支払った手数料を判定する
• 各トレード時点での各トークンの過去価格データを取得する
• 各トランザクションのPnLを集計して、トレーダーの合計PnLを計算する

​

ステップ1: 履歴データを取得する

1. getTransactionsForAddress （推奨）
2. getSignaturesForAddress および getTransaction
3. getBlock

​

方法1: getTransactionsForAddress（推奨）

​

この方法を使用する手順

• 必要なデータの時間範囲を決定し、フィルタを設定する
• transactionDetailsをfullに設定して、すべてのトランザクション詳細を取得する
• 必要に応じて、関連するトークンアカウントトランザクションを含めるようtokenAccountsフィルタを設定する
• paginationTokenを使用して結果をページネーションする
• 各イテレーションで、必要なデータを抽出し、データベースに保存する

​

getTransactionsForAddressを使用する利点

​

方法2: getSignaturesForAddressとgetTransaction

​

この方法を使う手順

• getSignaturesForAddressを呼び出す
• このコールで受け取った最後のトランザクションの署名を保存する
• 次のgetSignaturesForAddressの呼び出しには、この署名をbeforeパラメータに設定する
• 必要に応じてこのままループする
• この方法で取得した各トランザクション署名について、getTransactionを呼び出して、その完全なトランザクション詳細を取得する
• 関連データをデータベースに挿入する

​

この方法の欠点

• 最新のトランザクションから始めて後戻りする
• 各トランザクションに対して追加のRPCを呼び出す
• 同時処理を扱うスレッドセーフなキューを構築する
• データを見逃したりレート制限されないようにリトライとバックオフのためのロジックを構築する
• アドレスが所有する関連トークンアカウントを含むトランザクションは含まない

​

方法3: getBlockを使用

​

この方法を使う手順

• クエリする時間範囲を決定する
• この時間範囲をスロット番号に変換する
• 対応するブロックを順次（順方向か逆方向か）取得する
• 各ブロックでインデックスに関連するトランザクションをフィルタする
• それらからの関連情報をインデックスに保存する

​

ステップ2: Solanaデータをデータベースと同期

​

オプション1: SQLデータベース

​

実装例：

CREATE TABLE token_transfers (
    id BIGSERIAL PRIMARY KEY,
    slot BIGINT NOT NULL,
    timestamp TIMESTAMP NOT NULL,
    signature BYTEA NOT NULL UNIQUE,
    token_mint BYTEA NOT NULL,
    source_address BYTEA NOT NULL,
    destination_address BYTEA NOT NULL,
    amount BIGINT NOT NULL,
    decimals SMALLINT NOT NULL,
    program_id BYTEA
);

CREATE INDEX idx_source_address ON token_transfers (source_address);
CREATE INDEX idx_destination_address ON token_transfers (destination_address);
CREATE INDEX idx_token_mint ON token_transfers (token_mint);

CREATE INDEX idx_large_transfers ON token_transfers(amount) WHERE amount > 1000000;

​

オプション2: 列指向データベース

​

実装例：

CREATE TABLE token_transfers (
    block_time DateTime,
    slot UInt64,
    signature FixedString(64),
    token_mint FixedString(32),
    source_address FixedString(32),
    destination_address FixedString(32),
    amount UInt64,
    decimals UInt8,
    program_id FixedString(32),
    date Date DEFAULT toDate(block_time)
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(date)
ORDER BY (token_mint, date)
SETTINGS index_granularity = 8192;

SELECT date, signature, source_address, destination_address, amount
FROM token_transfers
WHERE token_mint = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v'
AND block_time BETWEEN '2025-01-01' AND '2025-01-31'

​

オプション3: データレイク

​

実装例：

s3://solana_index/token_transfers/YYYY/MM/DD/part-00000.parquet

SELECT block_time, signature, source_address, destination_address, amount
FROM token_transfers
WHERE token_mint = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' AND block_time BETWEEN TIMESTAMP '2025-01-01 00:00:00' AND TIMESTAMP '2025-01-31 23:59:59';

​

インデックスフレームワークの使用

​

主な機能:

• 人気のプログラム（トークンプログラム、DeFiプロトコル、Metaplex）のための事前構築されたデコーダー
• 設定可能なデータソース（RPC, LaserStream, 強化WebSockets）
• バックフィルとリアルタイムストリーミングの両方をサポート
• 複数のストレージバックエンドへの出力（Postgresは標準で提供されます）
• 完全にカスタマイズ可能：独自のデータソース、デコーダー、データシンクをセットアップできます

​

ステップ3: インデックスを最新の状態に保つ

​

方法1: LaserStream（推奨）

• 24時間の履歴再生：インデクサーが切断されても、LaserStreamは切断された場所からすべての未処理トランザクションを自動的に再生します
• 自動再接続：私たちのLaserStream SDK（Rust、Go、JS/TS）はネットワークの中断をシームレスに処理します
• **ノードフ

​

インデックス化におけるLaserStreamの使用方法

• フィルタをできるだけ絞り込む：索引に実際に必要なデータにのみ登録して、帯域幅の消費と必要な処理を最小限に抑える。
• confirmedのコミットメントレベルを使用する：これにより遅延と最終化のバランスが取れます。 processedレベルは信頼性が低すぎ、 finalizedは約13秒の遅延を加えます。
• failed: falseを設定する：失敗したトランザクションを追跡する必要がない場合。
• 投票トランザクションを除外する (vote: false): インデックス化には関連しません。

{
  transactions: {
    "transfers": {
      vote: false,
      failed: false,
      accountsInclude: [
        '​​TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA',
        'TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb'
      ]
    }
  },
  commitment: CommitmentLevel.CONFIRMED,
  accounts: {},
  slots: {},
  transactionsStatus: {},
  blocks: {},
  blocksMeta: {},
  entry: {},
  accountsDataSlice: []
}

​

方法2: LaserStream WebSocketを使用

• アプリケーションが時折のデータギャップを許容できる場合
• リアルタイムアップデートが重要だが、ミッションクリティカルでない場合
• 既存のインフラストラクチャがあり、欠落したデータの検出とバックフィルができる場合
• 予算の制約が大きく、ストリーミングコストを最小限に抑える必要がある場合
• LaserStreamの採用前にプロトタイプまたはテスト中の場合

• 速度：LaserStream WebSocketはLaserStream gRPCと同じバックエンドで動作しますが、WebSocketプロトコルにはJSONフレーミングとメッセージごとのオーバーヘッドがあります。最低遅延を求めるならLaserStream gRPCを使用してください。
• 信頼性：履歴の再生保証はありません。WebSocketが切断された場合、自動で検出し、RPCメソッドを使用して手動でギャップを埋める必要があります。
• 複雑性：データ完全性を保証するために追加の監視インフラストラクチャが必要です。

​

WebSocketsを使ったインデックス化の方法

{
  jsonrpc: '2.0',
  id: 1,
  method: 'transactionSubscribe',
  params: [
    {
      failed: false,
      accountInclude: [
        '​​TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA',
        'TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb'
      ]
    },
    {
      commitment: 'confirmed',
      encoding: 'jsonParsed',
      transactionDetails: 'full',
      maxSupportedTransactionVersion: 0
    }
  ]
}

​

始める

1. 効率的な履歴データの取得
2. データを迅速に取得するための変換と保存
3. インデックス化されたSolanaデータをリアルタイムで更新し続けること

​

補完的オプション

• DAS API ー NFT、代替可能トークン、圧縮資産（メタデータ、所有権、残高、オーナー／コレクション／クリエイターごとのクエリ）をインデックス化せずにクエリします。
• ウォレット API ー ウォレットの残高、履歴、転送、アイデンティティに関する高レベルRESTエンドポイント、USD換算値、シンプルな応答形。

​

次のステップ

• 無料Heliusアカウントに登録してAPIアクセスを取得
• getTransactionsForAddressガイドを読んでバックフィル
• LaserStream概要を探ってリアルタイムストリーミングを実現
• すべてのアーカイブ方法に関する履歴データの概要を確認