#dusk $DUSK Das Finanz-Backoffice hat nicht am meisten Angst vor einem fehlgeschlagenen Handel, sondern vor einem Handel, der erfolgreich war – und der „erfolgreich“ ein zweites Mal erfolgreich war. Der Nutzer klickt zweimal; das Netzwerk läuft in einen Timeout und versucht automatisch erneut. Die Mitarbeitenden sehen, dass die Seite nicht reagiert, und senden die Anfrage ein weiteres Mal ab. Wenn derselbe Rücknahme- oder Umbuchungsauftrag zweimal ausgeführt wird, ist der zweite nicht Effizienz, sondern ein Unfall.
Das ist auch der Grund, warum ich beim erneuten Lesen des Whitepapers @Dusk das Moonlight-Account-Modell so spannend fand: Das nonce ist es wert, mehr erklärt zu werden als die vier Worte „öffentlicher Account“. Moonlight hält für jeden Public-Key-Account den Kontostand und ein nonce fest, das fortlaufend inkrementiert. Nachdem eine Transaktion ins Netzwerk gelangt, wird neben der Prüfung, ob der Kontostand die Überweisung, Einzahlungen und die maximalen Gas-Kosten abdeckt, auch die Signatur verifiziert. Außerdem muss die mitgelieferte nonce exakt gleich sein dem aktuellen Kontononce plus eins. Nachdem die Transaktion akzeptiert wurde, rückt die nonce des Accounts weiter nach vorne.
Übersetzt in klare Worte: Jede einzelne Anweisung muss eine eindeutige „Warteschlangen-Nummer“ bekommen. Wenn die Nummer bereits verwendet wurde, kann die alte signierte Transaktion – selbst wenn jemand sie erneut im Netzwerk broadcastet – nicht mehr unverändert ausgeführt werden; springt die Nummer, spielt das Netzwerk ebenfalls nicht so, als wäre alles in Ordnung mit der Reihenfolge. Das ist kein Technik-Showcase, sondern das Prinzip „dieselbe Autorisierung kann nicht mehrfach abgebucht werden“ wird in die Transaktionsebene eingraviert.
Das gilt besonders für regulierte Vermögenswerte. Doppelte Banküberweisungen können noch über Stornos/Überziehungen abgewickelt werden. Wenn aber im Wertpapierregister eine Zeile doppelt umbenannt wird, zieht das später Konsequenzen nach sich: für Bestände, Dividenden, Stimmrechte und Rücknahmeberechtigung. Der Fehler ist nicht nur eine einzelne Geldsumme, sondern das Kopieren des gesamten Datensatzes der Rechte.
Aber nonce ist auch kein Allheilmittel gegen Idempotenz-Probleme. Es verhindert zwar das Wiederabspielen einer identischen alten Transaktion, aber es verhindert nicht, dass eine Anwendung mit zwei aufeinanderfolgenden neuen nonces zwei Befehle absendet, die wirtschaftlich dieselbe Bedeutung haben. Zum Beispiel: Wenn das Frontend wirklich zwei gültige Rückgabeanfragen generiert, behandelt die Chain das als zwei unterschiedliche Transaktionen. Auf Business-Ebene muss man weiterhin Order-IDs, Volumen-/Limit-Checks, den Freigabestatus und das Blockieren doppelter Anfragen umsetzen.
Deshalb reicht es für mich nicht zu schauen, ob Dusk bei Finanz-Workflows schnell genug ist. Ich schaue auch, wie Wallets und Anwendungen mit „pending nonce“, fehlgeschlagenen Retries und Bestellnummern über Systemgrenzen hinweg umgehen. Die On-Chain-Reihenfolge ist eine Schutzlinie, die Business-Idempotenz ist die andere. Wenn man beide Schutzlinien in einem einzigen Satz „Replay-Schutz“ vermischt, wird der Unfall früher oder später genau aus der Lücke dazwischen herausbrechen.
Ein wirklich reifes Finanzsystem muss nicht nur sicherstellen, dass die korrekten Transaktionen ausgeführt werden können, sondern auch gewährleisten, dass dieselbe „korrekte“ Sache niemals zweimal ausgeführt wird.
Das ist auch der Grund, warum ich beim erneuten Lesen des Whitepapers @Dusk das Moonlight-Account-Modell so spannend fand: Das nonce ist es wert, mehr erklärt zu werden als die vier Worte „öffentlicher Account“. Moonlight hält für jeden Public-Key-Account den Kontostand und ein nonce fest, das fortlaufend inkrementiert. Nachdem eine Transaktion ins Netzwerk gelangt, wird neben der Prüfung, ob der Kontostand die Überweisung, Einzahlungen und die maximalen Gas-Kosten abdeckt, auch die Signatur verifiziert. Außerdem muss die mitgelieferte nonce exakt gleich sein dem aktuellen Kontononce plus eins. Nachdem die Transaktion akzeptiert wurde, rückt die nonce des Accounts weiter nach vorne.
Übersetzt in klare Worte: Jede einzelne Anweisung muss eine eindeutige „Warteschlangen-Nummer“ bekommen. Wenn die Nummer bereits verwendet wurde, kann die alte signierte Transaktion – selbst wenn jemand sie erneut im Netzwerk broadcastet – nicht mehr unverändert ausgeführt werden; springt die Nummer, spielt das Netzwerk ebenfalls nicht so, als wäre alles in Ordnung mit der Reihenfolge. Das ist kein Technik-Showcase, sondern das Prinzip „dieselbe Autorisierung kann nicht mehrfach abgebucht werden“ wird in die Transaktionsebene eingraviert.
Das gilt besonders für regulierte Vermögenswerte. Doppelte Banküberweisungen können noch über Stornos/Überziehungen abgewickelt werden. Wenn aber im Wertpapierregister eine Zeile doppelt umbenannt wird, zieht das später Konsequenzen nach sich: für Bestände, Dividenden, Stimmrechte und Rücknahmeberechtigung. Der Fehler ist nicht nur eine einzelne Geldsumme, sondern das Kopieren des gesamten Datensatzes der Rechte.
Aber nonce ist auch kein Allheilmittel gegen Idempotenz-Probleme. Es verhindert zwar das Wiederabspielen einer identischen alten Transaktion, aber es verhindert nicht, dass eine Anwendung mit zwei aufeinanderfolgenden neuen nonces zwei Befehle absendet, die wirtschaftlich dieselbe Bedeutung haben. Zum Beispiel: Wenn das Frontend wirklich zwei gültige Rückgabeanfragen generiert, behandelt die Chain das als zwei unterschiedliche Transaktionen. Auf Business-Ebene muss man weiterhin Order-IDs, Volumen-/Limit-Checks, den Freigabestatus und das Blockieren doppelter Anfragen umsetzen.
Deshalb reicht es für mich nicht zu schauen, ob Dusk bei Finanz-Workflows schnell genug ist. Ich schaue auch, wie Wallets und Anwendungen mit „pending nonce“, fehlgeschlagenen Retries und Bestellnummern über Systemgrenzen hinweg umgehen. Die On-Chain-Reihenfolge ist eine Schutzlinie, die Business-Idempotenz ist die andere. Wenn man beide Schutzlinien in einem einzigen Satz „Replay-Schutz“ vermischt, wird der Unfall früher oder später genau aus der Lücke dazwischen herausbrechen.
Ein wirklich reifes Finanzsystem muss nicht nur sicherstellen, dass die korrekten Transaktionen ausgeführt werden können, sondern auch gewährleisten, dass dieselbe „korrekte“ Sache niemals zweimal ausgeführt wird.
