Crença 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. Os atacantes exploraram uma falha lógica relacionada a um "problema de estouro de inteiro" para realizar uma manipulação precisa, resultando em perdas superiores a 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 mais de 330 milhões de dólares no dia do ataque, com o montante bloqueado no protocolo Cetus a evaporar instantaneamente 84%, caindo para 38 milhões de dólares. Devido a isso, vários tokens populares na SUI caíram entre 76% e 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. Embora o evento Cetus tenha trazido flutuações de confiança a curto prazo, os fundos em cadeia e a atividade dos usuários não sofreram uma queda persistente, mas, ao contrário, impulsionaram uma atenção significativamente maior em todo o ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.

A Klein Labs irá abordar as causas deste ataque, o mecanismo de consenso de nós da SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema da SUI, analisando o atual ecossistema desta blockchain que ainda está em estágio 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 de ataque

De acordo com a análise técnica do incidente de ataque Cetus pela equipe Slow Mist, 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 o preço

Os hackers primeiro aproveitaram a maior slippage para fazer um empréstimo relâmpago de 10 bilhões de haSUI, emprestando uma grande quantidade de fundos para manipular os 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 este mecanismo para reduzir rapidamente o preço do mercado e controlá-lo com precisão dentro de um intervalo muito estreito.

Em seguida, o atacante se preparou para criar uma posição de liquidez extremamente estreita, definindo o intervalo de preços com precisão entre a oferta mais baixa 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 conseguiram manipular o preço do haSUI utilizando uma quantidade suficiente de tokens e uma enorme liquidez. Em seguida, eles também manipularam vários 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.

Na essência, é devido a duas razões:

1. Configuração de máscara excessivamente ampla: equivale a um limite máximo de adição de liquidez muito grande, fazendo com que a validação das entradas dos usuários no contrato seja praticamente inútil. Hackers, ao definir parâmetros anômalos, constroem entradas que estão sempre abaixo desse limite, contornando assim a detecção de overflow.

2. A sobrecarga de dados foi truncada: ao executar a operação de deslocamento n << 64 em um valor n, devido ao deslocamento exceder a largura efetiva do tipo de dados uint256 (256 bits), ocorreu uma truncagem de dados. A parte de overflow mais alta foi automaticamente descartada, resultando em um resultado de cálculo muito inferior ao 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, o resultado final ficou 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 substanciais. Por fim, retirar ativos em 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:

• 1290 mil SUI (cerca de 5400 mil dólares)

• 6000万美元USDC

• 490万美元 Haedal Staked SUI

• 1950万美元TOILET

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

2.2 A causa e características da vulnerabilidade desta vez

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

1. O custo de reparação é extremamente baixo: por um lado, a causa raiz do incidente 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 está restrita apenas ao Cetus, não tendo relação com o código 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; após a correçã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 operação há dois anos de forma estável e sem falhas. O Cetus Protocol passou por várias auditorias, mas nenhuma vulnerabilidade foi encontrada, principalmente porque a biblioteca Integer_Mate, usada para cálculos matemáticos, não foi incluída no escopo da auditoria.

Hackers use extreme values to precisely construct trading intervals, creating extremely rare scenarios with very high liquidity that trigger abnormal logic, indicating that such issues are difficult to discover through ordinary testing. These types of problems often lie in blind spots within people's vision, which is why they remain hidden for so long before being discovered.

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, foi utilizado um valor incorreto para a verificação de 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 utilizados as operações aritméticas 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, Rust), e eram até mais fáceis de explorar devido à falta de proteção contra overflow de inteiros; antes das atualizações da versão do Solidity, a verificação de overflow era muito fraca. Historicamente, ocorreram overflows de adição, subtração e multiplicação, sendo que a causa direta foi sempre porque 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 atacar.

3. Mecanismo de consenso do SUI

3.1 Introdução ao mecanismo de consenso SUI

Resumo:

SUI adota a estrutura de Prova de Participação Delegada (DeleGated Proof of Stake, abreviada como DPoS). Embora o mecanismo DPoS possa aumentar a capacidade de transações, 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, tornando difícil para os usuários comuns influenciarem 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: os usuários comuns não precisam executar nós por conta própria, basta que realizem o staking de SUI e deleguem a um validador candidato para participar da garantia de segurança da rede e da distribuição de recompensas. Esse mecanismo pode reduzir a barreira de entrada para usuários comuns, permitindo que participem do consenso da rede "contratando" validadores de confiança. Esta é uma das grandes vantagens do DPoS em comparação com o PoS tradicional.

• Representa a rodada de blocos: um número reduzido 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, realizar uma rotação dinâmica com base no peso dos votos, reeleger o conjunto de Validadores, garantindo a vitalidade dos nós, a consistência dos interesses e a descentralização.

Vantagens do DPoS:

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

• Baixo custo: menos nós participando do consenso, reduzindo significativamente a largura de banda da rede e os recursos computacionais necessários para a sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e manutenção diminuem, a exigência de poder computacional diminui e os custos são mais baixos. No final, resulta em taxas de usuário mais baixas.

• Alta segurança: os mecanismos de staking e delegação aumentam em sincronia os custos e riscos de ataques; juntamente com o mecanismo de apreensão 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 entre os validadores concordem para confirmar uma transação. Este mecanismo assegura que mesmo que um pequeno número de nós atue de forma maliciosa, a rede pode manter operações seguras e eficientes. Para realizar qualquer atualização ou decisão importante, também é necessário que mais de dois terços dos votos sejam alcançados para a implementação.

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 ativos de blocos para obter um desempenho mais alto no "triângulo impossível" da segurança-descentralização-escabilidade, sacrificando um certo grau de descentralização completa em comparação com o PoS puro ou PoW, mas melhorando significativamente a taxa de transferência 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 congelou rapidamente os endereços relacionados ao atacante.

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

O SUI possui uma mecânica de lista de rejeição (deny list) embutida, que é uma funcionalidade de lista negra que pode bloquear qualquer transação envolvendo endereços listados. Como essa funcionalidade já existe no cliente, quando um ataque ocorre,

SUI pode congelar imediatamente o endereço do hacker. Se não houver 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 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 tempo real 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 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 lançou uma lista negra, teoricamente os validadores podem escolher se a utilizam ------ mas na prática a maioria das pessoas acaba por adotá-la automaticamente. Portanto, embora esta funcionalidade proteja os fundos dos usuários, na sua essência tem realmente um certo grau de centralização.

A essência da funcionalidade da lista negra 3.2.3

A funcionalidade de lista negra na verdade não é uma lógica de nível de protocolo, mas sim 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 "cadeia de segurança" presa à porta, é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem agir maliciosamente em relação ao protocolo. Para o usuário:

• Para grandes investidores, 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 por grandes investidores. Para que o protocolo se desenvolva a longo prazo, certamente priorizará a segurança.

• Para os investidores individuais, contribuidores da atividade do ecossistema e fortes apoiantes da construção conjunta de tecnologia e comunidade. O projeto também espera atrair investidores individuais para a construção conjunta.