Zum Hauptinhalt springen
Es gibt zwei primäre Methoden, um Transaktionen auf Solana zu senden:
  1. Über gestakte Verbindungen (Standard)
  2. Über spezialisierte Dienste für die Transaktionsaufnahme wie Sender (empfohlen)
Dieser Artikel behandelt Best Practices zur Transaktionsoptimierung bei der Verwendung gestakter Verbindungen. Diese sind die Standardmethode für alle kostenpflichtigen Helius-Tarife. Gestakte Verbindungen eignen sich am besten für Anwendungsfälle, bei denen die Latenz für dein Geschäft nicht entscheidend ist, z. B. Zahlungen, Wallets oder soziale Apps. Wenn du als fortgeschrittener Trader, z. B. mit propAMM, Sniper, Copy Trader, Liquidation Bot oder Arbitrage, einen spezialisierten Dienst für die Transaktionsaufnahme mit extrem niedriger Latenz suchst, lies unser Sender-Tutorial.

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 maxRetries auf 0 und implementiere eine robuste Wiederholungslogik
  • Sende mit skipPreflight auf true gesetzt (optional)
Möchtest du tiefer einsteigen? In diesem Blogbeitrag behandeln wir alle Grundlagen.

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.
Diese Vorteile sind nur für erfahrene Trader spürbar. Entwicklern allgemeiner Apps empfehlen wir, die Richtlinien im folgenden Abschnitt „Intelligente Transaktionen senden“ zu befolgen.
Rufe Onchain-Transaktionsdaten mit Raw Shreds (UDP) so schnell wie möglich ab. Abonniere den Dienst in deinem Helius-Dashboard.

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.
Diese Methode ist der einfachste Weg, eine Transaktion auf Solana zu erstellen, zu senden und ins Netzwerk aufzunehmen. Wenn du die von Helius empfohlene Gebühr verwendest, werden Transaktionen von Helius-Nutzern mit einem unserer kostenpflichtigen Standardtarife über unsere gestakten Verbindungen geleitet. Das garantiert eine Transaktionszustellung von nahezu 100 % bei minimaler Latenz.

TypeScript-SDK

Die Methode sendSmartTransaction 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 Methode send_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 eine TransactionMessage 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-Methode simulateTransaction 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:
Füge außerdem einen kleinen Puffer hinzu, damit die Transaktion ohne Probleme ausgeführt wird. Lege dazu Folgendes fest:
Erstelle anschließend eine Anweisung, die das Compute-Unit-Limit auf diesen Wert setzt, und füge sie deinem Array mit Anweisungen hinzu:

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:
Erstelle anschließend eine Anweisung, die den Preis pro Compute Unit auf diesen Wert setzt, und füge sie deinen vorherigen Anweisungen hinzu:

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

Gestakte Verbindungen leiten eine Transaktion zwar direkt an den Leader weiter, sie kann jedoch weiterhin in der Banking Stage verworfen werden. Wir empfehlen, eine eigene Logik für erneutes Senden zu implementieren, statt dich darauf zu verlassen, dass RPC die Transaktion erneut sendet.
Die RPC-Methode sendTransaction 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 Methode sendSmartTransaction 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: