- Verwendung von staked connections (Standard)
- Verwendung spezieller Landing-Dienste wie Sender (empfohlen)
Zusammenfassung
Helius’ staked connections garantieren 100 % Transaktionslieferung mit minimalen Bestätigungszeiten. Um Ihre Transaktionsübertragungsraten mit staked connections zu optimieren, empfehlen wir die folgenden Best Practices:- Verwenden Sie das Engagement “confirmed”, um den letzten Blockhash abzurufen
- Fügen Sie Prioritätsgebühren hinzu und berechnen Sie sie dynamisch
- Optimieren Sie die Nutzung der Compute-Einheiten (CU)
- Setzen Sie
maxRetriesauf 0 und implementieren Sie robuste Retry-Logik - Senden Sie mit
skipPreflightgesetzt auftrue(optional)
Empfohlene Optimierungen für Händler
Für latenzsensible Handelsanwendungsfälle empfehlen wir die Verwendung von Sender. Wenn Sie jedoch staked connections verwenden und Ihr Setup für die niedrigsten möglichen Latenzen optimieren möchten, empfehlen wir die folgenden Optimierungen (zusätzlich zur Anwendung der oben genannten Best Practices):- Ihr Client-Server (die Maschine, von der aus Sie Transaktionen senden) sollte sich im Osten der USA oder Westeuropa befinden.
- Wählen Sie FRA oder PIT, wenn Sie sich mit den Helius-Transaktionssendeservern co-lokalisieren möchten.
- Vermeiden Sie das Senden aus Regionen, die weit vom Validator-Netzwerk entfernt sind (z. B. LATAM, Südafrika).
- Erwärmen Sie die regionalen Caches von Helius, um die Schlusslatenz zu minimieren.
- Pro Region ist nur ein Erwärmungs-Thread erforderlich - mehr bringt keinen Vorteil.
- Senden Sie jeden Sekunden einen
getHealthRPC-Anruf mit dem gleichen Endpunkt und API-Schlüssel, den Sie zum Senden von Transaktionen verwenden.
Senden Intelligenter Transaktionen
Die Helius TypeScript und Rust SDKs können intelligente Transaktionen senden. Diese neue Methode erstellt und sendet eine optimierte Transaktion und behandelt den Bestätigungsstatus. Benutzer können die Sendeoptionen der Transaktion konfigurieren, z. B. ob die Transaktion Preflight-Checks überspringen soll. Auf der grundlegendsten Ebene müssen Benutzer ihr Schlüsselpaar und die Anweisungen, die sie ausführen möchten, bereitstellen, und wir kümmern uns um den Rest. Wir:- Abrufen des neuesten Blockhash
- Erstellen der anfänglichen Transaktion
- Simulieren der anfänglichen Transaktion, um die genutzten Compute-Einheiten (CUs) zu ermitteln
- Setzen des CU-Limits auf die in der vorherigen Stufe konsumierten CUs mit etwas Spielraum
- Holen der von Helius empfohlenen Prioritätsgebühr über unsere Priority Fee API
- Setzen der Prioritätsgebühr (Microlamports pro CU) als die von Helius empfohlene Gebühr
- Hinzufügen einer kleinen Puffergebühr für den Fall, dass sich die empfohlene Gebühr in den nächsten Sekunden ändert
- Erstellen und Senden der optimierten Transaktion
- Rückgabe der Transaktionssignatur bei Erfolg
Die Anforderung des empfohlenen Wertes (oder höher) für unsere staked connections stellt sicher, dass Helius qualitativ hochwertige Transaktionen sendet und dass wir nicht von Validatoren ratebegrenzt werden.
TypeScript SDK
DiesendSmartTransaction-Methode ist in unserem Helius TypeScript SDK für Versionen >= 1.3.2 verfügbar. Um auf eine neuere Version des SDK zu aktualisieren, führen Sie npm update helius-sdk aus.
Dieses Beispiel überträgt SOL auf ein Konto Ihrer Wahl. Es verwendet sendSmartTransaction, um eine optimierte Transaktion zu senden, die keine Preflight-Checks überspringt:
Rust SDK
Diesend_smart_transaction-Methode ist in unserem Rust SDK für Versionen >= 0.1.5 verfügbar. Um auf eine neuere Version des SDK zu aktualisieren, führen Sie cargo update helius aus.
Das folgende Beispiel überträgt 0,01 SOL auf ein Konto Ihrer Wahl.
Es nutzt send_smart_transaction, um eine optimierte Transaktion zu senden, die Preflight-Checks überspringt und bei Bedarf zweimal wiederholt wird:
Senden von Transaktionen ohne das SDK
Wir empfehlen, intelligente Transaktionen mit einem unserer SDKs zu senden, aber dieselbe Funktionalität kann auch ohne eines erreicht werden. Sowohl das TypeScript SDK als auch das Rust SDK sind Open-Source, sodass der zugrunde liegende Code für die Funktionalität des intelligenten Transaktionsversands jederzeit angesehen werden kann.Vorbereiten und Erstellen der anfänglichen Transaktion
Bereiten Sie zuerst die anfängliche Transaktion vor und erstellen Sie sie. Dazu gehört das Erstellen einer neuen Transaktion mit einer Reihe von Anweisungen, das Hinzufügen des aktuellen Blockhash und das Zuweisen eines Gebührenzahlers. Für versionierte Transaktionen erstellen Sie einenTransactionMessage und kompilieren ihn mit Lookup-Tabellen, falls vorhanden.
Erstellen Sie dann eine neue versionierte Transaktion und signieren Sie diese — dies ist für den nächsten Schritt erforderlich, wenn wir die Transaktion simulieren, da die Transaktion signiert sein muss.
Wenn wir beispielsweise eine versionierte Transaktion vorbereiten möchten:
Optimierung des Compute-Einheitenverbrauchs (CU) der Transaktion
Um den Compute-Einheitenverbrauch (CU) der Transaktion zu optimieren, können wir diesimulateTransaction-RPC-Methode verwenden, um die Transaktion zu simulieren.
Simulation der Transaktion gibt die Menge der verwendeten CUs zurück, sodass wir diesen Wert verwenden können, um unser Compute-Limit entsprechend festzulegen.
Es wird empfohlen, zuerst eine Testtransaktion mit den gewünschten Anweisungen durchzuführen, plus eine Anweisung, die das Compute-Limit auf 1,4 Millionen CUs setzt.
Dies wird getan, um sicherzustellen, dass die Transaktionssimulation erfolgreich ist.
Zum Beispiel:
Serialisieren und Kodieren der Transaktion
Dies ist relativ unkompliziert. Zuerst, um die Transaktion zu serialisieren, haben sowohl Transaction- als auch VersionedTransaction-Typen eine.serialize()-Methode. Verwenden Sie dann das bs58-Paket, um die Transaktion zu kodieren.
Ihr Code sollte ungefähr so aussehen wie bs58.encode(txt.serialize());
Festlegen der richtigen Prioritätsgebühr
Verwenden Sie zuerst die Priority Fee API, um die Prioritätsgebührenschätzung zu erhalten. Wir möchten unsere Transaktion übergeben und die von Helius empfohlene Gebühr über den empfohlenen Parameter erhalten:Erstellen und Senden der optimierten Transaktion
Dieser Schritt ähnelt fast dem ersten Schritt. Das Array der anfänglichen Anweisungen wurde jedoch geändert, um zwei Anweisungen hinzuzufügen, um das Compute-Einheiten-Limit und den Preis optimal festzulegen. Senden Sie nun die Transaktion. Es spielt keine Rolle, ob Sie mit oder ohne Preflight-Checks senden oder andere Sendeoptionen ändern – die Transaktion wird für alle kostenpflichtigen Pläne über unsere staked connections geleitet.Überwachung des Transaktionsstatus und erneutes Senden
DiesendTransaction-RPC-Methode hat einen maxRetries-Parameter, der festgelegt werden kann, um die Standard-Retry-Logik des RPC zu überschreiben, was Entwicklern mehr Kontrolle über den Wiederholungsprozess gibt.
Es ist üblich, den aktuellen Blockhash über getLatestBlockhash abzurufen, den lastValidBlockHeight zu speichern und die Transaktion so lange zu wiederholen, bis der Blockhash abläuft.
Es ist wichtig, eine Transaktion nur dann neu zu signieren, wenn der Blockhash nicht mehr gültig ist, andernfalls ist es möglich, dass beide Transaktionen vom Netzwerk akzeptiert werden.
Sobald eine Transaktion gesendet wurde, ist es wichtig, ihren Bestätigungsstatus abzufragen, um festzustellen, ob das Netzwerk sie verarbeitet und bestätigt hat, bevor sie erneut gesendet wird. Verwenden Sie die getSignatureStatuses-RPC-Methode, um den Bestätigungsstatus einer Liste von Transaktionen zu überprüfen.
Das @solana/web3.js SDK bietet auch eine getSignatureStatuses-Methode in seiner Connection-Klasse, um den aktuellen Status mehrerer Signaturen zu ermitteln.
Wie sendSmartTransaction Polling und erneutes Senden behandelt
DiesendSmartTransaction-Methode hat eine Zeitüberschreitungsperiode von 60 Sekunden. Da ein Blockhash für 150 Slots gültig ist und bei perfekten 400-ms-Slots, kann man davon ausgehen, dass ein Blockhash der Transaktion nach einer Minute ungültig wird.
Die Methode sendet die Transaktion und fragt die Signatur unter Verwendung dieser Zeitüberschreitungsperiode ab:
txtSig ist auf die Signatur der gerade gesendeten Transaktion gesetzt.
Die Methode verwendet dann die pollTransactionConfirmation()-Methode, um den Bestätigungsstatus der Transaktion abzufragen. Diese Methode überprüft den Status einer Transaktion alle fünf Sekunden maximal dreimal.
Wenn die Transaktion in dieser Zeit nicht bestätigt wird, wird ein Fehler zurückgegeben: