Crença firme após a crise de segurança: por que 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 protocolo AMM de destaque Cetus, implantado na rede SUI, sofreu um ataque hacker. Os atacantes exploraram uma falha de lógica relacionada a "problemas de estouro de inteiros", 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 campo 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, e o valor 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% a 97% em apenas uma hora, gerando ampla preocupação no mercado sobre a segurança e a estabilidade do ecossistema 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 na cadeia 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, a construção de infraestrutura e a qualidade dos projetos.

A Klein Labs irá analisar a razão 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 panorama ecológico desta blockchain que ainda está em fase inicial de desenvolvimento e discutindo seu potencial de crescimento 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 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 de preços precisa 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 em três fases principais:

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

Os hackers primeiro usaram o maior slippage para trocar 10 bilhões de haSUI em um empréstimo relâmpago, 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 de serviço, possuindo características de alta alavancagem, baixo risco e baixo custo. Hackers aproveitaram esse mecanismo para reduzir rapidamente o preço do mercado, controlando-o com precisão dentro de uma faixa muito estreita.

Em seguida, o atacante se prepara para criar uma posição de liquidez extremamente estreita, definindo com precisão 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 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, declara a adição de liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.

É essencialmente devido a duas razões:

1. Definição de máscara excessiva: equivale a um limite de adição de liquidez extremamente alto, resultando em que a validação das entradas do usuário no contrato seja praticamente irrelevante. Hackers contornam a detecção de estouro configurando parâmetros anormais, construindo entradas que estão sempre abaixo desse limite.

2. A sobrecarga de dados foi truncada: ao executar a operação de deslocamento n << 64 no 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 superior do estouro 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 inferior a 1, mas como foi arredondado para cima, acabou sendo igual a 1, ou seja, o hacker só precisa adicionar 1 token para conseguir uma enorme liquidez.

③ Retirar liquidez

Realizar o reembolso do empréstimo relâmpago, mantendo lucros substanciais. No final, retirar ativos de tokens no valor total 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 milhões 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 desta vulnerabilidade

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

1. O custo de reparo é extremamente baixo: por um lado, a causa raiz 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á restrita apenas ao Cetus e não tem relação com o código do SUI. A raiz da vulnerabilidade está em uma verificação de condição de limite, e basta 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 seja completa e eliminando essa vulnerabilidade.

2. Alta ocultação: O contrato tem funcionado de forma estável e sem falhas durante dois anos, o Cetus Protocol passou por várias auditorias, mas nenhuma vulnerabilidade foi descoberta, 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 raros de submissão de liquidez extremamente alta, o que aciona lógicas anormais, indicando que esse tipo de problema é difícil de ser detectado por testes comuns. Esses problemas costumam estar em áreas cegas da percepção das pessoas, e por isso permanecem ocultos por muito tempo até 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 situações comuns. Este estouro ocorreu porque, ao adicionar liquidez, ao calcular a quantidade de tokens necessária, foi utilizado inicialmente um valor incorreto para a verificação do limite superior, 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 ou divisão, o Move automaticamente verificaria a situação de estouro, evitando esse problema de truncamento de bits altos.

Vulnerabilidades semelhantes também foram encontradas em outras linguagens (como Solidity, Rust), e até mesmo por sua falta de proteção contra overflow de inteiros, são mais facilmente exploradas; antes da atualização da versão do Solidity, a verificação de overflows era muito fraca. Historicamente, ocorreram overflows de adição, subtração e multiplicação, e a causa direta foi que o resultado da operação ultrapassou 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 atacar.

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 transação, ele não pode 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, tornando difícil para os usuários comuns influenciar diretamente a governança da rede.

• Número médio de validadores: 106

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

Mecanismo de fluxo:

• Delegação de Direitos: Usuários comuns não precisam executar nós por conta própria, basta que façam o staking de SUI e deleguem a validadores candidatos para participar da garantia de segurança da rede e da 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 comparação ao PoS tradicional.

• Representa a rodada de criação de blocos: um pequeno número de validadores escolhidos 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 fim de cada ciclo de contagem de votos, é realizada uma rotação dinâmica, reelecionando o conjunto de Validators com base no peso dos votos, garantindo a vitalidade dos nós, a consistência dos interesses e a descentralização.

Vantagens do DPoS:

• Alta eficiência: Como o número de nós de criação de blocos é controlável, 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 na largura de banda da rede e nos 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ções diminuem, a demanda por poder de computação é reduzida e os custos são mais baixos. Isso resulta em taxas de usuário mais baixas.

• Alta segurança: o mecanismo de staking e delegação aumenta simultaneamente os custos e riscos de ataque; em combinação com o mecanismo de confisco on-chain, inibe efetivamente comportamentos maliciosos.

Ao mesmo tempo, o mecanismo de consenso do SUI utiliza um algoritmo baseado em BFT (tolerância a falhas bizantinas), exigindo que mais de dois terços dos validadores concordem com os votos para confirmar uma transação. Este mecanismo garante que, mesmo que um pequeno número de nós aja de forma maliciosa, 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 escolhe reduzir o número de nós de bloco ativos em troca de um desempenho mais elevado dentro do "triângulo impossível" de segurança-descentralização-escabilidade. Em comparação com o PoS puro ou o PoW, sacrifica um certo grau de descentralização total, mas melhora significativamente a capacidade de processamento da rede e a velocidade das transações.

3.2 O desempenho do SUI nesta 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, impede que as 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 regras de protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores implementam, em um nível de consenso, um mecanismo semelhante ao "congelamento de contas" no sistema financeiro tradicional.

O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de blacklist que pode bloquear 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 a 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, recarregar 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 esta é uma "atualização urgente promovida 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 acaba adotando 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 de lista negra na verdade não é uma lógica de nível de protocolo, é mais como uma camada adicional de segurança para lidar com situações inesperadas e garantir 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é em relação ao protocolo. Para o usuário:

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

• Para os pequenos investidores, contribuidores da atividade ecológica, um forte apoio à construção conjunta de tecnologia e comunidade.