- Über gestakte Verbindungen (Standard)
- Über spezialisierte Dienste für die Transaktionsaufnahme wie Sender (empfohlen)
Zusammenfassung
Die gestakten Verbindungen von Helius garantieren eine Transaktionszustellung von 100 % bei minimalen Bestätigungszeiten. Um die Aufnahmerate deiner Transaktionen mit gestakten Verbindungen zu optimieren, empfehlen wir folgende Best Practices:- Verwende das commitment „confirmed“, um den neuesten blockhash abzurufen
- Füge Prioritätsgebühren hinzu und berechne sie dynamisch
- Optimiere die Nutzung von Compute Units (CU)
- Setze
maxRetriesauf 0 und implementiere eine robuste Wiederholungslogik - Sende mit
skipPreflightauftruegesetzt (optional)
Empfohlene Optimierungen für Trader
Für latenzkritische Trading-Anwendungsfälle empfehlen wir, Sender zu verwenden. Wenn du jedoch gestakte Verbindungen verwendest und dein Setup für die geringstmögliche Latenz optimieren möchtest, empfehlen wir zusätzlich zu den oben genannten Best Practices folgende Optimierungen:- Dein Client-Server, also der Rechner, von dem du Transaktionen sendest, sollte sich im Osten der USA oder in Westeuropa befinden.
- Wähle FRA oder PIT, wenn du deine Infrastruktur am selben Standort wie die Helius-Server für den Transaktionsversand betreiben möchtest.
- Vermeide das Senden aus Regionen, die weit vom Validator-Netzwerk entfernt sind, z. B. Lateinamerika oder Südafrika.
- Wärme die regionalen Helius-Caches auf, um die Tail-Latenz zu minimieren.
- Pro Region ist nur ein Thread zum Aufwärmen erforderlich. Weitere Threads bringen keinen Vorteil.
- Sende jede Sekunde einen
getHealth-RPC-Aufruf. Verwende dabei denselben endpoint und API key wie beim Senden von Transaktionen.
Intelligente Transaktionen senden
Sowohl das Helius-TypeScript- als auch das Rust-SDK können intelligente Transaktionen senden. Diese neue Methode erstellt und sendet eine optimierte Transaktion und verarbeitet dabei ihren Bestätigungsstatus. Du kannst die Sendeoptionen der Transaktion konfigurieren, etwa ob die Transaktion Preflight-Prüfungen überspringen soll. Im einfachsten Fall musst du dein Schlüsselpaar und die auszuführenden Anweisungen angeben. Den Rest übernehmen wir. Wir führen folgende Schritte aus:- Den neuesten blockhash abrufen
- Die anfängliche Transaktion erstellen
- Die anfängliche Transaktion simulieren, um die verbrauchten Compute Units (CUs) zu ermitteln
- Das CU-Limit mit einem gewissen Puffer auf die im vorherigen Schritt verbrauchten CUs setzen
- Die von Helius empfohlene Prioritätsgebühr über unsere Priority Fee API abrufen
- Die Prioritätsgebühr in Mikrolamports pro CU auf die von Helius empfohlene Gebühr setzen
- Eine kleine Puffergebühr hinzufügen, falls sich die empfohlene Gebühr in den nächsten Sekunden ändert
- Die optimierte Transaktion erstellen und senden
- Bei Erfolg die Transaktionssignatur zurückgeben
Wenn wir für unsere gestakten Verbindungen den empfohlenen Wert oder einen höheren Wert voraussetzen, kann Helius hochwertige Transaktionen senden, ohne dass Validatoren unsere rate limit begrenzen.
TypeScript-SDK
Die MethodesendSmartTransaction ist in unserem Helius TypeScript SDK ab Version >= 1.3.2 verfügbar. Führe npm update helius-sdk aus, um auf eine neuere Version des SDK zu aktualisieren.
Dieses Beispiel überträgt SOL an ein Konto deiner Wahl. Es verwendet sendSmartTransaction, um eine optimierte Transaktion zu senden, die Preflight-Prüfungen nicht überspringt:
Rust-SDK
Die Methodesend_smart_transaction ist in unserem Rust SDK ab Version >= 0.1.5 verfügbar. Führe cargo update helius aus, um auf eine neuere Version des SDK zu aktualisieren.
Das folgende Beispiel überträgt 0,01 SOL an ein Konto deiner Wahl.
Es verwendet send_smart_transaction, um eine optimierte Transaktion zu senden, die Preflight-Prüfungen überspringt und bei Bedarf zwei Wiederholungsversuche ausführt:
Transaktionen ohne das SDK senden
Wir empfehlen, intelligente Transaktionen mit einem unserer SDKs zu senden. Dieselbe Funktionalität lässt sich jedoch auch ohne SDK umsetzen. Sowohl das TypeScript-SDK als auch das Rust-SDK sind Open Source. Du kannst dir daher jederzeit den zugrunde liegenden Code für das Senden intelligenter Transaktionen ansehen.Anfängliche Transaktion vorbereiten und erstellen
Bereite zuerst die anfängliche Transaktion vor und erstelle sie. Erstelle dazu eine neue Transaktion mit einer Reihe von Anweisungen, füge den aktuellen blockhash hinzu und weise einen Gebührenzahler zu. Erstelle für versionierte Transaktionen eineTransactionMessage und kompiliere sie mit Lookup-Tabellen, falls welche vorhanden sind.
Erstelle anschließend eine neue versionierte Transaktion und signiere sie. Das ist für den nächsten Schritt erforderlich, da die Transaktion für die Simulation signiert sein muss.
So könntest du beispielsweise eine versionierte Transaktion vorbereiten:
Nutzung der Compute Units (CU) einer Transaktion optimieren
Um die Nutzung der Compute Units (CU) einer Transaktion zu optimieren, können wir die RPC-MethodesimulateTransaction verwenden, um die Transaktion zu simulieren.
Die Simulation der Transaktion gibt die Anzahl der verwendeten CUs zurück. Mit diesem Wert können wir das Compute-Limit entsprechend festlegen.
Wir empfehlen, zuerst eine Testtransaktion mit den gewünschten Anweisungen und einer zusätzlichen Anweisung zu verwenden, die das Compute-Limit auf 1,4 Millionen CUs setzt.
So stellst du sicher, dass die Transaktionssimulation erfolgreich ist.
Zum Beispiel:
Transaktion serialisieren und codieren
Dieser Schritt ist relativ unkompliziert. Sowohl der Typ Transaction als auch der Typ VersionedTransaction verfügen über eine Methode.serialize(), mit der du die Transaktion serialisieren kannst. Verwende anschließend das Paket bs58, um die Transaktion zu codieren.
Dein Code sollte ungefähr so aussehen: bs58.encode(txt.serialize());
Die richtige Prioritätsgebühr festlegen
Verwende zuerst die Priority Fee API, um die geschätzte Prioritätsgebühr abzurufen. Wir übergeben unsere Transaktion und rufen über den Parameter recommended die von Helius empfohlene Gebühr ab:Optimierte Transaktion erstellen und senden
Dieser Schritt entspricht fast dem ersten Schritt. Das Array der anfänglichen Anweisungen enthält jetzt jedoch zwei zusätzliche Anweisungen, mit denen das Compute-Unit-Limit und der Preis optimal festgelegt werden. Sende jetzt die Transaktion. Es spielt keine Rolle, ob du mit oder ohne Preflight-Prüfungen sendest oder andere Sendeoptionen änderst. Bei allen kostenpflichtigen Tarifen wird die Transaktion über unsere gestakten Verbindungen geleitet.Status der Transaktion abfragen und erneut senden
Die RPC-MethodesendTransaction besitzt den Parameter maxRetries. Du kannst ihn festlegen, um die standardmäßige Wiederholungslogik von RPC zu überschreiben und mehr Kontrolle über den Wiederholungsprozess zu erhalten.
Ein gängiges Muster besteht darin, den aktuellen blockhash über getLatestBlockhash abzurufen, lastValidBlockHeight zu speichern und die Transaktion zu wiederholen, bis der blockhash abläuft.
Signiere eine Transaktion unbedingt erst dann erneut, wenn der blockhash nicht mehr gültig ist. Andernfalls kann das Netzwerk beide Transaktionen akzeptieren.
Nachdem du eine Transaktion gesendet hast, solltest du ihren Bestätigungsstatus abfragen. Prüfe vor einem erneuten Versuch, ob das Netzwerk sie bereits verarbeitet und bestätigt hat. Verwende die RPC-Methode getSignatureStatuses, um den Bestätigungsstatus einer Liste von Transaktionen zu prüfen.
Das @solana/web3.js-SDK bietet außerdem eine Methode getSignatureStatuses in seiner Klasse Connection, mit der du den aktuellen Status mehrerer Signaturen abrufen kannst.
So verarbeitet sendSmartTransaction Statusabfragen und erneutes Senden
Die MethodesendSmartTransaction hat einen timeout von 60 Sekunden. Da ein blockhash für 150 slots gültig ist, können wir bei idealen slots von 400 ms davon ausgehen, dass der blockhash einer Transaktion nach einer Minute ungültig wird.
Die Methode sendet die Transaktion und fragt ihre Signatur innerhalb dieses timeout ab:
txtSig wird auf die Signatur der gerade gesendeten Transaktion gesetzt.
Anschließend verwendet die Methode pollTransactionConfirmation(), um den Bestätigungsstatus der Transaktion abzufragen. Diese Methode prüft den Status einer Transaktion alle fünf Sekunden und höchstens dreimal.
Wenn die Transaktion während dieses Zeitraums nicht bestätigt wird, gibt die Methode einen Fehler zurück: