Fé inabalável após a crise de segurança: por que o SUI ainda tem potencial de crescimento a longo prazo?

1. Uma reação em cadeia provocada por um ataque

No dia 22 de maio de 2025, o principal protocolo AMM Cetus, implantado na rede SUI, sofreu um ataque de hackers. Os atacantes exploraram uma falha lógica relacionada a um "problema de estouro de inteiro" para realizar um controle preciso, resultando em perdas de mais de 200 milhões de dólares em ativos. Este incidente não é apenas um dos maiores acidentes de segurança no espaço DeFi até agora este ano, mas também se tornou o ataque hacker mais destrutivo desde o lançamento da mainnet SUI.

De acordo com os dados da DefiLlama, o TVL total da SUI caiu drasticamente em mais de 330 milhões de dólares no dia do ataque, enquanto o montante bloqueado no protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI (incluindo Lofi, Sudeng, Squirtle, entre outros) despencaram entre 76% a 97% em apenas uma hora, gerando ampla preocupação no mercado sobre a segurança e a estabilidade ecológica da SUI.

Mas após essa onda de choque, o ecossistema SUI demonstrou uma forte resiliência e capacidade de recuperação. Embora o evento Cetus tenha causado uma flutuação de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram um declínio contínuo, mas sim incentivaram uma atenção significativa em todo o ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.

A Klein Labs irá analisar as causas deste ataque, o mecanismo de consenso dos nós do SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema do SUI, organizando o atual padrão ecológico desta blockchain que ainda se encontra em fase inicial de desenvolvimento e discutindo seu potencial de desenvolvimento futuro.

2. Análise das causas do ataque ao evento Cetus

2.1 Implementação do ataque

De acordo com a análise técnica da equipe Slow Mist sobre o ataque ao Cetus, os hackers exploraram com sucesso uma vulnerabilidade crítica de estouro aritmético no protocolo, utilizando empréstimos relâmpago, manipulação de preços precisa e defeitos de contrato, roubando mais de 200 milhões de dólares em ativos digitais em um curto espaço de tempo. O caminho do ataque pode ser dividido aproximadamente nas seguintes três fases:

①Iniciar um empréstimo relâmpago, manipular os preços

Os hackers primeiro utilizaram um flash loan de 10 bilhões de haSUI com o maior slippage, emprestando uma grande quantidade de fundos para manipulação de preços.

O empréstimo relâmpago permite que os usuários tomem emprestado e devolvam fundos na mesma transação, pagando apenas uma taxa, com características de alta alavancagem, baixo risco e baixo custo. Os hackers aproveitaram esse mecanismo para derrubar rapidamente o preço do mercado e controlá-lo de forma precisa dentro de um intervalo extremamente estreito.

Em seguida, o atacante prepara-se para criar uma posição de liquidez extremamente estreita, definindo o intervalo de preços precisamente entre a oferta mínima de 300.000 e o preço máximo de 300.200, com uma largura de preço de apenas 1,00496621%.

Através do método acima, os hackers utilizaram uma quantidade suficiente de tokens e uma enorme liquidez para manipular com sucesso o preço do haSUI. Em seguida, eles também manipularam vários tokens sem valor real.

②Adicionar liquidez

O atacante cria posições de liquidez estreitas, declarando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba recebendo apenas 1 token.

É essencialmente devido a duas razões:

1. Configuração de máscara muito ampla: equivale a um limite de adição de liquidez extremamente alto, levando a uma verificação das entradas dos usuários no contrato que é praticamente inútil. Hackers conseguem contornar a detecção de estouro ao definir parâmetros anormais, construindo entradas que estão sempre abaixo desse limite.

2. Dados de overflow foram truncados: ao executar a operação de deslocamento n << 64 em um valor numérico n, ocorreu uma truncagem de dados devido ao deslocamento exceder a largura efetiva do tipo de dado uint256 (256 bits). A parte de overflow mais significativa foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, fazendo com que o sistema subestimasse a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi cerca de 1, mas como foi arredondado para cima, acabou sendo igual a 1, ou seja, o hacker só precisou adicionar 1 token para conseguir retirar uma grande liquidez.

③ Retirar liquidez

Realizar o reembolso de um empréstimo relâmpago, mantendo lucros substanciais. No final, retirar ativos de tokens com um valor total de várias centenas de milhões de dólares de múltiplos pools de liquidez.

A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:

• 1290 milhões de SUI (cerca de 5400 milhões de dólares)

• 6000万美元USDC

• 4,9 milhões de dólares Haedal Staked SUI

• 1950万美元TOILET

• Outros tokens como HIPPO e LOFI caíram 75-80%, a liquidez esgotou-se

2.2 Causas e características da vulnerabilidade desta vez

Esta vulnerabilidade do Cetus tem três características:

1. O custo de reparação é extremamente baixo: por um lado, a causa fundamental do incidente Cetus é uma falha na biblioteca matemática Cetus, e não um erro no mecanismo de preços do protocolo ou na arquitetura subjacente. Por outro lado, a vulnerabilidade está limitada apenas ao Cetus e não está relacionada ao código do SUI. A raiz da vulnerabilidade está em uma verificação de condição de limite, e apenas duas linhas de código precisam ser modificadas para eliminar completamente o risco; uma vez concluída a reparação, pode ser imediatamente implantada na rede principal, garantindo que a lógica dos contratos subsequentes seja completa e eliminando essa vulnerabilidade.

2. Alta ocultação: O contrato esteve em operação estável sem falhas durante dois anos, o Cetus Protocol passou por várias auditorias, mas as vulnerabilidades não foram encontradas, principalmente porque a biblioteca Integer_Mate utilizada para cálculos matemáticos não foi incluída no escopo da auditoria.

Os hackers utilizam valores extremos para construir com precisão intervalos de negociação, criando cenários extremamente raros que submetem uma liquidez muito alta, o que desencadeia uma lógica anômala, indicando que esse tipo de problema é difícil de detectar por testes comuns. Esses problemas costumam estar em uma zona cega da percepção das pessoas, por isso permanecem ocultos por muito tempo antes de serem descobertos.

3. Não é um problema exclusivo do Move:

Move é superior a várias linguagens de contratos inteligentes em segurança de recursos e verificação de tipos, com detecção nativa de problemas de estouro de inteiros em situações comuns. O estouro ocorreu porque, ao adicionar liquidez, foi utilizado um valor incorreto para a verificação do limite superior ao calcular a quantidade de tokens necessária, e a operação de deslocamento foi usada em vez da multiplicação convencional. Se fossem usados os cálculos convencionais de adição, subtração, multiplicação e divisão, o Move verificaria automaticamente a situação de estouro, evitando esse problema de truncamento de bits altos.

Vulnerabilidades semelhantes também apareceram em outras linguagens (como Solidity e Rust), sendo até mais fáceis de serem exploradas devido à falta de proteção contra estouro de inteiros; antes da atualização da versão do Solidity, a verificação de estouro era muito fraca. Historicamente, ocorreram estouros em adição, subtração e multiplicação, sendo que a causa direta é que o resultado da operação excedeu o intervalo. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas através de parâmetros cuidadosamente construídos, contornando as instruções de verificação no contrato e realizando transferências excessivas para executar ataques.

3. Mecanismo de consenso do SUI

3.1 Introdução ao mecanismo de consenso SUI

Resumo:

SUI adota um quadro de Prova de Participação Delegada (DeleGated Proof of Stake, abreviado DPoS)). Embora o mecanismo DPoS possa aumentar a taxa de transações, ele não consegue oferecer um nível de descentralização tão alto quanto o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, e a barreira de entrada para a governança é relativamente alta, dificultando que usuários comuns influenciem diretamente a governança da rede.

• Número médio de validadores: 106

• Período médio de Epoch: 24 horas

mecanismo de processo:

• Delegação de direitos: Os usuários comuns não precisam executar nós por conta própria, basta que façam a aposta de SUI e deleguem a um validador candidato para participar da garantia de segurança da rede e da distribuição de recompensas. Este mecanismo pode reduzir a barreira de entrada para os usuários comuns, permitindo-lhes participar do consenso da rede através da "contratação" de validadores de confiança. Esta é também uma grande vantagem do DPoS em relação ao PoS tradicional.

• Representar a rodada de blocos: um pequeno número de validadores selecionados gera blocos em uma ordem fixa ou aleatória, aumentando a velocidade de confirmação e melhorando o TPS.

• Eleição dinâmica: Após o término de cada ciclo de contagem de votos, realiza-se uma rotação dinâmica com base no peso do voto, reelecionando o conjunto de Validadores, garantindo a vitalidade dos nós, consistência de interesses e descentralização.

Vantagens do DPoS:

• Alta eficiência: Devido à quantidade controlada de nós de criação de blocos, a rede pode completar a confirmação em milissegundos, satisfazendo a alta demanda de TPS.

• Baixo custo: Menos nós participam do consenso, reduzindo significativamente a largura de banda da rede e os recursos de computação necessários para a sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e operação diminuem, a demanda por poder computacional diminui e o custo é mais baixo. Isso resulta em taxas de usuário mais baixas.

• Alta segurança: os mecanismos de staking e delegação aumentam simultaneamente os custos e riscos de ataques; juntamente com o mecanismo de confisco on-chain, inibem efetivamente comportamentos maliciosos.

Ao mesmo tempo, no mecanismo de consenso do SUI, foi adotado um algoritmo baseado em BFT (tolerância a falhas bizantinas), que exige que mais de dois terços dos votos dos validadores cheguem a um consenso para confirmar a transação. Este mecanismo garante que, mesmo que um pequeno número de nós atue de forma maliciosa, a rede possa manter-se segura e funcionar de forma eficiente. Qualquer atualização ou decisão importante também requer mais de dois terços dos votos para ser implementada.

Essencialmente, o DPoS é uma solução de compromisso para o triângulo impossível, equilibrando descentralização e eficiência. O DPoS, no triângulo "impossível" da segurança-descentralização-escala, opta por reduzir o número de nós ativos de validação em troca de um desempenho mais elevado, abandonando um certo grau de descentralização total em comparação com o PoS puro ou PoW, mas melhorando significativamente a capacidade de processamento da rede e a velocidade das transações.

3.2 O desempenho do SUI neste ataque

3.2.1 Mecanismo de congelamento em operação

Neste evento, a SUI congelou rapidamente os endereços relacionados ao atacante.

Do ponto de vista do código, é impedir que as transações de transferência sejam empacotadas na blockchain. Os nós de validação são os componentes centrais da blockchain SUI, responsáveis por validar transações e executar as regras do protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores equivalem a implementar um mecanismo semelhante ao 'congelamento de conta' no nível de consenso, como no sistema financeiro tradicional.

SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de blacklist que pode impedir qualquer transação que envolva endereços listados. Como essa funcionalidade já existe no cliente, quando um ataque ocorre

SUI pode congelar imediatamente o endereço do hacker. Sem essa funcionalidade, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores um por um em um curto espaço de tempo.

3.2.2 Quem tem o poder de alterar a lista negra?

TransactionDenyConfig é um arquivo de configuração YAML/TOML carregado localmente por cada validador. Qualquer pessoa que execute um nó pode editar este arquivo, recarregá-lo em quente ou reiniciar o nó, e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar seus próprios valores.

Na verdade, para garantir a consistência e a eficácia das políticas de segurança, a atualização dessa configuração crítica é geralmente coordenada. Como se trata de uma "atualização urgente impulsionada pela equipe SUI", basicamente é a fundação SUI (ou os desenvolvedores autorizados por ela) que define e atualiza esta lista de rejeição.

A SUI publicou uma lista negra, teoricamente os validadores podem escolher se a adotam ou não ------ mas na prática, a maioria das pessoas tende a adotá-la automaticamente. Assim, embora esta funcionalidade proteja os fundos dos usuários, ela tem de fato um certo grau de centralização.

3.2.3 A essência da funcionalidade de lista negra

A funcionalidade da lista negra na verdade não é uma lógica de camada de protocolo, mas sim uma camada adicional de segurança para lidar com situações inesperadas, garantindo a segurança dos fundos dos usuários.

É essencialmente um mecanismo de garantia de segurança. Semelhante a uma "corrente de segurança" presa à porta, que é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que pretendem agir de má-fé contra o protocolo. Para o usuário:

• Para os grandes investidores, que são os principais provedores de liquidez, o protocolo é o que mais deseja garantir a segurança dos fundos, pois, na verdade, os dados on-chain tvl são todos contribuídos pelos principais grandes investidores. Para que o protocolo se desenvolva a longo prazo, certamente priorizará a segurança.

• Para os investidores individuais, contribuintes para a atividade ecológica, fortes apoiantes da construção conjunta de tecnologia e comunidade.