Das Detail, das mich zweimal hinschauen ließ: Auf Dusk ist „accepted“ nicht dasselbe wie final.
Ich erwartete, dass eine Blockchain für finanzielle Abwicklung erfolgreiche Ausführung als Ziellinie behandelt. Die eigenen L1-Integrationsdokumente von Dusk sind strenger: Eine Transaktion kann eingereicht und HTTP 202 „Accepted“ erhalten, in den Mempool eines Knotens gelangen, in einem akzeptierten Block ausgeführt werden, ohne Ausführungsfehler — und dennoch nicht zahlungsfinal sein.
Die Dokumentation sagt ausdrücklich, dass „accepted“-Blöcke weiterhin rückgängig gemacht werden können. Endgültigkeit tritt erst dann ein, wenn ein Ereignis „blocks/statechange“ den Block als „finalized“ markiert. Dusk warnt sogar Integratoren, „included“, „accepted“ oder „confirmed“ nicht als Signal für Zahlungsfinalität zu verwenden.
Das klingt zunächst wie Implementierungsdetails, bis man sich vor Augen führt, worauf DUSK abzielt: regulierte Finanzanwendungen. Für Börsen, Zahlungsabwickler oder Systeme mit tokenisierten Vermögenswerten kann die Verwechslung von Ausführung mit Abwicklung zu einem Buchhaltungsproblem werden — nicht nur zu einem UX-Thema.
Was meine Aufmerksamkeit geweckt hat, ist die Spannung: Dusk beschreibt deterministische Finalität nach der Ratifizierung, aber Anwendungen müssen diese explizite Finalisierungsgrenze dennoch respektieren. Das wirkt weniger wie ein Widerspruch und mehr wie ausgereifte Settlement-Ingenieurskunst.
Darauf schaue ich jetzt: wie konsequent Wallets und Finanz-Apps diese Unterscheidung offenlegen, statt alles zu einem einzigen „confirmed“-Status zusammenzufassen.
@Dusk_Foundation $DUSK #dusk
Ich erwartete, dass eine Blockchain für finanzielle Abwicklung erfolgreiche Ausführung als Ziellinie behandelt. Die eigenen L1-Integrationsdokumente von Dusk sind strenger: Eine Transaktion kann eingereicht und HTTP 202 „Accepted“ erhalten, in den Mempool eines Knotens gelangen, in einem akzeptierten Block ausgeführt werden, ohne Ausführungsfehler — und dennoch nicht zahlungsfinal sein.
Die Dokumentation sagt ausdrücklich, dass „accepted“-Blöcke weiterhin rückgängig gemacht werden können. Endgültigkeit tritt erst dann ein, wenn ein Ereignis „blocks/statechange“ den Block als „finalized“ markiert. Dusk warnt sogar Integratoren, „included“, „accepted“ oder „confirmed“ nicht als Signal für Zahlungsfinalität zu verwenden.
Das klingt zunächst wie Implementierungsdetails, bis man sich vor Augen führt, worauf DUSK abzielt: regulierte Finanzanwendungen. Für Börsen, Zahlungsabwickler oder Systeme mit tokenisierten Vermögenswerten kann die Verwechslung von Ausführung mit Abwicklung zu einem Buchhaltungsproblem werden — nicht nur zu einem UX-Thema.
Was meine Aufmerksamkeit geweckt hat, ist die Spannung: Dusk beschreibt deterministische Finalität nach der Ratifizierung, aber Anwendungen müssen diese explizite Finalisierungsgrenze dennoch respektieren. Das wirkt weniger wie ein Widerspruch und mehr wie ausgereifte Settlement-Ingenieurskunst.
Darauf schaue ich jetzt: wie konsequent Wallets und Finanz-Apps diese Unterscheidung offenlegen, statt alles zu einem einzigen „confirmed“-Status zusammenzufassen.
@Dusk_Foundation $DUSK #dusk