Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Transaktionsaufbau
Eine Solana-Transaktion hat drei Kernkomponenten:- Message: die geordnete Liste der Instruktionen, die Konten, auf die sie verweisen, und den kürzlichen Blockhash.
- Signatures: eine pro Unterzeichner, bestätigen, dass die Transaktion autorisiert wurde.
- Recent blockhash: beweist, dass die Transaktion aktuell ist; Transaktionen mit veralteten Blockhashes (>150 Slots alt) werden abgelehnt.
Instruktionen
Eine Instruktion legt fest:program_id— das aufzurufende Programm.accounts— die Konten (und deren writable/signer-Flags) die das Programm berühren darf.data— undurchsichtige Bytes, die das Programm interpretiert.
ComputeBudget::SetComputeUnitLimit— erhöht das Standard-CU-Limit.ComputeBudget::SetComputeUnitPrice— setzt eine Prioritätsgebühr.- Optional
CreateAssociatedTokenAccount— erstellt das Ausgabe-ATA, falls der Benutzer noch keine hat. Raydium::SwapBaseInput— führt den Swap aus.- Optional
CloseAccount— schließt ein wrapped-SOL-ATA.
raydium.trade.swap().
Konten in Transaktionen
Jedes Konto, das durch eine Instruktion in der Transaktion berührt wird, muss in der Kontoliste der Transaktion aufgeführt sein. Jedes Konto wird gekennzeichnet:- Signer / non-signer: muss der Inhaber des Kontos die Transaktion unterzeichnen?
- Writable / read-only: kann die Transaktion das Konto ändern?
solana-fundamentals/account-model). CLMM-Swaps mit mehreren Tick-Array-Übergängen können 20+ haben.
Transaktionsgrößenlimit
Solana begrenzt Transaktionen auf 1232 Bytes einschließlich Signaturen, Message und Headers. Dies ist das häufigste Hindernis für komplexe Transaktionen — Raydiums CLMM mit Multi-Hop-Routing stoßen regelmäßig an diese Grenze. Aufschlüsselung eines typischen ~1000-Byte-Raydium-Swaps:| Komponente | Größe |
|---|---|
| Signature | 64 B |
| Signature count | 1 B |
| Message header | 3 B |
| Blockhash | 32 B |
| Account keys (13 × 32 B) | 416 B |
| Instructions (4 × ~100-150 B) | 400–600 B |
| Gesamt | ~900–1100 B |
Address Lookup Tables (ALTs)
ALTs ermöglichen es einer Transaktion, auf Konten über einen 1-Byte-Index in einer veröffentlichten Tabelle zu verweisen, anstatt einen vollständigen 32-Byte-Pubkey zu verwenden. Dies komprimiert eine Transaktion erheblich:- Eine Transaktion, die auf 20 Konten direkt verweist: ~640 B Pubkeys.
- Dieselbe Transaktion mit ALTs: ~20 B Indizes + ALT-Referenzen.
Compute Budget
Jede Transaktion hat ein Compute Unit (CU) Budget. Die Überschreitung beendet die Ausführung und verursacht den Fehlschlag der Transaktion.- Standard: 200.000 CU pro Transaktion.
- Maximum: 1.400.000 CU pro Transaktion (erhöht über
ComputeBudget::SetComputeUnitLimit). - Pro-Block-Obergrenze: 48M CU pro Block (auf Protokollebene).
integration-guides/priority-fee-tuning für die vollständige Tabelle):
| Instruktion | CU |
|---|---|
| CPMM swap | ~140.000 |
| CLMM swap (keine Tick-Übergänge) | ~170.000 |
| CLMM swap (4 Tick-Übergänge) | ~320.000 |
| Farm v6 stake | ~130.000 |
| CPMM pool creation | ~250.000 |
ComputeBudget; sonst erhalten Sie den 200k-Standard, was für die meisten Raydium-Instruktionen zu niedrig ist.
Prioritätsgebühren
Über die Basisgebühr (5000 Lamports pro Signature) hinaus priorisieren Validatoren zunehmend Transaktionen, die Prioritätsgebühren zahlen: ein Pro-CU-Trinkgeld in Microlamports.integration-guides/priority-fee-tuning für die Anpassung dieser dynamisch.
Limits für Instruktions- und Kontoanzahl
Über das 1232-Byte-Gesamtlimit hinaus:- Max Konten pro Transaktion: 128.
- Max Konten pro Instruktion (CPI): 64.
- Max Instruktionen pro Transaktion: kein hartes Limit, nur durch das Größenlimit beschränkt.
- Max CPI-Tiefe: 4 (ein Programm kann ein anderes aufrufen, das wiederum ein anderes aufrufen kann, 4 Ebenen tief).
Gebührenkategorien bei einem Raydium-Swap
Eine Benutzer-Swap-Transaktion zahlt Gebühren in zwei Kategorien:Solana-Netzwerkgebühren
Bezahlt an Validatoren in SOL.- Basisgebühr pro Signature: 5000 Lamports pro Signature. Fast immer 1 Signature = 0,000005 SOL.
- Prioritätsgebühr: CU-Preis × CU-Limit in Microlamports. Variiert mit Stau; siehe
integration-guides/priority-fee-tuning.
Raydium-Protokollgebühren
Werden vom Swap-Betrag abgezogen.- Swap-Gebühr: Prozentsatz der Eingabe (CPMM typischerweise 0,25%, CLMM 0,01%–1% pro Stufe). Aufgeteilt zwischen LPs und Protokoll-Zielen. Siehe
ray/protocol-fees.
Beispiel: $1000 USDC → SOL über CPMM 0,25%-Stufe
| Gebührenkategorie | Betrag | Geht zu |
|---|---|---|
| Basisgebühr pro Signature | 0,000005 SOL (~$0,0007) | Validator |
| Prioritätsgebühr (10k µL × 300k CU) | 0,003 SOL (~$0,45) | Validator |
| CPMM swap fee (0,25%) | $2,50 | LPs + Protokoll |
| Gesamtkosten für Benutzer | ~$2,95 |
Versionierte Transaktionen
Solana hat zwei Transaktionsformate:- Legacy: das ursprüngliche Format, kein ALT-Support.
- v0 (Versioned): unterstützt ALTs, erweiterbar für zukünftige Versionen.
Blockhash-Aktualität
Eine Transaktion muss einen Blockhash aus den letzten ~150 Slots (~60 Sekunden) enthalten. Über dieses Fenster hinaus lehnen Validatoren es ab. Für Wiederholungsschleifen rufen Sie einen frischen Blockhash bei jedem Versuch ab:integration-guides/priority-fee-tuning für das vollständige Muster Wiederholung-mit-eskalierenden-Gebühren.
Parallele Ausführung
Solana führt nicht konfligierende Transaktionen parallel auf Multi-Core-Validatoren aus. Zwei Transaktionen sind in Konflikt, wenn beide dasselbe Konto schreiben. Auswirkungen auf Raydium:- Zwei Swaps auf dem gleichen Pool können nicht parallel ausgeführt werden — beide schreiben in den Pool-Status.
- Ein Swap auf Pool A und ein Swap auf Pool B führen parallel aus, wenn sich Kontolisten nicht überlappen.
- Eine schreibgeschützte Transaktion blockiert nie einen Writer auf dem gleichen Konto (schreibgeschützt ist konzurrent mit sich selbst, aber nicht mit Writes).
Transaktionsbestätigungsstufen
Beim Einreichen einer Transaktion wählen Sie eine Bestätigungsstufe:| Stufe | Wartezeit | Finalität |
|---|---|---|
processed | ~400 ms | Nicht finalisiert; kann zurückgerollt werden |
confirmed | ~1 s | Supermajorität hat abgestimmt |
finalized | ~13 s | Supermajorität ist verwurzelt |
confirmed Standard. Bei Operationen mit großem Wert (Pool-Erstellung, Reward-Top-ups) ist finalized sicherer.
Simulation
Solana unterstützt das Simulieren einer Transaktion vor der Einreichung:getBestSwapInfo, um zu überprüfen, dass die gewählte Route tatsächlich erfolgreich ist. Simulation ist nicht kostenlos — sie verbraucht RPC-Kapazität — aber sie fängt Fehler ab, bevor Sie dafür bezahlen.
Verweise
solana-fundamentals/account-model— Konten in Transaktionen.solana-fundamentals/pdas-and-cpis— wie Programme sich gegenseitig aufrufen.integration-guides/priority-fee-tuning— Anpassung von CU-Limits und Prioritätsgebühren.ray/protocol-fees— Raydium-Protokollgebührenstruktur.

