Cargando precios…
🩸BEARISH

Liquid pierde 320 millones de dólares en BTC por un fallo de caché

El exploit dejó al descubierto dos fallos de control independientes: un error de validación del consenso y una ruta automatizada de peg-out sin límites de importe ni revisión humana.

La federación de Liquid liberó aproximadamente 3.996 BTC, valorados en unos 320 millones de dólares, el 6 de septiembre, después de que la sidechain aceptara L-BTC sin respaldo en Bitcoin. El fallo comenzó con un error de validación de pruebas en Elements, el software en el que se basa Liquid, y terminó con un peg-out autorizado pero excepcional a través de SideSwap.

Simanta Gautam, CEO de Alpen Labs, afirma que unos agentes de IA rastrearon y reprodujeron el fallo localmente en aproximadamente una hora. El problema afectaba a comprobaciones criptográficas almacenadas en caché. Un cambio del 1 de septiembre concatenó campos de las claves de caché sin codificar sus límites, lo que permitía que una prueba “seed” válida y un objetivo inválido distinto produjeran una entrada de caché idéntica. Una vez que la prueba válida preparaba la caché, el wrapper afectado podía aceptar el objetivo sin realizar la nueva comprobación requerida.

Por qué importa

El incidente muestra cómo un fallo de consenso y unos controles operativos débiles pueden agravarse mutuamente. SideSwap afirma que un atacante envió 4.000 L-BTC a su servicio de peg-out, que quemó los tokens con una autorización válida antes de que los firmantes de la federación liberaran 3.996 BTC. Su sistema automatizado no contaba con controles de importe, velocidad, proporción respecto al suministro, historial de la cartera ni revisión humana.

Un límite de pago antes de la autorización o de la firma de la federación podría haber interrumpido esta ruta concreta. Una clave offline o un reenvío manual con retraso habría creado una pausa, aunque la transferencia de reservas de la federación podría haberse producido antes de que se devolvieran los fondos.

Impacto en el mercado

La corrección de Elements del 8 de septiembre codificó las longitudes de los campos en las claves de caché, añadió pruebas centradas en colisiones e introdujo una opción para omitir la caché de range-proof. La versión 23.3.4 llegó el 9 de septiembre. Liquid afirmó que las transacciones ordinarias se reanudaron el 17 de septiembre, mientras que los peg-outs permanecían pausados a la espera de un respaldo completo de BTC en una proporción de uno a uno, actualizaciones de software, pruebas y revisiones independientes.

La cuestión operativa central es si un sistema de peg-out reanudado cuenta con un control independiente capaz de detener una solicitud autorizada del tamaño de las reservas antes de que Bitcoin salga de la custodia de la federación. La revisión asistida por IA puede sacar a la luz defectos rápidamente, pero los controles de pago determinan cuánto daño puede causar un futuro fallo de validación.

Tokens relacionados
$BTC

Preguntas frecuentes

  1. ¿Cómo permitió el fallo de la caché de pruebas de Liquid que pasara L-BTC inválido?

    Un cambio del 1 de septiembre en Elements concatenó campos de las claves de caché sin codificar sus límites. Una prueba válida y un objetivo inválido distinto podían producir una entrada de caché idéntica, lo que permitía que un resultado almacenado evitara una nueva verificación.

  2. ¿Cuánto Bitcoin liberó la federación de Liquid?

    La federación liberó aproximadamente 3.996 BTC, valorados en unos 320 millones de dólares en ese momento. SideSwap afirma que envió casi la totalidad del importe a la dirección del cliente.

  3. ¿Qué papel desempeñó el proceso de pago de SideSwap en el exploit?

    SideSwap afirma que su servicio automatizado de peg-out aceptó una orden de 4.000 L-BTC sin controles de importe, velocidad, proporción respecto al suministro, historial de cartera ni revisión humana. Posteriormente, la federación firmó la solicitud excepcional después de que fallaran dos intentos de pago.

  4. ¿Podría un límite de pago haber evitado la pérdida de Bitcoin?

    Un límite de pago antes de la autorización o de la firma de la federación podría haber interrumpido esta ruta concreta. No habría corregido el fallo subyacente de validación del consenso.

  5. ¿Qué medidas aplicaron Elements y Liquid después del incidente?

    Elements codificó las longitudes de los campos en las claves de caché, añadió pruebas centradas en colisiones e introdujo una opción para omitir la caché de range-proof. Después llegó la versión 23.3.4, mientras Liquid mantuvo los peg-outs pausados a la espera de comprobaciones de respaldo, actualizaciones de…

Atribución de fuente
Agregado de CryptoSlate · Verificado · Última actualización hace 28d
Abrir original →