Al principio asumí que lo único que podía costarle a un Proveedor de Finalidad su posición era un comportamiento abiertamente malicioso: firmar dos bloques en conflicto, ser atrapado, ser sancionado (slashed), el binario clásico entre honesto o deshonesto. Al leer la documentación del propio módulo de Finalidad de Babylon, hay una segunda vía de fallo, más silenciosa, que no tiene nada que ver con la honestidad. Antes de que un Proveedor de Finalidad pueda incluso votar sobre un bloque, tiene que comprometer de forma proactiva la aleatoriedad pública de EOTS para esa altura futura específica, con anticipación, antes de que el bloque se proponga. El sistema de Babylon rastrea por separado dos categorías de proveedores problemáticos: los que equivocal (equivocadores), a quienes les descubren firmando mensajes contradictorios, y los lentos, que simplemente no se presentan a tiempo. Ser lento no es lo mismo que violar la honestidad, pero aun así se registra y se penaliza como una categoría propia. Lo que esto significa en la práctica es que un proveedor puede ser totalmente honesto, no firmar nunca nada en conflicto, no intentar nada adversarial, y aun así perder la capacidad de votar para una altura determinada únicamente porque su compromiso de aleatoriedad no se mantuvo al ritmo del tope (tip) de la cadena. Comprometer aleatoriedad no es un paso único de configuración: es un trabajo continuo de previsión, mantenerse por delante de una cadena que sigue avanzando tanto si estás listo como si no. Así que el modelo de seguridad real que se está describiendo no es solo honesto versus malicioso. Es honesto y puntual versus todos los demás, incluidos proveedores honestos que simplemente se quedaron atrás en un requisito de planificación que la mayoría de las personas que delegan (staking) con ellos probablemente ni se molesten en comprobar.
@BabylonLabs_io #baby $BABY