Un fallo en Liquid Network podría aclarar la salida de 320 millones de dólares en BTC

Investigadores que analizan el incidente de Liquid Network valorado en unos 320 millones de dólares apuntan a un posible fallo en la caché de validación de transacciones del software. Esa debilidad ofrecería una explicación más concreta de cómo tokens sin respaldo habrían podido canjearse por Bitcoin real. También han surgido dudas sobre el despliegue del código. Mononaut sostiene que el bug explotado entró en la rama "master" de desarrollo de Elements la semana anterior, pero que nunca llegó a una versión etiquetada. Según su relato, los "functionaries" de la federación de Liquid habrían estado ejecutando ese código, mientras que otros nodos rechazaron las transacciones inválidas. Blockstream no ha confirmado esa versión en las declaraciones disponibles. De demostrarse, el foco pasaría a ser el despliegue de software en un episodio en el que credenciales de firma válidas autorizaron la liberación de BTC frente a LBTC presuntamente creados por un fallo. Liquid es una sidechain de Bitcoin en la que los tokens LBTC están diseñados para estar respaldados 1:1 por BTC custodiado por su federación. Como informó previamente CryptoSlate, SideSwap indicó que un cliente envió 4.000 LBTC a través de su servicio de "peg-out" el 6 de septiembre, lo que desencadenó la salida de aproximadamente 3.996 BTC. Liquid afirmó que ni la clave de autorización de "peg-out" de SideSwap ni otras claves de la federación fueron comprometidas. Los análisis técnicos se centran, por tanto, en cómo esos tokens llegaron a activar el proceso de retirada. Calle describió un fallo relacionado con las "range proofs", que permiten a los nodos comprobar que cantidades ocultas en una transacción caen dentro de un rango permitido sin revelar los importes. En las transacciones confidenciales de Liquid no basta con que entradas y salidas cuadren: un valor negativo oculto podría compensar una salida positiva mayor y hacer que tokens recién creados parezcan equilibrados. Las "range proofs" existen para impedir ese escenario. Dado que verificarlas es costoso en términos computacionales, los nodos almacenan en caché resultados de verificaciones exitosas para reutilizarlos. Según Calle, un atacante habría podido construir una salida inválida y una prueba que coincidieran con la clave de caché asociada a una verificación previamente válida. Un nodo que encontrara ese resultado almacenado omitiría la comprobación que debería rechazar la salida inflacionaria. Charles Guillemet respaldó esta explicación y habló de una colisión deliberada de "cache key" que permitió a una transacción confidencial inválida saltarse el control de rango. Calle advirtió que su descripción simplifica el mecanismo y podría contener errores. Otra reconstrucción, realizada por Stu, identificó transacciones de preparación seguidas de una transacción presuntamente inválida en el bloque 4.050.336 de Liquid. Stu afirma que esa operación creó aproximadamente 3.996,0183 LBTC antes de la retirada posterior a través de SideSwap. El relato de Mononaut añade una diferencia relevante entre nodos que aceptaron la transacción y nodos que la rechazaron. Señala que los "functionaries" de la federación aceptaron las transacciones del exploit, aprobaron las retiradas y continuaron produciendo bloques. Otros nodos, incluidos los que alimentan el explorador de Liquid de mempool, habrían rechazado el bloque afectado. Esto explicaría por qué un explorador que siga a los nodos que rechazaron el bloque podría omitir transacciones visibles en otros entornos. La divergencia reportada convierte las versiones de software en un elemento clave para entender el fallo. Un informe postmortem tendría que determinar qué funciones de código se ejecutaron, por qué se desplegaron y en qué se diferenció su comportamiento de validación respecto al de los nodos que rechazaron el bloque. Por otro lado, quienes controlan el Bitcoin retirado se han descrito como "whitehats" y han condicionado la devolución de la mayor parte de los fondos a que el fallo quede corregido en los nodos afectados. La información disponible no confirma una devolución completada ni un despliegue generalizado del parche. Recuperar el BTC mitigaría el déficit de reservas; explicar por qué los nodos de la federación aceptaron las transacciones y demostrar que el software corregido las rechaza sería clave para cerrar la brecha que permitió la salida de esas reservas.