Actualidad

DeFi

THORChain reabre 10 de 13 cadenas tras el bug de reembolso

Una reorganización de un bloque en Ethereum hizo que THORChain pagara dos veces el mismo depósito. Diez cadenas vuelven a operar y tres siguen cerradas.

THORChain reabre 10 de 13 cadenas tras el bug de reembolso
THORChain reabre 10 de 13 cadenas tras el bug de reembolso

Un depósito de diez ethers que existió durante un bloque y dejó de existir en el siguiente bastó para parar una red entera de intercambios entre cadenas. THORChain detectó el 31 de octubre que había reembolsado un depósito que nunca recibió, activó su comprobador automático de solvencia y los operadores de nodos cerraron el comercio en casi todas las cadenas conectadas mientras investigaban qué había pasado.

El protocolo reanudó el comercio el 3 de noviembre con la versión 3.21.1. Los datos públicos del proyecto, que se consultan en su página de estado, confirman las mismas cifras y el detalle de cada red. Diez de las trece redes externas volvieron a operar con comercio y firma de transacciones activas, mientras BNB Smart Chain, Cosmos Hub y Solana seguían restringidas.

El token del protocolo, RUNE, subió alrededor de un 15 % en veinticuatro horas hasta quedarse cerca de los 0,64 dólares, un movimiento que dice poco sobre si la confianza ha vuelto y bastante sobre lo barato que sale mover el precio de un activo con poca liquidez. Lo interesante del incidente no es la cotización, sino el fallo: no hubo robo, hubo un desajuste contable contra la cadena.

Un bloque reorganizado y un depósito que existió dos veces

La secuencia que describe el protocolo es corta y muy instructiva. Un depósito de 10 ETH llegó a la bóveda de THORChain y el sistema lo acreditó, pero una reorganización de un solo bloque en Ethereum eliminó la transacción de la cadena. El depósito seguía acreditado en el libro del protocolo y ya no existía en la realidad, que es el peor estado posible para un sistema que custodia fondos ajenos.

El detalle técnico que importa es el orden: el protocolo actuó sobre información que la cadena todavía podía deshacer. Cualquier sistema que lea bloques recientes vive con esa ventana abierta unos segundos.

El intercambio asociado no alcanzó el límite de precio que el usuario había fijado, así que el mecanismo de reembolso devolvió los fondos. El problema es que los devolvió dos veces: una contra el depósito acreditado, que ya no existía, y otra contra el depósito real del usuario. La bóveda pagó diez ethers que nunca había recibido, y el desajuste lo detectó el comprobador de solvencia, no una persona.

Una reorganización de un bloque es un evento raro, pero perfectamente normal en Ethereum: dos mineros publican bloques casi a la vez, la red elige una rama y la otra se descarta. Lo que casi nunca se prueba es qué hace un sistema externo que ya había leído la rama descartada y había actuado en consecuencia. Ahí estaba el agujero.

El freno automático que evitó algo peor

El comprobador de solvencia de THORChain existe precisamente para este escenario. Cuando la suma de lo que el protocolo cree deber a los usuarios deja de cuadrar con lo que hay en las bóvedas, el sistema se detiene solo, sin esperar a que un humano se dé cuenta. En este caso funcionó: el agujero era de diez ethers, no de diez mil.

Los operadores de nodos, que son quienes sostienen la red, decidieron después ampliar la parada a varias cadenas mientras los desarrolladores miraban el código. Esa decisión convirtió un incidente contable pequeño en una interrupción de servicio global, y es la parte del episodio que más discusión va a generar: el freno automático protegió los fondos, pero la reacción humana amplió el daño reputacional.

El usuario devolvió los diez ethers, según el relato del proyecto, lo que cierra el agujero contable y deja abierta la pregunta de diseño. Un sistema que depende de que el beneficiario de un error lo devuelva por voluntad propia no tiene un mecanismo de recuperación, tiene una esperanza.

Diez cadenas abiertas y tres todavía cerradas

La reapertura no fue completa. Bitcoin, Ethereum, Bitcoin Cash, Dogecoin, Litecoin, Tron y Zcash volvieron con comercio y firma activos, incluidas las rutas que el protocolo usa para activos como DogeOS y el préstamo con precios de RedStone, y Avalanche, Base y XRP ya operaban desde el lunes. BNB Smart Chain, Cosmos Hub y Solana seguían mostrando advertencias en las dos funciones, así que quien necesitara mover valor por esas rutas seguía sin poder hacerlo.

La tabla de estado del proyecto es la única fuente pública que dice qué ruta funciona y cuál no, y cambia varias veces al día sin aviso. Quien opera con estas rutas tiene que consultarla antes de cada movimiento.

La distinción entre comercio y firma importa más de lo que parece. Con el comercio activo, pero la firma parada, el protocolo puede aceptar una operación y no puede liquidarla, lo que en la práctica es peor que un cierre limpio porque deja fondos en un estado intermedio. THORChain mantuvo las dos funciones alineadas en cada cadena, lo que sugiere que el criterio de reapertura fue conservador.

Cosmos Hub y Solana ya estaban restringidas antes del incidente, según los datos históricos de nodos, lo que cambia la lectura del parte oficial. No es que el bug haya cerrado tres cadenas: es que una cadena ya estaba cerrada por otros motivos y el bug añadió la segunda.

Los 14 nodos que frenan el rendimiento

De los 111 nodos activos, 97 habían actualizado a la 3.21.1 en el momento del parte y 14 seguían en la 3.21.0. El propio proyecto vinculó el despliegue incompleto a los problemas de rendimiento del intercambio, con una frase que no deja lugar a dudas: todos los nodos activos tienen que actualizar para arreglar el rendimiento.

Las notas de la versión añaden un detalle que conviene leer dos veces. La 3.21.1 no incluye cambio de consenso y pide a los operadores instalar un binario privado con parches de seguridad adicionales, sin altura de actualización coordinada. Un parche que no se puede auditar y que cada operador instala cuando quiere es exactamente el tipo de proceso que produce redes a medio actualizar durante semanas.

El episodio llega además en un momento en el que el sector del préstamo on-chain presume de 175 millones levantados para lending, y un parche privado encaja mal con ese relato. Cuando una cadena grande publica una actualización de seguridad, el calendario es público y la versión es verificable; aquí el operador confía en un binario que no puede inspeccionar.

El efecto colateral que nadie quería reconocer

Chainalysis señaló que la parada de THORChain retrasó sin querer el lavado de los fondos del robo a Binance, valorado en 6.300 millones de dólares. La analítica de la firma sostiene que los atacantes usaban las rutas del protocolo para mover parte del botín y que el cierre les obligó a buscar caminos alternativos en plena operación.

Chainalysis señala que la caída de THORChain limito el lavado de activos del hack de Binance
Chainalysis señala que la caída de THORChain limito el lavado de activos del hack de Binance

Ese dato convierte el incidente en un debate que el sector lleva años evitando. Un protocolo sin permisos que se detiene solo porque un número no cuadra es, de hecho, un mecanismo de censura, y en este caso la censura funcionó a favor de la investigación. Los operadores que votaron reabrir lo hicieron sabiendo que las rutas volvían a estar disponibles para esos fondos, como señaló el fundador de Pangolin Intelligence en las discusiones del lunes.

El debate no es nuevo y tampoco tiene solución técnica a la vista. Las redes que se presentan como neutrales llevan años conviviendo con listas de direcciones bloqueadas y con operadores que deciden por su cuenta.

Ninguna de las dos posiciones es cómoda. Si el protocolo puede parar, alguien decide cuándo, y ese alguien no ha sido elegido por nadie. El precedente de Arbitrum moviendo 8.425 ETH del botín de Binance sin la clave apunta en la misma dirección. Si no puede parar, el dinero robado circula libremente por la misma infraestructura que se presenta como neutral. THORChain acaba de demostrar que las dos cosas son verdad al mismo tiempo.

Reabriendo una cadena sin dueño

La pregunta que queda abierta no es técnica. Los nodos deciden reabrir cada cadena cuando la consideran segura, sin fecha publicada para las tres restringidas y sin criterio explícito de qué significa seguro. En un sistema que se vende como descentralizado, ese criterio debería ser público antes del incidente, no después.

Para el usuario la lección es más simple y menos amable. Los diez ethers volvieron porque quien los recibió quiso devolverlos, el rendimiento del intercambio depende de que catorce operadores actualicen un binario privado y las rutas hacia tres cadenas siguen cerradas sin plazo. El resto del ecosistema descentralizado mira el caso con interés, porque el mismo patrón de reorganización puede repetirse en cualquier protocolo que lea la cadena y actúe antes de que la cadena se confirme.

José Maldonado

Autor

José Maldonado

Activista y bloguero de tecnología, software libre y blockchain.

Lo último
cPGuard sirvió un backdoor a miles de servidores de hosting

Una lectura semanal imprescindible sobre inteligencia artificial y blockchain.

Te explicamos cómo transforman la economía, qué nuevas puertas te abren y cómo te afectan.