Tres cadenas de bloques se detienen en cuatro días, ¿quién tiene el poder de presionar el botón de pausa?

Autor: Liam 'Akiba' Wright, cryptoslate

Compilado por: Saoirse, Foresight News

En cuatro días, tres redes de blockchain han dejado de producir bloques sucesivamente. Cada parada de la red ha utilizado diferentes permisos de emergencia, siendo Cronos la única que ha reescrito parte de la historia de la cadena oficial.

Cronos indicó que, tras un ataque de vulnerabilidad en el protocolo Tectonic, los nodos de validación detuvieron la red a través de un mecanismo de consenso, restaurando la cadena al estado anterior al ataque y reiniciando la producción de bloques desde la altura de bloque 90,896,189. Esta operación no solo detuvo la producción de bloques, sino que también reescribió directamente el estado de la cadena. Las transacciones y cambios de estado generados después del punto de recuperación ya no pertenecen a la cadena principal oficial reiniciada.

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

La detención de la blockchain es solo el primer nivel de control. La cuestión más profunda es: ¿quién tiene el poder de ordenar la detención de la red? ¿Pueden reescribir el estado de la cadena ya confirmado? ¿Qué pérdidas serán irreparables cuando los fondos fluyan entre cadenas o entren en instituciones de custodia centralizadas?

La información sobre los permisos revelados en las medidas de emergencia desencadena riesgos de recuperación conocidos. La vulnerabilidad de Cronos y el ataque a Tectonic detuvieron la red y restauraron el estado de la cadena anterior a la vulnerabilidad mediante consenso de validadores; el anuncio de reinicio no reveló datos de votación y todas las actividades en la cadena después del punto de control fueron anuladas; los fondos que fluyeron a Ethereum no están bajo el control de Cronos; la estadística de pérdidas finales de Tectonic aún no se ha completado. Ontology detectó riesgos potenciales durante la inspección diaria y, tras confirmar la existencia de actividad maliciosa, pausó preventivamente la producción de bloques, sin realizar un rollback; no se revelaron los umbrales de activación de la emergencia ni las transacciones que no pudieron ejecutarse durante la actualización de la red; no se encontraron daños a los activos de los usuarios. ICON encontró una vulnerabilidad de repetición en el contrato de migración, primero pausó el contrato y luego detuvo toda la red; durante la fase de migración, la red fue controlada por la fundación, y la reducción en el número de nodos de validación principales significó que las pérdidas serían asumidas por la fundación; la posibilidad de recuperar el ICX en los exchanges depende del custodio, los procesos legales y las autoridades.

Comparación de los métodos de manejo de emergencia de las tres cadenas de bloques: Cronos, Ontology e ICON.

Cronos: De la detención a la reescritura del estado de la cadena {#article-toc-33687-2}

Cronos describió la gestión de este evento como una "acción de emergencia de 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 se reinició desde la altura de bloque 90,896,189, y el estado de la cadena retrocedió al momento anterior al ataque de vulnerabilidad de Tectonic.

La operación de detención de Cronos implica tomar decisiones sobre la distribución de beneficios en el punto de recuperación. Después del punto de control, el estado de la cadena relacionado con la vulnerabilidad, junto con todas las transacciones no relacionadas durante ese período, fueron borrados de la cadena oficial. El anuncio de reinicio no incluyó una lista de transacciones, estadísticas de nodos de validación, umbrales de peso de voto ni listas de nodos participantes. Cronos se comprometió a publicar un informe de revisión posterior, que necesita explicar completamente el proceso de manejo y el alcance del impacto técnico.

Incluso el tamaño de los activos protegidos por esta intervención aún no está claro. TRM Labs estima que, tras la manipulación del precio del token TONIC, aproximadamente 75 millones de dólares en activos fueron prestados; de los cuales, alrededor de 6 millones de dólares fluyeron hacia Ethereum, y aproximadamente 68.7 millones de dólares completaron el rollback en la cadena de Cronos. Las estadísticas de Bitquery indican un flujo total más alto, con aproximadamente 8.3 millones de dólares en activos fluyendo hacia Ethereum, y un total de 10,961 bloques fueron descartados.

Los dos enfoques de estadística tienen diferentes objetos de conteo, y los datos finales de pérdidas de Tectonic aún están pendientes de publicación. Pero una cosa ya es muy clara: el rollback de Cronos solo puede restaurar el estado que aún permanece en esta cadena; los activos en la cadena de Ethereum están completamente fuera de su control.

El plan de manejo de activos de Tectonic aún deja problemas contables para los usuarios. El protocolo indicó que priorizaría la apertura de funciones de retiro y reembolso de préstamos, mientras que pausaba depósitos y nuevos préstamos. Este plan ofrece a los usuarios una ruta de salida y desapalancamiento, pero no se ha confirmado si los proveedores de fondos podrán recuperar la totalidad. El informe posterior que Tectonic publicará aún necesita aclarar el principio de la vulnerabilidad, el total de flujos de fondos, el tamaño de las cuentas incobrables, los activos recuperados y las deudas restantes.

El progreso de recuperación de diversas infraestructuras no está sincronizado con el reinicio del consenso de la cadena. Cronos advierte que varios 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 detención y la posterior recuperación. La red de la cadena puede declarar un reinicio oficial, pero los diversos servicios que dependen de ella pueden no estar listos.

Ontology: La detención solo busca ganar tiempo para el manejo, no revoca transacciones {#article-toc-33687-3}

Las acciones de manejo de Ontology ocurrieron antes de confirmar la actividad maliciosa. La red informó que el equipo de desarrollo central descubrió riesgos de seguridad potenciales durante una inspección diaria y detuvo inmediatamente la producción de bloques, delegando la revisión del sistema al equipo técnico y a los nodos de validación.

El anuncio de actualización del 1 de septiembre indicó que la revisión confirmó la existencia de un ataque malicioso, y la red principal continuaría detenida para llevar a cabo la reparación de vulnerabilidades y la actualización de la red; este ataque no había afectado los activos de los usuarios. El objetivo de Ontology es restaurar el funcionamiento normal en 24 horas, siempre que la detección de seguridad, la reparación de vulnerabilidades, la actualización y las pruebas se completen sin problemas.

La detención de Ontology conserva todo el estado de la cadena ya confirmado, solo deteniendo la confirmación y liquidación de nuevas transacciones. El anuncio no especificó un punto de recuperación ni publicó un conjunto de transacciones que debían ser anuladas.

La información de permisos divulgada públicamente no es completa. El anuncio menciona la participación del equipo de desarrollo central, el equipo técnico y los nodos de validación de la red en el manejo, pero no especifica quién es el decisor final con poder vinculante, ni proporciona un umbral de activación de emergencia en forma numérica. La documentación de VBFT de Ontology describe el mecanismo de consenso habitual, que incluye la generación de nodos para confirmar bloques y gestionar la actualización del conjunto de nodos de consenso, pero la documentación solo cubre escenarios de funcionamiento normal, y las reglas de pausa de emergencia utilizadas el 31 de agosto no se han hecho públicas.

Incluso sin causar pérdidas de activos, la detención aún conlleva costos reales. Ontology informó a los usuarios que las transacciones en la cadena no se podrán procesar y recomendó no realizar operaciones sensibles al tiempo; posteriormente, indicó que el reinicio de la red depende de la reparación de vulnerabilidades, actualizaciones y pruebas. Los usuarios no pueden ajustar posiciones, realizar transferencias o liquidaciones en la cadena, y todos los servicios externos que se conectan a esta cadena solo pueden esperar señales de la red.

Los criterios para determinar la recuperación se orientan hacia la seguridad, pero los detalles específicos son limitados. Ontology indicó que, siempre que se completen la reparación, la actualización, las pruebas y la verificación, se esforzarán por restaurar el servicio en 24 horas, pero no se ha revelado quién determina que se han cumplido las condiciones, ni cuál es el umbral de activación.

Esto genera incertidumbre a nivel de gobernanza: el anuncio menciona las partes que participan en la revisión, pero no se ha aclarado quién tiene el poder de decisión final sobre el reinicio. Para los usuarios, el riesgo actual proviene de la interrupción del servicio, y no de pérdidas de activos confirmadas o de un rollback de la cadena.

ICON: ¿Por qué la detención de la blockchain llegó demasiado tarde? {#article-toc-33687-4}

El evento de ICON muestra de manera completa el proceso de alerta, manejo y la desvinculación de activos del control de la cadena.

Según el informe de revisión posterior de la fundación, el atacante repitió 1492 veces dos mensajes de retiro firmados válidos entre las 02:01:02 y las 02:21:12 UTC del 27 de agosto. Un defecto de precisión permitió que 1490 de estas 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 comenzó la investigación posteriormente; el contrato afectado fue pausado a las 03:53. Los principales exchanges comenzaron a detener los depósitos y retiros de ICX a las 05:54, y la detención total de la red se hizo efectiva 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 al mismo tiempo reparó la vulnerabilidad subyacente.

El informe de revisión considera que la raíz del problema es el proceso de respuesta al evento, y no la falta de capacidad de detección. La alerta se activó en 7 minutos, pero este tipo de alertas a menudo se confunden con excepciones 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, poco después de lo cual el contrato fue pausado.

Cuando la cadena finalmente se detuvo, la mayor parte del ICX afectado ya había sido incorporado al sistema de custodia de los exchanges. Los métodos de control del lado de la cadena de ICON no pudieron detener la transferencia o conversión de los activos que los exchanges tenían en sus manos. La fundación solo pudo depender de la congelación de activos en los exchanges, notificaciones de conservación, abogados y autoridades para manejar la situación.

Los límites de custodia determinan directamente la atribución de pérdidas. ICON indicó que todos los activos afectados pertenecen a la fundación, y 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 han sido completamente recuperados; de los 113,634 USDC prestados, 82,430 han sido recuperados. Las pérdidas netas confirmadas son aproximadamente 150.2 ETH, más 31,204 USDC. La gran mayoría del ICX involucrado solo ha sido congelado o rastreado en los exchanges, y no ha sido realmente recuperado.

La estructura de control de ICON también difiere de los otros dos casos. El informe de revisión indica que durante el período de migración, la red fue controlada por la fundación; el documento de guía de migración menciona que el consenso opera en modo de mantenimiento, con solo 7 nodos centrales. Por lo tanto, esta detención se basa en una estructura de operación especial claramente controlada por la fundación.

La naturaleza de los permisos de emergencia también es poder a nivel de balance de activos y pasivos {#article-toc-33687-5}

Cada detención de blockchain, en esencia, es una transferencia de riesgo a diferentes lugares.

• Cronos modifica la historia de la cadena oficial: puede proteger los activos que aún están bajo la jurisdicción de la cadena, pero invalida todas las actividades normales en la cadena que no están relacionadas con la vulnerabilidad, y no puede hacer nada con los activos en Ethereum.
• Ontology convierte el riesgo en costos de tiempo y pérdidas de disponibilidad del servicio; durante la investigación, las transacciones no pueden liquidarse y no se confirma la pérdida de activos en libros.
• ICON completó la separación del contrato y la red solo después de que los activos ya habían sido transferidos fuera 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 calificación descentralizada puede ocultar estos resultados tan diferentes. Un criterio de evaluación más pragmático es: ¿se publican las reglas de manejo de emergencia? ¿Cuál es el umbral que activa el manejo? ¿Solo se detienen los nuevos bloques, o se reescribe el estado de la cadena ya confirmado? Cuando ocurre la intervención, ¿quién controla los activos que están fuera de la jurisdicción de esta cadena? ¿Quién se compromete a asumir las pérdidas restantes?

Cronos y Tectonic aún deben publicar un informe completo de revisión. Ontology necesita revelar los detalles del ataque y las reglas de autorización de emergencia, y posteriormente confirmar si se han cumplido las condiciones para la actualización y el reinicio. Lo que realmente merece ser comparado son los límites de riesgo que cada red ha establecido: qué historia, tiempo y fondos estarán bajo riesgo.