Zum Hauptinhalt springen
Wenn du Anwendungen entwickelst, die auf On-Chain-Änderungen reagieren müssen, ist das Abfragen von RPC endpoints nach Konto-Updates ineffizient und langsam. Kontoabonnements lösen dieses Problem, indem sie Updates zu Änderungen des Kontostands in Echtzeit direkt an deine Anwendung senden. Dieser Leitfaden erklärt alles, was du über Kontoabonnements wissen musst: was sie sind, wie sie funktionieren und wie du sie für deinen konkreten Anwendungsfall optimierst.

Kontext zum Kontomodell

Überspringe diesen Abschnitt, wenn du mit Solana-Konten und ihrer Struktur vertraut bist.
Solana verwendet ein kontobasiertes Modell, bei dem alle Daten in einem Konto liegen – einem Container, der sowohl Daten als auch Metadaten enthält. Jedes Konto hat:
  • Daten: Die eigentlichen Bytes, in denen Programmzustand, token-Guthaben oder andere Informationen gespeichert sind
  • Eigentümer: Das Programm, das dieses Konto kontrolliert und seine Daten ändern kann
  • Lamports: Das SOL-Guthaben des Kontos für die Befreiung von der Rent-Gebühr
  • Ausführbar: Gibt an, ob dieses Konto Programmcode enthält
Programme sind zustandslos – sie speichern intern keine Daten. Stattdessen erstellen und verwalten sie separate Konten, um ihren Zustand zu speichern. Wenn du mit einem Programm interagierst, übergibst du die Konten, aus denen es lesen oder in die es schreiben soll. Dieses Design macht Kontoabonnements so leistungsfähig: Du kannst Änderungen an bestimmten Konten, an allen Konten eines Programms oder an Konten überwachen, die bestimmte Kriterien erfüllen.

Einfaches Kontoabonnement

Beginnen wir mit einem einfachen Beispiel, das Änderungen an token-Konten abonniert. Dieses Skript benachrichtigt dich, sobald sich token-Guthaben ändern:
Wenn du dieses einfache Abonnement ausführst, siehst du Konto-Updates in Echtzeit in deiner Konsole:
Was ist gerade passiert? Unser Abonnement hat wie vorgesehen funktioniert. Wir haben Laserstream gebeten, uns über Änderungen an token-Konten zu benachrichtigen, und ein Update zum Konto BKMHWYLAX4un3HUbR7a3u9jPmzCiLNa4mSj1RiX11eWF erhalten. Dieses Konto hat:
  • 2.039.280 Lamports (~0,002 SOL Guthaben – dies ist der Betrag für die Befreiung von der Rent-Gebühr bei diesem token-Konto)
  • Eigentümerprogramm TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (dies ist das SPL Token Program)
  • Transaktionssignatur 5C9Hr5nG2j8eQz6inxPmfyjbYdmXddzUDyR1iQgEnjYQ3RNvuP4Zzc8t1enLNy7Rk8KNCtQPEQztENYWxkt9GaVD zeigt, welche konkrete Transaktion die Änderung dieses Kontos verursacht hat
  • Slot 352366983 gibt an, wann dieses Update auf der Blockchain stattfand
  • Datenfeld enthält 165 Bytes Kontodaten, die als base58 codiert sind

Kontofilterung mit datasize verstehen

Das Datenfeld ist entscheidend – es enthält die eigentliche Struktur des token-Kontos. Nutzen wir dieses Wissen für eine intelligente Kontofilterung.

Warum datasize-Filterung verwenden?

Um zu verstehen, warum wir filtern müssen, sehen wir uns zunächst an, was token-Konten tatsächlich sind. Für jedes token in einer Wallet gibt es ein separates On-Chain-Konto. Wenn deine Wallet drei verschiedene token enthält (USDC, BONK und SOL), hast du tatsächlich ein Wallet-Konto (dein primäres SOL-Konto) sowie drei token-Konten (eines für jeden token-Typ). Jedes token-Konto ist genau 165 Bytes groß und speichert, welches token es enthält (Mint-Adresse), wem es gehört (deine Wallet-Adresse) und wie viel von diesem token es enthält (Betrag). Das Token Program besitzt Millionen von Konten auf Solana. Nicht alle davon sind jedoch das, was wir als „token-Konten“ mit Benutzerguthaben verstehen. Folgendes geschieht mit und ohne Filterung: Ohne Filterung – die Flut:
Damit abonnierst du ALLE Konten des Token Program, darunter:
  • token-Konten (165 Bytes) – Benutzerguthaben: Millionen von Konten
  • Mint-Konten (82 Bytes) – token-Definitionen: Hunderttausende Konten
  • Multisig-Konten (355 Bytes) – gemeinsame Wallet-Kontrollen: Zehntausende Konten
  • Konten des Associated Token Program (verschiedene Größen) – Millionen von Konten
Ergebnis: Deine Anwendung erhält fortlaufend Millionen von Konto-Updates, von denen die meisten für dich irrelevant sind.
Mit intelligenter Filterung – chirurgische Präzision:
Dadurch werden nur die 165 Byte großen Konten berücksichtigt. Dabei handelt es sich speziell um die token-Guthabenkonten der Benutzer – genau das, was du zum Verfolgen von token-Übertragungen, Guthabenänderungen und Portfolio-Updates brauchst. Der Unterschied:
  • Ohne Filterung: Millionen von Konto-Updates (Erstellung von Mints, Multisig-Änderungen usw.)
  • Mit datasize-Filterung: Nur Änderungen an token-Guthaben
Dadurch wird das Rauschen erheblich reduziert. Du konzentrierst dich nur auf die Konten, die tatsächlich token-Bestände von Benutzern darstellen.

Woher kommen die 165 Bytes?

Das ist keine Magie – die Größe ergibt sich aus der Kontostruktur des SPL Token Program. Im Quellcode sehen wir, dass die Struktur Account genau 165 Bytes definiert:
Mit dieser festen Größe können wir Standard-token-Konten präzise filtern und Folgendes ausschließen:
  • Mint-Konten (82 Bytes)
  • Multisig-Konten (355 Bytes)
  • Konten des Associated Token Account Program
  • Andere token-bezogene Konten mit abweichenden Größen
Wenn du Kontogrößen in anderen Programmen berechnen möchtest, sieh dir die Anchor Space Reference an. Dort erfährst du, wie viel Speicherplatz verschiedene Datentypen benötigen (Pubkey = 32 Bytes, u64 = 8 Bytes usw.).

Kontostruktur decodieren

Da wir jetzt wissen, warum wir nach 165 Bytes gefiltert haben, decodieren wir den Inhalt unseres Beispielkontos:
Die 165 Bytes teilen sich wie folgt auf:
  • Bytes 0–31: Mint-Adresse (welches token dieses Konto enthält)
  • Bytes 32–63: Eigentümeradresse (wem dieses token-Konto gehört)
  • Bytes 64–71: token-Betrag (wie viele token sich im Konto befinden)
  • Bytes 72–164: Zusätzliche Metadaten (Delegierter, Zustand, Berechtigung zum Schließen usw.)
Dieser strukturierte Ansatz ermöglicht chirurgische Präzision: Wir erhalten nur Updates für Standard-token-Konten und kein Rauschen von anderen Kontotypen.

Filter kombinieren: datasize + memcmp für höchste Präzision

Da wir jetzt wissen, dass sich die Mint-Adresse in den Bytes 0–31 befindet, können wir noch spezifischer filtern. Nehmen wir an, wir möchten nur USDC-token-Konten überwachen. Wir können unseren Filter datasize mit einem Filter memcmp kombinieren, um gezielt nach der exakten Mint-Adresse zu filtern:
Schrittweise Filterstrategie:
  1. Eigentümerfilter: „Zeige mir Konten des Token Program“ (Millionen von Konten)
  2. Datasize-Filter: „Aber nur Standard-token-Konten mit 165 Bytes“ (Hunderttausende)
  3. Memcmp-Filter: „Und nur solche, die USDC enthalten“ (Tausende)
Diese schrittweise Eingrenzung von breit zu spezifisch ist der Schlüssel für eine effiziente Kontoüberwachung. Jeder Filter grenzt die Ergebnismenge weiter ein, sodass du nur die Updates erhältst, die für dich relevant sind. Wichtig: Alle Filter verwenden eine UND-Logik – jede Bedingung muss erfüllt sein, damit ein Konto-Update ausgelöst wird.

USDC-Konto-Updates lesen: Wer, wie viel, wo?

Sehen wir uns nun an, was diese gefilterten Updates tatsächlich enthalten. Erstellen wir einen USDC-spezifischen Monitor, der bei einer Änderung eines token-Kontos die wichtigsten Fragen beantwortet:
  • Wem gehört dieses token-Konto?
  • Wie viel USDC enthält es jetzt?
  • Wo (welches konkrete Konto) gab es eine Änderung?
  • Wann ist diese Änderung erfolgt?
  • Welche Transaktion hat die Änderung verursacht?
Die Rohdaten der Konto-Updates enthalten Binärdaten, die wir decodieren müssen. Da Solana für Adressen und Signaturen eine base58-Codierung verwendet, konvertieren wir binäre Buffer-Objekte mit der Funktion bs58.encode() in lesbare Strings.
Wenn du diesen USDC-Monitor ausführst, siehst du eine übersichtliche, strukturierte Ausgabe wie diese:
Jeder Block stellt ein USDC-Konto dar, dessen Zustand sich geändert hat. Das erste Konto enthält jetzt 1.500 USDC, während das zweite Konto geleert wurde und nun 0 USDC enthält. Du erhältst den aktuellen Kontostand direkt nach jeder Transaktion sowie Informationen darüber, welches konkrete Konto sich wann geändert hat. Kontoabonnements zeigen dir das Endergebnis der Änderungen an jedem Konto, nicht die Transaktionsdetails. Wenn du den vollständigen Transaktionskontext verstehen musst – etwa wer an wen gesendet hat, welche Gebühren anfielen usw. –, musst du die vollständige Transaktion anhand der angezeigten Signatur abrufen.

Vollständige Filterreferenz

Zusätzlich zu den grundlegenden Filtern owner, datasize und memcmp, die wir verwendet haben, unterstützen Kontoabonnements weitere Filteroptionen, mit denen du deine Ergebnisse noch stärker eingrenzen kannst:

Nach bestimmten Konten filtern

Überwache bestimmte Konten anhand ihrer öffentlichen Schlüssel:
Dieser Ansatz eignet sich gut, wenn du genau weißt, welche Konten für deine Anwendung relevant sind – beispielsweise die Treasury-Konten deiner Anwendung oder bestimmte Benutzerkonten. Bei sehr großen Kontomengen werden explizite pubkey-Listen teuer – 32 Bytes pro Konto im subscribe request. Bei mehr als etwa 10.000 Konten solltest du einen komprimierten Cuckoo-Filter verwenden (~3–4 Bytes pro Konto), um Hunderttausende Konten in einem einzigen stream zu verfolgen. Verfügbar in den SDKs für Rust und JavaScript.

Kombinierte Filterstrategien

Die Stärke liegt in der Kombination mehrerer Filtertypen. Verwende dafür dieses mentale Modell:
  1. Wirf ein weites Netz aus mit owner – „Zeige mir alle Konten, die von diesem Programm verwaltet werden“
  2. Filtere nach Struktur mit datasize – „Aber nur Konten dieses bestimmten Typs“
  3. Filtere nach bestimmten Daten mit memcmp – „Und nur solche, die diese konkreten Informationen enthalten“
  4. Überwache bekannte Konten mit account – „Oder überwache nur genau die Konten, die für mich relevant sind“
Beispiel für die Überwachung wertvoller USDC-Konten:
Die wichtigste Erkenntnis ist, dass jeder Filter die Anzahl der empfangenen Updates reduziert. Ohne Filterung erhältst du möglicherweise eine überwältigende Menge an Konto-Updates. Mit intelligenter Filterung bekommst du nur die Updates, die für deinen konkreten Anwendungsfall relevant sind.

Das Gesamtbild verstehen

Stell dir Kontoabonnements wie einen Live-Feed mit Datenbankänderungen vor. Der Zustand von Solana ist im Wesentlichen ein riesiger Key-Value-Speicher, in dem jedes Konto einen Eintrag darstellt. Wenn Programme ausgeführt werden, ändern sie diese Konten. Mit deinem Abonnement kannst du die Änderungen bestimmter Einträge in Echtzeit verfolgen. Das Filtersystem funktioniert wie Datenbankindizes: Du überwachst nicht einfach „alle Änderungen“, sondern „Änderungen an Konten, die diesen Kriterien entsprechen“. So kannst du reaktionsfähige Anwendungen entwickeln, die sofort auf relevante On-Chain-Ereignisse reagieren, ohne dein System mit irrelevanten Daten zu überlasten.

Dieses Muster auf andere Programme anwenden

Der hier beschriebene Ansatz funktioniert für jedes Solana-Programm. Dies ist das allgemeine Muster:
  1. Recherchiere die Kontostruktur – Prüfe den Quellcode oder die Dokumentation des Programms
  2. Beginne mit der Eigentümerfilterung – Wähle das Programm aus, das die Konten verwaltet
  3. Wende Strukturfilter an – Verwende Kontogröße, Datenmuster oder andere Merkmale, um auf bestimmte Kontotypen einzugrenzen
  4. Füge gezielte Filter hinzu – Konzentriere dich auf bestimmte Konten, Zustände oder Datenwerte, die für deine Anwendung relevant sind