#dusk $DUSK @Dusk

Früher dachte ich, die 50-Iterationen-Grenze in Dusk sei nur irgendeine zufällige technische Schranke. Aber je mehr ich mir Succinct Attestation (SA) anschaue, desto mehr sehe ich darin eine Regel, wie Dusk mit Meinungsverschiedenheiten umgeht.

Der Dusk-Konsens funktioniert in Runden. Bereitsteller werden durch deterministische Sortition ausgewählt, dann wandern Blöcke durch Vorschlag, Validierung und Ratifizierung, bevor sie endgültig werden.

Das, was ich daran interessant finde, ist die Idee der Iterationen.

Unter normalen Bedingungen erwartet Dusk, dass der Konsens schnell zu einer Einigung kommt. Aber wenn Nachrichten verzögert werden, Bereitsteller offline gehen oder das Netzwerk stärker feindselig wird, kann der Konsens über zusätzliche Iterationen weiterlaufen, statt sofort aufzugeben. Älteres Dusk-Material zielte um 15-Sekunden-Blöcke herum und erklärte, dass schwierige Netzwerkbedingungen mehr Iterationen erfordern könnten.

Und Dusk hat tatsächlich an Dingen gearbeitet, wie etwa zeitlich abgelaufene Iterationen kurzschließen und Nachrichten aus vergangenen oder zukünftigen Iterationen erneut weiterverbreiten. Das sagt mir, dass die Iterationsgrenze nicht nur ums Zählen von Versuchen geht, sondern Teil davon ist, wie das Netzwerk sich erholt, wenn die Kommunikation chaotisch wird.

Was ich hier beobachte, ist das Gleichgewicht:

zu wenige Iterationen = weniger Spielraum zur Erholung.

zu viele = der Konsens kann Zeit verschwenden, um eine Einigung zu verfolgen.

Also ist für mich die interessante Frage nicht „warum 50?“

sondern: Wie viel Uneinigkeit kann Dusk tolerieren, bevor die Geschwindigkeit weichen muss, um Gewissheit zu erreichen?