Skip to main content
Die isBlockhashValid RPC-Methode überprüft, ob ein zuvor erhaltener Blockhash vom Netzwerk noch als gültig angesehen wird. Blockhashes haben eine begrenzte Lebensdauer (etwa 2 Minuten oder 150 Blöcke), nach deren Ablauf Transaktionen, die auf sie verweisen, abgelehnt werden. Diese Methode ist entscheidend für Anwendungen, die Blockhashes eine Zeitlang halten, bevor sie eine Transaktion einreichen, um sicherzustellen, dass die Transaktion nicht aufgrund eines abgelaufenen Blockhashes fehlschlägt. Versionshinweis: Diese Methode ist ab solana-core v1.9 verfügbar. Für Knoten, die solana-core v1.8 oder älter ausführen, sollten Sie getFeeCalculatorForBlockhash verwenden, das zusätzlich zu den Gebühreninformationen auch implizit die Gültigkeit von Blockhashes anzeigt (es wird einen Fehler ausgeben, wenn der Blockhash zu alt ist).

Häufige Anwendungsfälle

  • Transaktionswiederholungsversuch: Prüfen Sie, bevor Sie eine fehlgeschlagene Transaktion erneut versuchen, ob der ursprüngliche Blockhash noch gültig ist. Wenn nicht, muss ein neuer Blockhash abgerufen werden.
  • Verzögerte Transaktionssignierung: Wenn eine Transaktion vorbereitet, aber später signiert und eingereicht wird, überprüfen Sie die Gültigkeit des Blockhashes unmittelbar vor der Einreichung.
  • Optimistische Transaktionsverarbeitung: Bestimmen Sie, ob ein Blockhash wahrscheinlich vom Netzwerk akzeptiert wird, wenn eine Transaktion sofort gesendet wird.

Anforderungsparameter

  1. blockhash (string, erforderlich): Der zu überprüfende Blockhash, als base-58 kodierter String.
  2. options (object, optional): Ein optionales Konfigurationsobjekt, das Folgendes enthalten kann:
    • commitment (string, optional): Gibt die Commitment-Stufe für die Abfrage an (z. B. "finalized", "confirmed", "processed"). Wenn nicht angegeben, wird das Standard-Commitment des Knotens verwendet.
    • minContextSlot (u64, optional): Der minimale Slot, in dem die Anforderung ausgewertet werden kann. Dies stellt sicher, dass der RPC-Knoten nicht mit einem Status aus einem älteren Slot antwortet als dem minContextSlot.

Antwortstruktur

Das result-Feld in der JSON-RPC-Antwort ist ein RpcResponse-Objekt, das enthält:
  • context (object): Ein Objekt, das enthält:
    • slot (u64): Der Slot, bei dem der RPC-Knoten die Gültigkeit des Blockhashes überprüft hat.
  • value (boolean): true, wenn der Blockhash noch gültig ist, andernfalls false.
Beispielantwort (Gültiger Blockhash):
Beispielantwort (Ungültiger/Abgelaufener Blockhash):

Codebeispiele

Entwicklertipps

  • Blockhashes laufen ab: Blockhashes sind nur für eine begrenzte Zeit gültig (ca. 150 Slots oder ungefähr 1-2 Minuten). Holen Sie immer einen frischen Blockhash ein, wenn Sie unsicher sind oder wenn viel Zeit vergangen ist.
  • minContextSlot Nutzung: Verwenden Sie minContextSlot, um sich vor einer Abfrage eines veralteten RPC-Knotens zu schützen, der möglicherweise eine veraltete “gültige” Antwort für einen Blockhash gibt, der aus der Perspektive des restlichen Clusters tatsächlich zu alt ist.
  • Alternative für ältere Knoten: Für Knoten, die Solana-Versionen vor 1.9 ausführen, verwenden Sie getFeeCalculatorForBlockhash("<YOUR_BLOCKHASH>"). Wenn diese Methode erfolgreich zurückkehrt, ist der Blockhash gültig. Wenn sie einen Fehler ausgibt (typischerweise weil der Blockhash nicht gefunden wird oder zu alt ist), ist der Blockhash ungültig.
  • Netzwerkbestätigung: Selbst wenn isBlockhashValid true zurückgibt, wird eine Transaktion erst abgeschlossen, wenn sie nach der Einreichung das gewünschte Commitment-Level im Netzwerk erreicht.
Dieser Leitfaden bietet die notwendigen Details, um die isBlockhashValid RPC-Methode effektiv beim Erstellen von Solana-Anwendungen zu nutzen.

Verwandte Methoden

getLatestBlockhash

Holen Sie sich einen frischen Blockhash für neue Transaktionen