Skip to main content
Es gibt zwei Hauptmethoden zum Senden von Transaktionen auf Solana:
  1. Verwendung von staked connections (Standard)
  2. Verwendung spezieller Landing-Dienste wie Sender (empfohlen)
Dieser Artikel behandelt Best Practices zur Transaktionsoptimierung bei der Verwendung von staked connections, der Standardmethode für alle kostenpflichtigen Helius-Pläne. Staked connections sind am besten geeignet für Anwendungsfälle, bei denen Latenz nicht entscheidend für Ihr Geschäft ist (z. B. Zahlungen, Wallets, soziale Apps usw.). Wenn Sie ein fortgeschrittener Händler sind (z. B. propAMM, Sniper, Copy Trader, Liquidations-Bot, Arbitrage), der nach einem spezialisierten, ultraschnellen Transaktionsdienst sucht, lesen Sie unser Sender-Tutorial.

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 maxRetries auf 0 und implementieren Sie robuste Retry-Logik
  • Senden Sie mit skipPreflight gesetzt auf true (optional)
Möchten Sie tiefer eintauchen? Wir behandeln alle Grundlagen in diesem Blogbeitrag.

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 getHealth RPC-Anruf mit dem gleichen Endpunkt und API-Schlüssel, den Sie zum Senden von Transaktionen verwenden.
Diese Vorteile sind nur für erfahrene Händler spürbar. Für allgemeine App-Entwickler empfehlen wir, die Richtlinien im Abschnitt Senden Intelligenter Transaktionen unten zu befolgen.
Holen Sie sich On-Chain-Transaktionsdaten so schnell wie möglich mit Raw Shreds (UDP). Abonnieren Sie in Ihrem Helius-Dashboard.

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.
Diese Methode ist der einfachste Weg, eine Transaktion auf Solana zu erstellen, zu senden und zu verarbeiten. Durch die Verwendung der von Helius empfohlenen Gebühr werden Transaktionen von Helius-Benutzern auf einem unserer Standardzahlungstarife über unsere staked connections geleitet, was nahezu 100 % Transaktionslieferung und minimale Latenz garantiert.

TypeScript SDK

Die sendSmartTransaction-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

Die send_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 einen TransactionMessage 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 die simulateTransaction-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:
Es wird auch empfohlen, etwas Spielraum hinzuzufügen, um sicherzustellen, dass die Transaktion ohne Probleme ausgeführt wird. Wir können dies tun, indem wir folgendes festlegen:
Erstellen Sie dann eine Anweisung, die das Compute-Einheiten-Limit auf diesen Wert setzt, und fügen Sie sie zu Ihrem Anweisungsarray hinzu:

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 Sie dann eine Anweisung, die den Preis der Compute-Einheit auf diesen Wert setzt, und fügen Sie diese Anweisung zu Ihren vorherigen Anweisungen hinzu:

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

Obwohl staked connections eine Transaktion direkt an den Leader weiterleiten, kann es dennoch vorkommen, dass die Transaktion im Banking-Stadium abgelehnt wird. Es wird empfohlen, dass Benutzer ihre eigene erneute Sendungslogik implementieren, anstatt sich darauf zu verlassen, dass der RPC die Transaktion für sie wiederholt.
Die sendTransaction-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

Die sendSmartTransaction-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: