Ich habe damit angefangen, @Dusk anhand der Fork-Anzahl zu bewerten, aber ich denke, dass diese Kennzahl das spannendere Problem verdecken kann.

Keine sichtbaren Forks bedeuten nicht automatisch, dass das Netzwerk gesund ist. Was passiert, wenn die Latenz steigt, Paketverluste auftreten und einige Validatoren gleichzeitig offline gehen?

Ich würde auch die Fork-Anzahl nicht ignorieren. Sie ist immer noch eine nützliche Ergebnis-Kennzahl. Die bessere Frage ist jedoch, welche Bedingungen dahinterstehen.

Wenn die P95-Latenz 500 ms erreicht, der Paketverlust 5 % beträgt und die Verfügbarkeit der Validatoren um 20 % sinkt: Sieht DUSK dann mehr gegabelte Runden? Dauert der Konsens länger? Verlangsamt sich die Finalität, bevor die Nutzer irgendetwas bemerken?

Außerdem würde ich aufhören, eine einzige Explorer-„Mempool“-Zahl als vollständiges Bild zu behandeln. Der Vergleich von Warteschlangen für ausstehende Transaktionen und der Transaktionsalterung über mehrere Nodes hinweg könnte uns zeigen, ob die Überlastung lokal ist oder sich ausbreitet.

Eine gewisse Uneinigkeit ist in verteilten Systemen normal. Das macht mir nicht besonders Sorgen.

Was ich beobachte, ist die Fehlerkurve: Nimmt DUSK die kombinierte Belastung schrittweise auf, oder bricht die Zuverlässigkeit plötzlich wie von einer Klippe?

Diese Antwort sagt mir mehr als nur die Fork-Anzahl.

#dusk $DUSK

$ACE $EDEN

Was ist für die Zuverlässigkeit des DUSK-Netzwerks am wichtigsten?