#dusk $DUSK
Der Ausdruck „Emergency Mode“ tauchte in Dusk’ Whitepaper immer wieder auf, und ich bin daran vorbeigegangen. Als ich den Abschnitt tatsächlich las, stellte sich heraus, dass der Mechanismus spezifischer ist, als der Name vermuten lässt.
Normale Dusk-Konsenslogik: Jede Runde läuft maximal bis zu 50 Iterationen. Jeder Schritt – Proposal, Validation, Ratification – hat ein Timeout. Wenn sich kein Quorum bildet, bevor das Timeout abläuft, wird der Schritt übersprungen und schließlich beginnt eine neue Iteration. Sequenziell, begrenzt, vorhersehbar.
Emergency Mode ist anders. Er wird nach 16 aufeinanderfolgenden fehlgeschlagenen Iterationen ausgelöst – wobei „fehlgeschlagen“ bedeutet, dass kein Quorum erreicht wurde, typischerweise weil Validatoren offline sind oder isoliert wurden. Sobald er ausgelöst ist: Schritt-Timeouts werden deaktiviert. Neue Iterationen werden gestartet, aber jede laufende Iteration bleibt aktiv, anstatt zu schließen. Mehrere offene Iterationen laufen parallel. Das erhöht die Wahrscheinlichkeit, einen Block zu erzeugen. Es erhöht auch die Wahrscheinlichkeit von Forks.
Forks im Emergency Mode werden gelöst, indem der Block aus der Iterationsnummer mit der niedrigsten Nummer ausgewählt wird. Wenn das Netzwerk immer noch keinen Block bilden kann, bleibt als letzte Instanz ein Emergency Block: ein leerer Block ohne Transaktionen, signiert von Dusk als Entity, die ihren globalen Public Key nutzt. Provider, die eine Mehrheit am Stake halten, fordern ihn an.
Warum läuft das Netzwerk also nicht einfach den Emergency Mode, wenn es schneller sein will.
Der Normalmodus handelt etwas Tempo gegen sauberere Finalität ein. Parallele offene Iterationen erhöhen die Liveness unter Stress, bringen aber Komplexität mit. Der leere-Block-Fallback ist ein zentralisierender Eingriff – die Chain bewegt sich weiter, aber Dusk als Entity ist diejenige, die sie bewegt.
Ich finde die Emergency-Block-Designfrage tatsächlich am interessantesten – denn das bedeutet, dass die Liveness-Garantie letztlich von der Verfügbarkeit und Bereitschaft der Dusk-Entity abhängt, zu signieren. Protokollsicherheit und Dezentralisierung ziehen dort leicht in verschiedene Richtungen.
Was ich nicht gesehen habe, ist eine Erklärung dafür, was mit Transaktionen passiert, die sich zum Zeitpunkt befinden, wenn ein Emergency Block einen normalen Block ersetzt – ob sie in der nächsten Runde wieder aufgenommen werden oder ob sie verworfen werden. @Dusk
$DUSK #dusk
Der Ausdruck „Emergency Mode“ tauchte in Dusk’ Whitepaper immer wieder auf, und ich bin daran vorbeigegangen. Als ich den Abschnitt tatsächlich las, stellte sich heraus, dass der Mechanismus spezifischer ist, als der Name vermuten lässt.
Normale Dusk-Konsenslogik: Jede Runde läuft maximal bis zu 50 Iterationen. Jeder Schritt – Proposal, Validation, Ratification – hat ein Timeout. Wenn sich kein Quorum bildet, bevor das Timeout abläuft, wird der Schritt übersprungen und schließlich beginnt eine neue Iteration. Sequenziell, begrenzt, vorhersehbar.
Emergency Mode ist anders. Er wird nach 16 aufeinanderfolgenden fehlgeschlagenen Iterationen ausgelöst – wobei „fehlgeschlagen“ bedeutet, dass kein Quorum erreicht wurde, typischerweise weil Validatoren offline sind oder isoliert wurden. Sobald er ausgelöst ist: Schritt-Timeouts werden deaktiviert. Neue Iterationen werden gestartet, aber jede laufende Iteration bleibt aktiv, anstatt zu schließen. Mehrere offene Iterationen laufen parallel. Das erhöht die Wahrscheinlichkeit, einen Block zu erzeugen. Es erhöht auch die Wahrscheinlichkeit von Forks.
Forks im Emergency Mode werden gelöst, indem der Block aus der Iterationsnummer mit der niedrigsten Nummer ausgewählt wird. Wenn das Netzwerk immer noch keinen Block bilden kann, bleibt als letzte Instanz ein Emergency Block: ein leerer Block ohne Transaktionen, signiert von Dusk als Entity, die ihren globalen Public Key nutzt. Provider, die eine Mehrheit am Stake halten, fordern ihn an.
Warum läuft das Netzwerk also nicht einfach den Emergency Mode, wenn es schneller sein will.
Der Normalmodus handelt etwas Tempo gegen sauberere Finalität ein. Parallele offene Iterationen erhöhen die Liveness unter Stress, bringen aber Komplexität mit. Der leere-Block-Fallback ist ein zentralisierender Eingriff – die Chain bewegt sich weiter, aber Dusk als Entity ist diejenige, die sie bewegt.
Ich finde die Emergency-Block-Designfrage tatsächlich am interessantesten – denn das bedeutet, dass die Liveness-Garantie letztlich von der Verfügbarkeit und Bereitschaft der Dusk-Entity abhängt, zu signieren. Protokollsicherheit und Dezentralisierung ziehen dort leicht in verschiedene Richtungen.
Was ich nicht gesehen habe, ist eine Erklärung dafür, was mit Transaktionen passiert, die sich zum Zeitpunkt befinden, wenn ein Emergency Block einen normalen Block ersetzt – ob sie in der nächsten Runde wieder aufgenommen werden oder ob sie verworfen werden. @Dusk
$DUSK #dusk
