#dusk $DUSK 证券-Backoffice: der gefährlichste Hinweis – nicht unbedingt „fehlgeschlagen“, sondern „bereits bearbeitet“ (accepted). Ein Fehlschlag stoppt die Leute wenigstens. „Bereits bearbeitet“ wird hingegen viel zu leicht als „Geld und Ware sind endgültig ausgetauscht“ verstanden. Auch on-chain gilt dasselbe: Wenn ein Block in das lokale Ledger gelangt, heißt das nicht, dass er bereits den letzten, absolut nicht ersetzbaren Schritt erreicht hat.
Ich habe die Rolling-Finality im Whitepaper von @Dusk neu gelesen und erst dabei erkannt: Dusk hat nicht alle „Bestätigungen“ zu einem einzigen Wort vermischt, sondern in vier Zustände aufgeteilt: accepted, attested, confirmed und final. Ein accepted-Block hat zwar einen Erfolgsnachweis erhalten, kann aber dennoch ersetzt werden – etwa wenn er aus einer höheren Iteration stammt und die vorherigen niedrigen Iterationen keine Fehlschlagsnachweise enthalten. Wenn später ein legaler Block aus einer niedrigeren Iteration auftaucht, wird der accepted-Block ersetzt, und die nachfolgenden Blöcke gehen dann ebenfalls mit zurück.
attested ist robuster, weil es entweder aus Iteration 0 stammt oder weil die vorherigen Iterationen bereits Fehlschlagsnachweise hinterlassen haben; confirmed braucht zusätzlich, dass nachfolgende Blöcke weiterhin dazu beitragen, dass die aktuelle Kette glaubwürdig bleibt. Nur final bedeutet: Der Parent-Block ist ebenfalls final; der gesamte Ahnenpfad ist „zugemacht“, nicht mehr ersetzbar.
Das Whitepaper gibt ein konkretes Beispiel: Ein Block entsteht in der 5. Iteration. Davor gab es aber nur zwei Iterationen mit Fehlschlagsnachweisen – deshalb wird er zunächst als accepted markiert. Er muss dann noch 4 aufeinanderfolgende attested- oder confirmed-Blöcke abwarten, bevor er confirmed wird. Das heißt: „Es ist bereits ein Block ausgegeben“ und „man kann die Wertpapierabwicklung als unwiderrufliche Tatsache behandeln“ können tatsächlich ein paar Schritte auseinanderliegen.
Ich finde diese Ehrlichkeit gut. Das Finanzsystem fürchtet am meisten, wenn Wahrscheinlichkeiten in ein grünes Häkchen versteckt werden. Aber es gibt auch Produktteams Hausaufgaben: Welche Status werden in der Wallet, an der Handelsschnittstelle und im Registersystem wirklich angezeigt? Wenn Nutzer sehen, dass es accepted ist – können sie dann weiter übertragen oder einlösen? Wenn das UI überall einfach „Erfolg“ schreibt, wird selbst ein noch so strenger Konsenszustand durch Copywriting geglättet.
Deshalb schaue ich mir Dusk’s Sekundenfinalität nicht nur an, wie viele Sekunden im Durchschnitt benötigt werden, sondern auch daran, wie die Verteilung aussieht, wenn Iterationen „abnormal“ sind – wie sie von accepted zu final kommen – und ob die Anwendung wirklich erst dann „abhakt“, wenn final erreicht ist. Finalität ist keine Marketing-Zahl, sondern eine Disziplin: Man darf „fast fertig“ nicht als „schon fertig“ verkaufen.
Ich habe die Rolling-Finality im Whitepaper von @Dusk neu gelesen und erst dabei erkannt: Dusk hat nicht alle „Bestätigungen“ zu einem einzigen Wort vermischt, sondern in vier Zustände aufgeteilt: accepted, attested, confirmed und final. Ein accepted-Block hat zwar einen Erfolgsnachweis erhalten, kann aber dennoch ersetzt werden – etwa wenn er aus einer höheren Iteration stammt und die vorherigen niedrigen Iterationen keine Fehlschlagsnachweise enthalten. Wenn später ein legaler Block aus einer niedrigeren Iteration auftaucht, wird der accepted-Block ersetzt, und die nachfolgenden Blöcke gehen dann ebenfalls mit zurück.
attested ist robuster, weil es entweder aus Iteration 0 stammt oder weil die vorherigen Iterationen bereits Fehlschlagsnachweise hinterlassen haben; confirmed braucht zusätzlich, dass nachfolgende Blöcke weiterhin dazu beitragen, dass die aktuelle Kette glaubwürdig bleibt. Nur final bedeutet: Der Parent-Block ist ebenfalls final; der gesamte Ahnenpfad ist „zugemacht“, nicht mehr ersetzbar.
Das Whitepaper gibt ein konkretes Beispiel: Ein Block entsteht in der 5. Iteration. Davor gab es aber nur zwei Iterationen mit Fehlschlagsnachweisen – deshalb wird er zunächst als accepted markiert. Er muss dann noch 4 aufeinanderfolgende attested- oder confirmed-Blöcke abwarten, bevor er confirmed wird. Das heißt: „Es ist bereits ein Block ausgegeben“ und „man kann die Wertpapierabwicklung als unwiderrufliche Tatsache behandeln“ können tatsächlich ein paar Schritte auseinanderliegen.
Ich finde diese Ehrlichkeit gut. Das Finanzsystem fürchtet am meisten, wenn Wahrscheinlichkeiten in ein grünes Häkchen versteckt werden. Aber es gibt auch Produktteams Hausaufgaben: Welche Status werden in der Wallet, an der Handelsschnittstelle und im Registersystem wirklich angezeigt? Wenn Nutzer sehen, dass es accepted ist – können sie dann weiter übertragen oder einlösen? Wenn das UI überall einfach „Erfolg“ schreibt, wird selbst ein noch so strenger Konsenszustand durch Copywriting geglättet.
Deshalb schaue ich mir Dusk’s Sekundenfinalität nicht nur an, wie viele Sekunden im Durchschnitt benötigt werden, sondern auch daran, wie die Verteilung aussieht, wenn Iterationen „abnormal“ sind – wie sie von accepted zu final kommen – und ob die Anwendung wirklich erst dann „abhakt“, wenn final erreicht ist. Finalität ist keine Marketing-Zahl, sondern eine Disziplin: Man darf „fast fertig“ nicht als „schon fertig“ verkaufen.
