Tres blockchains se detienen en cuatro días: ¿quién tiene el poder de pausarlas?

Autor: Liam 'Akiba' Wright, cryptoslate

Compilación: Saoirse, Foresight News

En cuatro días, tres redes blockchain dejaron de producir bloques sucesivamente. Cada interrupción de la red utilizó poderes de emergencia completamente diferentes, y solo Cronos reescribió parte del historial oficial de la cadena.

Cronos declaró que, tras el ataque de vulnerabilidad al protocolo Tectonic, los nodos validadores apagaron la red mediante el mecanismo de consenso, restauraron la cadena al estado anterior al ataque y reiniciaron la producción de bloques desde la altura 90.896.189. Esta operación no solo detuvo la producción de bloques, sino que reescribió directamente el estado de la cadena. Las transacciones y cambios de estado generados después del punto de restauración ya no forman parte de la cadena principal oficial reiniciada.

Ontology e ICON adoptaron otro conjunto de medidas de emergencia. Ontology pausó la producción de bloques antes de confirmar el comportamiento malicioso, y su actualización del 1 de septiembre indicó que dicha actividad maliciosa no causó pérdidas de activos a los usuarios. ICON primero pausó el contrato atacado y luego apagó toda la red; la fundación afirmó que, durante la fase de migración, la red estaba bajo su control, y para entonces la mayor parte del ICX robado ya había sido transferido a cuentas de custodia de exchanges.

La interrupción de la blockchain es solo el primer nivel de control. La cuestión más profunda es: ¿quién tiene la autoridad para ordenar el apagado de la red? ¿Pueden reescribir el estado confirmado de la cadena? Cuando los fondos fluyen entre cadenas o entran en instituciones de custodia centralizadas, ¿qué pérdidas serán irrecuperables?

Comparación de los métodos de emergencia de las tres blockchains públicas Cronos, Ontology e ICON

Cronos: de la interrupción a la reescritura del estado de la cadena

Cronos denominó esta gestión del incidente como "acción de emergencia por consenso de validadores". El anuncio de reinicio del 31 de agosto mostró que a las 23:49:01 UTC del 30 de agosto, la red reanudó la producción de bloques desde la altura 90.896.189, y el estado de la cadena retrocedió al momento anterior al ataque de vulnerabilidad de Tectonic.

La operación de interrupción de Cronos implica una decisión de distribución de intereses sobre el punto de restauración. Después del checkpoint, los estados en cadena relacionados con la vulnerabilidad, junto con todas las transacciones no relacionadas de ese período, fueron eliminados de la cadena oficial. El anuncio de reinicio no incluyó lista de transacciones, estadísticas de nodos validadores, umbral de peso de votación ni lista de nodos participantes. Cronos prometió publicar un informe retrospectivo que explique completamente el proceso de gestión y el alcance del impacto técnico.

Incluso la magnitud de los activos realmente protegidos por esta intervención aún no está determinada. TRM Labs estimó que, tras la manipulación del precio del token TONIC, se tomaron prestados aproximadamente 75 millones de dólares en activos; de ellos, unos 6 millones fluyeron a Ethereum y unos 68,7 millones fueron revertidos dentro de la cadena Cronos. Las estadísticas de Bitquery indican una salida total mayor, con aproximadamente 8,3 millones de dólares en activos fluyendo a Ethereum y un total de 10.961 bloques descartados.

Los dos métodos estadísticos miden objetos diferentes, y los datos finales de pérdidas oficiales de Tectonic aún están por publicarse. Pero una cosa ya está muy clara: el rollback de Cronos solo puede restaurar el estado que permanece dentro de su propia cadena, y los activos en la cadena Ethereum están completamente fuera de su control.

El plan de disposición de activos de Tectonic aún deja problemas contables para los usuarios. El protocolo indicó que dará prioridad a habilitar las funciones de retiro y pago de préstamos, mientras suspende los depósitos y nuevos préstamos. Este plan ofrece a los usuarios una vía de salida y desapalancamiento, pero aún no se ha confirmado si los proveedores de fondos podrán redimir la totalidad. El informe retrospectivo pendiente de Tectonic deberá aclarar el principio de la vulnerabilidad, la salida total de fondos, la magnitud de la deuda incobrable, los activos recuperados y las deudas restantes.

El progreso de recuperación de las distintas infraestructuras no está sincronizado con el reinicio del consenso de la cadena. Cronos advirtió que los protocolos, puentes entre cadenas, exploradores de bloques y servicios RPC necesitarán más tiempo para recuperarse. La página de estado de Alchemy también registró por separado esta interrupción y la posterior recuperación. La red blockchain puede declarar oficialmente su reinicio, pero los servicios que dependen de ella no necesariamente están listos.

Ontology: la interrupción solo busca ganar tiempo, no revierte transacciones

La acción de Ontology ocurrió antes de confirmar la actividad maliciosa. La red afirmó que el equipo de desarrollo central detectó un riesgo potencial de seguridad durante una inspección rutinaria, pausó inmediatamente la producción de bloques y encargó al equipo técnico y a los nodos validadores una revisión sistemática.

La actualización del 1 de septiembre indicó que la revisión confirmó la existencia de un ataque malicioso, que la red principal continuaría detenida y que se llevarían a cabo la reparación de la vulnerabilidad y la actualización de la red; el ataque no afectó los activos de los usuarios. El objetivo de Ontology es restablecer el funcionamiento normal en 24 horas, siempre que las pruebas de seguridad, la reparación de vulnerabilidades, la actualización y las pruebas se completen con éxito.

La interrupción de Ontology conserva todo el estado confirmado en cadena y solo detiene la confirmación y liquidación de nuevas transacciones. El anuncio no especificó un punto de restauración ni publicó el conjunto de transacciones que debían invalidarse.

La información de autoridad divulgada públicamente es incompleta. El anuncio menciona la participación del equipo de desarrollo central, el equipo técnico y los nodos validadores de la red, pero no indica quién tiene la autoridad final vinculante ni proporciona un umbral numérico de emergencia. La documentación VBFT de Ontology describe el mecanismo de consenso ordinario, incluida la generación de bloques de confirmación por los nodos y la actualización del conjunto de nodos de consenso mediante contratos de gestión, pero la documentación solo cubre escenarios de funcionamiento normal; las reglas de pausa de emergencia utilizadas el 31 de agosto no se han hecho públicas.

Incluso sin pérdidas de activos, la interrupción conlleva costes reales. Ontology informó a los usuarios de que las transacciones en cadena no podrían procesarse y recomendó no ejecutar operaciones sensibles al tiempo; posteriormente indicó que el reinicio de la red depende de la reparación de la vulnerabilidad, la actualización y las pruebas. Los usuarios no pueden ajustar posiciones ni liquidar transferencias en cadena, y todos los servicios externos conectados a esta cadena solo pueden esperar la señal de la red.

El criterio para reanudar el funcionamiento se orienta a la seguridad, pero los detalles concretos son limitados. Ontology afirmó que, una vez completadas la reparación, actualización, pruebas y verificación, se esforzará por restablecer el servicio en 24 horas, pero no se ha divulgado quién determina que se cumplen las condiciones ni cuál es el umbral de activación.

Esto genera incertidumbre a nivel de gobernanza: el anuncio enumera las partes que participaron en la revisión, pero no se especifica quién tiene la autoridad final para reiniciar. Para los usuarios, el riesgo actual proviene de la interrupción del servicio, no de pérdidas de activos confirmadas ni de un rollback de la cadena.

ICON: por qué la interrupción de la blockchain llegó demasiado tarde

El incidente de ICON muestra completamente el proceso de alerta, gestión y salida de activos del control de la cadena.

Según el informe retrospectivo de la fundación, el atacante repitió 1.492 veces dos mensajes de retiro firmados históricamente válidos entre las 02:01:02 y las 02:21:12 UTC del 27 de agosto. Un defecto de precisión provocó que 1.490 de esas llamadas tuvieran éxito, transfiriendo 119,866 millones de ICX y 531.600 bnUSD del fondo de activos de la fundación.

A las 02:08, el sistema de monitoreo emitió una alerta, y el personal técnico inició la investigación posteriormente; el contrato afectado fue pausado a las 03:53. Los principales exchanges cerraron gradualmente los depósitos y retiros de ICX a las 05:54, y la interrupción total de la red entró en vigor a las 06:18:54. ICON completó el reinicio alrededor de las 07:51 del 28 de agosto, con un intervalo de aproximadamente 25 horas, y reparó la vulnerabilidad subyacente.

El informe retrospectivo considera que la causa raíz del problema fue el proceso de respuesta a incidentes, no una capacidad de detección insuficiente. La alerta se activó en 7 minutos, pero este tipo de alertas a menudo se confunde con anomalías RPC no relacionadas, y el sistema no notificó al personal de guardia. La investigación técnica no comenzó hasta alrededor de las 03:40, y poco después se pausó el contrato.

Cuando la cadena se detuvo oficialmente, la mayor parte del ICX afectado ya había sido incorporado al sistema de custodia de los exchanges. Los medios de control del lado de la cadena ICON no pueden impedir que los exchanges transfieran o conviertan los activos en su poder. La fundación solo puede recurrir a la congelación de activos por parte de los exchanges, notificaciones de preservación, abogados y autoridades judiciales.

La frontera de custodia determina directamente la atribución de pérdidas. ICON afirmó que todos los activos afectados pertenecían a la fundación y que los depósitos, saldos y posiciones de los usuarios comunes no fueron tocados. El informe muestra que 531.600 bnUSD y 1,366 millones de SODA fueron recuperados en su totalidad; de los 113.634 USDC prestados, 82.430 fueron recuperados. La pérdida neta confirmada es de aproximadamente 150,2 ETH más 31.204 USDC. La gran mayoría del ICX involucrado solo fue congelado o rastreado en los exchanges, no realmente recuperado.

La estructura de control de ICON también difiere de los otros dos casos. El informe retrospectivo indica que durante la migración de tokens, la red estaba controlada por la fundación; el documento de guía de migración menciona que el consenso operaba en modo de mantenimiento con solo 7 nodos centrales. Por lo tanto, esta interrupción se basó en una arquitectura operativa especial claramente controlada por la fundación.

El poder de emergencia es, en esencia, poder a nivel de balance

Cada interrupción de blockchain es, en esencia, una transferencia de riesgo a un lugar diferente.

• Cronos modificó el historial oficial de la cadena: puede proteger los activos que aún están bajo la jurisdicción de la cadena, pero invalida actividades normales en cadena ajenas a la vulnerabilidad y no puede hacer nada con los activos en Ethereum.
• Ontology convirtió el riesgo en coste de tiempo y pérdida de disponibilidad del servicio; durante la investigación, las transacciones no pudieron liquidarse y no se confirmaron pérdidas contables de activos.
• ICON completó el aislamiento del contrato y de la red solo después de que los activos ya habían salido del ámbito de custodia de la cadena; las pérdidas confirmadas son asumidas por la fundación, y la recuperación del ICX congelado depende de los exchanges y las autoridades judiciales.

Una simple puntuación de descentralización ocultaría estos desenlaces tan diferentes. Un criterio de evaluación más práctico es: ¿se publican las reglas de emergencia? ¿Cuál es el umbral que activa la intervención? ¿Solo se detienen los bloques nuevos o se reescribe el estado ya confirmado de la cadena? Cuando ocurre la intervención, ¿quién controla los activos que han salido de la jurisdicción de la cadena? ¿Quién se compromete a asumir las pérdidas restantes?

Cronos y Tectonic aún deben publicar informes retrospectivos completos. Ontology necesita divulgar los detalles del ataque y las reglas de autorización de emergencia, y posteriormente confirmar si se cumplen las condiciones para la actualización y el reinicio. Lo que realmente vale la pena comparar es la frontera de riesgo que cada red traza: qué historial, tiempo y fondos quedan expuestos al riesgo.

Enlace original