So landen Transaktionen auf Solana

Transaktionen

Die Programmausführung beginnt mit einer Transaktion, die an den Cluster übermittelt wird. Eine Transaktion enthält:

• Ein Array aller Accounts, die sie lesen oder beschreiben will
• Eine oder mehrere Anweisungen (also die kleinste Ausführungseinheit)
• Einen aktuellen Blockhash
• Eine oder mehrere Signaturen

Die Runtime verarbeitet alle Anweisungen der Transaktion der Reihe nach und atomar. Schlägt ein Teil einer Anweisung fehl, schlägt die gesamte Transaktion fehl.

Was ist ein Blockhash?

Ein „Blockhash“ ist der neueste Proof-of-History-Hash (PoH) für einen Slot. Da Solana PoH als vertrauenswürdige Uhr verwendet, lässt sich der aktuelle Blockhash einer Transaktion als Zeitstempel betrachten. Der Blockhash verhindert Duplikate und begrenzt die Lebensdauer von Transaktionen. Ist der Blockhash einer Transaktion zu alt, wird sie abgelehnt. Ein Blockhash ist maximal 150 Blöcke oder ~1 Minute und 19 Sekunden alt.

Wie werden Transaktionen übermittelt?

Eine Gruppe von Validatoren verwaltet Solana und validiert die Transaktionen, die dem Ledger hinzugefügt werden. Aus dieser Gruppe wird ein Leader-Validator ausgewählt, der Einträge an das Ledger anhängt. Ein Ledger-Eintrag kann entweder ein Tick oder ein Transaktionseintrag sein. Das Ledger enthält eine Liste von Einträgen mit Transaktionen, die Clients signiert haben. Konzeptionell reicht das Ledger bis zum Genesis-Block zurück. Das tatsächliche Ledger eines Validators kann jedoch nur neuere Blöcke enthalten, um Speicherplatz zu sparen. Ältere Blöcke sind grundsätzlich nicht erforderlich, um zukünftige Blöcke zu validieren.

Der Leader-Validator kann pro Slot nur einen Block erzeugen. Der Blockhash dient als eindeutige Kennung jedes Blocks. Er ist ein Hash aller Einträge eines Blocks einschließlich des Hashes des vorherigen Blocks. Der Leader-Zeitplan wird vor jeder Epoche festgelegt, normalerweise etwa zwei Tage im Voraus. Er bestimmt, welcher Validator zu einem bestimmten Zeitpunkt als Leader fungiert. Wird eine Transaktion initiiert, wird sie an den aktuellen und den nächsten Leader-Validator weitergeleitet.

Transaktionen können auf folgenden Wegen an den Leader übermittelt werden: 

1. RPC-Server: Ein RPC-Anbieter kann Transaktionen über die JSON-RPC-Methode sendTransaction übermitteln. Der empfangende RPC-Node versucht, die Transaktion alle zwei Sekunden als UDP-Paket an den aktuellen und den nächsten Leader zu senden, bis sie finalisiert ist oder ihr Blockhash abläuft (nach 150 Blöcken oder ~1 Minute und 19 Sekunden). Bis dahin existiert außerhalb des Clients und der weiterleitenden RPC-Nodes kein Datensatz zur Transaktion. 
2. TPU-Client: Der TPU-Client übermittelt die Transaktion lediglich. Die Clientsoftware muss die erneute Übertragung und Weiterleitung an den Leader selbst übernehmen.

Um die Methode sendTransaction zu verwenden, musst du das als String codierte Transaktionsobjekt übergeben. Weitere optionale Parameter sind:

1. encoding: Für die Transaktionsdaten wird die Codierung base58 oder base64 verwendet. 
2. skipPreflight: Preflight-Prüfungen verifizieren die Transaktionssignaturen und simulieren die Transaktion mit dem Bank-Slot, den das Preflight-Commitment vorgibt. Schlägt die Preflight-Prüfung fehl, wird ein Fehler zurückgegeben. Standardmäßig ist diese Funktion auf false gesetzt. Preflight-Prüfungen werden also nicht übersprungen.
3. preflightCommitment: Gibt das Commitment-Level für Preflight-Prüfungen an. Standardmäßig ist das Commitment-Level auf finalized gesetzt, es kann aber durch einen String geändert werden. Wir empfehlen, dasselbe Commitment und Preflight-Commitment anzugeben, um unerwartetes Verhalten zu vermeiden.
4. maxRetries: Der Parameter maxRetries bestimmt, wie oft der RPC-Node maximal erneut versuchen soll, die Transaktion an den Leader zu senden. Fehlt dieser Parameter, versucht es der RPC-Node so lange, bis die Transaktion finalisiert ist oder der Blockhash abläuft. 
5. minContextSlot: Der Parameter minContextSlot gibt den minimalen Slot für die Preflight-Prüfung der Transaktion an.

Wie werden Transaktionen verarbeitet?

Die Transaction Processing Unit (TPU) des Validators empfängt die Transaktion, verifiziert die Signatur, führt sie aus und teilt sie mit anderen Validatoren im Netzwerk.

Die TPU verarbeitet Transaktionen in fünf klar getrennten Phasen:

Fetch-Phase

Die Fetch-Phase empfängt Transaktionen. Sie kategorisiert eingehende Transaktionen anhand von drei Ports:

• tpu: verarbeitet reguläre Transaktionen wie Token-Transfers, NFT-Mints und Programmanweisungen
• tpu_vote: verarbeitet ausschließlich Vote-Transaktionen
• tpu_forwards: Kann der aktuelle Leader nicht alle Transaktionen verarbeiten, leitet dieser Port unverarbeitete Pakete an den nächsten Leader weiter

Pakete werden in Gruppen von 128 gebündelt und an die SigVerify-Phase weitergeleitet.

SigVerify-Phase

Die SigVerify-Phase verifiziert die Signaturen von Paketen und entfernt Pakete, deren Verifizierung fehlschlägt. Votes und reguläre Pakete durchlaufen zwei getrennte Pipelines. Aus Sicht der Software enthalten die empfangenen Pakete einige Metadaten. Zu diesem Zeitpunkt ist aber noch unklar, ob diese Pakete Transaktionen sind.

Ist eine GPU installiert, wird sie für die Signaturverifizierung verwendet. Außerdem gibt es eine Logik, die bei höherem Datenverkehr zu viele Pakete anhand von IP-Adressen verwirft.

Banking-Phase

Diese Phase filtert und verarbeitet Transaktionen. Aktuell besteht sie aus sechs unabhängigen Worker-Threads: zwei Vote-Threads und vier Non-Vote-Threads. Reguläre Transaktionen werden den Non-Vote-Threads hinzugefügt. Jeder Thread besitzt einen lokalen Puffer, der bis zu 64 konfliktfreie Transaktionen in einer Prioritätswarteschlange aufnehmen kann. Diese Transaktionen werden anschließend parallel verarbeitet. Möglich macht das Sealevel. In diesem Video erfährst du mehr über die Banking-Phase.

Proof-of-History-Service

Das Modul PoH Service zeichnet verstrichene Ticks auf. Jeder Tick stellt eine Zeiteinheit dar, und ein Slot umfasst 64 Ticks. Der Hash wird wiederholt erzeugt, bis ein Datensatz aus der Banking-Phase eingeht:

next_hash = hash(prev_hash, hash(transaction_ids))

Diese Datensätze werden dann in Einträge umgewandelt und über die Broadcast-Phase im Netzwerk verbreitet.

Broadcast-Phase

Die Einträge des PoH-Service werden in Shreds umgewandelt, die kleinste Einheit eines Blocks. Anschließend werden sie mit einer Blockverteilungstechnik namens Turbine an den Rest des Netzwerks gesendet. Vereinfacht gesagt zerlegt Turbine einen Block in kleinere Teile und verteilt sie über eine hierarchische Struktur von Nodes. Nodes müssen nicht mit jedem anderen Node verbunden sein. Sie müssen nur mit einigen ausgewählten Nodes kommunizieren. In diesem Artikel erfährst du mehr über Turbine und seine Funktionsweise. 

Warum schlagen Transaktionen fehl?

Abgesehen von Fehlern durch falsche Anweisungen oder benutzerdefinierte Programmfehler können Transaktionen aus folgenden Gründen fehlschlagen:

Netzwerkbedingte Verluste

Die Netzwerkschicht kann eine Transaktion verwerfen, bevor ein Leader sie überhaupt verarbeitet. Der einfachste Grund dafür ist UDP-Paketverlust. Ein weiterer Grund hängt mit fetch stage der TPU zusammen. Bei hoher Netzwerkauslastung können Validatoren von der Anzahl zu verarbeitender Transaktionen überlastet werden. Validatoren können zusätzliche Transaktionen an den Port tpu_forward des nächsten Validators weiterleiten. Die weiterleitbare Datenmenge ist jedoch begrenzt, und jede Weiterleitung ist auf einen Hop zwischen Validatoren beschränkt. Das bedeutet, dass über den Port tpu_forwards empfangene Transaktionen nicht an andere Validatoren weitergeleitet werden. Überschreitet die ausstehende Warteschlange für erneute Übertragungen 10.000 Transaktionen, werden neu übermittelte Transaktionen verworfen.

Veralteter/falscher Blockhash 

Jede Transaktion besitzt einen „aktuellen Blockhash“, der als Zeitstempel für die Proof-of-History-Uhr (PoH) dient. Dieser Blockhash verhindert, dass Validatoren dieselbe Transaktion zweimal verarbeiten, und hält fest, wann und in welcher Reihenfolge Transaktionen verarbeitet wurden. Ein ungültiger Blockhash führt dazu, dass der Validator die Transaktion während der Verarbeitung ablehnt.

Blockhash läuft ab

Der Blockhash einer Transaktion läuft ab, sobald er nicht mehr als ausreichend „aktuell“ gilt. Um eine Transaktion zu verarbeiten, suchen Solana-Validatoren in einem Block nach der Slot-Nummer des zugehörigen Blockhashes. Findet der Validator keine Slot-Nummer für den Blockhash oder liegt die gefundene Slot-Nummer mehr als 151 Slots unter der Slot-Nummer des verarbeiteten Blocks, wird die Transaktion abgelehnt. Standardmäßig laufen Solana-Transaktionen ab, wenn sie nicht innerhalb eines bestimmten Zeitraums (~1 Minute und 19 Sekunden) in einen Block aufgenommen werden.

Zurückliegende RPC-Nodes

Wenn du eine Transaktion über einen RPC übermittelst, kann der RPC-Pool dem Rest voraus sein. Das kann Probleme verursachen, wenn Nodes innerhalb des Pools zusammenarbeiten müssen. Wird zum Beispiel recentBlockhash einer Transaktion aus dem weiter fortgeschrittenen Teil des Pools abgefragt und an den zurückliegenden Teil übermittelt, erkennen die Nodes den neueren Blockhash nicht und lehnen die Transaktion ab. Du kannst das bei der Übermittlung erkennen, indem du Preflight-Prüfungen für sendTransaction aktivierst.

Temporäre Netzwerk-Forks

Auch temporäre Netzwerk-Forks können dazu führen, dass Transaktionen verworfen werden. Spielt ein Validator seine Blöcke in der Banking-Phase zu langsam ab, kann ein Minority Fork entstehen. Wenn ein Client eine Transaktion erstellt, kann sie auf recentBlockhash verweisen, das nur im Minority Fork existiert. Nach der Übermittlung der Transaktion kann der Cluster den Minority Fork verlassen, bevor die Transaktion verarbeitet wird. In diesem Fall wird die Transaktion verworfen, weil der Blockhash nicht gefunden wird.

Wie lande ich Transaktionen erfolgreich?

Um Bestätigungsprobleme zu diagnostizieren, musst du verstehen, wann Transaktionen ablaufen. Mit diesen Schritten erhöhst du die Erfolgschance deiner Transaktionen:

Kurzfassung

• Rufe den neuesten Blockhash mit dem Commitment „confirmed“ oder „finalized“ ab
• Setze skipPreflight auf true
• Optimiere die Anzahl der angeforderten Compute Units
• Füge Priority Fees hinzu und berechne sie dynamisch
• Setze maxRetries auf 0 und implementiere eine eigene Wiederholungslogik zum Senden von Transaktionen.
• Nutze Staked Connections
• Ist die Transaktion nicht zeitkritisch, verwende dauerhafte Nonces

Blockhash

Validatoren haben nur begrenzt Zeit, eine Transaktion zu verarbeiten. Läuft der zugehörige Blockhash ab, bevor der Validator die Transaktion verarbeitet, wird sie abgebrochen. Sende deine Transaktion daher mit einem aktuellen Blockhash. Läuft der Blockhash vor der Verarbeitung ab, kannst du die Transaktion mit einem neuen Blockhash erneut versuchen. Dafür gibt es zwei Möglichkeiten: 

1. Lege ein neues Commitment-Level fest:

Die empfohlene RPC-API-Methode zum Abrufen des neuesten Blockhashes ist getLatestBlockhash. Standardmäßig verwendet diese Methode das Commitment-Level finalized, um den Blockhash des zuletzt finalisierten Blocks zurückzugeben. Dieses Commitment-Level bedeutet, dass mindestens 31 bestätigte Blöcke über diesem Block hinzugefügt wurden. So vermeidest du das Risiko, einen Blockhash aus einem verworfenen Fork zu verwenden. Zwischen den neuesten bestätigten und finalisierten Blöcken liegen jedoch normalerweise mindestens 32 Slots. Dieser Kompromiss verkürzt die Lebensdauer von Transaktionen um etwa 13 Sekunden, bei instabilen Cluster-Bedingungen möglicherweise noch stärker. 

Du kannst das Commitment des Blockhashes überschreiben, indem du den Commitment-Parameter auf ein anderes Level setzt. Für RPC-Anfragen empfehlen wir das Commitment-Level confirmed. Es liegt normalerweise nur wenige Slots hinter processed und gehört mit geringer Wahrscheinlichkeit zu einem verworfenen Fork. Das Commitment-Level processed ruft zwar den aktuellsten Blockhash ab, wird aber nicht empfohlen. Aufgrund von Forks im Solana-Protokoll werden etwa 5 % der Blöcke vom Cluster nicht finalisiert. Verwendet deine Transaktion einen Blockhash aus einem verworfenen Fork, gilt er für keinen Block in der finalisierten Blockchain als aktuell.

2. Frage regelmäßig neue aktuelle Blockhashes ab:

Füge ein Skript hinzu, das häufig (alle 60 Sekunden) mit der Methode getLatestBlockhash den neuesten Blockhash abruft und speichert. So steht der Anwendung ein frischer Blockhash zur Verfügung, sobald ein Nutzer eine Transaktion auslöst. Auch Wallets sollten regelmäßig neue Blockhashes abfragen und den aktuellen Blockhash einer Transaktion unmittelbar vor dem Signieren ersetzen. So ist er möglichst aktuell.

Preflight überspringen

Vor dem Übermitteln einer Transaktion werden folgende Preflight-Prüfungen ausgeführt:

• Die Signaturen der Transaktion werden verifiziert.
• Die Transaktion wird mit dem Bank-Slot simuliert, den das Preflight-Commitment vorgibt. Schlägt die Simulation fehl, wird ein Fehler zurückgegeben. 

Ist der für die Simulation ausgewählte Block älter als der Block, der für den Blockhash deiner Transaktion verwendet wurde, schlägt die Simulation mit dem gefürchteten Fehler „blockhash not found“ fehl. 

Wenn du sicher bist, dass die Signatur deiner Transaktion verifiziert ist und keine anderen Fehler vorliegen, kannst du die Preflight-Prüfung überspringen. Auch wenn du den Parameter skipPreflight verwendest, solltest du preflightCommitment bei Anfragen an sendTransaction und simulateTransaction immer auf dasselbe Commitment-Level setzen, das du zum Abrufen des Blockhashes deiner Transaktion verwendet hast.

Compute Units

Wird eine Transaktion im Netzwerk bestätigt, verbraucht sie einen Teil der gesamten Compute Units (CU), die in einem Block verfügbar sind. Aktuell liegt das gesamte Compute-Limit eines Blocks bei 48 Mio. CU. Entwickler können für ihre Transaktionen ein Compute-Unit-Budget festlegen. Legen sie kein Budget fest, wird standardmäßig ein Wert von 200.000 verwendet. Viele Transaktionen nutzen nicht das gesamte CU-Budget, weil ein höheres Budget als nötig keine Nachteile verursacht. Werden im Voraus jedoch zu viele Compute Units angefordert, erschwert das die effiziente Planung von Transaktionen. Der Scheduler weiß erst nach der Ausführung einer Transaktion, wie viel Compute-Kapazität im Block verbleibt. Entwickler sollten deshalb präziser begrenzte CU-Anfragen festlegen, die den Anforderungen der Transaktion entsprechen. Dieser Leitfaden zeigt dir, wie du das Compute-Unit-Budget optimierst. Im kommenden Update auf Solana-Client v1.18 erhalten Transaktionen mit geringerem Bedarf an Compute Units eine höhere Priorität.

Die Optimierung deiner Compute-Unit-Nutzung (CU) bietet folgende Vorteile:

• Eine kleinere Transaktion wird mit höherer Wahrscheinlichkeit in einen Block aufgenommen.
• Günstigere Anweisungen erleichtern die Komposition deines Programms.
• Die Gesamtauslastung des Blocks sinkt, sodass mehr Transaktionen in einen Block passen.

Priority Fees implementieren

Priority Fees können zusätzlich zur Basisgebühr einer Transaktion gezahlt werden, damit Validatoren sie priorisieren. Diese Gebühren werden in Mikro-Lamports pro Compute Unit berechnet, also in kleinen SOL-Beträgen. Sie machen es für Validator-Nodes wirtschaftlich attraktiver, die Transaktionen in Netzwerkblöcke aufzunehmen.

Du solltest allerdings nicht unbegrenzt hohe Priority Fees zahlen. Ein Betrag über der üblichen Gebühr erhöht die Erfolgschance deiner Transaktion nicht. Berechne Priority Fees deshalb dynamisch. So zahlst du einen angemessenen und wettbewerbsfähigen Betrag, ohne zu viel auszugeben. Die Integration ist unkompliziert. Weitere Informationen findest du in der offiziellen Dokumentation zu Priority Fees oder über die sofort verfügbare Helius API.

Eine robuste Wiederholungslogik implementieren

Implementiere bei Netzwerküberlastung eine eigene Logik in deinem Code, die fehlgeschlagene Transaktionen verarbeitet und manuell wiederholt. Setze dazu den Parameter maxRetries auf 0, wenn du eine Transaktion mit sendTransaction übermittelst. Du kannst Transaktionen auf verschiedene Arten wiederholen:

• Frage transaction status mit unterschiedlichen Commitment-Levels ab und verwende kontinuierlich dieselbe signierte Transaktion, bis sie bestätigt wird. Nutze einen exponentiellen Backoff, um Spam zu vermeiden. Alternativ kannst du Transaktionen in festen Abständen übermitteln, bis ein Timeout eintritt.
• Speichere lastValidBlockHeight aus getLatestBlockhash method. Frage anschließend die Blockhöhe des Clusters ab und wiederhole die Transaktion manuell, sobald die aktuelle Blockhöhe lastValidBlockHeight überschreitet. Bei Abfragen über getLatestBlockhash solltest du das gewünschte Commitment-Level angeben. Wenn du das Commitment auf „confirmed“ (abgestimmt) oder „finalized“ (~30 Blöcke nach „confirmed“) setzt, vermeidest du die Abfrage eines Blockhashes aus einem Minority Fork.

Staked Connections

Die Netzwerkbandbreite eines Leaders ist begrenzt. Um sie effektiv zu nutzen, ist eine Gewichtung nach Stake erforderlich. Andernfalls würden Transaktionen unabhängig von ihrer Quelle blind nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ angenommen. Solana ist ein Proof-of-Stake-Netzwerk. Daher liegt es nahe, die Stake-Gewichtung auszuweiten, um die Servicequalität für Transaktionen zu verbessern. Das bedeutet, dass ein Node mit 0,5 % Stake mindestens 0,5 % der Pakete an den Leader senden kann. Der Rest des Netzwerks kann diese Pakete nicht vollständig verdrängen, unabhängig davon, wie der verbleibende Stake kombiniert wird. Dieser Mechanismus heißt Stake-Weighted Quality of Service (SWQoS).

Helius bietet Staked Connections für kostenpflichtige Pläne an. Weitere Informationen findest du in unserer Dokumentation: Transaktionen auf Solana senden.

Dauerhafte Nonces

Dauerhafte Nonces ermöglichen es, eine Transaktion zu erstellen und zu signieren, die zu einem beliebigen späteren Zeitpunkt übermittelt werden kann. Sie kommen in Anwendungsfällen wie Verwahrdiensten zum Einsatz, die mehr Zeit zum Erstellen einer Transaktionssignatur benötigen. Ist deine Transaktion nicht zeitkritisch, kannst du mit dieser Methode die kurze Lebensdauer von recentBlockhash einer Transaktion umgehen.

Um dauerhafte Transaktionen zu verwenden, musst du eine Transaktion übermitteln, deren Anweisungen einen speziellen „Nonce“-Account On-Chain erstellen und darin einen „dauerhaften Blockhash“ speichern. Der Nonce-Account speichert den Wert der Nonce. Solange der Nonce-Account nicht verwendet wurde, kannst du anhand dieser zwei Regeln eine dauerhafte Transaktion erstellen:

• Die Liste der Anweisungen muss mit einer „advance nonce“-Systemanweisung beginnen, die deinen On-Chain-Nonce-Account lädt.
• Der Blockhash der Transaktion muss dem dauerhaften Blockhash entsprechen, der im On-Chain-Nonce-Account gespeichert ist.

In diesem Artikel erfährst du, wie du dauerhafte Nonces über CLI und Web3.js implementierst.

So übermittelt Helius Transaktionen

Die Anfrage sendTransaction wird automatisch an unseren nächstgelegenen RPC-Node weitergeleitet. Ist maxRetries nicht angegeben, versucht er die Transaktion alle zwei Sekunden erneut, bis der Blockhash abläuft. Wir empfehlen, maxRetries auf 0 zu setzen und die Transaktion selbst alle zwei Sekunden erneut zu übertragen, bis sie bestätigt ist. 

Um der aktuellen Netzwerküberlastung entgegenzuwirken, arbeiten wir rund um die Uhr daran, die Erfolgsrate für die Transaktionen unserer Nutzer zu erhöhen. Wir haben das Ratenlimit für die Anfrage sendTransaction gesenkt. So steuern wir die Überlastung und verhindern, dass der Validator mit Spam überflutet wird. Die Limits findest du hier.

Außerdem leiten wir hochwertigen Datenverkehr kostenpflichtiger Pläne über Staked Connections. Für diese Staked Connections nutzen wir unseren Validator. Datenverkehr gilt als hochwertig, wenn die gesamte Priority Fee mindestens 10.000 Lamports beträgt, also dem Cluster-Median entspricht.

Wir verlangen Gesamtgebühren von mehr als 10.000 Lamports, damit Validatoren ausschließlich hochwertigen Datenverkehr von uns erhalten. Validatoren haben begonnen, Ratenlimits auf Datenquellen anzuwenden oder sie sogar vollständig zu blockieren, wenn sie Transaktionen mit niedrigen Gebühren senden.

Staked Connections können die Erfolgsrate deiner Transaktionen deutlich erhöhen. In diesem Artikel erfährst du mehr darüber, wie du beim Erstellen einer Transaktion Priority Fees festlegst.

Unsere Empfehlungen

Einsteiger und fortgeschrittene Einsteiger

Wir empfehlen, skipPreflight auf false zu setzen. Preflight-Prüfungen verifizieren die Transaktionssignaturen und simulieren die Transaktion mit dem Bank-Slot, den das Preflight-Commitment vorgibt. Schlägt die Preflight-Prüfung fehl, wird ein Fehler zurückgegeben. Ohne Preflight-Prüfung können deine Transaktionen aufgrund einer Fehlkonfiguration verworfen werden.

Erfahrene Nutzer

Wenn du als erfahrener Nutzer die niedrigstmögliche Latenz benötigst, solltest du skipPreflight auf true setzen. Du bist dann jedoch selbst dafür verantwortlich, die Transaktion korrekt zu konfigurieren. 

Fazit

Um Transaktionen bei hoher Auslastung erfolgreich im Solana-Netzwerk zu landen, musst du die Netzwerkarchitektur und die Mechanismen der Transaktionsverarbeitung genau verstehen. Beherrschst du Kernkonzepte wie die Rolle des Blockhashes für Eindeutigkeit und Aktualität einer Transaktion, die Übermittlung über RPC-Server oder TPU-Clients sowie die korrekte Konfiguration von Parametern wie skipPreflight, preflightCommitment und maxRetries, kannst du die Transaktionsleistung deutlich verbessern. Eine eigene Wiederholungslogik und Staked Connections können die Erfolgsrate zusätzlich erhöhen.

Ebenso wichtig ist es, die aktuellen Einschränkungen des Netzwerks und Anzas laufende Lösungsansätze zu kennen, darunter die kommende Client-Version v1.18. Während sich das Netzwerk weiterentwickelt und skaliert, musst du informiert und anpassungsfähig bleiben, um effektiv damit zu interagieren. 

Wenn du Hilfe oder Support benötigst, kontaktiere uns jederzeit auf Discord. Trage unten deine E-Mail-Adresse ein, damit du keine Neuigkeiten zu Solana verpasst. Möchtest du tiefer einsteigen? Entdecke die neuesten Artikel im Helius-Blog und setze deine Solana-Reise noch heute fort.

Ressourcen

• Transaktionen – Solana Cookbook
• Blockoptimierung auf Solana
• Solana Validator 101: Transaktionsverarbeitung von Jito Labs
• Transaction Processing Unit in einem Solana-Validator
• Solanas Scheduler
• Transaktionsbestätigung von Solana
• Transaktionen mit Solana erneut versuchen
• So verwendest du Priority Fees
• So optimierst du Compute
• Priorisierungsgebühren und Compute Units
• Dauerhafte Transaktions-Nonces
• Dauerhaftes und Offline-Signieren von Transaktionen mit Nonces
• Solana-Transaktionen: Dauerhafte Nonces von Helius