Fé firme após a crise de segurança: por que o SUI ainda possui potencial de crescimento a longo prazo?
1. Uma reação em cadeia causada 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 inteiro", executando um controle preciso, resultando em perdas de mais de 200 milhões de dólares em ativos. Este evento 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 despencaram entre 76% a 97% em apenas uma hora, gerando 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 causado uma flutuação na confiança a curto prazo, os fundos em cadeia e a atividade dos usuários não sofreram uma queda contínua; ao contrário, isso levou a um aumento significativo da atenção de todo o ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.
2. Análise das causas do ataque ao Cetus
2.1 Processo de implementação de ataque
De acordo com a análise técnica da equipe Slow Mist sobre o ataque Cetus, os hackers conseguiram explorar uma vulnerabilidade crítica de estouro aritmético no protocolo, utilizando um empréstimo relâmpago, manipulação de preços precisa e falhas no 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 aproveitaram o máximo deslizamento 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 reembolsem fundos na mesma transação, pagando apenas uma taxa de serviço, apresentando características de alta alavancagem, baixo risco e baixo custo. Os hackers aproveitaram esse mecanismo para reduzir rapidamente o preço do mercado e mantê-lo precisamente controlado 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 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%.
Usando os métodos acima, os hackers manipularam com sucesso 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, alegando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba recebendo apenas 1 token.
Essencialmente, isso se deve a dois motivos:
A configuração da máscara é excessivamente ampla: equivale a um limite de adição de liquidez extremamente alto, levando a que a validação das entradas do usuário no contrato seja irrelevante. Os hackers definem parâmetros anómalos, construindo entradas que são sempre inferiores a esse limite, contornando assim a detecção de transbordamento.
Dados de transbordo foram truncados: ao executar a operação de deslocamento n << 64 em um valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura efetiva do tipo de dado uint256 (256 bits). A parte de transbordo superior foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, o que fez com que o sistema subestimasse a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi cerca de 1 a menos, mas como foi arredondado para cima, o resultado final foi igual a 1, ou seja, o hacker só precisou adicionar 1 token para poder obter uma enorme liquidez.
③ Retirar liquidez
Realizar o reembolso do empréstimo relâmpago, mantendo lucros enormes. No final, retirar ativos de tokens com um valor total de várias centenas de milhões de dólares de múltiplas piscinas de liquidez.
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 desceram 75-80%, com liquidez esgotada
2.2 A causa e as características desta vulnerabilidade
A falha da Cetus tem três características:
O custo de reparo é 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 estava limitada apenas ao Cetus e não tinha relação com o código do SUI. A raiz da falha estava em uma verificação de condição de limite, precisando apenas de duas linhas de código para eliminar completamente o risco; após a correção, pode ser imediatamente implantada na mainnet, garantindo que a lógica do contrato subsequente seja completa e eliminando essa vulnerabilidade.
Alta ocultação: O contrato tem funcionado de forma estável e sem falhas há dois anos, e o Cetus Protocol passou por várias auditorias, mas as vulnerabilidades não foram encontradas, 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 extremamente raros de submissão de liquidez muito alta, o que desencadeia lógicas anómalas, indicando que esses problemas são difíceis de serem descobertos por testes comuns. Esses problemas muitas vezes estão em áreas cegas na percepção humana, por isso permanecem ocultos por um longo tempo antes de 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 uma 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 de tokens necessária, 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 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 são ainda mais fáceis de 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 porque o resultado da operação ultrapassou os limites. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas através de parâmetros cuidadosamente elaborados, contornando as instruçõ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 um quadro de Prova de Participação Delegada (DeleGated Proof of Stake, abreviado DPoS). Embora o mecanismo DPoS possa aumentar a capacidade de transações, não consegue fornecer um nível de descentralização tão elevado quanto 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 impactem 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 os usuários comuns, permitindo que participem do consenso da rede "contratando" validadores de confiança. Esta é uma grande vantagem do DPoS em relação ao PoS tradicional.
Representar a rodada de blocos: um pequeno número de validadores selecionados produzem 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 final de cada ciclo de contagem de votos, 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 de interesses e a descentralização.
Vantagens do DPoS:
Alta eficiência: devido ao número controlável de nós de blocos, a rede pode completar a confirmação em milissegundos, satisfazendo a necessidade de alta TPS.
Baixo custo: Menos nós participando do consenso resultam 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 operação diminuem, as exigências de poder computacional diminuem, resultando em custos mais baixos. No final, isso resulta em taxas de usuário mais baixas.
Alta segurança: o mecanismo de staking e delegação aumenta simultaneamente o custo e o risco de ataques; juntamente 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 exige que mais de dois terços dos votos dos validadores concordem para confirmar a transação. Este mecanismo garante que, mesmo que alguns nós ajam de forma maliciosa, a rede possa manter uma operação segura e eficiente. Para realizar 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, que faz uma troca 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 validação em troca de um desempenho mais elevado, abandonando um certo grau de completa descentralização em comparação com PoS puro ou PoW, mas melhorando 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 operação
Neste evento, SUI rapidamente congelou os endereços relacionados com o atacante.
Do ponto de vista do código, isso impede que as transações de transferência sejam empacotadas na cadeia. Os nós de validação são componentes centrais da blockchain SUI, responsáveis por validar transações e executar as regras do protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores equivalem a implementar um mecanismo semelhante ao 'congelamento de contas' encontrado nas finanças tradicionais em nível de consenso.
O SUI possui uma mecânica de lista de negaçã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 esta funcionalidade não existir, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores um a um em um curto espaço de tempo.
3.2.2 Quem tem o poder de alterar a lista negra?
TransactionDenyConfig é o arquivo de configuração YAML/TOML carregado localmente por cada validador. Qualquer pessoa que execute um nó pode editar este arquivo, recarregá-lo em quente ou reiniciar o nó e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar seus próprios valores.
Na verdade, para garantir a consistência e a eficácia 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 seus desenvolvedores autorizados) que estabelece e atualiza esta lista de rejeição.
A SUI publicou uma lista negra, teoricamente os validadores podem escolher se a adotam ou não - mas na prática, a maioria das pessoas automaticamente a adota por padrão. Assim, embora esta funcionalidade proteja os fundos dos usuários, na essência, realmente apresenta um certo grau de centralização.
3.2.3 A essência da funcionalidade de lista negra
A funcionalidade da lista negra não é, na verdade, uma lógica subjacente ao protocolo, mas sim uma camada adicional de segurança destinada a responder a situações imprevistas e garantir a segurança dos fundos dos usuários.
É essencialmente um mecanismo de garantia de segurança. Semelhante a uma "corrente de segurança" presa à porta, é ativado apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem agir de forma maliciosa contra o protocolo. Para o usuário:
Para os grandes investidores, que são os principais provedores de liquidez, o protocolo busca garantir a segurança dos fundos, pois na verdade os dados on-chain tvl são todos contribuídos pelos principais investidores. Para que o protocolo se desenvolva a longo prazo, é certo que a segurança será priorizada.
Para os pequenos investidores, contribuintes da atividade ecológica, e fortes apoiadores da construção conjunta de tecnologia e comunidade. A equipe do projeto também espera atrair pequenos investidores para co-construir, assim podendo gradualmente aperfeiçoar a ecologia e aumentar a taxa de retenção. E quanto ao setor de DeFi, a prioridade ainda é a segurança dos fundos.
A chave para julgar "se é centralizado" deve ser se os usuários têm controle sobre seus ativos. Nesse aspecto, SUI reflete isso através da linguagem de programação Move.
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.
10 Curtidas
Recompensa
10
6
Repostar
Compartilhar
Comentário
0/400
RektRecorder
· 8h atrás
Primeira fila do local de perdas explosivas
Ver originalResponder0
LiquidityNinja
· 8h atrás
Olha para baixo, já cortei a posição.
Ver originalResponder0
MevHunter
· 8h atrás
Aguardar pacientemente para o dump, o futuro é longo.
Ver originalResponder0
NeverVoteOnDAO
· 8h atrás
Não é a primeira vez que sou hackeado, acostume-se.
Ver originalResponder0
BtcDailyResearcher
· 8h atrás
Perda de corte saiu gg
Ver originalResponder0
consensus_whisperer
· 8h atrás
炸成这样还想 ignorar as pessoas e apanhar uma faca a cair?
SUI ecossistema demonstra resiliência: Análise das atualizações de segurança após o ataque Cetus e do potencial de crescimento a longo prazo
Fé firme após a crise de segurança: por que o SUI ainda possui potencial de crescimento a longo prazo?
1. Uma reação em cadeia causada 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 inteiro", executando um controle preciso, resultando em perdas de mais de 200 milhões de dólares em ativos. Este evento 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 despencaram entre 76% a 97% em apenas uma hora, gerando 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 causado uma flutuação na confiança a curto prazo, os fundos em cadeia e a atividade dos usuários não sofreram uma queda contínua; ao contrário, isso levou a um aumento significativo da atenção de todo o ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.
2. Análise das causas do ataque ao Cetus
2.1 Processo de implementação de ataque
De acordo com a análise técnica da equipe Slow Mist sobre o ataque Cetus, os hackers conseguiram explorar uma vulnerabilidade crítica de estouro aritmético no protocolo, utilizando um empréstimo relâmpago, manipulação de preços precisa e falhas no 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 aproveitaram o máximo deslizamento 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 reembolsem fundos na mesma transação, pagando apenas uma taxa de serviço, apresentando características de alta alavancagem, baixo risco e baixo custo. Os hackers aproveitaram esse mecanismo para reduzir rapidamente o preço do mercado e mantê-lo precisamente controlado 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 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%.
Usando os métodos acima, os hackers manipularam com sucesso 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, alegando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba recebendo apenas 1 token.
Essencialmente, isso se deve a dois motivos:
A configuração da máscara é excessivamente ampla: equivale a um limite de adição de liquidez extremamente alto, levando a que a validação das entradas do usuário no contrato seja irrelevante. Os hackers definem parâmetros anómalos, construindo entradas que são sempre inferiores a esse limite, contornando assim a detecção de transbordamento.
Dados de transbordo foram truncados: ao executar a operação de deslocamento n << 64 em um valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura efetiva do tipo de dado uint256 (256 bits). A parte de transbordo superior foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, o que fez com que o sistema subestimasse a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi cerca de 1 a menos, mas como foi arredondado para cima, o resultado final foi igual a 1, ou seja, o hacker só precisou adicionar 1 token para poder obter uma enorme liquidez.
③ Retirar liquidez
Realizar o reembolso do empréstimo relâmpago, mantendo lucros enormes. No final, retirar ativos de tokens com um valor total de várias centenas de milhões de dólares de múltiplas piscinas de liquidez.
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 desceram 75-80%, com liquidez esgotada
2.2 A causa e as características desta vulnerabilidade
A falha da Cetus tem três características:
O custo de reparo é 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 estava limitada apenas ao Cetus e não tinha relação com o código do SUI. A raiz da falha estava em uma verificação de condição de limite, precisando apenas de duas linhas de código para eliminar completamente o risco; após a correção, pode ser imediatamente implantada na mainnet, garantindo que a lógica do contrato subsequente seja completa e eliminando essa vulnerabilidade.
Alta ocultação: O contrato tem funcionado de forma estável e sem falhas há dois anos, e o Cetus Protocol passou por várias auditorias, mas as vulnerabilidades não foram encontradas, 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 extremamente raros de submissão de liquidez muito alta, o que desencadeia lógicas anómalas, indicando que esses problemas são difíceis de serem descobertos por testes comuns. Esses problemas muitas vezes estão em áreas cegas na percepção humana, por isso permanecem ocultos por um longo tempo antes de serem descobertos.
Move é superior a várias linguagens de contratos inteligentes em termos de segurança de recursos e verificação de tipos, incorporando uma 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 de tokens necessária, 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 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 são ainda mais fáceis de 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 porque o resultado da operação ultrapassou os limites. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas através de parâmetros cuidadosamente elaborados, contornando as instruçõ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 um quadro de Prova de Participação Delegada (DeleGated Proof of Stake, abreviado DPoS). Embora o mecanismo DPoS possa aumentar a capacidade de transações, não consegue fornecer um nível de descentralização tão elevado quanto 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 impactem 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 os usuários comuns, permitindo que participem do consenso da rede "contratando" validadores de confiança. Esta é uma grande vantagem do DPoS em relação ao PoS tradicional.
Representar a rodada de blocos: um pequeno número de validadores selecionados produzem 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 final de cada ciclo de contagem de votos, 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 de interesses e a descentralização.
Vantagens do DPoS:
Alta eficiência: devido ao número controlável de nós de blocos, a rede pode completar a confirmação em milissegundos, satisfazendo a necessidade de alta TPS.
Baixo custo: Menos nós participando do consenso resultam 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 operação diminuem, as exigências de poder computacional diminuem, resultando em custos mais baixos. No final, isso resulta em taxas de usuário mais baixas.
Alta segurança: o mecanismo de staking e delegação aumenta simultaneamente o custo e o risco de ataques; juntamente 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 exige que mais de dois terços dos votos dos validadores concordem para confirmar a transação. Este mecanismo garante que, mesmo que alguns nós ajam de forma maliciosa, a rede possa manter uma operação segura e eficiente. Para realizar 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, que faz uma troca 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 validação em troca de um desempenho mais elevado, abandonando um certo grau de completa descentralização em comparação com PoS puro ou PoW, mas melhorando 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 operação
Neste evento, SUI rapidamente congelou os endereços relacionados com o atacante.
Do ponto de vista do código, isso impede que as transações de transferência sejam empacotadas na cadeia. Os nós de validação são componentes centrais da blockchain SUI, responsáveis por validar transações e executar as regras do protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores equivalem a implementar um mecanismo semelhante ao 'congelamento de contas' encontrado nas finanças tradicionais em nível de consenso.
O SUI possui uma mecânica de lista de negaçã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 esta funcionalidade não existir, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores um a um em um curto espaço de tempo.
3.2.2 Quem tem o poder de alterar a lista negra?
TransactionDenyConfig é o arquivo de configuração YAML/TOML carregado localmente por cada validador. Qualquer pessoa que execute um nó pode editar este arquivo, recarregá-lo em quente ou reiniciar o nó e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar seus próprios valores.
Na verdade, para garantir a consistência e a eficácia 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 seus desenvolvedores autorizados) que estabelece e atualiza esta lista de rejeição.
A SUI publicou uma lista negra, teoricamente os validadores podem escolher se a adotam ou não - mas na prática, a maioria das pessoas automaticamente a adota por padrão. Assim, embora esta funcionalidade proteja os fundos dos usuários, na essência, realmente apresenta um certo grau de centralização.
3.2.3 A essência da funcionalidade de lista negra
A funcionalidade da lista negra não é, na verdade, uma lógica subjacente ao protocolo, mas sim uma camada adicional de segurança destinada a responder a situações imprevistas e garantir a segurança dos fundos dos usuários.
É essencialmente um mecanismo de garantia de segurança. Semelhante a uma "corrente de segurança" presa à porta, é ativado apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem agir de forma maliciosa contra o protocolo. Para o usuário:
Para os grandes investidores, que são os principais provedores de liquidez, o protocolo busca garantir a segurança dos fundos, pois na verdade os dados on-chain tvl são todos contribuídos pelos principais investidores. Para que o protocolo se desenvolva a longo prazo, é certo que a segurança será priorizada.
Para os pequenos investidores, contribuintes da atividade ecológica, e fortes apoiadores da construção conjunta de tecnologia e comunidade. A equipe do projeto também espera atrair pequenos investidores para co-construir, assim podendo gradualmente aperfeiçoar a ecologia e aumentar a taxa de retenção. E quanto ao setor de DeFi, a prioridade ainda é a segurança dos fundos.
A chave para julgar "se é centralizado" deve ser se os usuários têm controle sobre seus ativos. Nesse aspecto, SUI reflete isso através da linguagem de programação Move.