Reflexões e renascimento após o incidente de segurança no ecossistema SUI: Análise da vulnerabilidade Cetus e discussão sobre o potencial a longo prazo do SUI.
Fé firme após a crise de segurança: por que o SUI ainda possui potencial de crescimento a longo prazo?
TL;DR
1.O bug do Cetus origina-se da implementação de contrato, e não do SUI ou da linguagem Move em si:
O ataque em questão reside na falta de verificação dos limites das funções aritméticas no 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 seu valor em tempos de crise:
Embora o SUI tenha uma leve tendência à centralização devido a funcionalidades como a rotação de validadores DPoS e a lista negra de congelamento, isso foi útil na resposta ao evento CETUS: os validadores rapidamente sincronizaram endereços maliciosos na Deny List, recusando-se a empacotar transações relacionadas, resultando no congelamento imediato de mais de 160 milhões de dólares em fundos. Isso é essencialmente uma forma ativa de "keynesianismo em cadeia", onde o controle macroeconômico eficaz teve um impacto positivo no sistema econômico.
Reflexões e sugestões sobre a segurança técnica:
Matematica e verificação de limites: introduzir asserções de limites superior e inferior para todas as operações aritméticas críticas (como deslocamento, multiplicação e divisão) e realizar fuzzing de valores extremos e verificação formal. Além disso, é necessário reforçar a auditoria e monitorização: além da auditoria de código geral, aumentar a equipa de auditoria matemática especializada e a deteção em tempo real de comportamentos de transações na cadeia, capturando precocemente divisões anómalas ou grandes empréstimos relâmpago;
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, conseguindo congelar mais de 160 milhões de dólares em fundos e impulsionar 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 de auditoria para reforçar a linha de defesa de segurança. No futuro, pode-se avançar ainda mais na implementação de um sistema de rastreamento em cadeia, ferramentas de segurança construídas em conjunto pela comunidade, seguros descentralizados e outros mecanismos, aprimorando o sistema de proteção de fundos.
A expansão diversificada do ecossistema SUI
SUI rapidamente alcançou a transição de "nova cadeia" para "forte ecossistema" em menos de dois anos, construindo um ecossistema diversificado que abrange várias trilhas, incluindo stablecoins, DEX, infraestrutura, DePIN e jogos. O tamanho total das stablecoins ultrapassou 1 bilhão de dólares, fornecendo uma sólida base de liquidez para o módulo DeFi; o TVL ocupa a 8ª posição mundial, a atividade de negociação é a 5ª a nível global, e é a 3ª entre redes não EVM (apenas atrás do Bitcoin e Solana), mostrando uma forte participação dos usuários e capacidade de sedimentação de ativos.
1.Uma reação em cadeia provocada por um ataque.
No dia 22 de maio de 2025, o protocolo AMM líder Cetus, implantado na rede SUI, sofreu um ataque hacker. Os atacantes exploraram uma falha lógica relacionada a um "problema de estouro de inteiro", realizando uma manipulação precisa que resultou na perda de mais de 200 milhões de dólares em ativos. Este evento 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 devastador desde o lançamento da mainnet SUI.
De acordo com os dados da DefiLlama, 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 em 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI (incluindo Lofi, Sudeng, Squirtle, entre outros) caíram entre 76% e 97% em apenas uma hora, provocando 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 grande 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 recessão contínua, mas sim impulsionaram 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 incidente de ataque, o mecanismo de consenso dos nós SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema SUI, organizando o atual padrão ecológico desta blockchain que ainda está em estágio inicial de desenvolvimento, e discutir o seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque Cetus
2.1 Processo de implementação de ataque
De acordo com a análise técnica da equipe Slow Mist sobre o incidente de ataque a 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 para roubar 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 preços
Os hackers primeiro utilizaram um empréstimo relâmpago de 10 bilhões de haSUI com o maior deslizamento, emprestando uma grande quantidade de fundos para manipulação de preços.
O empréstimo relâmpago permite que os usuários peçam emprestado e devolvam fundos na mesma transação, pagando apenas uma taxa, apresentando características de alta alavancagem, baixo risco e baixo custo. Hackers aproveitaram esse mecanismo para reduzir rapidamente o preço do mercado e mantê-lo precisamente controlado em uma faixa muito estreita.
Em seguida, o atacante se prepara para criar uma posição de liquidez extremamente estreita, definindo precisamente a faixa de preço entre a menor cotação de 300,000 e a maior 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
Um 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.
Basicamente, isso se deve a duas razões:
O limite de máscara está muito largo: equivale a um limite de adição de liquidez extremamente grande, resultando em uma validação de entrada do usuário no contrato que é praticamente inexistente. Os hackers, ao definirem parâmetros anômalos, constroem entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.
Dados de transbordamento foram truncados: ao executar a operação de deslocamento n << 64 em um valor numérico n, ocorreu truncamento de dados devido ao deslocamento ultrapassar a largura efetiva do tipo de dados uint256 (256 bits). A parte de transbordamento alta 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 aproximadamente inferior a 1, mas como foi arredondado para cima, o resultado final foi igual a 1, ou seja, o hacker só precisa adicionar 1 token para poder trocar por uma enorme liquidez.
③ Retirar liquidez
Realizar o reembolso do empréstimo relâmpago, mantendo lucros substanciais. No final, retirar ativos de token 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万美元USDC
490 milhões de dólares Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, com liquidez esgotada.
2.2 Causas e características da vulnerabilidade
A falha do Cetus possui três características:
Custo de reparo extremamente baixo: por um lado, a causa fundamental do incidente Cetus foi uma falha na biblioteca matemática do Cetus, e não um erro no mecanismo de preços do protocolo ou um erro na arquitetura subjacente. Por outro lado, a vulnerabilidade está limitada 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 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 do contrato subsequente esteja completa e eliminando essa vulnerabilidade.
Alta ocultação: o contrato opera de forma estável e sem falhas há dois anos, o Cetus Protocol passou por várias auditorias, mas nenhuma vulnerabilidade foi encontrada, sendo a principal razão o fato de a biblioteca Integer_Mate, utilizada para cálculos matemáticos, não ter sido 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, que apenas acionam lógicas anómalas, indicando que esse tipo de problema é difícil de detectar através de testes comuns. Esses problemas costumam estar em áreas de sombra na percepção das pessoas, por isso permanecem ocultos por muito tempo antes de serem descobertos.
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ções nativas para 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 a situação de estouro, evitando esse problema de truncamento de bits altos.
Vulnerabilidades semelhantes também surgiram em outras linguagens (como Solidity, Rust) e eram ainda mais suscetíveis a serem exploradas devido à falta de proteção contra estouro de inteiros; antes das atualizações 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, etc., e a causa direta foi 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 declarações de verificação no contrato, 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 transações, ele não consegue oferecer o mesmo nível de descentralização que a PoW (Prova de Trabalho). Portanto, o grau de descentralização da SUI é relativamente baixo, com um limiar de governança relativamente alto, tornando difícil para 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 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 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.
Representar rodadas de blocos: um pequeno número de validadores escolhidos gera blocos em uma ordem fixa ou aleatória, aumentando a velocidade de confirmação e melhorando o TPS.
Eleições dinâmicas: Após o término de cada ciclo 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.
Vantagens do DPoS:
Alta eficiência: devido ao número controlável de nós de produçã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 na largura de banda da rede e nos 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, e a demanda por poder de computação é reduzida, resultando em custos mais baixos. Por fim, isso alcança taxas de usuário mais baixas.
Alta segurança: 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 aja de maneira maliciosa, a rede pode 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 a implementação.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, fazendo um equilíbrio 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 produção de blocos em troca de um desempenho superior, 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 funcionamento
Neste evento, a SUI rapidamente congelou os endereços relacionados aos atacantes.
Do ponto de vista do código, isso impede que as transações de transferência sejam empacotadas na cadeia. Os nós de verificação são os componentes centrais da blockchain SUI, responsáveis por validar transações e executar as regras do protocolo.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
14 Curtidas
Recompensa
14
6
Repostar
Compartilhar
Comentário
0/400
RugResistant
· 1h atrás
apenas mais um erro de contrato smh... a movimentação é sólida af ngl
Ver originalResponder0
MEVEye
· 8h atrás
Menos conversa, já estou quase com a faca na mão.
Ver originalResponder0
LiquiditySurfer
· 17h atrás
A Surf Dog pode se divertir à vontade, mas não pode evitar as armadilhas de um ecossistema maduro.
Ver originalResponder0
DAOdreamer
· 17h atrás
SUI é sempre um deus!
Ver originalResponder0
CommunityLurker
· 18h atrás
O contrato não deveria ser responsabilidade do sui.
Ver originalResponder0
DegenRecoveryGroup
· 18h atrás
Isso nem precisa ser dito? A descentralização do sui não tem nada de ruim, sempre há uma razão para as coisas.
Reflexões e renascimento após o incidente de segurança no ecossistema SUI: Análise da vulnerabilidade Cetus e discussão sobre o potencial a longo prazo do SUI.
Fé firme após a crise de segurança: por que o SUI ainda possui potencial de crescimento a longo prazo?
TL;DR
1.O bug do Cetus origina-se da implementação de contrato, e não do SUI ou da linguagem Move em si:
O ataque em questão reside na falta de verificação dos limites das funções aritméticas no 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 seu valor em tempos de crise:
Embora o SUI tenha uma leve tendência à centralização devido a funcionalidades como a rotação de validadores DPoS e a lista negra de congelamento, isso foi útil na resposta ao evento CETUS: os validadores rapidamente sincronizaram endereços maliciosos na Deny List, recusando-se a empacotar transações relacionadas, resultando no congelamento imediato de mais de 160 milhões de dólares em fundos. Isso é essencialmente uma forma ativa de "keynesianismo em cadeia", onde o controle macroeconômico eficaz teve um impacto positivo no sistema econômico.
Matematica e verificação de limites: introduzir asserções de limites superior e inferior para todas as operações aritméticas críticas (como deslocamento, multiplicação e divisão) e realizar fuzzing de valores extremos e verificação formal. Além disso, é necessário reforçar a auditoria e monitorização: além da auditoria de código geral, aumentar a equipa de auditoria matemática especializada e a deteção em tempo real de comportamentos de transações na cadeia, capturando precocemente divisões anómalas ou grandes empréstimos relâmpago;
No evento Cetus, a SUI colaborou de forma eficiente com a equipe do projeto, conseguindo congelar mais de 160 milhões de dólares em fundos e impulsionar 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 de auditoria para reforçar a linha de defesa de segurança. No futuro, pode-se avançar ainda mais na implementação de um sistema de rastreamento em cadeia, ferramentas de segurança construídas em conjunto pela comunidade, seguros descentralizados e outros mecanismos, aprimorando o sistema de proteção de fundos.
SUI rapidamente alcançou a transição de "nova cadeia" para "forte ecossistema" em menos de dois anos, construindo um ecossistema diversificado que abrange várias trilhas, incluindo stablecoins, DEX, infraestrutura, DePIN e jogos. O tamanho total das stablecoins ultrapassou 1 bilhão de dólares, fornecendo uma sólida base de liquidez para o módulo DeFi; o TVL ocupa a 8ª posição mundial, a atividade de negociação é a 5ª a nível global, e é a 3ª entre redes não EVM (apenas atrás do Bitcoin e Solana), mostrando uma forte participação dos usuários e capacidade de sedimentação de ativos.
1.Uma reação em cadeia provocada por um ataque.
No dia 22 de maio de 2025, o protocolo AMM líder Cetus, implantado na rede SUI, sofreu um ataque hacker. Os atacantes exploraram uma falha lógica relacionada a um "problema de estouro de inteiro", realizando uma manipulação precisa que resultou na perda de mais de 200 milhões de dólares em ativos. Este evento 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 devastador desde o lançamento da mainnet SUI.
De acordo com os dados da DefiLlama, 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 em 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI (incluindo Lofi, Sudeng, Squirtle, entre outros) caíram entre 76% e 97% em apenas uma hora, provocando 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 grande 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 recessão contínua, mas sim impulsionaram 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 incidente de ataque, o mecanismo de consenso dos nós SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema SUI, organizando o atual padrão ecológico desta blockchain que ainda está em estágio inicial de desenvolvimento, e discutir o seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque Cetus
2.1 Processo de implementação de ataque
De acordo com a análise técnica da equipe Slow Mist sobre o incidente de ataque a 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 para roubar 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 preços
Os hackers primeiro utilizaram um empréstimo relâmpago de 10 bilhões de haSUI com o maior deslizamento, emprestando uma grande quantidade de fundos para manipulação de preços.
O empréstimo relâmpago permite que os usuários peçam emprestado e devolvam fundos na mesma transação, pagando apenas uma taxa, apresentando características de alta alavancagem, baixo risco e baixo custo. Hackers aproveitaram esse mecanismo para reduzir rapidamente o preço do mercado e mantê-lo precisamente controlado em uma faixa muito estreita.
Em seguida, o atacante se prepara para criar uma posição de liquidez extremamente estreita, definindo precisamente a faixa de preço entre a menor cotação de 300,000 e a maior 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
Um 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.
Basicamente, isso se deve a duas razões:
O limite de máscara está muito largo: equivale a um limite de adição de liquidez extremamente grande, resultando em uma validação de entrada do usuário no contrato que é praticamente inexistente. Os hackers, ao definirem parâmetros anômalos, constroem entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.
Dados de transbordamento foram truncados: ao executar a operação de deslocamento n << 64 em um valor numérico n, ocorreu truncamento de dados devido ao deslocamento ultrapassar a largura efetiva do tipo de dados uint256 (256 bits). A parte de transbordamento alta 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 aproximadamente inferior a 1, mas como foi arredondado para cima, o resultado final foi igual a 1, ou seja, o hacker só precisa adicionar 1 token para poder trocar por uma enorme liquidez.
③ Retirar liquidez
Realizar o reembolso do empréstimo relâmpago, mantendo lucros substanciais. No final, retirar ativos de token 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万美元USDC
490 milhões de dólares Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, com liquidez esgotada.
2.2 Causas e características da vulnerabilidade
A falha do Cetus possui três características:
Custo de reparo extremamente baixo: por um lado, a causa fundamental do incidente Cetus foi uma falha na biblioteca matemática do Cetus, e não um erro no mecanismo de preços do protocolo ou um erro na arquitetura subjacente. Por outro lado, a vulnerabilidade está limitada 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 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 do contrato subsequente esteja completa e eliminando essa vulnerabilidade.
Alta ocultação: o contrato opera de forma estável e sem falhas há dois anos, o Cetus Protocol passou por várias auditorias, mas nenhuma vulnerabilidade foi encontrada, sendo a principal razão o fato de a biblioteca Integer_Mate, utilizada para cálculos matemáticos, não ter sido 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, que apenas acionam lógicas anómalas, indicando que esse tipo de problema é difícil de detectar através de testes comuns. Esses problemas costumam estar em áreas de sombra na percepção das pessoas, por isso permanecem ocultos por muito tempo antes de serem descobertos.
Move é superior a várias linguagens de contratos inteligentes em segurança de recursos e verificação de tipos, incorporando detecções nativas para 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 a situação de estouro, evitando esse problema de truncamento de bits altos.
Vulnerabilidades semelhantes também surgiram em outras linguagens (como Solidity, Rust) e eram ainda mais suscetíveis a serem exploradas devido à falta de proteção contra estouro de inteiros; antes das atualizações 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, etc., e a causa direta foi 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 declarações de verificação no contrato, 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 transações, ele não consegue oferecer o mesmo nível de descentralização que a PoW (Prova de Trabalho). Portanto, o grau de descentralização da SUI é relativamente baixo, com um limiar de governança relativamente alto, tornando difícil para 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 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 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.
Representar rodadas de blocos: um pequeno número de validadores escolhidos gera blocos em uma ordem fixa ou aleatória, aumentando a velocidade de confirmação e melhorando o TPS.
Eleições dinâmicas: Após o término de cada ciclo 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.
Vantagens do DPoS:
Alta eficiência: devido ao número controlável de nós de produçã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 na largura de banda da rede e nos 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, e a demanda por poder de computação é reduzida, resultando em custos mais baixos. Por fim, isso alcança taxas de usuário mais baixas.
Alta segurança: 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 aja de maneira maliciosa, a rede pode 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 a implementação.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, fazendo um equilíbrio 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 produção de blocos em troca de um desempenho superior, 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 funcionamento
Neste evento, a SUI rapidamente congelou os endereços relacionados aos atacantes.
Do ponto de vista do código, isso impede que as transações de transferência sejam empacotadas na cadeia. Os nós de verificação são os componentes centrais da blockchain SUI, responsáveis por validar transações e executar as regras do protocolo.