Wie funktionieren Transaktionen auf Solana?

Da bei jeder Transaktion eine Fee anfällt, ist es sinnvoll zu verstehen, wie Transaktionen funktionieren. Eine Transaktion besteht aus drei Teilen:

einer oder mehreren Anweisungen
einem Array von Konten zum Lesen oder Schreiben
einer oder mehreren Signaturen
einem aktuellen Blockhash oder Nonce

Eine Anweisung ist die kleinste Ausführungslogik auf Solana. Anweisungen sind Aufrufe zur Aktualisierung des globalen Solana-Zustands. Anweisungen rufen Programme auf, die den Solana-Runtime aufrufen, um den Zustand zu aktualisieren (zum Beispiel der Aufruf des Token Program, um Token von einem Ihrer Konten auf ein anderes zu übertragen). Man kann sich eine Anweisung wie einen Funktionsaufruf in einem Ethereum-Smart-Contract vorstellen.

Ein wesentlicher Unterschied zwischen Ethereum und Solana ist die Anzahl der Funktionsaufrufe in einer einzigen Transaktion, bedingt durch die Anzahl der Anweisungen. Mehrere Anweisungen pro Transaktion kommen Entwicklern zugute, da sie keine eigenen Smart Contracts erstellen müssen, um Funktionen in einer einzigen Transaktion zu verketten. Jede Anweisung kann ein separater Funktionsaufruf sein, der in der Transaktion der Reihe nach ausgeführt wird. Transaktionen sind atomar – wenn eine dieser Anweisungen fehlschlägt, schlägt die gesamte Transaktion fehl, und es wird nur die Transaktionsgebühr fällig. Dies ähnelt dem Fehlschlagen einer Transaktion auf Ethereum, wenn das korrekte Slippage nicht eingestellt wurde.

Ein weiterer wichtiger Unterschied ist die Verwendung eines aktuellen Blockhash anstelle eines inkrementellen Nonce für Transaktionen. Wenn eine Wallet eine Transaktion durchführen möchte, wird ein aktueller Blockhash vom Cluster abgerufen, um eine gültige Transaktion zu erstellen. Dieser aktuelle Blockhash macht die Transaktion nur für 150 Blöcke nach dem Abruf des Blockhash gültig. Dies verhindert, dass lang gültige Transaktionssignaturen zu einem viel späteren Zeitpunkt ausgeführt werden.

Cross-Program Invocation (CPI)

Ein Cross-Program Invocation (CPI) liegt vor, wenn ein Solana-Programm während der Ausführung der ursprünglichen Transaktion eine Anweisung auf einem anderen Programm aufruft. CPI ist die wichtigste Methode, mit der Solana-Programme miteinander interagieren. Das Kontenmodell beeinflusst jedoch das Design des Call-Graphen: Die Transaktion muss alle Konten umfassen, auf die die gesamte CPI-Kette lesend oder schreibend zugreifen wird, bevor die Ausführung beginnt.

Der Aufgerufene erbt nur die Signer- und Schreibrechte, die der Aufrufer erhalten hat, und der Aufgerufene verbraucht dasselbe Compute-Budget der Transaktion. Verwenden Sie invoke, wenn alle erforderlichen Signer die ursprüngliche Transaktion signiert haben. Verwenden Sie invoke_signed, wenn das aufrufende Programm für eine seiner PDAs mit Signer-Seeds signieren muss.

Commitment-Stufen

RPC-Lesevorgänge, Abonnements und Transaktionsbestätigungslogik können eine commitment-Stufe wählen. Dies ist Solanas Version der Entscheidung, auf wie viele Ethereum-Blockbestätigungen gewartet werden soll, mit dem Unterschied, dass die Stufen explizit definiert sind:

processed: Die neueste verarbeitete Ansicht des Knotens. Nur für optimistische UIs oder Abläufe verwenden, die einen Rollback tolerieren können.
confirmed: Ein Block, über den eine Supermehrheit des Stakes abgestimmt hat. Als Standard für die meisten Produktionsbestätigungen und benutzergerichtete Transaktionsstatus verwenden.
finalized: Der stärkste Bestätigungsstatus. Vor unwiderruflichen Off-Chain-Aktionen verwenden, wie z. B. Fiat-Auszahlungen, Warenversand oder endgültige Abrechnungseinträge.

Wenn eine RPC-Methode Commitment akzeptiert und Sie es weglassen, ist der Standard typischerweise finalized. Produktions-Clients sollten Commitment dennoch explizit setzen, damit UI-Latenz, Indexer-Verhalten und Abrechnungsrichtlinien bewusst gesteuert werden.