Ich habe tiefer in den Dusks Emergency Mode hineingeschaut. Der interessante Teil ist nicht einfach nur, dass das Netzwerk einen Fallback hat, wenn der Konsens fehlschlägt.

Stell dir vor, dass plötzlich die meisten Provisionierer offline gehen. Kein Angriff, kein Block – sie nehmen einfach nicht mehr teil. Ein Konsenssystem, das auf Teilnahme aufgebaut ist, könnte schnell ein Problem mit der Lebendigkeit (Liveness) bekommen.

Dusks Emergency Mode ist ein Weg, mit diesem Problem umzugehen.

Dusk geht das anders an. Dusks Emergency Mode ermöglicht es, neue Konsens-Iterationen zu beginnen, während frühere noch offen bleiben, sodass die Provisionierer, die online sind, mehr Chancen haben, eine Einigung zu erreichen. Wenn das weiterhin fehlschlägt, können Dusks Emergency Block Requests Einsatz (Stake) sammeln, um einen leeren Emergency Block zu erzeugen.

Der Emergency Block ist nicht dafür da, Transaktionen zu verarbeiten. Der Emergency Block hält die Kette in Bewegung. Erzeugt einen frischen Seed für einen weiteren Konsensversuch.

Es gibt einen Teil, den ich für wichtiger halte.

Wie oft benötigt Dusk tatsächlich diesen Wiederherstellungsmechanismus?

Wenn Dusks Emergency Mode zu einem Ereignis wird, würde ich das weniger als Erfolg des Fallbacks sehen, sondern eher als Signal, dass die Teilnahme von Validatoren unzuverlässig geworden ist.

Liveness ist wichtig. Das Erhalten von Liveness löst das zugrunde liegende Teilnahmeproblem von Dusk nicht.

#dusk $DUSK @Dusk

$ATM $ACE