Me di cuenta del problema cuando un provisioner parecía saludable, pero aun así parecía un poco tarde para la ronda. Rusk estaba en marcha, el estado se veía actualizado, la conexión de red estaba allí, pero algo en el traspaso se sentía raro. Mi primera intuición fue culpar a Kadcast. Quizás un mensaje se movió lentamente. Luego empecé a preguntarme si eso era demasiado simple. Un nodo puede recibir el mensaje correcto y aun así estar mal posicionado para actuar sobre él si el estado, el tiempo o la responsabilidad de consenso ya se han adelantado. Ahí es donde la pila de <$DUSK > se me hace más interesante. La evolución de SBA hacia Succinct Attestation puede asignar el trabajo de propuesta, validación y ratificación, pero esos roles solo importan si el sistema circundante está listo cuando la selección convierte la elegibilidad en responsabilidad. Kadcast lleva la coordinación. Rusk tiene que mantener alineada lo suficiente la realidad local para que esa coordinación signifique algo. Suena ordenado por escrito. Menos ordenado cuando un nodo se reconecta a mitad de la actividad, se salta un deber o se pone al día justo cuando empieza otra ronda. No estoy seguro de que la parte difícil sea lograr la finalización cuando todo se comporta. Preferiría observar qué pasa después de unos cuantos desconectes breves, mensajes retrasados y cambios de software, y luego ver qué tan rápido esos provisioners vuelven a ser genuinamente útiles.

@Dusk_Foundation #dusk