Ich dachte früher, Block-Confirmations wären ganz einfach: Die Transaktion wird in einen Block aufgenommen, dann zählt man ein paar Blöcke weiter – im Grunde ist es dann schon sicher. Aber heute Abend, als ich das Dokument zur Transaktions-Lebensdauer der @Dusk -Transaktion gelesen habe, hat mich ein einzelner Satz ins Stocken gebracht: „Accepted blocks can still be reverted.“ Wenn etwas bereits accepted wurde, warum kann man es dann noch zurückrollen?
Ich habe es erst verstanden, als ich das 2024 Whitepaper gelesen habe. In einer Dusk-Consensus-Runde durchläuft man mehrere Iterationen (iterations). In derselben Runde können konkurrierende Blöcke entstehen. Selbst wenn ein Block mit einer höheren Iteration bereits accepted ist, kann ein fallback ausgelöst werden, solange ein konkurrierender Block mit einer niedrigeren Iteration die Bedingungen erfüllt.
„Auf die Chain gesehen“ heißt also nicht, dass es nicht ersetzbar ist.
Rolling Finality wirkt sogar noch weniger intuitiv. Das Whitepaper verwendet „n“, um die Anzahl der Iterationen zu bezeichnen, deren Attestation-Feststellung noch nicht abgeschlossen ist. Ein accepted Block muss erst nach 2×n fortlaufenden Folgeblöcken, die attested oder confirmed sind, in confirmed übergehen. Angenommen, n=3: Dann muss man die nächsten 6 Blöcke beobachten, die den Bedingungen entsprechen.
Hier ist mir klar geworden, dass „Confirmations“ kein einheitliches Maß ist. Obwohl etwas gleichermaßen on-chain ist, kann die Stabilität je nach Konsenshistorie unterschiedlich sein.
Die Empfehlung in den aktuellen Docs ist noch direkter: Weder „included“, „accepted“ noch „confirmed“ sollte man als Auszahl-/Zahlungsbestätigung (到账信号) betrachten – man muss auf die echte „finalized“-Stufe warten.
Für kleine Überweisungen kann der Unterschied vielleicht nur ein paar Sekunden betragen; aber wenn man das in eine große OTC- oder RWA-DvP-Settlement (Liefer-gegen-Zahlung) einbettet, sind „Transaktion gesehen“ und „unumkehrbare Abwicklung“ völlig zwei verschiedene Dinge. Wenn ich mir künftig große Dusk-Transaktionen ansehe, frage ich nur noch: Ist es finalized?
#dusk $DUSK @Dusk
Ich habe es erst verstanden, als ich das 2024 Whitepaper gelesen habe. In einer Dusk-Consensus-Runde durchläuft man mehrere Iterationen (iterations). In derselben Runde können konkurrierende Blöcke entstehen. Selbst wenn ein Block mit einer höheren Iteration bereits accepted ist, kann ein fallback ausgelöst werden, solange ein konkurrierender Block mit einer niedrigeren Iteration die Bedingungen erfüllt.
„Auf die Chain gesehen“ heißt also nicht, dass es nicht ersetzbar ist.
Rolling Finality wirkt sogar noch weniger intuitiv. Das Whitepaper verwendet „n“, um die Anzahl der Iterationen zu bezeichnen, deren Attestation-Feststellung noch nicht abgeschlossen ist. Ein accepted Block muss erst nach 2×n fortlaufenden Folgeblöcken, die attested oder confirmed sind, in confirmed übergehen. Angenommen, n=3: Dann muss man die nächsten 6 Blöcke beobachten, die den Bedingungen entsprechen.
Hier ist mir klar geworden, dass „Confirmations“ kein einheitliches Maß ist. Obwohl etwas gleichermaßen on-chain ist, kann die Stabilität je nach Konsenshistorie unterschiedlich sein.
Die Empfehlung in den aktuellen Docs ist noch direkter: Weder „included“, „accepted“ noch „confirmed“ sollte man als Auszahl-/Zahlungsbestätigung (到账信号) betrachten – man muss auf die echte „finalized“-Stufe warten.
Für kleine Überweisungen kann der Unterschied vielleicht nur ein paar Sekunden betragen; aber wenn man das in eine große OTC- oder RWA-DvP-Settlement (Liefer-gegen-Zahlung) einbettet, sind „Transaktion gesehen“ und „unumkehrbare Abwicklung“ völlig zwei verschiedene Dinge. Wenn ich mir künftig große Dusk-Transaktionen ansehe, frage ich nur noch: Ist es finalized?
#dusk $DUSK @Dusk
