Zum Hauptinhalt springen
Die RPC-Methode getProgramAccounts ist ein leistungsstarkes Werkzeug für Abfragen auf der Solana-Blockchain. Mit ihr kannst du alle Accounts abrufen, die einem bestimmten On-Chain-Programm gehören. Das ist für viele Anwendungen unverzichtbar: Du kannst damit etwa alle Token-Accounts eines Benutzers für eine bestimmte Token-Mint finden oder alle benutzerspezifischen Daten-Accounts einer dezentralen Anwendung ermitteln. Da ein Programm potenziell sehr viele Accounts besitzen kann, bietet getProgramAccounts umfangreiche Filterfunktionen. Damit kannst du deine Suche eingrenzen und effizient nur die benötigten Daten abrufen. Wenn deine Anwendung sehr große Mengen von Programm-Accounts abfragen muss, solltest du getProgramAccountsV2 verwenden. Die Methode unterstützt cursorbasierte Paginierung mit konfigurierbaren Seitengrößen von bis zu 10.000 Accounts pro request.

Häufige Anwendungsfälle

  • Alle Token-Accounts für eine Mint finden: Ermittle alle Inhaber eines bestimmten SPL-Tokens.
  • Benutzerspezifische Daten abrufen: Rufe alle Accounts ab, die ein Programm für einen bestimmten Benutzer erstellt hat, z. B. die Positionen des Benutzers in einem DeFi-Protokoll oder seinen Spielstand in einem Play-to-Earn-Spiel.
  • Alle Instanzen eines benutzerdefinierten Account-Typs auflisten: Wenn dein Programm eine bestimmte Account-Struktur definiert, kann getProgramAccounts alle Instanzen dieser Struktur finden.
  • Programmstatus überwachen: Beobachte alle Accounts eines Programms, um seinen Gesamtstatus oder seine Aktivität zu verfolgen.
  • Explorer und Analysetools entwickeln: Aggregiere Daten zu Programmen und den zugehörigen Accounts.

Parameter des request

  1. programId (string, erforderlich):
    • Der Base58-codierte öffentliche Schlüssel des Programms, dessen Accounts du abrufen möchtest.
    • Beispiel: "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA" (für das SPL Token Program).
  2. options (object, optional): Ein Konfigurationsobjekt mit den folgenden Feldern:
    • commitment (string): Gibt das commitment-Level an, z. B. "finalized" oder "confirmed".
    • encoding (string): Codierung für das Feld data in jedem zurückgegebenen Account. Der Standardwert ist "base64".
      • "base58": Langsamere Alternative für Binärdaten.
      • "base64": Standardmäßige Base64-Codierung für Binärdaten.
      • "base64+zstd": Base64-codierte, mit zstd komprimierte Binärdaten.
      • "jsonParsed": Wenn der RPC-node einen Parser für den Account-Typ des Programms besitzt, z. B. SPL Token oder Stake, wird das Feld data als strukturiertes JSON-Objekt zurückgegeben. Diese Option wird für bessere Lesbarkeit und einfachere Verwendung dringend empfohlen.
    • filters (array): Ein Array mit Filterobjekten, die auf die Accounts angewendet werden. Das ist für Performance und Relevanz entscheidend. Du kannst bis zu vier Filter verwenden. Häufig verwendete Filter sind:
      • dataSize (object):
        • dataSize (u64): Filtert Accounts nach der Länge ihrer Daten in Byte. Beispiel: { "dataSize": 165 } (für SPL-Token-Accounts).
      • memcmp (object): Speichervergleich. Vergleicht einen Ausschnitt der Account-Daten mit den angegebenen Bytes.
        • offset (usize): Der Byte-Offset in den Account-Daten, an dem der Vergleich beginnt.
        • bytes (string): Eine Base58-codierte Zeichenfolge der abzugleichenden Bytes. Die Bytefolge muss kürzer als 129 Byte sein.
        • Beispiel: Um Token-Accounts für eine bestimmte Mint zu finden, verwendest du memcmp mit offset: 0, wo die Mint-Adresse in einem Token-Account gespeichert ist. Setze bytes auf den öffentlichen Schlüssel der Mint.
    • dataSlice (object): Gibt nur einen bestimmten Ausschnitt der Daten jedes Accounts zurück. Das ist bei großen Accounts nützlich, wenn du nur einen Teil der Daten benötigst.
      • offset (usize): Der Byte-Offset, ab dem der Ausschnitt beginnt.
      • length (usize): Die Anzahl der zurückzugebenden Bytes.
      • Hinweis: dataSlice ist primär für Binärcodierungen vorgesehen, nicht für jsonParsed.
    • withContext (boolean): Wenn der Wert true ist, enthält die response ein RpcResponse-Objekt mit context einschließlich slot sowie value, dem Array der Accounts. Wenn der Wert false ist oder weggelassen wird, enthält die response in der Regel nur das Array der Accounts. Das Verhalten kann je nach RPC-Anbieter leicht variieren.
    • minContextSlot (u64): Der minimale slot, an dem der request ausgewertet werden kann.

Struktur der response

Die response ist ein Array aus Objekten. Jedes Objekt stellt einen gefundenen Account dar und enthält:
  • pubkey (string): Der Base58-codierte öffentliche Schlüssel des Accounts.
  • account (object):
    • lamports (u64): Guthaben des Accounts in Lamports.
    • owner (string): Base58-codierter öffentlicher Schlüssel des Programms, dem dieser Account gehört. Dies entspricht dem abgefragten programId.
    • data (string, array oder object): Die Daten des Accounts, formatiert gemäß dem Parameter encoding.
      • Für jsonParsed: Ein JSON-Objekt, das den deserialisierten Account-Status darstellt.
      • Für base64: Ein Array ["encoded_string", "base64"].
    • executable (boolean): Gibt an, ob der Account ausführbar ist, also selbst ein Programm ist.
    • rentEpoch (u64): Die Epoche, in der für diesen Account das nächste Mal Rent fällig wird.
    • space (u64, optional): Die Datenlänge des Accounts in Byte. Wird manchmal als data.length bezeichnet, wenn die Daten ein Puffer sind, oder ist Teil der geparsten Struktur.
Wenn withContext: true verwendet wird, ist dieses Array im Feld value eines RpcResponse-Objekts verschachtelt.

Beispiele

1. Alle Token-Accounts für eine bestimmte Mint (USDC) finden

Dieses Beispiel findet alle SPL-Token-Accounts, die USDC halten. Es verwendet dataSize, um nach Token-Accounts mit 165 Byte zu filtern, und memcmp, um die USDC-Mint-Adresse am Offset 0 abzugleichen.

2. Alle Token-Accounts einer bestimmten Wallet finden

Dieses Beispiel findet alle SPL-Token-Accounts, die einer bestimmten Wallet-Adresse gehören. Es verwendet dataSize mit 165 Byte und memcmp am Offset 32, an dem der öffentliche Schlüssel des Besitzers in einem Token-Account gespeichert ist.

Erweiterte Filterung

Optimiere deine Abfragen mit Filtern, um die Größe der response zu reduzieren und die Performance zu verbessern:

API Reference

getProgramAccounts

Filtertypen

  • memcmp: Filtert Accounts, die an einem bestimmten Offset einem bestimmten Muster entsprechen
  • dataSize: Filtert Accounts nach ihrer exakten Datengröße
  • Mehrere Filter: Alle Bedingungen müssen erfüllt sein (logisches UND)

Tipps für Entwickler

  • Performance: getProgramAccounts kann auf RPC-nodes viele Ressourcen beanspruchen, besonders ohne Filter oder bei Programmen mit vielen Accounts. Verwende nach Möglichkeit immer Filter wie dataSize und memcmp sowie dataSlice, um den Umfang der Abfrage und die Größe der response zu reduzieren.
  • Große Ergebnismengen: Bei Abfragen mit vielen Ergebnissen kann die response abgeschnitten werden oder ein timeout auftreten. Verwende Filter, um den Umfang zu reduzieren, oder nutze getProgramAccountsV2 für Paginierung.
  • Rate Limits: Beachte die rate limits des RPC-Anbieters. Häufige oder umfangreiche Aufrufe von getProgramAccounts können diese Limits erreichen.
  • Kenntnis des Datenlayouts: Um memcmp effektiv zu nutzen, musst du das Byte-Layout der abgefragten Account-Daten verstehen.
  • Verfügbarkeit von jsonParsed: Die Codierung jsonParsed setzt voraus, dass der RPC-node einen Parser für die Account-Typen des jeweiligen Programms besitzt. Für häufig verwendete Programme wie SPL Token wird sie umfassend unterstützt.
getProgramAccounts ist eine unverzichtbare Methode für Entwickler, die Gruppen von Accounts eines Programms abfragen und mit ihnen interagieren müssen. Wenn du die Filteroptionen sicher beherrschst, kannst du effiziente und robuste Solana-Anwendungen entwickeln.

Paginierung für große Datensätze

Verwende für Anwendungen mit Programmen, die sehr viele Accounts besitzen (über 10.000), getProgramAccountsV2. Die Methode bietet:
  • Cursorbasierte Paginierung: Setze limit auf einen Wert von 1 bis 10.000 und verwende paginationKey, um durch die Ergebnisse zu navigieren
  • Inkrementelle Aktualisierungen: Verwende changedSinceSlot, um nur Accounts abzurufen, die seit einem bestimmten slot geändert wurden
  • Bessere Performance: Verhindert timeouts und reduziert den Speicherverbrauch
  • Paginierungsverhalten: Das Ende der Paginierung wird erst angezeigt, wenn keine Accounts zurückgegeben werden. Aufgrund der Filterung können weniger Accounts als durch das Limit festgelegt zurückgegeben werden. Setze die Paginierung fort, bis paginationKey null ist

Verwandte Methoden

getProgramAccountsV2

Paginierte Version mit cursorbasierter Navigation für große Datensätze