La ecología de SUI muestra resiliencia: análisis de la actualización de seguridad y el potencial de crecimiento a largo plazo después del ataque de Cetus
Fe de hierro después de la crisis de seguridad: ¿por qué SUI todavía 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 fue víctima de un ataque hacker. El atacante aprovechó una vulnerabilidad lógica relacionada con un "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 incidentes de seguridad en el ámbito DeFi hasta la fecha de este año, sino que también se ha convertido en el ataque hacker 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ó 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 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 de SUI y la estabilidad de su ecosistema.
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 provocó una fluctuación en la confianza a corto plazo, los fondos en cadena y la actividad de los usuarios no han sufrido una disminución sostenida, sino que han impulsado un aumento significativo en la atención hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos en todo el ecosistema.
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 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 trayectoria del ataque se puede dividir aproximadamente en las siguientes tres etapas:
①Iniciar un préstamo relámpago, manipular precios
Los hackers primero utilizaron un intercambio relámpago de 10 mil millones de haSUI con el mayor deslizamiento posible, prestando grandes cantidades de fondos 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 alto apalancamiento, bajo riesgo y bajo costo. Los hackers utilizaron este mecanismo para reducir el precio del mercado en poco 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 con precisión 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.
②Añadir liquidez
El atacante crea posiciones de liquidez estrechas, declara que añade liquidez, pero debido a una vulnerabilidad en la función checked_shlw, al final solo recibe 1 token.
Esencialmente se debe a dos razones:
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 meramente simbólica. Los hackers, al establecer parámetros anormales, construyen entradas que siempre son menores que este límite, eludiendo así la detección de desbordamiento.
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 datos uint256 (256 bits). La parte superior desbordada se descartó automáticamente, lo que llevó a que el resultado de la operación estuviera muy por debajo de lo esperado, lo que hizo que el sistema subestimara la cantidad de haSUI necesaria para el intercambio. El resultado final del cálculo 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 necesitaba agregar 1 token para obtener una gran liquidez.
③ retirar liquidez
Realizar el reembolso del préstamo instantáneo, 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 la vulnerabilidad
La vulnerabilidad de Cetus tiene tres características:
Costo de reparación extremadamente bajo: por un lado, la causa fundamental del incidente de 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 está limitada solo a Cetus y no tiene relación con el código de SUI. La raíz de la vulnerabilidad se encuentra en una verificación de condición de límite, y solo se necesitan modificar dos líneas de código para eliminar completamente el riesgo; una vez completada la reparación, se puede implementar de inmediato en la red principal, asegurando que la lógica de los contratos posteriores esté completa y eliminando esta vulnerabilidad.
Alta opacidad: El contrato ha estado funcionando sin fallos durante dos años, 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 aprovechan los valores extremos para construir con precisión intervalos de transacción, creando escenarios extremadamente raros de alta liquidez que activan lógicas anómalas, lo que indica que este tipo de problemas es difícil de detectar mediante pruebas normales. Este tipo de problemas a menudo se encuentra en áreas ciegas de la percepción, lo que permite que permanezcan ocultos durante mucho tiempo antes de ser descubiertos.
No es un problema exclusivo de Move:
Move es superior a varios lenguajes de contratos inteligentes en seguridad de recursos y verificación de tipos, y tiene detección nativa de problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al añadir liquidez se utilizó un valor erróneo para la verificación del límite superior al calcular la cantidad de tokens necesarios, y se usó una operación de desplazamiento en lugar de la operación de multiplicación convencional. Si se hubieran utilizado las operaciones convencionales de suma, resta, multiplicación o división, Move habría verificado 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 la falta de protección contra 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 siempre ha sido que el resultado de la operación excedió el rango. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity, lograron el ataque a través de la construcción cuidadosa de parámetros que eludieron las declaraciones de verificación en el contrato, permitiendo transferencias excesivas.
3. Mecanismo de consenso de SUI
3.1 Introducción al mecanismo de consenso SUI
Descripción:
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 nivel de descentralización tan alto como PoW (Prueba de Trabajo). Por lo tanto, el nivel 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
Promedio del ciclo de Epoch: 24 horas
Mecanismo de flujo:
Delegación de derechos: Los usuarios comunes no necesitan ejecutar nodos por sí mismos, 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 entrada 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 generación de bloques: un número reducido de validadores seleccionados generan bloques en un orden fijo o aleatorio, aumentando la velocidad de confirmación y mejorando el TPS.
Elecciones dinámicas: Al finalizar cada ciclo de conteo de votos, se realiza una rotación dinámica y se redefine el conjunto de Validadores según el peso del voto, 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 producción de bloques es controlable, 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 computacionales necesarios para la sincronización de información y la agregación de firmas. Esto reduce los costos de hardware y operación, disminuye los requisitos de potencia de cálculo y hace que los costos sean más bajos. Finalmente, se logra una tarifa de usuario más baja.
Alta seguridad: los mecanismos de staking y delegación amplifican los costos y riesgos de ataque de manera sincronizada; junto con el mecanismo de confiscación en la cadena, se inhiben eficazmente 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 acuerdo para confirmar las transacciones. Este mecanismo asegura que, incluso si unos pocos nodos actúan maliciosamente, la red puede mantener su seguridad y operar de manera eficiente. Para llevar a cabo cualquier actualización o decisión importante, también se necesita que más de dos tercios de los votos estén a favor.
En esencia, el DPoS es una solución de compromiso para el "triángulo imposible" que realmente no se puede alcanzar, realizando un compromiso entre la descentralización y la eficiencia. El DPoS elige reducir el número de nodos activos de producción de bloques a cambio de un rendimiento superior en el "triángulo imposible" de seguridad-descentralización-escalabilidad, renunciando a cierto grado de completa descentralización en comparación con el PoS puro o el PoW, 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 Operación del mecanismo de congelación
En este evento, SUI congeló rápidamente las direcciones relacionadas con el atacante.
Desde un punto de vista del código, esto 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 transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores están implementando 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 enumeradas. Dado que esta función ya está integrada en el cliente, cuando ocurre un ataque
SUI puede congelar inmediatamente las direcciones de los hackers. Sin esta función, incluso si SUI solo tiene 113 validadores, a Cetus le será 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 por 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 consistencia y efectividad de la política de seguridad, la actualización de esta configuración crítica suele ser coordinada. Dado que se trata de 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, teóricamente los validadores pueden elegir si adoptarla 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 capa de protocolo, sino que se parece más a una capa de seguridad adicional para hacer frente a situaciones imprevistas 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 intentan invadir el hogar, es decir, para las personas que buscan hacer daño al protocolo. Para los usuarios:
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 tvl son todos contribuciones de los principales inversores. Para que el protocolo se desarrolle a largo plazo, sin duda se priorizará la seguridad.
Para los minoristas, contribuyentes a la actividad del ecosistema, poderosos apoyos de la tecnología y la construcción comunitaria. El equipo del proyecto también espera atraer a los minoristas para que co-construyan, de este modo se podrá perfeccionar gradualmente el ecosistema y aumentar la tasa de retención. En el ámbito de defi, lo más importante sigue siendo la seguridad de los fondos.
El clave para juzgar "si es descentralizado" debería ser si los usuarios tienen el control de sus activos. En este sentido, SUI ha demostrado esto a través del lenguaje de programación Move.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
10 me gusta
Recompensa
10
6
Republicar
Compartir
Comentar
0/400
RektRecorder
· hace8h
Primera fila del lugar de pérdidas masivas
Ver originalesResponder0
LiquidityNinja
· hace8h
Viendo a la baja, ya se ha cerrado la posición.
Ver originalesResponder0
MevHunter
· hace8h
Esperando a hacer un dump, el futuro es largo.
Ver originalesResponder0
NeverVoteOnDAO
· hace8h
No es la primera vez que me hackean, así que me he acostumbrado.
Ver originalesResponder0
BtcDailyResearcher
· hace8h
Reducir pérdidas salió gg
Ver originalesResponder0
consensus_whisperer
· hace8h
¿Así de destruido y aún quieres engañar a la gente para que atrape un cuchillo que cae?
La ecología de SUI muestra resiliencia: análisis de la actualización de seguridad y el potencial de crecimiento a largo plazo después del ataque de Cetus
Fe de hierro después de la crisis de seguridad: ¿por qué SUI todavía 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 fue víctima de un ataque hacker. El atacante aprovechó una vulnerabilidad lógica relacionada con un "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 incidentes de seguridad en el ámbito DeFi hasta la fecha de este año, sino que también se ha convertido en el ataque hacker 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ó 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 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 de SUI y la estabilidad de su ecosistema.
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 provocó una fluctuación en la confianza a corto plazo, los fondos en cadena y la actividad de los usuarios no han sufrido una disminución sostenida, sino que han impulsado un aumento significativo en la atención hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos en todo el ecosistema.
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 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 trayectoria del ataque se puede dividir aproximadamente en las siguientes tres etapas:
①Iniciar un préstamo relámpago, manipular precios
Los hackers primero utilizaron un intercambio relámpago de 10 mil millones de haSUI con el mayor deslizamiento posible, prestando grandes cantidades de fondos 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 alto apalancamiento, bajo riesgo y bajo costo. Los hackers utilizaron este mecanismo para reducir el precio del mercado en poco 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 con precisión 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.
②Añadir liquidez
El atacante crea posiciones de liquidez estrechas, declara que añade liquidez, pero debido a una vulnerabilidad en la función checked_shlw, al final solo recibe 1 token.
Esencialmente se debe a dos razones:
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 meramente simbólica. Los hackers, al establecer parámetros anormales, construyen entradas que siempre son menores que este límite, eludiendo así la detección de desbordamiento.
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 datos uint256 (256 bits). La parte superior desbordada se descartó automáticamente, lo que llevó a que el resultado de la operación estuviera muy por debajo de lo esperado, lo que hizo que el sistema subestimara la cantidad de haSUI necesaria para el intercambio. El resultado final del cálculo 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 necesitaba agregar 1 token para obtener una gran liquidez.
③ retirar liquidez
Realizar el reembolso del préstamo instantáneo, 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 la vulnerabilidad
La vulnerabilidad de Cetus tiene tres características:
Costo de reparación extremadamente bajo: por un lado, la causa fundamental del incidente de 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 está limitada solo a Cetus y no tiene relación con el código de SUI. La raíz de la vulnerabilidad se encuentra en una verificación de condición de límite, y solo se necesitan modificar dos líneas de código para eliminar completamente el riesgo; una vez completada la reparación, se puede implementar de inmediato en la red principal, asegurando que la lógica de los contratos posteriores esté completa y eliminando esta vulnerabilidad.
Alta opacidad: El contrato ha estado funcionando sin fallos durante dos años, 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 aprovechan los valores extremos para construir con precisión intervalos de transacción, creando escenarios extremadamente raros de alta liquidez que activan lógicas anómalas, lo que indica que este tipo de problemas es difícil de detectar mediante pruebas normales. Este tipo de problemas a menudo se encuentra en áreas ciegas de la percepción, lo que permite que permanezcan ocultos durante mucho tiempo antes de ser descubiertos.
Move es superior a varios lenguajes de contratos inteligentes en seguridad de recursos y verificación de tipos, y tiene detección nativa de problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al añadir liquidez se utilizó un valor erróneo para la verificación del límite superior al calcular la cantidad de tokens necesarios, y se usó una operación de desplazamiento en lugar de la operación de multiplicación convencional. Si se hubieran utilizado las operaciones convencionales de suma, resta, multiplicación o división, Move habría verificado 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 la falta de protección contra 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 siempre ha sido que el resultado de la operación excedió el rango. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity, lograron el ataque a través de la construcción cuidadosa de parámetros que eludieron las declaraciones de verificación en el contrato, permitiendo transferencias excesivas.
3. Mecanismo de consenso de SUI
3.1 Introducción al mecanismo de consenso SUI
Descripción:
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 nivel de descentralización tan alto como PoW (Prueba de Trabajo). Por lo tanto, el nivel 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
Promedio del ciclo de Epoch: 24 horas
Mecanismo de flujo:
Delegación de derechos: Los usuarios comunes no necesitan ejecutar nodos por sí mismos, 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 entrada 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 generación de bloques: un número reducido de validadores seleccionados generan bloques en un orden fijo o aleatorio, aumentando la velocidad de confirmación y mejorando el TPS.
Elecciones dinámicas: Al finalizar cada ciclo de conteo de votos, se realiza una rotación dinámica y se redefine el conjunto de Validadores según el peso del voto, 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 producción de bloques es controlable, 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 computacionales necesarios para la sincronización de información y la agregación de firmas. Esto reduce los costos de hardware y operación, disminuye los requisitos de potencia de cálculo y hace que los costos sean más bajos. Finalmente, se logra una tarifa de usuario más baja.
Alta seguridad: los mecanismos de staking y delegación amplifican los costos y riesgos de ataque de manera sincronizada; junto con el mecanismo de confiscación en la cadena, se inhiben eficazmente 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 acuerdo para confirmar las transacciones. Este mecanismo asegura que, incluso si unos pocos nodos actúan maliciosamente, la red puede mantener su seguridad y operar de manera eficiente. Para llevar a cabo cualquier actualización o decisión importante, también se necesita que más de dos tercios de los votos estén a favor.
En esencia, el DPoS es una solución de compromiso para el "triángulo imposible" que realmente no se puede alcanzar, realizando un compromiso entre la descentralización y la eficiencia. El DPoS elige reducir el número de nodos activos de producción de bloques a cambio de un rendimiento superior en el "triángulo imposible" de seguridad-descentralización-escalabilidad, renunciando a cierto grado de completa descentralización en comparación con el PoS puro o el PoW, 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 Operación del mecanismo de congelación
En este evento, SUI congeló rápidamente las direcciones relacionadas con el atacante.
Desde un punto de vista del código, esto 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 transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores están implementando 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 enumeradas. Dado que esta función ya está integrada en el cliente, cuando ocurre un ataque
SUI puede congelar inmediatamente las direcciones de los hackers. Sin esta función, incluso si SUI solo tiene 113 validadores, a Cetus le será 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 por 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 consistencia y efectividad de la política de seguridad, la actualización de esta configuración crítica suele ser coordinada. Dado que se trata de 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, teóricamente los validadores pueden elegir si adoptarla 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 capa de protocolo, sino que se parece más a una capa de seguridad adicional para hacer frente a situaciones imprevistas 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 intentan invadir el hogar, es decir, para las personas que buscan hacer daño al protocolo. Para los usuarios:
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 tvl son todos contribuciones de los principales inversores. Para que el protocolo se desarrolle a largo plazo, sin duda se priorizará la seguridad.
Para los minoristas, contribuyentes a la actividad del ecosistema, poderosos apoyos de la tecnología y la construcción comunitaria. El equipo del proyecto también espera atraer a los minoristas para que co-construyan, de este modo se podrá perfeccionar gradualmente el ecosistema y aumentar la tasa de retención. En el ámbito de defi, lo más importante sigue siendo la seguridad de los fondos.
El clave para juzgar "si es descentralizado" debería ser si los usuarios tienen el control de sus activos. En este sentido, SUI ha demostrado esto a través del lenguaje de programación Move.