Als ich diese Passage zum SA-Konsens gelesen habe, war meine erste Reaktion, nach dem Parameter für die endgültige Endgültigkeit zu suchen. Das Whitepaper schreibt „innerhalb von Sekunden wird Finalität erreicht“, aber es nennt nicht genau, wie viele Sekunden. Diese Unschärfe macht mich ein wenig unruhig, aber sie brachte mich auch dazu, die dahinterliegende Logik wirklich verstehen zu wollen.
Zuerst ein Vergleich: Die Finalität von Bitcoin $DUSK beruht auf Wahrscheinlichkeit. Mit sechs Blockbestätigungen dauert es ungefähr eine Stunde; je länger du wartest, desto sicherer ist die Transaktion davor, dass sie zurückgerollt wird. Die PoS-Finalität von Ethereum über den Casper-Mechanismus erfordert zwei Epochs, also etwa 12,8 Minuten. Dusk behauptet, es brauche nur Sekunden – aber warum eigentlich?
Der Schlüssel liegt im deterministischen Zuteilungsmechanismus. Das Whitepaper sagt, dass der DS-Algorithmus vor Beginn jeder Runde bereits im Voraus ausgewählt hat, wer den Block generiert und wer im Abstimmungsgremium sitzt. Dieses „Vorherwissen“ bedeutet, dass die Wähler bereits vorbereitet sind, bevor der Block überhaupt erzeugt wird: kein kurzfristiges „Ziehen von Leuten“, keine Notwendigkeit, dass das gesamte Netzwerk per Broadcast nach Konsens sucht. Die Kommunikationskosten werden dadurch stark reduziert.
Ich habe den Ablauf einmal zerlegt. Jede Runde umfasst mehrere Iterationen, und jede Iteration hat drei Phasen: Vorschlag, Abstimmung und Bestätigung. Das Abstimmungsgremium besteht nur aus den ausgewählten Verifizierern – nicht aus dem gesamten Netzwerk. Die Anzahl der Knoten, die an der Abstimmung teilnehmen, wird auf einen relativ kleinen Bereich begrenzt. Dadurch ist der Kommunikationsaufwand für den Abstimmungsprozess sehr gering; es reicht, wenn man etwa @Dusk -malig Informationen austauscht, um damit fertig zu werden.
Aber hier gibt es etwas, das ich nicht ganz durchdringen kann. Das Whitepaper erwähnt den Begriff „rollierende Finalität“, aber erläutert den konkreten Mechanismus nicht. Mein Verständnis ist, dass es dabei nicht um eine einmalige, feste Sperrung der Finalität geht, sondern dass mit dem kontinuierlichen Generieren neuer Blöcke die Wahrscheinlichkeit für die Finalität des vorherigen Blocks Schritt für Schritt steigt. Wenn das stimmt, dann könnte sich „Sekunden“ auf die Bestätigung der ersten Ebene beziehen – und nicht auf eine endgültig unwiderrufliche Finalität.#dusk
Außerdem ist mir aufgefallen, dass das Whitepaper keine exakte Anzahl an Sekunden angibt. 3 Sekunden und 9 Sekunden werden zwar beide „Sekunden“ genannt, aber für einen Finanzkontext ist der Unterschied komplett entscheidend. Diese Frage kann ich bislang nicht direkt aus dem Whitepaper herausfinden; vielleicht muss ich auf die tatsächlichen Testdaten nach dem Go-Live des Mainnets warten.
Zuerst ein Vergleich: Die Finalität von Bitcoin $DUSK beruht auf Wahrscheinlichkeit. Mit sechs Blockbestätigungen dauert es ungefähr eine Stunde; je länger du wartest, desto sicherer ist die Transaktion davor, dass sie zurückgerollt wird. Die PoS-Finalität von Ethereum über den Casper-Mechanismus erfordert zwei Epochs, also etwa 12,8 Minuten. Dusk behauptet, es brauche nur Sekunden – aber warum eigentlich?
Der Schlüssel liegt im deterministischen Zuteilungsmechanismus. Das Whitepaper sagt, dass der DS-Algorithmus vor Beginn jeder Runde bereits im Voraus ausgewählt hat, wer den Block generiert und wer im Abstimmungsgremium sitzt. Dieses „Vorherwissen“ bedeutet, dass die Wähler bereits vorbereitet sind, bevor der Block überhaupt erzeugt wird: kein kurzfristiges „Ziehen von Leuten“, keine Notwendigkeit, dass das gesamte Netzwerk per Broadcast nach Konsens sucht. Die Kommunikationskosten werden dadurch stark reduziert.
Ich habe den Ablauf einmal zerlegt. Jede Runde umfasst mehrere Iterationen, und jede Iteration hat drei Phasen: Vorschlag, Abstimmung und Bestätigung. Das Abstimmungsgremium besteht nur aus den ausgewählten Verifizierern – nicht aus dem gesamten Netzwerk. Die Anzahl der Knoten, die an der Abstimmung teilnehmen, wird auf einen relativ kleinen Bereich begrenzt. Dadurch ist der Kommunikationsaufwand für den Abstimmungsprozess sehr gering; es reicht, wenn man etwa @Dusk -malig Informationen austauscht, um damit fertig zu werden.
Aber hier gibt es etwas, das ich nicht ganz durchdringen kann. Das Whitepaper erwähnt den Begriff „rollierende Finalität“, aber erläutert den konkreten Mechanismus nicht. Mein Verständnis ist, dass es dabei nicht um eine einmalige, feste Sperrung der Finalität geht, sondern dass mit dem kontinuierlichen Generieren neuer Blöcke die Wahrscheinlichkeit für die Finalität des vorherigen Blocks Schritt für Schritt steigt. Wenn das stimmt, dann könnte sich „Sekunden“ auf die Bestätigung der ersten Ebene beziehen – und nicht auf eine endgültig unwiderrufliche Finalität.#dusk
Außerdem ist mir aufgefallen, dass das Whitepaper keine exakte Anzahl an Sekunden angibt. 3 Sekunden und 9 Sekunden werden zwar beide „Sekunden“ genannt, aber für einen Finanzkontext ist der Unterschied komplett entscheidend. Diese Frage kann ich bislang nicht direkt aus dem Whitepaper herausfinden; vielleicht muss ich auf die tatsächlichen Testdaten nach dem Go-Live des Mainnets warten.