
getTransactionsForAddress und bis zu 10-mal schnellere Archivdaten
Inhaltsverzeichnis
getTransactionsForAddress (gTFA) ist eine neue Solana RPC-Methode zum Abfragen historischer Daten. Sie kombiniert getSignaturesForAddress und getTransaction in einem einzigen Aufruf und bietet leistungsstarke neue Funktionen wie Rückwärtssuche, zeit-, status- und slotbasierte Filter sowie Paginierung.
Bisher mussten Entwickler zum Backfilling und Abfragen historischer Daten auf Solana langsame, teure Methoden wie getBlock verwenden oder mit getSignaturesForAddress und getTransaction über Signatur-Batches iterieren.
Jetzt können Entwickler mit einem einzigen Aufruf und leistungsstarken Filter- und Sortieroptionen bis zu 100 Datensätze mit vollständigen Transaktionsdetails oder bis zu 1.000 Datensätze nur mit Signaturen abfragen.
Herausforderungen beim Abfragen historischer Daten auf Solana
Das Ledger von Solana enthält jede Transaktion, die jemals on-chain gesendet wurde. Diese historischen Daten umfassen jeden Mint, Transfer, Swap und jede Programminteraktion seit der Genesis.
Bis heute hat Solana mehr als 375 Millionen Blöcke erzeugt. Der vollständige, ungekürzte Transaktionsverlauf vom Genesis-Block bis heute umfasst Hunderte Terabyte.
Ein schneller und zuverlässiger Zugriff auf diese Daten ist für praktisch jedes Team unverzichtbar, das heute auf Solana entwickelt. Die Archivmethoden von Solana bilden die Grundlage für alles – vom Tab mit dem Transaktionsverlauf in deinem bevorzugten Wallet bis zu deinem bevorzugten Explorer und Portfolio-Dashboard.
Bisher hatten Entwickler nur zwei Möglichkeiten, Archivdaten abzufragen – und beide sind mühsam:
getBlockgetSignaturesForAddressplusgetTransaction
getBlock ist zu langsam
Zunächst könnten Entwickler versuchen, Daten über getBlock nachzuladen. Das ist zwar möglich, aber unnötig zeitaufwendig, teuer und ressourcenintensiv:
- Rufe
getBlocksauf, um bestätigte Blöcke in deinem Slot-Bereich zu finden - Rufe
getBlockfür jeden Block auf, um vollständige Transaktionsdetails, Signaturen oder Accounts abzurufen - Parse alle relevanten Daten aus dem Block und speichere sie in deiner Datenbank
- Wiederhole den Vorgang, bis alle Blöcke vollständig verarbeitet sind
Die Methode getBlock funktioniert gut für stark frequentierte Programme, etwa beim Indexieren beliebter Token wie USDC oder von Solana-Programmen wie Pump.fun. Für kleine, spezifische Datensätze ist sie jedoch unpraktisch.
Schleifen mit getSignaturesForAddress und getTransaction
Eine weitere gängige Methode zum Nachladen von Daten ist die gemeinsame Verwendung von getSignaturesForAddress (gSFA) und getTransaction.
Dieser „N+1-Schleifen“-Ansatz ruft wiederholt Transaktionssignaturen ab, normalerweise jeweils 1.000, und verwendet anschließend RPC-Batch-Aufrufe, um die Details jeder Transaktion abzurufen.
Aufgrund der enormen Anzahl an RPC-Anfragen müssen Entwickler exponentielle Backoffs und eine Wiederholungslogik implementieren, damit sie keine Rate Limits überschreiten und keine Daten verpassen.
gSFA und getTransaction sind zwar flexibler als getBlock, aber im großen Maßstab weiterhin teuer, kompliziert und fehleranfällig.
Vorteile von getTransactionForAddress
Die neue RPC-Methode getTransactionsForAddress kombiniert getSignaturesForAddress und getTransaction in einem einzigen Aufruf. Leistungsstarke Funktionen machen das Erstellen von Indizes und Abfragen historischer Daten einfacher und schneller.
Das sind die wichtigsten Funktionen:
1. Rückwärtssuche
Bei bestehenden Archiv-RPC-Methoden wie gSFA mussten Entwickler mit der neuesten Transaktion beginnen und rückwärts arbeiten.
Mit getTransactionForAddress können Entwickler jetzt zwischen einer aufsteigenden (also chronologisch, älteste zuerst) und einer absteigenden Sortierung (also neueste zuerst) wählen.
In Kombination mit zeitbasierten Filtern können Entwickler getTransactionForAddress verwenden, um jeden Abschnitt der Solana-Historie ab einem beliebigen Zeitpunkt und in beliebiger Reihenfolge abzufragen.
Zum Beispiel verwendet Orb, unser neuer Solana-Block-Explorer, die RPC-Methode getTransactionsForAddress für den Filter „Älteste zuerst anzeigen“:
Wenn du dieselben Daten mit getSignaturesForAddress und getTransaction abfragen wolltest, müsstest du:
- Den exakten Zeitstempel der ersten Transaktion finden
- Die zu deinem Startdatum gehörende Transaktionssignatur finden
- Mit
before: lastSignatureab dieser Signatur rückwärts iterieren - Die Schleife fortsetzen, bis
blockTimeder zurückgegebenen Signaturen das Enddatum erreicht - Backoff- und Wiederholungslogik schreiben, damit du keine Rate Limits überschreitest und keine Daten verpasst
Dieser Prozess ist nicht nur langsam bei der Abfrage, sondern auch frustrierend einzurichten und fehleranfällig.
2. Erweiterte Filter
Mit der neuen Methode getTransactionsForAddress können Entwickler nach Zeitraum (also Unix-Zeitstempel), Slot und Status (z. B. erfolgreich oder fehlgeschlagen) filtern. Diese Filter geben dir eine präzisere, granulare Kontrolle, damit du genau die benötigten Daten abfragen kannst.
Dieser zeitbasierte Filter verwendet beispielsweise Unix-Zeitstempel, um alle erfolgreichen Transaktionen abzurufen, die zwischen dem 1. Januar 2025 um 00:00 Uhr (GMT) und dem 1. Oktober 2025 um 00:00 Uhr (GMT) stattgefunden haben.
// Time range with successful transactions only
"filters": {
"blockTime": {
"gte": 1767225600,
"lte": 1759363200
},
"status": "succeeded"
}3. Cursor-basierte Paginierung
Wenn du mehr Transaktionen abfragen musst, als die Standardlimits von gTFA erlauben (1.000 Signaturen oder 100 Datensätze mit vollständigen Transaktionsdetails), kannst du paginationToken aus der Antwort verwenden, um die nächste Seite abzurufen. paginationToken ist ein einfacher String im Format "slot:position", der der API mitteilt, wo sie fortfahren soll.
Diese Abfrage verwendet beispielsweise paginationToken (einen Cursor), um den Verlauf der Adressen in Batches von 100 zu durchsuchen.
// First request
let paginationToken = null;
let allTransactions = [];
const getNextPage = async (paginationToken = null) => {
const params = [
'ADDRESS',
{
transactionDetails: 'signatures',
limit: 100,
...(paginationToken && { paginationToken })
}
];
const response = await fetch(rpcUrl, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'getTransactionsForAddress',
params
})
});
const data = await response.json();
return data.result;
};
// Paginate through all results
do {
const result = await getNextPage(paginationToken);
allTransactions.push(...result.data);
paginationToken = result.paginationToken;
console.log(`Fetched ${result.data.length} transactions, total: ${allTransactions.length}`);
} while (paginationToken);
Neues Solana-Archivsystem
Zusätzlich zur neuen Methode getTransactionsForAddress haben wir ein komplett neues Archivsystem veröffentlicht. Wir haben es von Grund auf neu entwickelt, um die Router- und Speicherpfade des Archivs zu optimieren.
Das neue System ist für alle Solana-Archiv-RPC-Methoden aktiviert (z. B. getTransaction, getBlock, getInflationReward) und steht Nutzern in allen kostenlosen und kostenpflichtigen Tarifen zur Verfügung.
Das bedeutet: Jede Archivmethode ist jetzt in jedem Tarif 2- bis 10-mal schneller – mit geringerer Latenz, besserer Performance und ohne notwendige Codeänderungen.
Jetzt starten
Die RPC-Methode getTransactionsForAddress ist ab heute öffentlich in allen kostenpflichtigen Tarifen verfügbar und kann mit deiner bestehenden Helius RPC-URL verwendet werden. Die gTFA-Methode kostet 100 Credits pro Aufruf und gehört zu deiner RPC-Rate-Limit-Gruppe.
Lies die API-Referenz und folge unserer Kurzanleitung für getTransactionsForAddress, um zu erfahren, wie die Methode funktioniert, und direkt loszulegen.
Ähnliche Artikel
Helius abonnieren
Bleib bei der Solana-Entwicklung auf dem Laufenden und erhalte Updates, wenn wir neue Beiträge veröffentlichen


