Ich habe seit ein paar Wochen eine kleine Position in $DUSK , hauptsächlich beobachtend. Nichts Dramatisches: Gestern habe ich ein wenig mehr dazugekauft, nachdem ich etwas in den Protokolldokumenten entdeckt hatte, worüber niemand zu sprechen schien.
Es geht darum, was passiert, wenn Konsens einfach … nicht mehr funktioniert. Nicht wegen eines Angriffs. Nicht wegen eines Bugs. Sondern einfach, weil Validatoren still werden.
Dusk hat etwas, das „Emergency Mode“ genannt wird, und mein erster Eindruck war, dass er dazu dient, Notfallblöcke zu erzeugen. Ganz so ist es aber nicht.
Der eigentliche Punkt ist die Wahrung der Lebendigkeit (Liveness), wenn die Beteiligung am Stake unzuverlässig wird.
Was meine Aufmerksamkeit geweckt hat: Dusk friert nicht ein, wenn Validatoren weiter fehlen. Stattdessen lässt es vorherige Konsensiterationen offen, während gleichzeitig neue Iterationen starten. Verbleibende Provisioner bekommen mehr Versuche, um eine Einigung zu finden, statt auf eine harte Wand zu treffen.
Auch die Prioritätsregel ist wichtig: Wenn mehrere Iterationen gleichzeitig erfolgreich sind, bevorzugt das Protokoll immer die Iteration mit der niedrigsten Nummer. So löst es das konkurrierende-Block-Problem, ohne dass man manuell eingreifen muss.
Und falls selbst das scheitert, springt die „Emergency Block Request“ (EBR) an.
Sobald EBRs, die die Mehrheit des Stakings repräsentieren, sich ansammeln, produziert die Chain einen leeren Block! Keine Transaktionen, nur Kontinuität und ein frischer Seed für die nächste Runde.
Diese Designentscheidung sagt mir, dass @Dusk nicht für ideale Bedingungen baut.
Es baut für den Moment, in dem diese Bedingungen brechen.
Was ich noch wirklich nicht weiß, ist, wie gut dieser Wiederherstellungspfad durchhält, wenn die Beteiligung über mehrere aufeinanderfolgende Runden hinweg weiter stark beeinträchtigt bleibt. Das wäre der Stresstest, den ich dokumentiert sehen möchte.
#Dusk #EmergencyMode #DuskEVM
Was ist am wichtigsten am Design von Dunks „Emergency Mode“?
Es geht darum, was passiert, wenn Konsens einfach … nicht mehr funktioniert. Nicht wegen eines Angriffs. Nicht wegen eines Bugs. Sondern einfach, weil Validatoren still werden.
Dusk hat etwas, das „Emergency Mode“ genannt wird, und mein erster Eindruck war, dass er dazu dient, Notfallblöcke zu erzeugen. Ganz so ist es aber nicht.
Der eigentliche Punkt ist die Wahrung der Lebendigkeit (Liveness), wenn die Beteiligung am Stake unzuverlässig wird.
Was meine Aufmerksamkeit geweckt hat: Dusk friert nicht ein, wenn Validatoren weiter fehlen. Stattdessen lässt es vorherige Konsensiterationen offen, während gleichzeitig neue Iterationen starten. Verbleibende Provisioner bekommen mehr Versuche, um eine Einigung zu finden, statt auf eine harte Wand zu treffen.
Auch die Prioritätsregel ist wichtig: Wenn mehrere Iterationen gleichzeitig erfolgreich sind, bevorzugt das Protokoll immer die Iteration mit der niedrigsten Nummer. So löst es das konkurrierende-Block-Problem, ohne dass man manuell eingreifen muss.
Und falls selbst das scheitert, springt die „Emergency Block Request“ (EBR) an.
Sobald EBRs, die die Mehrheit des Stakings repräsentieren, sich ansammeln, produziert die Chain einen leeren Block! Keine Transaktionen, nur Kontinuität und ein frischer Seed für die nächste Runde.
Diese Designentscheidung sagt mir, dass @Dusk nicht für ideale Bedingungen baut.
Es baut für den Moment, in dem diese Bedingungen brechen.
Was ich noch wirklich nicht weiß, ist, wie gut dieser Wiederherstellungspfad durchhält, wenn die Beteiligung über mehrere aufeinanderfolgende Runden hinweg weiter stark beeinträchtigt bleibt. Das wäre der Stresstest, den ich dokumentiert sehen möchte.
#Dusk #EmergencyMode #DuskEVM
Was ist am wichtigsten am Design von Dunks „Emergency Mode“?
🔗Chain liveness above all
66%
⚖️The iteration priority rule
17%
🧪Still needs a stress test
17%
6 Stimmen • Abstimmung beendet