Fe de acero 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 atacado por hackers, quienes 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 de mayor escala en el ámbito DeFi hasta la fecha en 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ó 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 cayeron entre un 76% y un 97% en solo una hora, lo que generó una amplia preocupación en el mercado sobre la seguridad de SUI y la estabilidad de su ecosistema.
Pero después de esta ola de impacto, el ecosistema SUI ha demostrado una gran resiliencia y capacidad de recuperación. A pesar de que el evento Cetus trajo una fluctuación de confianza a corto plazo, los fondos en la cadena y la actividad de los usuarios no han experimentado un declive sostenido, sino que han impulsado un aumento significativo en la atención hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos en todo el ecosistema.
Este artículo se centrará en las razones de este ataque, el mecanismo de consenso de nodos de SUI, la seguridad del lenguaje MOVE y el desarrollo ecológico de SUI, organizando el actual patrón ecológico de esta cadena pública que aún se encuentra en las primeras etapas de desarrollo, y explorando su potencial de desarrollo futuro.
2. Análisis de las causas del ataque de Cetus
2.1 Proceso de implementación del ataque
Según el análisis técnico del equipo de seguridad sobre el ataque a Cetus, los hackers aprovecharon con éxito una vulnerabilidad crítica de desbordamiento aritmético en el protocolo, utilizando préstamos relámpago, manipulación de precios precisa y defectos en el contrato, para robar más de 200 millones de dólares en activos digitales en un corto período de tiempo. La trayectoria del ataque se puede dividir aproximadamente en las siguientes tres etapas:
①Iniciar un préstamo relámpago, manipular el precio
Los hackers primero utilizaron un préstamo relámpago de 10 mil millones de haSUI con el deslizamiento máximo, prestando grandes cantidades de fondos para manipular el precio.
El préstamo relámpago permite a los usuarios pedir prestado y devolver fondos en una sola transacción, pagando solo una tarifa. Posee características de alto apalancamiento, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para bajar el precio del mercado en poco tiempo y lo controlaron con precisión dentro de un rango extremadamente 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 forma anterior, 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
Los atacantes crean posiciones de liquidez estrechas, reclaman añadir liquidez, pero debido a una vulnerabilidad en la función checked_shlw, al final solo reciben 1 token.
Esencialmente se debe a dos razones:
La configuración de la máscara es demasiado amplia: equivale a un límite de adición de liquidez extremadamente alto, lo que hace que la verificación de la entrada del usuario en el contrato sea prácticamente inútil. 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 produjo un truncamiento de datos debido a que el desplazamiento superó el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte de desbordamiento de bits altos se descartó automáticamente, lo que resultó en un resultado de operación muy por debajo de lo esperado, lo que llevó al sistema a subestimar 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 se calcula como igual a 1, lo que significa que el hacker solo necesita agregar 1 token para poder intercambiar una gran liquidez.
③ Retirar liquidez
Realizar el reembolso del préstamo relámpago, conservando enormes beneficios. Finalmente, retirar activos de tokens por un valor total de varios cientos de millones de dólares de múltiples pools de liquidez.
La situación de pérdida de fondos es grave, el ataque ha provocado el robo de los siguientes activos:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000万美元USDC
490 millones de dólares Haedal Staked SUI
1950 millones de dólares TOILET
Otros tokens como HIPPO y LOFI han caído 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:
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 ni un error 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 borde, y solo se requiere modificar dos líneas de código para eliminar completamente el riesgo; una vez completada la reparación, se puede implementar de inmediato en la red principal, asegurando que la lógica de los contratos posteriores sea completa y eliminando dicha vulnerabilidad.
Alta ocultación: el contrato ha estado funcionando sin fallos durante dos años desde su lanzamiento y ha sido auditado varias veces, pero no se han encontrado vulnerabilidades. La principal razón 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 raros con una liquidez extremadamente alta que desencadenan lógicas anómalas, lo que indica que este tipo de problemas son difíciles de detectar mediante pruebas ordinarias. Este tipo de problemas a menudo se encuentra en una zona ciega 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 comprobación de tipos, y tiene 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 comprobación del límite superior al calcular la cantidad de tokens necesarios, y se reemplazó la multiplicación convencional por una operación de desplazamiento. Si se hubieran utilizado operaciones de suma, resta, multiplicación o división convencionales, Move habría verificado automáticamente la situación de desbordamiento, evitando así este problema de truncamiento de bits altos.
Vulnerabilidades similares también han aparecido en otros lenguajes (como Solidity, Rust), e incluso son más fáciles de explotar debido a la 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, y la causa directa 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 han eludido las declaraciones de detección en el contrato mediante parámetros cuidadosamente elaborados, logrando ataques mediante 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 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 la barrera de entrada para la gobernanza es relativamente alta, lo que dificulta que los usuarios comunes influyan directamente en la gobernanza de la red.
Número promedio de validadores: 106
Promedio de ciclo de Epoch: 24 horas
Proceso del mecanismo:
Delegación de derechos: Los usuarios comunes no necesitan ejecutar nodos por sí mismos, solo necesitan apostar SUI y delegarlo a 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 bloque de ronda: 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.
Elecciones dinámicas: Al final de cada ciclo de conteo, se realiza una rotación dinámica y se reelige el conjunto de Validadores según el peso del voto, garantizando la vitalidad de los nodos, la consistencia de intereses y la descentralización.
Ventajas de DPoS:
Alta eficiencia: Debido a que el número de nodos de bloque puede ser controlado, la red puede completar la confirmación en milisegundos, satisfaciendo la necesidad 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 disminuye los costos de hardware y operación, reduce los requisitos de potencia de cálculo y, por lo tanto, los costos son más bajos. Finalmente, se logró una tarifa de usuario más baja.
Alta seguridad: los mecanismos de participación y delegación amplifican simultáneamente el costo y el riesgo de los ataques; junto con el mecanismo de confiscación en la cadena, se suprimen eficazmente las conductas maliciosas.
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 confirmar las transacciones. Este mecanismo asegura que, incluso si algunos nodos actúan de manera maliciosa, la red pueda seguir funcionando de manera segura y eficiente. Para realizar cualquier actualización o toma de decisiones importantes, también se necesita más de dos tercios de los votos para implementarlo.
En esencia, DPoS es una solución de compromiso al triángulo imposible, que busca un equilibrio entre descentralización y eficiencia. DPoS elige reducir la cantidad de nodos activos de producción de bloques a cambio de un mayor rendimiento, lo que implica una cierta renuncia a la completa descentralización en comparación con PoS puro o PoW, pero mejora 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, es hacer que las transacciones de transferencia no se puedan empaquetar en la cadena. Los nodos de verificación son componentes centrales de la cadena de bloques SUI, responsables de validar transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores han implementado en el 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 implique direcciones listadas. Dado que esta función ya existe en el cliente, cuando ocurre un ataque
SUI puede congelar inmediatamente la dirección del hacker. Si no tuviera esta función, incluso si SUI solo tiene 113 validadores, sería difícil coordinar a todos los validadores para que respondan uno a uno en un corto período de tiempo.
3.2.2 ¿Quién tiene el poder de modificar 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 primera 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 de emergencia impulsada por el equipo", básicamente es la fundación (o los desarrolladores autorizados por ella) quienes establecen y actualizan esta lista de rechazo.
Publicar una lista negra, en teoría, los validadores pueden elegir si adoptarla o no------pero en la práctica, la mayoría de las personas la adoptan automáticamente por defecto. Por lo tanto, aunque esta función protege los fondos de los usuarios, en esencia, tiene un cierto grado de centralización.
3.2.3 La esencia de la función de lista negra
La función de lista negra en realidad no es una lógica de protocolo subyacente, sino que es más bien una capa de seguridad adicional para hacer frente a situaciones inesperadas y garantizar la seguridad de los fondos del usuario.
Esencialmente es un mecanismo de garantía de seguridad. Similar a una "cadena de seguridad" atada a la puerta, se activa solo para aquellos que intentan invadir el hogar, es decir, para quienes actúan de mala fe en el protocolo. Para los usuarios:
Para los grandes inversores, que son los principales proveedores de liquidez, el protocolo es el que más desea garantizar la seguridad de los fondos, ya que en realidad los datos en la cadena de tvl son contribuidos en su totalidad por los principales grandes inversores. Para que el protocolo se desarrolle de manera sostenible, debe priorizar la seguridad.
Para los inversores minoristas, contribuyentes a la actividad del ecosistema, y fuertes apoyadores de la construcción conjunta de tecnología y comunidad. El equipo del proyecto también espera poder atraer a los inversores minoristas para co-construir, de esta manera se podrá mejorar gradualmente el ecosistema y aumentar la tasa de retención. En el ámbito de defi, lo más primordial
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
4
Compartir
Comentar
0/400
LiquidityOracle
· hace16h
caída... ¿cuándo terminará la caída?
Ver originalesResponder0
SatoshiNotNakamoto
· 08-04 12:21
Negro y camina con estilo
Ver originalesResponder0
PuzzledScholar
· 08-04 12:14
No te preocupes, esto se llama apretón en corto y subir.
Detrás de la resiliencia del ecosistema SUI: Análisis del evento de ataque de Cetus y discusión sobre el potencial de desarrollo futuro
Fe de acero 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 atacado por hackers, quienes 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 de mayor escala en el ámbito DeFi hasta la fecha en 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ó 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 cayeron entre un 76% y un 97% en solo una hora, lo que generó una amplia preocupación en el mercado sobre la seguridad de SUI y la estabilidad de su ecosistema.
Pero después de esta ola de impacto, el ecosistema SUI ha demostrado una gran resiliencia y capacidad de recuperación. A pesar de que el evento Cetus trajo una fluctuación de confianza a corto plazo, los fondos en la cadena y la actividad de los usuarios no han experimentado un declive sostenido, sino que han impulsado un aumento significativo en la atención hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos en todo el ecosistema.
Este artículo se centrará en las razones de este ataque, el mecanismo de consenso de nodos de SUI, la seguridad del lenguaje MOVE y el desarrollo ecológico de SUI, organizando el actual patrón ecológico de esta cadena pública que aún se encuentra en las primeras etapas de desarrollo, y explorando su potencial de desarrollo futuro.
2. Análisis de las causas del ataque de Cetus
2.1 Proceso de implementación del ataque
Según el análisis técnico del equipo de seguridad sobre el ataque a Cetus, los hackers aprovecharon con éxito una vulnerabilidad crítica de desbordamiento aritmético en el protocolo, utilizando préstamos relámpago, manipulación de precios precisa y defectos en el contrato, para robar más de 200 millones de dólares en activos digitales en un corto período de tiempo. La trayectoria del ataque se puede dividir aproximadamente en las siguientes tres etapas:
①Iniciar un préstamo relámpago, manipular el precio
Los hackers primero utilizaron un préstamo relámpago de 10 mil millones de haSUI con el deslizamiento máximo, prestando grandes cantidades de fondos para manipular el precio.
El préstamo relámpago permite a los usuarios pedir prestado y devolver fondos en una sola transacción, pagando solo una tarifa. Posee características de alto apalancamiento, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para bajar el precio del mercado en poco tiempo y lo controlaron con precisión dentro de un rango extremadamente 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 forma anterior, 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
Los atacantes crean posiciones de liquidez estrechas, reclaman añadir liquidez, pero debido a una vulnerabilidad en la función checked_shlw, al final solo reciben 1 token.
Esencialmente se debe a dos razones:
La configuración de la máscara es demasiado amplia: equivale a un límite de adición de liquidez extremadamente alto, lo que hace que la verificación de la entrada del usuario en el contrato sea prácticamente inútil. 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 produjo un truncamiento de datos debido a que el desplazamiento superó el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte de desbordamiento de bits altos se descartó automáticamente, lo que resultó en un resultado de operación muy por debajo de lo esperado, lo que llevó al sistema a subestimar 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 se calcula como igual a 1, lo que significa que el hacker solo necesita agregar 1 token para poder intercambiar una gran liquidez.
③ Retirar liquidez
Realizar el reembolso del préstamo relámpago, conservando enormes beneficios. Finalmente, retirar activos de tokens por un valor total de varios cientos de millones de dólares de múltiples pools de liquidez.
La situación de pérdida de fondos es grave, el ataque ha provocado el robo de los siguientes activos:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000万美元USDC
490 millones de dólares Haedal Staked SUI
1950 millones de dólares TOILET
Otros tokens como HIPPO y LOFI han caído 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:
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 ni un error 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 borde, y solo se requiere modificar dos líneas de código para eliminar completamente el riesgo; una vez completada la reparación, se puede implementar de inmediato en la red principal, asegurando que la lógica de los contratos posteriores sea completa y eliminando dicha vulnerabilidad.
Alta ocultación: el contrato ha estado funcionando sin fallos durante dos años desde su lanzamiento y ha sido auditado varias veces, pero no se han encontrado vulnerabilidades. La principal razón 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 raros con una liquidez extremadamente alta que desencadenan lógicas anómalas, lo que indica que este tipo de problemas son difíciles de detectar mediante pruebas ordinarias. Este tipo de problemas a menudo se encuentra en una zona ciega 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 comprobación de tipos, y tiene 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 comprobación del límite superior al calcular la cantidad de tokens necesarios, y se reemplazó la multiplicación convencional por una operación de desplazamiento. Si se hubieran utilizado operaciones de suma, resta, multiplicación o división convencionales, Move habría verificado automáticamente la situación de desbordamiento, evitando así este problema de truncamiento de bits altos.
Vulnerabilidades similares también han aparecido en otros lenguajes (como Solidity, Rust), e incluso son más fáciles de explotar debido a la 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, y la causa directa 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 han eludido las declaraciones de detección en el contrato mediante parámetros cuidadosamente elaborados, logrando ataques mediante 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 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 la barrera de entrada para la gobernanza es relativamente alta, lo que dificulta que los usuarios comunes influyan directamente en la gobernanza de la red.
Número promedio de validadores: 106
Promedio de ciclo de Epoch: 24 horas
Proceso del mecanismo:
Delegación de derechos: Los usuarios comunes no necesitan ejecutar nodos por sí mismos, solo necesitan apostar SUI y delegarlo a 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 bloque de ronda: 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.
Elecciones dinámicas: Al final de cada ciclo de conteo, se realiza una rotación dinámica y se reelige el conjunto de Validadores según el peso del voto, garantizando la vitalidad de los nodos, la consistencia de intereses y la descentralización.
Ventajas de DPoS:
Alta eficiencia: Debido a que el número de nodos de bloque puede ser controlado, la red puede completar la confirmación en milisegundos, satisfaciendo la necesidad 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 disminuye los costos de hardware y operación, reduce los requisitos de potencia de cálculo y, por lo tanto, los costos son más bajos. Finalmente, se logró una tarifa de usuario más baja.
Alta seguridad: los mecanismos de participación y delegación amplifican simultáneamente el costo y el riesgo de los ataques; junto con el mecanismo de confiscación en la cadena, se suprimen eficazmente las conductas maliciosas.
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 confirmar las transacciones. Este mecanismo asegura que, incluso si algunos nodos actúan de manera maliciosa, la red pueda seguir funcionando de manera segura y eficiente. Para realizar cualquier actualización o toma de decisiones importantes, también se necesita más de dos tercios de los votos para implementarlo.
En esencia, DPoS es una solución de compromiso al triángulo imposible, que busca un equilibrio entre descentralización y eficiencia. DPoS elige reducir la cantidad de nodos activos de producción de bloques a cambio de un mayor rendimiento, lo que implica una cierta renuncia a la completa descentralización en comparación con PoS puro o PoW, pero mejora 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, es hacer que las transacciones de transferencia no se puedan empaquetar en la cadena. Los nodos de verificación son componentes centrales de la cadena de bloques SUI, responsables de validar transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores han implementado en el 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 implique direcciones listadas. Dado que esta función ya existe en el cliente, cuando ocurre un ataque
SUI puede congelar inmediatamente la dirección del hacker. Si no tuviera esta función, incluso si SUI solo tiene 113 validadores, sería difícil coordinar a todos los validadores para que respondan uno a uno en un corto período de tiempo.
3.2.2 ¿Quién tiene el poder de modificar 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 primera 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 de emergencia impulsada por el equipo", básicamente es la fundación (o los desarrolladores autorizados por ella) quienes establecen y actualizan esta lista de rechazo.
Publicar una lista negra, en teoría, los validadores pueden elegir si adoptarla o no------pero en la práctica, la mayoría de las personas la adoptan automáticamente por defecto. Por lo tanto, aunque esta función protege los fondos de los usuarios, en esencia, tiene un cierto grado de centralización.
3.2.3 La esencia de la función de lista negra
La función de lista negra en realidad no es una lógica de protocolo subyacente, sino que es más bien una capa de seguridad adicional para hacer frente a situaciones inesperadas y garantizar la seguridad de los fondos del usuario.
Esencialmente es un mecanismo de garantía de seguridad. Similar a una "cadena de seguridad" atada a la puerta, se activa solo para aquellos que intentan invadir el hogar, es decir, para quienes actúan de mala fe en el protocolo. Para los usuarios:
Para los grandes inversores, que son los principales proveedores de liquidez, el protocolo es el que más desea garantizar la seguridad de los fondos, ya que en realidad los datos en la cadena de tvl son contribuidos en su totalidad por los principales grandes inversores. Para que el protocolo se desarrolle de manera sostenible, debe priorizar la seguridad.
Para los inversores minoristas, contribuyentes a la actividad del ecosistema, y fuertes apoyadores de la construcción conjunta de tecnología y comunidad. El equipo del proyecto también espera poder atraer a los inversores minoristas para co-construir, de esta manera se podrá mejorar gradualmente el ecosistema y aumentar la tasa de retención. En el ámbito de defi, lo más primordial