Versión popular: Una simple "traducción" para interpretar el análisis del hacker @CetusProtocol por parte del jefe tecnológico: Este ataque expone un problema clásico de desbordamiento de enteros, que se manifiesta en el truncamiento de datos durante la conversión de tipos. Detalles técnicos desmontado: 1) Ubicación de la vulnerabilidad: El problema se produce en el mecanismo de conversión de tipos de la función get_amount_by_liquidity, y la conversión de conversión de U256 a U64 provoca una pérdida de datos de alto nivel. 2) Proceso de ataque: 1. El atacante pasa una gran cantidad de parámetros de liquidez a través de la función add_liquidity; 2. El número de tokens B necesarios para el cálculo de la llamada get_delta_b función del sistema; 3. En el proceso de cálculo, los dos datos de tipo U128 se multiplican y el resultado teórico debe ser de tipo U256; Defecto clave: El resultado de u256 se convierte en u64 cuando la función devuelve, lo que resulta en el truncamiento de los datos de alto nivel de 128 bits. 3) Efecto de utilización: La cuota de liquidez que originalmente requería una gran cantidad de tokens para acuñar ahora se puede completar con solo una cantidad muy pequeña de tokens. El atacante obtiene una gran parte de la liquidez a un costo muy bajo, y luego realiza el arbitraje del grupo destruyendo parte de la liquidez. Analogía simple: al igual que usar una calculadora que solo puede mostrar 8 dígitos para calcular 1 mil millones × 1 mil millones, el resultado de un cálculo de 20 dígitos solo puede mostrar los últimos 8 dígitos y los primeros 12 dígitos desaparecen directamente. El atacante explota esta vulnerabilidad. Para ser claros: esta vulnerabilidad no tiene nada que ver con la arquitectura de seguridad subyacente de @SuiNetwork, y la "gloria" de seguridad del lenguaje Move sigue siendo creíble por el momento. ¿Por qué? El lenguaje Move tiene ventajas significativas en términos de administración de recursos y seguridad de tipos, y puede prevenir eficazmente problemas de seguridad de bajo nivel, como el doble gasto y la fuga de recursos. Sin embargo, esta vez el protocolo Cetus es un error matemático a nivel de lógica de aplicación, no un fallo de diseño en el propio lenguaje Move. Específicamente, el sistema de tipos de Move, aunque riguroso, aún depende del juicio correcto del desarrollador para el casting explícito. Cuando un programa realiza activamente una conversión de tipos de U256 a U64, el compilador no puede determinar si se trata de un error intencionado o lógico. Además, este incidente de seguridad no tiene nada que ver con las funciones subyacentes principales de Sui, como el mecanismo de consenso, el procesamiento de transacciones y la gestión de estados. Sui Network solo ejecuta fielmente las instrucciones de transacción enviadas por el protocolo Cetus, y la vulnerabilidad se deriva de los fallos lógicos del propio protocolo de la capa de aplicación. Para decirlo sin rodeos, ninguna cantidad de lenguajes de programación avanzados puede eliminar por completo los errores lógicos en la capa de la aplicación. Move puede evitar la mayoría de los riesgos de seguridad subyacentes, pero no puede reemplazar a los desarrolladores con la comprobación de límites de la lógica de negocios y la protección contra el desbordamiento de las operaciones matemáticas.