Stell dir vor, du betreibst ein Netzwerk, in dem plötzlich die meisten Menschen, die dafür zuständig sind, sich auf einen Konsens zu einigen, einfach offline gehen.
Kein Angriff. Kein böswilliger Block.
Sie sind einfach nicht da.
Das ist es, was den Emergency Mode von @Dusk für mich interessant gemacht hat.
Je genauer ich hinsah, desto mehr wurde mir klar, dass es dabei nicht wirklich darum geht, einen Notfall-Block zu produzieren.
Es geht darum, die Lebendigkeit (Liveness) zu bewahren, wenn die Teilnahme durch Einsatz (Stake) unzuverlässig wird.
Dusk kann sich durch mehrere Konsens-Iterationen bewegen, aber wenn die Teilnahme ständig fehlschlägt, friert das Protokoll nicht einfach ein.
Der Emergency Mode lässt frühere Iterationen offen, während neue beginnen, sodass die verbleibenden Provisioner mehr Chancen haben, sich zu einigen.
Allerdings gibt es einen Trade-off. Unterschiedliche Iterationen könnten konkurrierende Blöcke erzeugen, daher priorisiert Dusk die niedrigste erfolgreich abgeschlossene Iteration.
Und wenn der normale Konsens weiterhin scheitert, wird der Emergency Block Request (EBR) zur Absicherung. Sobald EBRs gesammelt sind, die eine Mehrheit des Netzwerk-Stakes repräsentieren, kann $DUSK einen leeren Emergency Block erzeugen.
Dieser Block ist nicht dafür gedacht, Transaktionen zu verarbeiten. Sein Zweck ist es, die Kette am Laufen zu halten und einen frischen Seed für einen weiteren Versuch festzulegen.
Ich denke, das ist eine subtile, aber wichtige Designentscheidung.
Dusk geht nicht von einer perfekten Teilnahme aus.
Stattdessen ist es so entworfen, dass es für den Moment vorbereitet ist, in dem diese Annahme bricht.
Die spannende Frage ist, wie effizient dieser Wiederherstellungspfad funktioniert, wenn die Teilnahme über einen längeren Zeitraum hinweg weiterhin beeinträchtigt bleibt?
#dusk #DUSK #Dusk $DUSK
Kein Angriff. Kein böswilliger Block.
Sie sind einfach nicht da.
Das ist es, was den Emergency Mode von @Dusk für mich interessant gemacht hat.
Je genauer ich hinsah, desto mehr wurde mir klar, dass es dabei nicht wirklich darum geht, einen Notfall-Block zu produzieren.
Es geht darum, die Lebendigkeit (Liveness) zu bewahren, wenn die Teilnahme durch Einsatz (Stake) unzuverlässig wird.
Dusk kann sich durch mehrere Konsens-Iterationen bewegen, aber wenn die Teilnahme ständig fehlschlägt, friert das Protokoll nicht einfach ein.
Der Emergency Mode lässt frühere Iterationen offen, während neue beginnen, sodass die verbleibenden Provisioner mehr Chancen haben, sich zu einigen.
Allerdings gibt es einen Trade-off. Unterschiedliche Iterationen könnten konkurrierende Blöcke erzeugen, daher priorisiert Dusk die niedrigste erfolgreich abgeschlossene Iteration.
Und wenn der normale Konsens weiterhin scheitert, wird der Emergency Block Request (EBR) zur Absicherung. Sobald EBRs gesammelt sind, die eine Mehrheit des Netzwerk-Stakes repräsentieren, kann $DUSK einen leeren Emergency Block erzeugen.
Dieser Block ist nicht dafür gedacht, Transaktionen zu verarbeiten. Sein Zweck ist es, die Kette am Laufen zu halten und einen frischen Seed für einen weiteren Versuch festzulegen.
Ich denke, das ist eine subtile, aber wichtige Designentscheidung.
Dusk geht nicht von einer perfekten Teilnahme aus.
Stattdessen ist es so entworfen, dass es für den Moment vorbereitet ist, in dem diese Annahme bricht.
Die spannende Frage ist, wie effizient dieser Wiederherstellungspfad funktioniert, wenn die Teilnahme über einen längeren Zeitraum hinweg weiterhin beeinträchtigt bleibt?
#dusk #DUSK #Dusk $DUSK