Im Kontext von Solana-Archivdaten bezeichnet Indexierung den Prozess, historische Transaktionsdaten zu strukturieren und in einer Datenbank zu organisieren, damit sie schnell und effizient abgerufen werden können. Die meisten Unternehmen, die Produkte auf Solana entwickeln, pflegen Indizes mit Bezug zu ihrem Geschäft, etwa für Stablecoin-Transfers. Bei einem Backfill werden historische Transaktionsdaten von einem beliebigen Zeitpunkt seit dem Genesis-Block von Solana abgerufen, um einen Index aufzubauen. In den meisten Fällen können Entwickler eine RPC-Methode wie getTransactionsForAddress verwenden, um zeitbasierte Filter anzuwenden, die Sortierreihenfolge festzulegen (also chronologisch oder neueste zuerst) und Transaktions-Batches zu paginieren. Für große Backfills können sich Unternehmen an unser Team wenden und verwaltete Backfills anfragen.

Mit Self-Service kannst du Solana-Daten über bestehende RPC-Methoden wie unser erweitertes getTransactionsForAddress selbst auffüllen oder indexieren und in deinem bevorzugten Zielsystem speichern. Verwaltete Backfills sind ein Beta-Angebot, bei dem wir diesen Prozess für dich übernehmen. Anfangs beschränken wir den Zugang zum verwalteten Backfill-Service auf eine begrenzte Zahl von Kunden. So können wir Probleme und gewünschte Zielsysteme für Backfill-Daten besser verstehen, bevor wir ihn als Self-Service-Option anbieten.

Die empfohlene Methode zur Indexierung von Solana-Daten besteht darin, mit der RPC-Methode getTransactionsForAddress sämtliche Solana-Archivdaten abzurufen und in einer Datenbank deiner Wahl zu speichern, etwa PostgreSQL oder einer spaltenorientierten Datenbank wie ClickHouse. Anschließend hältst du deinen Index mit einer Solana-Datenstreaming-Lösung wie LaserStream oder Enhanced WebSockets in Echtzeit aktuell.

Die RPC-Methode getTransactionsForAddress (gTFA) ist eine exklusiv von Helius angebotene Solana-RPC-Methode zum Abfragen von Archivdaten, die getSignaturesForAddress und getTransaction in einem einzigen Aufruf kombiniert. Entwickler können leistungsstarke neue Funktionen nutzen, darunter Rückwärtssuche, zeit-, status- und Slot-basierte Filter sowie Paginierung. Damit lassen sich Batches mit bis zu 100 vollständigen Transaktionen oder 1.000 Signaturen abrufen.

Der neue tokenAccounts-Filter für getTransactionForAddress gibt mit einem einzigen Aufruf alle Transaktionen einer Solana-Adresse zurück – einschließlich aller Transaktionen, an denen die Associated Token Accounts (ATAs) der Adresse beteiligt sind. Zuvor mussten Entwickler getTokenAccountsByOwner und anschließend getSignaturesForAddress für jeden Token-Account abfragen. Das war langsam, teuer und erforderte oft Hunderte zusätzliche RPC-Aufrufe.

Ja. Für einen vollständigen Überblick kannst du mit der Parsed Events API die Historie einer Adresse seitenweise abrufen. Unterstützte Anweisungen werden dabei über mehr als 3.600 Solana-Programme hinweg in benannte Argumente und Accounts dekodiert. Hinzu kommen Details zu Token-Transfers und, sofern unterstützt, Zusammenfassungen in natürlicher Sprache. Wenn keine Dekodierung verfügbar ist, bleiben die Rohdaten der Anweisungen erhalten. Verwende getTransactionsForAddress, wenn du die rohen Transaktions-Payloads benötigst. Mit getTransfersByAddress kannst du außerdem kompakte, geparste Datensätze zu SOL- und Token-Transfers für eine Adresse abrufen.

Um die gesamte Historie einer Solana-Wallet einschließlich all ihrer Associated Token Accounts (ATAs) abzurufen, verwende die RPC-Methode getTransactionsForAddress und setze den tokenAccounts-Filter auf all. Dafür müssen die zurückgegebenen Transaktionen die Adresse der Wallet oder eines Token-Accounts referenzieren, der der Wallet gehört. Weitere Informationen findest du in unserem Leitfaden zum Abrufen der Solana-Token-Historie mit einem einzigen Aufruf.

Wir haben ein komplett neues Solana-Archivsystem von Grund auf entwickelt, um die standardmäßige Google-BigTable-Datenbank zu ersetzen, über die die meisten anderen RPC-Anbieter historische Daten bereitstellen. Unser Index speichert einen Eintrag für jedes eindeutige Paar aus Transaktion und Account. Bis heute umfasst unser Index mehr als 2,3 Billionen Zeilen, in denen zum Zeitpunkt der Veröffentlichung über 450 Milliarden Solana-Transaktionen gespeichert sind. Trotz dieser Größe liegt die P50-Abfragezeit unter Produktionslast bei etwa 8 ms. Außerdem haben wir weitere Indizes für Abfragen nach Slot, Zeit, Status und anderen Kriterien entwickelt. Alle diese Indizes laufen auf eigens entwickelten Bare-Metal-Hosts mit hochmodernen NVMEs im Petabyte-Bereich. Sie werden über mehrere Regionen repliziert und bieten Entwicklern dadurch zuverlässigen, skalierbaren Zugriff auf historische Daten bei niedriger Latenz.

Standardmäßige RPC-Methoden wie getBlock sind langsam und eignen sich nicht für kleine, spezifische Datensätze. Schleifen mit Methoden wie getSignaturesForAddress und getTransaction erfordern viele unnötige RPC-Anfragen, exponentielle Backoffs und Wiederholungslogik. Bislang griffen diese standardmäßigen RPC-Methoden außerdem auf Google BigTable zu, den von den meisten RPC-Anbietern verwendeten Standard-Datenspeicher für Archivdaten. Wir haben unseren eigenen Index von Grund auf entwickelt, um das Speichern, Abrufen und Bereitstellen historischer Daten zu optimieren. Wenn Entwickler die Methode getTransactionsForAddress (gTFA) abfragen, kombinieren sie die Standardmethoden getSignaturesForAddress und getTransaction in einer einzigen Abfrage mit zusätzlichen Optionen für Sortierung, Filterung und Paginierung. Dank unserer benutzerdefinierten Indizes gibt getTransactionsForAddress Entwicklern mehr Kontrolle über ihre Abfragen, vereinfacht Workflows und liefert Daten schneller zurück.