Creencia firme 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 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 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 DeFi hasta la fecha 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 el monto bloqueado 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 apenas una hora, lo que provocó 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 mostrado una gran resiliencia y capacidad de recuperación. A pesar de que el evento Cetus provocó una fluctuación de confianza a corto plazo, los fondos en cadena y la actividad de los usuarios no han sufrido una caída sostenida, sino que han impulsado un aumento significativo en la atención del ecosistema hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos.
Klein Labs se centrará en las causas de este incidente de ataque, el mecanismo de consenso de nodos de SUI, la seguridad del lenguaje MOVE y el desarrollo del ecosistema de SUI, organizando el actual paisaje ecológico 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 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 intercambiar 10 mil millones de haSUI a través de un préstamo relámpago, prestando una gran cantidad de fondos para manipular el precio.
El préstamo relámpago permite a los usuarios pedir prestado y devolver fondos en una misma transacción, pagando solo una tarifa, con características de alta apalancamiento, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para reducir el precio del mercado en un corto período de tiempo y mantenerlo controlado con precisión 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 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
El 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:
Configuración de la máscara demasiado amplia: equivale a un límite de adición de liquidez extremadamente grande, lo que provoca que la verificación de la entrada del usuario en el contrato sea prácticamente nula. Los hackers evitan la detección de desbordamiento al establecer parámetros anómalos, construyendo entradas que siempre son menores que ese límite.
Desbordamiento de datos truncado: Al realizar la operación de desplazamiento n << 64 en el valor numérico n, debido a que el desplazamiento excede el ancho de bits efectivo del tipo de datos uint256 (256 bits), se produjo un truncamiento de datos. La parte de desbordamiento superior se descartó automáticamente, lo que llevó a 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 fue aproximadamente menor que 1, pero debido a que se redondea hacia arriba, al final resultó ser igual a 1, es decir, el hacker solo necesita agregar 1 token para poder intercambiar por una gran liquidez.
③Retirar liquidez
Realizar el reembolso de un préstamo relámpago y conservar enormes ganancias. Finalmente, retirar activos de tokens por un valor total de cientos de millones de dólares de múltiples grupos de liquidez.
La situación de pérdida de fondos es grave, el ataque ha causado el robo de los siguientes activos:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000万美元USDC
4900000 dólares Haedal Staked SUI
1950万美元TOILET
Otros tokens como HIPPO y LOFI han caído entre un 75 y un 80%, la liquidez se ha agotado.
2.2 La causa y características de esta vulnerabilidad
La vulnerabilidad de Cetus tiene tres características:
El costo de la reparación es 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 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 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 del contrato posterior sea completa y eliminando esta vulnerabilidad.
Alta ocultación: El contrato ha estado funcionando de manera estable sin fallos durante dos años, el Cetus Protocol ha sido auditado múltiples veces, pero no se han encontrado vulnerabilidades, la razón principal 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 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. Estos problemas suelen estar en áreas ciegas de la visión de las personas, por lo que han permanecido 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 términos de seguridad de recursos y verificación de tipos, e incluye 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 comprobación del límite superior al calcular la cantidad de tokens necesarios, y se reemplazó la multiplicación convencional con operaciones de desplazamiento. Sin embargo, si se utilizan operaciones convencionales de suma, resta, multiplicación y división, Move verificará automáticamente la situación de desbordamiento y no habrá problemas de truncamiento de bits altos.
Vulnerabilidades similares también han aparecido en otros lenguajes (como Solidity y 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, han ocurrido desbordamientos en suma, resta y multiplicación, siendo la causa directa el hecho de que el resultado de la operación excedió el rango. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity, fueron atacadas mediante parámetros cuidadosamente construidos que eludieron las declaraciones de verificación en el contrato, logrando 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 el 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
Proceso del mecanismo:
Delegación de derechos: los usuarios comunes no necesitan ejecutar un nodo por su cuenta, solo necesitan apostar 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 es también una gran ventaja de DPoS en comparación con el PoS tradicional.
Rondas de representación de bloques: un número limitado 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 período de conteo de votos, se realiza una rotación dinámica y se vuelve a elegir el 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 bloque 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. Por lo tanto, los costos de hardware y operación disminuyen, se reducen los requisitos de potencia de cálculo y los costos son más bajos. Finalmente, se logra una tarifa de usuario más baja.
Alta seguridad: el mecanismo de staking y delegación amplifica de manera sinérgica el costo y el riesgo de los ataques; junto con el mecanismo de confiscación en la cadena, se suprimen 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 una transacción. Este mecanismo asegura que, incluso si unos pocos nodos actúan mal, la red pueda mantener una operación segura y eficiente. Para cualquier actualización o decisión importante, también se necesita que más de dos tercios de los votos estén a favor para llevarla a cabo.
En esencia, DPoS es una solución de compromiso para el triángulo imposible, que realiza un compromiso entre la descentralización y la eficiencia. DPoS elige reducir la cantidad de nodos activos para obtener un mayor rendimiento en el "triángulo imposible" de seguridad-descentralización-escalabilidad, renunciando a un cierto grado de descentralización completa en comparación con PoS puro o 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 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 blockchain SUI, responsables de validar transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores equivalen a implementar un mecanismo similar al 'congelamiento de cuentas' en las finanzas tradicionales a nivel de consenso.
SUI incorpora un mecanismo de lista de rechazos (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 solo tiene 113 validadores, a Cetus le resultarí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, parece que cada validador expresa 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 de emergencia impulsada por el equipo de SUI", básicamente es la fundación SUI (o sus desarrolladores autorizados) quienes establecen y actualizan esta lista de rechazo.
SUI publica una lista negra, teóricamente los validadores pueden elegir si adoptarla ------ 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 asemeja más a una capa adicional de seguridad destinada a 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 desean invadir el hogar, es decir, para las personas que actúan maliciosamente contra el protocolo. Para los usuarios, esto:
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 contribuidos principalmente por grandes inversores. Para que el protocolo se desarrolle a largo plazo, definitivamente se priorizará la seguridad.
Para los inversionistas minoristas, contribuyentes de la actividad ecológica, y fuertes apoyadores de la construcción conjunta de tecnología y comunidad. El equipo del proyecto también espera atraer a los inversionistas minoristas para que colaboren en la construcción, de esta manera.
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.
13 me gusta
Recompensa
13
4
Compartir
Comentar
0/400
GweiWatcher
· 08-01 19:47
¿Así que hay que comprar en el punto más bajo? Terrible.
Ver originalesResponder0
DefiPlaybook
· 08-01 19:44
Según el análisis de datos on-chain, la vulnerabilidad de Cetus expone los riesgos inherentes de los contratos inteligentes, y la caída del TVL del 83.7% resalta la fragilidad de la liquidez.
Ver originalesResponder0
GigaBrainAnon
· 08-01 19:37
No hay manera de reparar el cielo.
Ver originalesResponder0
0xSherlock
· 08-01 19:30
Realmente solo saben especular y Gran aumento Gran caída.
La resiliencia del ecosistema SUI se destaca, con un potencial de crecimiento a largo plazo incluso después de incidentes de seguridad.
Creencia firme 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 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 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 DeFi hasta la fecha 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 el monto bloqueado 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 apenas una hora, lo que provocó 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 mostrado una gran resiliencia y capacidad de recuperación. A pesar de que el evento Cetus provocó una fluctuación de confianza a corto plazo, los fondos en cadena y la actividad de los usuarios no han sufrido una caída sostenida, sino que han impulsado un aumento significativo en la atención del ecosistema hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos.
Klein Labs se centrará en las causas de este incidente de ataque, el mecanismo de consenso de nodos de SUI, la seguridad del lenguaje MOVE y el desarrollo del ecosistema de SUI, organizando el actual paisaje ecológico 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 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 intercambiar 10 mil millones de haSUI a través de un préstamo relámpago, prestando una gran cantidad de fondos para manipular el precio.
El préstamo relámpago permite a los usuarios pedir prestado y devolver fondos en una misma transacción, pagando solo una tarifa, con características de alta apalancamiento, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para reducir el precio del mercado en un corto período de tiempo y mantenerlo controlado con precisión 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 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
El 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:
Configuración de la máscara demasiado amplia: equivale a un límite de adición de liquidez extremadamente grande, lo que provoca que la verificación de la entrada del usuario en el contrato sea prácticamente nula. Los hackers evitan la detección de desbordamiento al establecer parámetros anómalos, construyendo entradas que siempre son menores que ese límite.
Desbordamiento de datos truncado: Al realizar la operación de desplazamiento n << 64 en el valor numérico n, debido a que el desplazamiento excede el ancho de bits efectivo del tipo de datos uint256 (256 bits), se produjo un truncamiento de datos. La parte de desbordamiento superior se descartó automáticamente, lo que llevó a 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 fue aproximadamente menor que 1, pero debido a que se redondea hacia arriba, al final resultó ser igual a 1, es decir, el hacker solo necesita agregar 1 token para poder intercambiar por una gran liquidez.
③Retirar liquidez
Realizar el reembolso de un préstamo relámpago y conservar enormes ganancias. Finalmente, retirar activos de tokens por un valor total de cientos de millones de dólares de múltiples grupos de liquidez.
La situación de pérdida de fondos es grave, el ataque ha causado el robo de los siguientes activos:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000万美元USDC
4900000 dólares Haedal Staked SUI
1950万美元TOILET
Otros tokens como HIPPO y LOFI han caído entre un 75 y un 80%, la liquidez se ha agotado.
2.2 La causa y características de esta vulnerabilidad
La vulnerabilidad de Cetus tiene tres características:
El costo de la reparación es 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 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 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 del contrato posterior sea completa y eliminando esta vulnerabilidad.
Alta ocultación: El contrato ha estado funcionando de manera estable sin fallos durante dos años, el Cetus Protocol ha sido auditado múltiples veces, pero no se han encontrado vulnerabilidades, la razón principal 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 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. Estos problemas suelen estar en áreas ciegas de la visión de las personas, por lo que han permanecido ocultos durante mucho tiempo antes de ser descubiertos.
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 de problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al agregar liquidez, se utilizó un valor incorrecto para la comprobación del límite superior al calcular la cantidad de tokens necesarios, y se reemplazó la multiplicación convencional con operaciones de desplazamiento. Sin embargo, si se utilizan operaciones convencionales de suma, resta, multiplicación y división, Move verificará automáticamente la situación de desbordamiento y no habrá problemas de truncamiento de bits altos.
Vulnerabilidades similares también han aparecido en otros lenguajes (como Solidity y 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, han ocurrido desbordamientos en suma, resta y multiplicación, siendo la causa directa el hecho de que el resultado de la operación excedió el rango. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity, fueron atacadas mediante parámetros cuidadosamente construidos que eludieron las declaraciones de verificación en el contrato, logrando 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 el 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
Proceso del mecanismo:
Delegación de derechos: los usuarios comunes no necesitan ejecutar un nodo por su cuenta, solo necesitan apostar 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 es también una gran ventaja de DPoS en comparación con el PoS tradicional.
Rondas de representación de bloques: un número limitado 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 período de conteo de votos, se realiza una rotación dinámica y se vuelve a elegir el 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 bloque 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. Por lo tanto, los costos de hardware y operación disminuyen, se reducen los requisitos de potencia de cálculo y los costos son más bajos. Finalmente, se logra una tarifa de usuario más baja.
Alta seguridad: el mecanismo de staking y delegación amplifica de manera sinérgica el costo y el riesgo de los ataques; junto con el mecanismo de confiscación en la cadena, se suprimen 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 una transacción. Este mecanismo asegura que, incluso si unos pocos nodos actúan mal, la red pueda mantener una operación segura y eficiente. Para cualquier actualización o decisión importante, también se necesita que más de dos tercios de los votos estén a favor para llevarla a cabo.
En esencia, DPoS es una solución de compromiso para el triángulo imposible, que realiza un compromiso entre la descentralización y la eficiencia. DPoS elige reducir la cantidad de nodos activos para obtener un mayor rendimiento en el "triángulo imposible" de seguridad-descentralización-escalabilidad, renunciando a un cierto grado de descentralización completa en comparación con PoS puro o 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 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 blockchain SUI, responsables de validar transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores equivalen a implementar un mecanismo similar al 'congelamiento de cuentas' en las finanzas tradicionales a nivel de consenso.
SUI incorpora un mecanismo de lista de rechazos (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 solo tiene 113 validadores, a Cetus le resultarí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, parece que cada validador expresa 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 de emergencia impulsada por el equipo de SUI", básicamente es la fundación SUI (o sus desarrolladores autorizados) quienes establecen y actualizan esta lista de rechazo.
SUI publica una lista negra, teóricamente los validadores pueden elegir si adoptarla ------ 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 asemeja más a una capa adicional de seguridad destinada a 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 desean invadir el hogar, es decir, para las personas que actúan maliciosamente contra el protocolo. Para los usuarios, esto:
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 contribuidos principalmente por grandes inversores. Para que el protocolo se desarrolle a largo plazo, definitivamente se priorizará la seguridad.
Para los inversionistas minoristas, contribuyentes de la actividad ecológica, y fuertes apoyadores de la construcción conjunta de tecnología y comunidad. El equipo del proyecto también espera atraer a los inversionistas minoristas para que colaboren en la construcción, de esta manera.