¿El retroceso en la cadena no puede recuperar los activos robados?

Tres blockchains públicas se detuvieron de emergencia, revelando las limitaciones reales del poder de respuesta en la cadena.

Escrito por: Liam 'Akiba' Wright

Traducido por: Saoirse, Foresight News

En cuatro días, tres redes de blockchain dejaron de producir bloques. Cada parada de la red utilizó diferentes poderes de emergencia, de los cuales solo Cronos reescribió parte de la historia oficial de la cadena.

Cronos indicó que, tras un ataque de vulnerabilidad al protocolo Tectonic, los nodos validadores 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 suspendió la producción de bloques antes de confirmar el comportamiento malicioso; 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 suspendió 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ía de los ICX robados ya se habían transferido a cuentas de custodia en exchanges.

La detención de la blockchain es solo el primer nivel de control. La pregunta más profunda es: ¿quién tiene la autoridad para ordenar la detención de la red? ¿Pueden reescribir el estado de la cadena ya confirmado? ¿Qué pérdidas no se pueden recuperar una vez que los fondos se transfieren a través de cadenas o entran en instituciones de custodia centralizadas?

La información de permisos revelada por las medidas de emergencia desencadenadas por el evento de la red ya conoce los riesgos de recuperación. La detención de la red por el ataque de vulnerabilidad de CronosTectonic y la restauración al estado de la cadena antes del ataque se basan en el consenso de los validadores; el anuncio de reinicio no reveló datos de votación y todas las actividades en la cadena después del punto de verificación fueron anuladas; los fondos transferidos a Ethereum no están bajo el control de Cronos; la estadística final de pérdidas del protocolo Tectonic aún no se ha completado. Ontology descubrió riesgos potenciales durante la inspección diaria, y tras confirmar la existencia de actividades maliciosas, suspendió preventivamente la producción de bloques, sin realizar un retroceso. El equipo de desarrollo central, el equipo técnico y los nodos validadores participaron; no se revelaron los umbrales de activación de emergencia ni la reparación durante la actualización de la red, lo que impidió la ejecución de transacciones; no se encontraron activos de usuarios dañados. ICON tuvo un contrato de migración con una vulnerabilidad de repetición, primero suspendió el contrato y luego detuvo toda la red; durante la fase de migración, la red fue controlada por la fundación, y la cantidad de nodos validadores centrales se redujo, asumiendo la fundación las pérdidas; la posibilidad de recuperar los ICX en los exchanges depende de la parte de custodia, los procesos legales y las agencias de aplicación de la ley.

Comparación de los métodos de respuesta de emergencia de las tres blockchains: Cronos, Ontology e ICON

Cronos: De la detención a la reescritura del estado de la cadena

Cronos denominó la gestión de este evento como "acción de emergencia del consenso de validadores". El anuncio de reinicio del 31 de agosto muestra 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 verificación, el estado de la cadena relacionado con la vulnerabilidad, junto con todas las transacciones no relacionadas durante ese período, se borraron de la cadena oficial. El anuncio de reinicio no incluyó una lista de transacciones, estadísticas de nodos validadores, 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 gestión y el alcance del impacto técnico.

Incluso el tamaño real 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 se completaron en la cadena de Cronos. Las estadísticas de Bitquery indican un flujo total aún mayor, con aproximadamente 8.3 millones de dólares en activos fluyendo hacia Ethereum, y un total de 10,961 bloques fueron descartados.

Los dos conjuntos de estadísticas tienen diferentes objetos de conteo, y los datos finales de pérdidas del protocolo Tectonic aún están por publicarse. Pero una cosa ya es muy clara: el retroceso de Cronos solo puede restaurar el estado que aún permanece dentro de esta cadena, los activos en la cadena de Ethereum están completamente fuera de su control.

El plan de gestión de activos de Tectonic aún deja problemas de cuentas para los usuarios. El protocolo indicó que priorizará la apertura de funciones de retiro y reembolso de préstamos, mientras que suspenderá depósitos y nuevos préstamos. Este plan ofrece a los usuarios una salida y un camino para reducir el apalancamiento, pero no se ha confirmado si el proveedor de fondos podrá recuperar la totalidad. El informe posterior que Tectonic publicará también necesita aclarar el principio de la vulnerabilidad, el total de fondos que fluyeron, 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 diversos 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 recuperación posterior. La red de la cadena puede declarar un reinicio formal, pero los diversos servicios que dependen de ella pueden no estar listos.

Ontology: La detención solo busca ganar tiempo para la gestión, no revoca transacciones

La acción de gestión de Ontology ocurrió antes de confirmar actividades maliciosas. La red indicó que el equipo de desarrollo central descubrió riesgos de seguridad potenciales durante una inspección diaria y detuvo inmediatamente la producción de bloques, dejando que el equipo técnico y los nodos validadores realizaran una revisión del sistema.

La actualización del 1 de septiembre indicó que la revisión confirmó la existencia de un ataque malicioso, la red principal continuará detenida para realizar reparaciones de vulnerabilidades y actualizaciones; este ataque no afectó los activos de los usuarios. El objetivo de Ontology es restaurar el funcionamiento normal dentro de 24 horas, siempre que las pruebas de seguridad, reparaciones de vulnerabilidades, actualizaciones y 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 validadores de la red en la gestión, 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, incluyendo 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 puede generar 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 las reparaciones de vulnerabilidades, actualizaciones y pruebas. Los usuarios no pueden ajustar posiciones, realizar transferencias o liquidaciones en la cadena, y todos los servicios externos conectados a esta cadena solo pueden esperar señales de la red.

Los criterios para determinar la reanudación del funcionamiento están orientados a la seguridad, pero los detalles específicos son limitados. Ontology indicó que, siempre que se completen las reparaciones, actualizaciones, pruebas y verificaciones, se esforzará por restaurar el servicio en 24 horas, pero no se ha revelado quién determina si se cumplen las condiciones, ni cuál es el umbral de activación.

Esto genera incertidumbre a nivel de gobernanza: el anuncio menciona a las partes involucradas en la revisión, pero no se ha aclarado quién tiene la autoridad final para decidir el reinicio. Para los usuarios, el riesgo actual proviene de la interrupción del servicio, y no de pérdidas de activos determinadas o de un retroceso de la cadena.

ICON: ¿Por qué la detención de la blockchain llegó demasiado tarde?

El evento de ICON muestra de manera completa el proceso de alerta, gestión 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 llevó a 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 inició una investigación posteriormente; el contrato afectado fue suspendido a las 03:53. Los principales exchanges comenzaron a cerrar las funciones de depósito y retiro de ICX a las 05:54, y la detención total de la red entró en vigor oficialmente a las 06:18:54. ICON completó el reinicio alrededor de las 07:51 del 28 de agosto, transcurriendo aproximadamente 25 horas, al mismo tiempo que se repararon las vulnerabilidades subyacentes.

El informe de revisión considera que la raíz del problema es el proceso de respuesta a eventos, 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, y poco después se suspendió el contrato.

Cuando la cadena finalmente se detuvo, la mayoría de los ICX afectados ya habían sido incorporados a los sistemas 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 su poder. La fundación solo pudo depender de la congelación de activos en los exchanges, notificaciones de conservación, abogados y agencias de aplicación de la ley 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 ya han sido recuperados en su totalidad; 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 de los ICX involucrados solo han sido congelados o rastreados en los exchanges, y no han sido realmente recuperados.

La estructura de control de ICON también difiere de los otros dos casos. El informe de revisión indica que durante la migración de tokens, 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.

Los poderes de emergencia son, en esencia, un poder a nivel de balance de activos y pasivos

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 anula 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 se pueden liquidar, y no se confirma la pérdida de activos en libros. * ICON completa la separación del contrato y la red solo después de que los activos ya se han transferido fuera del alcance de la custodia de la cadena; las pérdidas confirmadas son asumidas por la fundación, y la recuperación de los ICX congelados depende de los exchanges y las autoridades judiciales.

Una simple puntuación descentralizada puede ocultar estos resultados tan diferentes. Un estándar de evaluación más pragmático es: ¿se publican las reglas de respuesta de emergencia? ¿Cuál es el umbral que activa la gestión? ¿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 se han desvinculado 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 de revisión completo. 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 delineado: qué historia, tiempo y fondos estarán bajo riesgo.