Als ich mir dieses Mal die Transaktionslebenszyklen von Dusk angesehen habe, war es vor allem eins, das mich hat innehalten lassen: Es behandelt „Bestätigung“ und „endgültige Fertigstellung“ nicht als etwas wirklich Unterschiedliches.
Die offizielle Dokumentation zerlegt eine Transaktion sehr klar: Zuerst wird sie aus dem Mempool entfernt, dann in „confirmed“ überführt, und erst wenn der Block Finalität erreicht, wird die Transaktion in einen endgültig unumkehrbaren Zustand überführt.
Auf den ersten Blick wirkt das wie eine zusätzliche Zustandsstufe.
Aber wenn man aus der Perspektive von Wertpapier-/Vermögensabrechnung darauf schaut, ist dieser Unterschied entscheidend.
Bei einer normalen Überweisung kann man bei „confirmed“ vielleicht einfach direkt mit dem nächsten Schritt weitermachen.
Doch bei Wertpapieren, Zahlungen oder der Abwicklung von Vermögenswerten ist das anders.
Was du wirklich bestätigen musst, ist nicht:
„Diese Transaktion wird sehr wahrscheinlich nicht scheitern.“
Sondern:
„Kann dieser Vermögenswert jetzt tatsächlich als endgültiges Ergebnis verbucht werden?“
> Für Finanzmärkte sind „sehr wahrscheinlich kein Rollback“ und „bereits unumkehrbar“ nicht dasselbe.
Ducks Design trennt diese beiden Phasen: Es schafft Klarheit, indem es „zuerst das Ergebnis sehen“ und „das Ergebnis ist schon fest zementiert“ getrennt behandelt.
Das bringt jedoch einen sehr realen Aufwand mit sich.
Auf Finalität zu warten bedeutet, dass eine Anwendung nicht einfach nur auf den ersten Bestätigungsstatus starren und dann sofort alle nachfolgenden Abläufe komplett durchziehen kann.
Doch dafür erhält man klarere Abgrenzungen der Abrechnung.
Bei gewöhnlichen On-Chain-Transfers mag diese Differenz weniger auffallen.
Bei Transaktionen, bei denen tokenisierte Wertpapiere, Payment-Legs und Asset-Legs gleichzeitig vorangetrieben werden, sorgt eine einmal unscharf gewordene Abgrenzung dafür, dass spätere Abwicklung, Buchung und Berechtigungsprüfungen durcheinander geraten.
Darum glaube ich heute immer stärker, dass Dusk „deterministic settlement“ nicht nur für „Schnelligkeit“ betont.
Es geht mehr darum:
**Wann genau man diese Transaktion von „passiert“ zu „endgültig feststeht“ überführen kann.**
Wenn du das Backoffice einer Finanzinstitution betreust, würdest du dann nicht eher darauf achten, ob man den Abschluss quasi sofort sieht – oder würdest du lieber etwas länger warten, bis die klare Finalität erreicht ist, und erst dann den gesamten Vermögenswert offiziell verbuchen?@Dusk
#dusk $DUSK
Die offizielle Dokumentation zerlegt eine Transaktion sehr klar: Zuerst wird sie aus dem Mempool entfernt, dann in „confirmed“ überführt, und erst wenn der Block Finalität erreicht, wird die Transaktion in einen endgültig unumkehrbaren Zustand überführt.
Auf den ersten Blick wirkt das wie eine zusätzliche Zustandsstufe.
Aber wenn man aus der Perspektive von Wertpapier-/Vermögensabrechnung darauf schaut, ist dieser Unterschied entscheidend.
Bei einer normalen Überweisung kann man bei „confirmed“ vielleicht einfach direkt mit dem nächsten Schritt weitermachen.
Doch bei Wertpapieren, Zahlungen oder der Abwicklung von Vermögenswerten ist das anders.
Was du wirklich bestätigen musst, ist nicht:
„Diese Transaktion wird sehr wahrscheinlich nicht scheitern.“
Sondern:
„Kann dieser Vermögenswert jetzt tatsächlich als endgültiges Ergebnis verbucht werden?“
> Für Finanzmärkte sind „sehr wahrscheinlich kein Rollback“ und „bereits unumkehrbar“ nicht dasselbe.
Ducks Design trennt diese beiden Phasen: Es schafft Klarheit, indem es „zuerst das Ergebnis sehen“ und „das Ergebnis ist schon fest zementiert“ getrennt behandelt.
Das bringt jedoch einen sehr realen Aufwand mit sich.
Auf Finalität zu warten bedeutet, dass eine Anwendung nicht einfach nur auf den ersten Bestätigungsstatus starren und dann sofort alle nachfolgenden Abläufe komplett durchziehen kann.
Doch dafür erhält man klarere Abgrenzungen der Abrechnung.
Bei gewöhnlichen On-Chain-Transfers mag diese Differenz weniger auffallen.
Bei Transaktionen, bei denen tokenisierte Wertpapiere, Payment-Legs und Asset-Legs gleichzeitig vorangetrieben werden, sorgt eine einmal unscharf gewordene Abgrenzung dafür, dass spätere Abwicklung, Buchung und Berechtigungsprüfungen durcheinander geraten.
Darum glaube ich heute immer stärker, dass Dusk „deterministic settlement“ nicht nur für „Schnelligkeit“ betont.
Es geht mehr darum:
**Wann genau man diese Transaktion von „passiert“ zu „endgültig feststeht“ überführen kann.**
Wenn du das Backoffice einer Finanzinstitution betreust, würdest du dann nicht eher darauf achten, ob man den Abschluss quasi sofort sieht – oder würdest du lieber etwas länger warten, bis die klare Finalität erreicht ist, und erst dann den gesamten Vermögenswert offiziell verbuchen?@Dusk
#dusk $DUSK