メインコンテンツへスキップ
getAccountInfo RPCメソッドは、Solanaブロックチェーンをクエリするための基本的なツールです。特定のアカウント公開鍵に関連付けられたすべての保存情報を取得できます。これには、アカウントのランポート残高、それを所有するプログラム、実行可能かどうか、および保存されたデータが含まれます。

一般的な使用例

  • SOLのバランス確認: 任意のアカウントのネイティブSOLバランスを確認します。
  • アカウントの存在確認: 指定された公開鍵を持つアカウントが初期化されているかどうか(ランポートやデータがあるか)を確認します。
  • プログラムアカウントの調査: プログラムが所有するアカウント内に保存されたデータを取得し、プログラムの状態を理解するために重要です。
  • アカウントの所有者の特定: アカウントの所有者であるプログラムを確認します。これにより、アカウントのデータをどのように解釈するか、またはシステム所有のアカウントかどうかが判断できます。
  • アカウントが実行可能かどうかの確認: アカウントにデプロイされたプログラムが含まれているかを識別します。

パラメータ

  1. publicKey (文字列、必須): クエリするアカウントのbase-58エンコードされた公開鍵。
  2. config (オブジェクト、省略可能): 次のフィールドを持つ構成オブジェクト:
  • commitment (文字列、省略可能): クエリに使用するコミットメントレベルを指定します。デフォルトはfinalizedです。
  • finalized: クラスターのスーパー多数によって最大ロックアウトに達したと確認される最新のブロックをクエリします。
  • confirmed: クラスターのスーパー多数によって投票された最新のブロックをクエリします。
  • processed: ノードの最新のブロックをクエリします。ただし、ブロックが完成していない可能性があります。
  • encoding (文字列、省略可能): アカウントデータのエンコーディング。デフォルトはbase64です。
  • base58 (遅い)
  • base64
  • base64+zstd (データが圧縮されている場合)
  • jsonParsed: アカウントデータが既知のプログラム状態(例: トークンアカウント、ステークアカウント)の場合、ノードはそれをJSON構造に解析しようとします。一般的なプログラムアカウントの場合、通常はバイナリ(base64)に戻ります。
  • dataSlice (オブジェクト、省略可能): 特定のスライスに返されたアカウントデータを制限します。base58base64、またはbase64+zstdエンコードの場合のみ利用可能です。
  • offset (番号): アカウントデータの先頭からスライスを開始するバイト数。
  • length (番号): 返されるバイト数。
  • minContextSlot (番号、省略可能): リクエストが評価される最小スロット。

レスポンス

アカウントが見つかった場合、resultフィールドには、2つの主なプロパティを含むオブジェクトが含まれます。
  • context (オブジェクト): リクエストに関するメタデータが含まれます。
  • slot (番号): 情報が取得されたスロット。
  • apiVersion (文字列、省略可能): RPC APIバージョン。
  • value (オブジェクト | null): アカウントが存在しない場合、これはnullになります。それ以外の場合、それには次の情報を含むオブジェクトになります。
  • lamports (番号): アカウントが所有するランポート数 (1 SOL = 1,000,000,000ランポート)。
  • owner (文字列): このアカウントを所有するプログラムのbase-58エンコードされた公開鍵。
  • data (配列 | オブジェクト | 文字列): アカウントに保存されているデータ。使用されたencodingパラメータに応じて形式が異なる。
  • base64(デフォルト)、base58base64+zstdの場合:通常は配列[encoded_string, encoding_format]、例: ["string_data", "base64"]
  • jsonParsedの場合:データがRPCノードによって解析される場合、JSONオブジェクトになることがあります(例: SPLトークンアカウント)。それ以外の場合、既知のレイアウトとして認識されない場合、["", "base64"]または同様のものに戻ることがあります。
  • executable (ブーリアン): アカウントにプログラムが含まれている場合true、そうでない場合false
  • rentEpoch (番号): このアカウントが次のエポックで賃貸料を負う予定の時期。
  • space (番号、省略可能): データのバイト数(注意: 公式Solanaドキュメントに記載されているspaceですが、一部のRPCプロバイダーはこれを含むことがあります。これはアカウントのデータに割り当てられた総スペースを表します)。アカウントデータとデシリアライズに関する詳細については、詳細ガイドを参照してください。
アカウントが見つからない場合、結果のvalueフィールドはnullになります。

例: アカウント情報の取得

メインネット上のSerum Program V3 ID (9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin)の情報を取得しましょう。 注: 下記の例ではYOUR_API_KEYを実際のHelius APIキーで置き換えてください。

開発者のヒント

  • パフォーマンス: 複数のアカウントの頻繁なチェックを必要とするアプリケーションには、getMultipleAccountsを使用してリクエストをバッチ化し、往復回数を減らすことを検討してください。
  • データのデシリアライズ: dataフィールドは、しばしば所有プログラムのデータ構造に基づいてデシリアライズが必要です。プログラムに特化したツールとライブラリ(例: トークンアカウント用のSPLトークンライブラリ)が通常必要です。私たちのアカウントデータのデシリアライズに関するブログ記事には、役立つ技術と例があります。
  • レート制限: 多数のアカウントをクエリする場合や頻繁にリクエストを行う場合は、RPCノードのレート制限に注意してください。
  • コスト管理: getAccountInfoは一般に低コストのクエリですが、頻繁なポーリングは積み重なる可能性があります。クエリパターンを最適化してください。
  • jsonParsedの利点: jsonParsedは便利ですが、すべてのアカウントタイプをサポートしない可能性があり、プログラムがそのデータ構造を更新すると出力が変わる可能性があります。重要なアプリケーションには、既知のレイアウトによるバイナリデータの解析がより安定しています。
  • dataSliceを検討: アカウントのデータの一部のみが必要な場合、dataSliceを使用して転送データ量を削減し、クエリコストを低下させる可能性があります。

関連メソッド

getMultipleAccounts

より良いパフォーマンスのために一度に複数のアカウントをバッチフェッチする

getBalance

アカウントの詳細なしでSOLバランスだけを取得する