#dusk $DUSK @Dusk
Ich hatte so einen Moment, als ich das Dusk-Whitepaper las, bei dem ich kurz innehalten und ein paar Zeilen zurückgehen musste.

Der Abschnitt zur Konsensbildung war komplexer, als ich erwartet hatte. Zunächst suchte ich nach der üblichen einfachen Erklärung dafür, wie Blöcke genehmigt werden, aber Dusk ging anders vor, sodass ich langsamer wurde und den Prozess tatsächlich nachvollzogen habe.

Besonders aufgefallen ist mir die Idee, gewöhnliche Transaktionsknoten von der aufwendigeren Arbeit zur Überprüfung, zum Voten und zur Notarisierung zu trennen. Anfangs fragte ich mich, ob das das Netzwerk schwerer zu koordinieren machen würde. Dann wurde die Begründung klarer: Wenn diese intensiven Aufgaben bei Provisionern gebündelt werden, kann man unnötigen Netzwerkverkehr reduzieren, während der Konsensprozess dennoch unterstützt wird.

Das Paper beschreibt Dusk’s SBA*‑Konsens als ein Ziel, das Gleichgewicht zwischen Sicherheit, Effizienz und Flexibilität zu finden. Eine Einzelheit, die ich notiert habe, war die im Paper genannte Finalitäts-Spanne: Unter den beschriebenen Annahmen kann die Blockfinalität schon nach mindestens 2 Runden eintreten, während das Worst-Case-Szenario als 9 Runden beschrieben wurde.

Ich würde eine Zahl aus einem alten Whitepaper nicht als aktuellen Leistungsversprechen betrachten. Genau das habe ich korrigiert – meine eigene Denkweise.

Für mich war der interessante Teil ohnehin nicht die Zahl. Es war zu sehen, wie viel von Dusk’s Design damit beginnt, das Problem der Koordination von Privatsphäre, Teilnahme und Finalität anzugehen, ohne das Netzwerk unnötig schwer zu machen.

Dadurch habe ich mir $DUSK a ein wenig anders angesehen.

Wie viel Aufmerksamkeit widmest du dem Konsensdesign, wenn du eine Blockchain bewertest?

#dusk @Dusk $TRUMP
Was ist am wichtigsten, wenn man die Blockchain-Architektur von Dusk bewertet?