#dusk $DUSK @Dusk

Anfangs dachte ich, das Limit von Dusk mit 50 Iterationen sei nur eine technische Obergrenze. Je mehr ich darüber nachdachte, desto mehr begann es sich anzufühlen wie ein kleines Fenster dafür, wie das Netzwerk mit Uneinigkeit umgeht.

Der Dusk-Konsens ist darauf ausgelegt, sich über Vorschlag, Validierung und Ratifizierung zu bewegen; dabei werden Bereitsteller über deterministische Selektion ausgewählt. Doch wenn Nachrichten zu spät eintreffen, Bereitsteller verschwinden oder die Kommunikation chaotisch wird, gibt der Konsens nicht sofort auf. Er bekommt mehr Gelegenheiten, um zu einer Übereinstimmung zu gelangen.

Das hat meine Sicht auf die Zahl verändert.

Es geht nicht wirklich um „50 Versuche“. Es wirkt eher wie ein Geduldsbudget für den Fall, dass sich das Netzwerk nicht mehr normal verhält.

Außerdem fand ich Dusk’ Vorgehen interessant, zeitlich abgelaufene Iterationen kurzschließen und Nachrichten aus früheren oder späteren Iterationen erneut zu propagieren. Für mich deutet das auf ein weniger offensichtlicheres Problem hin: Erholung ist nicht nur das erneute Versuchen, sondern darum, diese zusätzlichen Versuche sinnvoll zu machen.

Und genau dort wird der Kompromiss spannend.

Zu wenige Iterationen können eine vorübergehende Störung wie einen Ausfall aussehen lassen. Zu viele können dazu führen, dass das Netzwerk Zeit damit verbringt, eine Einigung zu verfolgen, während die Latenz weiter ansteigt.

Also komme ich immer wieder zu dieser Frage:

Wie viel Uneinigkeit kann Dusk tolerieren, bevor der Mechanismus, der dafür entworfen wurde, sich davon zu erholen, selbst zur Ursache der Verzögerung wird?

@Dusk #dusk $DUSK