Nach dem Update von Dusk habe ich, neugierig geworden, den On-Chain-Browser geöffnet, um die Anzahl der Bestätigungen nachzuschauen. Dabei ist mir ein leicht zu übersehendes Detail aufgefallen: Bei Dusk ist „Block bestätigt“ kein einfacher Schalter, sondern eine mehrstufige Status-Treppe, die sich nach und nach nach oben bewegt.
Die meisten verstehen die Endgültigkeit als entweder/oder: entweder nicht bestätigt, oder bestätigt und nicht mehr rückgängig zu machen. Das Design von Rolling Finality ist jedoch komplett anders. Ein Block muss von seiner Erzeugung bis zum vollständigen „Einfrieren“ vier Phasen durchlaufen: Zuerst accepted (angenommen). In dieser Phase kann er noch durch zuvor iterierte Kandidatenblöcke ersetzt werden. Danach kommt attested (attestiert/bestätigt im Sinne der Instanzen), und erst wenn alle vorherigen Iterationen gescheitert sind, kann er diesen Schritt erreichen; außerdem wird er dann nicht mehr ersetzt. Als Nächstes folgt confirmed (bestätigt). Dafür braucht es eine Stapelung zusätzlicher nachfolgender Blöcke. Schließlich final (endgültig): Dafür ist die Voraussetzung, dass sein Vaterblock bereits final ist – erst dann kann er selbst final werden.
Das Intuitionswidrigste an diesem Mechanismus ist: Wie viele nachfolgende Blöcke benötigt werden, damit ein Block aufrückt, ist keine feste Zahl. In den Regeln gibt es eine Variable n, die die Anzahl der Iterationen beschreibt, die „nicht erfolgreich“ waren, bevor dieser Block zustande kam. Je größer n ist, desto mehr nachfolgende Bestätigungsblöcke werden benötigt – und zwar nach dem Muster 2n. Anders gesagt: Je turbulenter die Geburt eines Blocks verlief, desto länger dauert es danach, bis er wirklich endgültig festgezurrt wird. Daher kann selbst dann, wenn in der Wallet „bestätigt“ steht, das tatsächliche Maß an „Einfrieren/Finalität“ sehr unterschiedlich ausfallen.
Der Vorteil dieses Designs ist, dass Knoten einen Block wesentlich feiner einschätzen können, nämlich wie sehr er „vertrauenswürdig“ ist – statt nur schwarz-weiß. Der Preis ist allerdings auch klar: Für normale Nutzer ist kaum erkennbar, auf welcher Stufe sich die eigene Transaktion gerade befindet. Die Wallet zeigt nur eine allgemeine „Bestätigt“-Anzeige; diese Schichtung wird vollständig verborgen. Ob dieser Informationsunterschied bei extremen Fork-Situationen ausgenutzt werden kann, ist fraglich.
Geht ihr normalerweise extra nach, um zu prüfen, bis zu welchem Bestätigungsgrad eure Transaktion gekommen ist – oder glaubt ihr einfach, was die Wallet mit „bestätigt“ sagt? Schreibt’s in die Kommentare.#dusk $DUSK @Dusk
Die meisten verstehen die Endgültigkeit als entweder/oder: entweder nicht bestätigt, oder bestätigt und nicht mehr rückgängig zu machen. Das Design von Rolling Finality ist jedoch komplett anders. Ein Block muss von seiner Erzeugung bis zum vollständigen „Einfrieren“ vier Phasen durchlaufen: Zuerst accepted (angenommen). In dieser Phase kann er noch durch zuvor iterierte Kandidatenblöcke ersetzt werden. Danach kommt attested (attestiert/bestätigt im Sinne der Instanzen), und erst wenn alle vorherigen Iterationen gescheitert sind, kann er diesen Schritt erreichen; außerdem wird er dann nicht mehr ersetzt. Als Nächstes folgt confirmed (bestätigt). Dafür braucht es eine Stapelung zusätzlicher nachfolgender Blöcke. Schließlich final (endgültig): Dafür ist die Voraussetzung, dass sein Vaterblock bereits final ist – erst dann kann er selbst final werden.
Das Intuitionswidrigste an diesem Mechanismus ist: Wie viele nachfolgende Blöcke benötigt werden, damit ein Block aufrückt, ist keine feste Zahl. In den Regeln gibt es eine Variable n, die die Anzahl der Iterationen beschreibt, die „nicht erfolgreich“ waren, bevor dieser Block zustande kam. Je größer n ist, desto mehr nachfolgende Bestätigungsblöcke werden benötigt – und zwar nach dem Muster 2n. Anders gesagt: Je turbulenter die Geburt eines Blocks verlief, desto länger dauert es danach, bis er wirklich endgültig festgezurrt wird. Daher kann selbst dann, wenn in der Wallet „bestätigt“ steht, das tatsächliche Maß an „Einfrieren/Finalität“ sehr unterschiedlich ausfallen.
Der Vorteil dieses Designs ist, dass Knoten einen Block wesentlich feiner einschätzen können, nämlich wie sehr er „vertrauenswürdig“ ist – statt nur schwarz-weiß. Der Preis ist allerdings auch klar: Für normale Nutzer ist kaum erkennbar, auf welcher Stufe sich die eigene Transaktion gerade befindet. Die Wallet zeigt nur eine allgemeine „Bestätigt“-Anzeige; diese Schichtung wird vollständig verborgen. Ob dieser Informationsunterschied bei extremen Fork-Situationen ausgenutzt werden kann, ist fraglich.
Geht ihr normalerweise extra nach, um zu prüfen, bis zu welchem Bestätigungsgrad eure Transaktion gekommen ist – oder glaubt ihr einfach, was die Wallet mit „bestätigt“ sagt? Schreibt’s in die Kommentare.#dusk $DUSK @Dusk