Fé firme após a crise de segurança: por que o SUI ainda tem potencial para subir a longo prazo?
TL;DR
A vulnerabilidade do Cetus origina-se da implementação do contrato, e não da linguagem SUI ou Move em si:
O ataque desta vez baseia-se na falta de verificação de limites nas funções aritméticas do protocolo Cetus------vulnerabilidades lógicas causadas por uma máscara muito ampla e estouro de deslocamento, que não têm relação com o 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.
O "centralismo razoável" no mecanismo SUI revela seu 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 foi exatamente ú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 instantâneo de mais de 160 milhões de dólares em fundos. Isso é essencialmente uma forma ativa de "keynesianismo on-chain", onde um controle macroeconômico eficaz teve um efeito positivo sobre o sistema econômico.
Reflexões e sugestões sobre a segurança técnica:
Matemática e verificação de limites: introduzir afirmaçõ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 validação formal. Além disso, é necessário reforçar a auditoria e monitorização: além da auditoria de código geral, incluir uma equipe de auditoria matemática especializada e detecção em tempo real de comportamentos de transações on-chain, para capturar precocemente divisões anormais 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 promovendo um plano de reembolso de 100%, demonstrando uma forte capacidade de resposta em cadeia e responsabilidade ecológica. A Fundação SUI também adicionou 10 milhões de dólares em fundos de auditoria, reforçando a linha de segurança. No futuro, pode-se avançar ainda mais na implementação de sistemas de rastreamento em cadeia, ferramentas de segurança construídas pela comunidade, seguros descentralizados e outros mecanismos, aprimorando o sistema de proteção de fundos.
A múltipla expansão do ecossistema SUI
SUI conseguiu rapidamente realizar uma transição de "nova cadeia" para "forte ecossistema" em menos de dois anos, construindo um diversificado mapa ecológico que abrange várias áreas, incluindo stablecoins, DEX, infraestrutura, DePIN e jogos. O tamanho total das stablecoins ultrapassou 1 bilhão de dólares, proporcionando 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ª global, e é a 3ª entre as redes não EVM (apenas atrás do Bitcoin e Solana), demonstrando uma 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 principal protocolo AMM Cetus, implantado na rede SUI, sofreu um ataque de hackers. Os atacantes exploraram uma vulnerabilidade lógica relacionada a um "problema 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 espaço DeFi até agora este ano, mas também se tornou o ataque hacker mais destrutivo desde o lançamento da mainnet da 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, 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, etc.) caíram entre 76% e 97% em apenas uma hora, gerando uma ampla preocupação do 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 on-chain e a atividade dos usuários não sofreram uma queda contínua, mas, ao contrário, 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 ecológico do SUI, organizando o atual panorama ecológico desta blockchain que ainda se encontra em fase inicial de desenvolvimento, e discutirá seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque 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 de preços precisa 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 preços
Os hackers primeiro utilizam a maior slippage para realizar um empréstimo relâmpago de 10 bilhões de haSUI, 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 exploraram esse mecanismo para baixar rapidamente o preço do mercado e controlá-lo 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 o intervalo de preços com precisão 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 usaram 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 adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba recebendo apenas 1 token.
Essencialmente, isso se deve a duas razões:
Configuração de máscara excessivamente ampla: equivale a um limite máximo de adição de liquidez extremamente grande, resultando em validações de entrada do usuário no contrato que são praticamente ineficazes. Hackers configuraram parâmetros anormais, construindo entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.
O estouro de dados foi truncado: ao executar a operação de deslocamento n << 64 em um valor numérico n, ocorreu truncamento de dados devido ao deslocamento exceder a largura efetiva do tipo de dados uint256 (256 bits). A parte de estouro 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 ficou cerca de 1 a menos, mas como foi arredondado para cima, no final resultou em 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. No final, retirar ativos de tokens no valor total de centenas de milhões de dólares de vários 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
4,9 milhões de dólares Haedal Staked SUI
1950万美元 TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, liquidez esgotada
2.2 Causas e características da vulnerabilidade desta vez
A falha do Cetus tem três características:
Custo de reparação 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 origem da vulnerabilidade está em uma verificação de condição de limite, que pode ser completamente eliminada com a modificação de duas linhas de código; após a reparação, pode ser imediatamente implantada na rede principal, garantindo que a lógica dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.
Alta ocultação: O contrato funcionou de forma estável e sem falhas durante dois anos, 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 muito raros de submissão de liquidez extremamente alta, que desencadeiam uma lógica anômala, indicando que esses problemas são difíceis de detectar através de testes comuns. Esses problemas muitas vezes ficam em uma zona cega na visão das pessoas, por isso foram descobertos após muito tempo.
Não é um problema exclusivo do Move:
Move é superior a várias linguagens de contratos inteligentes em termos de segurança de recursos e verificação de tipos, com detecção nativa de problemas de estouro de inteiros em cenários comuns. Este 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 as operações de adição, subtração, multiplicação e divisão convencionais fossem usadas, 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, devido à falta de proteção contra estouro de inteiros, eram ainda mais fáceis de serem exploradas; 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, 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 por meio de parâmetros cuidadosamente elaborados, contornando as instruções de verificação no contrato e realizando transferências excessivas para efetuar ataques.
3. Mecanismo de consenso 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 taxa 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 impactem diretamente a governança da rede.
Número médio de validadores: 106
Média do ciclo Epoch: 24 horas
Processo mecânico:
Delegação de Direitos: usuários comuns não precisam executar nós por conta própria, basta que façam staking de SUI e deleguem a validadores candidatos para participar da garantia de 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 "contratando" validadores de confiança. Esta também é uma grande vantagem do DPoS em relação ao PoS tradicional.
Representar a rodada de blocos: um pequeno número 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, realiza-se uma rotação dinâmica e uma nova eleição do conjunto de Validadores, com base no peso dos votos, garantindo a vitalidade dos nós, a consistência de interesses e a descentralização.
Vantagens do DPoS:
Alta eficiência: Devido à quantidade controlável de nós de blocos, a rede pode completar a confirmação em milissegundos, atendendo à alta demanda de TPS.
Baixo custo: Menos nós participando do consenso, a largura de banda da rede e os recursos computacionais necessários para a sincronização de informações e agregação de assinaturas são significativamente reduzidos. Assim, os custos de hardware e operação diminuem, a exigência de poder de computação diminui, resultando em custos mais baixos. Isso leva a taxas de usuário mais baixas.
Alta segurança: O mecanismo de staking e delegação amplifica simultaneamente os custos e os riscos de ataque; combinado com o mecanismo de confisco on-chain, inibe 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 requer que mais de dois terços dos votos dos validadores cheguem a um consenso para confirmar as transações. Este mecanismo garante que, mesmo que alguns nós se comportem de forma maliciosa, a rede pode continuar a operar de forma segura e 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, equilibrando descentralização e eficiência. O DPoS opta por reduzir o número de nós ativos de blocos em troca de maior segurança - descentralização - escalabilidade no "triângulo impossível".
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
22 Curtidas
Recompensa
22
7
Compartilhar
Comentário
0/400
fork_in_the_road
· 07-03 18:33
Identificar problemas e ainda fazer uma revisão. Esta operação é possível.
Ver originalResponder0
StakeOrRegret
· 07-01 08:28
Parece muito apetitoso, não consigo ficar sem comprar.
Ver originalResponder0
RunWhenCut
· 07-01 08:26
Totalmente, chegou a vez de nós, idiotas, fazermos uma contribuição.
Ver originalResponder0
MEVHunter
· 07-01 08:23
O problema não está no contrato, é simplesmente que a verificação de overflow não é rigorosa o suficiente. Aqueles que realmente hodlam entendem.
Ver originalResponder0
StopLossMaster
· 07-01 08:23
A mentalidade quebrou, como é que todos os projetos podem ser atacados.
Ver originalResponder0
LiquidityWitch
· 07-01 08:02
Hacker riu e chorou 呜呜cetus
Ver originalResponder0
PanicSeller
· 07-01 08:01
Fique tranquilo, ainda não fizeram as pessoas de parvas e já duplicou.
Resiliência do ecossistema SUI em destaque: Reflexões de segurança após o ataque Cetus e análise do potencial de crescimento a longo prazo
Fé firme após a crise de segurança: por que o SUI ainda tem potencial para subir a longo prazo?
TL;DR
O ataque desta vez baseia-se na falta de verificação de limites nas funções aritméticas do protocolo Cetus------vulnerabilidades lógicas causadas por uma máscara muito ampla e estouro de deslocamento, que não têm relação com o 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.
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 foi exatamente ú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 instantâneo de mais de 160 milhões de dólares em fundos. Isso é essencialmente uma forma ativa de "keynesianismo on-chain", onde um controle macroeconômico eficaz teve um efeito positivo sobre o sistema econômico.
Matemática e verificação de limites: introduzir afirmaçõ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 validação formal. Além disso, é necessário reforçar a auditoria e monitorização: além da auditoria de código geral, incluir uma equipe de auditoria matemática especializada e detecção em tempo real de comportamentos de transações on-chain, para capturar precocemente divisões anormais 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 promovendo um plano de reembolso de 100%, demonstrando uma forte capacidade de resposta em cadeia e responsabilidade ecológica. A Fundação SUI também adicionou 10 milhões de dólares em fundos de auditoria, reforçando a linha de segurança. No futuro, pode-se avançar ainda mais na implementação de sistemas de rastreamento em cadeia, ferramentas de segurança construídas pela comunidade, seguros descentralizados e outros mecanismos, aprimorando o sistema de proteção de fundos.
SUI conseguiu rapidamente realizar uma transição de "nova cadeia" para "forte ecossistema" em menos de dois anos, construindo um diversificado mapa ecológico que abrange várias áreas, incluindo stablecoins, DEX, infraestrutura, DePIN e jogos. O tamanho total das stablecoins ultrapassou 1 bilhão de dólares, proporcionando 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ª global, e é a 3ª entre as redes não EVM (apenas atrás do Bitcoin e Solana), demonstrando uma 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 principal protocolo AMM Cetus, implantado na rede SUI, sofreu um ataque de hackers. Os atacantes exploraram uma vulnerabilidade lógica relacionada a um "problema 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 espaço DeFi até agora este ano, mas também se tornou o ataque hacker mais destrutivo desde o lançamento da mainnet da 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, 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, etc.) caíram entre 76% e 97% em apenas uma hora, gerando uma ampla preocupação do 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 on-chain e a atividade dos usuários não sofreram uma queda contínua, mas, ao contrário, 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 ecológico do SUI, organizando o atual panorama ecológico desta blockchain que ainda se encontra em fase inicial de desenvolvimento, e discutirá seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque 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 de preços precisa 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 preços
Os hackers primeiro utilizam a maior slippage para realizar um empréstimo relâmpago de 10 bilhões de haSUI, 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 exploraram esse mecanismo para baixar rapidamente o preço do mercado e controlá-lo 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 o intervalo de preços com precisão 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 usaram 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 adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba recebendo apenas 1 token.
Essencialmente, isso se deve a duas razões:
Configuração de máscara excessivamente ampla: equivale a um limite máximo de adição de liquidez extremamente grande, resultando em validações de entrada do usuário no contrato que são praticamente ineficazes. Hackers configuraram parâmetros anormais, construindo entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.
O estouro de dados foi truncado: ao executar a operação de deslocamento n << 64 em um valor numérico n, ocorreu truncamento de dados devido ao deslocamento exceder a largura efetiva do tipo de dados uint256 (256 bits). A parte de estouro 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 ficou cerca de 1 a menos, mas como foi arredondado para cima, no final resultou em 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. No final, retirar ativos de tokens no valor total de centenas de milhões de dólares de vários 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
4,9 milhões de dólares Haedal Staked SUI
1950万美元 TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, liquidez esgotada
2.2 Causas e características da vulnerabilidade desta vez
A falha do Cetus tem três características:
Custo de reparação 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 origem da vulnerabilidade está em uma verificação de condição de limite, que pode ser completamente eliminada com a modificação de duas linhas de código; após a reparação, pode ser imediatamente implantada na rede principal, garantindo que a lógica dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.
Alta ocultação: O contrato funcionou de forma estável e sem falhas durante dois anos, 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 muito raros de submissão de liquidez extremamente alta, que desencadeiam uma lógica anômala, indicando que esses problemas são difíceis de detectar através de testes comuns. Esses problemas muitas vezes ficam em uma zona cega na visão das pessoas, por isso foram descobertos após muito tempo.
Move é superior a várias linguagens de contratos inteligentes em termos de segurança de recursos e verificação de tipos, com detecção nativa de problemas de estouro de inteiros em cenários comuns. Este 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 as operações de adição, subtração, multiplicação e divisão convencionais fossem usadas, 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, devido à falta de proteção contra estouro de inteiros, eram ainda mais fáceis de serem exploradas; 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, 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 por meio de parâmetros cuidadosamente elaborados, contornando as instruções de verificação no contrato e realizando transferências excessivas para efetuar ataques.
3. Mecanismo de consenso 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 taxa 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 impactem diretamente a governança da rede.
Número médio de validadores: 106
Média do ciclo Epoch: 24 horas
Processo mecânico:
Delegação de Direitos: usuários comuns não precisam executar nós por conta própria, basta que façam staking de SUI e deleguem a validadores candidatos para participar da garantia de 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 "contratando" validadores de confiança. Esta também é uma grande vantagem do DPoS em relação ao PoS tradicional.
Representar a rodada de blocos: um pequeno número 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, realiza-se uma rotação dinâmica e uma nova eleição do conjunto de Validadores, com base no peso dos votos, garantindo a vitalidade dos nós, a consistência de interesses e a descentralização.
Vantagens do DPoS:
Alta eficiência: Devido à quantidade controlável de nós de blocos, a rede pode completar a confirmação em milissegundos, atendendo à alta demanda de TPS.
Baixo custo: Menos nós participando do consenso, a largura de banda da rede e os recursos computacionais necessários para a sincronização de informações e agregação de assinaturas são significativamente reduzidos. Assim, os custos de hardware e operação diminuem, a exigência de poder de computação diminui, resultando em custos mais baixos. Isso leva a taxas de usuário mais baixas.
Alta segurança: O mecanismo de staking e delegação amplifica simultaneamente os custos e os riscos de ataque; combinado com o mecanismo de confisco on-chain, inibe 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 requer que mais de dois terços dos votos dos validadores cheguem a um consenso para confirmar as transações. Este mecanismo garante que, mesmo que alguns nós se comportem de forma maliciosa, a rede pode continuar a operar de forma segura e 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, equilibrando descentralização e eficiência. O DPoS opta por reduzir o número de nós ativos de blocos em troca de maior segurança - descentralização - escalabilidade no "triângulo impossível".