Auditoría de la cadena de Genesis de Babylon realizada por Zellic, publicada el 26 de marzo de 2025, documenta 32 hallazgos entre cinco consultores durante diez semanas. Siete se calificaron como críticos. Todos fueron corregidos o reconocidos por Babylon Labs.
Dos de esos hallazgos aparecen uno junto al otro en el informe y describen la misma brecha subyacente desde ángulos distintos.
Un proveedor de finalización al que se le impone una penalización (slash) se supone que debe perder su poder de voto de inmediato. Pero el código verificó el estado de penalización en una ruta de ejecución y lo pasó por alto en otra. Si a un proveedor se le había aplicado la penalización mientras aún tenía una delegación de BTC pendiente, esa delegación podría procesarse después sin que se volviera a comprobar la penalización, devolviendo al proveedor al conjunto activo de votación.
Esto no es una hipótesis de alguien que se planteó a posteriori. Es una ruta de código documentada, con las funciones exactas nombradas en el informe, y una corrección que Babylon Labs realmente publicó en dos commits.
Vale la pena detenerse a pensar por qué esto ocurre en absoluto. El diseño central de Babylon ejecuta dos ciclos de vida separados en paralelo: el estado de penalización del proveedor por un lado y el flujo de aprobación de la delegación por el otro. La mayor parte del tiempo, se mantienen sincronizados. Este hallazgo es lo que sucede en la ventana estrecha en la que no lo están.
Una comparación razonable: un empleado ve desactivada su credencial por una infracción de seguridad, pero una solicitud separada para otorgarle acceso al edificio —enviada antes de la desactivación— termina procesándose después y reactiva la credencial, porque ambos sistemas no verificaban entre sí en tiempo real.
Lo que no dejo de considerar es que un sistema construido sobre dos estados verificados de manera independiente —la penalización en el lado de Bitcoin y el poder de voto en la cadena— solo es tan sólido como el código que los mantiene consistentes bajo temporizaciones de casos límite. Ese problema de coordinación no desaparece por completo solo porque esta instancia específica haya sido corregida.#baby $BABY
@BabylonLabs_io #crypto #Binance
Dos de esos hallazgos aparecen uno junto al otro en el informe y describen la misma brecha subyacente desde ángulos distintos.
Un proveedor de finalización al que se le impone una penalización (slash) se supone que debe perder su poder de voto de inmediato. Pero el código verificó el estado de penalización en una ruta de ejecución y lo pasó por alto en otra. Si a un proveedor se le había aplicado la penalización mientras aún tenía una delegación de BTC pendiente, esa delegación podría procesarse después sin que se volviera a comprobar la penalización, devolviendo al proveedor al conjunto activo de votación.
Esto no es una hipótesis de alguien que se planteó a posteriori. Es una ruta de código documentada, con las funciones exactas nombradas en el informe, y una corrección que Babylon Labs realmente publicó en dos commits.
Vale la pena detenerse a pensar por qué esto ocurre en absoluto. El diseño central de Babylon ejecuta dos ciclos de vida separados en paralelo: el estado de penalización del proveedor por un lado y el flujo de aprobación de la delegación por el otro. La mayor parte del tiempo, se mantienen sincronizados. Este hallazgo es lo que sucede en la ventana estrecha en la que no lo están.
Una comparación razonable: un empleado ve desactivada su credencial por una infracción de seguridad, pero una solicitud separada para otorgarle acceso al edificio —enviada antes de la desactivación— termina procesándose después y reactiva la credencial, porque ambos sistemas no verificaban entre sí en tiempo real.
Lo que no dejo de considerar es que un sistema construido sobre dos estados verificados de manera independiente —la penalización en el lado de Bitcoin y el poder de voto en la cadena— solo es tan sólido como el código que los mantiene consistentes bajo temporizaciones de casos límite. Ese problema de coordinación no desaparece por completo solo porque esta instancia específica haya sido corregida.#baby $BABY
@BabylonLabs_io #crypto #Binance
