Crença firme após a crise de segurança: por que SUI ainda possui potencial de crescimento a longo prazo?
1. Uma reação em cadeia desencadeada 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 aproveitaram uma falha lógica relacionada ao "problema de estouro de inteiro" para realizar uma manipulação precisa, resultando em perdas superiores a 200 milhões de dólares em ativos. Este incidente não apenas é um dos maiores acidentes de segurança no setor DeFi até o momento este ano, mas também se tornou o ataque hacker mais devastador desde o lançamento da rede principal SUI.
De acordo com os dados da DefiLlama, o TVL total da rede 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) despencaram entre 76% e 97% em apenas uma hora, gerando ampla preocupação no mercado sobre a segurança e a estabilidade ecológica da SUI.
Mas após essa onda de choque, o ecossistema SUI demonstrou uma forte resiliência e capacidade de recuperação. Embora o evento Cetus tenha trazido flutuações de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram uma queda contínua; ao contrário, isso levou a uma atenção significativa em todo o ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.
2. Análise das causas do ataque ao evento 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 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, e roubaram mais de 200 milhões de dólares em ativos digitais em um curto espaço de tempo. O caminho do ataque pode ser dividido em três fases principais:
①Iniciar um empréstimo relâmpago, manipular preços
Os hackers primeiro utilizaram um empréstimo relâmpago de 100 bilhões de haSUI com o maior deslizamento possível, emprestando grandes quantias de dinheiro para manipulação de preços.
O empréstimo relâmpago permite que os usuários emprestem e devolvam fundos na mesma transação, pagando apenas uma taxa, apresentando características de alta alavancagem, baixo risco e baixo custo. Os hackers aproveitaram este mecanismo para reduzir rapidamente os preços de mercado, controlando-os de forma precisa dentro de um intervalo extremamente estreito.
Em seguida, os atacantes se prepararam 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 máximo 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
O atacante cria posições de liquidez estreitas, declara adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
Essencialmente por duas razões:
Definição de máscara muito ampla: equivale a um limite de adição de liquidez extremamente grande, levando a uma verificação de entrada do usuário que é praticamente inútil no contrato. Hackers configuram parâmetros anômalos, 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 na variável numérica n, ocorreu um truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dados uint256 (256 bits). A parte de estouro mais alta foi automaticamente descartada, resultando em um resultado de cálculo muito inferior ao esperado, levando o sistema a subestimar a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi aproximadamente inferior a 1, mas como foi arredondado para cima, acabou sendo igual a 1, ou seja, o hacker só precisava adicionar 1 token para trocar por uma enorme liquidez.
③ Retirar liquidez
Realizar reembolso de empréstimos relâmpago, mantendo lucros enormes. 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 milhões de dólares)
6000万美元USDC
490万美元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 vulnerabilidade do Cetus tem três características:
Custo de reparação extremamente baixo: por um lado, a causa raiz do incidente Cetus foi uma falha na biblioteca matemática Cetus, e não um erro no mecanismo de preços do protocolo ou na arquitetura subjacente. Por outro lado, a vulnerabilidade está limitada apenas ao Cetus e não tem relação com o código SUI. A origem da vulnerabilidade está numa verificação de condição de limite, e basta modificar duas linhas de código para eliminar completamente o risco; após a reparaçã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 está em funcionamento estável e sem falhas há dois anos, o Cetus Protocol foi auditado várias vezes, mas falhas não foram encontradas, 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 acionam lógicas anômalas, indicando que este tipo de problema é difícil de ser detectado através de testes comuns. Esses problemas geralmente estão em zonas cegas na visão das pessoas, por isso permanecem ocultos por um longo tempo até 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, com 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 máximo 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. Caso fossem utilizadas operações convencionais de adição, subtração, multiplicação ou 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 e Rust), e eram até mais fáceis de serem exploradas devido à falta de proteção contra estouro de inteiros; antes das atualizações de 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 a causa direta sempre o fato de 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 elaborados, contornando as instruções de verificação no contrato e realizando ataques com transferências excessivas.
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ção, ele não consegue oferecer um nível de descentralização tão alto quanto o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, e o limiar de governança é relativamente alto, tornando difícil para usuários comuns influenciar 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 operar nós por conta própria, basta que façam a staking 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-lhes participar do consenso da rede "contratando" validadores de confiança. Esta é também uma grande vantagem do DPoS em comparação com o 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, é feita uma rotação dinâmica, reelecionando o conjunto de Validadores com base no peso dos votos, 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 mineração, a rede pode completar a confirmação em milissegundos, atendendo à demanda de alta 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ções diminuem, as exigências de poder computacional são menores, resultando em custos mais baixos. Isso leva a taxas de transação mais baixas para os usuários.
Alta segurança: o mecanismo de staking e delegação amplifica simultaneamente os custos e riscos de ataque; juntamente com o mecanismo de penalização em cadeia, 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 que uma transação seja confirmada. Este mecanismo garante que, mesmo que alguns nós ajam de forma maliciosa, a rede possa 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 que a implementação ocorra.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, que faz um equilíbrio entre descentralização e eficiência. No "triângulo impossível" da segurança-descentralização-escala, o DPoS opta por reduzir o número de nós de validação ativos em troca de maior desempenho, sacrificando um certo grau de completa descentralização em comparação com PoS ou PoW, mas melhorando significativamente a capacidade 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, a SUI congelou rapidamente os endereços relacionados ao 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 implementam, em nível de consenso, um mecanismo semelhante ao 'congelamento de contas' no setor financeiro tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de lista negra que pode impedir 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 essa funcionalidade não existir, mesmo que SUI tenha apenas 113 validadores, será difícil para o 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 é um arquivo de configuração YAML/TOML carregado localmente por cada validador. Qualquer pessoa que execute um nó pode editar este arquivo, fazer recarga a quente ou reiniciar o nó e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar os seus próprios valores.
Na verdade, para a consistência e eficácia das políticas de segurança, a atualização dessa configuração crítica é geralmente coordenada. Uma vez que esta é uma "atualização urgente promovida pela equipe SUI", basicamente é a fundação SUI (ou os desenvolvedores autorizados por ela) que define e atualiza esta lista de rejeição.
SUI publicou uma lista negra, teoricamente os validadores podem escolher se a adotam ou não ------ mas na prática a maioria das pessoas acaba adotando automaticamente. Assim, embora essa funcionalidade proteja os fundos dos usuários, ela tem, na essência, um certo grau de centralização.
3.2.3 A essência da funcionalidade da lista negra
A funcionalidade de lista negra na verdade não é uma lógica da camada de protocolo, mas sim uma camada adicional de segurança destinada a lidar com situações inesperadas e garantir a segurança dos fundos dos usuários.
É essencialmente um mecanismo de garantia de segurança. Semelhante a uma "corrente de segurança" presa à porta, que só é ativada para aqueles que desejam invadir a casa, ou seja, para aqueles que têm a intenção de prejudicar o protocolo. Para os usuários, isso significa:
Para os grandes investidores, os principais provedores de liquidez, o protocolo é o que mais deseja garantir a segurança dos fundos, pois na verdade os dados on-chain tvl são todos contribuídos pelos principais grandes investidores; para que o protocolo se desenvolva a longo prazo, é imprescindível priorizar a segurança.
Para os investidores individuais, contribuidores da atividade ecológica, apoiantes fortes da construção conjunta de tecnologia e comunidade. O projeto também espera atrair investidores individuais para co-construir, assim poderá gradualmente melhorar a ecologia e aumentar a taxa de retenção. E quanto ao campo do defi, a segurança dos fundos é sempre a prioridade.
A chave para determinar "se é descentralizado" deve ser se os usuários têm controle sobre seus ativos. Nesse aspecto, o SUI utiliza a Move.
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.
11 gostos
Recompensa
11
5
Partilhar
Comentar
0/400
Web3ProductManager
· 20h atrás
analisando os dados de retenção de usuários... este hack pode ser um grande ponto de atrito para a adoção em massa, para ser sincero
Ver originalResponder0
MEVHunterWang
· 20h atrás
Uma falha tão grande e ninguém percebeu? Incrível, incrível.
Ver originalResponder0
fren.eth
· 20h atrás
É uma pena, ainda estou a sofrer perdas consecutivas.
Ver originalResponder0
¯\_(ツ)_/¯
· 20h atrás
fazer as pessoas de parvas um pedaço de carne a menos, quando é que deve subir ainda sobe
Ver originalResponder0
MetaverseMigrant
· 21h atrás
Esta viagem não existe mais, quem ainda se atreve a entrar numa posição é realmente um guerreiro.
Análise do ecossistema SUI: resiliência e potencial de crescimento a longo prazo após o incidente de ataque da Cetus
Crença firme após a crise de segurança: por que SUI ainda possui potencial de crescimento a longo prazo?
1. Uma reação em cadeia desencadeada 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 aproveitaram uma falha lógica relacionada ao "problema de estouro de inteiro" para realizar uma manipulação precisa, resultando em perdas superiores a 200 milhões de dólares em ativos. Este incidente não apenas é um dos maiores acidentes de segurança no setor DeFi até o momento este ano, mas também se tornou o ataque hacker mais devastador desde o lançamento da rede principal SUI.
De acordo com os dados da DefiLlama, o TVL total da rede 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) despencaram entre 76% e 97% em apenas uma hora, gerando ampla preocupação no mercado sobre a segurança e a estabilidade ecológica da SUI.
Mas após essa onda de choque, o ecossistema SUI demonstrou uma forte resiliência e capacidade de recuperação. Embora o evento Cetus tenha trazido flutuações de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram uma queda contínua; ao contrário, isso levou a uma atenção significativa em todo o ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.
2. Análise das causas do ataque ao evento 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 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, e roubaram mais de 200 milhões de dólares em ativos digitais em um curto espaço de tempo. O caminho do ataque pode ser dividido em três fases principais:
①Iniciar um empréstimo relâmpago, manipular preços
Os hackers primeiro utilizaram um empréstimo relâmpago de 100 bilhões de haSUI com o maior deslizamento possível, emprestando grandes quantias de dinheiro para manipulação de preços.
O empréstimo relâmpago permite que os usuários emprestem e devolvam fundos na mesma transação, pagando apenas uma taxa, apresentando características de alta alavancagem, baixo risco e baixo custo. Os hackers aproveitaram este mecanismo para reduzir rapidamente os preços de mercado, controlando-os de forma precisa dentro de um intervalo extremamente estreito.
Em seguida, os atacantes se prepararam 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 máximo 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
O atacante cria posições de liquidez estreitas, declara adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
Essencialmente por duas razões:
Definição de máscara muito ampla: equivale a um limite de adição de liquidez extremamente grande, levando a uma verificação de entrada do usuário que é praticamente inútil no contrato. Hackers configuram parâmetros anômalos, 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 na variável numérica n, ocorreu um truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dados uint256 (256 bits). A parte de estouro mais alta foi automaticamente descartada, resultando em um resultado de cálculo muito inferior ao esperado, levando o sistema a subestimar a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi aproximadamente inferior a 1, mas como foi arredondado para cima, acabou sendo igual a 1, ou seja, o hacker só precisava adicionar 1 token para trocar por uma enorme liquidez.
③ Retirar liquidez
Realizar reembolso de empréstimos relâmpago, mantendo lucros enormes. 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 milhões de dólares)
6000万美元USDC
490万美元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 vulnerabilidade do Cetus tem três características:
Custo de reparação extremamente baixo: por um lado, a causa raiz do incidente Cetus foi uma falha na biblioteca matemática Cetus, e não um erro no mecanismo de preços do protocolo ou na arquitetura subjacente. Por outro lado, a vulnerabilidade está limitada apenas ao Cetus e não tem relação com o código SUI. A origem da vulnerabilidade está numa verificação de condição de limite, e basta modificar duas linhas de código para eliminar completamente o risco; após a reparaçã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 está em funcionamento estável e sem falhas há dois anos, o Cetus Protocol foi auditado várias vezes, mas falhas não foram encontradas, 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 acionam lógicas anômalas, indicando que este tipo de problema é difícil de ser detectado através de testes comuns. Esses problemas geralmente estão em zonas cegas na visão das pessoas, por isso permanecem ocultos por um longo tempo até serem descobertos,
Move é superior a várias linguagens de contratos inteligentes em segurança de recursos e verificação de tipos, com 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 máximo 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. Caso fossem utilizadas operações convencionais de adição, subtração, multiplicação ou 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 e Rust), e eram até mais fáceis de serem exploradas devido à falta de proteção contra estouro de inteiros; antes das atualizações de 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 a causa direta sempre o fato de 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 elaborados, contornando as instruções de verificação no contrato e realizando ataques com transferências excessivas.
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ção, ele não consegue oferecer um nível de descentralização tão alto quanto o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, e o limiar de governança é relativamente alto, tornando difícil para usuários comuns influenciar 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 operar nós por conta própria, basta que façam a staking 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-lhes participar do consenso da rede "contratando" validadores de confiança. Esta é também uma grande vantagem do DPoS em comparação com o 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, é feita uma rotação dinâmica, reelecionando o conjunto de Validadores com base no peso dos votos, 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 mineração, a rede pode completar a confirmação em milissegundos, atendendo à demanda de alta 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ções diminuem, as exigências de poder computacional são menores, resultando em custos mais baixos. Isso leva a taxas de transação mais baixas para os usuários.
Alta segurança: o mecanismo de staking e delegação amplifica simultaneamente os custos e riscos de ataque; juntamente com o mecanismo de penalização em cadeia, 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 que uma transação seja confirmada. Este mecanismo garante que, mesmo que alguns nós ajam de forma maliciosa, a rede possa 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 que a implementação ocorra.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, que faz um equilíbrio entre descentralização e eficiência. No "triângulo impossível" da segurança-descentralização-escala, o DPoS opta por reduzir o número de nós de validação ativos em troca de maior desempenho, sacrificando um certo grau de completa descentralização em comparação com PoS ou PoW, mas melhorando significativamente a capacidade 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, a SUI congelou rapidamente os endereços relacionados ao 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 implementam, em nível de consenso, um mecanismo semelhante ao 'congelamento de contas' no setor financeiro tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de lista negra que pode impedir 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 essa funcionalidade não existir, mesmo que SUI tenha apenas 113 validadores, será difícil para o 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 é um arquivo de configuração YAML/TOML carregado localmente por cada validador. Qualquer pessoa que execute um nó pode editar este arquivo, fazer recarga a quente ou reiniciar o nó e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar os seus próprios valores.
Na verdade, para a consistência e eficácia das políticas de segurança, a atualização dessa configuração crítica é geralmente coordenada. Uma vez que esta é uma "atualização urgente promovida pela equipe SUI", basicamente é a fundação SUI (ou os desenvolvedores autorizados por ela) que define e atualiza esta lista de rejeição.
SUI publicou uma lista negra, teoricamente os validadores podem escolher se a adotam ou não ------ mas na prática a maioria das pessoas acaba adotando automaticamente. Assim, embora essa funcionalidade proteja os fundos dos usuários, ela tem, na essência, um certo grau de centralização.
3.2.3 A essência da funcionalidade da lista negra
A funcionalidade de lista negra na verdade não é uma lógica da camada de protocolo, mas sim uma camada adicional de segurança destinada a lidar com situações inesperadas e garantir a segurança dos fundos dos usuários.
É essencialmente um mecanismo de garantia de segurança. Semelhante a uma "corrente de segurança" presa à porta, que só é ativada para aqueles que desejam invadir a casa, ou seja, para aqueles que têm a intenção de prejudicar o protocolo. Para os usuários, isso significa:
Para os grandes investidores, os principais provedores de liquidez, o protocolo é o que mais deseja garantir a segurança dos fundos, pois na verdade os dados on-chain tvl são todos contribuídos pelos principais grandes investidores; para que o protocolo se desenvolva a longo prazo, é imprescindível priorizar a segurança.
Para os investidores individuais, contribuidores da atividade ecológica, apoiantes fortes da construção conjunta de tecnologia e comunidade. O projeto também espera atrair investidores individuais para co-construir, assim poderá gradualmente melhorar a ecologia e aumentar a taxa de retenção. E quanto ao campo do defi, a segurança dos fundos é sempre a prioridade.
A chave para determinar "se é descentralizado" deve ser se os usuários têm controle sobre seus ativos. Nesse aspecto, o SUI utiliza a Move.