Brüder, lasst uns heute über ein Thema sprechen, das Leben retten kann—keiner soll sich an der Ausdrucksweise stören.
Der große Kuchen ist auf über 80.000 gestiegen—BTC ist wirklich stark!
In der Community gibt es jetzt eine typische Marotte: Kaum hört man von einer Transaktions-Hash, will man am liebsten sofort Champagner knallen lassen. Aber mal ehrlich: In einer Chain wie Dusk, die nach regelkonformer Finanzlogik strebt, liegt zwischen Confirmed (bestätigt) und Finalized (endgültig) eigentlich eine „Zeitlücke“, die man sich mit einer Lupe ansehen muss.
Ich habe das Fundament von Succinct Attestation noch einmal neu geordnet und festgestellt: Das Design ist ziemlich kontraintuitiv. Es ist nicht diese brutale Logik „Sobald ein Block kommt, ist alles wie festgenagelt“, sondern eher drei sehr stabile Stufen:
Zuerst bringt der Provisioner den Kandidatenblock auf die Bühne. Dann überprüft ein per Zufall ausgewähltes Komitee den Validierungsschritt—und selbst das ist noch nicht alles. Es braucht noch die Ratifikation: eine andere Gruppe von Schiedsrichtern muss den Hammer fallen lassen. Erst wenn der dritte Schritt—der Hammer—wirklich landet, gilt das Ledger als „mit Tinte als Beweis verewigt“. Die ersten beiden Schritte sind, so hart es klingt, immer noch nur „Entwürfe“.
Der Unterschied ist im Alltag bei normalen Transfers kaum spürbar, aber wenn du genauer darüber nachdenkst—was wäre, wenn das ein Wertpapier-Clearing auf Dusk Trade wäre, oder eine große Geldeingangsbuchung bei einer bestimmten Stelle?
Wenn man nur auf Contract Executed lauscht und das direkt verbucht, dann ist es zwar erstmal sauber. Aber sobald später Block Reverted kommt (merk dir: Das ist nicht einfach ein „Vertragsfehler“ wie bei einem Smart Contract—es ist auf der Konsensebene so etwas wie „Zeit zurückdrehen“), wie soll man dann mit der Buchhaltung aufgehen? Das Belegarchiv kommt unter Umständen nicht zurück. Die Dokumentation trennt deshalb bewusst Contract Revert und Block Revert: ersteres ist ein Stolpern im Code—letzteres bedeutet, dass der gesamte Block vom Konsens „abgeschossen“ wird. Zwei Arten des Scheiterns, zwei Arten der Rettung—und das zu vermischen ist, als würde man sich selbst eine Zeitzünder-Grube in den Boden graben.
Also sieh: Selbst wenn die Regeln noch so klar in Schwarz auf Weiß dastehen—wenn der Integrator schlampig arbeitet, bringt das nichts. Mich interessiert dabei nie, wie viele Sekunden im Schnitt $DUSK einen Block auswerfen. Ich beobachte vielmehr, ob die Leute, die Anwendungen bauen, wirklich Finalized als festen „Todesschlüssel“ behandeln—und wenn etwas schiefgeht, ob sie auch wirklich nicht aus der Spur geraten.
Falls es doch knallt: Gibt es dann ein auditierbares Re-Play-Tool-Set, mit dem sich die Geschäfts-Books gemeinsam mit der Chain „einen Rückschritt ins Bedauern“ machen lassen?
Die echte Abrechnungsendgültigkeit besteht nie darin, dass die Knoten hinter geschlossenen Türen genau einmal einen Beschluss fassen. Sie muss von dem finalized-Event ausgehen, dann Schritt für Schritt die Hürden der archivierenden Knoten durchlaufen und auch das Nacharbeiten bei unterbrochenen Verbindungen erledigen—und am Ende stabil in der Datenbank der Anwendung landen. Wenn dabei irgendein Teil zu früh „raus springt“, ist die Sache gelaufen.
@Dusk $DUSK #dusk
Der große Kuchen ist auf über 80.000 gestiegen—BTC ist wirklich stark!
In der Community gibt es jetzt eine typische Marotte: Kaum hört man von einer Transaktions-Hash, will man am liebsten sofort Champagner knallen lassen. Aber mal ehrlich: In einer Chain wie Dusk, die nach regelkonformer Finanzlogik strebt, liegt zwischen Confirmed (bestätigt) und Finalized (endgültig) eigentlich eine „Zeitlücke“, die man sich mit einer Lupe ansehen muss.
Ich habe das Fundament von Succinct Attestation noch einmal neu geordnet und festgestellt: Das Design ist ziemlich kontraintuitiv. Es ist nicht diese brutale Logik „Sobald ein Block kommt, ist alles wie festgenagelt“, sondern eher drei sehr stabile Stufen:
Zuerst bringt der Provisioner den Kandidatenblock auf die Bühne. Dann überprüft ein per Zufall ausgewähltes Komitee den Validierungsschritt—und selbst das ist noch nicht alles. Es braucht noch die Ratifikation: eine andere Gruppe von Schiedsrichtern muss den Hammer fallen lassen. Erst wenn der dritte Schritt—der Hammer—wirklich landet, gilt das Ledger als „mit Tinte als Beweis verewigt“. Die ersten beiden Schritte sind, so hart es klingt, immer noch nur „Entwürfe“.
Der Unterschied ist im Alltag bei normalen Transfers kaum spürbar, aber wenn du genauer darüber nachdenkst—was wäre, wenn das ein Wertpapier-Clearing auf Dusk Trade wäre, oder eine große Geldeingangsbuchung bei einer bestimmten Stelle?
Wenn man nur auf Contract Executed lauscht und das direkt verbucht, dann ist es zwar erstmal sauber. Aber sobald später Block Reverted kommt (merk dir: Das ist nicht einfach ein „Vertragsfehler“ wie bei einem Smart Contract—es ist auf der Konsensebene so etwas wie „Zeit zurückdrehen“), wie soll man dann mit der Buchhaltung aufgehen? Das Belegarchiv kommt unter Umständen nicht zurück. Die Dokumentation trennt deshalb bewusst Contract Revert und Block Revert: ersteres ist ein Stolpern im Code—letzteres bedeutet, dass der gesamte Block vom Konsens „abgeschossen“ wird. Zwei Arten des Scheiterns, zwei Arten der Rettung—und das zu vermischen ist, als würde man sich selbst eine Zeitzünder-Grube in den Boden graben.
Also sieh: Selbst wenn die Regeln noch so klar in Schwarz auf Weiß dastehen—wenn der Integrator schlampig arbeitet, bringt das nichts. Mich interessiert dabei nie, wie viele Sekunden im Schnitt $DUSK einen Block auswerfen. Ich beobachte vielmehr, ob die Leute, die Anwendungen bauen, wirklich Finalized als festen „Todesschlüssel“ behandeln—und wenn etwas schiefgeht, ob sie auch wirklich nicht aus der Spur geraten.
Falls es doch knallt: Gibt es dann ein auditierbares Re-Play-Tool-Set, mit dem sich die Geschäfts-Books gemeinsam mit der Chain „einen Rückschritt ins Bedauern“ machen lassen?
Die echte Abrechnungsendgültigkeit besteht nie darin, dass die Knoten hinter geschlossenen Türen genau einmal einen Beschluss fassen. Sie muss von dem finalized-Event ausgehen, dann Schritt für Schritt die Hürden der archivierenden Knoten durchlaufen und auch das Nacharbeiten bei unterbrochenen Verbindungen erledigen—und am Ende stabil in der Datenbank der Anwendung landen. Wenn dabei irgendein Teil zu früh „raus springt“, ist die Sache gelaufen.
@Dusk $DUSK #dusk