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 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 falha lógica relacionada a um "problema de estouro de inteiros" para realizar 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 campo 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 SUI caiu mais de 330 milhões de dólares no dia do ataque, e o valor bloqueado no protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como efeito colateral, vários tokens populares na SUI despencaram de 76% a 97% em apenas uma hora, gerando ampla preocupação do 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. Apesar do incidente Cetus ter trazido flutuações de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram um declínio contínuo, mas, ao contrário, impulsionaram uma atenção significativa de 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 Implementação do ataque
De acordo com a análise técnica da equipe Slow Mist sobre o incidente de ataque a Cetus, os hackers conseguiram explorar uma vulnerabilidade crítica de estouro aritmético no protocolo, utilizando empréstimos relâmpago, manipulação precisa de preços e falhas contratuais para roubar mais de 200 milhões de dólares em ativos digitais em um curto período de tempo. O caminho do ataque pode ser dividido aproximadamente nas seguintes três fases:
①Iniciar um empréstimo relâmpago, manipular preços
Os hackers inicialmente utilizaram um empréstimo relâmpago de 10 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 tomem emprestado 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 esse mecanismo para reduzir rapidamente o preço do mercado e controlá-lo com precisão dentro de um intervalo extremamente estreito.
Em seguida, o atacante se prepara para criar uma posição de liquidez extremamente estreita, definindo a faixa de preços precisamente 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%.
Dessa forma, os hackers conseguiram manipular 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, afirmando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
Essencialmente, isso se deve a duas razões:
A configuração da máscara é muito ampla: equivale a um enorme limite de adição de liquidez, o que torna a verificação de entrada do usuário no contrato inútil. Os hackers, ao configurarem parâmetros anormais, constroem entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.
A transbordamento de dados foi truncado: ao executar a operação de deslocamento n << 64 em um valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dado uint256 (256 bits). A parte superior que transbordou 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 é cerca de 1, mas como é arredondado para cima, o resultado final é igual a 1, ou seja, o hacker só precisa adicionar 1 token para obter 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 múltiplos pools de liquidez.
A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:
1290 milhões de SUI (cerca de 5400 mil dólares)
6000万美元USDC
490万美元Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75-80%, com liquidez esgotada.
2.2 A causa e as características da vulnerabilidade desta vez
A vulnerabilidade do Cetus tem três características:
O custo de reparação é extremamente baixo: por um lado, a causa fundamental do incidente Cetus foi uma falha na biblioteca matemática do Cetus, e não um erro no mecanismo de preços do protocolo ou uma falha na arquitetura subjacente. Por outro lado, a vulnerabilidade está limitada apenas ao Cetus, não tendo relação com o código do SUI. A origem da vulnerabilidade está em uma 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 dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.
Alto grau de ocultação: O contrato está em funcionamento estável e sem falhas há dois anos, o Cetus Protocol passou por várias auditorias, mas não foram encontrados vulnerabilidades, 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 precisamente intervalos de negociação, criando cenários extremamente raros de liquidez elevada, o que desencadeia lógicas anómalas, indicando que tais problemas são difíceis de descobrir através de testes comuns. Esses problemas costumam estar em uma zona cega da percepção das pessoas, por isso permanecem ocultos por muito 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, incorporando a detecção nativa de problemas de estouro de inteiros em cenários comuns. Este estouro ocorreu porque, ao adicionar liquidez, ao calcular a quantidade necessária de tokens, foi inicialmente utilizado um valor incorreto para a verificação do limite superior e a operação de deslocamento foi usada no lugar da operação de multiplicação convencional, enquanto se fossem usadas operações convencionais de adição, subtração, multiplicação ou divisão, o Move verificaria automaticamente a situação de estouro, não ocorrendo este problema de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity, Rust), e são até mais fáceis de serem exploradas 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., e a causa direta foi que o resultado da operação ultrapassou o limite. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas através de parâmetros cuidadosamente elaborados, contornando as instruções de verificação dentro do contrato para realizar transferências excessivas.
3. Mecanismo de consenso do SUI
3.1 Introdução ao mecanismo de consenso SUI
Resumo:
SUI adota um framework 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 elevado quanto o PoW (Prova de Trabalho). Assim, o nível de descentralização do SUI é relativamente baixo, e a barreira de entrada para governança é relativamente alta, 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 da Epoch: 24 horas
Mecanismo de processo:
Delegação de direitos: Usuários comuns não precisam executar nós por conta própria, basta que façam a delegação de SUI para um validador candidato para participar da garantia de segurança da rede e da distribuição de recompensas. Este mecanismo pode reduzir a barreira de entrada para usuários comuns, permitindo que participem do consenso da rede através da "contratação" de validadores de confiança. Esta é uma das grandes vantagens do DPoS em relação ao PoS tradicional.
Representar a 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 elevando 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, reelecionando o conjunto de Validadores com base no peso dos votos, garantindo a vitalidade dos nós, a consistência de interesses e a descentralização.
As vantagens do DPoS:
Alta eficiência: devido ao número controlável de nós de bloco, a rede pode completar a confirmação em milissegundos, atendendo à alta demanda de TPS.
Baixo custo: Menos nós participando do consenso resultam em uma redução significativa na largura de banda de rede e nos recursos computacionais necessários para sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e operação diminuem, a demanda por poder computacional é menor, e os custos são reduzidos. Isso resulta, em última instância, 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; combinado com o mecanismo de confisco na 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 cheguem a um consenso para confirmar uma transação. Este mecanismo garante que, mesmo que um pequeno número de nós aja de forma maliciosa, a rede possa permanecer segura e operar de forma 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.
Essencialmente, o DPoS é uma solução de compromisso para o triângulo impossível, que faz um compromisso entre descentralização e eficiência. No "triângulo impossível" de segurança-descentralização-escalabilidade, o DPoS opta por reduzir o número de nós ativos de criação de blocos em troca de um desempenho superior, renunciando a um certo grau de total 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, a SUI rapidamente congelou 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 blockchain. Os nós de validação são componentes centrais da blockchain SUI, responsáveis por validar transações e executar regras de protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores equivalem a implementar, em nível de consenso, um mecanismo semelhante ao 'congelamento de contas' na finança tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de blacklist que pode bloquear qualquer transação envolvendo endereços listados. Como essa funcionalidade já está presente no cliente, quando um ataque ocorre,
SUI pode congelar imediatamente o endereço de um hacker. Se não houver essa funcionalidade, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores um a um em um curto período 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 hot reload 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 a consistência e eficácia das políticas 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 define e atualiza esta lista de rejeição.
SUI publica uma lista negra, teoricamente os validadores podem escolher se adotam ou não ------ mas, na prática, a maioria das pessoas automaticamente adotará. Assim, embora esta funcionalidade proteja os fundos dos usuários, ela, na essência, realmente possui um certo grau de centralização.
3.2.3 A essência da funcionalidade de 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 para lidar com situações imprevistas, garantindo 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, é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que pretendem prejudicar o protocolo. Para o usuário:
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 na cadeia tvl são todos contribuídos pelos principais grandes investidores. Para que o protocolo se desenvolva a longo prazo, certamente priorizará a segurança.
Para os investidores individuais, contribuintes da atividade do ecossistema e fortes apoiantes da construção conjunta de tecnologia e comunidade. O projeto também espera conseguir atrair investidores individuais para co-construir, de forma a melhorar gradualmente o ecossistema e aumentar a taxa de retenção. E para o campo do defi, a prioridade continua a ser a segurança dos fundos.
O fator chave para determinar "se é centralizado" deve ser se os usuários têm controle sobre seus ativos. Nesse aspecto, o SUI, através da linguagem de programação Move, reflete o controle dos usuários sobre os ativos.
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
SchrodingersPaper
· 16h atrás
Outra onda de Rekt, SUI me matou dez mil vezes... mas eu ainda não consigo resistir a entrar na retração.
Ver originalResponder0
MEVHunterLucky
· 16h atrás
sui triste volta triste de qualquer forma eu lembro que não perdi nada
SUI ecossistema exibe resiliência: Reflexões de segurança após o ataque da Cetus e análise do potencial de desenvolvimento a longo prazo
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 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 falha lógica relacionada a um "problema de estouro de inteiros" para realizar 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 campo 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 SUI caiu mais de 330 milhões de dólares no dia do ataque, e o valor bloqueado no protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como efeito colateral, vários tokens populares na SUI despencaram de 76% a 97% em apenas uma hora, gerando ampla preocupação do 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. Apesar do incidente Cetus ter trazido flutuações de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram um declínio contínuo, mas, ao contrário, impulsionaram uma atenção significativa de 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 Implementação do ataque
De acordo com a análise técnica da equipe Slow Mist sobre o incidente de ataque a Cetus, os hackers conseguiram explorar uma vulnerabilidade crítica de estouro aritmético no protocolo, utilizando empréstimos relâmpago, manipulação precisa de preços e falhas contratuais para roubar mais de 200 milhões de dólares em ativos digitais em um curto período de tempo. O caminho do ataque pode ser dividido aproximadamente nas seguintes três fases:
①Iniciar um empréstimo relâmpago, manipular preços
Os hackers inicialmente utilizaram um empréstimo relâmpago de 10 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 tomem emprestado 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 esse mecanismo para reduzir rapidamente o preço do mercado e controlá-lo com precisão dentro de um intervalo extremamente estreito.
Em seguida, o atacante se prepara para criar uma posição de liquidez extremamente estreita, definindo a faixa de preços precisamente 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%.
Dessa forma, os hackers conseguiram manipular 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, afirmando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
Essencialmente, isso se deve a duas razões:
A configuração da máscara é muito ampla: equivale a um enorme limite de adição de liquidez, o que torna a verificação de entrada do usuário no contrato inútil. Os hackers, ao configurarem parâmetros anormais, constroem entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.
A transbordamento de dados foi truncado: ao executar a operação de deslocamento n << 64 em um valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dado uint256 (256 bits). A parte superior que transbordou 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 é cerca de 1, mas como é arredondado para cima, o resultado final é igual a 1, ou seja, o hacker só precisa adicionar 1 token para obter 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 múltiplos pools de liquidez.
A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:
2.2 A causa e as características da vulnerabilidade desta vez
A vulnerabilidade do Cetus tem três características:
O custo de reparação é extremamente baixo: por um lado, a causa fundamental do incidente Cetus foi uma falha na biblioteca matemática do Cetus, e não um erro no mecanismo de preços do protocolo ou uma falha na arquitetura subjacente. Por outro lado, a vulnerabilidade está limitada apenas ao Cetus, não tendo relação com o código do SUI. A origem da vulnerabilidade está em uma 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 dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.
Alto grau de ocultação: O contrato está em funcionamento estável e sem falhas há dois anos, o Cetus Protocol passou por várias auditorias, mas não foram encontrados vulnerabilidades, 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 precisamente intervalos de negociação, criando cenários extremamente raros de liquidez elevada, o que desencadeia lógicas anómalas, indicando que tais problemas são difíceis de descobrir através de testes comuns. Esses problemas costumam estar em uma zona cega da percepção das pessoas, por isso permanecem ocultos por muito tempo até serem descobertos.
Move é superior a várias linguagens de contratos inteligentes em segurança de recursos e verificação de tipos, incorporando a detecção nativa de problemas de estouro de inteiros em cenários comuns. Este estouro ocorreu porque, ao adicionar liquidez, ao calcular a quantidade necessária de tokens, foi inicialmente utilizado um valor incorreto para a verificação do limite superior e a operação de deslocamento foi usada no lugar da operação de multiplicação convencional, enquanto se fossem usadas operações convencionais de adição, subtração, multiplicação ou divisão, o Move verificaria automaticamente a situação de estouro, não ocorrendo este problema de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity, Rust), e são até mais fáceis de serem exploradas 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., e a causa direta foi que o resultado da operação ultrapassou o limite. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas através de parâmetros cuidadosamente elaborados, contornando as instruções de verificação dentro do contrato para realizar transferências excessivas.
3. Mecanismo de consenso do SUI
3.1 Introdução ao mecanismo de consenso SUI
Resumo:
SUI adota um framework 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 elevado quanto o PoW (Prova de Trabalho). Assim, o nível de descentralização do SUI é relativamente baixo, e a barreira de entrada para governança é relativamente alta, tornando difícil para usuários comuns influenciar diretamente a governança da rede.
Mecanismo de processo:
Delegação de direitos: Usuários comuns não precisam executar nós por conta própria, basta que façam a delegação de SUI para um validador candidato para participar da garantia de segurança da rede e da distribuição de recompensas. Este mecanismo pode reduzir a barreira de entrada para usuários comuns, permitindo que participem do consenso da rede através da "contratação" de validadores de confiança. Esta é uma das grandes vantagens do DPoS em relação ao PoS tradicional.
Representar a 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 elevando 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, reelecionando o conjunto de Validadores com base no peso dos votos, garantindo a vitalidade dos nós, a consistência de interesses e a descentralização.
As vantagens do DPoS:
Alta eficiência: devido ao número controlável de nós de bloco, a rede pode completar a confirmação em milissegundos, atendendo à alta demanda de TPS.
Baixo custo: Menos nós participando do consenso resultam em uma redução significativa na largura de banda de rede e nos recursos computacionais necessários para sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e operação diminuem, a demanda por poder computacional é menor, e os custos são reduzidos. Isso resulta, em última instância, 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; combinado com o mecanismo de confisco na 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 cheguem a um consenso para confirmar uma transação. Este mecanismo garante que, mesmo que um pequeno número de nós aja de forma maliciosa, a rede possa permanecer segura e operar de forma 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.
Essencialmente, o DPoS é uma solução de compromisso para o triângulo impossível, que faz um compromisso entre descentralização e eficiência. No "triângulo impossível" de segurança-descentralização-escalabilidade, o DPoS opta por reduzir o número de nós ativos de criação de blocos em troca de um desempenho superior, renunciando a um certo grau de total 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, a SUI rapidamente congelou 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 blockchain. Os nós de validação são componentes centrais da blockchain SUI, responsáveis por validar transações e executar regras de protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores equivalem a implementar, em nível de consenso, um mecanismo semelhante ao 'congelamento de contas' na finança tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de blacklist que pode bloquear qualquer transação envolvendo endereços listados. Como essa funcionalidade já está presente no cliente, quando um ataque ocorre,
SUI pode congelar imediatamente o endereço de um hacker. Se não houver essa funcionalidade, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores um a um em um curto período 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 hot reload 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 a consistência e eficácia das políticas 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 define e atualiza esta lista de rejeição.
SUI publica uma lista negra, teoricamente os validadores podem escolher se adotam ou não ------ mas, na prática, a maioria das pessoas automaticamente adotará. Assim, embora esta funcionalidade proteja os fundos dos usuários, ela, na essência, realmente possui um certo grau de centralização.
3.2.3 A essência da funcionalidade de 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 para lidar com situações imprevistas, garantindo 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, é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que pretendem prejudicar o protocolo. Para o usuário:
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 na cadeia tvl são todos contribuídos pelos principais grandes investidores. Para que o protocolo se desenvolva a longo prazo, certamente priorizará a segurança.
Para os investidores individuais, contribuintes da atividade do ecossistema e fortes apoiantes da construção conjunta de tecnologia e comunidade. O projeto também espera conseguir atrair investidores individuais para co-construir, de forma a melhorar gradualmente o ecossistema e aumentar a taxa de retenção. E para o campo do defi, a prioridade continua a ser a segurança dos fundos.
O fator chave para determinar "se é centralizado" deve ser se os usuários têm controle sobre seus ativos. Nesse aspecto, o SUI, através da linguagem de programação Move, reflete o controle dos usuários sobre os ativos.