@Dusk_Foundation Ich beurteilte DUSK zuerst anhand der Fork-Anzahl, und jetzt fühlt sich das wie der falsche Ausgangspunkt an.
Eine Kette mit null sichtbaren Forks kann dennoch schwache Netzwerkkonditionen darunter tragen. Entscheidend ist eher, wie sich der Konsens verhält, wenn sich Latenz, Paketverlust und Ausfallzeiten von Validatoren gemeinsam stapeln.
Nehmen wir 500 ms P95-Latenz. Allein bricht vielleicht nichts. Fügt man 5 % Paketverlust und 20 % Validator-Ausfallzeit hinzu, stellt sich die Frage, wie stark steigt das Odds Ratio für einen Fork gegenüber normalen Bedingungen – und wie viel Konsensverzögerung tritt auf, bevor Fork-Runden entstehen?
Die gleiche Logik gilt für den Mempool. DUSK-Knoten müssen nicht identische ausstehende Warteschlangen haben, bevor sie sich auf einen finalen Block einigen. So sagt mir ein Explorer, der 500 ausstehende Transaktionen zeigt, weniger als die P90/P10-Streuung über 20 Knoten oder ein Druckindex, der aus der medianen Warteschlangengröße × dem medianen Pending-Alter aufgebaut ist.
Eine gewisse Uneinigkeit ist normal. Verteilte Systeme sind nun einmal chaotisch – aber das ist nicht alarmierend.
Der eigentliche Test für DUSK ist, ob die Uneinigkeit lokal und vorübergehend bleibt oder in Einschluss-Wahrscheinlichkeiten, Konsensverzögerung und Finalität überläuft.
Ich beobachte immer noch einen unangenehmen Punkt: Wenn sich Stressfaktoren kombinieren, verschlechtert sich DUSK dann allmählich – oder bricht die Zuverlässigkeit plötzlich ein?
#dusk $DUSK
Eine Kette mit null sichtbaren Forks kann dennoch schwache Netzwerkkonditionen darunter tragen. Entscheidend ist eher, wie sich der Konsens verhält, wenn sich Latenz, Paketverlust und Ausfallzeiten von Validatoren gemeinsam stapeln.
Nehmen wir 500 ms P95-Latenz. Allein bricht vielleicht nichts. Fügt man 5 % Paketverlust und 20 % Validator-Ausfallzeit hinzu, stellt sich die Frage, wie stark steigt das Odds Ratio für einen Fork gegenüber normalen Bedingungen – und wie viel Konsensverzögerung tritt auf, bevor Fork-Runden entstehen?
Die gleiche Logik gilt für den Mempool. DUSK-Knoten müssen nicht identische ausstehende Warteschlangen haben, bevor sie sich auf einen finalen Block einigen. So sagt mir ein Explorer, der 500 ausstehende Transaktionen zeigt, weniger als die P90/P10-Streuung über 20 Knoten oder ein Druckindex, der aus der medianen Warteschlangengröße × dem medianen Pending-Alter aufgebaut ist.
Eine gewisse Uneinigkeit ist normal. Verteilte Systeme sind nun einmal chaotisch – aber das ist nicht alarmierend.
Der eigentliche Test für DUSK ist, ob die Uneinigkeit lokal und vorübergehend bleibt oder in Einschluss-Wahrscheinlichkeiten, Konsensverzögerung und Finalität überläuft.
Ich beobachte immer noch einen unangenehmen Punkt: Wenn sich Stressfaktoren kombinieren, verschlechtert sich DUSK dann allmählich – oder bricht die Zuverlässigkeit plötzlich ein?
#dusk $DUSK