Wir hatten letzte Woche in Islamabad eine Phase von Lastabwürfen, bei der das Netz einfach immer wieder ausfiel. Und jedes Mal, wenn es wieder kam, musste das Backup-System von vorn starten, statt dort weiterzumachen, wo es aufgehört hatte. Ich ging davon aus, dass Dusk's Emergency-Mode genauso funktioniert: Netzwerkstalls, dann wird einfach immer wieder der gleiche feste Timeout erneut versucht, bis etwas „greift“.
So läuft es aber nicht. Der Emergency-Mode setzt erst nach 16 aufeinanderfolgenden fehlgeschlagenen Iterationen ein, und sobald er aktiviert wird, wird die gesamte Timeout-Struktur entfernt. Iterationen laufen nicht mehr ab; sie laufen unbegrenzt weiter, bis tatsächlich ein Kandidatenblock vorgeschlagen wird und sowohl in der Validierung als auch in der Ratifizierung das Quorum erreicht. Die Votes NoCandidate und NoQuorum werden ebenfalls deaktiviert, sodass jeder Schritt korrekt gelingen muss, bevor der nächste beginnt.
Was das für mich letztlich klarer gemacht hat: Mehrere dieser offenen Iterationen können gleichzeitig laufen. Das ist kein Fehler, sondern beabsichtigt—es erhöht die Wahrscheinlichkeit, dass mindestens eine einen gültigen Block erzeugt. Der Trade-off ist ein höheres Fork-Risiko, das dadurch gelöst wird, dass stets der Kandidat ausgewählt wird, der in der niedrigsten Iterationsnummer Konsens erreicht hat.
Es gibt außerdem einen letzten Ausweg innerhalb des letzten Auswegs. Wenn sogar die finale Iteration ins Stocken gerät, können Provisioner, die die Mehrheit des gesamten Einsatzes halten, einen Notfallblock anfordern: einen speziellen leeren Block, der von Dusk signiert ist, ohne Transaktionen—nur um die Runde am Laufen zu halten.
Was das Whitepaper nicht sagt, ist, wie oft das bisher auf echter Dusk-Infrastruktur tatsächlich ausgelöst wurde. Ich habe keine Daten, um eine Häufigkeitsbehauptung zu untermauern.
Der echte Test für DUSK ist, wie selten der Emergency-Mode feuern muss, sobald Mainnet in realem Maßstab läuft.
Hat das schon jemand tatsächlich beobachtet: dass der Emergency-Mode auf Dusk ausgelöst wurde?
@Dusk #dusk $DUSK
So läuft es aber nicht. Der Emergency-Mode setzt erst nach 16 aufeinanderfolgenden fehlgeschlagenen Iterationen ein, und sobald er aktiviert wird, wird die gesamte Timeout-Struktur entfernt. Iterationen laufen nicht mehr ab; sie laufen unbegrenzt weiter, bis tatsächlich ein Kandidatenblock vorgeschlagen wird und sowohl in der Validierung als auch in der Ratifizierung das Quorum erreicht. Die Votes NoCandidate und NoQuorum werden ebenfalls deaktiviert, sodass jeder Schritt korrekt gelingen muss, bevor der nächste beginnt.
Was das für mich letztlich klarer gemacht hat: Mehrere dieser offenen Iterationen können gleichzeitig laufen. Das ist kein Fehler, sondern beabsichtigt—es erhöht die Wahrscheinlichkeit, dass mindestens eine einen gültigen Block erzeugt. Der Trade-off ist ein höheres Fork-Risiko, das dadurch gelöst wird, dass stets der Kandidat ausgewählt wird, der in der niedrigsten Iterationsnummer Konsens erreicht hat.
Es gibt außerdem einen letzten Ausweg innerhalb des letzten Auswegs. Wenn sogar die finale Iteration ins Stocken gerät, können Provisioner, die die Mehrheit des gesamten Einsatzes halten, einen Notfallblock anfordern: einen speziellen leeren Block, der von Dusk signiert ist, ohne Transaktionen—nur um die Runde am Laufen zu halten.
Was das Whitepaper nicht sagt, ist, wie oft das bisher auf echter Dusk-Infrastruktur tatsächlich ausgelöst wurde. Ich habe keine Daten, um eine Häufigkeitsbehauptung zu untermauern.
Der echte Test für DUSK ist, wie selten der Emergency-Mode feuern muss, sobald Mainnet in realem Maßstab läuft.
Hat das schon jemand tatsächlich beobachtet: dass der Emergency-Mode auf Dusk ausgelöst wurde?
@Dusk #dusk $DUSK
