Autor: Liam 'Akiba' Wright, Cryptoslate
Compilado por: Saoirse, Foresight News
En cuatro días, tres redes blockchain se detuvieron sucesivamente. Cada interrupción de red utilizó permisos de emergencia completamente diferentes, y solo Cronos modificó parte del historial oficial de la cadena.
Cronos indicó que, tras el ataque de vulnerabilidad al protocolo Tectonic, los nodos de validación apagaron la red mediante el mecanismo de consenso, restaurando la cadena al estado anterior al ataque y reiniciando la generación de bloques desde la altura de bloque 90,896,189. Esta operación no solo detuvo la generación de bloques, sino que también reescribió directamente el estado de la cadena. Todas las transacciones y cambios de estado generados después del punto de restauración ya no pertenecen a la cadena principal oficial tras el reinicio.
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 causó pérdidas de activos de los usuarios. ICON primero suspendió el contrato atacado y luego apagó toda la red; la fundación afirmó que, durante la fase de migración, tenía control sobre la red, y en ese momento la mayor parte de los ICX robados ya se habían transferido a cuentas de custodia en intercambios.
El cierre de la blockchain es simplemente una medida de control de primer nivel. El problema más profundo es: ¿quiénes tienen autoridad para ordenar el cierre de la red? ¿Pueden reescribir el estado de la cadena ya confirmado? ¿Qué pérdidas serán irrecuperables cuando los fondos se transfieran entre cadenas o ingresen a instituciones centralizadas de custodia?
Se ha restaurado la información de permisos para las medidas de respuesta de emergencia a eventos desencadenados por red; se conoce el riesgo de recuperación tras el ataque de vulnerabilidad CronosTectonic que apagó la red y restauró el estado de la cadena al momento previo a la vulnerabilidad mediante consenso de validadores; todos los eventos en cadena posteriores al punto de verificación de los datos de conteo de votos y el umbral de votación se anulan; los fondos transferidos a Ethereum no están bajo el control de Cronos; el cálculo final de pérdidas del protocolo Tectonic aún no se ha completado; durante una inspección diaria, Ontology detectó un riesgo potencial, posteriormente se confirmó actividad maliciosa, por lo que se suspendió preventivamente la producción de bloques sin realizar rollback; el equipo de desarrollo central, el equipo técnico y los nodos validadores participaron; no se divulgaron los umbrales de activación para la respuesta de emergencia; durante la reparación y actualización de la red, las transacciones no pudieron ejecutarse; no se encontró daño en los activos de los usuarios; el contrato de migración de ICON presenta una vulnerabilidad de replay; se suspendió primero el contrato, luego se detuvo toda la red; durante la fase de migración, la red estuvo bajo el control de la fundación, con una reducción en el número de nodos validadores centrales; las pérdidas las asume la fundación; la recuperación de ICX almacenado en intercambios depende del proveedor de custodia, los procesos legales y las autoridades encargadas de hacer cumplir la ley.
Comparación de los métodos de respuesta de emergencia para las cadenas públicas Cronos, Ontology e ICON
Cronos: de la interrupción a la reescritura del estado de la cadena
Cronos denominó esta respuesta al evento como "acción de emergencia de consenso de validadores". El anuncio de reinicio del 31 de agosto indicó que, a las 23:49:01 UTC del 30 de agosto, la red recuperó la producción de bloques desde la altura de bloque 90,896,189, retrocediendo el estado de la cadena al punto anterior al ataque de vulnerabilidad de Tectonic.
La operación de apagado de Cronos implica tomar decisiones sobre la distribución de beneficios en los puntos de recuperación. Después del punto de verificación, el estado en cadena relacionado con la vulnerabilidad, junto con todas las transacciones irrelevantes durante ese período, se eliminan de la cadena oficial. El anuncio de reinicio no incluye una lista de transacciones, estadísticas de nodos de validación, umbrales de peso de voto ni una lista de nodos participantes. Cronos se compromete a publicar un informe posterior al evento que explique completamente el proceso de manejo y el alcance técnico del impacto.
Incluso la escala real de activos protegidos por esta intervención aún no está clara. TRM Labs estima que, tras la manipulación del precio del token TONIC, se prestaron aproximadamente 75 millones de dólares en activos; de ellos, unos 6 millones de dólares se dirigieron a Ethereum y aproximadamente 68,7 millones de dólares se revertieron dentro de la cadena Cronos. Las estadísticas de Bitquery arrojan un volumen total de salida más alto: unos 8,3 millones de dólares en activos se dirigieron a Ethereum, y un total de 10.961 bloques fueron descartados.
Los dos métodos de estadística tienen diferentes objetivos, y los datos finales de pérdidas de Tectonic aún no se han publicado. Pero un punto ya es muy claro: 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 disposición de activos de Tectonic aún deja pendientes problemas contables de los usuarios. El protocolo indica que se priorizará la apertura de funciones de retiro y reembolso de préstamos, mientras se suspenden los depósitos y nuevos préstamos. Este plan ofrece a los usuarios una vía para salir y reducir la apalancamiento, pero aún no se ha confirmado si los proveedores de fondos podrán rescatar completamente sus activos. El informe posterior a evento que Tectonic aún debe publicar necesita aclarar el mecanismo de la vulnerabilidad, el monto total de salidas de fondos, el volumen de malas deudas, los activos recuperados y las demás deudas pendientes.
Los avances en la recuperación de diversas infraestructuras no están sincronizados con la reanudación del consenso de la cadena. Cronos advierte que los diversos protocolos, puentes cruzados, exploradores de bloques y servicios RPC requerirán más tiempo para recuperarse. La página de estado de Alchemy también registra por separado este apagón y la recuperación posterior. Aunque la red de la cadena puede declarar su reinicio oficial, los servicios que dependen de ella aún podrían no estar listos.
Ontology: El mantenimiento solo busca ganar tiempo para gestionar el incidente, sin cancelar las operaciones
La acción de处置 de Ontology ocurrió antes de confirmar la actividad maliciosa. La red indicó que el equipo de desarrollo principal descubrió posibles vulnerabilidades de seguridad durante las inspecciones diarias, suspendió inmediatamente la producción de bloques y entregó el sistema a un equipo técnico y nodos de validación para su revisión.
La actualización del 1 de septiembre indica que la revisión confirmó la presencia de un ataque malicioso; la red principal seguirá fuera de línea mientras se realizan la corrección de vulnerabilidades y la actualización de la red; el ataque no afectó los activos de los usuarios. Ontology tiene como objetivo restaurar el funcionamiento normal dentro de las próximas 24 horas, siempre que las pruebas de seguridad, la corrección de vulnerabilidades, la actualización y las pruebas se completen exitosamente.
El mantenimiento de Ontology conserva todos los estados en cadena confirmados, solo deteniendo la confirmación y liquidación de nuevas transacciones. El anuncio no especifica el punto de recuperación ni publicó el conjunto de transacciones que deben anularse.
La información sobre los permisos divulgada públicamente no es completa. El anuncio menciona que el equipo de desarrollo principal, el equipo técnico y los nodos de validación de la red participaron en el manejo, pero no especifica quién es la persona con autoridad decisoria final ni proporciona un umbral de respuesta de emergencia en formato numérico. El documento VBFT de Ontology describe el mecanismo de consenso habitual, incluyendo la generación de bloques confirmados por los nodos y la gestión del conjunto de nodos de consenso para actualizaciones de contratos, pero el documento solo cubre escenarios de funcionamiento normal; las reglas de suspensión de emergencia utilizadas el 31 de agosto no se han divulgado públicamente.
Aunque no se haya producido pérdida de activos, el tiempo de inactividad aún conlleva costos reales. Ontology informó a los usuarios que las transacciones en la cadena no podrán procesarse y sugirió no realizar operaciones sensibles al tiempo; posteriormente indicó que el reinicio de la red depende de la corrección de la vulnerabilidad, la actualización y las pruebas. Los usuarios no pueden ajustar sus posiciones ni realizar transferencias ni liquidaciones en la cadena, y todos los servicios externos conectados a esta red deben esperar la señal de la red.
Los criterios para determinar la recuperación del servicio están orientados a la seguridad, pero los detalles específicos son limitados. Ontology indica que, una vez completadas la reparación, la actualización, las pruebas y la validación, se esforzará por restaurar el servicio en 24 horas, pero no ha revelado quién determinará si se han cumplido las condiciones ni cuáles son los umbrales de activación.
Esto genera incertidumbre en el nivel de gobernanza: el anuncio especifica las partes involucradas en la revisión, pero no identifica claramente a la entidad con la autoridad final para tomar la decisión de reanudar el servicio. Para los usuarios, el riesgo actual proviene de la interrupción del servicio, no de una pérdida de activos confirmada ni de un rollback en la cadena.
ICON: Por qué el tiempo ya se ha acabado para el mantenimiento de la blockchain
El evento de ICON mostró completamente el proceso de alerta, respuesta y liberación de activos del control de la cadena.
Según el informe de revisión posterior al incidente de la fundación, el atacante reprodujo 1.492 veces dos mensajes de retiro firmados históricamente válidos entre el 27 de agosto a las 02:01:02 y las 02:21:12 UTC. Un defecto de precisión hizo que 1.490 de estas llamadas tuvieran éxito, transfiriendo 119.866.000 ICX y 531.600 bnUSD desde el fondo de activos de la fundación.
02:08 el sistema de monitoreo emitió una alerta, y el personal técnico inició la investigación posteriormente; el contrato afectado se suspendió a las 03:53. Las principales plataformas de intercambio cerraron progresivamente los depósitos y retiros de ICX a las 05:54, y el apagón total entró en vigor oficialmente a las 06:18:54. ICON se reinició alrededor de las 07:51 del 28 de agosto, tras un intervalo de aproximadamente 25 horas, y se corrigió la vulnerabilidad subyacente.
El informe de revisión concluye que la causa raíz fue el proceso de respuesta al incidente, no una falta de capacidad de detección. La alerta se activó en menos de 7 minutos, pero este tipo de alertas a menudo se confunden con anomalías de RPC no relacionadas, y el sistema no notificó al personal de guardia. La investigación técnica no comenzó hasta aproximadamente las 03:40, poco antes de que se suspendiera el contrato.
Cuando la cadena se desconecte oficialmente, la mayoría de los ICX afectados ya habrán sido incorporados por los intercambios a sus propios sistemas de custodia. Los controles de la cadena ICON no pueden impedir que los intercambios transfieran o conviertan los activos que poseen. La fundación solo puede confiar en la congelación de activos por parte de los intercambios, notificaciones de conservación, abogados y autoridades encargadas de hacer cumplir la ley.
El límite de custodia determina directamente la asignación de pérdidas. ICON indica que todos los activos afectados pertenecen a la fundación; los depósitos, saldos y posiciones de los usuarios normales no se han visto afectados. El informe muestra que se han recuperado completamente 531600 bnUSD y 1,366 millones de SODA; de los 113634 USDC prestados, se han recuperado 82430. La pérdida neta confirmada es de aproximadamente 150,2 ETH, más 31204 USDC. La mayoría de los ICX involucrados simplemente fueron congelados o rastreados en el intercambio, sin ser realmente recuperados.
La estructura de gobernanza 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 estuvo bajo el control de la fundación; el documento de instrucciones de migración menciona que el consenso funcionaba en modo de mantenimiento, con solo 7 nodos principales. Por lo tanto, este apagón se basó en una arquitectura de operación especial claramente controlada por la fundación.
Los permisos de emergencia también son poderes a nivel del balance general.
Cada interrupción de la cadena de bloques es, en esencia, trasladar el riesgo a otro lugar.
- Cronos modifica el historial de la cadena principal: puede proteger los activos que aún se encuentran bajo la jurisdicción de la cadena, pero invalida simultáneamente las actividades normales en la cadena fuera de la vulnerabilidad, sin capacidad para afectar los activos en Ethereum.
- Ontology convierte el riesgo en costo de tiempo y pérdida de disponibilidad del servicio; durante la investigación, las operaciones no pudieron liquidarse y no se confirmó ninguna pérdida contable de activos.
- ICON completó la separación del contrato y la red después de que los activos ya hubieran salido del alcance de la custodia en la cadena; se confirma que la pérdida será asumida por la fundación, y la recuperación de los ICX congelados depende de los intercambios y las autoridades judiciales.
Una simple calificación descentralizada ocultará estos resultados tan distintos. Un criterio de evaluación más pragmático es: ¿son públicas las reglas de respuesta de emergencia? ¿Cuál es el umbral que activa la intervención? ¿Se detiene solo la creación de nuevos bloques, o se reescribe el estado de la cadena ya confirmado? ¿Quién controla los activos que se escapan de la jurisdicción de esta cadena cuando ocurre la intervención? ¿Quién se compromete a asumir las pérdidas restantes?
Cronos y Tectonic aún deben publicar el informe completo de revisión. Ontology necesita divulgar los detalles del ataque y las reglas de autorización de emergencia, y posteriormente debe confirmar si se han cumplido las condiciones para la actualización y reinicio. Lo realmente digno de comparar son los límites de riesgo establecidos por cada red: qué historial, tiempo y fondos se exponen al riesgo.