A fé inabalável após a crise de segurança: por que o SUI ainda tem potencial de crescimento 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 deve-se à falta de verificação de limites nas funções aritméticas do protocolo Cetus------uma vulnerabilidade lógica causada por uma máscara muito ampla e um estouro de deslocamento, que não tem 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 "raciocínio centralizado" no mecanismo SUI revela seu valor em tempos de crise:
Embora o SUI tenha uma leve tendência para a centralização devido a funcionalidades como rodadas de validadores DPoS e congelamento de listas negras, isso foi útil na resposta ao evento CETUS: os validadores rapidamente sincronizaram endereços maliciosos à Deny List, recusando-se a empacotar transações relacionadas, resultando em um congelamento instantâneo de mais de 160 milhões de dólares. Isso é essencialmente uma forma ativa de "keynesianismo em cadeia", onde o controle macro eficaz teve um efeito positivo no 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 limite 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, aumentar a equipe de auditoria matemática especializada e a deteção de comportamento de transações em tempo real na blockchain, para capturar 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 eficientemente 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 de auditoria, reforçando a linha de defesa de segurança. No futuro, pode-se avançar ainda mais com sistemas de rastreamento em cadeia, ferramentas de segurança construídas pela comunidade, seguros descentralizados e outros mecanismos para aperfeiçoar o sistema de garantia de fundos.
A expansão diversificada do ecossistema SUI
SUI alcançou rapidamente a transição de "nova cadeia" para "forte ecossistema" em menos de dois anos, construindo um mapa ecológico diversificado que abrange várias trilhas, incluindo stablecoins, DEX, infraestrutura, DePIN, jogos, entre outros. 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 está classificado em 8º lugar globalmente, com a 5ª maior atividade de negociação no mundo e o 3º entre as redes não EVM (apenas atrás do Bitcoin e Solana), demonstrando forte participação de 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 principal protocolo AMM Cetus, implantado na rede SUI, sofreu um ataque hacker, onde o atacante explorou uma falha lógica relacionada ao "problema de estouro de inteiro", realizando uma manipulação precisa, resultando na perda 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 mais de 330 milhões de dólares no dia do ataque, e o montante 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) caíram entre 76% a 97% em apenas uma hora, gerando uma ampla preocupação no mercado sobre a segurança da SUI e a estabilidade do ecossistema.
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 sim impulsionaram um aumento significativo na atenção de todo o ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.
A Klein Labs irá abordar as causas do ataque, o mecanismo de consenso dos nós SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema SUI, analisando o atual quadro ecológico 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 Cetus
2.1 Processo de Implementação de Ataque
De acordo com a análise técnica do incidente de ataque ao Cetus pela equipe Slow Mist, os hackers conseguiram explorar uma vulnerabilidade crítica de estouro aritmético no protocolo, usando 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 aproximadamente nas seguintes três fases:
①Iniciar um empréstimo relâmpago, manipular o preço
Os hackers primeiro usaram um empréstimo relâmpago de 10 bilhões de haSUI com o máximo deslizamento, 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 de serviço, 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 sob controle em uma faixa extremamente 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 maior preço de 300.200, com uma largura de preço de apenas 1,00496621%.
Desta forma, 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, afirma adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
É essencialmente devido a duas razões:
Configuração de máscara muito ampla: equivale a um limite máximo de adição de liquidez extremamente alto, resultando na validação das entradas dos usuários no contrato sendo praticamente nula. Hackers, ao configurar parâmetros anômalos, conseguem construir entradas que estão sempre abaixo desse limite, assim contornando a detecção de estouro.
A sobrecarga de dados foi truncada: ao realizar a operação de deslocamento n << 64 no valor n, ocorreu uma truncagem de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dados uint256 (256 bits). A parte superior do overflow foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do 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 é igual a 1, ou seja, o hacker só precisa adicionar 1 token para obter uma grande liquidez.
③ Retirar liquidez
Realizar o reembolso de empréstimos relâmpago, mantendo lucros significativos. No final, retirar de múltiplas pools de liquidez um total de ativos de token no valor de centenas de milhões de dólares.
A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:
1290 mil SUI (cerca de 5400 dólares americanos)
6000万美元 USDC
490万美元 Haedal Staked SUI
1950万美元 TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, a liquidez esgotou.
2.2 Causas e características da vulnerabilidade desta vez
A vulnerabilidade 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 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 reside 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 rede principal, garantindo que a lógica dos contratos subsequentes esteja completa e que essa vulnerabilidade seja eliminada.
Alta ocultação: o contrato está em operação estável e sem falhas há dois anos, o Cetus Protocol passou por várias auditorias, mas nenhuma vulnerabilidade foi encontrada, principalmente porque a biblioteca Integer_Mate, utilizada para cálculos matemáticos, não foi incluída no escopo da auditoria.
Os hackers usam 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 detectar através de testes comuns. Esses problemas frequentemente estão em áreas cegas na visão das pessoas, por isso ficam ocultos por muito tempo até serem descobertos.
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, incorporando detecção nativa para 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 necessária de tokens, e a operação de deslocamento foi usada em vez da operação de multiplicação convencional. Se fossem utilizadas operações convencionais de adição, subtração, multiplicação e divisão, o Move automaticamente verificaria 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 até mesmo se tornaram mais fáceis de explorar 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, etc., sendo que a causa direta foi sempre o resultado da operação excedendo 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 dentro do contrato e realizando transferências excessivas para efetuar ataques.
3. 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 o throughput das transações, ele não consegue fornecer o mesmo nível de descentralização que o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, e o limiar de governança é relativamente alto, dificultando que usuários comuns influenciem diretamente a governança da rede.
Número médio de validadores: 106
Duração média do 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 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-lhes participar 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 da rodada de criação de blocos: um pequeno número 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 ciclo de votação, realiza-se uma rotação dinâmica, reelecionando o conjunto de Validadores com base no peso do voto, 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 consegue concluir a confirmação em milissegundos, atendendo à alta demanda de TPS.
Baixo custo: Menos nós participam do consenso, o que resulta em uma redução significativa da largura de banda de rede e dos 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 exigência de poder computacional é menor, resultando em custos mais baixos. Isso culmina em taxas de transação mais baixas para os usuários.
Alta segurança: o mecanismo de staking e delegação aumenta simultaneamente os custos e riscos de ataque; em conjunto 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 sejam maliciosos, a rede pode manter uma operação segura e eficiente. Para qualquer atualização ou decisão significativa, também é necessário que mais de dois terços dos votos sejam alcançados para ser implementado.
Em essência, o DPoS é na verdade uma forma de um triângulo impossível.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
14 gostos
Recompensa
14
5
Partilhar
Comentar
0/400
GasFeeCrying
· 07-31 03:05
Mesmo um peixe morto pode se revirar. Aposte no sui.
Ver originalResponder0
FromMinerToFarmer
· 07-31 03:04
ainda é melhor fazer as pessoas de parvas para ser mais rápido
Ver originalResponder0
PumpingCroissant
· 07-31 03:03
Ainda acredito no sui. Afinal, o código de base não tem problema.
Ver originalResponder0
LoneValidator
· 07-31 02:52
Ainda bem que a falha não é muito grave. Se continuar, já era.
A resiliência do ecossistema SUI: reflexão sobre o incidente de ataque da Cetus e análise do potencial de crescimento a longo prazo
A fé inabalável após a crise de segurança: por que o SUI ainda tem potencial de crescimento a longo prazo?
TL;DR
O ataque desta vez deve-se à falta de verificação de limites nas funções aritméticas do protocolo Cetus------uma vulnerabilidade lógica causada por uma máscara muito ampla e um estouro de deslocamento, que não tem 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 para a centralização devido a funcionalidades como rodadas de validadores DPoS e congelamento de listas negras, isso foi útil na resposta ao evento CETUS: os validadores rapidamente sincronizaram endereços maliciosos à Deny List, recusando-se a empacotar transações relacionadas, resultando em um congelamento instantâneo de mais de 160 milhões de dólares. Isso é essencialmente uma forma ativa de "keynesianismo em cadeia", onde o controle macro eficaz teve um efeito positivo no sistema econômico.
Matemática e verificação de limites: introduzir afirmações de limite 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, aumentar a equipe de auditoria matemática especializada e a deteção de comportamento de transações em tempo real na blockchain, para capturar precocemente divisões anómalas ou grandes empréstimos relâmpago;
No evento Cetus, a SUI colaborou eficientemente 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 de auditoria, reforçando a linha de defesa de segurança. No futuro, pode-se avançar ainda mais com sistemas de rastreamento em cadeia, ferramentas de segurança construídas pela comunidade, seguros descentralizados e outros mecanismos para aperfeiçoar o sistema de garantia de fundos.
SUI alcançou rapidamente a transição de "nova cadeia" para "forte ecossistema" em menos de dois anos, construindo um mapa ecológico diversificado que abrange várias trilhas, incluindo stablecoins, DEX, infraestrutura, DePIN, jogos, entre outros. 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 está classificado em 8º lugar globalmente, com a 5ª maior atividade de negociação no mundo e o 3º entre as redes não EVM (apenas atrás do Bitcoin e Solana), demonstrando forte participação de 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 principal protocolo AMM Cetus, implantado na rede SUI, sofreu um ataque hacker, onde o atacante explorou uma falha lógica relacionada ao "problema de estouro de inteiro", realizando uma manipulação precisa, resultando na perda 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 mais de 330 milhões de dólares no dia do ataque, e o montante 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) caíram entre 76% a 97% em apenas uma hora, gerando uma ampla preocupação no mercado sobre a segurança da SUI e a estabilidade do ecossistema.
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 sim impulsionaram um aumento significativo na atenção de todo o ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.
A Klein Labs irá abordar as causas do ataque, o mecanismo de consenso dos nós SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema SUI, analisando o atual quadro ecológico 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 Cetus
2.1 Processo de Implementação de Ataque
De acordo com a análise técnica do incidente de ataque ao Cetus pela equipe Slow Mist, os hackers conseguiram explorar uma vulnerabilidade crítica de estouro aritmético no protocolo, usando 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 aproximadamente nas seguintes três fases:
①Iniciar um empréstimo relâmpago, manipular o preço
Os hackers primeiro usaram um empréstimo relâmpago de 10 bilhões de haSUI com o máximo deslizamento, 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 de serviço, 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 sob controle em uma faixa extremamente 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 maior preço de 300.200, com uma largura de preço de apenas 1,00496621%.
Desta forma, 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, afirma adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
É essencialmente devido a duas razões:
Configuração de máscara muito ampla: equivale a um limite máximo de adição de liquidez extremamente alto, resultando na validação das entradas dos usuários no contrato sendo praticamente nula. Hackers, ao configurar parâmetros anômalos, conseguem construir entradas que estão sempre abaixo desse limite, assim contornando a detecção de estouro.
A sobrecarga de dados foi truncada: ao realizar a operação de deslocamento n << 64 no valor n, ocorreu uma truncagem de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dados uint256 (256 bits). A parte superior do overflow foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do 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 é igual a 1, ou seja, o hacker só precisa adicionar 1 token para obter uma grande liquidez.
③ Retirar liquidez
Realizar o reembolso de empréstimos relâmpago, mantendo lucros significativos. No final, retirar de múltiplas pools de liquidez um total de ativos de token no valor de centenas de milhões de dólares.
A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:
1290 mil SUI (cerca de 5400 dólares americanos)
6000万美元 USDC
490万美元 Haedal Staked SUI
1950万美元 TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, a liquidez esgotou.
2.2 Causas e características da vulnerabilidade desta vez
A vulnerabilidade 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 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 reside 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 rede principal, garantindo que a lógica dos contratos subsequentes esteja completa e que essa vulnerabilidade seja eliminada.
Alta ocultação: o contrato está em operação estável e sem falhas há dois anos, o Cetus Protocol passou por várias auditorias, mas nenhuma vulnerabilidade foi encontrada, principalmente porque a biblioteca Integer_Mate, utilizada para cálculos matemáticos, não foi incluída no escopo da auditoria.
Os hackers usam 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 detectar através de testes comuns. Esses problemas frequentemente estão em áreas cegas na visão das pessoas, por isso ficam ocultos por muito tempo até serem descobertos.
Move é superior a várias linguagens de contratos inteligentes em termos de segurança de recursos e verificação de tipos, incorporando detecção nativa para 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 necessária de tokens, e a operação de deslocamento foi usada em vez da operação de multiplicação convencional. Se fossem utilizadas operações convencionais de adição, subtração, multiplicação e divisão, o Move automaticamente verificaria 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 até mesmo se tornaram mais fáceis de explorar 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, etc., sendo que a causa direta foi sempre o resultado da operação excedendo 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 dentro do contrato e realizando transferências excessivas para efetuar ataques.
3. 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 o throughput das transações, ele não consegue fornecer o mesmo nível de descentralização que o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, e o limiar de governança é relativamente alto, dificultando que usuários comuns influenciem diretamente a governança da rede.
Número médio de validadores: 106
Duração média do 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 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-lhes participar 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 da rodada de criação de blocos: um pequeno número 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 ciclo de votação, realiza-se uma rotação dinâmica, reelecionando o conjunto de Validadores com base no peso do voto, 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 consegue concluir a confirmação em milissegundos, atendendo à alta demanda de TPS.
Baixo custo: Menos nós participam do consenso, o que resulta em uma redução significativa da largura de banda de rede e dos 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 exigência de poder computacional é menor, resultando em custos mais baixos. Isso culmina em taxas de transação mais baixas para os usuários.
Alta segurança: o mecanismo de staking e delegação aumenta simultaneamente os custos e riscos de ataque; em conjunto 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 sejam maliciosos, a rede pode manter uma operação segura e eficiente. Para qualquer atualização ou decisão significativa, também é necessário que mais de dois terços dos votos sejam alcançados para ser implementado.
Em essência, o DPoS é na verdade uma forma de um triângulo impossível.