Creencias firmes tras 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 protocolo AMM líder 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 resultó en una 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 de DeFi hasta la fecha de 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 de toda la cadena SUI cayó en más de 330 millones de dólares en el día del ataque, y la cantidad bloqueada del protocolo Cetus se evaporó instantáneamente en un 84%, cayendo a 38 millones de dólares. Como resultado, varios tokens populares en SUI 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 la estabilidad del ecosistema de SUI.

Pero después de esta ola de impacto, el ecosistema SUI ha demostrado una gran resiliencia y capacidad de recuperación. A pesar de que el evento Cetus trajo fluctuaciones de confianza a corto plazo, los fondos en la cadena y la actividad de los usuarios no han sufrido un deterioro sostenido, 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 se centrará en las causas de este ataque, el mecanismo de consenso de nodos de SUI, la seguridad del lenguaje MOVE y el desarrollo del ecosistema de SUI, organizando la actual estructura ecosistémica 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 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 precisa de precios 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 aprovecharon el deslizamiento máximo para hacer un intercambio relámpago de 100 mil millones de haSUI mediante un préstamo relámpago, prestando grandes cantidades de dinero para manipular el precio.

El préstamo relámpago permite a los usuarios pedir prestado y devolver fondos en una sola transacción, pagando solo una tarifa, con características de alta apalancamiento, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para reducir drásticamente el precio del mercado en un corto período de tiempo y controlarlo de manera precisa dentro de un rango muy estrecho.

Luego, el atacante se prepara 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 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, declarando 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 lleva a que la verificación de la entrada del usuario en el contrato sea prácticamente nula. Un hacker, al establecer parámetros anómalos, construyó una entrada que siempre es menor que este 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, ocurrió un truncamiento de datos debido a que el desplazamiento excedió el ancho de bits efectivo del tipo de dato uint256 (256 bits). La parte de desbordamiento de bits altos se descartó automáticamente, lo que llevó a que el resultado de la operación fuera mucho menor de lo esperado, lo que hizo que el sistema subestimara la cantidad de haSUI necesaria para el intercambio. El resultado final del cálculo es aproximadamente menor que 1, pero como se redondea hacia arriba, al final se obtiene igual a 1, es decir, el hacker solo necesita agregar 1 token para poder intercambiar una gran liquidez.

③Retirar liquidez

Realizar el reembolso de un préstamo relámpago y conservar grandes ganancias. Finalmente, retirar activos en 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 llevado al robo de los siguientes activos:

• 1290 millones de SUI (aproximadamente 5400 millones de dólares)

• 6000 millones de dólares USDC

• 490 millones de dólares Haedal Staked SUI

• 1950 millones de dólares TOILET

• Otros tokens como HIPPO y LOFI han bajado un 75--80%, la liquidez se ha agotado.

2.2 La causa 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 o en la arquitectura subyacente. Por otro lado, la vulnerabilidad está limitada únicamente a Cetus y no tiene relación con el código de SUI. La raíz de la vulnerabilidad radica en una condición de borde, y solo se necesita modificar dos líneas de código para eliminar completamente el riesgo; una vez completada la reparación, puede ser desplegada inmediatamente en la red principal, asegurando que la lógica del contrato posterior esté completa y eliminando esta vulnerabilidad.

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

Los hackers utilizan valores extremos para construir con precisión intervalos de negociación, creando escenarios extremadamente raros con una liquidez muy alta, lo que desencadena una lógica anómala, lo que indica que este tipo de problemas son difíciles de detectar mediante pruebas ordinarias. Este tipo de 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 cuenta con una detección nativa de 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 reemplazó la operación de multiplicación convencional por un desplazamiento de bits. En cambio, si se utilizan operaciones de suma, resta, multiplicación y división convencionales en Move, se verificará automáticamente el desbordamiento, evitando así problemas 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 su falta de protección contra desbordamientos de enteros; antes de la actualización de versiones de Solidity, la verificación de desbordamientos era muy débil. Históricamente, ha habido desbordamientos de suma, desbordamientos de resta, desbordamientos de multiplicación, etc., y la causa directa ha sido que el resultado de la operación superó el rango. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity han sido explotadas mediante parámetros cuidadosamente construidos, eludiendo las declaraciones de verificación en el contrato, logrando transferencias excesivas para llevar a cabo ataques.

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, y el umbral de gobernanza es relativamente alto, lo que dificulta que los usuarios comunes puedan influir directamente en la gobernanza de la red.

• Número promedio de validadores: 106

• Promedio de ciclo de Epoch: 24 horas

Mecanismo de flujo:

• Delegación de derechos: los usuarios normales no necesitan ejecutar nodos por su cuenta, solo necesitan 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 entrada para los usuarios comunes, permitiéndoles participar en el consenso de la red mediante la "contratación" de validadores de confianza. Esta es también una gran ventaja del DPoS en comparación con el PoS tradicional.

• Representar rondas de bloque: 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 lleva a cabo una rotación dinámica y se reelige 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 el número de nodos de bloque puede controlarse, la red puede completar la confirmación en milisegundos, satisfaciendo la demanda de alto TPS.

• Bajo costo: Menos nodos participan en el consenso, lo que reduce significativamente el ancho de banda de red y los recursos de cálculo necesarios para la sincronización de información y la agregación de firmas. Como resultado, los costos de hardware y mantenimiento disminuyen, y los requisitos de potencia de cálculo son menores, lo que reduce los costos. En última instancia, se logra una tarifa de usuario más baja.

• Alta seguridad: los mecanismos de staking y delegación amplifican simultáneamente los costos y riesgos de ataque; junto con el mecanismo de confiscación en la cadena, se inhiben 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 coincidan para confirmar una transacción. Este mecanismo asegura que, incluso si algunos nodos actúan mal, la red puede seguir funcionando de manera segura y eficiente. Cualquier actualización o decisión importante también requiere más de dos tercios de los votos para ser implementada.

En esencia, DPoS es una solución de compromiso del triángulo imposible, que realiza un equilibrio entre la descentralización y la eficiencia. DPoS, en el "triángulo imposible" de seguridad-descentralización-escalabilidad, opta por reducir el número de nodos de bloques activos a cambio de un mayor rendimiento, sacrificando un cierto grado de completa descentralización en comparación con el puro PoS o PoW, pero mejorando significativamente el rendimiento de la red y la velocidad de las transacciones.

3.2 En este ataque, el rendimiento de SUI

Operación del mecanismo de congelación 3.2.1

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

Desde el punto de vista del código, impide que las transacciones de transferencia se empaqueten en la cadena. Los nodos de validación son componentes centrales de la cadena de bloques SUI, responsables de validar las transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores implementan, en el nivel de consenso, un mecanismo similar al de 'congelación de cuentas' en las finanzas tradicionales.

SUI incorpora 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. Dado que esta función ya existe en el cliente, cuando ocurre un ataque

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

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

TransactionDenyConfig es el archivo de configuración YAML/TOML que se carga localmente en cada validador. Cualquiera que ejecute un nodo puede editar este archivo, recargarlo en caliente o reiniciar el nodo y actualizar la lista. A primera vista, parece que cada validador está 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 crítica suele ser coordinada. Dado que esto es una "actualización urgente impulsada por el equipo de SUI", básicamente es la Fundación SUI (o los desarrolladores autorizados por ella) quienes establecen y actualizan esta lista de rechazo.

SUI publica una lista negra, en teoría los validadores pueden elegir si adoptarla------pero en la práctica la mayoría de las personas la adoptarán 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 subyacente del protocolo, sino que es más bien una capa de seguridad adicional para hacer frente a situaciones inesperadas y garantizar la seguridad de los fondos de los usuarios.

Esencialmente es un mecanismo de garantía de seguridad. Similar a una "cadena de seguridad" 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 los usuarios:

• Para los grandes inversores, 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 tvl son todos contribuciones de grandes inversores. Para que el protocolo se desarrolle a largo plazo, necesariamente se priorizará la seguridad.

• Para los minoristas, contribuyentes a la actividad ecológica, y fuertes apoyadores de la co-construcción técnica y comunitaria. El equipo del proyecto también espera poder atraer a los minoristas para co-construir.