Creencia firme tras la crisis de seguridad: ¿por qué SUI todavía tiene el potencial de subir 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 el "problema de desbordamiento de enteros" para llevar a cabo un control preciso, lo que resultó en la 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 red principal de SUI.
Según los datos de DefiLlama, el TVL total de SUI 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 (incluyendo Lofi, Sudeng, Squirtle, entre otros) cayeron entre un 76% y un 97% en solo una hora, lo que generó una amplia preocupación en el mercado sobre la seguridad y la estabilidad del ecosistema de SUI.
Pero después de esta ola de 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 de confianza a corto plazo, los fondos en la cadena y la actividad de los usuarios no han sufrido un declive continuo, sino que han impulsado un aumento significativo en la atención a la seguridad, la construcción de infraestructura y la calidad de los proyectos en todo el ecosistema.
2. Análisis de las causas del ataque del evento Cetus
2.1 Proceso de implementación de 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 utilizaron un préstamo relámpago de 10 mil millones de haSUI con el deslizamiento máximo para pedir prestado una gran cantidad de fondos y manipular los precios.
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 aprovecharon este mecanismo para reducir el precio del mercado en un corto período de tiempo y controlarlo 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 suficientemente grande de tokens y una enorme 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 está añadiendo 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 máscara demasiado amplia: equivale a un límite de adición de liquidez extremadamente grande, lo que hace que la validación de las entradas del usuario en el contrato sea prácticamente inexistente. Los hackers, al establecer parámetros anómalos, construyen 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 produce un truncamiento de datos debido a que el desplazamiento excede el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte superior del desbordamiento se descarta automáticamente, lo que resulta en un resultado de cálculo muy por debajo de lo esperado, lo que lleva al sistema a subestimar la cantidad de haSUI necesaria para el intercambio. El resultado final del cálculo es aproximadamente menor que 1, pero debido a que se redondea hacia arriba, al final se obtiene igual a 1, lo que significa que el hacker solo necesita añadir 1 token para poder intercambiar una gran liquidez.
③Retirar liquidez
Realizar el reembolso de un préstamo relámpago, conservando 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 resultado en el robo de los siguientes activos:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000 millones de dólares USDC
490 millones de dólares Haedal Staked SUI
1950万美元TOILET
Otros tokens como HIPPO y LOFI han bajado entre un 75 y un 80%, la liquidez se ha agotado.
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 ni en la arquitectura subyacente. Por otro lado, la vulnerabilidad está limitada únicamente a Cetus y no tiene relación con el código de SUI. La raíz de la vulnerabilidad radica en una condición de límite, y solo se requieren dos líneas de código para eliminar completamente el riesgo; una vez finalizada la reparación, se puede desplegar inmediatamente en la red principal, asegurando que la lógica de los contratos posteriores esté completa y eliminando esta vulnerabilidad.
Alta privacidad: El contrato ha estado funcionando sin fallos durante dos años, y el Cetus Protocol ha sido auditado varias veces, pero no se han encontrado vulnerabilidades, principalmente porque 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 con alta liquidez que desencadenan lógicas anómalas, lo que indica que este tipo de problemas son difíciles de detectar a través de pruebas comunes. Estos problemas a menudo se encuentran en áreas ciegas de la visión de las personas, 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 cuanto a la seguridad de los recursos y la verificación de tipos, y cuenta con una detección nativa de problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al agregar liquidez, se utilizó primero un valor incorrecto para la verificación del límite superior al calcular la cantidad de tokens necesarios, y se empleó una operación de desplazamiento en lugar de la multiplicación convencional. Sin embargo, si se utilizan operaciones convencionales de suma, resta, multiplicación y división en Move, se comprobará automáticamente la situación de desbordamiento, por lo que no habrá este problema 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 de suma, desbordamientos de resta, desbordamientos de multiplicación, etc., y la causa directa es que el resultado de la operación excede el rango. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity han eludido las declaraciones de verificación en el contrato mediante parámetros cuidadosamente construidos, llevando a transferencias excesivas para llevar a cabo ataques.
3. Mecanismo de consenso de SUI
3.1 Introducción al mecanismo de consenso SUI
Resumen:
SUI adopta un marco de Prueba de Participación Delegada (DeleGated Proof of Stake, abreviado DPoS). Aunque el mecanismo DPoS puede aumentar el rendimiento de las transacciones, no puede proporcionar un alto grado de descentralización como lo hace PoW (Prueba de Trabajo). Por lo tanto, el grado de descentralización de SUI es relativamente bajo, y el umbral de gobernanza es relativamente alto, lo que dificulta que los usuarios comunes 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 su cuenta, solo deben apostar SUI y delegarlo a los validadores candidatos para participar en la garantía de seguridad de la red y 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 también es una gran ventaja del DPoS en comparación con el PoS tradicional.
Representa el ciclo de bloques: un pequeño número de validadores seleccionados producen bloques en un orden fijo o aleatorio, lo que mejora la velocidad de confirmación y aumenta el TPS.
Elección dinámica: al final de cada ciclo de votación, se realiza una rotación dinámica de acuerdo con el peso de los votos, reelectando el conjunto de Validadores, garantizando la vitalidad de los nodos, la coherencia de intereses y la descentralización.
Ventajas de DPoS:
Alta eficiencia: Debido a que la cantidad de nodos de bloque es controlable, la red puede completar la confirmación en milisegundos, cumpliendo con la alta demanda de 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. Como resultado, los costos de hardware y mantenimiento disminuyen, los requisitos de potencia de cálculo se reducen y los costos son más bajos. Finalmente, se logra una tarifa de usuario más baja.
Alta seguridad: el mecanismo de participación y delegación amplifica simultáneamente el costo y el riesgo de los ataques; combinado con el mecanismo de confiscación en la cadena, suprime 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 estén de acuerdo para confirmar una transacción. Este mecanismo asegura que incluso si algunos nodos actúan de manera maliciosa, la red puede mantener una operación segura y eficiente. Para llevar a cabo cualquier actualización o decisión importante, también se requiere que más de dos tercios de los votos estén de acuerdo para implementarla.
En esencia, el DPoS es una solución de compromiso para el triángulo imposible, que busca un equilibrio entre la descentralización y la eficiencia. En el "triángulo imposible" de seguridad-descentralización-escalabilidad, el DPoS elige reducir la cantidad de nodos activos de producción de bloques a cambio de un mejor rendimiento, sacrificando en cierta medida la 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 mecanismo de congelación en funcionamiento
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 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 implementan una especie de mecanismo similar al 'congelamiento de cuentas' en las finanzas tradicionales a nivel de consenso.
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 implique direcciones enumeradas. Dado que esta función ya está presente 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 para que respondan 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. Cualquier persona que ejecute un nodo puede editar este archivo, recargarlo en caliente o reiniciar el nodo, y actualizar la lista. A simple vista, parece que cada validador está expresando libremente sus propios valores.
En realidad, para la coherencia y efectividad de la política de seguridad, la actualización de esta configuración clave suele ser coordinada. Dado que se trata de "una actualización urgente impulsada por el equipo 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 ------ pero en realidad 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 subyacente del protocolo, sino que es más bien 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 quienes 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 desea garantizar la seguridad de los fondos, ya que, en realidad, los datos en cadena tvl son aportados principalmente por grandes inversores. Si se desea que el protocolo se desarrolle a largo plazo, necesariamente se priorizará la seguridad.
Para los minoristas, contribuyentes a la actividad del ecosistema, y fuertes apoyadores de la co-creación técnica y comunitaria. El equipo del proyecto también espera atraer a los minoristas para co-crear, así es como se puede mejorar 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 centralizado" debe ser si los usuarios tienen el control sobre sus activos. En este sentido, SUI utiliza 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.
11 me gusta
Recompensa
11
5
Compartir
Comentar
0/400
Web3ProductManager
· hace19h
observando los datos de retención de usuarios... este hack podría ser un gran punto de fricción para la adopción masiva, la verdad
Ver originalesResponder0
MEVHunterWang
· hace19h
¿Nadie descubrió un agujero tan grande? Inesperado, inesperado.
Ver originalesResponder0
fren.eth
· hace19h
Es realmente trágico, he perdido varias veces.
Ver originalesResponder0
¯\_(ツ)_/¯
· hace19h
tomar a la gente por tonta una vez, menos un trozo de carne, ¿cuándo debe subir, seguirá subiendo?
Ver originalesResponder0
MetaverseMigrant
· hace19h
Esta vez no hay tren, los que se atreven a introducir una posición son verdaderos guerreros.
Análisis del ecosistema SUI: resiliencia y potencial de crecimiento a largo plazo tras el incidente de ataque de Cetus
Creencia firme tras la crisis de seguridad: ¿por qué SUI todavía tiene el potencial de subir 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 el "problema de desbordamiento de enteros" para llevar a cabo un control preciso, lo que resultó en la 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 red principal de SUI.
Según los datos de DefiLlama, el TVL total de SUI 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 (incluyendo Lofi, Sudeng, Squirtle, entre otros) cayeron entre un 76% y un 97% en solo una hora, lo que generó una amplia preocupación en el mercado sobre la seguridad y la estabilidad del ecosistema de SUI.
Pero después de esta ola de 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 de confianza a corto plazo, los fondos en la cadena y la actividad de los usuarios no han sufrido un declive continuo, sino que han impulsado un aumento significativo en la atención a la seguridad, la construcción de infraestructura y la calidad de los proyectos en todo el ecosistema.
2. Análisis de las causas del ataque del evento Cetus
2.1 Proceso de implementación de 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 utilizaron un préstamo relámpago de 10 mil millones de haSUI con el deslizamiento máximo para pedir prestado una gran cantidad de fondos y manipular los precios.
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 aprovecharon este mecanismo para reducir el precio del mercado en un corto período de tiempo y controlarlo 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 suficientemente grande de tokens y una enorme 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 está añadiendo 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 máscara demasiado amplia: equivale a un límite de adición de liquidez extremadamente grande, lo que hace que la validación de las entradas del usuario en el contrato sea prácticamente inexistente. Los hackers, al establecer parámetros anómalos, construyen 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 produce un truncamiento de datos debido a que el desplazamiento excede el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte superior del desbordamiento se descarta automáticamente, lo que resulta en un resultado de cálculo muy por debajo de lo esperado, lo que lleva al sistema a subestimar la cantidad de haSUI necesaria para el intercambio. El resultado final del cálculo es aproximadamente menor que 1, pero debido a que se redondea hacia arriba, al final se obtiene igual a 1, lo que significa que el hacker solo necesita añadir 1 token para poder intercambiar una gran liquidez.
③Retirar liquidez
Realizar el reembolso de un préstamo relámpago, conservando 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 resultado en el robo de los siguientes activos:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000 millones de dólares USDC
490 millones de dólares Haedal Staked SUI
1950万美元TOILET
Otros tokens como HIPPO y LOFI han bajado entre un 75 y un 80%, la liquidez se ha agotado.
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 ni en la arquitectura subyacente. Por otro lado, la vulnerabilidad está limitada únicamente a Cetus y no tiene relación con el código de SUI. La raíz de la vulnerabilidad radica en una condición de límite, y solo se requieren dos líneas de código para eliminar completamente el riesgo; una vez finalizada la reparación, se puede desplegar inmediatamente en la red principal, asegurando que la lógica de los contratos posteriores esté completa y eliminando esta vulnerabilidad.
Alta privacidad: El contrato ha estado funcionando sin fallos durante dos años, y el Cetus Protocol ha sido auditado varias veces, pero no se han encontrado vulnerabilidades, principalmente porque 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 con alta liquidez que desencadenan lógicas anómalas, lo que indica que este tipo de problemas son difíciles de detectar a través de pruebas comunes. Estos problemas a menudo se encuentran en áreas ciegas de la visión de las personas, por lo que permanecen latentes durante mucho tiempo antes de ser descubiertos.
Move es superior a varios lenguajes de contratos inteligentes en cuanto a la seguridad de los recursos y la verificación de tipos, y cuenta con una detección nativa de problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al agregar liquidez, se utilizó primero un valor incorrecto para la verificación del límite superior al calcular la cantidad de tokens necesarios, y se empleó una operación de desplazamiento en lugar de la multiplicación convencional. Sin embargo, si se utilizan operaciones convencionales de suma, resta, multiplicación y división en Move, se comprobará automáticamente la situación de desbordamiento, por lo que no habrá este problema 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 de suma, desbordamientos de resta, desbordamientos de multiplicación, etc., y la causa directa es que el resultado de la operación excede el rango. Por ejemplo, las vulnerabilidades en los contratos inteligentes BEC y SMT del lenguaje Solidity han eludido las declaraciones de verificación en el contrato mediante parámetros cuidadosamente construidos, llevando a transferencias excesivas para llevar a cabo ataques.
3. Mecanismo de consenso de SUI
3.1 Introducción al mecanismo de consenso SUI
Resumen:
SUI adopta un marco de Prueba de Participación Delegada (DeleGated Proof of Stake, abreviado DPoS). Aunque el mecanismo DPoS puede aumentar el rendimiento de las transacciones, no puede proporcionar un alto grado de descentralización como lo hace PoW (Prueba de Trabajo). Por lo tanto, el grado de descentralización de SUI es relativamente bajo, y el umbral de gobernanza es relativamente alto, lo que dificulta que los usuarios comunes 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 su cuenta, solo deben apostar SUI y delegarlo a los validadores candidatos para participar en la garantía de seguridad de la red y 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 también es una gran ventaja del DPoS en comparación con el PoS tradicional.
Representa el ciclo de bloques: un pequeño número de validadores seleccionados producen bloques en un orden fijo o aleatorio, lo que mejora la velocidad de confirmación y aumenta el TPS.
Elección dinámica: al final de cada ciclo de votación, se realiza una rotación dinámica de acuerdo con el peso de los votos, reelectando el conjunto de Validadores, garantizando la vitalidad de los nodos, la coherencia de intereses y la descentralización.
Ventajas de DPoS:
Alta eficiencia: Debido a que la cantidad de nodos de bloque es controlable, la red puede completar la confirmación en milisegundos, cumpliendo con la alta demanda de 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. Como resultado, los costos de hardware y mantenimiento disminuyen, los requisitos de potencia de cálculo se reducen y los costos son más bajos. Finalmente, se logra una tarifa de usuario más baja.
Alta seguridad: el mecanismo de participación y delegación amplifica simultáneamente el costo y el riesgo de los ataques; combinado con el mecanismo de confiscación en la cadena, suprime 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 estén de acuerdo para confirmar una transacción. Este mecanismo asegura que incluso si algunos nodos actúan de manera maliciosa, la red puede mantener una operación segura y eficiente. Para llevar a cabo cualquier actualización o decisión importante, también se requiere que más de dos tercios de los votos estén de acuerdo para implementarla.
En esencia, el DPoS es una solución de compromiso para el triángulo imposible, que busca un equilibrio entre la descentralización y la eficiencia. En el "triángulo imposible" de seguridad-descentralización-escalabilidad, el DPoS elige reducir la cantidad de nodos activos de producción de bloques a cambio de un mejor rendimiento, sacrificando en cierta medida la 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 mecanismo de congelación en funcionamiento
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 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 implementan una especie de mecanismo similar al 'congelamiento de cuentas' en las finanzas tradicionales a nivel de consenso.
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 implique direcciones enumeradas. Dado que esta función ya está presente 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 para que respondan 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. Cualquier persona que ejecute un nodo puede editar este archivo, recargarlo en caliente o reiniciar el nodo, y actualizar la lista. A simple vista, parece que cada validador está expresando libremente sus propios valores.
En realidad, para la coherencia y efectividad de la política de seguridad, la actualización de esta configuración clave suele ser coordinada. Dado que se trata de "una actualización urgente impulsada por el equipo 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 ------ pero en realidad 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 subyacente del protocolo, sino que es más bien 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 quienes 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 desea garantizar la seguridad de los fondos, ya que, en realidad, los datos en cadena tvl son aportados principalmente por grandes inversores. Si se desea que el protocolo se desarrolle a largo plazo, necesariamente se priorizará la seguridad.
Para los minoristas, contribuyentes a la actividad del ecosistema, y fuertes apoyadores de la co-creación técnica y comunitaria. El equipo del proyecto también espera atraer a los minoristas para co-crear, así es como se puede mejorar 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 centralizado" debe ser si los usuarios tienen el control sobre sus activos. En este sentido, SUI utiliza Move.