Nachdem ich ein paar Tage damit verbracht habe, in Dusk einzutauchen, ist mir eine Sache besonders aufgefallen: Der interessante Teil ist nicht nur, wie der Konsens funktioniert, wenn alles richtig läuft – sondern was passiert, wenn das Netzwerk nicht dorthin gelangt.
Stell dir vor, mehrere Iterationen schlagen fehl, weil wichtige Provisioner offline oder isoliert sind. Ein System könnte einfach weiter aussetzen, bis es erneut versucht, und dabei ständig auf ein Timing-Out warten.
Dusk geht einen anderen Weg.
Laut dem Whitepaper betritt sein Succinct Attestation Protokoll nach 16 aufeinanderfolgenden fehlgeschlagenen Iterationen den Emergency Mode. Schritt-Timeouts werden deaktiviert und der Prozess läuft weiter, bis ein Kandidatenblock erzeugt ist und Quorum sowohl in der Validierung als auch in der Ratifizierung erreicht wird.
Aber es gibt einen wichtigen Trade-off.
Mehrere offene Iterationen können gleichzeitig laufen, was die Wahrscheinlichkeit erhöht, einen gültigen Block zu erreichen, aber auch die Möglichkeit von Forks steigert. Dusk löst diese Forks, indem es den Kandidaten aus der niedrigsten Iteration auswählt.
Was meine Aufmerksamkeit erregt hat, ist die Design-Philosophie: Ein Fehler wird nicht als das Ende des Prozesses behandelt. Das Protokoll hat einen definierten Pfad, um auch unter extremen Netzwerkbedingungen weiter in Richtung einer Entscheidung zu gelangen.
Das macht den Emergency Mode weniger wie ein Backup-Schalter und eher wie ein sorgfältig entwickelter Bestandteil, wie Dusk mit Ausfällen umgeht.
@Dusk $DUSK
$GPS
#dusk $PORTAL
Stell dir vor, mehrere Iterationen schlagen fehl, weil wichtige Provisioner offline oder isoliert sind. Ein System könnte einfach weiter aussetzen, bis es erneut versucht, und dabei ständig auf ein Timing-Out warten.
Dusk geht einen anderen Weg.
Laut dem Whitepaper betritt sein Succinct Attestation Protokoll nach 16 aufeinanderfolgenden fehlgeschlagenen Iterationen den Emergency Mode. Schritt-Timeouts werden deaktiviert und der Prozess läuft weiter, bis ein Kandidatenblock erzeugt ist und Quorum sowohl in der Validierung als auch in der Ratifizierung erreicht wird.
Aber es gibt einen wichtigen Trade-off.
Mehrere offene Iterationen können gleichzeitig laufen, was die Wahrscheinlichkeit erhöht, einen gültigen Block zu erreichen, aber auch die Möglichkeit von Forks steigert. Dusk löst diese Forks, indem es den Kandidaten aus der niedrigsten Iteration auswählt.
Was meine Aufmerksamkeit erregt hat, ist die Design-Philosophie: Ein Fehler wird nicht als das Ende des Prozesses behandelt. Das Protokoll hat einen definierten Pfad, um auch unter extremen Netzwerkbedingungen weiter in Richtung einer Entscheidung zu gelangen.
Das macht den Emergency Mode weniger wie ein Backup-Schalter und eher wie ein sorgfältig entwickelter Bestandteil, wie Dusk mit Ausfällen umgeht.
@Dusk $DUSK
$GPS
#dusk $PORTAL