Fe y firmeza después de la crisis de seguridad: ¿por qué SUI todavía tiene potencial de crecimiento a largo plazo?

TL;DR

1. La vulnerabilidad de Cetus proviene de la implementación del contrato, no de SUI o del lenguaje Move en sí:

El ataque se basa fundamentalmente en la falta de verificación de los límites de las funciones aritméticas en el protocolo Cetus------una vulnerabilidad lógica causada por una máscara demasiado amplia y un desbordamiento de desplazamiento, que no está relacionada con el modelo de seguridad de recursos de la cadena SUI o el lenguaje Move. La vulnerabilidad se puede corregir con "una verificación de límites en una línea" y no afecta la seguridad central de todo el ecosistema.

2. El valor de la "centralización razonable" en el mecanismo SUI se manifiesta en tiempos de crisis:

Aunque SUI presenta una ligera tendencia a la centralización con funciones como el ciclo de validadores DPoS y la congelación de listas negras, esto fue precisamente útil en la respuesta al evento CETUS: los validadores sincronizaron rápidamente las direcciones maliciosas en la Deny List, rechazando empaquetar las transacciones relacionadas, lo que logró la congelación instantánea de más de 160 millones de dólares en fondos. Esto es esencialmente una forma activa de "keynesianismo en cadena", donde una efectiva regulación macroeconómica tiene un efecto positivo en el sistema económico.

3. Reflexiones y sugerencias sobre la seguridad técnica:

Matemáticas y verificación de límites: Introducir aserciones de límites superior e inferior para todas las operaciones aritméticas clave (como desplazamientos, multiplicación y división), y realizar fuzzing de valores extremos y verificación formal. Además, se necesita mejorar la auditoría y la supervisión: además de la auditoría de código general, agregar un equipo de auditoría matemática especializado y detección en tiempo real del comportamiento de transacciones en la cadena, para capturar de manera temprana divisiones anómalas o préstamos relámpago de gran volumen.

4. Resumen y recomendaciones del mecanismo de garantía de fondos:

En el evento de Cetus, SUI colaboró eficientemente con el equipo del proyecto, congelando con éxito más de 160 millones de dólares y promoviendo un plan de compensación del 100%, lo que refleja una fuerte capacidad de respuesta en la cadena y un sentido de responsabilidad ecológica. La Fundación SUI también añadió 10 millones de dólares en fondos para auditoría, fortaleciendo la línea de defensa de seguridad. En el futuro, se pueden avanzar mecanismos como un sistema de seguimiento en la cadena, herramientas de seguridad construidas en conjunto por la comunidad, y seguros descentralizados, mejorando así el sistema de garantía de fondos.

5. La expansión diversa del ecosistema SUI

SUI ha logrado una rápida transición de "nueva cadena" a "ecosistema robusto" en menos de dos años, construyendo un mapa ecológico diversificado que abarca múltiples sectores como stablecoins, DEX, infraestructura, DePIN y juegos. La capitalización total de stablecoins ha superado los 1,000 millones de dólares, proporcionando una sólida base de liquidez para el módulo DeFi; el TVL ocupa el puesto 8 a nivel mundial, con el quinto lugar en actividad de transacciones a nivel global y el tercero entre las redes no EVM (solo detrás de Bitcoin y Solana), lo que demuestra una fuerte participación de usuarios y capacidad de acumulación de activos.

1. Una reacción en cadena provocada por un ataque.

El 22 de mayo de 2025, el principal protocolo AMM Cetus, desplegado en la red SUI, sufrió un ataque de hackers. Los atacantes aprovecharon un fallo lógico relacionado con el "problema de desbordamiento de enteros" para llevar a cabo un control preciso, lo que resultó en pérdidas de más de 200 millones de dólares en activos. Este incidente no solo es uno de los mayores accidentes de seguridad en el ámbito DeFi hasta la fecha este año, sino que también se ha convertido en el ataque de hackers más destructivo desde el lanzamiento de la mainnet de SUI.

Según los datos de DefiLlama, el TVL total de SUI en la cadena cayó más de 330 millones de dólares el día del ataque, y el monto bloqueado del protocolo Cetus se evaporó instantáneamente en un 84%, cayendo a 38 millones de dólares. Como resultado, varios tokens populares en SUI (incluidos Lofi, Sudeng, Squirtle, entre otros) cayeron entre un 76% y un 97% en solo una hora, lo que generó una amplia preocupación en el mercado sobre la seguridad de SUI y la estabilidad de su ecosistema.

Pero después de esta ola de impacto, el ecosistema SUI ha mostrado una gran resistencia y capacidad de recuperación. A pesar de que el evento de Cetus trajo fluctuaciones en la confianza a corto plazo, los fondos en la cadena y la actividad de los usuarios no han sufrido una disminución persistente, sino que han impulsado un aumento significativo en la atención a la seguridad, la construcción de infraestructura y la calidad de los proyectos en todo el ecosistema.

Klein Labs analizará las causas de este ataque, el mecanismo de consenso de nodos de SUI, la seguridad del lenguaje MOVE y el desarrollo ecológico de SUI, organizando el actual ecosistema de esta cadena pública que aún se encuentra en una etapa temprana de desarrollo y explorando su potencial de desarrollo futuro.

2. Análisis de las causas del ataque del evento Cetus

2.1 Proceso de implementación del ataque

Según el análisis técnico del equipo de Slow Mist sobre el incidente de ataque de Cetus, los hackers aprovecharon con éxito una vulnerabilidad crítica de desbordamiento aritmético en el protocolo, utilizando préstamos relámpago, manipulación de precios precisa y defectos en el contrato, robando más de 200 millones de dólares en activos digitales en un corto período de tiempo. La ruta del ataque se puede dividir aproximadamente en las siguientes tres etapas:

①Iniciar un préstamo relámpago, manipular el precio

Los hackers primero utilizaron un intercambio relámpago con un deslizamiento máximo de 100 mil millones de haSUI, prestando una gran cantidad de fondos para manipular los precios.

El préstamo relámpago permite a los usuarios pedir prestado y devolver fondos en una sola transacción, pagando solo una tarifa. Tiene características de alto apalancamiento, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para reducir el precio del mercado en poco tiempo y controlar con precisión en un rango muy estrecho.

Luego, el atacante se preparó para crear una posición de liquidez extremadamente estrecha, estableciendo el rango de precios exactamente entre la oferta más baja de 300,000 y el precio más alto de 300,200, con un ancho de precio de solo 1.00496621%.

A través de los métodos anteriores, los hackers utilizaron una cantidad suficiente de tokens y una gran liquidez para manipular con éxito el precio de haSUI. Luego, también manipularon varios tokens sin valor real.

②Agregar liquidez

Un atacante crea posiciones de liquidez estrechas, declara que añade liquidez, pero debido a una vulnerabilidad en la función checked_shlw, finalmente solo recibe 1 token.

Esencialmente se debe a dos razones:

1. Configuración de máscara demasiado amplia: equivale a un límite de adición de liquidez extremadamente grande, lo que hace que la verificación de la entrada del usuario en el contrato sea prácticamente inútil. Los hackers, al establecer parámetros anómalos, construyen entradas que siempre son menores que ese límite, eludiendo así la detección de desbordamiento.

2. Desbordamiento de datos truncado: al realizar la operación de desplazamiento n << 64 en el valor numérico n, se produjo un truncamiento de datos debido a que el desplazamiento excedió el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte de desbordamiento de bits altos se descartó automáticamente, lo que resultó en que el resultado de la operación fue mucho menor de lo esperado, lo que llevó al sistema a subestimar la cantidad de haSUI necesaria para el intercambio. El resultado final de los cálculos fue aproximadamente menor que 1, pero como se redondeó hacia arriba, el resultado final fue igual a 1, lo que significa que el hacker solo necesita agregar 1 token para obtener una gran liquidez.

③ retirar liquidez

Realiza el reembolso de préstamos relámpago y conserva enormes ganancias. Finalmente, retira activos de tokens por un valor total de cientos de millones de dólares de múltiples pools de liquidez.

La situación de pérdida de fondos es grave, el ataque ha provocado el robo de los siguientes activos:

• 12.9 millones de SUI (aproximadamente 54 millones de dólares)

• 6000万美元 USDC

• 490 millones de dólares Haedal Staked SUI

• 1950 millones de dólares TOILET

• Otros tokens como HIPPO y LOFI cayeron un 75--80%, la liquidez se agotó.

2.2 Causas y características de esta vulnerabilidad

La vulnerabilidad de Cetus tiene tres características:

1. Costo de reparación muy bajo: por un lado, la causa fundamental del evento Cetus es un descuido en la biblioteca matemática de Cetus, y no un error en el mecanismo de precios del protocolo o en la arquitectura subyacente. Por otro lado, la vulnerabilidad se limita únicamente a Cetus y no está relacionada con el código de SUI. La raíz de la vulnerabilidad se encuentra en una evaluación de condición de frontera, y solo se necesitan modificar dos líneas de código para eliminar completamente el riesgo; una vez completada la reparación, se puede desplegar de inmediato en la red principal, asegurando que la lógica del contrato posterior sea completa y eliminando esta vulnerabilidad.

2. Alta ocultación: El contrato ha estado en funcionamiento estable sin fallos durante dos años, el Cetus Protocol ha realizado múltiples auditorías, pero no se han encontrado vulnerabilidades, la principal razón es que la biblioteca Integer_Mate utilizada para cálculos matemáticos no fue incluida en el alcance de la auditoría.

Los hackers utilizan valores extremos para construir con precisión intervalos de negociación, creando escenarios extremadamente raros con alta liquidez, lo que activa lógicas anómalas, lo que indica que este tipo de problemas son difíciles de detectar mediante pruebas ordinarias. Estos problemas a menudo se encuentran en áreas ciegas de la visión de las personas, por lo que permanecen ocultos durante mucho tiempo antes de ser descubiertos.

3. No es un problema exclusivo de Move:

Move es superior a varios lenguajes de contratos inteligentes en términos de seguridad de recursos y verificación de tipos, y tiene una detección nativa para problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al agregar liquidez, se utilizó un valor incorrecto para la verificación del límite superior al calcular la cantidad de tokens necesarios, y se utilizó una operación de desplazamiento en lugar de la multiplicación convencional. Si se utilizaran operaciones de suma, resta, multiplicación y división convencionales, Move verificaría automáticamente la situación de desbordamiento, evitando así este problema de truncamiento de bits altos.

Vulnerabilidades similares también han aparecido en otros lenguajes (como Solidity, Rust), e incluso son más fáciles de explotar debido a la falta de protección contra el desbordamiento de enteros; antes de la actualización de la versión de Solidity, la verificación de desbordamiento era muy débil. Históricamente, han ocurrido desbordamientos de suma, desbordamientos de resta, desbordamientos de multiplicación, etc., y la causa directa es que el resultado de la operación excede el rango. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity se lograron eludiendo las declaraciones de verificación en el contrato mediante parámetros cuidadosamente construidos, logrando ataques de transferencias excesivas.

3. Mecanismo de consenso de SUI

3.1 Introducción al mecanismo de consenso SUI

Resumen:

SUI adopta un marco de Prueba de Participación Delegada (DeleGated Proof of Stake, abreviado DPoS); aunque el mecanismo DPoS puede aumentar el rendimiento de las transacciones, no puede proporcionar un alto grado de descentralización como lo hace PoW (Prueba de Trabajo). Por lo tanto, el grado de descentralización de SUI es relativamente bajo, el umbral de gobernanza es relativamente alto y los usuarios comunes tienen dificultades para influir directamente en la gobernanza de la red.

• Número promedio de validadores: 106

• Promedio del ciclo de Epoch: 24 horas

Proceso del mecanismo:

• Delegación de derechos: Los usuarios comunes no necesitan ejecutar nodos por sí mismos, solo deben hacer staking de SUI y delegarlo a un validador candidato para participar en la garantía de seguridad de la red y en la distribución de recompensas. Este mecanismo puede reducir la barrera de entrada para los usuarios comunes, permitiéndoles participar en el consenso de la red a través de la "contratación" de validadores de confianza. Esta también es una gran ventaja del DPoS en comparación con el PoS tradicional.

• Representa la ronda de generación de bloques: un pequeño número de validadores seleccionados generan bloques en un orden fijo o aleatorio, lo que mejora la velocidad de confirmación y aumenta el TPS.

• Elección dinámica: Al final de cada ciclo de conteo de votos, se realiza una rotación dinámica y una nueva elección del conjunto de Validadores según el peso del voto, garantizando la vitalidad de los nodos, la coherencia de intereses y la descentralización.

Ventajas de DPoS:

• Alta eficiencia: Debido a que el número de nodos de creación de bloques es controlable, la red puede completar la confirmación en milisegundos, satisfaciendo la alta demanda de TPS.

• Bajo costo: Menos nodos participan en el consenso, lo que reduce significativamente el ancho de banda de la red y los recursos computacionales necesarios para la sincronización de información y la agregación de firmas. Como resultado, los costos de hardware y operación disminuyen, se reducen los requisitos de poder de cálculo y los costos son más bajos. Finalmente, se logra una tarifa de usuario más baja.

• Alta seguridad: los mecanismos de apuesta y delegación amplifican el costo y el riesgo de un ataque; junto con el mecanismo de confiscación en la cadena, se inhiben efectivamente los comportamientos maliciosos.

Al mismo tiempo, en el mecanismo de consenso de SUI, se utiliza un algoritmo basado en BFT (tolerancia a fallos bizantinos), que requiere que más de dos tercios de los votos de los validadores lleguen a un consenso para confirmar las transacciones. Este mecanismo asegura que incluso si un pequeño número de nodos actúa de manera maliciosa, la red puede seguir operando de forma segura y eficiente. Para cualquier actualización o decisión importante, también se requiere más de dos tercios de los votos para su implementación.

En esencia, el DPoS es una solución de compromiso del triángulo imposible.