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, 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 pérdidas de más de 200 millones de dólares en activos. Este incidente no solo es uno de los accidentes de seguridad más grandes 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 red principal de SUI.
Según los datos, el TVL total de SUI en la cadena cayó drásticamente más de 330 millones de dólares en el día del ataque, y el monto bloqueado del protocolo Cetus se evaporó instantáneamente en un 84%, cayendo a 38 millones de dólares. Como resultado, varios tokens populares en SUI (incluidos Lofi, Sudeng, Squirtle, etc.) cayeron entre un 76% y un 97% en solo 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 mostró 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 la cadena y la actividad de los usuarios no sufrieron un deterioro sostenido, sino que, por el contrario, impulsaron un aumento significativo en la atención del ecosistema hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos.
Vamos a analizar 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 el actual patrón ecológico de esta cadena pública que aún se encuentra en una etapa temprana de desarrollo, y exploraremos su potencial de desarrollo futuro.
2. Análisis de las causas del ataque al evento Cetus
2.1 Proceso de implementación del ataque
Según el análisis técnico del incidente de ataque a Cetus, los hackers aprovecharon con éxito una vulnerabilidad clave 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 grandes cantidades de dinero 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. Tiene 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 lo controlaron con precisión en 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 la anterior manera, los hackers utilizaron una cantidad suficiente de tokens y una gran liquidez para manipular con éxito el precio de haSUI. Posteriormente, también manipularon varios tokens que no tenían valor real.
②Agregar liquidez
El atacante crea posiciones de liquidez estrechas, declara que añade liquidez, pero debido a la vulnerabilidad de la función checked_shlw, finalmente solo recibe 1 token.
Esencialmente se debe a dos razones:
Configuración de la máscara demasiado ancha: equivale a un límite de adición de liquidez extremadamente grande, lo que hace que la verificación de las entradas del usuario en el contrato sea ineficaz. Los hackers establecen parámetros anormales, construyendo entradas que siempre son menores que ese 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, se produjo un truncamiento de datos debido a que el desplazamiento excedió el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte de desbordamiento de alta posición fue automáticamente descartada, 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 inferior a 1, pero debido a que se redondea hacia arriba, al final se calculó como 1, lo que significa que el hacker solo necesita agregar 1 token para poder obtener una gran liquidez.
③Retirar liquidez
Realizar el reembolso del préstamo relámpago, manteniendo grandes ganancias. Finalmente, retirando activos de token 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:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000万美元USDC
490万美元Haedal Staked SUI
1950 millones de dólares TOILET
Otros tokens como HIPPO y LOFI cayeron un 75-80%, la liquidez se ha agotado
2.2 Causas y características de esta vulnerabilidad
La vulnerabilidad de Cetus tiene tres características:
Costo de reparación extremadamente bajo: por un lado, la causa fundamental del evento Cetus es un descuido 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 está limitada únicamente a Cetus y no está relacionada con el código de SUI. La raíz de la vulnerabilidad se encuentra en una verificación de condición de frontera, 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 esté completa y eliminando esta vulnerabilidad.
Alta ocultación: El contrato ha estado funcionando de manera estable sin fallos durante dos años, se han 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 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 anormales, lo que indica que este tipo de problemas es difícil de detectar mediante pruebas ordinarias. Estos problemas a menudo se encuentran en áreas ciegas de la percepción humana, por lo que permanecen latentes 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 verificación del límite superior al calcular la cantidad de tokens necesarios, y se sustituyó la operación de multiplicación convencional por un desplazamiento, mientras que si se utilizan las operaciones aritméticas convencionales en Move, se comprobará automáticamente la situación de 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 la versión de Solidity, la verificación de desbordamientos era muy débil. Históricamente, han ocurrido desbordamientos en sumas, restas y multiplicaciones, 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 eludir las declaraciones de verificación en el contrato mediante parámetros cuidadosamente estructurados, lo que permitió ataques de 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 la capacidad de 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 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 nodos por sí mismos, solo deben 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 "contratando" validadores de confianza. Esta es también una gran ventaja del DPoS en comparación con el PoS tradicional.
Representa la ronda de producción de bloques: un pequeño grupo de validadores seleccionados produce 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 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. Esto reduce los costos de hardware y operación, disminuye los requisitos de potencia de cálculo y reduce los costos. Finalmente, se logra una tarifa de usuario más baja.
Alta seguridad: los mecanismos de staking y delegación amplifican conjuntamente el costo y el riesgo de los ataques; junto con el mecanismo de confiscación en la cadena, se inhiben de manera efectiva 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 consenso para poder confirmar la transacción. Este mecanismo asegura que, incluso si unos pocos nodos actúan maliciosamente, la red puede mantener un funcionamiento seguro y eficiente. Para realizar cualquier actualización o decisión importante, también se requiere que más de dos tercios de los votos estén a favor para que se implemente.
En esencia, DPoS es un compromiso dentro del triángulo imposible, que busca un equilibrio entre descentralización y eficiencia. DPoS elige reducir el número de nodos de bloque activos a cambio de un rendimiento superior en el "triángulo imposible" de seguridad-descentralización-escalabilidad, lo que implica una pérdida de un grado de completa descentralización en comparación con PoS puro o PoW, pero mejora significativamente la capacidad de procesamiento de la red y la velocidad de las transacciones.
3.2 El rendimiento de SUI en este ataque
3.2.1 mecanismo de congelación en funcionamiento
En este incidente, SUI congeló rápidamente las direcciones relacionadas con el atacante.
Desde el 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 clave de la blockchain SUI, responsables de validar las transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores han implementado, en un nivel de consenso, un mecanismo similar al de 'congelación de cuentas' en las finanzas tradicionales.
SUI tiene incorporado 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 las direcciones de los hackers. Sin esta función, incluso si SUI solo tiene 113 validadores, 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 para cambiar la lista negra?
TransactionDenyConfig es un 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, cada validador parece estar 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", básicamente es la fundación (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 ------ 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 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 es más bien una capa adicional de seguridad para hacer frente a situaciones imprevistas y garantizar la seguridad de los fondos de los usuarios.
Es esencialmente un mecanismo de garantía de seguridad. Similar a una "cadena de seguridad" atada a la puerta, que solo se activa para aquellos que quieren invadir el hogar, es decir, para aquellos que actúan maliciosamente contra el protocolo. Para el usuario:
Para los grandes inversores, los principales proveedores de liquidez, el protocolo es el que más quiere garantizar la seguridad de los fondos, ya que en realidad los datos en cadena (tvl) son contribuidos por los principales grandes inversores. Para que el protocolo se desarrolle a largo plazo, definitivamente se priorizará la seguridad.
Para los minoristas, contribuyentes a la actividad del ecosistema, fuertes apoyadores de la construcción conjunta de tecnología y comunidad. El equipo del proyecto también espera poder atraer a los minoristas para co-construir, de esta manera se podrá perfeccionar gradualmente el ecosistema y aumentar la retención.
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.
14 me gusta
Recompensa
14
7
Compartir
Comentar
0/400
CodeZeroBasis
· hace6h
Este bug me da miedo.
Ver originalesResponder0
MoonMathMagic
· hace6h
Está bien, si hay que perder, se pierde. ¿Quién no ha perdido dinero alguna vez?
Ver originalesResponder0
MeltdownSurvivalist
· hace6h
Otra vez un evento de Hacker, ¿y todavía lo hacen tan grande?
Ver originalesResponder0
BearMarketBro
· hace6h
Solo es un nombre vacío, incluso se pueden presentar este tipo de vulnerabilidades.
Ver originalesResponder0
BridgeTrustFund
· hace6h
sui realmente estalló en tres minutos
Ver originalesResponder0
0xSunnyDay
· hace6h
¿Cuándo caerá sui a 0?
Ver originalesResponder0
AirdropHarvester
· hace6h
¡Bum, bum, bum! El ecosistema SUI casi se ha desvanecido por completo.
La resiliencia del ecosistema SUI: Reflexiones de seguridad y perspectivas de desarrollo tras el ataque de Cetus
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, 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 pérdidas de más de 200 millones de dólares en activos. Este incidente no solo es uno de los accidentes de seguridad más grandes 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 red principal de SUI.
Según los datos, el TVL total de SUI en la cadena cayó drásticamente más de 330 millones de dólares en el día del ataque, y el monto bloqueado del protocolo Cetus se evaporó instantáneamente en un 84%, cayendo a 38 millones de dólares. Como resultado, varios tokens populares en SUI (incluidos Lofi, Sudeng, Squirtle, etc.) cayeron entre un 76% y un 97% en solo 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 mostró 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 la cadena y la actividad de los usuarios no sufrieron un deterioro sostenido, sino que, por el contrario, impulsaron un aumento significativo en la atención del ecosistema hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos.
Vamos a analizar 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 el actual patrón ecológico de esta cadena pública que aún se encuentra en una etapa temprana de desarrollo, y exploraremos su potencial de desarrollo futuro.
2. Análisis de las causas del ataque al evento Cetus
2.1 Proceso de implementación del ataque
Según el análisis técnico del incidente de ataque a Cetus, los hackers aprovecharon con éxito una vulnerabilidad clave 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 grandes cantidades de dinero 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. Tiene 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 lo controlaron con precisión en 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 la anterior manera, los hackers utilizaron una cantidad suficiente de tokens y una gran liquidez para manipular con éxito el precio de haSUI. Posteriormente, también manipularon varios tokens que no tenían valor real.
②Agregar liquidez
El atacante crea posiciones de liquidez estrechas, declara que añade liquidez, pero debido a la vulnerabilidad de la función checked_shlw, finalmente solo recibe 1 token.
Esencialmente se debe a dos razones:
Configuración de la máscara demasiado ancha: equivale a un límite de adición de liquidez extremadamente grande, lo que hace que la verificación de las entradas del usuario en el contrato sea ineficaz. Los hackers establecen parámetros anormales, construyendo entradas que siempre son menores que ese 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, se produjo un truncamiento de datos debido a que el desplazamiento excedió el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte de desbordamiento de alta posición fue automáticamente descartada, 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 inferior a 1, pero debido a que se redondea hacia arriba, al final se calculó como 1, lo que significa que el hacker solo necesita agregar 1 token para poder obtener una gran liquidez.
③Retirar liquidez
Realizar el reembolso del préstamo relámpago, manteniendo grandes ganancias. Finalmente, retirando activos de token 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:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000万美元USDC
490万美元Haedal Staked SUI
1950 millones de dólares TOILET
Otros tokens como HIPPO y LOFI cayeron un 75-80%, la liquidez se ha agotado
2.2 Causas y características de esta vulnerabilidad
La vulnerabilidad de Cetus tiene tres características:
Costo de reparación extremadamente bajo: por un lado, la causa fundamental del evento Cetus es un descuido 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 está limitada únicamente a Cetus y no está relacionada con el código de SUI. La raíz de la vulnerabilidad se encuentra en una verificación de condición de frontera, 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 esté completa y eliminando esta vulnerabilidad.
Alta ocultación: El contrato ha estado funcionando de manera estable sin fallos durante dos años, se han 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 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 anormales, lo que indica que este tipo de problemas es difícil de detectar mediante pruebas ordinarias. Estos problemas a menudo se encuentran en áreas ciegas de la percepción humana, por lo que permanecen latentes 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 verificación del límite superior al calcular la cantidad de tokens necesarios, y se sustituyó la operación de multiplicación convencional por un desplazamiento, mientras que si se utilizan las operaciones aritméticas convencionales en Move, se comprobará automáticamente la situación de 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 la versión de Solidity, la verificación de desbordamientos era muy débil. Históricamente, han ocurrido desbordamientos en sumas, restas y multiplicaciones, 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 eludir las declaraciones de verificación en el contrato mediante parámetros cuidadosamente estructurados, lo que permitió ataques de 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 la capacidad de 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 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 nodos por sí mismos, solo deben 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 "contratando" validadores de confianza. Esta es también una gran ventaja del DPoS en comparación con el PoS tradicional.
Representa la ronda de producción de bloques: un pequeño grupo de validadores seleccionados produce 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 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. Esto reduce los costos de hardware y operación, disminuye los requisitos de potencia de cálculo y reduce los costos. Finalmente, se logra una tarifa de usuario más baja.
Alta seguridad: los mecanismos de staking y delegación amplifican conjuntamente el costo y el riesgo de los ataques; junto con el mecanismo de confiscación en la cadena, se inhiben de manera efectiva 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 consenso para poder confirmar la transacción. Este mecanismo asegura que, incluso si unos pocos nodos actúan maliciosamente, la red puede mantener un funcionamiento seguro y eficiente. Para realizar cualquier actualización o decisión importante, también se requiere que más de dos tercios de los votos estén a favor para que se implemente.
En esencia, DPoS es un compromiso dentro del triángulo imposible, que busca un equilibrio entre descentralización y eficiencia. DPoS elige reducir el número de nodos de bloque activos a cambio de un rendimiento superior en el "triángulo imposible" de seguridad-descentralización-escalabilidad, lo que implica una pérdida de un grado de completa descentralización en comparación con PoS puro o PoW, pero mejora significativamente la capacidad de procesamiento de la red y la velocidad de las transacciones.
3.2 El rendimiento de SUI en este ataque
3.2.1 mecanismo de congelación en funcionamiento
En este incidente, SUI congeló rápidamente las direcciones relacionadas con el atacante.
Desde el 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 clave de la blockchain SUI, responsables de validar las transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores han implementado, en un nivel de consenso, un mecanismo similar al de 'congelación de cuentas' en las finanzas tradicionales.
SUI tiene incorporado 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 las direcciones de los hackers. Sin esta función, incluso si SUI solo tiene 113 validadores, 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 para cambiar la lista negra?
TransactionDenyConfig es un 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, cada validador parece estar 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", básicamente es la fundación (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 ------ 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 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 es más bien una capa adicional de seguridad para hacer frente a situaciones imprevistas y garantizar la seguridad de los fondos de los usuarios.
Es esencialmente un mecanismo de garantía de seguridad. Similar a una "cadena de seguridad" atada a la puerta, que solo se activa para aquellos que quieren invadir el hogar, es decir, para aquellos que actúan maliciosamente contra el protocolo. Para el usuario:
Para los grandes inversores, los principales proveedores de liquidez, el protocolo es el que más quiere garantizar la seguridad de los fondos, ya que en realidad los datos en cadena (tvl) son contribuidos por los principales grandes inversores. Para que el protocolo se desarrolle a largo plazo, definitivamente se priorizará la seguridad.
Para los minoristas, contribuyentes a la actividad del ecosistema, fuertes apoyadores de la construcción conjunta de tecnología y comunidad. El equipo del proyecto también espera poder atraer a los minoristas para co-construir, de esta manera se podrá perfeccionar gradualmente el ecosistema y aumentar la retención.