Skip to main content
Die getSignatureStatuses RPC-Methode ermöglicht es Ihnen, den Verarbeitungs- und Bestätigungsstatus einer Liste von Transaktionssignaturen abzurufen. Dies ist nützlich, um festzustellen, ob Transaktionen vom Netzwerk verarbeitet, bestätigt oder abgeschlossen wurden. Es sei denn, die Option searchTransactionHistory ist aktiviert. Diese Methode fragt hauptsächlich einen aktuellen Status-Cache auf dem RPC-Knoten ab. Für ältere Transaktionen ist das Aktivieren von searchTransactionHistory entscheidend.
Vermeiden Sie Batch-Verarbeitung für bessere LeistungBatch-Verarbeitung von Archivierungsmethoden erhöht die Latenz erheblich. Batches mit mehr als 10 Anfragen sind nicht erlaubt.

Häufige Anwendungsfälle

  • Bestätigen der Transaktionsfinalität: Überprüfen, ob eine gesendete Transaktion ein gewünschtes Bestätigungsniveau erreicht hat (z.B. confirmed oder finalized).
  • Batch-Statusabfrage: Effiziente Überprüfung des Status mehrerer Transaktionen auf einmal, z.B. nach einem Batch-Versand.
  • Aktualisierung der Benutzeroberfläche basierend auf dem Transaktionsstatus: Den Echtzeitstatus einer Transaktion für den Benutzer widerspiegeln.
  • Fehlerüberprüfung: Ermitteln, ob eine der Transaktionen in einer Liste fehlgeschlagen ist und warum.

Anfrageparameter

  1. signatures (array von string): (Erforderlich) Ein Array von Base-58-kodierten Transaktionssignaturen. Sie können bis zu 256 Signaturen in einer einzigen Anfrage abfragen.
  2. options (object, optional): Ein optionales Konfigurationsobjekt mit folgendem Feld:
    • searchTransactionHistory (boolean, optional): Wenn true, sucht der RPC-Knoten seine gesamte Transaktionshistorie nach den Signaturen ab. Wenn false (Standard), wird nur ein aktueller Status-Cache durchsucht. Für alte oder möglicherweise gestrichene Transaktionen setzen Sie dies auf true.

Antwortstruktur

Das result-Feld der JSON-RPC-Antwort enthält ein Objekt mit zwei Feldern:
  • context (object): Ein Objekt, das Folgendes enthält:
    • slot (u64): Der Slot, in dem dieser Anfrage vom RPC-Knoten verarbeitet wurde.
  • value (array von object | null): Ein Array von Statusobjekten, entsprechend der Reihenfolge der Signaturen in der Anfrage. Jedes Element kann sein:
    • Ein Objekt mit den folgenden Feldern, wenn die Signatur gefunden wird:
      • slot (u64): Der Slot, in dem die Transaktion verarbeitet wurde.
      • confirmations (number | null): Die Anzahl der Blöcke, die seit der Verarbeitung der Transaktion bestätigt wurden. null, wenn die Transaktion abgeschlossen ist (da Finalität impliziert, dass sie nicht zurückgerollt wird, ist eine spezifische Bestätigungsanzahl weniger relevant).
      • err (object | null): Ein Fehlerobjekt, wenn die Transaktion fehlgeschlagen ist (z.B. {"InstructionError":[0,{"Custom":1}]}), oder null, wenn sie erfolgreich war.
      • status (object): Ein Objekt, das den Ausführungsstatus der Transaktion anzeigt. Normalerweise {"Ok":null} für erfolgreiche Transaktionen oder ein Objekt, das den Fehler bei fehlgeschlagenen Transaktionen detailliert beschreibt.
      • confirmationStatus (string | null): Der Bestätigungsstatus des Clusters für die Transaktion (z.B. processed, confirmed, finalized). Kann null sein, wenn der Status nicht im Cache verfügbar ist und searchTransactionHistory falsch ist.
    • null: Wenn eine Signatur im Status-Cache nicht gefunden wird und searchTransactionHistory false ist (oder auch mit der Verlaufsdurchsuchung wirklich nicht existiert).

Beispiele

1. Status für eine Liste von Signaturen abrufen (Aktueller Cache)

Dieses Beispiel ruft den Status für zwei Signaturen ab und verlässt sich dabei auf den aktuellen Cache des Knotens.

2. Status mit Transaktionsverlaufsdurchsuchung abrufen

Dieses Beispiel ruft den Status für Signaturen ab und fordert den Knoten ausdrücklich auf, seinen Transaktionsverlauf zu durchsuchen.

Entwicklertipps

  • searchTransactionHistory: Entscheidend für die Zuverlässigkeit. Wenn false (Standard), überprüft die Methode nur einen begrenzten aktuellen Cache. Wenn eine Transaktion alt ist oder möglicherweise gestrichen wurde und nicht in diesem Cache ist, wird null für den Status dieser Signatur zurückgegeben. Setzen Sie es immer auf true, wenn Sie den Status von Transaktionen bestätigen müssen, die möglicherweise nicht sehr aktuell sind.
  • Signaturgrenze: Sie können maximal 256 Signaturen pro Anruf abfragen.
  • null Status: Ein null im value Array für eine gegebene Signatur bedeutet, dass ihr Status nicht gefunden wurde. Dies könnte daran liegen, dass sie nicht im aktuellen Cache ist (wenn searchTransactionHistory falsch ist), die Transaktion nie landete oder sie zu alt für die historische Suche des Knotens ist, selbst mit searchTransactionHistory: true.
  • confirmations: null: Dies bedeutet normalerweise, dass die Transaktion den finalized Status erreicht hat. Zu diesem Zeitpunkt ist das Konzept einer spezifischen Anzahl von Bestätigungen weniger relevant, da der Block als unumkehrbar angesehen wird.
  • Fehlerbehandlung: Überprüfen Sie das err Feld innerhalb jedes Statusobjekts, um festzustellen, ob eine Transaktion fehlgeschlagen ist. Das status Feld liefert ebenfalls Details (z.B. {"Err":...}).
Die Verwendung von getSignatureStatuses ist eine effiziente Möglichkeit, den Status mehrerer Solana-Transaktionen zu überwachen. Denken Sie daran, searchTransactionHistory: true für eine robuste Statusüberprüfung zu verwenden.