Skip to main content
Beim Erstellen von Anwendungen, die auf On-Chain-Änderungen reagieren müssen, ist das Abfragen von RPC-Endpunkten für Kontoaktualisierungen ineffizient und langsam. Kontoabonnements lösen dies, indem sie in Echtzeit Aktualisierungen über Kontoänderungen direkt an Ihre Anwendung liefern. Dieser Leitfaden behandelt alles, was Sie über Kontoabonnements wissen müssen: was sie sind, wie sie funktionieren und wie Sie sie für Ihren spezifischen Anwendungsfall optimieren können.

Der Kontext des Kontomodells

Überspringen Sie diesen Abschnitt, wenn Sie mit Solana-Konten und ihrer Struktur vertraut sind.
Solana verwendet ein kontobasiertes Modell, bei dem jedes Datenstück in einem Konto lebt - einem Container, der sowohl Daten als auch Metadaten hält. Jedes Konto hat:
  • Daten: Die tatsächlichen Bytes, die den Programmzustand, Token-Salden oder andere Informationen speichern
  • Besitzer: Das Programm, das dieses Konto kontrolliert und seine Daten ändern kann
  • Lamports: Der SOL-Saldo des Kontos für Freistellung von Miete
  • Ausführbar: Ob dieses Konto Programmcode enthält
Programme sind zustandslos - sie speichern keine Daten intern. Stattdessen erstellen und verwalten sie separate Konten, um ihren Zustand zu speichern. Wenn Sie mit einem Programm interagieren, geben Sie die Konten an, von denen es lesen oder schreiben soll. Dieses Design macht Kontoabonnements leistungsstark: Sie können Änderungen an bestimmten Konten überwachen, alle von einem Programm verwalteten Konten oder Konten, die bestimmten Kriterien entsprechen.

Einfaches Kontoabonnement

Beginnen wir mit einem einfachen Beispiel, das sich auf Änderungen in Token-Konten abonniert. Dieses Skript benachrichtigt Sie, wann immer sich Token-Salden ändern:
Wenn Sie dieses grundlegende Abonnement ausführen, sehen Sie Echtzeit-Kontoaktualisierungen, die zu Ihrer Konsole gestreamt werden:
Was ist gerade passiert? Unser Abonnement hat perfekt funktioniert! Wir haben Laserstream gebeten, uns über Änderungen an Token-Konten zu benachrichtigen, und es hat ein Update über Konto BKMHWYLAX4un3HUbR7a3u9jPmzCiLNa4mSj1RiX11eWF geliefert. Dieses Konto hat:
  • 2.039.280 Lamports (~0,002 SOL-Saldo - dies ist der mietfreie Betrag für dieses Token-Konto)
  • Besitzerprogramm TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (dies ist das SPL-Token-Programm)
  • Transaktionssignatur 5C9Hr5nG2j8eQz6inxPmfyjbYdmXddzUDyR1iQgEnjYQ3RNvuP4Zzc8t1enLNy7Rk8KNCtQPEQztENYWxkt9GaVD, die zeigt, welche spezifische Transaktion dieses Konto geändert hat
  • Slot 352366983, der angibt, wann dieses Update auf der Blockchain aufgetreten ist
  • Datenfeld mit 165 Bytes Kontodaten kodiert als base58

Verständnis der Kontofilterung mit datasize

Das Datenfeld ist entscheidend - es enthält die tatsächliche Token-Kontostruktur. Lassen Sie uns dieses Verständnis für ein intelligentes Kontofiltering nutzen.

Warum datasize-Filterung verwenden?

Um zu verstehen, warum wir filtern müssen, lassen Sie uns zuerst verstehen, was Token-Konten tatsächlich sind. Für jedes Token, das eine Wallet hält, gibt es ein separates Konto on-chain. Wenn Ihre Wallet 3 verschiedene Token hält (USDC, BONK und SOL), haben Sie tatsächlich 1 Wallet-Konto (Ihr Haupt-SOL-Konto) plus 3 Token-Konten (eines für jeden Token-Typ). Jedes Token-Konto ist genau 165 Bytes lang und speichert: welches Token es hält (Mint-Adresse), wem es gehört (Ihre Wallet-Adresse) und wie viel von diesem Token es enthält (Menge). Das Token-Programm besitzt Millionen von Konten auf Solana, aber nicht alle sind das, was wir als “Token-Konten” verstehen, die Benutzerbilanzen halten. Hier ist, was mit und ohne Filterung passiert: Ohne Filterung - Die Flut:
Dies abonniert ALLE vom Token-Programm verwalteten Konten, einschließlich:
  • Token-Konten (165 Bytes) - Benutzerbilanzen: Millionen von Konten
  • Mint-Konten (82 Bytes) - Token-Definitionen: Hunderttausende von Konten
  • Multisig-Konten (355 Bytes) - Gemeinsame Wallet-Kontrollen: Zehntausende von Konten
  • Verbundene Token-Programmkonten (verschiedene Größen) - Millionen von Konten
Ergebnis: Ihre Anwendung erhält ständig Millionen von Kontoaktualisierungen, von denen die meisten nicht relevant sind.
Mit intelligentem Filter - Chirurgische Präzision:
Dies filtert nur die 165-Byte-Konten heraus, die speziell die Benutzer-Token-Saldenkonten sind - genau das, was Sie für das Tracking von Token-Transfers, Saldoänderungen und Portfolioaktualisierungen benötigen. Der Unterschied:
  • Ohne Filterung: Millionen von Kontoaktualisierungen (Mint-Erstellungen, Multisig-Änderungen usw.)
  • Mit datasize-Filterung: Nur Token-Saldoänderungen
Das ist eine erhebliche Reduzierung des Geräuschpegels und konzentriert sich nur auf die Konten, die tatsächlich Benutzer-Token-Bestände darstellen.

Woher kommen die 165 Bytes?

Das ist keine Magie - es stammt aus der SPL-Token-Programm-Kontostruktur. Im Quellcode sehen wir, dass die Account-Struktur genau 165 Bytes definiert:
Diese feste Größe erlaubt es uns, präzise nach Standard-Token-Konten zu filtern und auszuschließen:
  • Mint-Konten (82 Bytes)
  • Multisig-Konten (355 Bytes)
  • Verbundene Token-Programmkonten
  • Andere tokenbezogene Konten mit unterschiedlichen Größen
Für die Berechnung der Kontogrößen in anderen Programmen schauen Sie sich die Anchor Space Reference an – sie zeigt Ihnen, wie viel Platz verschiedene Datentypen benötigen (Pubkey = 32 Bytes, u64 = 8 Bytes, etc.).

Dekodierung der Kontostruktur

Jetzt, da wir verstehen, warum wir nach 165 Bytes gefiltert haben, lassen Sie uns dekodieren, was sich in unserem Beispielkonto befindet:
Die 165 Bytes gliedern sich wie folgt:
  • Bytes 0-31: Mint-Adresse (welches Token dieses Konto hält)
  • Bytes 32-63: Eigentümeradresse (wem dieses Token-Konto gehört)
  • Bytes 64-71: Token-Menge (wie viele Token sich im Konto befinden)
  • Bytes 72-164: Zusätzliche Metadaten (Bevollmächtigter, Zustand, Schließberechtigung usw.)
Dieser strukturierte Ansatz gibt uns chirurgische Präzision: wir erhalten nur Updates für Standard-Token-Konten, nicht das Rauschen von anderen Kontotypen.

Kombinieren von Filtern: datasize + memcmp für höchste Genauigkeit

Jetzt, wo wir wissen, dass sich die Mint-Adresse bei Bytes 0-31 befindet, können wir noch spezifischer werden. Angenommen, wir möchten nur USDC-Token-Konten überwachen. Wir können unseren datasize-Filter mit einem memcmp-Filter kombinieren, um die genaue Mint-Adresse zu treffen:
Fortschrittliche Filterstrategie:
  1. Besitzerfilter: „Gib mir Konten, die vom Token-Programm verwaltet werden“ (Millionen von Konten)
  2. Datasize-Filter: „Aber nur 165-Byte-Standard-Token-Konten“ (Hunderttausende)
  3. Memcmp-Filter: „Und nur diejenigen, die USDC halten“ (Tausende)
Dieser Fortschritt von breit zu spezifisch ist der Schlüssel zur effizienten Kontoüberwachung. Jeder Filter schränkt die Ergebnismenge weiter ein, sodass Sie nur die genauen Updates erhalten, die Sie interessieren. Wichtig: Alle Filter verwenden AND-Logik - jede Bedingung muss erfüllt sein, damit ein Konto-Update ausgelöst wird.

Lesen von USDC-Kontoaktualisierungen: Wer, Wie viel, Wo?

Sehen wir uns nun an, was diese gefilterten Updates tatsächlich enthalten. Lassen Sie uns einen USDC-spezifischen Monitor erstellen, der die entscheidenden Fragen beantwortet, wenn sich ein Token-Konto ändert:
  • Wer besitzt dieses Token-Konto?
  • Wie viel USDC enthält es jetzt?
  • Wo (welches spezifische Konto) hat sich geändert?
  • Wann ist diese Änderung aufgetreten?
  • Welche Transaktion hat die Änderung verursacht?
Die rohen Kontoaktualisierungen enthalten Binärdaten, die wir dekodieren müssen. Da Solana base58-Codierung für Adressen und Signaturen verwendet, nutzen wir die bs58.encode()-Funktion, um binäre Buffer-Objekte in lesbare Zeichenfolgen zu konvertieren.
Wenn Sie diesen USDC-Monitor ausführen, sehen Sie saubere, strukturierte Ausgaben wie diese:
Jeder Block stellt ein USDC-Konto dar, das den Zustand geändert hat. Das erste Konto hält nun 1.500 USDC, während das zweite Konto auf 0 USDC geleert wurde. Sie erhalten den aktuellen Saldo sofort nach jeder Transaktion sowie welches spezifische Konto sich geändert hat und wann. Kontoabonnements zeigen Ihnen das Endergebnis dessen, was mit jedem Konto passiert ist, aber nicht die Transaktionsdetails. Wenn Sie den vollständigen Transaktionskontext verstehen müssen (wer an wen gesendet hat, Gebühren usw.), müssen Sie die vollständige Transaktion mit der angezeigten Signatur abrufen.

Komplette Filterreferenz

Neben den Basisfiltern owner, datasize und memcmp, die wir verwendet haben, unterstützen Kontoabonnements zusätzliche Filteroptionen, um Ihre Ergebnisse weiter zu verfeinern:

Spezifische Kontofilterung

Überwachen Sie genaue Konten anhand ihrer öffentlichen Schlüssel:
Dieser Ansatz funktioniert gut, wenn Sie genau wissen, welche Konten für Ihre Anwendung wichtig sind - wie das Überwachen der Tresorkonten Ihrer Anwendung oder bestimmter Benutzerkonten. Für sehr große Konten-Sets werden explizite Pubkey-Listen teuer — 32 Bytes pro Konto in der Abonnementanfrage. Ab etwa ~10.000 Konten verwenden Sie einen komprimierten Cuckoo-Filter (~3–4 Bytes pro Konto), um Hunderttausende von Konten in einem einzigen Stream zu verfolgen. Verfügbar in den Rust- und JavaScript-SDKs.

Kombinierte Filterstrategien

Die Stärke kommt aus der Kombination mehrerer Filtertypen. Hier ist das Grundmodell:
  1. Werfen Sie ein großes Netz mit owner - “Gib mir alle von diesem Programm verwalteten Konten”
  2. Filter nach Struktur mit datasize - “Aber nur Konten dieses speziellen Typs”
  3. Zielspezifische Daten mit memcmp - “Und nur diejenigen mit diesen spezifischen Informationen”
  4. Überwachen Sie bekannte Konten mit account - “Oder überwachen Sie einfach diese genauen Konten, die mir wichtig sind”
Zum Beispiel die Überwachung hochrangiger USDC-Konten:
Der Schlüssel ist, dass jeder Filter das Volumen der erhaltenen Updates reduziert. Ohne Filterung könnten Sie überwältigende Mengen an Kontoaktualisierungen erhalten. Mit intelligenten Filtern erhalten Sie nur die Updates, die für Ihren spezifischen Anwendungsfall relevant sind.

Das größere Bild verstehen

Betrachten Sie Kontoabonnements als das Beobachten eines Live-Feeds von Datenbankänderungen. Der Zustand von Solana ist im Wesentlichen ein massiver Key-Value-Store, bei dem jedes Konto ein Eintrag ist. Wenn Programme ausgeführt werden, ändern sie diese Konten. Ihr Abonnement ermöglicht es Ihnen, spezifische Einträge in Echtzeit ändern zu sehen. Das Filtersystem funktioniert wie Datenbankindizes - Sie beobachten nicht nur “alle Änderungen”, sondern “Änderungen an Konten, die diesen Kriterien entsprechen.” Dies ermöglicht es, reaktionsschnelle Anwendungen zu erstellen, die sofort auf relevante On-Chain-Ereignisse reagieren, ohne Ihr System mit irrelevanten Daten zu überlasten.

Anwendung dieses Musters auf andere Programme

Der Ansatz, den wir gelernt haben, funktioniert für jedes Solana-Programm. Hier ist das allgemeine Muster:
  1. Erforschen der Kontostruktur - Überprüfen Sie den Quellcode oder die Dokumentation des Programms
  2. Beginnen Sie mit der Besitzerfilterung - Ziel ist das Programm, das die Konten verwaltet
  3. Anwenden von Strukturfiltern - Verwenden Sie Kontogröße, Datenmuster oder andere Merkmale, um auf spezifische Kontotypen einzugrenzen
  4. Hinzufügen gezielter Filter - Fokussieren Sie sich auf spezifische Konten, Zustände oder Datenwerte, die für Ihre Anwendung wichtig sind