Fe de firmeza tras la crisis de seguridad: ¿Por qué SUI todavía tiene potencial de crecimiento a largo plazo?
1. Reacción en cadena provocada por un ataque
El 22 de mayo de 2023, el principal protocolo AMM Cetus, desplegado en la red SUI, fue víctima de un ataque hacker. 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 mayores accidentes de seguridad en el ámbito DeFi hasta ahora 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 en la cadena cayó abruptamente más de 330 millones de dólares en el día del ataque, y la cantidad bloqueada del protocolo Cetus se evaporó instantáneamente en un 84%, cayendo a 38 millones de dólares. Como consecuencia, varios tokens populares en SUI cayeron entre un 76% y un 97% en solo una hora, lo que generó una amplia preocupación en el mercado sobre la seguridad de SUI y la estabilidad de su ecosistema.
Pero después de esta ola de choque, el ecosistema SUI ha demostrado una gran resiliencia y capacidad de recuperación. A pesar de que el evento Cetus provocó una fluctuación de confianza a corto plazo, los fondos en cadena y la actividad de los usuarios no han sufrido un deterioro continuo, sino que han impulsado un notable aumento en la atención de todo el ecosistema hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos.
Nos centraremos 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, para analizar la actual estructura ecológica de esta cadena pública que aún se encuentra en una etapa temprana de desarrollo y discutir su potencial de desarrollo futuro.
2. Análisis de las causas del ataque del evento Cetus
2.1 Proceso de implementación del ataque
Según el análisis técnico del equipo de Slow Mist sobre el incidente del 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 de precios precisa y defectos en el contrato, robando más de 200 millones de dólares en activos digitales en un corto período de tiempo. La 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 mediante un préstamo relámpago, prestando grandes cantidades de fondos para manipular precios.
El préstamo relámpago permite a los usuarios pedir prestado y devolver fondos en la misma transacción, pagando solo una tarifa, con características de alta palanca, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para reducir el precio del mercado en poco tiempo y lo controlaron con precisión en 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 los métodos anteriores, los hackers utilizaron una cantidad suficiente de tokens y una gran liquidez para manipular con éxito el precio de haSUI. Luego, también manipularon varios tokens sin valor real.
②Agregar liquidez
Un 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 máscara demasiado amplia: equivale a un límite de adición de liquidez extremadamente alto, lo que hace que la validación de la entrada del usuario en el contrato sea prácticamente inútil. Los hackers eligen parámetros anómalos, construyendo entradas que siempre son inferiores a este límite, eludiendo así la detección de desbordamiento.
Desbordamiento de datos truncado: Al realizar una operación de desplazamiento n << 64 en el valor numérico n, ocurrió un truncamiento de datos debido a que el desplazamiento excedió el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte de desbordamiento alto se descartó automáticamente, lo que llevó a que el resultado de la operación estuviera muy por debajo de lo esperado, lo que hizo que el sistema subestimara la cantidad de haSUI necesaria para el intercambio. El resultado final del cálculo es aproximadamente menor que 1, pero debido a que se redondea hacia arriba, al final se calcula como 1, es decir, el hacker solo necesita agregar 1 token para poder obtener una gran liquidez.
③Retirar liquidez
Realizar el reembolso del 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 llevado al robo de los siguientes activos:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000 millones de dólares USDC
490万美元 Haedal Staked SUI
1950 millones de dólares TOILET
Otros tokens como HIPPO y LOFI cayeron un 75--80%, con falta de liquidez
2.2 La causa 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 o un error 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 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 sea completa y eliminando dicha vulnerabilidad.
Alta ocultación: El contrato ha estado funcionando de manera estable y sin fallos durante dos años, el Cetus Protocol ha 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 con alta liquidez, lo que activa una lógica anómala, lo que indica que este tipo de problemas es difícil de detectar mediante pruebas normales. Este tipo de problemas a menudo se encuentra en las zonas ciegas de la percepció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 la seguridad de recursos y la verificación de tipos, e incorpora la detección nativa de problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al agregar liquidez, se utilizó inicialmente un valor incorrecto para la verificación del límite superior al calcular la cantidad de tokens requerida, y se reemplazó la multiplicación convencional por una operación de desplazamiento. Sin embargo, si se utilizan operaciones convencionales de suma, resta, multiplicación y división, Move verifica 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 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, ha habido desbordamientos en suma, resta y multiplicación, 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 se han explotado eludiendo las sentencias de detección en el contrato mediante parámetros cuidadosamente construidos, lo que permite realizar 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 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 del ciclo de Epoch: 24 horas
Mecanismo de proceso:
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 la distribución de recompensas. Este mecanismo puede reducir la barrera de entrada para los usuarios comunes, permitiéndoles participar en el consenso de la red a través de la "contratación" de validadores de confianza. Esta es también una gran ventaja del DPoS en comparación con el PoS tradicional.
Representa el ciclo de creación de bloques: un número reducido de validadores seleccionados crean bloques en un orden fijo o aleatorio, lo que aumenta la velocidad de confirmación y mejora el TPS.
Elección dinámica: 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 la cantidad de nodos de bloque es controlable, la red puede completar la confirmación en milisegundos, cumpliendo con la demanda de alto TPS.
Bajo costo: Menos nodos participan en el consenso, lo que reduce significativamente el ancho de banda de red y los recursos computacionales necesarios para la sincronización de información y la agregación de firmas. Esto reduce el costo de hardware y operación, disminuye los requisitos de potencia de cálculo y, por lo tanto, 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 los costos y riesgos de un ataque; combinado con el mecanismo de confiscación en cadena, suprime efectivamente los comportamientos maliciosos.
Al mismo tiempo, en el mecanismo de consenso de SUI, se utiliza un algoritmo basado en BFT (tolerancia a fallos bizantinos), que requiere que más de dos tercios de los votos de los validadores lleguen a un acuerdo para confirmar la transacción. Este mecanismo asegura que incluso si algunos nodos actúan de manera maliciosa, la red puede mantenerse segura y operar de manera eficiente. Para realizar cualquier actualización o decisión importante, también se necesita que más de dos tercios de los votos estén a favor para poder implementarla.
En esencia, DPoS es una solución de compromiso del triángulo imposible, que realiza un equilibrio entre la descentralización y la eficiencia. DPoS, en el triángulo "imposible" de seguridad-descentralización-escalabilidad, opta por reducir el número de nodos de bloques activos a cambio de un mayor rendimiento, renunciando a cierto grado de completa descentralización en comparación con PoS puro o PoW, pero mejorando significativamente el rendimiento de la red y la velocidad de las transacciones.
3.2 El rendimiento de SUI en este ataque.
3.2.1 Mecanismo de congelación en funcionamiento
En este evento, SUI rápidamente congeló las direcciones relacionadas con el atacante.
Desde una perspectiva de código, se impide que las transacciones de transferencia sean empaquetadas en la cadena. Los nodos de validación son componentes centrales de la blockchain SUI, responsables de validar transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores están implementando, a nivel de consenso, un mecanismo similar al 'congelar cuentas' en las finanzas tradicionales.
SUI en sí tiene un mecanismo de lista de rechazo (deny list), que es una función de lista negra que puede bloquear cualquier transacción que involucre direcciones enumeradas. Dado que esta función ya existe en el cliente, cuando ocurre un ataque,
SUI puede congelar inmediatamente la dirección de un hacker. Si no tuviera esta función, incluso si SUI solo tiene 113 validadores, sería difícil para Cetus coordinar a todos los validadores uno por 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. Cualquiera que ejecute un nodo puede editar este archivo, hacer una recarga 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 esta es una "actualización urgente impulsada por el equipo de SUI", básicamente es la fundación SUI (o los desarrolladores autorizados por ella) quienes establecen y actualizan esta lista de rechazo.
SUI publica una lista negra, teóricamente los validadores pueden elegir si adoptarla ------ 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 de seguridad adicional para hacer frente a situaciones inesperadas 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 quieren invadir el hogar, es decir, para las personas que quieren hacer daño al protocolo. Para los usuarios:
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 todos contribuciones de 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 ecológica, poderosos apoyadores de la co-construcción técnica y comunitaria. El equipo del proyecto también espera poder atraer a los minoristas para co-construir,
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 me gusta
Recompensa
13
5
Compartir
Comentar
0/400
MEVHunterNoLoss
· hace10h
Esta ola de hackeo no me asusta reducir pérdidas.
Ver originalesResponder0
gas_fee_trauma
· hace10h
炒币亏完了就全在这
Responder0
faded_wojak.eth
· hace11h
¿Y todavía te atreves a hablar de resiliencia? Directamente te han dejado calvo.
Ver originalesResponder0
LiquidationKing
· hace11h
sui no necesariamente está frío, pero hay que tener cuidado con el hierro.
Ver originalesResponder0
MEVSandwich
· hace11h
¿Quién entiende el dolor de reducir pérdidas y estar atado?
La resiliencia del ecosistema SUI se destaca, mostrando un potencial de crecimiento a largo plazo después de eventos de seguridad.
Fe de firmeza tras la crisis de seguridad: ¿Por qué SUI todavía tiene potencial de crecimiento a largo plazo?
1. Reacción en cadena provocada por un ataque
El 22 de mayo de 2023, el principal protocolo AMM Cetus, desplegado en la red SUI, fue víctima de un ataque hacker. 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 mayores accidentes de seguridad en el ámbito DeFi hasta ahora 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 en la cadena cayó abruptamente más de 330 millones de dólares en el día del ataque, y la cantidad bloqueada del protocolo Cetus se evaporó instantáneamente en un 84%, cayendo a 38 millones de dólares. Como consecuencia, varios tokens populares en SUI cayeron entre un 76% y un 97% en solo una hora, lo que generó una amplia preocupación en el mercado sobre la seguridad de SUI y la estabilidad de su ecosistema.
Pero después de esta ola de choque, el ecosistema SUI ha demostrado una gran resiliencia y capacidad de recuperación. A pesar de que el evento Cetus provocó una fluctuación de confianza a corto plazo, los fondos en cadena y la actividad de los usuarios no han sufrido un deterioro continuo, sino que han impulsado un notable aumento en la atención de todo el ecosistema hacia la seguridad, la construcción de infraestructura y la calidad de los proyectos.
Nos centraremos 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, para analizar la actual estructura ecológica de esta cadena pública que aún se encuentra en una etapa temprana de desarrollo y discutir su potencial de desarrollo futuro.
2. Análisis de las causas del ataque del evento Cetus
2.1 Proceso de implementación del ataque
Según el análisis técnico del equipo de Slow Mist sobre el incidente del 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 de precios precisa y defectos en el contrato, robando más de 200 millones de dólares en activos digitales en un corto período de tiempo. La 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 mediante un préstamo relámpago, prestando grandes cantidades de fondos para manipular precios.
El préstamo relámpago permite a los usuarios pedir prestado y devolver fondos en la misma transacción, pagando solo una tarifa, con características de alta palanca, bajo riesgo y bajo costo. Los hackers aprovecharon este mecanismo para reducir el precio del mercado en poco tiempo y lo controlaron con precisión en 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 los métodos anteriores, los hackers utilizaron una cantidad suficiente de tokens y una gran liquidez para manipular con éxito el precio de haSUI. Luego, también manipularon varios tokens sin valor real.
②Agregar liquidez
Un 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 máscara demasiado amplia: equivale a un límite de adición de liquidez extremadamente alto, lo que hace que la validación de la entrada del usuario en el contrato sea prácticamente inútil. Los hackers eligen parámetros anómalos, construyendo entradas que siempre son inferiores a este límite, eludiendo así la detección de desbordamiento.
Desbordamiento de datos truncado: Al realizar una operación de desplazamiento n << 64 en el valor numérico n, ocurrió un truncamiento de datos debido a que el desplazamiento excedió el ancho de bits efectivo del tipo de datos uint256 (256 bits). La parte de desbordamiento alto se descartó automáticamente, lo que llevó a que el resultado de la operación estuviera muy por debajo de lo esperado, lo que hizo que el sistema subestimara la cantidad de haSUI necesaria para el intercambio. El resultado final del cálculo es aproximadamente menor que 1, pero debido a que se redondea hacia arriba, al final se calcula como 1, es decir, el hacker solo necesita agregar 1 token para poder obtener una gran liquidez.
③Retirar liquidez
Realizar el reembolso del 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 llevado al robo de los siguientes activos:
12.9 millones de SUI (aproximadamente 54 millones de dólares)
6000 millones de dólares USDC
490万美元 Haedal Staked SUI
1950 millones de dólares TOILET
Otros tokens como HIPPO y LOFI cayeron un 75--80%, con falta de liquidez
2.2 La causa 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 o un error 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 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 sea completa y eliminando dicha vulnerabilidad.
Alta ocultación: El contrato ha estado funcionando de manera estable y sin fallos durante dos años, el Cetus Protocol ha 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 con alta liquidez, lo que activa una lógica anómala, lo que indica que este tipo de problemas es difícil de detectar mediante pruebas normales. Este tipo de problemas a menudo se encuentra en las zonas ciegas de la percepció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 la seguridad de recursos y la verificación de tipos, e incorpora la detección nativa de problemas de desbordamiento de enteros en situaciones comunes. Este desbordamiento ocurrió porque al agregar liquidez, se utilizó inicialmente un valor incorrecto para la verificación del límite superior al calcular la cantidad de tokens requerida, y se reemplazó la multiplicación convencional por una operación de desplazamiento. Sin embargo, si se utilizan operaciones convencionales de suma, resta, multiplicación y división, Move verifica 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 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, ha habido desbordamientos en suma, resta y multiplicación, 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 se han explotado eludiendo las sentencias de detección en el contrato mediante parámetros cuidadosamente construidos, lo que permite realizar 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 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 del ciclo de Epoch: 24 horas
Mecanismo de proceso:
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 la distribución de recompensas. Este mecanismo puede reducir la barrera de entrada para los usuarios comunes, permitiéndoles participar en el consenso de la red a través de la "contratación" de validadores de confianza. Esta es también una gran ventaja del DPoS en comparación con el PoS tradicional.
Representa el ciclo de creación de bloques: un número reducido de validadores seleccionados crean bloques en un orden fijo o aleatorio, lo que aumenta la velocidad de confirmación y mejora el TPS.
Elección dinámica: 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 la cantidad de nodos de bloque es controlable, la red puede completar la confirmación en milisegundos, cumpliendo con la demanda de alto TPS.
Bajo costo: Menos nodos participan en el consenso, lo que reduce significativamente el ancho de banda de red y los recursos computacionales necesarios para la sincronización de información y la agregación de firmas. Esto reduce el costo de hardware y operación, disminuye los requisitos de potencia de cálculo y, por lo tanto, 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 los costos y riesgos de un ataque; combinado con el mecanismo de confiscación en cadena, suprime efectivamente los comportamientos maliciosos.
Al mismo tiempo, en el mecanismo de consenso de SUI, se utiliza un algoritmo basado en BFT (tolerancia a fallos bizantinos), que requiere que más de dos tercios de los votos de los validadores lleguen a un acuerdo para confirmar la transacción. Este mecanismo asegura que incluso si algunos nodos actúan de manera maliciosa, la red puede mantenerse segura y operar de manera eficiente. Para realizar cualquier actualización o decisión importante, también se necesita que más de dos tercios de los votos estén a favor para poder implementarla.
En esencia, DPoS es una solución de compromiso del triángulo imposible, que realiza un equilibrio entre la descentralización y la eficiencia. DPoS, en el triángulo "imposible" de seguridad-descentralización-escalabilidad, opta por reducir el número de nodos de bloques activos a cambio de un mayor rendimiento, renunciando a cierto grado de completa descentralización en comparación con PoS puro o PoW, pero mejorando significativamente el rendimiento de la red y la velocidad de las transacciones.
3.2 El rendimiento de SUI en este ataque.
3.2.1 Mecanismo de congelación en funcionamiento
En este evento, SUI rápidamente congeló las direcciones relacionadas con el atacante.
Desde una perspectiva de código, se impide que las transacciones de transferencia sean empaquetadas en la cadena. Los nodos de validación son componentes centrales de la blockchain SUI, responsables de validar transacciones y ejecutar las reglas del protocolo. Al ignorar colectivamente las transacciones relacionadas con el atacante, estos validadores están implementando, a nivel de consenso, un mecanismo similar al 'congelar cuentas' en las finanzas tradicionales.
SUI en sí tiene un mecanismo de lista de rechazo (deny list), que es una función de lista negra que puede bloquear cualquier transacción que involucre direcciones enumeradas. Dado que esta función ya existe en el cliente, cuando ocurre un ataque,
SUI puede congelar inmediatamente la dirección de un hacker. Si no tuviera esta función, incluso si SUI solo tiene 113 validadores, sería difícil para Cetus coordinar a todos los validadores uno por 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. Cualquiera que ejecute un nodo puede editar este archivo, hacer una recarga 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 esta es una "actualización urgente impulsada por el equipo de SUI", básicamente es la fundación SUI (o los desarrolladores autorizados por ella) quienes establecen y actualizan esta lista de rechazo.
SUI publica una lista negra, teóricamente los validadores pueden elegir si adoptarla ------ 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 de seguridad adicional para hacer frente a situaciones inesperadas 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 quieren invadir el hogar, es decir, para las personas que quieren hacer daño al protocolo. Para los usuarios:
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 todos contribuciones de 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 ecológica, poderosos apoyadores de la co-construcción técnica y comunitaria. El equipo del proyecto también espera poder atraer a los minoristas para co-construir,