Empecé a juzgar @Dusk por el conteo de forks, pero creo que esa métrica puede ocultar el problema más interesante.

Tener cero forks visibles no significa automáticamente que la red esté sana. ¿Qué ocurre cuando aumenta la latencia, aparece pérdida de paquetes y algunos validadores se desconectan al mismo tiempo?

Tampoco ignoraría el conteo de forks. Sigue siendo una métrica de resultado útil. La mejor pregunta es qué condiciones hay detrás de ello.

Si la latencia P95 alcanza los 500 ms, la pérdida de paquetes llega al 5% y la disponibilidad de los validadores cae un 20%, ¿DUSK ve más rondas con forks? ¿El consenso tarda más? ¿La finalidad se ralentiza antes de que los usuarios noten algo?

También dejaría de tratar el número del mempool de un solo explorador como la imagen completa. Comparar las colas pendientes y la antigüedad de las transacciones entre varios nodos podría decirnos si la congestión es local o se está extendiendo.

Alguna discrepancia es normal en sistemas distribuidos. Eso no me preocupa mucho.

Lo que estoy observando es la curva de fallo: ¿DUSK absorbe gradualmente el estrés combinado, o la confiabilidad cae de repente como desde un acantilado?

Esa respuesta me dice más que el conteo de forks por sí solo.

#dusk $DUSK

$ACE $EDEN

¿Qué es lo que más importa para la confiabilidad de la red DUSK?