Para ser sinceros, la arquitectura de Babylon es realmente bonita en su planteamiento: “un protocolo nativo de staking de Bitcoin, diseñado para extender la seguridad de Bitcoin a otras redes”. Que el poseedor de $BTC haga staking directo de BTC, sin puentes, sin envolturas y sin custodia. Pero entre lo bonito y lo seguro hay toda una cadena de agujeros todavía por rellenar.
Babylon solo ejecuta nodos ligeros de BTC y depende de retransmisores externos para actualizar los encabezados de los bloques de Bitcoin. El escenario divulgado por Zellic me dejó con el estómago encogido: mientras la cadena de Babylon está caída, la red de Bitcoin sigue produciendo bloques. Al reiniciarse, el cliente ligero aún cree que la altura más reciente es la que había antes de la caída. Un pool minero malicioso puede enviar con antelación una cadena bifurcada, y el nodo de Babylon la interpretará temporalmente como si fuera la cadena principal. El atacante no necesita superar en potencia de cómputo a la red principal de Bitcoin; solo necesita ir más rápido que el retransmisor honesto tras el reinicio.
Tampoco me dio más tranquilidad la firma EOTS de una sola vez. Zellic descubrió que todos los esquemas de firma de Babylon basados en Secp256k1 implementan la multiplicación escalar con un valor de tiempo variable, lo que introduce una vulnerabilidad de canal lateral de tiempo que podría filtrar el nonce y permitir recuperar la clave privada. El aviso de seguridad de GitHub además reveló una vulnerabilidad de replay de firmas: el atacante puede inyectar un compromiso PubRand inválido.
El límite de bloqueo en los scripts de Bitcoin también es frágil. La vulnerabilidad expuesta por GHSA-4rmq-mc2c-r495 muestra que: si FP sale del conjunto activo en la misma altura de bloque, los delegadores que ya quedaron completamente desvinculados de BTC todavía conservan ActiveSatoshis no nulos; es decir, continúa cobrando recompensas por staking con 0 BTC.
La velocidad de producción de bloques en ambas cadenas es totalmente diferente, y el estado de staking tiene una diferencia temporal de varios minutos. El módulo zoneconcierge de Babylon, al procesar paquetes IBC, usa la iteración no determinista del map de Go; distintos nodos generan órdenes de recorrido diferentes, y toda la cadena se detiene (halt).
Por último, está la reacción en cadena causada por la congestión de la red BTC. En agosto de 2024, en la fase Cap-1, las tarifas de gas de Bitcoin se dispararon de 0,5 USD a 132 USD. Con un tope de staking de 1000 BTC, se necesitaron aproximadamente 21.000 transacciones para llenar 6 bloques y completarlo. El script de deshakeo (desbloqueo) tiene la tasa de comisión codificada de forma rígida; el costo de deshakeo llegó a representar el 45% de las comisiones de toda la red Bitcoin.
Un protocolo cuya supervivencia depende del estado de congestión de la red BTC: ¿estás seguro de que podrá aguantar la próxima guerra de gas?
#baby $BABY @BabylonLabs_io
Babylon solo ejecuta nodos ligeros de BTC y depende de retransmisores externos para actualizar los encabezados de los bloques de Bitcoin. El escenario divulgado por Zellic me dejó con el estómago encogido: mientras la cadena de Babylon está caída, la red de Bitcoin sigue produciendo bloques. Al reiniciarse, el cliente ligero aún cree que la altura más reciente es la que había antes de la caída. Un pool minero malicioso puede enviar con antelación una cadena bifurcada, y el nodo de Babylon la interpretará temporalmente como si fuera la cadena principal. El atacante no necesita superar en potencia de cómputo a la red principal de Bitcoin; solo necesita ir más rápido que el retransmisor honesto tras el reinicio.
Tampoco me dio más tranquilidad la firma EOTS de una sola vez. Zellic descubrió que todos los esquemas de firma de Babylon basados en Secp256k1 implementan la multiplicación escalar con un valor de tiempo variable, lo que introduce una vulnerabilidad de canal lateral de tiempo que podría filtrar el nonce y permitir recuperar la clave privada. El aviso de seguridad de GitHub además reveló una vulnerabilidad de replay de firmas: el atacante puede inyectar un compromiso PubRand inválido.
El límite de bloqueo en los scripts de Bitcoin también es frágil. La vulnerabilidad expuesta por GHSA-4rmq-mc2c-r495 muestra que: si FP sale del conjunto activo en la misma altura de bloque, los delegadores que ya quedaron completamente desvinculados de BTC todavía conservan ActiveSatoshis no nulos; es decir, continúa cobrando recompensas por staking con 0 BTC.
La velocidad de producción de bloques en ambas cadenas es totalmente diferente, y el estado de staking tiene una diferencia temporal de varios minutos. El módulo zoneconcierge de Babylon, al procesar paquetes IBC, usa la iteración no determinista del map de Go; distintos nodos generan órdenes de recorrido diferentes, y toda la cadena se detiene (halt).
Por último, está la reacción en cadena causada por la congestión de la red BTC. En agosto de 2024, en la fase Cap-1, las tarifas de gas de Bitcoin se dispararon de 0,5 USD a 132 USD. Con un tope de staking de 1000 BTC, se necesitaron aproximadamente 21.000 transacciones para llenar 6 bloques y completarlo. El script de deshakeo (desbloqueo) tiene la tasa de comisión codificada de forma rígida; el costo de deshakeo llegó a representar el 45% de las comisiones de toda la red Bitcoin.
Un protocolo cuya supervivencia depende del estado de congestión de la red BTC: ¿estás seguro de que podrá aguantar la próxima guerra de gas?
#baby $BABY @BabylonLabs_io