A fé firme após a crise de segurança: por que SUI ainda possui 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 hacker. O atacante explorou uma falha lógica relacionada ao "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 setor DeFi até agora este ano, mas também se tornou o ataque hacker mais devastador desde o lançamento da rede principal SUI.

De acordo com os dados, o TVL total da cadeia SUI caiu mais de 330 milhões de dólares no dia do ataque, e o montante bloqueado do 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% e 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. Apesar do evento Cetus ter trazido flutuações de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram uma recessão prolongada, mas sim incentivaram todo o ecossistema a aumentar significativamente a atenção à segurança, à construção de infraestrutura e à qualidade dos projetos.

Vamos analisar as razões por trás deste ataque, o mecanismo de consenso dos nós SUI, a segurança da linguagem MOVE e o desenvolvimento ecológico do SUI, organizando o atual padrão ecológico desta blockchain que ainda está em fase inicial de desenvolvimento e discutindo seu potencial de desenvolvimento futuro.

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

2.1 Processo de implementação do ataque

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

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

Os hackers primeiro utilizaram uma troca flash com um deslizamento máximo de 100 bilhões de haSUI através de um empréstimo relâmpago, emprestando grandes quantidades de fundos para manipulação de preços.

Os empréstimos relâmpago permitem que os usuários peçam emprestado e devolvam fundos na mesma transação, pagando apenas uma taxa de serviço, apresentando características de alta alavancagem, baixo risco e baixo custo. Hackers exploraram este mecanismo para baixar rapidamente os preços de mercado e controlá-los com precisão dentro de uma faixa extremamente estreita.

Em seguida, o atacante se prepara para criar uma posição de liquidez extremamente estreita, definindo precisamente a faixa de preços entre a menor oferta de 300,000 e o preço mais alto de 300,200, com uma largura de preço de apenas 1.00496621%.

Através da forma acima, os hackers utilizaram uma quantidade suficientemente grande 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, declara a adição de 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, resultando em uma verificação dos inputs dos usuários que é praticamente nula. Hackers conseguem contornar a verificação de estouro ao configurar parâmetros anormais, fazendo com que a entrada esteja sempre abaixo desse limite.

2. Dados de overflow foram truncados: ao executar a operação de deslocamento n << 64 sobre o valor n, devido ao deslocamento exceder a largura efetiva do tipo de dado uint256 (256 bits), ocorreu a truncagem dos dados. A parte de overflow mais alta foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, levando o sistema a subestimar 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 uma enorme liquidez.

③ Retirar liquidez

Realizar o reembolso do empréstimo relâmpago, mantendo lucros maciços. No final, retirar um total de ativos de tokens no valor de 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:

• 12,9 milhões de SUI (aproximadamente $54 milhões)

• 6000万美元USDC

• 490万美元Haedal Staked SUI

• 1950万美元TOILET

• Outras moedas como HIPPO e LOFI caíram 75-80%, a liquidez esgotou.

2.2 Causas e características da vulnerabilidade desta vez

A falha do Cetus tem três características:

1. O custo de reparação é extremamente baixo: por um lado, a causa raiz do incidente Cetus é uma falha na biblioteca matemática do Cetus, e não um erro no mecanismo de preços do protocolo ou uma falha na arquitetura subjacente. Por outro lado, a vulnerabilidade limita-se apenas ao Cetus e não tem relação com o código do SUI. A origem da falha reside numa verificação de condição de limite, sendo necessário apenas modificar duas linhas de código para eliminar completamente o risco; uma vez concluída a reparação, pode ser imediatamente implantada na mainnet, garantindo que a lógica dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.

2. Alta ocultação: o contrato está em funcionamento estável há dois anos sem falhas, tendo sido auditado várias vezes, mas as vulnerabilidades não foram descobertas, 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 precisamente intervalos de negociação, criando cenários extremamente raros de submissão de alta liquidez, que desencadeiam lógicas anómalas, indicando que esse tipo de problema é difícil de detectar através de testes normais. Esses problemas costumam estar em áreas cegas da percepção das pessoas, por isso demoram a ser 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, incorporando detecção nativa de problemas de estouro de inteiros em cenários 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 operação de multiplicação convencional. Se fossem usadas operações 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 ocorreram em outras linguagens (como Solidity e Rust), e até mesmo por falta de proteção contra estouro de inteiros, tornando-as mais suscetíveis a exploração; antes da atualização da versão do Solidity, a verificação de estouros era muito fraca. Historicamente, ocorreram estouros de adição, estouros de subtração, estouros de multiplicação, etc., com a causa direta sendo que o resultado da operação ultrapassou o limite. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity conseguiram contornar as instruções de verificação no contrato por meio de parâmetros cuidadosamente construídos, permitindo transferências excessivas para realizar ataques.

3. Mecanismo de consenso do SUI

3.1 Introdução ao mecanismo de consenso SUI

Resumo:

SUI adota uma estrutura de Prova de Participação Delegada (DeleGated Proof of Stake, abreviada para DPoS)). Embora o mecanismo DPoS possa aumentar a capacidade de processamento de transações, não consegue fornecer 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

• Epoch médio: 24 horas

Mecanismo de fluxo:

• Delegação de direitos: Os usuários comuns não precisam executar nós por conta própria, basta que façam a 'subida' do 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 o ciclo de blocos: um pequeno número de validadores selecionados produzem 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, a rotação dinâmica é realizada com base no peso dos votos, reelecionando o conjunto de Validators, garantindo a vitalidade dos nós, a consistência de interesses e a descentralização.

Vantagens do DPoS:

• Alta eficiência: Devido ao controle do número de nós de geração de blocos, a rede pode completar a confirmação em milissegundos, atendendo à demanda de alta TPS.

• Baixo custo: Menos nós participando do consenso resultam em uma redução significativa na largura de banda de rede e nos recursos computacionais necessários para a sincronização de informações e agregação de assinaturas. Isso reduz os custos de hardware e de operação, diminui a demanda por capacidade computacional e, consequentemente, os custos são mais baixos. Isso resulta em taxas de transação mais baixas para os usuários.

• Alta segurança: o mecanismo de staking e delegação amplifica o custo e o risco de ataques; juntamente com o mecanismo de confisco on-chain, eficazmente inibe 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 concordem para confirmar uma transação. Este mecanismo garante que mesmo que alguns nós se comportem mal, a rede possa manter uma operação segura e eficiente. Qualquer atualização ou decisão importante também requer mais de dois terços dos votos para ser implementada.

Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, equilibrando descentralização e eficiência. O DPoS opta por reduzir o número de nós de bloqueio ativo em troca de maior desempenho dentro do "triângulo impossível" de segurança-descentralização-escalabilidade, sacrificando um certo grau de descentralização total em comparação com PoS puro ou PoW, mas aumentando 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, o SUI rapidamente congelou os endereços relacionados ao atacante.

Do ponto de vista do código, isso impede que transações de transferência sejam empacotadas na cadeia. Os nós de validação são 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 estão, em essência, implementando um mecanismo semelhante ao 'congelamento de contas' no nível de consenso, como na financeira tradicional.

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

SUI pode congelar imediatamente o endereço do hacker. Se não houvesse esta funcionalidade, mesmo que o SUI tivesse apenas 113 validadores, seria difícil coordenar todos os validadores para responder um a um em um curto período 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 a consistência e eficácia da política de segurança, a atualização dessa configuração crítica é geralmente coordenada. Como se trata de uma "atualização de emergência forçada", basicamente é a fundação (ou os desenvolvedores autorizados por ela) que define e atualiza esta lista de rejeição.

SUI publica uma lista negra, teoricamente os validadores podem escolher se adotam ou não ------ mas na prática a maioria das pessoas automaticamente a adota. Portanto, embora esta funcionalidade proteja os fundos dos usuários, na essência tem um certo grau de centralização.

3.2.3 A essência da funcionalidade de lista negra

A funcionalidade de lista negra na verdade não é uma lógica de baixo nível do protocolo, mas sim uma camada adicional de segurança para lidar com situações inesperadas, garantindo a segurança dos fundos dos utilizadores.

É essencialmente um mecanismo de garantia de segurança. Semelhante a uma "cadeado de segurança" preso à porta, é ativado apenas para aqueles que tentam invadir a casa, ou seja, para aqueles que querem prejudicar 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, deve priorizar a segurança.

• Para os investidores de varejo, contribuidores da atividade ecológica, fortes apoiadores da construção conjunta de tecnologia e comunidade. A equipe do projeto também espera atrair investidores de varejo para co-construir, assim poderá gradualmente aperfeiçoar a ecologia e aumentar a retenção.