Harmony (ONE) lleva 184 horas sin un bloque nuevo, y el parche que iba a evitar el fallo tenía una puerta: bastaba declarar una época anterior

Harmony (ONE) no produce un bloque nuevo desde el 11 de agosto a las 23:25:37 UTC. Lo he comprobado esta tarde en los tres nodos públicos de la red, incluido uno independiente del proyecto, y los tres devuelven la misma altura: 92.730.034 en el fragmento cero y 94.978.278 en el uno, exactamente los dos bloques que el equipo eligió como punto de partida del retroceso. Pedir el siguiente devuelve un error. Son más de 184 horas, siete días y dieciséis horas, sin que la cadena avance un solo bloque.

El retroceso de Harmony ya está hecho en el estado: la dirección emisora que el 12 de agosto guardaba 618.468 millones de ONE falsificados hoy responde cero, y una de las dos direcciones que el proyecto pidió congelar también. Lo que falta es que la red vuelva a producir bloques. Y en el código que lo permitirá hay algo que nadie ha contado: el parche que la propia Harmony había desplegado en julio para cerrar precisamente este tipo de ataque solo se aplicaba a partir de una época determinada, y bastaba presentar un recibo firmado de una época anterior para saltárselo.

¿En qué estado está la cadena de Harmony ahora mismo?

Los nodos siguen contestando a todo menos a lo que importa. La época sigue siendo la 3002, el bloque más nuevo no contiene ninguna transacción y su sello de tiempo es de hace más de una semana. Consultado dos veces con 75 segundos de diferencia, el número no se movió en ninguno de los dos fragmentos. La versión del binario que sirve esas respuestas es la v2026.1.2, compilada el 15 de agosto a las 19:55 UTC, posterior al ataque y anterior al reinicio.

Esa última fila tiene gracia: el suministro declarado hoy es 332.398 ONE menor que el del día del ataque. No es una quema, son las recompensas de bloque de la semana borrada, que desaparecen con todo lo demás. Mientras tanto CoinGecko sigue publicando un circulante de 14.870.211.425 ONE, la misma cifra que antes del incidente, sobre una cadena cuyo estado ha cambiado dos veces desde entonces.

¿Qué se borra con el retroceso de Harmony?

El plan que el equipo publicó el 17 de agosto pone número al coste. Se descartan 141.628 bloques, y dentro de ellos 109.126 transacciones ordinarias y 315 de staking que no tenían nada que ver con el atacante: compras, ventas, envíos entre carteras, delegaciones. El corte es único para todos, y eso es precisamente lo que el proyecto defiende como virtud. Harmony dice haber estudiado quemar los tokens, poner las direcciones en lista negra y hasta migrar a un token nuevo, y describe el retroceso como la opción más justa y más segura porque aplica una sola regla a todo el mundo.

La razón por la que no se puede quemar es la de siempre en estos casos: el dinero falso ya se mezcló con el bueno. El propio equipo admite haber rastreado más del 99,9% de los tokens forjados, pero muchos pasaron por fondos de liquidez de intercambios descentralizados y por puentes entre redes, así que quemarlos golpearía a gente que compró ONE sin saber nada. Cuando medí el ataque por RPC el 12 de agosto el total identificado eran 3,29 billones de ONE, 214,7 veces el suministro declarado; la reconstrucción que Harmony publicó cinco días después habla de 3,01 billones en seis transacciones a cuatro carteras. Las dos cifras cuentan lo mismo: no era un robo, era una impresora.

El parche de julio tenía una puerta, y era declarar una época anterior

Aquí es donde el relato público se queda corto. La prensa ha resumido el fallo como un problema de verificación de recibos entre fragmentos, y es cierto, pero el parche de emergencia que el equipo fusionó el 12 de agosto a las 06:22 UTC, cincuenta y un minutos después de la última transferencia falsificada, dice algo más incómodo. Ese parche no crea la defensa: le quita una condición.

La marca que indica que un recibo ya se cobró se guardaba usando el fragmento y el número de bloque que venían dentro de la prueba de Merkle, campos que no van firmados. La red ya tenía una corrección para eso, activada con la bifurcación Bloom el 13 de julio, y consistía en tomar esos datos de la cabecera firmada en lugar de la prueba. Pero la corrección estaba condicionada a la época de esa cabecera: solo se aplicaba desde la 2964 en adelante. Y la propia nota que los desarrolladores dejaron en el código lo explica sin rodeos: una prueba que declare una época anterior puede llevar una prueba de Merkle manipulada conservando una cabecera y una firma auténticas. Con eso, un recibo ya cobrado parece nuevo y se vuelve a cobrar. Un abono sin cargo en el otro lado, tantas veces como se quiera.

La cadena tenía 3002 épocas de historia, o sea 2963 llenas de cabeceras firmadas legítimas anteriores al arreglo, disponibles para cualquiera. El binario que hoy sirve la red ya lleva esa condición eliminada y el flanco activo desde la propia época de Bloom, veintinueve días antes del ataque, de modo que al reiniciar las reglas corregidas rigen sobre todo el tramo reconstruido.

El recuento de firmas que contaba sillas en vez de votos

El mismo parche toca una segunda cosa, y es de las que quitan el sueño. La función que decide si un conjunto de firmas alcanza el quórum medía el tamaño de la lista de claves públicas del comité, no cuántos de esos firmantes habían firmado de verdad. Traducido: contaba las sillas de la sala, no las manos levantadas. La versión corregida recorre el mapa de bits y cuenta los firmantes activos uno por uno, y las pruebas nuevas que acompañan al cambio incluyen el caso más elocuente posible, un mapa de bits con cero firmantes, que antes habría pasado y ahora debe fallar.

Harmony no ha publicado un informe técnico que reparta responsabilidad entre los dos fallos, así que la lectura de cuál usó el atacante es mía y sale del código y de los comentarios de los desarrolladores. Lo que no admite lectura es el orden de los hechos: la puerta llevaba abierta desde el 13 de julio.

Tres hashes escritos a mano para que la cadena vieja no vuelva

Un retroceso no basta con anunciarlo, porque la rama antigua sigue existiendo en los discos de los validadores y cualquiera puede intentar reconstruirla. La solución está en el cambio fusionado el 15 de agosto, que añade dos archivos nuevos con una lista negra de tres hashes de bloque escritos literalmente en el código: el primer hijo abandonado del fragmento cero en el 92.730.035, el bloque malicioso del fragmento cero en el 92.730.036 y el del fragmento uno en el 94.978.279. El rechazo se aplica antes de la caché del consenso y antes de escribir cabecera, firma, cuerpo, recibos y estado, y también cuando esos hashes aparecen referenciados dentro de enlaces cruzados entre fragmentos.

Es la parte que conviene mirar de frente. Lo que sostiene el retroceso no es una regla general de consenso, son tres cadenas hexadecimales fijadas a mano en el cliente que los validadores instalan. Funciona, y es honesto en su fealdad, pero cualquiera que corra un nodo con un binario anterior no tiene esa lista. La reescritura que Ravencoin hizo este mismo mes se resolvió con minería y dificultad; aquí se resuelve con una lista de exclusión firmada por el equipo.

La otra cara: 10,7 millones de capitalización y un botín incobrable

Conviene no inflar el episodio. ONE cotiza a 0,00072041 dólares, sube un 0,97% en 24 horas y capitaliza 10,7 millones, un 99,81% por debajo de su récord de 2021. Los 3 billones falsificados valían sobre el papel miles de millones, pero el volumen real de la última jornada es de 1,62 millones de dólares, un 96% menos que los 40,48 millones del día del ataque, porque los intercambios tienen los depósitos parados: nadie iba a poder vender ese botín ni con la cadena viva. Frente a la ortodoxia de que una cadena no se reescribe, la alternativa era convivir para siempre con doscientas veces el suministro repartido entre carteras que ya habían pasado por puentes entre redes y fondos de liquidez. Harmony ha elegido el daño acotado sobre el daño permanente, que es defendible aunque incomode.

Lo que no se arregla con un retroceso es la confianza de quien tenía 109.126 transacciones confirmadas y va a descubrir que no ocurrieron. Ni la pregunta de cuántas redes más llevan una corrección de seguridad condicionada a una época que el atacante puede esquivar simplemente eligiendo un recibo más viejo.

Basado en: nodos públicos de Harmony api.harmony.one, api.s0.t.hmny.io, api.s1.t.hmny.io y 1rpc.io/one consultados por mí el 19 de agosto a las 16:04 UTC; repositorio harmony-one/harmony en GitHub (versiones v2026.1.0, v2026.1.1 y v2026.1.2 y cambios 5101 y 5106); The Block; Cointelegraph; CoinGecko.