Ich habe angefangen, Dusk’ Emergency Mode genauer anzuschauen, nachdem ich mir eine einfache Frage gestellt hatte: Was passiert, wenn plötzlich die meisten der Teilnehmer, die für den Konsens verantwortlich sind, offline gehen?
Kein Angriff. Kein böswilliger Block.
Nur nicht genug Beteiligung am Stake, um eine Einigung zu erreichen.
Das war es, was @Dusk ’ Emergency Mode für mich interessant machte.
Zunächst nahm ich an, dass der Emergency Mode vor allem dazu dient, einen Notfallblock zu erzeugen. Bei genauerem Hinsehen ist das jedoch nicht wirklich der Punkt.
Wenn eine Konsens-Iteration scheitert, schließt Dusk die Tür nicht sofort. Frühere Iterationen können offen bleiben, während neue beginnen, und geben den verbleibenden Provisionern mehr Chancen, zu einer Einigung zu gelangen.
Aber das schafft einen Zielkonflikt: Mehrere Iterationen am Leben zu halten erhöht auch die Möglichkeit konkurrierender Blöcke.
Darum priorisiert Dusk die niedrigste erfolgreich abgeschlossene Iteration.
Und wenn die Beteiligung weiterhin nicht ausreicht, bietet die Emergency Block Request (EBR) einen weiteren Wiederherstellungsweg. Sobald EBRs, die einen Großteil des Netzwerk-Stakes repräsentieren, gesammelt wurden, kann ein leerer Emergency Block erzeugt werden.
Dieser Block ist nicht dafür da, Transaktionen zu verarbeiten. Sein Zweck ist es, die Kette in Bewegung zu halten und einen frischen Seed für einen weiteren Konsensversuch zu etablieren.
Emergency Mode geht also nicht wirklich darum, was passiert, wenn der Konsens erfolgreich ist. Es geht darum, was das Protokoll tut, wenn die Annahmen, auf denen der Konsens beruht, nicht mehr länger gelten.
Das ist der tiefere Zielkonflikt: Laufzeit-Fortschritt (Liveness) zu erhalten ist nützlich, aber der Wiederherstellungsweg muss deterministisch bleiben, wenn mehrere Ergebnisse möglich sind.
Die Frage, die mir bleibt, ist, wie gut dieser Wiederherstellungsweg durchhält, wenn eine beeinträchtigte Beteiligung nicht nur vorübergehend ist, sondern dauerhaft.
@Dusk $DUSK #dusk
Kein Angriff. Kein böswilliger Block.
Nur nicht genug Beteiligung am Stake, um eine Einigung zu erreichen.
Das war es, was @Dusk ’ Emergency Mode für mich interessant machte.
Zunächst nahm ich an, dass der Emergency Mode vor allem dazu dient, einen Notfallblock zu erzeugen. Bei genauerem Hinsehen ist das jedoch nicht wirklich der Punkt.
Wenn eine Konsens-Iteration scheitert, schließt Dusk die Tür nicht sofort. Frühere Iterationen können offen bleiben, während neue beginnen, und geben den verbleibenden Provisionern mehr Chancen, zu einer Einigung zu gelangen.
Aber das schafft einen Zielkonflikt: Mehrere Iterationen am Leben zu halten erhöht auch die Möglichkeit konkurrierender Blöcke.
Darum priorisiert Dusk die niedrigste erfolgreich abgeschlossene Iteration.
Und wenn die Beteiligung weiterhin nicht ausreicht, bietet die Emergency Block Request (EBR) einen weiteren Wiederherstellungsweg. Sobald EBRs, die einen Großteil des Netzwerk-Stakes repräsentieren, gesammelt wurden, kann ein leerer Emergency Block erzeugt werden.
Dieser Block ist nicht dafür da, Transaktionen zu verarbeiten. Sein Zweck ist es, die Kette in Bewegung zu halten und einen frischen Seed für einen weiteren Konsensversuch zu etablieren.
Emergency Mode geht also nicht wirklich darum, was passiert, wenn der Konsens erfolgreich ist. Es geht darum, was das Protokoll tut, wenn die Annahmen, auf denen der Konsens beruht, nicht mehr länger gelten.
Das ist der tiefere Zielkonflikt: Laufzeit-Fortschritt (Liveness) zu erhalten ist nützlich, aber der Wiederherstellungsweg muss deterministisch bleiben, wenn mehrere Ergebnisse möglich sind.
Die Frage, die mir bleibt, ist, wie gut dieser Wiederherstellungsweg durchhält, wenn eine beeinträchtigte Beteiligung nicht nur vorübergehend ist, sondern dauerhaft.
@Dusk $DUSK #dusk
