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

TL;DR

1. A vulnerabilidade do Cetus origina-se da implementação do contrato, e não da linguagem SUI ou Move em si:

O ataque em questão baseia-se na falta de verificação de limites nas funções aritméticas do protocolo Cetus - uma vulnerabilidade lógica causada por uma máscara excessivamente ampla e um estouro de deslocamento, que não está relacionada ao modelo de segurança de recursos da cadeia SUI ou da linguagem Move. A vulnerabilidade pode ser corrigida com uma "verificação de limites em uma linha" e não afeta a segurança central de todo o ecossistema.

2. O mecanismo SUI de "centralização razoável" revela valor em tempos de crise:

Embora o SUI tenha uma leve tendência à centralização devido a funções como rodadas de validadores DPoS e congelamento de listas negras, isso se mostrou útil na resposta ao incidente CETUS: os validadores rapidamente sincronizaram endereços maliciosos na Deny List, recusando-se a empacotar transações relacionadas, resultando no congelamento instantâneo de mais de 160 milhões de dólares em fundos. Isso é essencialmente uma forma ativa de "keynesianismo on-chain", onde o controle macroeconômico efetivo desempenha um papel positivo no sistema econômico.

3. Reflexões e sugestões sobre a segurança técnica:

Matemática e validação de limites: Introduzir asserções de limites superiores e inferiores para todas as operações aritméticas críticas (como deslocamento, multiplicação e divisão), e realizar fuzzing de valores extremos e validação formal. Além disso, é necessário aprimorar a auditoria e a monitorização: além da auditoria de código geral, aumentar a equipe de auditoria matemática especializada e a detecção de comportamento de transações em tempo real na blockchain, para capturar precocemente divisões anormais ou grandes empréstimos relâmpago;

4. Resumo e sugestões sobre o mecanismo de garantia de fundos:

No evento Cetus, a SUI colaborou de forma eficiente com a equipe do projeto, congelando com sucesso mais de 160 milhões de dólares em fundos e promovendo um plano de reembolso de 100%, demonstrando uma forte capacidade de resposta em cadeia e um senso de responsabilidade ecológica. A Fundação SUI também adicionou 10 milhões de dólares em fundos para auditoria, reforçando a linha de defesa de segurança. No futuro, poderá avançar ainda mais com sistemas de rastreamento em cadeia, ferramentas de segurança construídas em comunidade, seguros descentralizados e outros mecanismos para aperfeiçoar o sistema de garantia de fundos.

5. A expansão diversificada do ecossistema SUI

SUI conseguiu rapidamente realizar a transição de "nova cadeia" para "ecossistema forte" em menos de dois anos, construindo um ecossistema diversificado que abrange várias faixas, incluindo stablecoins, DEX, infraestrutura, DePIN e jogos. O tamanho total das stablecoins ultrapassou 1 bilhão de dólares, fornecendo uma base sólida de liquidez para o módulo DeFi; o TVL ocupa a 8ª posição global, a atividade de negociação é a 5ª do mundo, e a 3ª entre redes não EVM (apenas atrás do Bitcoin e Solana), demonstrando forte participação dos usuários e capacidade de acumulação de ativos.

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

No dia 22 de maio de 2025, o protocolo AMM de destaque, Cetus, implantado na rede SUI, foi alvo de um ataque hacker. Os atacantes exploraram uma vulnerabilidade lógica relacionada ao "problema de estouro de inteiro", realizando 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 cadeia SUI caiu drasticamente em mais de 330 milhões de dólares no dia do ataque, e o valor bloqueado do protocolo Cetus evaporou instantaneamente em 84%, caindo para 38 milhões de dólares. Com o impacto, vários tokens populares na SUI (incluindo Lofi, Sudeng, Squirtle, entre outros) despencaram de 76% a 97% em apenas uma hora, gerando uma 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 na confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram uma queda contínua, mas, ao contrário, 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á abordar as causas deste incidente de ataque, o mecanismo de consenso dos nós do SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema do SUI, analisando o atual padrão ecológico desta blockchain que ainda se encontra em uma fase inicial de desenvolvimento, e discutir 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 da equipe Slow Mist sobre o 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 espaço de tempo. O caminho do ataque pode ser dividido grosso modo nas seguintes três fases:

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

Os hackers primeiro utilizaram um empréstimo relâmpago de 10 bilhões haSUI com a maior derrapagem, 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, possuindo características de alta alavancagem, baixo risco e baixo custo. Os hackers aproveitaram esse mecanismo para reduzir rapidamente o preço do mercado e controlá-lo com precisão dentro de uma faixa extremamente estreita.

Em seguida, o atacante se preparou para criar uma posição de liquidez extremamente estreita, definindo com precisão a faixa de preços entre a cotação mínima de 300.000 e a cotação máxima de 300.200, com uma largura de preço de apenas 1,00496621%.

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

②Adicionar liquidez

O atacante cria posições de liquidez estreitas, declara adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber 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 grande, levando a uma verificação de entrada do usuário dentro do contrato a ser praticamente inexistente. Hackers definiram parâmetros anômalos, construindo entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.

2. A sobrecarga de dados foi truncada: ao executar a operação de deslocamento n << 64 sobre o valor numérico n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dados uint256 (256 bits). A parte de sobrecarga de bits altos 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, o resultado final foi igual a 1, ou seja, o hacker só precisou adicionar 1 token para obter uma enorme liquidez.

③ Retirar liquidez

Realizar o reembolso do empréstimo relâmpago, mantendo lucros enormes. No final, retirar ativos de tokens de 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:

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

• 6000 milhões de dólares USDC

• 490万美元 Haedal Staked SUI

• 1950万美元 TOILET

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

2.2 A causa e as características da vulnerabilidade desta vez

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

1. Custo de correção extremamente baixo: por um lado, a causa raiz do evento Cetus foi 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 estava restrita apenas ao Cetus, não tendo relação com o código do SUI. A raiz da vulnerabilidade estava em uma verificação de condição de limite, e só era necessário modificar duas linhas de código para eliminar completamente o risco; após a correção, pode ser imediatamente implantada na mainnet, garantindo que a lógica dos contratos subsequentes esteja completa e evitando essa vulnerabilidade.

2. Alta ocultação: o contrato está em operação estável há dois anos sem falhas, o Cetus Protocol passou por várias auditorias, 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 com precisão intervalos de negociação, criando cenários extremamente raros de submissão de liquidez muito alta, que desencadeiam uma lógica anômala, indicando que esse tipo de problema é difícil de ser descoberto por testes normais. 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, incorporando a 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 necessária de tokens, e a operação de deslocamento foi usada em vez da operação de multiplicação convencional. Se fossem utilizadas as operações convencionais de adição, subtração, multiplicação e divisão, o Move verificaria automaticamente as situações de estouro, evitando esse problema de truncamento de bits altos.

Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity, Rust), e eram ainda 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 de adição, estouros de subtração, estouros de multiplicação, sendo a causa direta o fato de que o resultado da operação ultrapassou o limite. 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 efetuar o ataque.

3. O 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 capacidade de transação, ele não pode fornecer um nível tão alto de descentralização como 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, tornando difícil para usuários comuns influenciar diretamente a governança da rede.

• Número médio de validadores: 106

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

Mecanismo de fluxo:

• Delegação de direitos: Usuários comuns não precisam operar nós por conta própria, basta que façam staking de SUI e deleguem a validadores candidatos para participar na garantia da segurança da rede e na distribuição de recompensas. Este mecanismo pode reduzir a barreira de entrada para usuários comuns, permitindo que participem 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.

• Representa o ciclo de blocos: um número reduzido de validadores selecionados cria 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 período de contagem de votos, realiza-se uma rotação dinâmica com base no peso dos votos, reelecionando o conjunto de Validadores, garantindo a vitalidade dos nós, a consistência de interesses e a descentralização.

As vantagens do DPoS:

• Alta eficiência: devido ao número controlável de nós de criação de blocos, a rede pode completar a confirmação em milissegundos, atendendo à alta demanda de TPS.

• Baixo custo: Menos nós participando do consenso resultam em uma redução significativa da largura de banda e dos recursos computacionais necessários para a sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e operação diminuem, os requisitos de poder computacional caem e os custos são mais baixos. Isso resulta em taxas de usuário mais baixas.

• Alta segurança: os mecanismos de staking e delegação amplificam simultaneamente o custo e o risco de ataque; juntamente com o mecanismo de confisco na cadeia, isso efetivamente 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 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 operar de forma eficiente. Para qualquer atualização ou decisão importante, também é necessário que mais de dois terços dos votos sejam obtidos para implementação.

Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, que faz uma troca entre descentralização e eficiência. O DPoS, no triângulo "impossível" de segurança-descentralização-escabilidade, opta por reduzir o número de nós ativos de validação em troca de um desempenho mais alto, em comparação.