Solana Durable Nonces erklärt: Offline-Signaturen, Nonce Accounts und Risiken
Wer Solana-Transaktionen vorbereitet, unterschreibt und erst später absendet, stösst auf eine Besonderheit: Eine normale Transaktion ist nur begrenzt gültig. Das schützt das Netzwerk vor der wiederholten Ausführung alter Zahlungsanweisungen, erschwert aber die Zusammenarbeit mehrerer Unterschriftsberechtigter. Durable Nonces sind ein spezieller Mechanismus, um die zeitliche Gültigkeit einer noch nicht eingereichten Transaktion von einem kurzlebigen Blockhash zu entkoppeln. Du lernst hier, wie Nonce Accounts technisch funktionieren, wann sich die Konstruktion lohnt und welche Fehler trotz vermeintlich unbegrenzter Gültigkeit zu einem Verlust oder einer gescheiterten Überweisung führen können.
Warum Solana-Transaktionen normalerweise ablaufen
Eine gewöhnliche Solana-Transaktion referenziert einen kürzlich beobachteten Blockhash. Dieser gehört zum signierten Nachrichteninhalt und begrenzt damit die Zeitspanne, in der Validatoren die Transaktion akzeptieren. Die Solana-Dokumentation beschreibt für normale Transaktionen eine Gültigkeitsgrenze anhand der jüngsten Blockhashes; bei Durable Nonces entfällt die entsprechende Grenze von 150 Slots. Slots sind dabei keine garantierte Uhrzeit. Netzwerklast, ausgelassene Slots und die Geschwindigkeit der Blockproduktion beeinflussen, wie lange die praktische Frist dauert. Ein Wallet kann deshalb nicht einfach behaupten, eine unterschriebene Standardtransaktion werde morgen noch gültig sein. Ein neuer Blockhash verändert die signierte Nachricht und verlangt grundsätzlich neue Signaturen.
Was ein Durable Nonce tatsächlich ist
Ein Durable Nonce ist keine beliebig wählbare fortlaufende Zahl und auch keine zusätzliche Kryptowährung. Es handelt sich um einen in einem speziellen Solana-Konto gespeicherten Wert, der aus einem Blockhash abgeleitet wird. Dieser Wert wird im Transaktionsfeld recent_blockhash verwendet. Das Konto gehört dem System Program und enthält unter anderem die öffentliche Adresse der Nonce Authority, den aktuellen Nonce-Wert und eine gespeicherte Gebühreninformation. Der entscheidende Unterschied: Solange der gespeicherte Nonce nicht verändert wird und die weiteren Voraussetzungen erfüllt sind, kann eine damit signierte Transaktion auch nach Ablauf des gewöhnlichen Blockhash-Fensters eingereicht werden. Dauerhaft bedeutet hier nicht unwiderruflich, unendlich wiederverwendbar oder unabhängig vom Netzwerkzustand.
Nonce Account und Nonce Authority
Der Nonce Account ist ein eigenständiges Onchain-Konto. Er darf nicht mit dem Konto verwechselt werden, aus dem SOL versendet wird. Die Nonce Authority kontrolliert, wer den gespeicherten Nonce weiterstellen darf. Für die Ausführung einer Durable-Nonce-Transaktion muss diese Autorisierung gültig sein. Du kannst damit die Person oder Hardware, welche die Nonce kontrolliert, von der Person unterscheiden, die eine Überweisung inhaltlich genehmigt. Das ist für institutionelle Zahlungsabläufe interessant. Gleichzeitig entsteht ein weiterer Schlüssel, dessen Verlust oder Kompromittierung den Prozess gefährdet. Ein Angreifer mit Kontrolle über die Nonce Authority kann den gespeicherten Wert verändern und damit vorbereitete Signaturen unbrauchbar machen.
Der technische Ablauf in fünf Phasen
Zuerst wird ein Konto erstellt und mit InitializeNonceAccount initialisiert. Anschliessend liest die Anwendung den gespeicherten Nonce aus. Beim Aufbau der eigentlichen Zahlung wird dieser Wert anstelle eines gewöhnlichen recent_blockhash eingesetzt. Als erste Instruktion muss AdvanceNonceAccount stehen. Danach folgen die eigentlichen Zahlungs- oder Programm-Instruktionen. Die Beteiligten unterschreiben exakt diese Nachricht. Zu einem späteren Zeitpunkt wird die vollständige signierte Transaktion an das Netzwerk übermittelt. Nach erfolgreicher Verarbeitung wird der gespeicherte Nonce weitergestellt. Eine zweite Transaktion mit dem alten Wert lässt sich dann nicht erneut ausführen. Die Reihenfolge der Instruktionen ist keine optische Konvention, sondern Bestandteil der Erkennung durch die Solana Runtime.
Warum die erste Instruktion entscheidend ist
Solana prüft bei einer Transaktion mit nicht mehr aktuellem Blockhash, ob die erste Instruktion eine gültige AdvanceNonceAccount-Instruktion des System Program ist. Das Nonce-Konto muss dabei an der vorgeschriebenen Position als beschreibbares Konto referenziert werden. Anschliessend prüft die Runtime, ob der gespeicherte Wert mit dem signierten Blockhash übereinstimmt. Auch die Nonce Authority muss korrekt autorisiert sein. Ein scheinbar kleiner Fehler beim Zusammenstellen der Instruktionsliste kann deshalb die ganze Konstruktion ungültig machen. Bibliotheken, die eine Durable-Nonce-Lifetime setzen, sollten so verwendet werden, dass spätere Änderungen nicht versehentlich die Advance-Instruktion von Position eins verdrängen.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Code: AUSWANDERNSCHWEIZ
Offline-Signierung und mehrstufige Freigaben
Ein typischer Anwendungsfall ist eine Zahlung, die zwei Personen genehmigen müssen. Eine Person arbeitet mit einem abgeschotteten Gerät, die andere in einem anderen Land. Mit einer Standardtransaktion könnte die Gültigkeit schon ablaufen, bevor beide Unterschriften vorliegen. Eine Durable-Nonce-Transaktion kann dagegen vorbereitet, offline unterschrieben, sicher übertragen und erst nach Abschluss des Freigabeprozesses eingereicht werden. Die Signaturen schützen den Inhalt vor nachträglicher Veränderung. Allerdings schützt die Technik nicht vor einer falschen Empfängeradresse, einem kompromittierten Freigabegerät oder einer betrügerischen Anweisung. Der Prozess muss deshalb sowohl den signierten Nachrichteninhalt als auch die menschliche Genehmigung zuverlässig kontrollieren.
Verzögerte Ausführung ist kein eingebauter Zahlungskalender
Eine signierte Durable-Nonce-Transaktion kann später abgesendet werden. Daraus folgt nicht, dass das Netzwerk selbst einen Ausführungstermin garantiert. Für eine Auszahlung am nächsten Montag braucht es weiterhin einen verlässlichen Dienst oder einen menschlichen Prozess, der die Transaktion tatsächlich einreicht. Ein Nonce ist auch kein Treuhandvertrag, keine bedingte Zahlung und kein Smart Contract, der eine Frist automatisch durchsetzt. Wer einen zeitlichen Ablauf verspricht, muss deshalb erklären, welche Komponente die Übermittlung auslöst und was bei einem Ausfall dieser Komponente geschieht.
Ein Nonce-Wert ist nur einmal nutzbar
Zwei vorbereitete Transaktionen, die denselben gespeicherten Nonce referenzieren, konkurrieren miteinander. Wird eine davon gültig verarbeitet, verändert sich der Wert im Nonce Account. Die andere ist anschliessend nicht mehr gültig. Für mehrere gleichzeitig ausstehende, voneinander unabhängige Zahlungen benötigt ein System deshalb geeignete getrennte Nonce Accounts oder einen streng seriellen Ablauf. Wer die alte Nonce nach einer Zahlung aus einem lokalen Cache wiederverwendet, riskiert abgewiesene Transaktionen. Die Solana-Dokumentation empfiehlt, den Kontozustand vor dem Aufbau einer weiteren Transaktion erneut abzurufen.
Was bei einer fehlgeschlagenen Zahlung geschieht
Wichtig ist die Unterscheidung zwischen einer ungültigen Transaktion und einer Transaktion, deren eigentliche Ausführung scheitert. Wenn beispielsweise die Nonce Authority nicht unterschrieben hat oder das Konto nicht passt, kann die Transaktion bereits bei der Validierung verworfen werden; dann werden laut Solana-Dokumentation weder Gebühren erhoben noch Zustandsänderungen vorgenommen. Besteht sie dagegen die Nonce-Validierung und scheitert erst eine nachfolgende Instruktion, wird die Nonce dennoch weitergestellt und die Gebühr erhoben. Dadurch kann dieselbe signierte Transaktion nicht beliebig wiederholt werden. Eine Fehlermeldung darf deshalb niemals pauschal mit einem erneuten Absenden derselben Bytes beantwortet werden.
Gebühren und gebundenes SOL
Die Einrichtung eines Nonce Accounts benötigt SOL für die Kontofinanzierung und den vom Netzwerk geforderten Mindestbestand. Hinzu kommen die normalen Transaktionsgebühren für die Erstellung und spätere Nutzung. Der Mindestbetrag ist ein Netzwerkparameter und kann sich verändern; feste Beispielwerte aus alten Tutorials sind keine verlässliche Gebührenauskunft. Für die wirtschaftliche Beurteilung solltest du zwischen tatsächlich bezahlten Transaktionsgebühren und im Konto gebundenem SOL unterscheiden. Letzteres ist nicht automatisch verloren, kann aber bis zur ordnungsgemässen Schliessung beziehungsweise Entnahme des Kontos nicht frei anderweitig verwendet werden.
Beispielrechnung für ein Zahlungsprojekt
Angenommen, eine Organisation will 20 voneinander unabhängige Auszahlungen vorbereiten und jede erst nach zwei Genehmigungen senden. Werden alle 20 gleichzeitig offen gehalten, ist ein einziges Nonce-Konto keine saubere Lösung, weil die erste erfolgreiche Nutzung die übrigen Signaturen ungültig machen würde. Bei einem Entwurf mit 20 separaten Nonce-Konten ergibt sich die gebundene Kontofinanzierung aus 20 mal dem jeweils aktuell abgefragten Mindestbetrag. Beträgt dieser rein hypothetisch 0,0015 SOL je Konto, wären 0,0300 SOL gebunden. Das ist ausdrücklich eine Modellrechnung und kein bestätigter aktueller Netzwerkwert. Dazu kommen die Transaktionsgebühren. Vor einer Implementierung müssen alle Beträge live aus dem Netzwerk gelesen werden.
Sicherheitsrisiko: Schlüssel und Berechtigungen
Eine Durable Nonce löst nur das Problem der kurzen Blockhash-Gültigkeit. Die Signatursicherheit bleibt unverändert zentral. Eine kompromittierte Nonce Authority kann den Ablauf stören. Ein kompromittierter Zahlungsschlüssel kann unter Umständen unautorisierte Transaktionen signieren. Ein manipuliertes Benutzerinterface kann einen falschen Empfänger oder eine unerwünschte Instruktion anzeigen. Für grössere Beträge sind getrennte Rollen, Hardware-Signierung, verifizierte Transaktionsdetails und ein Vier-Augen-Prinzip sinnvoll. Ausserdem muss dokumentiert sein, wer Nonce-Konten verwaltet, wer sie schliessen darf und wie bei Schlüsselverlust reagiert wird.
Betriebsrisiko: veraltete Kontodaten und Parallelität
Ein häufiger technischer Fehler besteht darin, den gespeicherten Nonce zu lesen und danach anzunehmen, dass er unverändert bleibt. Eine andere Anwendung, ein Administrator oder eine bereits eingereichte Transaktion könnte ihn zwischenzeitlich weiterstellen. Ebenso können RPC-Endpunkte zeitweise unterschiedliche Zustände melden. Systeme sollten deshalb den Kontozustand unmittelbar vor der Vorbereitung überprüfen, eindeutige Auftragskennungen verwenden und den bestätigten Onchain-Status nach dem Versand auswerten. Ein blosses erfolgreiches Senden an einen RPC-Endpunkt ist noch kein Nachweis dafür, dass die Zahlung final verarbeitet wurde.
Vergleich: normaler Blockhash und Durable Nonce
Eine Standardtransaktion ist für alltägliche Wallet-Zahlungen meist einfacher. Sie benötigt kein zusätzliches Nonce-Konto und hat ein begrenztes Gültigkeitsfenster. Eine Durable-Nonce-Transaktion kann länger vorbereitet bleiben, verlangt dafür aber zusätzliche Kontoverwaltung, Authority-Signaturen und eine präzise Instruktionsreihenfolge. Für schnelle persönliche Überweisungen ist die zusätzliche Komplexität oft unnötig. Für Offline-Signierung oder abgestufte Freigabeprozesse kann sie einen klaren Nutzen haben. Welche Variante geeignet ist, entscheidet sich nicht am Coin-Kurs, sondern am operativen Zahlungsprozess und seinem Sicherheitsmodell.
Keine Garantie für endgültige Ausführung
Auch eine technisch korrekt signierte Durable-Nonce-Transaktion kann scheitern. Mögliche Gründe sind ein inzwischen veränderter Nonce, fehlendes SOL für Gebühren, nicht mehr erfüllte Programmbedingungen oder ein Netzwerkproblem. Der gespeicherte Nonce konserviert nicht den gesamten damaligen Kontozustand. Wenn eine Anwendung heute eine Zahlung vorbereitet und erst Wochen später sendet, können sich Token-Kontostände, Berechtigungen und Programmdaten verändert haben. Das Ergebnis muss daher bei Einreichung anhand der dann geltenden Regeln bewertet werden.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Code: AUSWANDERNSCHWEIZ
Mögliche zukünftige Änderungen
Die offizielle Solana-Dokumentation weist ausdrücklich darauf hin, dass Durable Nonces in einer zukünftigen Version möglicherweise abgeschafft werden könnten. Für langfristig geplante Geschäftsprozesse ist diese Einschränkung wesentlich. Du solltest eine Anwendung nicht so bauen, dass sie ohne Aktualisierung auf Dauer von unveränderten Protokollregeln ausgeht. Vor der produktiven Nutzung gehören die aktuellen Solana-Spezifikationen, Entwicklerhinweise und gegebenenfalls relevante SIMD-Diskussionen auf die Prüfliste. Aussagen aus älteren Tutorials können überholt sein.
Einordnung für Anleger in der Schweiz
Durable Nonces sind eine technische Funktion des Solana-Netzwerks und keine Anlageklasse. Sie begründen weder eine zusätzliche Rendite noch einen Anspruch auf eine bestimmte Kursentwicklung von SOL. Wer SOL hält, trägt weiterhin Marktpreis-, Verwahrungs- und Gegenparteirisiken. Bei einer geschäftlichen Zahlungsanwendung können zudem buchhalterische, regulatorische und steuerliche Fragen entstehen. Die steuerliche Behandlung hängt vom tatsächlichen Vorgang und der persönlichen oder betrieblichen Situation ab. Eine technische Offline-Signatur ersetzt keine Prüfung von Compliance, Zahlungsfreigaben oder Dokumentationspflichten.
FAQ: Kann ich eine Durable-Nonce-Transaktion zurücknehmen?
Eine noch nicht ausgeführte signierte Transaktion kann unter Umständen dadurch ungültig werden, dass die autorisierte Person den Nonce im zugehörigen Konto weiterstellt. Das ist aber kein allgemeiner Rückrufmechanismus für bereits ausgeführte Blockchain-Zahlungen. Wer eine Zahlung stoppen will, muss den aktuellen Kontozustand und den Bestätigungsstatus prüfen. Eine bereits final verarbeitete Überweisung lässt sich nicht durch blosses Ändern des Nonce rückgängig machen.
FAQ: Sind Durable Nonces dasselbe wie Ethereum-Nonces?
Nein. Der Begriff Nonce bezeichnet in verschiedenen Blockchains unterschiedliche Mechanismen. Auf Ethereum ist die Konto-Nonce unter anderem für die Reihenfolge und Einmaligkeit von Transaktionen relevant. Auf Solana ist der Durable Nonce ein gesondert gespeicherter Wert, der das Ablaufverhalten einer vorbereiteten Transaktion verändert. Die gleiche Bezeichnung darf nicht zu der Annahme führen, dass Wallets, Signaturabläufe oder Gebührenregeln identisch wären.
FAQ: Brauche ich als Privatanleger einen Nonce Account?
Für gewöhnliche SOL-Überweisungen aus einer modernen Wallet in der Regel nicht. Der Standardablauf ist einfacher und wird von den meisten Anwendungen automatisch abgewickelt. Ein Durable Nonce wird erst interessant, wenn du eine konkrete Anforderung an Offline-Signaturen, lange Freigabezeiten oder verzögerte Einreichung hast. Auch dann solltest du zuerst prüfen, ob deine Wallet und die verwendeten Programme den Mechanismus tatsächlich unterstützen.
Fazit
Solana Durable Nonces verlängern nicht die Lebensdauer eines Coins, sondern die mögliche Einreichungsfrist einer spezifisch aufgebauten und unterschriebenen Transaktion. Der Mechanismus eignet sich besonders für Offline-Signaturen und mehrstufige Zahlungsfreigaben. Er verlangt jedoch ein separates Nonce-Konto, korrekte Authority-Verwaltung, eine feste Instruktionsreihenfolge und eine saubere Behandlung von Fehlern. Der wichtigste Praxisgrundsatz lautet: Eine alte Signatur ist nur solange nutzbar, wie der zugehörige gespeicherte Nonce und alle übrigen Transaktionsbedingungen passen. Prüfe deshalb vor jeder Umsetzung die aktuelle Dokumentation und teste den Ablauf mit kleinen Beträgen.
Weitere passende Fachartikel
Quellen und weiterführende Literatur
Solana Foundation: Durable Nonces – https://solana.com/docs/core/transactions/durable-nonces . Solana Developers: Transaction Confirmation & Expiration – https://solana.com/developers/cookbook/transactions/confirmation . Solana Developers: Durable & Offline Transaction Signing using Nonces – https://solana.com/developers/cookbook/transactions/durable-nonces . Solana Foundation: Deferred Execution – https://solana.com/de/docs/payments/advanced-payments/deferred-execution . Dies sind offizielle technische Dokumentationen; sie beschreiben den Protokollmechanismus, nicht die Eignung einer bestimmten Geldanlage.
Kommentare