Fe de hierro después de la crisis de seguridad: ¿por qué SUI aún tiene potencial de crecimiento a largo plazo?

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 una vulnerabilidad lógica relacionada con el "problema de desbordamiento de enteros" para llevar a cabo un control preciso, lo que provocó la pérdida 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 ahora este año, sino que también se ha convertido en el ataque de hackers más destructivo desde el lanzamiento de la red principal de SUI.

Según los datos de DefiLlama, el TVL total de SUI en la cadena cayó en más de 330 millones de dólares el día del ataque, y la cantidad bloqueada en el protocolo Cetus se evaporó instantáneamente en un 84%, cayendo a 38 millones de dólares. Como consecuencia, 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 y estabilidad ecológica de SUI.

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

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

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

2.1 Proceso de implementación del ataque

Según el análisis técnico del equipo Slow Fog sobre el incidente de ataque a 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, para robar más de 200 millones de dólares en activos digitales en un corto período de tiempo. La ruta de ataque se puede dividir aproximadamente en las siguientes tres etapas:

①Iniciar un préstamo relámpago, manipular precios

Los hackers primero aprovecharon el deslizamiento máximo para intercambiar 10 mil millones de haSUI a través de un préstamo relámpago, 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, y tiene características de alto apalancamiento, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para reducir rápidamente el precio del mercado y controlarlo con precisión dentro de un rango muy estrecho.

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

A través de la forma anterior, 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

El atacante crea posiciones de liquidez estrechas, declara que está añadiendo liquidez, pero debido a una vulnerabilidad en la función checked_shlw, al final solo recibe 1 token.

Esencialmente debido 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 validació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 n, debido a que el desplazamiento excede el ancho de bits efectivo del tipo de datos uint256 (256 bits), se produjo una truncación de datos. La parte de desbordamiento alto se descartó automáticamente, lo que provocó que el resultado de la operación fuera muy inferior al esperado, lo que hizo que el sistema subestimara la cantidad de haSUI necesaria para el intercambio. El resultado final del cálculo es aproximadamente inferior a 1, pero como se redondea hacia arriba, el resultado final es igual a 1, es decir, el hacker solo necesita agregar 1 token para poder intercambiar una gran liquidez.

③ Retirar liquidez

Realizar el reembolso del préstamo relámpago, conservando enormes ganancias. Finalmente, retirar 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 millones de dólares USDC

• 4900000 dólares Haedal Staked SUI

• 1950万美元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. El costo de reparación es extremadamente bajo: por un lado, la causa fundamental del incidente de Cetus fue una omisión en la biblioteca matemática de Cetus, y no un error en el mecanismo de precios del protocolo ni en la arquitectura subyacente. Por otro lado, la vulnerabilidad se limita únicamente a Cetus y no tiene relación con el código de SUI. La raíz de la vulnerabilidad se encuentra en una condición de límite, y solo se necesita 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 dicha vulnerabilidad.

2. Alta ocultación: el contrato ha estado funcionando sin fallos durante dos años desde su lanzamiento, el Cetus Protocol ha sido auditado varias veces, pero no se han encontrado vulnerabilidades, siendo la principal razón 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 transacción, creando escenarios extremadamente raros con alta liquidez, lo que activa una lógica anómala, lo que indica que este tipo de problemas es difícil de detectar mediante pruebas comunes. Este tipo de problemas a menudo se encuentra en zonas ciegas de la percepción humana, por lo que permanecen latentes 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, e incluye detección nativa para problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al agregar liquidez, se utilizó primero un valor incorrecto para la verificación del límite superior al calcular la cantidad de tokens necesarios, y se sustituyó la operación de multiplicación convencional por una operación de desplazamiento. 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 susceptibles a ser explotadas debido a su falta de protección contra desbordamientos de enteros; antes de la actualización de la versión de Solidity, la verificación de desbordamientos era muy débil. Históricamente, han ocurrido desbordamientos en la suma, en la resta y en la multiplicación, siendo la causa directa que los resultados de las operaciones excedieron el límite. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity, lograron el ataque mediante parámetros cuidadosamente construidos que evadieron las declaraciones de detección en el contrato, realizando 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 ofrecer el mismo nivel de descentralización extrema que PoW (Prueba de Trabajo). Por lo tanto, el grado de descentralización de SUI es relativamente bajo, y el umbral de gobernanza es relativamente alto, lo que dificulta que los usuarios comunes influyan directamente en la gobernanza de la red.

• Número promedio de validadores: 106

• Periodo promedio de Epoch: 24 horas

Mecanismo de flujo:

• Delegación de derechos: Los usuarios comunes no necesitan ejecutar nodos por sí solos, solo tienen que apostar SUI y delegarlo a validadores candidatos 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 participación para los usuarios comunes, permitiéndoles participar en el consenso de la red al "contratar" validadores de confianza. Esta también es una gran ventaja del DPoS en comparación con el PoS tradicional.

• Representa el ciclo de bloques: un pequeño número de validadores seleccionados producen 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 se vuelve a elegir el conjunto de validadores según el peso de los votos, garantizando la vitalidad de los nodos, la consistencia de intereses y la descentralización.

Ventajas de DPoS:

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

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

• Alta seguridad: los mecanismos de staking y delegación amplifican de manera sincrónica los costos y riesgos de los ataques; junto con el mecanismo de confiscación en la cadena, se suprimen eficazmente las conductas maliciosas.

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 la transacción. Este mecanismo asegura que, incluso si algunos nodos actúan de manera malintencionada, la red puede seguir funcionando de manera segura y eficiente. Para realizar cualquier actualización o decisión importante, también se requiere más de dos tercios de los votos para implementar.

En esencia, DPoS es una solución de compromiso del triángulo imposible, que busca un equilibrio entre la descentralización y la eficiencia. DPoS elige reducir la cantidad de nodos activos de validación a cambio de un mejor rendimiento en el triángulo "imposible" de seguridad-descentralización-escalabilidad, renunciando a cierto grado de descentralización completa en comparación con PoS o PoW puro, pero mejorando significativamente el rendimiento de la red y la velocidad de las transacciones.

3.2 El rendimiento de SUI en este ataque

3.2.1 Funcionamiento del mecanismo de congelación

En este evento, SUI congeló rápidamente las direcciones relacionadas con el atacante.

Desde el punto de vista del código, se trata de hacer que las transacciones de transferencia no puedan ser empaquetadas en la cadena. Los nodos de verificación son componentes clave de la cadena de bloques SUI, responsables de verificar transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores están implementando, en un nivel de consenso, un mecanismo similar al 'congelamiento de cuentas' en las finanzas tradicionales.

SUI en sí mismo tiene un mecanismo de lista de rechazo (deny list), que es una función de lista negra que puede bloquear cualquier transacción que involucre direcciones listadas. Debido a que esta función ya está presente en el cliente, cuando ocurre un ataque

SUI puede congelar inmediatamente la dirección del hacker. Sin esta función, incluso si SUI solo tiene 113 validadores, a Cetus le sería difícil coordinar a todos los validadores uno por uno en un corto período de tiempo.

3.2.2 ¿Quién tiene el poder de cambiar la lista negra?

TransactionDenyConfig es un archivo de configuración YAML/TOML que se carga localmente en cada validador. Cualquier persona que ejecute un nodo puede editar este archivo, recargarlo en caliente o reiniciar el nodo y actualizar la lista. A primera vista, cada validador parece estar expresando libremente sus propios valores.

En realidad, para la coherencia y efectividad de la política de seguridad, la actualización de esta configuración clave suele ser coordinada. Dado que se trata de una "actualización urgente impulsada por el equipo de SUI", es esencialmente la fundación SUI (o los desarrolladores autorizados por ella) quienes establecen y actualizan esta lista de rechazo.

SUI publica una lista negra, teóricamente los validadores pueden elegir si la adoptan o no------pero en la práctica la mayoría de las personas la adoptan automáticamente por defecto. Por lo tanto, aunque esta función protege los fondos de los usuarios, en esencia tiene un cierto grado de centralización.

3.2.3 La esencia de la función de lista negra

La función de lista negra en realidad no es una lógica de nivel de protocolo, sino que se asemeja más a una capa de seguridad adicional para hacer frente a situaciones inesperadas y garantizar la seguridad de los fondos del usuario.

Esencialmente es un mecanismo de garantía de seguridad. Similar a una "cadena antirrobo" atada a la puerta, que solo se activa para aquellos que desean invadir el hogar, es decir, para aquellos que actúan maliciosamente contra el protocolo. Para el usuario:

• Para los grandes inversores, que son los principales proveedores de liquidez, el protocolo es el que más desea garantizar la seguridad de los fondos, ya que en realidad los datos en cadena de tvl son todos contribuciones de los principales inversores. Para que el protocolo se desarrolle a largo plazo, definitivamente se priorizará la seguridad.

• Para los inversores minoristas, contribuyentes a la actividad del ecosistema, fuertes apoyos a la co-construcción técnica y comunitaria.